From: Kai Blin
Now, getting back to the patch submission process, you're talking about a patch management system. How would that look like, in your opinion. We
were
discussing a couple of ideas, but in the end figured that most of those
would
slow down the submission speed of patches that are accepted.
Our idea was to have patches be recieved by the subsytem maintainers, and Alexandre would only apply patches he got from those guys. We voted that
one
down.
Now I would be interested in your idea for such a system. I figure that writing an emacs frontend won't be too troublesome if it's reasonably designed, so let's ignore that for now.
A patch management system isn't exactly a new idea. It came up last year, during the same type of discussion we're having now (and it will probably come up next year when we have the same discussion again). See e.g. http://www.winehq.org/pipermail/wine-devel/2005-September/039837.html and note this sentence: "However, it became clear that the requirements were fairly substantial (the tight emacs integration became our first clue :-/), and that project got back burnered."
The users of such a patch management system would fall into 3 categories: Developers/patch submitters, subsystem maintainers and Alexandre. I can take a guess at what subsystem maintainers and Alexandre would want from such a system, but of course I can only really speak as a patch submitter. My primary requirements would be to be able to: - Submit a patch - Specify a subsystem - Keep track of its progress - Resubmit after receiving feedback - Get an overview of patches in the queue - Apply a queued patch to my working copy - Provide feedback to others - Withdraw a patch In addition to the patch submitter requirements, subsystem maintainers would probably like to be able to: - Get an overview of patches relevant to their subsystem - Recommend a patch for inclusion In addition to all of the above, I guess Alexandre would need to be able to: - Get an overview of recommended patches - Commit a patch - Reject a patch - All from within emacs
Moving on to implementation, I see a set of database tables giving a patch the following attributes: - Submitter - Short description - Status (Queued, Waiting for developer, Recommended, Withdrawn, Committed, Rejected) - Subsystem - Patch text (multiple versions, to allow resubmits and still keep a history) - Comments
Some status changes are restricted (e.g. only a subsystem maintainer would be able to recommend a patch). Everyone would be able to submit a patch, which would initially have Queued status. When feedback is provided, the feedback provider (anyone) could change the status to Waiting for developer. If a patch is in "Waiting for developer" status too long (say a month) it could be automatically rejected. When "Waiting", the submitter could provide a new version or respond with a comment, setting the status back to Queued again. Or he could decide to Withdraw the patch. When a patch makes it into the tree it will gain the most holy of all statuses, Committed. I envision manually Rejecting a patch to be a pretty rare case, normally feedback would be provided and the Waiting status would be set. Uncommittable patches would then exit the system via the automatic clean up (in "Waiting" too long) or via a Withdraw.
The heart of the system would be a couple of web pages. However, not everyone likes web pages and the current system with mailing lists does have its strong points too. So, there could be a two-way gateway between the web system and the mailing lists. If a patch is submitted via the web, it could be sent out via wine-patches too. If a patch comes in via wine-patches, it could be added to the database automatically (when that doesn't succeed a notification is sent to the author). Same for comments, they could be fed from the web page to wine-devel.
If there is genuine interest to make this work I could put up a few mock webpages to get a better idea of how it would work.
Gé van Geldorp.
On 9/25/06, Ge van Geldorp ge@gse.nl wrote:
If there is genuine interest to make this work I could put up a few mock webpages to get a better idea of how it would work.
See also my similar post regarding a patch system: http://www.winehq.org/pipermail/wine-devel/2006-September/051052.html
n0dalus.
Hi
Ge van Geldorp wrote:
If there is genuine interest to make this work I could put up a few mock webpages to get a better idea of how it would work.
maybe it is worth looking at patchwork?
------------------- PatchWork is a web-based patch tracking system designed to facilitate the contribution and management of contributions to an open-source project. Patches that have been sent to a mailing list are 'caught' by the system, and appear on a web page. Any comments posted that reference the patch are appended to the patch page too. The project's maintainer can then scan through the list of patches, marking each with a certain state, such as Accepted, Rejected or Under Review. Old patches can be sent to the archive or deleted. --------------------- http://ozlabs.org/~jk/projects/patchwork/
I have never used it myself though, so no idea if it does everything you want.
maybe it is worth looking at patchwork?
PatchWork is a web-based patch tracking system designed to facilitate the contribution and management of contributions to an open-source project. Patches that have been sent to a mailing list are 'caught' by the system, and appear on a web page. Any comments posted that reference the patch are appended to the patch page too. The project's maintainer can then scan through the list of patches, marking each with a certain state, such as Accepted, Rejected or Under Review. Old patches can be sent to the archive or deleted.
http://ozlabs.org/~jk/projects/patchwork/
I have never used it myself though, so no idea if it does everything you want.
Hmm. Now I'm worried; I've long thought this would be a Good Idea (TM), and yet if you look at the 'live' project site (presumably the project this was built for): http://patchwork.ozlabs.org/linuxppc64/
It's pretty clear that it's not getting any use - it's just a mirror of the mailing list.
So clearly the folks on the Linux PPC 64 project didn't feel it was worth investing much energy into.
Also, it might be interesting to compare how the Linux kernel does things; presumably they are a successful model.
My sense was that it was all pretty ad-hoc, and as bad, or much worse, than Wine when it came to patches going into the void. (I'm batting .500 with patches to the kernel; one took me 2 years and a personal plea to Alan Cox to get in, the other is still not in, despite the sub system maintainer agreeing that it was good [after many repeated pleas]).
Has that changed? I presume that this same thread has come up over there - did a consensus ever develop? (Forgive me, but I don't follow LKML, I'm hoping someone braver than I might know).
Cheers,
Jeremy
On 9/25/06, Jeremy White jwhite@winehq.org wrote:
Hmm. Now I'm worried; I've long thought this would be a Good Idea (TM), and yet if you look at the 'live' project site (presumably the project this was built for): http://patchwork.ozlabs.org/linuxppc64/
It's pretty clear that it's not getting any use - it's just a mirror of the mailing list.
I think a good system would still be useful even if no developers or maintainers ended up using it. At the least, it could provide a nice interface for people to find old patches easily. Patchwork seems ok, but has no real features that the mailing list combined with a decent email client doesn't have. A system such as described by Ge and I would allow anyone who was interested to combine, group and watch patches, which gives some incentive to use it.
It doesn't even need to have an emacs interface. Alexandre could continue with his current approach and the system would know whether or not a patch has been accepted by watching the wine-cvs list.
n0dalus.
On Tuesday 26 September 2006 00:16, Jeremy White wrote:
Hmm. Now I'm worried; I've long thought this would be a Good Idea (TM), and yet if you look at the 'live' project site (presumably the project this was built for): http://patchwork.ozlabs.org/linuxppc64/
It's pretty clear that it's not getting any use - it's just a mirror of the mailing list.
Are you sure about that? Scroll down and take a look at some of the "rejected" or "changes requested" ones. First you have a status for each patch. You also have a record of the discussion for each patch. On the other hand the most recent patch listed there is from March so perhaps they have stopped using it.
So clearly the folks on the Linux PPC 64 project didn't feel it was worth investing much energy into.
Wouldn't it be better to ask them than to speculate? (query sent)
It may well be that the PPC64 project was merged into the PPC one, which is seemingly more up to date: http://patchwork.ozlabs.org/
I don't have any real reason to have a say in this (as someone who hasn't successfully made any changes to the wine tree, for which I blame my inability to contribute anything that belongs there rather than any problems with the current system), but I was just thinking that "Patch management system" and "Bugzilla" sound like similar systems. Wine already has a bugzilla. I'd like to at least consider how close it is to meeting the requirements.
- Submit a patch
Can do, as long as it has a bug.
- Specify a subsystem
Also possible, but the subsystem is specified in the bug.
- Keep track of its progress
Yes, but there may actually not be any progress.
- Resubmit after receiving feedback
Yep.
- Get an overview of patches in the queue
Uhh..I guess you could do some kind of search. You'd actually see bugs that have patches, not the patches themselves.
- Apply a queued patch to my working copy
I don't know how this is supposed to work, even forgetting about bugzilla for a moment.
- Provide feedback to others
Yep.
- Withdraw a patch
Uh huh.
Aside from the "working copy" thing, which I'm completely confused about, you could keep track of "patch status" with keywords. Not everyone would know how/want to maintain the keywords manually--you'd need either an army of gnomes to patrol the bugzilla or an automated system to attach the right keywords if you want to make things easy for patch submitters, which it appears you do. A nice checkbox on the attachment form saying something like "I believe this patch is ready to be included in wine in its current form", only not as stupid, could work (the rest has to be done by people who can handle keywords damnit).
The other major problem is that not every patch goes with an existing bug. Presumably, each patch IS meant to improve Wine somehow. I think it could be made more convenient to submit a but report along with the patch. Having the history of events related to the patch/issue in one place (bugzilla) rather than two (bugzilla and the patch manager, or bugzilla and the wine-patches/wine-devel mailing list archives as it is now) could be convenient.
Or it could just add lots of unwanted clutter to bugzilla. I don't know.
In addition to the patch submitter requirements, subsystem maintainers would probably like to be able to:
- Get an overview of patches relevant to their subsystem
Bugzilla queries take care of this.
- Recommend a patch for inclusion
Um..I guess you could use keywords for that too..
In addition to all of the above, I guess Alexandre would need to be able to:
<snip>
- All from within emacs
I don't want to think about this anymore.
-
Ge van Geldorp -
Jeremy White -
n0dalus -
Peter Beutner -
Troy Rollo -
Vincent Povirk