stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: Convention for merge changelogs
Date Tue, 05 Feb 2008 02:05:34 GMT
William A. Rowe, Jr. wrote:
> 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.

The [still draft] release process says that committers decide on
a set of Release Criteria:
   http://stdcxx.apache.org/releases.html#release_criteria

and vote in a Release Manager for each release:
   http://stdcxx.apache.org/releases.html#release_manager

The idea is that the RM is then responsible for stabilizing the release
branch while adhering to the Release Criteria. To make the RM's job
easier everyone else agrees to follow the RTC policy on the release
branch, with the RM being entrusted with the responsibility to decide
which changes get to go in the release and when they're ready to be
integrated. Committers can go on working on trunk under CRT, or on
other release branches in parallel (with or without another RM).
This approach was modeled on release processes used by other open
source projects (including HTTPD, gcc, and Boost).

> 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.

We could change the process to eliminate the RM role and instead act
as a committee but it seems to me that by doing so we would very
likely slow the release process down without any benefit. Instead of
having two votes up front (to decide on the Release Criteria and to
choose the Release Manager) we'd likely end up with a whole number
of "little" votes.

> 
> 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.

We're working on opening up the build and test process so that anyone
can easily submit their build logs and have them show up on the results
page, but we're not there yet.

Martin

> 
> Bill
> 
> 
> 
> 


Mime
View raw message