On Jun 1, 2009, at 3:41 PM, Paul Davis wrote:
On Mon, Jun 1, 2009 at 3:26 PM, Damien Katz <[email protected]> wrote:
On Jun 1, 2009, at 3:00 PM, Chris Anderson wrote:
Devs,
We've talked some about discontinuing use of svn's merge/block
procedure for maintaining old release branches, in favor just asking
committers to remember to put applicable patches into the 0.9.x
branch.
My experience is that by default, patches shouldn't be included in
branches.
The point of branches is to provide a an increasingly stable code
base, so
that users of the branch can get updates and upgrade with little
fear the
update will introduce a change in behavior or regression into their
production systems.
Therefore, only patches that fix serious bugs (data loss, hangs) or
regressions (features that worked in previous versions no longer
work)
should be considered for merging. Any patch that is merged back
should be
justifiable as to why it's important enough to risk destabilizing the
branch.
I think idea that we need to track all the patches going into trunk
and the
branches, because we might forget an important patch. Yes, we might
forget
an important patch, but then we can simply apply to the next
release of the
branch if its that important. Rather than track all the patches for
all
branches, we should rely on the community to tells us what's an
important
patch and what is not.
-Damien
I'm in complete agreement with one caveat. I would imagine that the
group of people that care about a maintenance branch, and the group
that pays attention to the individual commits have a relatively small
overlap. If there were some mechanism that we agreed on for getting
public feed back on possible maintenance patches I'd be cool.
I think we should just ask the mailing list, "Are there any trunk
fixes you want to see in 0.9.1?" a week before we release.
The reason I tend to worry about this is that I seem to do alot of
user facing patches that I kinda waffle on whether they should be
maintenance or not. A prime example would be whether patches that
improve error messages should go in or not. I can see good arguments
for both sides. Even something like, "submit it to the user@ for an
informal vote" before putting in maintenance would be good enough for
me.
IMO, unless that patch fixes a serious bug, it shouldn't be merged
back. There is no objective criteria for what's is serious enough for
inclusion, but I think at the minimum we need one person who thinks
it's serious enough for inclusion, and at least on contributor who
familiar enough with the area to weigh the risks of regression with
the patch. And while I don't want to institute such a rule just yet,
once we hit 1.0, all patches to a stable branch should be reviewed by
2 contributors.
-Damien
Paul Davis
There is discussion to be had about what patches are applicable to
point release branches.
Perspectives?
Chris
--
Chris Anderson
http://jchrisa.net
http://couch.io
