[Pkg-uml-devel] [VERY LONG - uml planning for etch] how to plan the future

[Mattia Dongili]

On Fri, Jan 13, 2006 at 11:41:03PM +0100, Andreas Schuldei wrote:
> On Thu, Jan 12, 2006 at 11:54:27PM +0100, Stefano Melchior wrote:
[...]
> > 3 - uml-utilities;
> 
> and this

This is the only one I currently use from the debian repos

[...]
> > (1) user-mode-linux
> > It is crucial. At the moment there is the support for 2.4.27, 2.6.8 (but
> > not working) and 2.6.12. This could be enough, even though its support is
> > in deplay, for Sarge. Etch requires at least 2.6.14 support.
> > What about the `old` 2.4.27? what 2.4.x serie kernle will be supported on
> > Etch?
> 
> the goal is to have no 2.4 in etch, aparently. which is very good
> for us.
> 
> > So it is time to start from the 2.6.12-1um idea and implement the
> > 2.6.{14,15} support. That is the target. 2.6.12 is out of date, now.
> > I subscribed the uml lists on sourceforge and 2.6.15 is not so stable and
> > reliable to be definitively included. So first, my idea, is to focus on
> > 2.6.14, waiting for a better release.
> 
> what about trying to cooperate with the kernel team and supply
> them with fixes to make the kernel that seems to end up in etch
> to make uml run as good as possible? will such patches be
> produced by the uml hackers for e.g. 2.6.15?

That's the same I was sugesting here [1].
I'm only worried about uml fragility (? if any) and the willingness
(AFAIU [2]) of the kernel team to to stay as close as possible to
vanilla kernels.

[1]: http://lists.alioth.debian.org/pipermail/pkg-uml-devel/2006-January/000133.html
[2]: http://wiki.debian.org/DebianKernelPatchAcceptanceGuidelines

[...]
> > (5) kernel-patch-uml
> > It is time to choose the future of this pkg: it should not be usefull
> > since the kernel version newer that 2.6.8 provides um architecture support
> > embedded. But we still need to support the previous kernel ones, so we are
> > encouraged to keep it alive and, above all, to fix the bugs.
> 
> really? why? for etch (what we work towards) it is not really
> desireable to have a wide range of all sorts of kernels

agreed, and I believe this is event more valid for the UML case where
you don't have to deal with fancy hardware. We just need the best
possible UML, no need to bring to life old and possibly buggy
implementations.

> supported. people pick debian because they just installed a
> pre-compiled package and it works. they dont want to fiddle much
> with it. 
> 
> if we manage to work with the kernel guys and make their kernel
> compile a stable, good uml kernel and we can ship that
> precompiled we are all set, i think. 

agreed again.

> should we try to get the skas kernel into the mainline kernel?

mainline == vanilla or mainline == debian's ?
If the latter, given the above wiki page I'm not that optimistic :)

> does it have any penalites for the non-uml case?

don't know, sorry.

[...]
> could you please give the URLs of the svn and the cvs archive?
> i mean the output of svn info and cvs's CVS/Root content.

svn:
http://svn.debian.org/wsvn/pkg-uml
svn://svn.debian.org/pkg-uml/

cvs:
https://alioth.debian.org/scm/?group_id=30573
http://cvs.alioth.debian.org/cgi-bin/cvsweb.cgi?cvsroot=pkg-uml

-- 
mattia
:wq!