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
customer").
IMO, Fedora has obvious problems with its
- work-flow (Too immature SW migrates/sneaks through from Alpha/Beta to
Final)
- 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.
Ralf
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
