From: "Randy Dunlap" <rdunlap@xenotime.net>
To: "Stratos Psomadakis" <psomas@ece.ntua.gr>
Cc: "Matt Mackall" <mpm@selenic.com>,
david@lang.hm, linux-kernel@vger.kernel.org,
"Frank Kingswood" <frank@kingswood-consulting.co.uk>,
"Linus Torvalds" <torvalds@linux-foundation.org>
Subject: Re: ketchup script and 3.0
Date: Tue, 7 Jun 2011 14:33:53 -0700 [thread overview]
Message-ID: <05cba294449b86a9aa22cec4abc7e98f.squirrel@xenotime.net> (raw)
In-Reply-To: <4DEE9695.7060805@ece.ntua.gr>
On Tue, June 7, 2011 2:22 pm, Stratos Psomadakis wrote:
> On 06/07/2011 11:59 PM, Matt Mackall wrote:
>> On Tue, 2011-06-07 at 13:50 -0700, david@lang.hm wrote:
>>> On Tue, 7 Jun 2011, Matt Mackall wrote:
>>>
>>>> But my point is that if we have adhoc transitions, we will encounter
>>>> the
>>>> "fix all the scripts and websites" pain at every transition. And tools
>>>> that are managed via distros and the like can literally take years to
>>>> get into the hands of users. It'd be nice if the copy of ketchup
>>>> shipped
>>>> in <enterprise distro> just worked 3 years from now because 4.0 wasn't
>>>> a
>>>> surprise.
>>> if you special case 2.4->2.6, and make the default that 4.0 > 3.x, 5.0
>>> >
>>> 4.x, etc won't things 'just work' for the forseeable future?
>> No, because you sometimes want to know what 2.6.39++ is and what 3.0--
>> is.
>>
>> For instance, to upgrade from 2.6.37.2 to 3.1.2, ketchup will want to
>> download, cache, and apply:
>>
>> patch-2.6.37.2 (reversed!)
>> patch-2.6.38
>> patch-2.6.39
>> patch-3.0 ?? <- hopefully Linus will make a delta against 2.6.39!
>> patch-3.1
>> patch-3.1.2
> Well, if this is a ketchup-only issue (and there's no other need for
> defining at which point major numbers are going to inc), we could find a
> solution/workaround (to future-proof it, without the need of constant
> updating of the code with every major release), but it'll probably be
> uglier, and I think that what Matt proposed is better.
It's also an issue for scripts/patch-kernel, unless I decide
to just kill (drop) it.
> Anyway, when this issue is clarified, I'll try to fix the code, in order
> to handle next major releases, without requiring code changes.
--
~Randy
next prev parent reply other threads:[~2011-06-07 21:40 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-07 7:40 Frank Kingswood
2011-06-07 12:53 ` Matt Mackall
2011-06-07 19:48 ` Stratos Psomadakis
2011-06-07 20:10 ` Matt Mackall
2011-06-07 20:32 ` Stratos Psomadakis
2011-06-07 20:46 ` Matt Mackall
2011-06-07 20:50 ` david
2011-06-07 20:59 ` Matt Mackall
2011-06-07 21:22 ` Stratos Psomadakis
2011-06-07 21:33 ` Randy Dunlap [this message]
2011-06-11 6:02 ` Américo Wang
2011-06-11 18:28 ` Randy Dunlap
2011-06-08 16:21 ` Florian Mickler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=05cba294449b86a9aa22cec4abc7e98f.squirrel@xenotime.net \
--to=rdunlap@xenotime.net \
--cc=david@lang.hm \
--cc=frank@kingswood-consulting.co.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=mpm@selenic.com \
--cc=psomas@ece.ntua.gr \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®