Re: kernel-patch-amd64
On Wed, Jul 07, 2004 at 03:20:35PM -0500, Troy Benjegerdes wrote:
> > Who took that decision ? And even then, how would it be all that
> > different from the many alternative trees out there, like the -mm one
> > Christoph refered to me recently.
> >
> > Nothing is stoping us from presenting usefull stuff to our unstable
> > users while we are still working on it, is this not how free software
> > works ?
>
> This may be okay for unstable, but I would love it if the next stable
> release of debian shipped a 'pristine' (except for non-distributable
> firmware) kernel.org kernel for ppc, x86, and amd64. Other arches will
> probably need some patch.
I understand you would love it, but is this reasonable ? The upstream
release schedules and the debian one may or might not coincide, making
your above mentioned goal an unreachable one, and during both the freeze
and the stable lifetime, the package is due to diverge again, as at
least security fixes are backported.
> Do we have a mechanism for dropping patches as we move from
> unstable->testing->stable ? Or a way to mark a package as "unstable
> only" ?
We simply do upload a package dropping some patches. It would be easy
enough to drop patches from the kernel-source package with just removing
them from the 00list file.
But again, what if we are freezing and then releasing at a time before
let's say 2.6.12 is released, and many of our 2.6.11 patches are already
in the 2.6.12 development tree ?
Again, i believe adhering too strictly to the dogma of shipping only
pristine sources will hurt us more than it will help us. It is a worthy
goal, but we have to step back into reality, and adapt to the different
situation at hand. As long as the patches are of upstream quality, and
are going submitted upstream, it matters not if they are already in the
upstream tree or not.
> > > 2) Getting the patch upstream allows upstream kernel hackers to review
> > > it. This is of real interest to our users, since we ensure that they
> > > will have a verified and accepted (read: supported) kernel.
> >
> > Except that it doesn't always work, often the upstream kernel hackers
> > don't even care to read the patch and you wait forever for comments.
>
> Sometimes, but I think we now have a better chance if we keep Viro, HCH,
> Benh, etc involved.
Yep, i agree. Indeed, i hope that we are as near as upstream as
possible, but let's stay flexible and realistic too.
> If there is a specific patch that's submitted to kernel.org, and we get
> no response, by all means, include it in the debian package, but if we
> have a good reason to have it, and can make good technical points, we
> can include it.. but it's got to be discussed first.
Yep, as opposed to someone taking the decision alone without bothering
to mention this to the team.
> I looked over the amd64 patch, and it's all arch-specific code.. so I
> don't have a real problem with it, assumeing the changes are slated to
> show up in 2.6.8.
So, why is everyone making an huge drama over it ? Instead of letting
the amd64 guy into the team and into the kernel subversion repo, and
working with him, instead of being agressive as the first response where ?
It is preferable to the goal above to work with people, and bring the
different arch patch maintainer into the fold of the debian-kernel team,
than having them angry with us because we disconsider them, and them
working their own stuff out of the team, and given the way debian works,
there is nothing that we can do if they chose to do so.
Friendly,
Sven Luther
>
> --
> --------------------------------------------------------------------------
> Troy Benjegerdes 'da hozer' hozer@hozed.org
>
> Somone asked my why I work on this free (http://www.fsf.org/philosophy/)
> software stuff and not get a real job. Charles Shultz had the best answer:
>
> "Why do musicians compose symphonies and poets write poems? They do it
> because life wouldn't have any meaning for them if they didn't. That's why
> I draw cartoons. It's my life." -- Charles Shultz
Reply to: