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

[Aleksandar Kurtakov]

----- Original Message -----
> From: "drago01" <drago01 at gmail.com>
> To: "Development discussions related to Fedora" <devel at lists.fedoraproject.org>
> Sent: Monday, November 5, 2012 9:39:54 AM
> Subject: Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how	to install into a LVM partitions (or
> RAID))
> 
> On Mon, Nov 5, 2012 at 5:57 AM, Dennis Gilmore <dennis at ausil.us>
> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > El Wed, 31 Oct 2012 10:59:54 -0700
> > Jesse Keating <jkeating at j2solutions.net> escribió:
> >> On 10/31/2012 09:56 AM, Toshio Kuratomi wrote:
> >> > * 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.
> >>
> >> I'm not entirely sure what I felt then, but I'm certainly open to
> >> a
> >> longer release cycle.  In fact I'm very much in favor of one, one
> >> that puts more time between "feature complete" and the actual
> >> alpha
> >> release. All too often we see features crash land right at the
> >> deadline, and any software that has to integrate across a lot of
> >> pieces (like anaconda) gets stuck trying to account for all these
> >> changes in a very limited time frame, only to be hindered quickly
> >> by
> >> a freeze process.
> >
> > I really do not object to a longer release cycle.  I am also open
> > to
> > making feature freeze being 4-6 weeks before Alpha change freeze.
> > The
> > risk we run is people land new features anyway. but we run that
> > today.
> > We always have a run of things late. People need to land changes
> > earlier  the bigger the change the earlier it needs to land.  Maybe
> > it
> > wont be a popular idea but having feature freeze at previous
> > release
> > time is needed. What I am thinking is:
> >
> > Branch as we do, which opens up development for next release same
> > as
> > we do today, so in the current cycle when we branched off f18, f19
> > features needed to start landing so all that would be taken for f18
> > is
> > bug fix and integration fixes.  when we release f18 we hit F19
> > feature
> > freeze.
> 
> That does not work because we do not have unlimited resources ... you
> can't expect people to work on F19 features at the same time while
> they are trying to get F18 ready for release.
> Honestly I don't think that the current issues have anything to do
> with the schedule but more with the way we handled the anaconda
> feature. We should just fix that and not try to make random changes
> all over the place.
> 
> Basically there should not be any "this cannot be reverted" (there is
> no such thing really) features. If it is evident before the feature
> freeze that a given feature would not be ready in time we have to
> punt
> it to the next release PERIOD.

Looks like this issue comes to every project(pretty similar thing happened in Eclipse for 4.x). What happens if Anaconda devs say they can no long maintain the old version and they will spend all their time on the new one? Will there some magic happen and someone else will step in to do the changes in anaconda for the new dracut (mentioned in the thread)? Or we will revert dracut and systemd and etc. to their f17 version making no point in even having new release maybe?
I agree we fail but sometimes you can not just revert and the better idea looks like when some such low level changes happen it is better to just accept it and make the release a bit longer from the beginning.

Alexander Kurtakov

> --
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel