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' and get all our other patches
upstream. 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.
 Not right now but after squeeze.
 Mostly successfully.
> Well, that's just random week-end thoughts - you know, world
> domination and the like :)
> Best regards,
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus
Pkg-lustre-maintainers mailing list