|| ||Toshio Kuratomi <a.badger-AT-gmail.com> |
|| ||Development discussions related to Fedora <devel-AT-lists.fedoraproject.org> |
|| ||Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how
to install into a LVM partitions (or RAID)) |
|| ||Wed, 31 Oct 2012 09:56:24 -0700|
|| ||Article, Thread
On Wed, Oct 31, 2012 at 10:27:09AM +0100, Vratislav Podzimek wrote:
> On Tue, 2012-10-30 at 19:32 +0100, Gianluca Sforna wrote:
> > On Tue, Oct 30, 2012 at 7:12 PM, Adam Williamson <firstname.lastname@example.org> wrote:
> > > I'd recommend asking dcantrell, as he has some good points on this
> > > topic. I broadly agree with him that it might well be more or less
> > > impossible to smoothly handle a major rewrite of anaconda in our current
> > > development process. CCing to make sure he sees this.
> > If you are saying that 6 months are a too short time for something
> > like this I think I can understand it.
> 6 months are a too short time. And it was less than 6 months. As can be
> seen from the F18 release schedule , originally it was about 3 months
> between the day F17 was released and the day new Anaconda was expected
> to work (F18 Alpha release). We of course didn't start the work on May
> 29, but since there were significant changes in F17 too at least part of
> the team had to fix bugs and make F17 releasable.
There's a mismatch between this practice and the theory of how we
We also tell folks that a development cycle of Fedora starts from the branch
point of the release to be and goes all the way to the release of the next
The theory of developing Fedora is that development starts when we branch
rawhide from Fedora-Next. For the F18 cycle, this was January or February
2012. So the theory is that currently, there's been about 9 months for the
development of Anaconda for F18. There were 6-7 months up to Feature
Freeze when your feature was supposed to be implemented.
Now a couple comments based on both the practice and the theory:
* Many other contributors use the same practical development cycle as you
do rather than the theoretical one.
- We could decide this was okay and figure that the real development cycle
that we give people is only 3 months so how do we help people with that.
- We could decide that there's no way we can make two releases a year
(especially if we have to adjust for slips by absorbing the time in the
next cycle) and force people to start thinking of development starting
at branch time. One possibility here would be to freeze Next more. For
instance, from alpha-release, next would be frozen with only "approved"
changes going in.
* There's a lot of talk about focusing energies on getting the next release
out the door rather than developing for rawhide.
- This could be a perception thing. Since people are already running
behind with when they started development, they're behind on finishing
it up at the end. I don't think this theory fits with human behaviour
- This could be a sign of lack of manpower to both make releases and
do big feature development within some teams. This has several possible
+ Don't do big feature development
+ Add more manpower
+ Remove some of the burden on them -- for instance, if dracut would
require big anaconda changes dracut becomes responsible for providing
the manpower to adjust to the change.
- This could just mean that people care more about the release that is due
out really soon rather than the one that's due out in 6+ months.
* Jesse Keating, Jeremy Katz, and others who helped shape the current policy
and theory of our release schedule felt that the 6 month release cycle was
fine but that certain features were going to take longer to develop.
Those would need to be developed and not enter into Fedora until they were
close enough that they could be completed during that cycle.
- No matter what we do to try and increase the development cycle within
a release, there's always going to be issues that take longer than the
release that we need to deal with. Perhaps, we just need to be better
about making people follow this model.
> Also Alpha is not
> supposed to be 100% feature complete, but it seemed to me that not
> everybody was taking this into account.
Here you're treading on a very thin grey line:
New features must be feature complete or close enough to completion by
Feature Freeze so that a majority of its functionality can be tested during
the Alpha and Beta releases.
At this point in the cycle, we should be Feature Complete and Testable. The
Fedora Alpha release is like a Beta release in more traditional software
development release cycles.... we're supposeed to just be squashing bugs
from here on out.
devel mailing list
to post comments)