[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: kernel-patch-amd64



On Wed, Jun 30, 2004 at 07:47:10AM +0100, viro@parcelfarce.linux.theplanet.co.uk wrote:
> On Wed, Jun 30, 2004 at 08:30:05AM +0200, Sven Luther wrote:
> > > Bad idea.  Split the patch and get as much as possible merged upstream.
> > > Note that large parts are simply "Lindent that file" and they certainly
> > > should not be mixed with the rest.
> > 
> > And ? Is that incompatible with making a kernel-patch-amd64 package and
> > building a kernel from it ?
> > 
> > What i really dislike about this politic of submitting stuff upstream,
> > is that we are going all stupid and rigid about it, and totally loosing
> > the interest of our users from our minds.
> 
> WTF does it have to do with interest of our users?

Well, i don't know about the amd64 situation, but basically it goes like
that :

  This feature/port/whatever is not in the nice situation we want it
  (not splitted patch, or not everything is upstream yet, or whatever),
  so let's not package it yet, and wait that someone eventually cleans
  it up. In the meantime, the users are on their own.

> > So what if it is a monolitic patch ?
> 
> Simple fact that it makes maintaining it (as opposed to "Me Og. Og wget.
> Og package.  Og upload.  Og no read.  Og maintainer.") harder.  And no,
> I'm not implying that anyone involved in this thread is on that level.

Sure, but what trouble it is, if there is already a existing monolitic
patch, to make the result available to the general user, _while_ the
cleanup is happening behing the scene, over not making it available
while cleaning it up.

And i really don't see what the best maintenance is if it is never
released.

> Have you reviewed the patch in question?  Beyond "applies clean, might

No, have you ? 

> even boot" stage, that is.  Guess what - to do that you will need to
> start with splitting it up, at least to see if e.g. msr.c part is
> Lindent-only or there are actual changes in it.

And, do we care ? We are not going to force that thing upstream as is or
something such, we are just going to build the amd64 kernel-image with
it, and while the users use it and make bug reports and such, hopefully
getting the thing cleaned and split. After allm if it doesn't work, the
maintainer will get the bug report and will have to deal with it, and
none of the rest of us will be affected, but on the other side, if it
works, the code will be there and the user will profit from it.

> > So, don't forget, in the fight between user availablitiy and mostly
> > cosmetic changes which won'ty be noticed by anyone apart from us, it is
> > clear where the priority of debian goes, go reread the social contract
> > if you are not convinced.
> 
> Where does social contract say that blind, unreviewed use of code that
> will run with maximal priveleges possible is in the interests of users?

"Our priorities are our users and free software"

This does speak nowhere that said code has to be in pristine conditions,
and that a bunch of purist will withold the code from our users because
of that, trying to force work on volunteers they are not willing to do
themselves.

BTW, who are you anyway who don't sign your messages and which i have
never seen here before ? And your help to cleanup said patches are
welcome, instead of your moralizing speaches from up there.

Friendly,

Sven Luther



Reply to: