Re: Release Policy

Re: Release Policy

[David S. Miller]

   From: Andrew Morton <akpm@zip.com.au>
   Date: Mon, 26 Nov 2001 17:04:02 -0800
   
   Marcelo, if someone sends you a patch which has not been thoroughly
   reviewed on the appropriate mailing list, I would urge you to
   peremptorily shitcan it.  There is no reason why you alone should
   be responsible for reviewing kernel changes.

Are you suggesting that, for example, I should send every Sparc change
to this list?

I bet a lot of what he is seeing are driver and arch updates.

Such updates really only need to go through his "stupid filter"
when it is coming from the maintainer, but it does add up and
take up time.

Re: Release Policy

[H. Peter Anvin]

Followup to:  <20011126.171301.50592818.davem@redhat.com>
By author:    "David S. Miller" <davem@redhat.com>
In newsgroup: linux.dev.kernel
>
>    From: Andrew Morton <akpm@zip.com.au>
>    Date: Mon, 26 Nov 2001 17:04:02 -0800
>    
>    Marcelo, if someone sends you a patch which has not been thoroughly
>    reviewed on the appropriate mailing list, I would urge you to
>    peremptorily shitcan it.  There is no reason why you alone should
>    be responsible for reviewing kernel changes.
> 
> Are you suggesting that, for example, I should send every Sparc change
> to this list?
> 

appropriate != this.

> I bet a lot of what he is seeing are driver and arch updates.
> 
> Such updates really only need to go through his "stupid filter"
> when it is coming from the maintainer, but it does add up and
> take up time.

Obviously.  If it's for a maintained subsystem:

a) if it's from the subsystem maintainer, sanity-check it.
b) if it's not, dump it or reject with the appropriate notice.

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

Re: Release Policy

[Anuradha Ratnaweera]

On Mon, Nov 26, 2001 at 05:32:18PM -0800, H. Peter Anvin wrote:
> > 
> > Such updates really only need to go through his "stupid filter"
> > when it is coming from the maintainer, but it does add up and
> > take up time.
> 
> Obviously.  If it's for a maintained subsystem:
> 
> a) if it's from the subsystem maintainer, sanity-check it.
> b) if it's not, dump it or reject with the appropriate notice.

A minor issue...

How does Marcelo (or Linus or Alan, say) know that the patch _really_ came from
the subsystem aintainer himself?  I mean anybody would have sent any crap, but
not too bad enough to suspect.  But if it came with a CC to a list, there is a
much smaller chance of this happenning.

Yes.  This would be very rare and the effects would be very short lived.  But
still the _possibility_ exists.

Cheers,

Anuradha

-- 

Debian GNU/Linux (kernel 2.4.13)

When you make your mark in the world, watch out for guys with erasers.
		-- The Wall Street Journal

Re: Release Policy

[H. Peter Anvin]

Anuradha Ratnaweera wrote:

> 
> A minor issue...
> 
> How does Marcelo (or Linus or Alan, say) know that the patch _really_ came from
> the subsystem aintainer himself?  I mean anybody would have sent any crap, but
> not too bad enough to suspect.  But if it came with a CC to a list, there is a
> much smaller chance of this happenning.
> 
> Yes.  This would be very rare and the effects would be very short lived.  But
> still the _possibility_ exists.
> 


How about sending a quick reply "got your patch, applied it?"  The 
maintainer can then say "WHAT PATCH?"

	-hpa

Re: Release Policy

[Anuradha Ratnaweera]

On Mon, Nov 26, 2001 at 11:40:30PM -0800, H. Peter Anvin wrote:
> Anuradha Ratnaweera wrote:
> > 
> > How does Marcelo (or Linus or Alan, say) know that the patch _really_ came from
> > the subsystem aintainer himself?  I mean anybody would have sent any crap, but
> > not too bad enough to suspect.  But if it came with a CC to a list, there is a
> > much smaller chance of this happenning.
> > 
> > Yes.  This would be very rare and the effects would be very short lived.  But
> > still the _possibility_ exists.
> 
> How about sending a quick reply "got your patch, applied it?"  The 
> maintainer can then say "WHAT PATCH?"

Don't we need a consistent indexing system for patches?

May be the subsystem maintainers can upload patches to some place over ssh/ssl
and the maintainer can _download_ them from there. The maintainer will simply
email the patch number and not the whole thing. And patches can be
numbered/named in some consistent manner.  Once the system is in place, we can
even automate md5 checksums etc.

