Re: [uml-devel] Re: [uml-user] skas not found

[BlaisorBlade <blaisorblade_spam@yahoo.it>]

Alle 19:17, martedì 8 giugno 2004, Jeff Dike ha scritto:
> blaisorblade_spam@yahoo.it said:
> > - There should be a stable branch, just updating to new releases, and
> > development patches, adding experimental features. It works so all
> > over the  world. Sadly not here. I would also think that stable trunk
> > is 2.4.26-1,  -2... while for development we have a list of
> > independent patches  (HUMFS-2.4.26-1-v1.patch to apply onto 2.4.26-1,
> > and which is version 1).

> I don't disagree.  A stable tree would be a fine idea.  The only problem is
> that no one has volunteered to manage it, and I don't have time to open
> up and maintain a new tree.

Well, let's discuss this on the ML. I could be maybe able to maintain it, if 
we intend it as "porting to new vanilla kernels, merging patches when they 
are ready and building the patch". Not very timely maybe, but I could. This 
is not a good moment for this, since I should be busy... however I'm going to 
post a test-patch for 2.6.7... it will maybe include some trivial changes I 
posted recently.

> > This could be done in 2.6 mainline if UML updates get merged: Jeff,
> > you could  update UML to kernel changes in mainline, while putting
> > experimental patches  on the site until they are tested enough to be
> > merged.

> Who's going to test individual patches unless they are part of a widely
> used tree?

>  I think a stable tree is a fine idea, but I don't particularly
> like the idea of having an "official" set of patches floating around.  If
> they're official, then they can be part of a development tree, and everyone
> who uses that tree tests all of the patches in it.
>
> 				Jeff

Ok, I could translate and correct my idea to:

- the "stable" tree will be, at the end, the vanilla tree (so no release work 
for you).

- you keep mantaining a development tree, but if possible in the form of a 
patchset (like -mm); each new (non-trivial) patch is posted to the ML (well, 
obviously you don't need to wait for comments), so that it can be tested 
before the new release (especially if it's development work).

The "patchset" form is especially important to be able to commit patches in 
little bits (well, not so little: splitting one big change in 7 depending 
changes as on LKML is a lot of work, but separating HUMFS and other fixes is 
not).

To manage well the patchset, with little effort, there are the patch-scripts 
from Randy Dunlap, used for -mm (at 
http://developer.osdl.org/rddunlap/patch-scripts/). I'm going to study them, 
probably.
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729



-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel