Re: Bug tracker and transplants

[Rik]

On 04/04/2011 07:14 AM, John W. Eaton wrote:
> On  3-Apr-2011, Jordi Gutiérrez Hermoso wrote:
> 
> | This is what the hg pros had to say about it:
> | 
> |      
> http://mercurial.808500.n3.nabble.com/Suggested-workflow-for-Octave-td2768774.html
> | 
> | Greg Ward's response seems particularly detailed.
> 
> Thanks.
> 
> I sent two responses to that thread.  The first is apparently being
> held for approval, but the second was posted and is here:
> 
>   http://selenic.com/pipermail/mercurial/2011-April/037835.html
> 
> So now that I finally understand this workflow better, I think it is
> good, provided we can train everyone to apply patches on the correct
> branch.
> 
> Have you looked at how hard it would be to switch to this workflow
> from where we are now?
I'm not sure about how much work there is, but I think this is an excellent
time to experiment and make a small point release (3.4.1).  First, we've
fixed a number of errors that were bound to happen with any *.*.0 release.
 Second, as soon as a determination for 'perror' and 'strerror' is made, I
will have finished incorporating every single function visible to Octave
into the documentation.  I.e., the documentation will have mostly caught up
with the code.
> 
> Are there changes that break binary compatibility or any otherwise
> risky changes that have been applied to the default branch since the
> 3.4.0 release?  If not, then we could just merge and start using this
> method now.  But if there are some changesets that should only appear
> on default and not stable, I think there will be a little more work
> involved in making the switch.

And for those who would rather not understand all the gritty details of the
version control system, are there some simple rules that could be published
and also added to the Contribution Guidelines section of the documentation?
 I read the discussion, but it still wasn't immediately obvious to me how
I, as a developer, should behave and what the benefit was.  In particular,
the frequent merges of stable to default (recommended every 8-10
changesets) are being done by the release manager (jwe) or by individual
coders?  For example, while fixing a bug I often find a little something
else that could be done in the nearby code.  I can break the changeset into
one which is a pure bug fix and applied to stable, but then I would
presumably need to immediately merge that change down to default, and
finally add the new code.

Also, would it be worthwhile to incorporate more naming standards for the
Mercurial ChangeLog entries?  We currently have '(bug #NNNNN)' which should
allow the release manager to quickly find bugs.  Do we want a facility for
marking documentation changes so that they could be found easily as well?
Perhaps it doesn't matter if doc fixes are always applied to stable.

--Rik