On Fri, Feb 11, 2011 at 05:43:44PM +0000, Ed W wrote:
> Hi
> >>These merge conflicts would disappear if you would be kind enough to
> >>switch to using the "localversion-" method to add EXTRAVERSION params
> >>rather than patching the Makefile?
> >assuming that you use the proper base kernel, I don't
> >see why that chunk would cause any merge failures ...
> That's basically the point, I kind of don't want to use the correct base
> kernel...
> OK, stop there before you panic... The point is not to give you support
> grief, but that patch management tools such as git don't think in terms
> of "patches against specific versions", but they tear up the code into a
> series of change sets which are stacked on top of each other:
so simply do not check in that specific change, it should
almost always end up in a separate patch hunk which can
be removed with filterdiff or grepdiff ...
if you feel like localversion, you could also grep/sed
that out of the removed change and add it back there
fully automated ...
> I'm trying to use git to keep a fixed series of vserver patches and
> forward port the *kernel* on those patches (kind of the opposite of how
> you would develop the patchset). So I'm having some success in:
> - branch mainline kernel on say 2.6.36
> - patch vs-2.6.36(.0)
> - merge kernel changes up to 2.6.36.1
> - patch vs-2.6.36.1 onto vanilla and commit that (basically giving the
> incremental vs patch)
> - merge kernel changes up to 2.6.36.2
> - patch vs-2.6.36.2 , etc, etc
> The important bit is that this gives the incremental changes at each
> step to move upwards in time (obviously beware that only certain
> points are tested working kernels, but that's not the purpose or a
> limitation). However, this appears to make it quite straightforward to
> merge several such trees of patchsets together
> In my case I'm looking at maintaining a grsec or pax + vserver + aufs
> patchset. It's fairly straightforward to use the procedure above
> to work out the incremental patchset for each kernel version and
> maintaining the joint patchset is vastly easier because we can largely
> maintain only the incremental changes at each stage. So far in my
> experiments merging through non major kernel re-org work has been
> quite straightforward and maintaining a hybrid patch is much simpler
> However, in the case of linux-vserver, once I apply the vs patch,
> then try and pull all the new kernel commits to get me up to the next
> kernel version (in prep to apply the next vs patch), I always get
> a merge failure on the EXTRAVERSION bump commit... So far I don't
> know how to script an automated fix to a git merge and then restart
> the merge... It's basically quite a slowdown in the otherwise simple
> process of maintaining the patch...
> >we use the EXTRAVERSION to ensure that everybody who
> >uses the patch on a different kernel release as intended
> >gets a proper 'warning' at patch time,
> It would appear that it doesn't quite achieve this? Only checks that
> you use the correct minor kernel version? Not that the major version is
> correct?
as the patch will also fail when the first context line
(the SUBLEVEL) is different, I'm pretty sure it covers
all 'real world' cases ...
> Also, is this useful? Your biggest problem on the list seems to be
> debian users still on 2.6.9 or something antique, not users trying to
> apply the patch to some release candidate of the next kernel?
well, maybe that is _because_ we do it this way :)
> Also, not that I am advocating users trying this, but from my very
> limited observation so far, largely the patch for 2.6.x.1 seems
> appropriate to apply to 2.6.x.2?
yes, but there is a difference between a patch which
applies perfectly fine and a patch intended for this
specific version (the former might fail at compile or
runtime)
> >I don't see why that would be hard to automate for you,
> >after all, I automated the EXTRAVERSION change as well,
> >with a simple sed line ...
> I am trying to use a more modern patch management process, in this
> case git. It has automated processes to maintain a series of patches
> and there isn't an obvious way to insert an extra step to run some
> sed recipe part way through a merge? I dont think the situation would
> change if I used mercurial/bzr/quilt, etc though - fundamentally
> it's a deliberately inserted merge failure (in your case to stop the
> theoretical mis-application to the wrong version, in my case stopping
> me easily generating a series of incremental patches)
> Additionally every patchset wants to show it's hand in EXTRAVERSION,
> and localversion- was basically added to make this process scalable
> (I want to show aufs+grsec as well as vs versions)
as I said, perfectly fine for your personal version
> I would be grateful if you would weigh up a genuine (small) barrier
> to using the vserver patch more easily/widely vs the possibility
> of someone learning to use the "-p1" feature of patch and then
> "accidently" applying the patchset to the wrong base kernel, and come
> down on the side of ease of use... (pretty please...)
I did, and your arguments do not convince me, sorry ...
> I will write a second email with a suggestion on how you might find
> git useful for your own internal process - so far it seems like it
> might work pretty well for forward porting vserver patches to new
> kernels?! (To be clear, I'm doing the reverse, forward porting the
> kernel onto the old patch...)
feel free to do so, but know that I tried git several
times (for Linux-VServer development) and it failed
for me each time, so I went back to the (very similar)
way of maintaining kernel trees in a hard linked setup
which works perfectly fine ...
note that I cannot help to notice that most of the
arguments you brought up so far are based on the
assumption that _I_ should change something in the
way _we_ develop Linux-VServer to simplify _your_
work ... shouldn't it be the other way round?
please don't get this the wrong way, I have been
developing Linux-VServer for almost 10 years now and
the procedures work reasonably well and stable, so
I do not see any reason to change that in the near
future without _really_good_ reasons ...
best,
Herbert
> Kind regards
> Ed W
Received on Fri Feb 11 18:03:46 2011