On 5/30/06, Anders Eriksson C (KI/EAB) wrote:
>
> > On 5/29/06, Anders Eriksson C (KI/EAB) wrote:
> >
> <snip>
> >
> > How'd you make out on the 2.6.16 patch? Any success?
> Not really (yet). I've got the patch split:
:). Last person that attempted said everything applied to 2.6.16,
except the a small portion fo the memory section... That didn't apply
because there where changes in the LK in that area. The person who
wrote that wasn't able to resolve that problem...
> -rw-r--r-- 1 eraaero users 90203 May 3 17:10 base
> -rw-r--r-- 1 eraaero users 17018 May 3 17:11 coconsole
> -rw-r--r-- 1 eraaero users 80666 May 3 17:11 cofs
> -rw-r--r-- 1 eraaero users 7748 May 3 17:11 conet
> -rw-r--r-- 1 eraaero users 35937 May 3 17:11 driver
nice...
> ..and started to browse around in the base patch. Real Work has
> derailed me a bit I'm afraid. I've not given up on it though!
:). I have that problem all the time.
> > The size of the
> > patch and it's monolithic nature have never stopped other coLinux
> > kernel patch submitters in the past. I have no objections to
> > splitting up the patch. Henry is on vacation, but when he get's back
> > I'd be interested in his opinion of splitting this patch up into
> > chunks.
> >
> How has this been handled in the past? If I hack away on the monolithic
> patch I can imagine myself having my own 250 KB patch (for e.g. 2.6.16)
> at the end... Would the proper procedure be to send it to the list?
> Or get myself a monotone account some where and maybe monotone sorts
> things out? (I'm not familiar with monotone).
Check the archives. In the past any kernel patch (even ones I
worked on, I believe) have been posted to colinux-devel for review. I
usually recommend that if you are going to submit a patch to the
projects at least submit it to the colinux-devel ML. I prefer an CC
to the developers (ie me & Dan or currently me & Henry). You could,
also, post the patch on SF, but to be honest patches have slipped
through the crack when that was done in the past.
Submit the patch as you see fit... broken up if you like into
seperate parts. If we still think it needs to be monolithic as part
of the official source, we have the tools/means to make that the
happen.
monotone is not all that different than cvs in it's fundamentals,
it's just built a little more for distributed use... We've set it up
so that only certain users have write access to the publicly available
monotone db, so those users have to be the ones who make the changes
to the source in the monotone db. By anonymously getting the monotone
db using monotone client, you create a local db... with that local db
you can do whatever you like, including write to it, merge branches,
etc... You can even diff to create patch to submit to the devel
list, if you like.
> As I don't really trust myself in these waters, so I'd much like to have
> my contrib reviewed by the core delvels before it approaches mainline.
> How's that procedure setup? I've never really seen patch-reviews on the
> colinux maillists (as is customary in lkml).
Sounds like you are doing a bang-up job. So far in the past I've
taken discussions of the patch off-line to the main devels and the
person submitting the patch... Not sure why, just seemed liked the
right thing to do.
Seriously, do the development how you like and what works for you.
If breaking up the patch works for you, and you get a working 2.6.16
from doing that, submit it we'll be happy to review it, and apply it
to the real source, even if we do so officially as an monolithic
patch.
> > That is how the current coLinux kernel patch 'system' currently adds
> > third-party patches, such as Knoppix's cloop. We built it that way to
> > allow coLinux to be base that others modifed as needed.
> >
> Under this philosophy, would my (250KB 2.6.16 diff) contrib apply on top
> of the existing 2.6.12 patch? While I can see that the mechanics work
> for the actual build, it doesn't seem to be maneageable for the future as
> there's no incentive for patch consolidation nor patch enhancements.
Not really. The intent is that there'd be a 'monolithic'/base
patch, and patches for additional things like more virtual devices, or
cloop, squash, sftp/FUSE, etc could be added by anyone who wants to
change coLinux's official source to enhance it in some way.
If I was you I'd replace the linux-2.6.12 that's there with your
base, coconsole, cofs, conet, driver, and leave the cloop there (to
verify it doesn't conflict).
> I agree that things are rapidly changing in this area, but on the other
> hand, even if we'd never merge, wouldn't a one-patch-per-feature be more
> maneageable? Virtualization is a hoopt topic in linux right now, and I'd
> expect that *some* of the things that gets introduced can be taken
> advantage of in colinux (e.g. the frontends of virtual network interface drivers).
If we had more developer's maybe. Really I've always felt that
quilt or patch-sets are a developer's preference... Working on the
project I've probably gotten into a rut in working with the monolithic
patch, but I myself like patch-sets but haven't really gotten familiar
with patchset tools like quilt or the like.
> > Some background on past discussion and the results of them. The
> > kernel version for 'stable' will not change after the initial release
> > of that version series (ie the kernel of 0.6.x will always be 2.6.10),
> > although we have 'bent' this a little in the recent release, but
> > typically only to fix outstanding bugs and make stable, well more
> > stable and usable. This being because we want stable to be stable,
> > hopefully devel doesn't get as behind as it has recently. That is
> > what has really hurt us to this point.
> >
> Sounds reasonable. Let's hope we can get traction on the devel side.
>
> Any pointer to established procedured for patch handling would be
> appreciated!!
Pretty much it's submit it to colinux-devel ML, and/or developers and
that's pretty much it.
--
George
|