On Fri, Feb 03, 2012 at 05:35:06PM +0100, Jaap Keuter wrote:
> On backporting, I did a lot of that stuff for 1.4.11. From my
> experience, when the patch is clean the backport is easy.
> Trouble is is that the patch comes from another trunk, which may have
> other changes (like ENCodings) which make patches incompatible.
> A little (or a lot of) tweaking of the patch makes them apply, but this
> cannot be automated. So thinking about automation is a step too far.
> Another way of tagging/marking revisions would 1. require a script to
> extract the tags/marks, and 2. commit messages cannot be corrected once
> a mistake is made.
The idea (as I see it) would work as follows:
- We (well Gerald :) want to make a new release 1.6.n+1
- Obtain the svn revision of 1.6.n
- Go through the changelog of all patches to trunk since that
commit up to HEAD.
- Determine all commits that have the backport magic in the commit message
- Extract all these patches into individual files with their revision numbers
in the name. Create a corresponding file with the original commit message
(maybe with the backport magic removed).
Up until this point, everything can be automated.
For every patchfile:
- Apply the patch and make fixes if necessary.
- Commit using the commit file.
This would reduce the overhead of the backporting process for Gerald.
> As flawed as it is, the Wiki is the best we got so far. Other tools (who
> uses Trac, or that other one I can't remember right now) may provide
> this.
I see this differently, as stated above ;-)
Ciao
Jörg
Teaser: I have a writeup of the Dinnertalks and FOSDEM Beer Event on my
laptop, but maybe there will be more during today.
--
Joerg Mayer <jmayer@xxxxxxxxx>
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.