[Pkg-lustre-maintainers] Status of kernel patch packages

[Ben Hutchings]

On Tue, Mar 23, 2010 at 11:35:33PM +0100, Yann Dirson wrote:
> On Sun, Mar 21, 2010 at 12:17:22AM +0900, Hideki Yamane wrote:
> > On Sat, 20 Mar 2010 15:14:59 +0100
> > Yann Dirson <ydirson at free.fr> wrote:
> > > So the question is, is it time to request removal of those packages,
> > > or is there any remaining reason not to do so that I missed ?
> > 
> >  As linux-patch-tomoyo1.7 package maintainer, tomoyo is merged with 
> >  mainline, but it's not fully featured one yet. At least, I want to 
> >  provide it with squeeze.
> > 
> >  and hope kernel-package would enable patch support again... ;)
> 
> I won't speak for Manoj here, but I feel we should think about other
> ways to provide those patches.
> 
> One way could be simply to provide ensure those patches in some git
> tree, that users can easily fetch and merge before running make-kpkg.
 
Or just 'make deb-pkg', the upstream-supported method.

> But I'm not aware of a git tree holding the debian kernels - SVN is
> still listed as the VCS for the linux-2.6 package (which, BTW,
> continues to surprise me).

It's on our to-do list but further down than the work needed for squeeze.

I do have a script that can convert the patch series into a git branch,
and I could publish a git repository if that's useful.

> But at least we could have some convention
> about where to make available git trees for patch stacks - something
> on git.debian.org surely, which could be quite efficient with the
> "forks" feature of gitweb activated (which does not seems to be the
> case aleady).
> 
> Then maybe some simple helper scripts could make it a snap to fetch
> all patch stacks and start a merge.  Maybe we could at some point also
> be able to publish merges of conflicting patch stacks in a similarly
> convenient way.  Such a resource may even be interesting to many
> people out of Debian.
 
Forking Linux is easy; maintaining a fork is very hard indeed, and we
generally try to avoid doing so.  This is why we are trying to get rid
of the virtualisation 'featuresets'[1] and get all our other patches
upstream[2].  It's also why we're sharing the work of maintaining 2.6.32
with other distributions.  Any intrusive patch set (as opposed to a new
driver or filesystem, which is easier to maintain out-of-tree) should be
treated as a short-term experiment, to be merged upstream or abandoned.
It should never be included in a stable distribution.

[1] Not right now but after squeeze.
[2] Mostly successfully.

Ben.

> Well, that's just random week-end thoughts - you know, world
> domination and the like :)
> 
> Best regards,

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
                                                              - Albert Camus