httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodent of Unusual Size <Ken.C...@Golux.Com>
Subject Re: httpd-docs CVS modules
Date Fri, 21 Apr 2000 16:40:33 GMT
Marc Slemko wrote:
> The avail file isn't anything more than an arbitrary file that
> is checked by an arbitrary ( 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 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

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 -- 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                    <http://Golux.Com/coar/>
Apache Software Foundation  <>
"Apache Server for Dummies" <http://Apache-Server.Com/>
"Apache Server Unleashed"   <http://ApacheUnleashed.Com/>

View raw message