Re: 3.4 and bug reports

[John W. Eaton]

On  9-Feb-2011, Jordi Gutiérrez Hermoso wrote:

| The release manager would, because he would keep a separate sanctified
| repo and would decide if and when to pull the 3.4 patches we make.
| Everyone can propose a patch there, but only the release manager
| decides to pull it. If we all had our private repos public, this could
| be a bit easier. Maybe this sounds awkward, though?

I want to keep the branches in the public archive, and I want fairly
tight control over the release branches.  Since I don't have direct
access to the public archive on savannah that would allow me to strip
changes when things get screwed up, I really don't want multiple
people checking things in on the release branches.

And as I've said before, I don't like having random branching and
merging on the public archive because it makes it much harder for me
to follow what is happening with the changes at merge points.  Maybe
someday I'll see the folly in my position and it will change, but for
now I still want to see a linear history in the public archive.

There is nothing preventing you from having your archive public if
that is what you want.

| It introduces some weirdness in history and statistics. Now that I'm
| working on the codeswarm, it's introduced a bit of noise, since some
| people seem doubly active, although if their patches went into 3.4,
| perhaps they deserve it.

For the purposes of codeswarm, can't you just look at the default
branch?  If there is no option for that, then can't you strip branches
from an hg archive so that you will only have the default branch?

| I know this sounds frivolous, but it could
| also reduce work for the release manager, all he has to do is pull and
| push, not transplant.

Transplanting is not too much trouble.  I agree that it is not great
that transplanting results in two changesets instead of just one, but
I can live with that, at least for now.

jwe