Bernhard Rozenkränzer (bero), coordinator of the distribution development, answered him.
Q (N.P.): So, back to the distribution, where are we now? Could we have an updated schedule? Not something like “we’re doing QA [Quality Assurance]” or “we did an alpha-beta-whatever” some months ago, but a real schedule for the month to come.
A (Bero): thanks for bringing up [this] topic.
The problem there is that we’re currently blocked by more or less external matters that should be resolved soon, but we have no way to know when exactly.
We’re planning to make a beta release as soon as possible, but in order to do that right (e.g. push in packages identifying it as a release and telling it to update from 2013.0 directories rather than cooker), we need a release branch on ABF.
Once we get that, we have to build a few packages there (anything related to updating), then we can build an iso and pass it to QA for testing. Building the beta candidate iso once we have the release branch should take less than a day.
This should take around 3 days, but there might be further delays if QA actually finds showstoppers that need to be fixed before we go beta.
Then we’ll have to give QA some time to find potential showstoppers, push the beta out to mirrors, get bug reports from the public, and fix relevant bugs reported.
Since we’ve had an extremely long alpha cycle, I’d think we can get by with just 1 beta release and a 3 week beta cycle, but we may decide to prolong it and make more beta releases if people find serious bugs that take longer to fix.
After that, we build another (RC) iso, push it to QA, allow them a bit of time to test, push it out to the public and wait for more bug reports/fix bugs.
This should take 2 weeks unless we run into serious bugs that take longer to fix.
After that, it’s building another (hopefully final) iso, push it to QA, get green light, push it out, and un-freeze cooker.
Q: What are the current blocking points?
A: Main blocker right now is not having the release branch on ABF.
Other known things that we need to fix:
- fix remaining mass build failures (fortunately there’s not that many)
- replace remaining Mandriva branding/artwork
- make sure the infrastructure (including mirrors, download pages, relevant code such as urpmi) is ready to handle releases and updates from release branches
- go through the reports on bugzilla, sort out which ones are relevant for the release, fix them
Q: What is the deadline to work on them?
A: Deadline for work that should go even into the beta (given we’re hard-frozen, only bugfixes allowed even now – but exceptions can be discussed here, the libreoffice 4.1 update has already been approved): Until the release branch is created on ABF. (Yes, that’s not a real date, but that’s when we’re planning to cut the beta release.)
Q: What are the different RC versions to expect, and especially what would be the date for each of these?
A: – Beta release: 2-3 days after this, unless QA finds showstoppers that can’t be fixed in this timeframe.
If we find enough serious problems to decide we need a second beta (I hope this won’t be necessary since we’ve already been delayed more than enough and we’ve had a long alpha cycle):
- Beta 2 release: Around 3 weeks later
- RC release: Around 3 weeks later unless public testing finds showstoppers that can’t be fixed in this timeframe.
- Final release: Around 2 weeks later unless public testing finds showstoppers that can’t be fixed in this timeframe.
I realize this is more vague than what you were hoping for — but it is impossible to set schedules in stone when we have no way to know what feedback we’ll get and we have no way to know for real how many contributors will be available for how much time to fix things. We’re not a company with any guaranteed availability of people.
Q: Some months ago, I could understand it could be difficult to have a precise view on this, because the association, servers, infrastructure… needed to be set up, but now, where are we?
A: All the setup is essentially done (with a bit of a problem remaining on the ABF (build system) side — we have no way to create release branches without semi-external help).
Cooker is usable and in pretty good shape. It is still difficult to have any precise schedules — and this is unlikely to change anytime soon, there’s simply no way to guarantee some delivery date if the number of contributors is small enough for 1 “missing person” to matter, and there’s 0 guaranteed availability. We’re a community project now — with all the advantages it brings, but also the few disadvantages it brings (no full-time developers with guaranteed availability).
Note from bero: things have improved since this answer (the ABF issue is resolved), so there’s a pretty good chance we can actually stick to this timeline. Of course we still have to make room for the possibility that there will be showstopper bugs that simply take longer than expected to fix, so don’t take this as a 100% promise.
image credit: Penguin looking at the moon http://disney.go.com/create/art/2gs11k6YoEjb00001004x4w0-h-3a10fc