Old split quilt queues

Old split quilt queues

[Ralf Ramsauer]

Hi everyone,

I'm looking for older RT split quilt queues, especially those for kernel
versions 2.6.31 and 2.6.33.
Apparently, these are the only two versions without split quilt queues
available on the FTP server.

Does someone of you know where to get those patch stacks? Or more
precisely: are split quilt queues actually existing for those versions?

I'm looking for _all_ available split quilt queues for those versions as
I'm doing some analysis on the patch stacks.
And no, I of course don't want to run my box on those old versions :-)

Thanks!

Cheers
  Ralf

-- 
Ralf Ramsauer
GPG: 0x8F10049B

Re: Old split quilt queues

[Thomas Gleixner]

Ralf,

On Mon, 18 Jan 2016, Ralf Ramsauer wrote:

> I'm looking for older RT split quilt queues, especially those for kernel
> versions 2.6.31 and 2.6.33.
> Apparently, these are the only two versions without split quilt queues
> available on the FTP server.
>
> Does someone of you know where to get those patch stacks? Or more
> precisely: are split quilt queues actually existing for those versions?

I think that was the time where we actually tried to handle the rt patches in
git and therefor did not release quilt queues. Those git branches are gone
from git.kernel.org AFAICT, but I should have an archive somewhere. Poke me
again in a week if I forget to search for it.

> I'm looking for _all_ available split quilt queues for those versions as
> I'm doing some analysis on the patch stacks.

Out of curiousity. What kind of analysis are you doing?

Archaeological studies? I wouldn't be suprised, given that you are in the
pyramid building business.

Thanks,

	tglx

Re: Old split quilt queues

[Ralf Ramsauer]

Hi Thomas,

On 01/20/2016 09:59 PM, Thomas Gleixner wrote:
> Ralf,
>
> On Mon, 18 Jan 2016, Ralf Ramsauer wrote:
>
>> I'm looking for older RT split quilt queues, especially those for kernel
>> versions 2.6.31 and 2.6.33.
>> Apparently, these are the only two versions without split quilt queues
>> available on the FTP server.
>>
>> Does someone of you know where to get those patch stacks? Or more
>> precisely: are split quilt queues actually existing for those versions?
> I think that was the time where we actually tried to handle the rt patches in
> git and therefor did not release quilt queues. Those git branches are gone
> from git.kernel.org AFAICT, but I should have an archive somewhere. Poke me
> again in a week if I forget to search for it.
Ok, that's what I thought. A working git repo would really be helpful.
>
>> I'm looking for _all_ available split quilt queues for those versions as
>> I'm doing some analysis on the patch stacks.
> Out of curiousity. What kind of analysis are you doing?
>
> Archaeological studies? I wouldn't be suprised, given that you are in the
> pyramid building business.
Well, yes, kind of. I'm doing some archaeological research, digging deep
inside prehistoric PreemptRT and trying to figure out what we can learn
from history.

RT is a pretty huge patch stack which has been around for a couple of
years. I'm trying to find answers to questions like:
 - how did RT evolve over the years?
 - which kind of patches went upstream?
 - how long did a patch live in the RT stack before it went upstream?
 - which kind of patches tend to stay in the patch stack and will
probably not go upstream?

Therefore I'm happy for anything old that's still available out there.
Anything helps.
I will keep you informed.

Thank you
  Ralf
>
> Thanks,
>
> 	tglx
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


-- 
Ralf Ramsauer
GPG: 0x8F10049B

Re: Old split quilt queues

[Ralf Ramsauer]

Hi,

On 01/20/16 21:59, Thomas Gleixner wrote:
> Ralf,
>
> On Mon, 18 Jan 2016, Ralf Ramsauer wrote:
>
>> I'm looking for older RT split quilt queues, especially those for kernel
>> versions 2.6.31 and 2.6.33.
>> Apparently, these are the only two versions without split quilt queues
>> available on the FTP server.
>>
>> Does someone of you know where to get those patch stacks? Or more
>> precisely: are split quilt queues actually existing for those versions?
> I think that was the time where we actually tried to handle the rt patches in
> git and therefor did not release quilt queues. Those git branches are gone
> from git.kernel.org AFAICT, but I should have an archive somewhere. Poke me
> again in a week if I forget to search for it.
Poke :-)
Did you find some old archive?

Thanks
  Ralf
