Hello all!
My comments to several mails are the following:
Bob Tarling wrote:
> I do think we need a longer period of verification before we go live
> and also give beta testers more time to find high priority bugs. The
> 7th would be long enough I should think.
OK. Yes, that is a better idea.
> How shall we okay whether fixes can be applied in Linus absence?
I think it is best if I just appoint someone to this responsibility
(Either Bob or Tom). That person will then make decisions on the risk
against benefit scale.
> I suggest we still post patches for peer review. P1/P2 issues should
> be commited if any peer agrees.
I think it is better if one person does this instead of any peer. The
peer reviews should go on to the same extent as usual but those are for
correctness, not for risk/benefit decisions.
Tom Morris wrote:
> This release was planned for May 15 (not the "original planned date"
of
> July 21 that's on the web page).
Sorry about that. I thought there were something wrong but didn't
bother. I have fixed this.
> A beta on Aug. 8 would imply a release date of Aug. 15 or
> later. That's a 3 month slip on a 3 month schedule -- 100%!
This is alarming but not very surprising. In order, not to do this
again, I would like us to reconsider the concept of releases, stable
releases and alpha/beta periods after 0.22 is completed. I think we need
something new but I don't really know what that would be.
> We seem to have lost our focus on making this a quick turnaround
> release to fix critical problems in 0.20. My impression is that
> many (most? all?) of these late breaking problems are bugs that
> we introduced during this development cycle.
I agree. This was unfortunate. This also made the alpha/beta period a
lot longer because of all problems.
> I would like to see the next beta be our last.
I don't think it is necessary to reduce the number of betas for any
reason. The most important thing is the stability and quality and if
that is best achieved with an extra beta, so be it.
> This means we've got to be 100% focused on stability.
I agree, stability and quality is the most important thing.
> One other schedule thing - it makes most sense to me to do the SVN
upgrade
> at a release boundary. Is there a reason that we have it scheduled
for
> partway through the next development cycle? Can we move it to
immediately
> after the 0.22 release?
I set the date for the SVN change not to disturb the summer of code
work. Yesterday I added the releases around it because with the 0.22 so
late, at this date we have not reached very far into the 0.23 cycle
anyway.
I can think of one important reason, not to have it immediately after
0.22 and that is if we decide to do a 0.22.1 release immediately after
0.22 to fix some serious late found bug. In that case, it is convenient
not to be in the middle of a lot of infrastructure changes. On the other
hand, I would prefer to do the change in the beginning of a cycle. The
reason for having a pair of releases scheduled just before and
immediately after the change to SVN was to make it easier to pinpoint
problems introduced by the change. I made the same thing when we did
re-indentation of all of the code.
Tom wrote:
> A beta on Aug. 8 would imply a release date of Aug. 15 or later.
Bob wrote:
> I do think we need a longer period of verification before we
> go live and also give beta testers more time to find high
> priority bugs. The 7th would be long enough I should think.
Michiel wrote:
> it is important that 0.22 is released ASAP.
Let me suggest one beta next week, one beta on the 7th and then the
stable release just after that (sometimes between the 10th and the
15th).
Is that a good idea?
/Linus
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
