Bioperl: New list management, bug fixing rules

[Steve Chervitz]

Ewan Birney writes:
 > 
 > 
 > Firstly noone has complained about moving the discussion onto this list.
 > This means that the guts list should only be for:
 > 
 > 	a) automatic notification from bug list
 > 	b) automatic cvs notification (I'll activate this soon)
 > 	c) cvs branch management for people working on moving bugs around.
 > 
 > *Everything* else - all the new module "xxx" proposal or "I have made the
 > following fix" type mails should be directed here. I'll move mails
 > over here if they are inappropiately posted...
 > 
 > This should mean that alot of people will want to unsubscribe from guts.
 > 
 > 
 > Secondly - Jason and Elia - it is great to see you both fixing bugs
 > on the branch, but you have to be careful about using the mail address. Do
 > not reply to all addresses - you submit a new bug. Also - if you are doing
 > alot of bug rearrangement, switch off notification to guts and then email 
 > a precise of your work, in this case to guts.
 > 
 > 
 > Thirdly - Branch/Main trunk ettiquette:
 > 
 > 	Reminder -
 > 
 > 	The branch is *only for bugs*. Anything that looks like a feature
 > goes on the main trunk. Now we have anonymous cvs, main trunk code is very
 > accessible for people who "must have feature xxx". The absolute goal of
 > the branch is 0 bugs. 
 > 
 > 	- so far we have kept to this. 
 > 
 > 
 > 	People who work on the branch *should clear their fixes* on this
 > list first. Post here, wait 1 day and if there is no complaints, fix on
 > the branch. 
 > 
 > 	Finally - the people who do a fix on the branch are responsible
 > for migrating the fixes onto the main trunk. There will no longer be a
 > global cvs merge. I have noticed that this is the way most other projects
 > work and I think it is better (comments anyone?)

(My comment qualifies for the guts list, but since the original
message was posted here, I'm replying here as well.)

Arguments against manual bugfix migration:

  - It doubles development effort to have to do your fix in both places.
  - You may forget to fix in both the trunk and branch.
  - If you have multiple fixes, you may forget to move some of them.

However, merging can be messy, especially when you need to merge into
the trunk more than once. Tagging the branch after the merge helps
here. Still, coordinating a merge amonst many developers is a challenge.

When you have a few, isolated bugs, it seems okay to patch both the
branch and trunk. But with many, related bug fixes, it could be easier
to fix on the branch and then merge en masse into trunk (as I did with
the Blast module fixes on the 0.05 branch -> trunk).

Maybe we should leave it up to the developer to decide how to get
their fixes from the branch to the trunk. They can repeat the fix in
the trunk if it's simple, or do a cvs merge if the fix is more
involved. If someone is planning to do a merge, they should inform the
group well in advance.

It would be a good idea to spell out our policy somewhere on the
website.

Steve 
sac@neomorphic.com

 > 
 > 	I notice that I have actually broken all three rules (bad Ewan!)
 > and I will be migrating a raft of fixes from the branch into the main
 > trunk this week - I hope -
 > 
 > 
 > 
 > Happy bioperl'ing. BTW - many thanks for the people who have mailed me
 > about the 0.6 release - it is great to have positive feedback. Feel free
 > to mail to the list as well.
 > 
 > 
 > 
 > 
 > -----------------------------------------------------------------
 > Ewan Birney. Mobile: +44 (0)7970 151230, Work: +44 1223 494420
 > <birney@ebi.ac.uk>. 
 > -----------------------------------------------------------------
 > 
 > =========== Bioperl Project Mailing List Message Footer =======
 > Project URL: http://bio.perl.org/
 > For info about how to (un)subscribe, where messages are archived, etc:
 > http://www.techfak.uni-bielefeld.de/bcd/Perl/Bio/vsns-bcd-perl.html
 > ====================================================================
 > 
=========== Bioperl Project Mailing List Message Footer =======
Project URL: http://bio.perl.org/
For info about how to (un)subscribe, where messages are archived, etc:
http://www.techfak.uni-bielefeld.de/bcd/Perl/Bio/vsns-bcd-perl.html
====================================================================