stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: Convention for merge changelogs
Date Tue, 05 Feb 2008 00:23:41 GMT
Martin Sebor wrote:
> 
> After Feature Freeze, our release process says that only the RM
> does merges. Unless the RM wants to merge each change individually
> the multi-change format is the only one that makes sense.

Just want to point out or clarify a few things...

multichange commits become much harder to follow, therefore they may
be an obstacle to devs during a release vote.  But either way, what
you describe above is the process most ASF projects apply to one
release.  So let's say for a moment that Travis wants a release, and
you want a release, and have different goals.  Both branch, patch
and tag, and the community votes on which release is right.

It's a really obscure way to an end point (one release that the project
agrees to), but it ensures a project's never hostage to only-one-way
to get things done.  It's an example of why a release can't be vetoed.

But I want to clarify, no one individual ever has sole commit authority
over a maintenance branch, period.  I know this came up during incubation,
but the policy is very harsh.  The ASF is not about individual PMC
members, not even the chairman, but it's a flat meritocracy.  So the code
is either C-T-R with every committer having direct-access, or R-T-C with
every committer proposing patches, and a community vote (not one person's
decision) over the patches that are applied.

I'm a bit concerned, what with RW's generous test and build mechanics,
etc, that the project does appear more homogeneous than even at the point
it graduated (incubation is not the end of the diversity and broader
community requirements).  I've noticed about 3 or 4 posts a month which
read as entirely partisan/commercial, and I'd appreciate if everyone would
keep their eyes out for such problems.

Bill




Mime
View raw message