Announce: daily 2.5 BK snapshots

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

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

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/

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

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

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 

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.

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 

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

I would like to test it for a while and see if Linus objects, before doing so...

Jeff