[WG: Sakai QA] Branch management strategies

Noah Botimer botimer at umich.edu
Sun Aug 23 07:29:44 PDT 2009


This is completely fair. It seems to me that the guidelines on what  
is appropriate, important, urgent, or inappropriate are the key here,  
not the mechanics of merging (why and what, not how).

Sliding toward either of "all my fixes are blockers" or "we shouldn't  
fix anything but data loss and security" is not in the best interest  
of overall production quality.

There is also some natural attenuation of change priority for a major  
version over time. We fix a lot in trunk, quite a bit in the most  
recent release early, a few things in a release as it approaches  
being "two back", and almost nothing in whatever is two versions back  
(especially as it ages). This ramp-down toward increased stability is  
mirrored in most software projects that have multiple supported  
versions at a time. If you need stronger stability assurance, you use  
an older release, on the principle that it has been in use longer and  
stuff that has been released more recently has more important  
oversights in it.

I think that a branch commit from an informed, diligent contributor  
is a rather appropriate indication of intent of maintenance release  
inclusion. Debatable issues should be discussed beforehand.  
Questionable merges should be flagged, discussed, and maybe backed  
out. If someone goes through the trouble of backporting, recompiling,  
testing, and merging a fix, there's a high likelihood it will be  
important to production installations.

I think we should optimize for this common case more than for fear of  
rare cowboy merges. This also streamlines QA since the fixes will be  
on a nightly where they can be tested without asking QA personnel to  
customize builds for single issues. It also addresses the branch  
manager workload some, focusing on monitoring the sanity of the  
branch, not compiling and merging hundreds of changes. Again, clear  
guidelines of what happens before merge are the key, not necessarily  
who vets or applies merges.

Thanks,
-Noah

On Aug 22, 2009, at 3:08 AM, Stephen Marquard wrote:

> Sometimes the point of a maintenance branch is stability and  
> predictability rather than quality, or to put it another way, every  
> fix introduces a risk of regression, and there is an appropriate  
> balance between risk and improvement.
>
> So making the "fix to merge" interval as short as possible and  
> involve as few people as possible to increase the number of fixes  
> going into maintenance branches is not necessary a desireable goal.
>
> Let's say every 10 merged fixes introduce 1 functional regression.  
> If you're running a maintenance branch in production, do you want  
> old bugs fixed at the expense of new bugs introduced? Sometimes, to  
> quote Glenn from way back, you want to fix "as little as possible"  
> rather than "as much as possible".
>
> Cheers
> Stephen
>
>>>> Anthony Whyte <arwhyte at umich.edu> 8/22/2009 5:25 AM >>>
> In other words, imagine the portfolio team with the puck in the
> offensive zone with an opportunity to score.  Why force them to dish
> the puck off to a branch manager back on the blue line when Beth
> Kirschner is in position to top-shelf the goalie with a wrist shot
> from just above the circle?
>
> I think she should take the shot.
>
> Anth
>
>
>
> On Aug 21, 2009, at 7:16 PM, Noah Botimer wrote:
>
>> I see this as strikingly accurate and exceedingly valuable.
>> Monitoring makes more sense in most cases than gate keeping. The
>> kernel is most sensitive and already handled with some additional
>> guidelines and care. Cross-module dependencies are next and require
>> some level of cooperation, but I wouldn't say they beg for central
>> administration.
>>
>> For modules with no inward dependencies, I see limited value in
>> handing things off for the sake of handing them off. The folks who
>> apply fixes are usually the closest to the knowledge of how things
>> should work out. They are also the ones who are ultimately
>> responsible for the well-being of that module. The ability to merge
>> closer to the time of fix, by more familiar hands, is valuable for a
>> raft of sanity and quality reasons. It's also worth noting that none
>> of this requires that we lose any visibility of, or ability to raise
>> issue with, changes going into maintenance branches.
>>
>> If I were cheeky on a Friday evening, I might say that oversee is
>> the right verb, not overdo.
>>
>> Thanks,
>> -Noah
>
>
> <Part.002>_______________________________________________
> sakai-qa mailing list
> sakai-qa at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-qa
>
> TO UNSUBSCRIBE: send email to sakai-qa- 
> unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"



More information about the sakai-qa mailing list