Re: A modest proposal -- We need a patch penguin

Re: A modest proposal -- We need a patch penguin

[John Weber]

I would be happy to serve as patch penguin, as I plan on collecting all
patches anyway in my new duties as maintainer of www.linuxhq.com.

I am currently writing code to scan the usual places for linux patches
and automatically add them to our databases.  This would be really
simplified by having patches sent to us.  And, since we already have a
functioning site, we have the hardware/network capacity to serve as
a limitless queue of waiting patches for Linus.  I would love nothing
more than to update the site with information as to the status of these
patches.

( john.weber@linux.org )

Re: A modest proposal -- We need a patch penguin

[Rob Landley]

On Monday 28 January 2002 08:53 pm, John Weber wrote:
> I would be happy to serve as patch penguin, as I plan on collecting all
> patches anyway in my new duties as maintainer of www.linuxhq.com.
>
> I am currently writing code to scan the usual places for linux patches
> and automatically add them to our databases.  This would be really
> simplified by having patches sent to us.  And, since we already have a
> functioning site, we have the hardware/network capacity to serve as
> a limitless queue of waiting patches for Linus.  I would love nothing
> more than to update the site with information as to the status of these
> patches.
>
> ( john.weber@linux.org )

Philosophical question: Would you have a major philosophical objection to 
acting as Dave Jones's secretary and webmaster?  (He is the de facto current 
patch penguin.  I'm just asking for the position to be recognized.  We need 
that before we can really move forward with anything else.  If you were to 
queue patches for Linus and then be ignored by Linus, nothing would have been 
accomplished, and if somebody ELSE then takes your work and integrates it, it 
would be yet more pressure to fork the tree, pressure which I'm trying to 
REDUCE here...)

Remember minix?  Way way way back?  Andrew Tanenbaum had a little kernel, ran 
on intel hardware, came with complete source code.  And he did not accept 
patches, due to his minix book contract and the resulting licensing issues.  
Collaborative development on Linux STARTED in the minix newsgroup, largely by 
recruiting people who were frustrated at trying to get their patches into 
minix.

Remember GNU?  Stalled in the late 80's?  For legal reasons, Richard Stallman 
wanted people to physically sign over their copyrights (on paper he could put 
in his file cabinet) to any code they submitted to the GNU project.  This 
caused way too much friction (and Richard wasn't exactly a coalition building 
statesman either), and eventually people got fed up with the project and took 
their code elsewhere.

These are the kind of pressures that, if they build up high enough, cause 
projects to fork.  It's all different trees with different patches in them, 
and if the patch pressure builds up too high forking is inevitable.  
(Re-integration of forks is also quite possible, they can be short lived.  
But that's the same integration issue, just deferred a bit.)

I'm not saying Linux is in immediate danger of forking, I'm just saying that 
code integration can be a serious limiting factor, and is a potentially 
seperable problem from being a code architect.  I think an explicit full-time 
integration maintainer could reduce/buffer the patch pressure, and that this 
could be good for the project.

Rob

Re: A modest proposal -- We need a patch penguin

[Rik van Riel]

On Mon, 28 Jan 2002, John Weber wrote:

> I would be happy to serve as patch penguin, as I plan on collecting all
> patches anyway in my new duties as maintainer of www.linuxhq.com.

> we have the hardware/network capacity to serve as a limitless queue of
> waiting patches for Linus.

Please don't just accumulate stuff.

It would be useful to know which of the patches still
applies against the most recent 2.2, 2.4 or 2.5 kernel,
so each patch gets some status fields:

1) applies against 2.2
2) applies against 2.4
3) applies against 2.5

4) was applied to 2.2
5) was applied to 2.4
6) was applied to 2.5

7) bitrotted patch, no longer applies and wasn't
   applied ... moved to 'old' queue

kind regards,

Rik
-- 
"Linux holds advantages over the single-vendor commercial OS"
    -- Microsoft's "Competing with Linux" document

http://www.surriel.com/		http://distro.conectiva.com/

Re: A modest proposal -- We need a patch penguin

[Denis Vlasenko]

On 29 January 2002 09:04, Rik van Riel wrote:
> On Mon, 28 Jan 2002, John Weber wrote:
> > I would be happy to serve as patch penguin, as I plan on collecting all
> > patches anyway in my new duties as maintainer of www.linuxhq.com.
> >
> > we have the hardware/network capacity to serve as a limitless queue of
> > waiting patches for Linus.
>
> Please don't just accumulate stuff.

Right. Accepting any patch is wrong policy. You'll be swamped.
Patch must be marked "applies to 2.N.M", patch tracking system must check 
that automagically.

Also each patch(set) can be commented by general public and by maintainers.
If there is _no_ comment from any of _maintainers_ (i.e. it is not reviewed 
or found too ugly to worth commenting) it is automatically dropped from the 
system after some time.  This will force patch authors to care about code 
quality.

If patch is too old (several releases behind) system can mail author(s):
"Warning. Your patchset #3476346 needs rediffing. It will be dropped 
otherwise"

These "small" details determine whether system is useful or just turns into 
huge pile of patches of questionable value.
--
vda

Re: A modest proposal -- We need a patch penguin

[Horst von Brand]

John Weber <weber@nyc.rr.com> said:
> I would be happy to serve as patch penguin, as I plan on collecting all
> patches anyway in my new duties as maintainer of www.linuxhq.com.

Complete with "Patches only against 2.4.17 through 2.4.19", "Doesn't
compile con ARM with CONFIG_FOO", "Works fine on AXP"?

Plus search capability: Which files does it touch? What functions/variables
change/appear/dissapear? Etc?

Looks like a _HUGE_ ammount of work...

> I am currently writing code to scan the usual places for linux patches
> and automatically add them to our databases.  This would be really
> simplified by having patches sent to us.  And, since we already have a
> functioning site, we have the hardware/network capacity to serve as
> a limitless queue of waiting patches for Linus.  I would love nothing
> more than to update the site with information as to the status of these
> patches.

Again, as was discussed here: PLEASE do save the complete message. Oh, BTW
the following thread might have caveats, fixes, and important comments.
-- 
Horst von Brand			     http://counter.li.org # 22616

Re: A modest proposal -- We need a patch penguin

[Olaf Dietsche]

Hi John,

John Weber <weber@nyc.rr.com> writes:

> I am currently writing code to scan the usual places for linux patches
> and automatically add them to our databases.  This would be really
> simplified by having patches sent to us.  And, since we already have a

How about extracting patches from lkml with procmail?

---cut here-->8---
:0 :
* ^sender: linux-kernel-owner@vger.kernel.org
* ^subject:.*patch
{
	:0 Bc:
	* ^--- .*/
	* ^+++ .*/
	linux-kernel-patches
}
---8<--cut here---

This recipe has its limits, but it's a start.

Regards, Olaf.

Re: A modest proposal -- We need a patch penguin

[James Stevenson]

> ---cut here-->8---
> :0 :
> * ^sender: linux-kernel-owner@vger.kernel.org
> * ^subject:.*patch
> {
> :0 Bc:
> * ^--- .*/
> * ^+++ .*/
> linux-kernel-patches
> }
> ---8<--cut here---
>
> This recipe has its limits, but it's a start.

well since most patches have a subject line
starting with [PATCH] its not hard to pull them out
with procmail.

Re: A modest proposal -- We need a patch tracking system.

[Kervin Pierre]

Public patch tracking system/queue, maybe something derived from bugzilla.

(i) patches are sent to the maintainer and entered into the system.