Cheers,

Anuradha

-- 

Debian GNU/Linux (kernel 2.4.13)

There's one consolation about matrimony.  When you look around you can
always see somebody who did worse.
		-- Warren H. Goldsmith

Re: Release Policy

[Harald Arnesen]

Anuradha Ratnaweera <anuradha@gnu.org> writes:

> How does Marcelo (or Linus or Alan, say) know that the patch
> _really_ came from the subsystem aintainer himself?

They could reject patches that came without the maintainers GPG or PGP
signature.
-- 
Hilsen Harald.

Re: Release Policy

[Giacomo Catenazzi]

Harald Arnesen wrote:

> Anuradha Ratnaweera <anuradha@gnu.org> writes:
> 
> 
>>How does Marcelo (or Linus or Alan, say) know that the patch
>>_really_ came from the subsystem aintainer himself?
>>
> 
> They could reject patches that came without the maintainers GPG or PGP
> signature.
> 

Why? If the patch seem to come from a maintainer AND the quality of
patch is ok, why to require some other 'burocratic' steps?

	giacomo

Re: Release Policy

[Keith Owens]

On Tue, 27 Nov 2001 11:08:04 +0100, 
Harald Arnesen <gurre@start.no> wrote:
>Anuradha Ratnaweera <anuradha@gnu.org> writes:
>
>> How does Marcelo (or Linus or Alan, say) know that the patch
>> _really_ came from the subsystem aintainer himself?
>
>They could reject patches that came without the maintainers GPG or PGP
>signature.

Unfortunately the normal GPG/PGP signing changes '-' at start of line
to '- -', even with clear text signing, and destroys the patch.  You
have to use --not-dash-escaped in GPG, where the man page says:

--not-dash-escaped
  This  option changes the behavior of cleartext signatures so that
  they can be used for patch files. You should not send such an armored
  file via email because all spaces and line endings are hashed too.
  You can not use this option for data which has 5 dashes at the
  beginning of a line, patch files don't have this. A special armor
  header line tells GnuPG about this cleartext signature option.

I don't know if PGP accepts text signed by GPG with --not-dash-escaped
nor do I know if there really is a problem with mailing such patches.
But the warning above is nasty enough to rule it out.  The only other
option for signed patches is uuencode or MIME (with or without
compression) and Linus does not like that format.

Re: Release Policy

[Mike Fedyk]

On Tue, Nov 27, 2001 at 09:29:36PM +1100, Keith Owens wrote:
> On Tue, 27 Nov 2001 11:08:04 +0100, 
> Harald Arnesen <gurre@start.no> wrote:
> >Anuradha Ratnaweera <anuradha@gnu.org> writes:
> >
> >> How does Marcelo (or Linus or Alan, say) know that the patch
> >> _really_ came from the subsystem aintainer himself?
> >
> >They could reject patches that came without the maintainers GPG or PGP
> >signature.
> 
> Unfortunately the normal GPG/PGP signing changes '-' at start of line
> to '- -', even with clear text signing, and destroys the patch.  You
> have to use --not-dash-escaped in GPG, where the man page says:
> 
> --not-dash-escaped
>   This  option changes the behavior of cleartext signatures so that
>   they can be used for patch files. You should not send such an armored
>   file via email because all spaces and line endings are hashed too.
>   You can not use this option for data which has 5 dashes at the
>   beginning of a line, patch files don't have this. A special armor
>   header line tells GnuPG about this cleartext signature option.
> 

Interesting.

> I don't know if PGP accepts text signed by GPG with --not-dash-escaped
> nor do I know if there really is a problem with mailing such patches.
> But the warning above is nasty enough to rule it out.  The only other
> option for signed patches is uuencode or MIME (with or without
> compression) and Linus does not like that format.
> 

But we're not dealing with Linus with 2.4 anymore.  Maybe Marcello will
accept signed compressed patches.  With a few modifications, most MUAs that
support external processing could be setup to verify the sig, uncompress,
and view in the message area.

MF

Re: Release Policy

[Jes Sorensen]

"David S. Miller" <davem@redhat.com> writes:
> Are you suggesting that, for example, I should send every Sparc change
> to this list?
> 
> I bet a lot of what he is seeing are driver and arch updates.
> 
> Such updates really only need to go through his "stupid filter"
> when it is coming from the maintainer, but it does add up and
> take up time.

A real problem is the large number of driver patches that come in
from non maintainers.

Jes