Re: Linux 2.6.11.2

Bill Davidsen
2005-03-14T17:22:52Z

On Fri, 11 Mar 2005, Greg KH wrote:

> On Fri, Mar 11, 2005 at 11:19:28AM -0800, Chris Wright wrote:
> > * Matt Mackall (mpm@selenic.com) wrote:
> > > Or do you want to do it the same way you do for every other branch? I
> > > don't want to special-case it in my code and I don't think users want
> > > to special-case it in their brains. Have separate interdiffs on the
> > > side, please, and then people can choose, but do it the standard way.
> > >
> > > Dear ${SUCKER}s, can we have a decision on this? My ketchup tool is
> > > broken for 2.6.11.2 and I don't want to cut a new release until a firm
> > > decision is made. Obviously I have a strong preference for all 2.6.x.y
> > > diffs being against 2.6.x, it means that .y can be treated the same as
> > > -rc, -bk, -mm, ... (and I already coded it that way when 2.6.8.1 came
> > > out).
> >
> > I agree with having the patch be against .x, with x.y -> x.y+1 interdiffs
> > available on the side. Greg, any issue with that?
>
> No, I agree with that, and will not be hard to do at all (the release
> script already handles this just fine.)
>
> I've held off rediffing 2.6.11.2 so far, as I don't know where to put
> the x.y+1 interdiffs? kernel/v2.6/incr/ ? Any thoughts?

I guess incr is as good as any, I thought you would put the "against base"
somewhere, having already decided to do incrementals. Hopefully you will
at least change the numbering on the patch file (no, not the version in
the Makefile), so patch 2.6.11.3i is againt 2.6.11.2, and 2.6.11.3 is
against 2.6.11. That way people can tell after the download which one they
have if they forget.

I didn't like the initial decision to go incremental, and I even less like
changing now, but it's the right thing to do. It's not like we have a big
investment in scripts or anything, and you're doing the work.

--
bill davidsen <davidsen@tmr.com>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.