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