(ii) reviewed patches are update appropriately, eg. ( "reject - untidy, 
please fix", "accept - expected version 2.4.18pre19" etc. )

(iii) patch versions, updates can be kept, as in mozilla's bugzilla 
site.  And comments on that patch can also be kept right along side the 
code.

Regardless of wether the current system is changed or not, the linux 
kernel would benefit from a central, searchable, public repository of 
patches.

The code is available, bugzilla has all this functionality today.

So here's hoping for a patchzilla.kernel.org :)

--Kervin



Denis Vlasenko wrote:
> On 29 January 2002 09:04, Rik van Riel wrote:
> 
>>On Mon, 28 Jan 2002, John Weber wrote:
>>
>>>I would be happy to serve as patch penguin, as I plan on collecting all
>>>patches anyway in my new duties as maintainer of www.linuxhq.com.
>>>
>>>we have the hardware/network capacity to serve as a limitless queue of
>>>waiting patches for Linus.
>>>
>>Please don't just accumulate stuff.
>>
> 
> Right. Accepting any patch is wrong policy. You'll be swamped.
> Patch must be marked "applies to 2.N.M", patch tracking system must check 
> that automagically.
> 
> Also each patch(set) can be commented by general public and by maintainers.
> If there is _no_ comment from any of _maintainers_ (i.e. it is not reviewed 
> or found too ugly to worth commenting) it is automatically dropped from the 
> system after some time.  This will force patch authors to care about code 
> quality.
> 
> If patch is too old (several releases behind) system can mail author(s):
> "Warning. Your patchset #3476346 needs rediffing. It will be dropped 
> otherwise"
> 
> These "small" details determine whether system is useful or just turns into 
> huge pile of patches of questionable value.
> --
> vda
> -
> 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/
> 
> 



-- 
http://linuxquestions.org/ - Ask linux questions, give linux help.

Re: A modest proposal -- We need a patch penguin

[Stuart Young]

At 07:33 PM 29/01/02 +0100, Olaf Dietsche wrote:

>How about extracting patches from lkml with procmail?
>
>---cut here-->8---
>:0 :
>* ^sender: linux-kernel-owner@vger.kernel.org
>* ^subject:.*patch
>{
>         :0 Bc:
>         * ^--- .*/
>         * ^+++ .*/
>         linux-kernel-patches
>}
>---8<--cut here---
>
>This recipe has its limits, but it's a start.

Actually I was sort of thinking that maybe part of the problem with our 
current system is the noise-to-signal ratio of lkml itself.

Perhaps it's time we set up a specific lkml-patch mailing list, and leave 
lkml for discussions about the problems. Have a script that posts general 
details about patches on lkml when there is a post to lkml-patch if you 
like, so people know and can go and take a look if they want. If you get 
complex, it can vet the patches to see if they apply, before pushing them 
to the list. It also goes well with some sort of patch tracking system (who 
says we can't use a mailing list as a distribution mechanism), if that gets 
the go ahead, while not requiring it.

Another possibility (or could even be combined) is that perhaps we need to 
start separating the mailing list at the code tree level.

eg: The "development" tree (lkml-dev which would currently contain 2.5.x) 
from the "stable" tree (lkml-stable which would currently contain 2.4.x) 
from the "older" trees (lkml-old which would currently contain 
2.2.x/2.0.x), at the mailing list level.

That way, people can concentrate on a specific tree (eg: Linus could 
concentrate on 2.5.x), without getting inundated with all the other stuff. 
This progresses easily when the next "stable" branch hits, so that the 
"dev" list can keep talking about what they plan to do while waiting for 
the stable to fork into the new development tree, and the previous stable 
joins the ranks of the "old" kernels, where it might possibly still get the 
occasional fix.

By reducing the noise (and hey, there is a reason people black-list certain 
subjects on lkml apart from personal/flame war issues), people can 
concentrate on the facts. The less noise (the less traffic?) the more 
likely every message will be read, patches will be checked, etc. Especially 
when you have other "duties" apart from maintaining kernel code, it's not 
always easy keeping up with lkml.


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..]

Re: A modest proposal -- We need a patch penguin

[Jeff Garzik]

On Wed, Jan 30, 2002 at 12:00:11PM +1100, Stuart Young wrote:
> Perhaps it's time we set up a specific lkml-patch mailing list, and leave 

I like the suggestion (most recently, of Daniel?  pardon if I
miscredit) of having patches-2.[45]@vger.kernel.org type addresses,
which would archive patches, and have a high noise-to-signal ratio.
Maybe even filter out all non-patches.

The big issue I cannot decide upon is whether standard e-mails should be
	To: torvalds@
	CC: patches-2.4@
or just
	To: patches-2.4@

(I'm guessing Linus would prefer the first, but who knows)

Also, something noone has mentioned is out-of-band patches.  Security fixes and other
patches which for various reasons go straight to Linus.

	Jeff

Re: A modest proposal -- We need a patch penguin

[Stuart Young]

At 08:18 PM 29/01/02 -0500, Jeff Garzik wrote:
>On Wed, Jan 30, 2002 at 12:00:11PM +1100, Stuart Young wrote:
> > Perhaps it's time we set up a specific lkml-patch mailing list, and leave
>
>I like the suggestion (most recently, of Daniel?  pardon if I
>miscredit) of having patches-2.[45]@vger.kernel.org type addresses,
>which would archive patches, and have a high noise-to-signal ratio.
>Maybe even filter out all non-patches.
>
>The big issue I cannot decide upon is whether standard e-mails should be
>         To: torvalds@
>         CC: patches-2.4@
>or just
>         To: patches-2.4@
>
>(I'm guessing Linus would prefer the first, but who knows)

Perhaps it'd be easier for patches-2.4 to actually send a copy to whoever 
is the relevant maintainer of a "section" (which could be worked out from 
the path in the patch, as long as it's made relevant to linux/) as well as 
the 2.4 maintainer? There is a lot of things that can be done here.

>Also, something noone has mentioned is out-of-band patches.  Security 
>fixes and other patches which for various reasons go straight to Linus.

Perhaps that is a good use for my lkml-patches idea, which gives those who 
have no avenue a place to post patches so they get picked up.

Something that does need to be done is that various directories under the 
kernel tree need to have someone "who receives patches" for that part, and 
who forwards them onto the kernel maintainer (eg: Linus, Marcello, etc) for 
further review/inclusion/rejection. This way, anything that doesn't fall 
under a particular maintainer gets sectioned off to someone, so it does get 
review, and hopefully a reply.


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..]

Re: A modest proposal -- We need a patch penguin

[Daniel Phillips]

On January 30, 2002 02:18 am, Jeff Garzik wrote:
> On Wed, Jan 30, 2002 at 12:00:11PM +1100, Stuart Young wrote:
> > Perhaps it's time we set up a specific lkml-patch mailing list, and leave 
> 
> I like the suggestion (most recently, of Daniel?  pardon if I
> miscredit) of having patches-2.[45]@vger.kernel.org type addresses,
> which would archive patches, and have a high noise-to-signal ratio.
> Maybe even filter out all non-patches.
> 
> The big issue I cannot decide upon is whether standard e-mails should be
> 	To: torvalds@
> 	CC: patches-2.4@
> or just
> 	To: patches-2.4@
> 
> (I'm guessing Linus would prefer the first, but who knows)

I'd say: cc Linus specifically if you think it's something he'd find 
personally interesting.  Leave out the cc if it's a minor bugfix or 
maintainance.

Oh, as somebody suggested in this thread, there is a difference in priority 
between bugfixes and other kinds of patches.  Should buxfixes go to 
patches-xxx@kernel.org with [BUGFIX] in the subject, or would 
bugs-xxx@kernel.org be a better idea?

> Also, something noone has mentioned is out-of-band patches.  Security fixes
> and other patches which for various reasons go straight to Linus.

Out-of-band patches are not going to stop.  The difference is, they will be 
duly noticed after the fact because they should be relatively few in 
comparison to in-band patches.

Another kind of out-of-band patch is where Linus takes the basic idea from 
somebody's patch and completely rewrites it, or does some hacking on his own, 
which he's been known to do.  Somehow I wouldn't expect he'd bother emailing 
the results to himself.

-- 
Daniel

Re: A modest proposal -- We need a patch tracking system.

[H. Peter Anvin]

Followup to:  <3C573428.3000404@fit.edu>
By author:    Kervin Pierre <kpierre@fit.edu>
In newsgroup: linux.dev.kernel
>
> Public patch tracking system/queue, maybe something derived from bugzilla.
> 
> (i) patches are sent to the maintainer and entered into the system.
> 
> (ii) reviewed patches are update appropriately, eg. ( "reject - untidy, 
> please fix", "accept - expected version 2.4.18pre19" etc. )
> 
> (iii) patch versions, updates can be kept, as in mozilla's bugzilla 
> site.  And comments on that patch can also be kept right along side the 
> code.
> 
> Regardless of wether the current system is changed or not, the linux 
> kernel would benefit from a central, searchable, public repository of 
> patches.
> 
> The code is available, bugzilla has all this functionality today.
> 
> So here's hoping for a patchzilla.kernel.org :)
> 

If Linus et al signs on to the idea, I'm sure we can build it...

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>