Re: Constantly Usable Testing BoF @ DebConf10
> I'd like to invite any Release and FTP team members who are attending
> DebConf to the Constantly Usable Testing BoF, Tuesday at 10:30 am.
Im not sure I can attend this using the stream, maybe, we will see.
But twerner is around in NYC, he might attend it.
> The purpose of the BoF is to finally explore whether it would make sense
> to implement the Constantly Usable Testing idea, ways to do it, and
> get feedback and advice from teams that could be affected by it.
> So it would be great to have some dak and britney wranglers to give advice
> on topics like:
> * Snapshotting testing.
> * How to support upgrades from old testing snapshots to current testing?
> * Installability/usability of testing. Issues like important packages
> being temporarily removed due to RC bugs.
> * Does testing get enough testing? Would having users use CUT improve
> that and help the quality of stable releases, or the opposite?
For dak side - it is not too hard to add another suite, exported to the
public or not. What bothers most is the size of a dists/ dir:
If we copy testing as is, then thats another 400mb hit there on index
files that regularly change. Can we go without contents files?
Thats already 200mb. (The pure size isn't a problem, in a tree that has
hundreds of gigs, but dists/ is what changes a lot, compared to files in
pool/ and that gets a good part of traffic on the mirrors. And our
snapshot archive also has to store all the indexes... Having less ==
(And if we can also start this suite not having any bz2 index
files, that would be doubly good. They are a pure waste of space, gzip
is so much better for our mirrors (--rsyncable does gain a lot)).
Also, technically, ftpmaster doesnt want to have to do much with the
suite: We run the service, someone else does the work :)
That is, we would want a team that has the say about it and that
supplies us with an input file that defines how the suite has to
look. Once, twice or four times a day. (That will be "Heidi" Format then)
What will be the rules for the versions in CUT? It will definitely be >=
stable. Also, I think <= unstable. No specific relation with testing?
Though I think it should be somewhere <= testing and every update should
go via testing first, it could be wanted to directly get a new version
from unstable to CUT, while britney not yet let that migrate to testing.
Especially if it ends up being 2 processes that define how testing/cut look.
How about the testing-proposed-update suite and the relations there?
Does this suite also need a p-u one? (I dont think so)
"That's just f***ing great, now the bar for being a cool guy in free
software just got raised. It used to be you just had to write a million
lines of useful code. Now you've got to get a subpoena from SCO to be cool."