Re: Release Policy

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 [was: Linux 2.4.16 ]

[Andrew Morton]

Marcelo Tosatti wrote:
> 
> (people are flooding me with patches, btw, please stop for a while).
> 

That's funny.  The rest of us haven't seen these patches.

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.

-

Release Policy [was: Linux 2.4.16 ]

[David Relson]

Marcelo,

Thank you for stepping forward to be the maintainer of the 2.4 tree.  This 
is a very valuable and important service for use Linux users.

Also, thank you for releasing 2.4.16.  I have it building on my linux box 
as I write this message :-)

Over the last few days, there have been lots of messages regarding "Kernel 
Release" and "-preX vs. -rcX".  You, as the official maintainer of kernel 
2.4 are the person who actually creates the release policy and makes it happen.

Would you care to share your thoughts on this matter?

David

At 07:30 AM 11/26/01, Marcelo Tosatti wrote:

>Hi,
>
>Due to the corruption problems on 2.4.15, I'm releasing 2.4.16.

Re: Release Policy [was: Linux 2.4.16 ]

[Marcelo Tosatti]

On Mon, 26 Nov 2001, David Relson wrote:

> Marcelo,
> 
> Thank you for stepping forward to be the maintainer of the 2.4 tree.  This 
> is a very valuable and important service for use Linux users.
> 
> Also, thank you for releasing 2.4.16.  I have it building on my linux box 
> as I write this message :-)
> 
> Over the last few days, there have been lots of messages regarding "Kernel 
> Release" and "-preX vs. -rcX".  You, as the official maintainer of kernel 
> 2.4 are the person who actually creates the release policy and makes it happen.
> 
> Would you care to share your thoughts on this matter?

Sorry for not being able to discuss this issues... Its just that I'm too
busy doing the maintenance and other stuff at Conectiva at the same time
(people are flooding me with patches, btw, please stop for a while).

Daniel Quinlan suggested me to release a "pre-final" release before the
real final one (which would catch most "stupid" bugs), and I think thats a
nice way of solving the problem.

I'll _probably_ do that --- not sure yet, though. 

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

[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