>
>> I'm looking for _all_ available split quilt queues for those versions as
>> I'm doing some analysis on the patch stacks.
> Out of curiousity. What kind of analysis are you doing?
>
> Archaeological studies? I wouldn't be suprised, given that you are in the
> pyramid building business.
>
> Thanks,
>
> 	tglx
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Ralf Ramsauer
GPG: 0x8F10049B

Re: Old split quilt queues

[Thomas Gleixner]

On Thu, 28 Jan 2016, Ralf Ramsauer wrote:
> On 01/20/16 21:59, Thomas Gleixner wrote:
> > from git.kernel.org AFAICT, but I should have an archive somewhere. Poke me
> > again in a week if I forget to search for it.
> Poke :-)

Ouch :)

> Did you find some old archive?

Yes. Just forgot to push it out to k.org. Here you go:

     git://git.kernel.org/pub/scm/linux/kernel/git/tglx/rt-history.git

It has two branches: linux-2.6.31.y-rt and linux-2.6.33.y-rt

Have fun!

Thanks,

	tglx

Re: Old split quilt queues

[Ralf Ramsauer]

Great, thank you very much!
  Ralf

On 01/29/16 12:12, Thomas Gleixner wrote:
> On Thu, 28 Jan 2016, Ralf Ramsauer wrote:
>> On 01/20/16 21:59, Thomas Gleixner wrote:
>>> from git.kernel.org AFAICT, but I should have an archive somewhere. Poke me
>>> again in a week if I forget to search for it.
>> Poke :-)
> Ouch :)
>
>> Did you find some old archive?
> Yes. Just forgot to push it out to k.org. Here you go:
>
>      git://git.kernel.org/pub/scm/linux/kernel/git/tglx/rt-history.git
>
> It has two branches: linux-2.6.31.y-rt and linux-2.6.33.y-rt
>
> Have fun!
>
> Thanks,
>
> 	tglx
>
>

-- 
Ralf Ramsauer
GPG: 0x8F10049B

Re: Old split quilt queues

[Ralf Ramsauer]

Hi,

just out of curiosity:

As I expected, inside that repo are a lot of tags for the various -rt
versions.
First I thought, RT would make use of rebasing, like:
  - Rebase onto the next kernel version and drop unnecessary commits
(e.g. patches that went upstream)
  - Do some additional changes
  - Export vA.B.C...vA.B.C-rtX as split quilt queue

But afaict, (at least on the old rt-history), you made a lot of merges
from rt/* branches and added tags describing the -rt version. Then you
went on merging against master in order to keep up with upstream.

Given that, how do you create a split quilt queue, that applies against
an upstream tag?

For example, let's take the first RT Tag of rt-history: v2.6.31-rc6-rt2
How would you create a split quilt queue, that applies against v2.6.31-rc6?

(I need to extract all those split quilt queues RT version<->base
upstream version)

Thank you
  Ralf

On 01/29/16 12:12, Thomas Gleixner wrote:
> On Thu, 28 Jan 2016, Ralf Ramsauer wrote:
>> On 01/20/16 21:59, Thomas Gleixner wrote:
>>> from git.kernel.org AFAICT, but I should have an archive somewhere. Poke me
>>> again in a week if I forget to search for it.
>> Poke :-)
> Ouch :)
>
>> Did you find some old archive?
> Yes. Just forgot to push it out to k.org. Here you go:
>
>      git://git.kernel.org/pub/scm/linux/kernel/git/tglx/rt-history.git
>
> It has two branches: linux-2.6.31.y-rt and linux-2.6.33.y-rt
>
> Have fun!
>
> Thanks,
>
> 	tglx
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Ralf Ramsauer
GPG: 0x8F10049B

Re: Old split quilt queues

[Thomas Gleixner]

On Fri, 29 Jan 2016, Ralf Ramsauer wrote:
> As I expected, inside that repo are a lot of tags for the various -rt
> versions.
> First I thought, RT would make use of rebasing, like:
>   - Rebase onto the next kernel version and drop unnecessary commits
> (e.g. patches that went upstream)
>   - Do some additional changes
>   - Export vA.B.C...vA.B.C-rtX as split quilt queue
> 
> But afaict, (at least on the old rt-history), you made a lot of merges
> from rt/* branches and added tags describing the -rt version. Then you
> went on merging against master in order to keep up with upstream.
> 
> Given that, how do you create a split quilt queue, that applies against
> an upstream tag?
> 
> For example, let's take the first RT Tag of rt-history: v2.6.31-rc6-rt2
> How would you create a split quilt queue, that applies against v2.6.31-rc6?
> 
> (I need to extract all those split quilt queues RT version<->base
> upstream version)

As I said before: That was an experiment whether git is usable as a tool to
manage something complex as rt. It turned out, that it's not. I recreated a
new quilt queue after I abondoned git for rt.

So creating split queues is going to be a very interesting and tedious
detective work.

Thanks,

	tglx

Re: Old split quilt queues

[Paul Gortmaker]

On Fri, Jan 29, 2016 at 2:56 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
> On Fri, 29 Jan 2016, Ralf Ramsauer wrote:
>> As I expected, inside that repo are a lot of tags for the various -rt
>> versions.
>> First I thought, RT would make use of rebasing, like:
>>   - Rebase onto the next kernel version and drop unnecessary commits
>> (e.g. patches that went upstream)
>>   - Do some additional changes
>>   - Export vA.B.C...vA.B.C-rtX as split quilt queue
>>
>> But afaict, (at least on the old rt-history), you made a lot of merges
>> from rt/* branches and added tags describing the -rt version. Then you
>> went on merging against master in order to keep up with upstream.
>>
>> Given that, how do you create a split quilt queue, that applies against
>> an upstream tag?
>>
>> For example, let's take the first RT Tag of rt-history: v2.6.31-rc6-rt2
>> How would you create a split quilt queue, that applies against v2.6.31-rc6?
>>
>> (I need to extract all those split quilt queues RT version<->base
>> upstream version)
>
> As I said before: That was an experiment whether git is usable as a tool to
> manage something complex as rt. It turned out, that it's not. I recreated a
> new quilt queue after I abondoned git for rt.
>
> So creating split queues is going to be a very interesting and tedious
> detective work.

Just stumbled upon this older discussion now by happenstance.

I can say with experience that it is exactly that:  tedious.

2.6.33 split queue:

http://www.spinics.net/lists/linux-rt-users/msg06310.html

2.6.34 split queue:

http://permalink.gmane.org/gmane.linux.kernel/1109036

The repo I referenced in the above doesn't seem to exist anymore
on kernel.org - although I don't explicitly recall deleting it.  Maybe
that was fallout from when kernel.org got hacked?

But I am guessing I probably still have a local copy somewhere that
could be used to repopulate if anyone really cared about that old stuff.

I don't recall if I implicitly made a 2.6.31 series in the march forward to
the 2.6.33 but since 31 didn't have merges (aside from stable stuff)
that series would probably be reasonably easy to construct.

Paul.
--

>
> Thanks,
>
>         tglx
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Old split quilt queues

[Ralf Ramsauer]

Hi Paul,

On 03/07/16 04:42, Paul Gortmaker wrote:
> On Fri, Jan 29, 2016 at 2:56 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
>> On Fri, 29 Jan 2016, Ralf Ramsauer wrote:
>>> As I expected, inside that repo are a lot of tags for the various -rt
>>> versions.
>>> First I thought, RT would make use of rebasing, like:
>>>   - Rebase onto the next kernel version and drop unnecessary commits
>>> (e.g. patches that went upstream)
>>>   - Do some additional changes
>>>   - Export vA.B.C...vA.B.C-rtX as split quilt queue
>>>
>>> But afaict, (at least on the old rt-history), you made a lot of merges
>>> from rt/* branches and added tags describing the -rt version. Then you
>>> went on merging against master in order to keep up with upstream.
>>>
>>> Given that, how do you create a split quilt queue, that applies against
>>> an upstream tag?
>>>
>>> For example, let's take the first RT Tag of rt-history: v2.6.31-rc6-rt2
>>> How would you create a split quilt queue, that applies against v2.6.31-rc6?
>>>
>>> (I need to extract all those split quilt queues RT version<->base
>>> upstream version)
>> As I said before: That was an experiment whether git is usable as a tool to
>> manage something complex as rt. It turned out, that it's not. I recreated a
>> new quilt queue after I abondoned git for rt.
>>
>> So creating split queues is going to be a very interesting and tedious
>> detective work.
> Just stumbled upon this older discussion now by happenstance.
>
> I can say with experience that it is exactly that:  tedious.
I bet!
>
> 2.6.33 split queue:
>
> http://www.spinics.net/lists/linux-rt-users/msg06310.html
>
> 2.6.34 split queue:
>
> http://permalink.gmane.org/gmane.linux.kernel/1109036
Oh my god, that must have been some agonizing days back in 2011 :-)

I tried the same, but eventually stopped linearizing the patch stack
after a few hours as there was no real chance of fast success...
>
> The repo I referenced in the above doesn't seem to exist anymore
> on kernel.org - although I don't explicitly recall deleting it.  Maybe
> that was fallout from when kernel.org got hacked?
>
> But I am guessing I probably still have a local copy somewhere that
> could be used to repopulate if anyone really cared about that old stuff.
If you still have access to those old versions, I'd appreciate if you
would let me know, anything helps!

Just out of curiosity: Do you still remember how long it took you to
linearize those stacks? As I already mentioned, I gave up after a few
hours .-)

Cheers
  Ralf
>
> I don't recall if I implicitly made a 2.6.31 series in the march forward to
> the 2.6.33 but since 31 didn't have merges (aside from stable stuff)
> that series would probably be reasonably easy to construct.
>
> Paul.
> --
>
>> Thanks,
>>
>>         tglx
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Ralf Ramsauer
PGP: 0x8F10049B

Re: Old split quilt queues

[Paul Gortmaker]

[Re: Old split quilt queues] On 07/03/2016 (Mon 12:15) Ralf Ramsauer wrote:

> Hi Paul,
> 
> On 03/07/16 04:42, Paul Gortmaker wrote:
> > On Fri, Jan 29, 2016 at 2:56 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
> >> On Fri, 29 Jan 2016, Ralf Ramsauer wrote:
> >>> As I expected, inside that repo are a lot of tags for the various -rt
> >>> versions.
> >>> First I thought, RT would make use of rebasing, like:
> >>>   - Rebase onto the next kernel version and drop unnecessary commits
> >>> (e.g. patches that went upstream)
> >>>   - Do some additional changes
> >>>   - Export vA.B.C...vA.B.C-rtX as split quilt queue
> >>>
> >>> But afaict, (at least on the old rt-history), you made a lot of merges
> >>> from rt/* branches and added tags describing the -rt version. Then you
> >>> went on merging against master in order to keep up with upstream.
> >>>
> >>> Given that, how do you create a split quilt queue, that applies against
> >>> an upstream tag?
> >>>
> >>> For example, let's take the first RT Tag of rt-history: v2.6.31-rc6-rt2
> >>> How would you create a split quilt queue, that applies against v2.6.31-rc6?
> >>>
> >>> (I need to extract all those split quilt queues RT version<->base
> >>> upstream version)
> >> As I said before: That was an experiment whether git is usable as a tool to
> >> manage something complex as rt. It turned out, that it's not. I recreated a
> >> new quilt queue after I abondoned git for rt.
> >>
> >> So creating split queues is going to be a very interesting and tedious
> >> detective work.
> > Just stumbled upon this older discussion now by happenstance.
> >
> > I can say with experience that it is exactly that:  tedious.
> I bet!
> >
> > 2.6.33 split queue:
> >
> > http://www.spinics.net/lists/linux-rt-users/msg06310.html
> >
> > 2.6.34 split queue:
> >
> > http://permalink.gmane.org/gmane.linux.kernel/1109036
> Oh my god, that must have been some agonizing days back in 2011 :-)
> 
> I tried the same, but eventually stopped linearizing the patch stack
> after a few hours as there was no real chance of fast success...

Yeah, it is not something you are going to bang out in a couple of
hours.

> >
> > The repo I referenced in the above doesn't seem to exist anymore
> > on kernel.org - although I don't explicitly recall deleting it.  Maybe
> > that was fallout from when kernel.org got hacked?
> >
> > But I am guessing I probably still have a local copy somewhere that
> > could be used to repopulate if anyone really cared about that old stuff.
> If you still have access to those old versions, I'd appreciate if you
> would let me know, anything helps!

I've restored it so that the links in the above post should be working
again as they did five years ago.

http://git.kernel.org/cgit/linux/kernel/git/paulg/rt-patches.git

> 
> Just out of curiosity: Do you still remember how long it took you to
> linearize those stacks? As I already mentioned, I gave up after a few
> hours .-)

I don't really recall exactly, but feel free to mine into the git repo
to look at the start commit date and go from there.  Pretty sure the
unit of measure will be in "days" and not "hours"...

Paul.
--

> 
> Cheers
>   Ralf
> >
> > I don't recall if I implicitly made a 2.6.31 series in the march forward to
> > the 2.6.33 but since 31 didn't have merges (aside from stable stuff)
> > that series would probably be reasonably easy to construct.
> >
> > Paul.
> > --
> >
> >> Thanks,
> >>
> >>         tglx
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> >> the body of a message to majordomo@vger.kernel.org
> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> -- 
> Ralf Ramsauer
> PGP: 0x8F10049B
> 
> 

Re: Old split quilt queues

[Ralf Ramsauer]

Hi Paul,

thank you very much!

  Ralf

On 03/14/16 07:31, Paul Gortmaker wrote:
> [Re: Old split quilt queues] On 07/03/2016 (Mon 12:15) Ralf Ramsauer wrote:
>
>> Hi Paul,
>>
>> On 03/07/16 04:42, Paul Gortmaker wrote:
>>> On Fri, Jan 29, 2016 at 2:56 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
>>>> On Fri, 29 Jan 2016, Ralf Ramsauer wrote:
>>>>> As I expected, inside that repo are a lot of tags for the various -rt
>>>>> versions.
>>>>> First I thought, RT would make use of rebasing, like:
>>>>>   - Rebase onto the next kernel version and drop unnecessary commits
>>>>> (e.g. patches that went upstream)
>>>>>   - Do some additional changes
>>>>>   - Export vA.B.C...vA.B.C-rtX as split quilt queue
>>>>>
>>>>> But afaict, (at least on the old rt-history), you made a lot of merges
>>>>> from rt/* branches and added tags describing the -rt version. Then you
>>>>> went on merging against master in order to keep up with upstream.
>>>>>
>>>>> Given that, how do you create a split quilt queue, that applies against
>>>>> an upstream tag?
>>>>>
>>>>> For example, let's take the first RT Tag of rt-history: v2.6.31-rc6-rt2
>>>>> How would you create a split quilt queue, that applies against v2.6.31-rc6?
>>>>>
>>>>> (I need to extract all those split quilt queues RT version<->base
>>>>> upstream version)
>>>> As I said before: That was an experiment whether git is usable as a tool to
>>>> manage something complex as rt. It turned out, that it's not. I recreated a
>>>> new quilt queue after I abondoned git for rt.
>>>>
>>>> So creating split queues is going to be a very interesting and tedious
>>>> detective work.
>>> Just stumbled upon this older discussion now by happenstance.
>>>
>>> I can say with experience that it is exactly that:  tedious.
>> I bet!
>>> 2.6.33 split queue:
>>>
>>> http://www.spinics.net/lists/linux-rt-users/msg06310.html
>>>
>>> 2.6.34 split queue:
>>>
>>> http://permalink.gmane.org/gmane.linux.kernel/1109036
>> Oh my god, that must have been some agonizing days back in 2011 :-)
>>
>> I tried the same, but eventually stopped linearizing the patch stack
>> after a few hours as there was no real chance of fast success...
> Yeah, it is not something you are going to bang out in a couple of
> hours.
>
>>> The repo I referenced in the above doesn't seem to exist anymore
>>> on kernel.org - although I don't explicitly recall deleting it.  Maybe
>>> that was fallout from when kernel.org got hacked?
>>>
>>> But I am guessing I probably still have a local copy somewhere that
>>> could be used to repopulate if anyone really cared about that old stuff.
>> If you still have access to those old versions, I'd appreciate if you
>> would let me know, anything helps!
> I've restored it so that the links in the above post should be working
> again as they did five years ago.
>
> http://git.kernel.org/cgit/linux/kernel/git/paulg/rt-patches.git
>
>> Just out of curiosity: Do you still remember how long it took you to
>> linearize those stacks? As I already mentioned, I gave up after a few
>> hours .-)
> I don't really recall exactly, but feel free to mine into the git repo
> to look at the start commit date and go from there.  Pretty sure the
> unit of measure will be in "days" and not "hours"...
>
> Paul.
> --
>
>> Cheers
>>   Ralf
>>> I don't recall if I implicitly made a 2.6.31 series in the march forward to
>>> the 2.6.33 but since 31 didn't have merges (aside from stable stuff)
>>> that series would probably be reasonably easy to construct.
>>>
>>> Paul.
>>> --
>>>
>>>> Thanks,
>>>>
>>>>         tglx
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> -- 
>> Ralf Ramsauer
>> PGP: 0x8F10049B
>>
>>

-- 
Ralf Ramsauer
PGP: 0x8F10049B