Ralf Corsepius rc040203 at freenet.de
Thu Feb 9 16:57:14 UTC 2012

On 02/09/2012 01:36 AM, Jesse Keating wrote:
> On 2/8/12 4:30 PM, Reindl Harald wrote:
>> it is a very good idea because the overall quality of fedora would
>> be improved if there would be a larger release-blocking to get
>> the big changes fixed BEFORE alpha and in the meantime not involved
>> maintainers could proceed fixing the tons of small bugs and polish
>> the distribution at all - there are really neough rough corners
>> involved in the last releases to work on that there is no need
>> to proceed this way of releasing and starting alpha/beta with
>> known broken things
> The entire point of having alpha/beta releases is to get wide testing
> without having everything "perfect". If it were perfect, it'd be the
> release. So you have relaxed requirements for earlier stages of the
> release.
> In this case, anaconda upgrades is not a required functionality for the
> Alpha release. It is required however for Beta. We can go ahead with
> Alpha and get wider testing on everything else, while anaconda team and
> others work on the upgrade issue, and hope to have it fixed by Beta time.
> This is how software development works.
Well, no disagreement wrt. alpha/beta, but the problem is when software 
development derails into "banana software deployment" ("ripes at the 

IMO, Fedora has obvious problems with its
- work-flow (Too immature SW migrates/sneaks through from Alpha/Beta to 
- management, whom seems to be driven by a "must have at any price, no 
point of return ever" policy.

That said, observing the usrmove stuff killing yum updates in rawhide 
mock-buildroots at present time is not much of a problem to me, but it 
doing the same with F16->F17 yum-upgrades releases will be a problem.


More information about the devel mailing list