Re: recommendations wanted for new patch management system in xorg-x11
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Branden Robinson wrote:
| A couple of people, including Fabio, were confused by my intentions
| regarding the "apply-patches" and "revert-patches" targets in the new rules
| file[3].
|
| I don't intend for those targets to be run as part of the normal package
| build process -- they're intended for development convenience. Of course I
| should have documented this in a comment, but I was in experimental hack
| mode. :)
thanks for your time explaining it :)
| Before I start, however, let me state a few premises:
|
| * A coherent patch management system is a good idea, and far preferable to
| a monolithic .diff.gz with no discrete separation of patches available.
|
| * The presence (or usage) of a patch management system in the xorg-x11
| source package doesn't mean that we shouldn't be submitting patches
| upstream to freedesktop.org Bugzilla[4] as appropriate.
|
| * A patch management system can be a good thing even if you're not applying
| a lot of patches. You can realize benefits with it as soon as you apply
| more than one patch to the upsteram source.
fully agree here.
|
| Therefore, please don't interpret this discussion as a desire to maintain a
| fork of X.Org X11 for Debian that is dramatically different from the
| original. I want it to be *easy* to get patches to upstream.
|
I think we should start submitting patches as soon as we get them and we know
they are working, as part of the normal development process for our packages.
IÍRC daniel did submit all of the Ubuntu patches already.
| 3) The patch development process using the patch management system should
| be straightforward enough to be easily applicable to X Strike Force
| requirements and documentable within that context.
|
| The process one would have to use with the current apply-patches and
| revert-patches targets is workable, but somewhat cumbersome, and
| involves more steps than I'd like. Basically, once you've identified a
| patch you want to apply:
|
| 1) You run revert-patches to restore your checkout to a "pristine"
| state;
| 2) You manually apply any patches that would be prerequisites for the
| one you're about to apply;
| 3) You make backups of the files you're about to change;
| 4) You make your patch and store the diff in debian/patches;
| 5) You manually apply any patches that would be affected by your changes
| and repair fuzz/offsets/etc. by basically repeating steps 3) and 4),
| updating debian/patches/* files as needed.
| 6) You re-revert all patches you applied to get the checkout back to a
| "pristine" state again;
| 7) You run apply-patches and confirm that you didn't screw anything up
| in steps 2) to 6);
| 8) If you screwed nothing up, you SVN add the new patch and SVN commit
| the whole group of changes (xc/ changes, debian/patches/, and
| debian/changelog) together.
|
| There are several opportunities in the above for human error to creep
| in.
This is the only part of the entire proposal that scares me.
We should definetely provide a script or a make target to edit patches and
automate some of the tests, like applying all the patches on top of the edited
one, see if there are rejs/offsets/fuzz and offer to the option to fix it, without
having to unpack/unpatch/repatch/rediff and so on.
Let's see if an example can express my idea better.
Scenario:
debian/patches/
001_stolen_from_foo
003_fix_bar
004_fix_whatver
I am in the need to create a 002_bazbar patch.
xorg-x11-edit-patch 002_bazbar
[unpatch/patch game here]
manually edit the patch...
xorg-x11-save-patch
[create the diff]
now.. almost all the patch management systems will stop here.
This is clearly not enough.
What we can do is start applying 003_fix_bar and so on.. and check
if they still apply clean or not.
Let say for example that 003_fix_bar doesn't apply clean anymore
due to some offset/fuzz/rejects introduced by 002_.
Instead of failing miserably here, we could really just tell the
maintainer: "Hey dude.. 003 failed! want to fix it now (Y/n)?"
A yes would give you the opportunity to do your investigation
and execute again:
xorg-x11-save-patch
[create/update the diff]
until the end of the patches. At the end of this process all the patches
have been updated and applied, bringing the code at the latest patch level
and all the patches clean and dandy.
A no will clearly leave you with what
you have asked for.
Since we are somehow writing this from scratch, it would be nice to
be able to keep comments inside the patches without having to edit
the patch in some manual way. Perhaps we can have some kind of
@COMMENTSECTION@ that our patch tool can understand and preserve
across rediffs.
As well we can implement more metadata like: PUSHEDUPSTREAM and in what date.
IF we rediff our patch we can detect the date change and warn the maintainer
that the patch has been sent upstream and we might need to push the new one.
In the previous example 003_fix_bar might now depends on 002. So we need
to push 002 and update 003.
|
| Would someone like to help?
|
| Please make a case for your favorite patch management system; when doing
| so, please explicitly evaluate it against the criteria above, instead of
| just saying "Have you heard of $FOO? I think that does everything you
| want." Explain how.
|
| I want to provoke discussion -- while I'm wearing my XSF leader hat at the
| moment, I'd like to pick a technology that other people will enjoy using
| (or at least be able tolerate). I'm pretty sure my ad-hoc
| apply-patches/revert-patches targets don't qualify.
Now the point is.. should we invest sometime creating our own patch management
system or should we use one that is already outthere?
In my experience dbs is the one that works best, but it doesn't fulfill 1).
The others tools i have been using across the time always showed different
flaws in one way or another.
I would say that we need to test your system. I am never against experemintation
and see how it works, how many times we will have to unroll changes due to
human error and reevaluate the overall in sometime from now. all of us need to get use
to it, so i wouldn't consider the first month as relevant to take a decision.
Fabio
- --
Self-Service law:
The last available dish of the food you have decided to eat, will be
inevitably taken from the person in front of you.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCQnQUhCzbekR3nhgRArMwAJ4qQDvcgvSI3voO1ZjqsBkf4v9XxgCggXmm
wMWE3nHaSPGlF+IKrg5yILA=
=Emxh
-----END PGP SIGNATURE-----
Reply to: