Since Linus does not do pre-patches anymore, he mentioned some time ago
it would be nice if somebody created an automated BK snapshot process to
make BK changes accessible between kernel releases. I've done that.
ftp://ftp.kernel.org/pub/linux/kernel/people/jgarzik/snap/2.5/
All BK changes not in the current 2.5 kernel release will be posted at
this URL, in GNU patch form, on a daily basis. [snap happens at one
minute past midnight, California time] The full changelog log is also
extracted. Each time Linus releases a new kernel, the contents of this
directory will be wiped out.
Questions and comments welcome.
Jeff
Jeff Garzik wrote:
> Since Linus does not do pre-patches anymore, he mentioned some time ago
> it would be nice if somebody created an automated BK snapshot process to
> make BK changes accessible between kernel releases. I've done that.
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/jgarzik/snap/2.5/
Two more details:
* Just like a pre-patch, the Makefile EXTRAVERSION is hacked to indicate
"-bk1", "-bk2", etc.
* I'll be setting up a process like this for 2.4, too, at the request of
Marcelo
On Thu, 8 Aug 2002, Jeff Garzik wrote:
> Since Linus does not do pre-patches anymore, he mentioned some time ago
> it would be nice if somebody created an automated BK snapshot process to
> make BK changes accessible between kernel releases. I've done that.
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/jgarzik/snap/2.5/
> Questions and comments welcome.
Heh, I've had something vaguely like this on NL.linux.org:
ftp://ftp.nl.linux.org/pub/linux/bk2patch/
Every 3 hours it creates a unidiff between the latest
tagged version and the head of the bk tree, for both 2.5
and 2.4.
cheers,
Rik
--
http://www.linuxsymposium.org/2002/
"You're one of those condescending OLS attendants"
"Here's a nickle kid. Go buy yourself a real t-shirt"
http://www.surriel.com/ http://distro.conectiva.com/
Rik van Riel wrote:
> On Thu, 8 Aug 2002, Jeff Garzik wrote:
>
>
>>Since Linus does not do pre-patches anymore, he mentioned some time ago
>>it would be nice if somebody created an automated BK snapshot process to
>>make BK changes accessible between kernel releases. I've done that.
>>
>>ftp://ftp.kernel.org/pub/linux/kernel/people/jgarzik/snap/2.5/
>
>
>>Questions and comments welcome.
>
>
> Heh, I've had something vaguely like this on NL.linux.org:
>
> ftp://ftp.nl.linux.org/pub/linux/bk2patch/
>
> Every 3 hours it creates a unidiff between the latest
> tagged version and the head of the bk tree, for both 2.5
> and 2.4.
Just to forestall other private responses [already gotten two], mine is
slightly different than your's, and David Woodhouse's setup. My goal
was basically to create a daily pre-patch, complete with hacked
EXTRAVERSION. That's something that is familiar to testers (pre-patch
form), and the snapshot is not so often that people will get buried in a
flurry of patches and csets. can you say "2.5.30-bk439" ;-)
So I consider my dailies as a complement to your bk2patch and dwmw2's
output, not redundant. Programmers would probably find dwmw2's per-cset
patches to be more useful, while testers and power users, and maybe
maintainers, would prefer daily pre-patches to test and sync against.
Jeff
H. Peter Anvin wrote:
>>Jeff Garzik wrote:
>>
>>>Since Linus does not do pre-patches anymore, he mentioned some time ago
>>>it would be nice if somebody created an automated BK snapshot process to
>>>make BK changes accessible between kernel releases. I've done that.
>>>
>>>ftp://ftp.kernel.org/pub/linux/kernel/people/jgarzik/snap/2.5/
> Could we please settle on a directory that isn't in a people/
> directory, such as /pub/linux/kernel/v*/snapshot?
>
> I can create those directories and chown them to you.
I would like to test it for a while and see if Linus objects, before
doing so...
Jeff
I probably won't be using this since my scripts already do a nightly
pull, but I'd also like to see what people think of this. I have a
setup that does a nightly pull of 2.5, builds it for UP and SMP, pushes
to two machines (UP and SMP) and runs LTP on it. Then sends me back the
results of all of it. Of course if something fails that didn't fail the
previous day, I have a limited set of Changesets as culprits so it's
easier for me to find the cause of problems when I do more frequent
testing like this. Any major problems are reported immediatly of
course, but would anyone be interested in seeing the results of this
more often? I don't know if I have enough space on the LTP website to
post all the data that's gathered every single day (It would add up
REALLY fast), but would a weekly rollup to lkml be something people
would like to see?
Thanks,
Paul Larson
On Fri, Aug 09, 2002 at 09:36:17AM -0500, Paul Larson wrote:
> previous day, I have a limited set of Changesets as culprits so it's
> easier for me to find the cause of problems when I do more frequent
> testing like this.
By the way, if you look at Documentation/BUG-HUNTING which describes how
to do binary search to track down bugs, you'll notice you can now do the
same thing with BK at a much finer granularity. It's possible to track
down bugs to the changeset which caused the bug, rather than the release.
Which is what Paul is talking about, but he's talking about doing it over
a small set of csets. You can do it over a large set of csets as well.
File this away as a thing you can do and if you ever need the details,
contact me and I'll walk you through it if it isn't obvious.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
> I probably won't be using this since my scripts already do a nightly
> pull, but I'd also like to see what people think of this. I have a
> setup that does a nightly pull of 2.5, builds it for UP and SMP, pushes
> to two machines (UP and SMP) and runs LTP on it. Then sends me back the
> results of all of it. Of course if something fails that didn't fail the
> previous day, I have a limited set of Changesets as culprits so it's
> easier for me to find the cause of problems when I do more frequent
> testing like this. Any major problems are reported immediatly of
> course, but would anyone be interested in seeing the results of this
> more often? I don't know if I have enough space on the LTP website to
> post all the data that's gathered every single day (It would add up
> REALLY fast), but would a weekly rollup to lkml be something people
> would like to see?
Personally, I'd love to see the *changes* in what passed and failed
posted every day - the whole result set is obviously too big. The
quicker people know what's wrong, the quicker it gets fixed, before
we build more on top of an unstable foundation.
M.
> Personally, I'd love to see the *changes* in what passed and failed
> posted every day - the whole result set is obviously too big. The
> quicker people know what's wrong, the quicker it gets fixed, before
> we build more on top of an unstable foundation.
I really like "fix it before we build on an unstable foundation".
It seems to me that we could get to something like tinderbox (? One of the
mozilla tools). What I'm imagining is something like a web page which
has a set of links in which point at the csets which cause the problem.
In order to make this work, we need to fix BK/Web to talk URLs with
"keys" instead of revs because, as some of you have noticed, revs change
when there is parallel development which makes the URLs pretty useless
if they contain revs.
If you need that fix in order to be able to have a list of URLs pointing
int BK/Web on bkbits.net, bug me about it, we'll do it right away.
I like the idea of having a status page which says "these changesets
cause problems". You can have two links, one which gets you to the BK
cset html and the other which gets the patch corresponding to the cset.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Fri, 2002-08-09 at 10:19, Martin J. Bligh wrote:
> Personally, I'd love to see the *changes* in what passed and failed
> posted every day - the whole result set is obviously too big. The
> quicker people know what's wrong, the quicker it gets fixed, before
> we build more on top of an unstable foundation.
Right, that's the plan. If something changes from one day to the next,
then it will be submitted immediatly. Right now I'm in that stage of
building a "stable" foundation. It could probably use some tweaking to
the .config and other things to introduce a higher likelyhood of finding
problems from one day to the next, but I don't want to be constantly
just finding things that everyone is already aware of. Any suggestions
wrt this are welcome.
-Paul Larson