Re: [GUSDEV] managing GUS releases

[Steve F. <sfi...@pc...>]

Fernan-

see below for response to your first point.

for your second point, i strongly urge you to cut and paste into a new 
posting to the group with an appropriate subject.   its too important a 
topic to be buried inside this one.

steve

Fernan Aguero wrote:

>+----[ sfi...@pc... <sfi...@pc...> (04.Jul.2005 09:09):
>|
>| Folks-
>| 
>| I have had a number of discussions with people at CBIL about how to manage GUS
>| version numbers and releases in the source code repository.
>| 
>| I have posted a proposal for this on the wiki at
>| http://www.gusdb.org/wiki/index.php/GusVersionBranch
>| 
>| If you have a chance to take a look before the GUS conference, this might make a
>| good topic for discussion.
>| 
>| Steve
>|
>+----]
>
>Steve,
>
>here are my ideas about the part of your proposal that deal
>with 'managing branches'. 
>
>I agree with you on the branching before release, therefore
>freeing the main trunk for continuing development towards
>future versions. I also agree on the 'tagging' of already
>released branches to provide landmarks of bug fixing
>activity. However I think that it should also be pointed out
>that usually you don't need to wait for the release engineer
>to post a new tarball ... in your example, people can just
>track the '3.6' branch and get all bug fixes irrespective of
>the minor version. Am i correct?
>  
>
i am not sure i understand what you mean by tracking the 3.6 branch.  
perhaps you mean downloading from the repository directly using the 
tag?   the one thing we don't want is for people to download and use 
untagged versions.  then we don't know what they have, and can't 
properly track bugs, etc

>The other issue that I would like to bring forward is that
>of control of the repository and user involvement in GUS
>development. These are not strictly related to the version
>managing, but since we're talking about the source
>repository and about setting a policy, perhaps it is also a
>good time to discuss these ideas:
>
>I'm sure that everyone agrees that the repository should not
>be open to everyone. All open source projects control access
>to repositories. But there should be a way to gain access to
>'commit privileges'. The following are standard practices in
>the FreeBSD community (with which I'm most familiar). I
>believe that these are both fair to all participants and
>work well to keep things clean:
>
>o every file or group of files has a maintainer. The
>  maintainer is responsible for these files. Users suggesting
>  changes to these files or sending patches need to get
>  approval from the maintainer. This usually works by CCing
>  the maintainer when you create a new item in bugzilla.
>  Approval is by a simple followup message from the
>  maintainer. Maintainership can be dropped or requested.
>  Some files do not have maintainers and are maintained by
>  'everyone', some files have active maintainers.  
>
>o some users have commit privileges (they can commit changes
>  to the repository). But maintainers != committers. Some
>  maintainers do not have commit privileges, some do.
>  Committers need to know how to deal with the repository,
>  maintainers only need to know about their files or their
>  area of development.
>http://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/
>
>o Usually you should participate in mailing lists and send
>  good patches, before you can ask for or be offered to have
>  commit privileges. And even when you're given the 'commit
>  bit', there is a period when you have a 'mentor' with whom
>  you should discuss everything before commiting (ie your
>  commits should be approved by your mentor). And even if you
>  have commit privileges and the maintainer doesn't you
>  cannot commit stuff without approval from the maintainer. 
>
>Perhaps some of this is already in place ... I'm fairly new
>to GUS, so I don't know how you guys give away commit
>privileges. But from what I've seen there is no
>'maintainership' as depicted above. From my experience in
>FreeBSD this is a great way to have users involved in the
>maintaince of code and documentation without giving
>widespread commit privileges. It has worked quite well for
>several projects. 
>
>Also, I wanted to stress the fact that producing tarballs
>for major releases is fine but you cannot do a release for
>every bug fixed on the repository.  Having a branch (3.6 in
>the example) that you can track using cvs or cvsup and that
>will only have non-breaking fixes is a good way to keep old
>releases supported.
>
>Sorry for the long email. Hope this adds to the project,
>
>Fernan
>  
>