On 31-01-13 19:04, John Ralls wrote:
On Jan 31, 2013, at 9:06 AM, Geert Janssens <[email protected]> wrote:
On 31-01-13 17:15, John Ralls wrote:
On Jan 31, 2013, at 7:04 AM, Derek Atkins <[email protected]> wrote:
Geert Janssens <[email protected]> writes:
[snip]
Daggy fixing is probably not the only useful scheme though. I could
also imagine something like this to work:
- all bugfixes and only bugfixes happen on the 2.4 branch
- the 2.4 branch regularly gets merged into the development branch, so
all bugfixes also will end up in future releases
This concept is no longer back-porting, but
forward-porting. Advantage: all bugfixes eventually end up in the
active trees and git branches show the history, no need for BP->AUDIT
Note that neither daggy fixing nor forward porting are possible as
long as we're tied to svn. So this discussion is on future process,
not practical next steps yet.
Techncally we could do the "all bugfixes go into release; frequently
merge release back into trunk" method. The downside is that larger
"fixes" dont get tested as much before going into the release.
I think that you guys have a misunderstanding about how merging works.
Perhaps I do. That's why I'm discussing this topic here :)
Try merging 2.4 back into trunk.
When I did just now, 4 files merged successfully, the rest have conflicts. One
might be able to do better by playing with the merge options. I'm not going to
spend the time.
I believe this is in large part because the common ancestor between 2.4 and
trunk is already too far down history. I explicitly said regularly merging into
the development branch.
No, you're looking at it backwards. The conflicts arise from changes to trunk,
not stable.
We don't develop *anything* in the stable branch -- at least, we're not
supposed to. Trunk changes, 2.4 mostly doesn't, and all of the changes in 2.4
are supposed to have been made in trunk first, so if trunk hasn't diverged much
from stable, then a merge from stable into trunk should be a no-op.
That's the main premise I was challenging. Suppose we *do* develop on
2.4, but bugfixes only or if you will more generally, only that stuff we
actually want to end up in the next 2.4.x release (like translations as
well for example). It would obviously be important to clearly define
what's welcome on a stable branch and what isn't.
The problem of course is that trunk *does* diverge. That's the whole point of
having a stable branch. As trunk diverges, the code required to implement a bug
fix becomes different between the two branches. The merge conflicts arise from
those differences.
Yes, that's clear. And it would be the same if bugfixes (those we *want*
in the next release) are done on the stable branch and then merged
forward into development. I'm *not* focussing on the merge conflicts.
They will be there in both cases. I'm focussing on traceability of the
commits that are supposed to go on both branches. Since generally
speaking all bugfixes we want on the stable branch should also be in
development but not the other way around, my proposal makes it easier to
trace: just look at the last merge from stable to development. Any more
recent commit on stable is not merged into development yet.
Now we *could* reduce that divergence by adopting a scheduled release process like Gnome
has done. Then trunk would never be more than 6 months different from the current stable
branch. We could go even further and adopt "continuous integration", though
that's always seemed to me to be an anti-user approach (Gnome's users have been noisily
unhappy), and both seen risky given our poor test coverage.
Agreed these are not really good options with our current code base and
development team size.
Our current process (using the BP and AUDIT markers) has the same weaknesses
IMO. There is no clear indication in the commit history of which commits were
backported. We have BP/AUDIT as a visual reminder that backports should happen,
but no easy way to check in retrospect if they actually happened.
Go reread the Wiki article on BP/AUDIT [1]:
"Developers should request changesets get audited and approved before they are
pulled into the release branch."
The intent was that backports should get a code review from another developer
before being committed to stable. Since we don't actually do that, perhaps the
automated email is superfluous anyway.
Indeed, I implicitly worked from the actual current situation, not how
it was originally intended and written in the wiki. I think an automated
mail in general is still useful, but I'm questioning the BP/AUDIT extra
addon.
We could instead require a bug for backports and include the bug number in
both commits, and both commits could be referenced in the bug before closing
it. The commit note in stable could also note the source commit from trunk.
When one finds a bug on one's own it's pretty easy to write a bug to satisfy
that requirement, and ISTR someone mentioning a git-Bugzilla utility of some
sort in the last couple of weeks.
That could probably work as well. I suppose the bug should only be
marked as fixed after is available on both branches, regardless of the
mechanism we'd use to get them there. But still: can we enforce the bug
to remain open until that is the case ? What if someone closes a bug too
soon ? How will we know that commit still has to be copied one way or
another to the other branch ? Again I think having it visually in the
commit history looks stronger to me.
Just to be honest and complete, I will add myself what I perceive as a
weakness in my model:
How do we know upfront which fixes we want on the release and which ones
we we don't ? Sometimes it's only clear *after* the bug has been fixed
how complex the solution has become and whether it could still be
considered for backporting.
For my model, I'd rely on separate working branches and git's
flexibility of rebasing branches to deal with this:
- for a bugfix, create a working branch from stable and fix the bug on
that branch.
- If it turns out to be more complicated than originally intended,
either you decide it's not for stable (potentially after peer review and
discussion) or it still is.
- In the first case, rebase the branch to development (potentially
dealing with merge conflicts due to diverged trees - a clear drawback).
- In the latter case, merge the working branch in stable, to be merged
back into development later on.
This situation should be infrequent in my opinion though. For most bugs
a fairly good estimate of the impact can be made before writing the
first line of code and based on that the appropriate base branch can
already be chosen.
Geert
_______________________________________________
gnucash-devel mailing list
[email protected]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
