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 <ydir...@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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100324003910.gm16...@decadent.org.uk