Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <awilliam@xxxxxxxxxx> 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 [1], 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
develop Fedora.

https://fedoraproject.org/wiki/No_Frozen_Rawhide_Proposal#Problem_Space
"""
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
release
"""

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
    solutions
    + 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:
https://fedoraproject.org/wiki/Features/Policy/Milestones#Feature_Freeze

"""
Feature Freeze

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.

-Toshio

Attachment: pgpgl9sfovT_q.pgp
Description: PGP signature

-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux