[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