Return-Path: Delivered-To: apmail-new-httpd-archive@apache.org Received: (qmail 20593 invoked by uid 500); 21 Apr 2000 16:41:32 -0000 Mailing-List: contact new-httpd-help@apache.org; run by ezmlm Precedence: bulk X-No-Archive: yes Reply-To: new-httpd@apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list new-httpd@apache.org Received: (qmail 20579 invoked from network); 21 Apr 2000 16:41:31 -0000 Message-ID: <39008481.207B555F@Golux.Com> Date: Fri, 21 Apr 2000 12:40:33 -0400 From: Rodent of Unusual Size Organization: The Apache Software Foundation X-Mailer: Mozilla 4.06 [en] (WinNT; U) MIME-Version: 1.0 To: new-httpd@apache.org Subject: Re: httpd-docs CVS modules References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N Marc Slemko wrote: > > The avail file isn't anything more than an arbitrary file that > is checked by an arbitrary (cvs_acls.pl) bit of code that can do > whatever it wants. And that I think we shouldn't screw with it if we don't have to, since a buglet there affects ALL of the ASF projects. It works, it ain't broke, so don't fix it. > > a. because the first time someone who has the wider CVS access > > adds something, it won't be owned by the docs group but by > > the code group. Manual intervention by someone with root required. > > So why doesn't that happen right now with people in multiple groups? Possibly because we don't have any subsetted modules, so it never comes up? Ah, my bad -- you're suggesting that everyone with code access automatically be a member of the docs group as well, but that doc workers be only in the docs group? Yea, that should work. That's not how I was looking at your suggestion. Minor bobbles if whoever's adding a developer forgets to add them to the docs group, but that can be handled, and would happen anyway. > Oh. So you are proposing a lot more than just splitting out the docs > tree. You are proposing that we never have any branches for docs > within a major version? Ouch. Huh? Not at all. See the end of this message. > I asked the same question and got essentially the same answer a > year ago... that's all. If it will really happen, great. If > "httpd" is the direction to go in (which I support), great. But > in the past when I suggested "httpd" for things instead of "apache" > people didn't like it. It sounds like everyone's happy with 'httpd-docs*' now. > And by pulling the docs out, you are encouraging it to change even > less and stay up to date even less. That's almost impossible. :-) By pulling it out, or rather making work on it possible for people who don't have code access, we're encouraging people who want to improve its readability to help in that area. Coders can still keep the docs in their accustomed place in the tree with cd apache-1.3 cvs -d locus.apache.org:/home/cvs co -d htdocs httpd-docs-v1 and from that point on CVS should do things reasonably magically. > "foo-1.3" > "foo-v1" > > Where did the "v" come from? "foo-1.3" is clearly a version number in this context. "foo-1" isn't -- it's just the first *something* of foo. If we leave the point release on, the 'v' isn't necessary. If we keep just the major number, I think the 'v' (or something similar) should stay to make this clear. > I'm confused. So would you expect there to be branches or not? Your > earlier talk about what not having versions for each x.y tree implied > that you didn't want that at all. You're confusing yourself; don't blame me. :-) If there's one module for the 1.* docs, and another for the 2.* docs, then yes, there would be branches. If there's a 1:1 relationship between code and doc modules (i.e., a docs module for each of 1.2, 1,3, 2.0, ...), then branches aren't necessary. But I think the latter approach is stupid and wasteful. > It doesn't make any sense to me to use branches for the docs in places > that different repositories are used in the code. Well, it makes sense to me, since having a completely separate module for 1.3 that's only a tiny bit different from, and mostly the same as, the one for 1.2 seems stupid. But if you really feel strongly that there should be a unique docs area for each unique code module, it's no big deal. > > No, this is a separate reason: taking the onus and responsibilty > > of tracking crap about which they don't care off the coders who > > want to work on code. Namely, the current commit list. > > They all contribute to the exact same goal: allowing more open access > to the docs. I have seen no other reasons presented. Then you're not understanding. But have it your way; that's a sufficient-enough reason. > So it has already been decided that we want to have translations > of the docs and how we are going to support such translations given > that they will always be at least one step behind the english docs? Considering the enthusiastic embracing of translations of the 'it worked' page over the last few months, I think it has been decided, yes. I think it has always been somewhat implicit that one reason to open them up was to allow people to translate them. Dirk, wasn't that your understanding? > > You come up with a solution that RELIABLY allows some people to > > hack on *only* one portion of a module under our current CVS setup > > and I'll be glad to hear it. Unfortunately, I don't see one. > > $ for user in `users in httpd group`; do add user to httpd-docs group; done > $ chgrp -R httpd-docs $CVSROOT/apache-?.?/htdocs Don't forget 'repeat step 1 every time someone is added to the httpd group.' But that would be necessary anyway, so it falls out. This was due to my misunderstanding of your earlier point. Objection withdrawn -- this one, at least. > People should, whenever possible, make appropriate changes to docs > whenever any code is committed. The docs are not this separate entity > that exists independent of the code. They need the same version > control, etc. that the code does. And they deserve far better attention than they get, or are likely to get in the current framework. > The very fact that you are suggesting that we don't need a docs tree > for each dev tree shows one of the reasons why pulling them out of the > code tree is a bad idea. Non sequitur. > I'm afraid that the only reply I can see to the message of mine that > you quote above just ignored my question about why it is necessary... Ah, so we're down to 'necessity,' then? Not relative goodness? Or even admissions of 'I don't know so let's try it'? *I* make that one. > > Perhaps not an overwhelming 'go for it,' but Brian, Dirk, Jim, Ryan, > > Ben, Randy, and I were quite in favour, Ralf seemed amenable, and > > you were the only one with questions. > > You can't use support for something a year ago as a prerogative to > go ahead and so something somewhat similar (but different) now > without proper discussion... Fine, so we're having the discussion now. Possibly with repeats. > > Given that list of support, unless you veto I'm still planning to > > go ahead. (Or if those people change their minds. :-) > > -1 > > If you can give a good reason why you need to move them to their own > top level directory under CVSROOT, fine. But I haven't seen any > reason. And I don't see any valid justification for your veto. But never mind. Here's another reason: Where the CVS mail gets sent is determined from the CVS module it's in. Well, actually, which top-level directory it's under. Unless we change that -- and I don't think it would be a simple change, and again it's to something that isn't broken (namely log_accum.pl) -- all changes to the docs would be sent to the apache-*-cvs mailing lists. So developers on the list would see doc changes -- but doc workers would also be forced to see the flood of code change messages. By putting the docs in a separate module, developers can stay up-to-date by subscribing to the docs-cvs list as well as apache-*-cvs, and doc workers can avoid the flood by *not* subscribing to the apache-*-cvs list. > And I do not understand what you are proposing WRT dealing with docs > trees for each separate x.y version. I'm easy -- either one module for the v1 docs and one for the v2 docs, each with appropriate branches, or one docs module for each code tree. Though I think the latter is stupid, particularly in light of the recent discussion about 'we should take better advantage of CVS' capabilities.' But whatever. Here's an idea: Rather than *moving* the docs, do you have any objection to them being *copied* into separate modules and turning the interested people loose on them? Someone can stand up to merge the changes back and forth, and we can see just how well it works. If it works according to my optimisim, we can revisit *moving* them later; if it falls out according to your pessimism, we can just shut down that project and revert to the way we've always done things. -- #ken P-)} Ken Coar Apache Software Foundation "Apache Server for Dummies" "Apache Server Unleashed"