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

[Stefano Melchior]

On Sat, Jan 14, 2006 at 06:00:24PM +0100, Mattia Dongili wrote:
Hi all,
> > and this
> 
> This is the only one I currently use from the debian repos
[...]
> > > (1) user-mode-linux
> > 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.

With my first mail I tried to summarize the state of the art, plus to
start planning what action to do in the next months.
I agree with both you when you say that it is better to have only one good
and working UML kernel than various and (not always with a good support).
The problem in debian is that you don't always know what is the final
kernel version: 2.6.14 or 2.6.15?
My idea is to go for the 2.6.15. Join the kernel team efford and
cohoperate with both debian and u-m-l.sf.net ML team.

In this case, are we leaving the 2.4 serie branch support?
If so, the support should be only for woody and its kernle version.
If not which kernle to support? 2.4.27 for sarge? But Sarge inclueds no
kernel-dependent u-m-l pkg, since u-m-l is not included, as well as kernel-patch-uml and kernle-patch-skas (if I am not wrong about the latest).

If etch, as you say, won't support 2.4 serie kernel at all, it is good for
me to concentrate our effords only on 2.6.15. Do you agree?
> 
> [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

My idea was to support one u-m-l kernel for each official kernel: i.e.
2.4.27 and 2.6.15; but if we all agree to leave this approach we will not
save my latest efford (2.4.27-1um), it is not a problem.
> 
> 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.
correct
> 
> > 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.
then we all agree! In this way we can dismiss kernel-patch-uml and use
only user-mode-linux pkg as a reference/focus.
However we need to support kernel-patch-skas, for the host kernel.
> 
> > 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?
it should not
> 
> 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.
Why on the alioth site are any CVS/SVN statistics present on the home
page?
> 
> 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
tonight you both will be included as the svn admins, ok?
Cheers

SteX

-- 
Stefano Melchior, GPG key = D52DF829 - <stefano.melchior at openlabs.it>
http://etinarcadiaego.dyndns.org    --     http://www.stex.name
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-uml-devel/attachments/20060114/c561cb73/attachment.pgp