On Tue, 2002-01-29 at 02:10, Stuart Young wrote:
> At 10:00 PM 28/01/02 -0800, Linus Torvalds wrote:
> >I think it helps a lot to have people pick up patches that nobody else
> >wants to maintain, and to gather them up. Andrea does that to some degree.
> >But it is _much_ better if you have somebody who is a point-man for
> >specific areas.
> >
> >The problem with an overall guy is that there can't be too many of them.
> >The very thing you are _complaining_ about is in fact that there are a
> >number of over-all guys without clear focus, which only leads to confusion
> >about who handles what.
> >
> >Clarity is good.
>
> Perhaps what we need is a patch maintenance system? Now I'm not talking
> CVS, I'm talking about something that is, in reality, pretty simple.
> Something that does the following:
>
> 1. People can submit patches, which are given a unique patch ID.
> 2. Notifications of patches are passed on to (from a selection or
> automatic detection):
> a. A module maintainer
> b. A section maintainer
> c. A tree maintainer
> d. Linus Torvalds
> 3. The patches can be reviewed, and immediately:
> a. Dropped with a canned reject message
> b. Dropped with a custom reject message
> c. Dropped but archived for later review
> d. Suspended/Skipped for later review
> e. Redelegated up/down to a maintainer
> f. Accepted, pending testing
> 4. If someone wants to know why their patch is not being accepted:
> a. They can easily look up the current status
> b. There is a common reference place
> c. If their patch is rejected, they can ask for more detail
Kinda like bugzilla, but for patches ? Am I off the deep end here ?
Just a thought.
>
> Yes it's a tiny patch tracking system. The idea is that if we can make the
> thing simple to use, simple to understand, and simple to maintain, people
> will actually use it. Submitting patches by mail in freeform, while
> reasonably simple, leads to overall complication, and may take longer to
> sort through.
>
> It doesn't have to be that involved. A shell script (or perl) could happily
> do the submission job (which could all still be done by mail, however in a
> more formatted approach). It'd also be simple to do some sort of web
> interface if anyone was actually inclined.
>
> Later, maybe, we can have it track possible conflicts (between waiting
> patches) and flag them as such so the maintainer is aware of the fact.
>
> If we can automate some simple, key parts of the kernel maintenance, then
> this could help immensely, and let everyone get on with the job than the
> hassle. Maybe we want to re-invent this wheel, maybe we don't.
>
> PS: Remember this is only a suggestion. I'm not infallible (is anyone?),
> all I can do is give the big guy ideas (even bad ones), so he can make
> better decisions. *grin*
>
>
> Stuart Young - sgy@amc.com.au
> (aka Cefiar) - cefiar1@optushome.com.au
>
> [All opinions expressed in the above message are my]
> [own and not necessarily the views of my employer..]
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jan 31 2002 - 21:00:58 EST