Convention for merge changelogs

[Travis Vitek <Tr...@roguewave.com>]

I've noticed that we aren't being consistent about the changelog text
for merged changes. Here are a few examples.

	http://svn.apache.org/viewvc?rev=617627&view=rev
	http://svn.apache.org/viewvc?rev=614790&view=rev
	http://svn.apache.org/viewvc?rev=612563&view=rev
	http://svn.apache.org/viewvc?rev=616004&view=rev

As you can see there isn't much consistency. Sometimes we copy the
date-user-email line from the original commit, simetimes we don't.
Sometimes we list the jira issue number on a line of its own. Is there
an expected or required format for the merge changelogs? 

Travis

Re: Convention for merge changelogs

[Mark Brown <ma...@gmail.com>]

Travis Vitek-4 wrote:
> 
> 
> I've noticed that we aren't being consistent about the changelog text
> for merged changes. Here are a few examples.
> 
> 	http://svn.apache.org/viewvc?rev=617627&view=rev
> 	http://svn.apache.org/viewvc?rev=614790&view=rev
> 	http://svn.apache.org/viewvc?rev=612563&view=rev
> 
> 

Hi Travis,

In my opinion the last format makes sense when merging a whole
number of changes made by different authors. Otherwise I think
a more compact format should be fine.

Regards
-- Mark



> 
> 	http://svn.apache.org/viewvc?rev=616004&view=rev
> 
> As you can see there isn't much consistency. Sometimes we copy the
> date-user-email line from the original commit, simetimes we don't.
> Sometimes we list the jira issue number on a line of its own. Is there
> an expected or required format for the merge changelogs? 
> 
> Travis
> 
> 

-- 
View this message in context: http://www.nabble.com/Convention-for-merge-changelogs-tp15275740p15278361.html
Sent from the stdcxx-dev mailing list archive at Nabble.com.

Re: Convention for merge changelogs

[Martin Sebor <se...@roguewave.com>]

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

Re: Convention for merge changelogs

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

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

Re: Convention for merge changelogs

[Martin Sebor <se...@roguewave.com>]

Travis Vitek wrote:
> I've noticed that we aren't being consistent about the changelog text
> for merged changes. Here are a few examples.
> 
> 	http://svn.apache.org/viewvc?rev=617627&view=rev
> 	http://svn.apache.org/viewvc?rev=614790&view=rev
> 	http://svn.apache.org/viewvc?rev=612563&view=rev
> 	http://svn.apache.org/viewvc?rev=616004&view=rev
> 
> As you can see there isn't much consistency. Sometimes we copy the
> date-user-email line from the original commit, simetimes we don't.
> Sometimes we list the jira issue number on a line of its own. Is there
> an expected or required format for the merge changelogs? 

We started out with the second one on your list for merges involving
just one change. The generic form I've seen is the third one down,
i.e.,

   http://svn.apache.org/viewvc?view=rev&revision=612563

It scales beyond merging just a single change.

FWIW, I've been waffling on how/when it's best to do merges during
development. There are cases when I'd rather we hold off on merging
a change until it's gotten more exposure, both on the list and in
nightly testing. That way, when the change turns out to cause
problems on some platforms it only needs to be fixed on trunk. In
these cases, it might make sense to wait and merge a whole bunch
of good changes instead of just one. Then there are trivial changes
that are probably best merged right away and waiting would just add
unnecessary overhead. For these, the simple format should be good
enough.

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.

Martin

> 
> Travis
>