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[1], 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:
32M experimental
1.9G lenny
4.0M lenny-proposed-updates
3.3G sid
401M squeeze
2.0M squeeze-proposed-updates
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 ==
good).
(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)
--
bye, Joerg
"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."
Reply to: