On Thu, 2010-03-04 at 15:53 -0500, Toshio Kuratomi wrote: > > I'm not particularly sold on the definition in the freeze policy, and > > honestly I suspect it's been honored much more in the breach than in the > > observance. I'd be very surprised if all planned features of a given > > release have ever been fully 'testable' in our Alpha releases. Frankly, > > that seems like an unrealistic goal given the timescales we work with, > > depending what definition of 'testable' you want to take (there's a huge > > amount of wiggle room in that word). > > > We should change or refine the Freeze Policy page then. Having different > definitions of what is required for alpha to go out and what can go in after > alpha leads to incorrect expectations on the part of developers. I agree. I think probably all we need to do is remove the weasel-word 'testable' and give a more solid definition there. > > To give a practical example, if 'KDE X.Y with shiny new IM client' is > > listed as a feature for the Alpha, we'd say the freeze policy requires > > the new IM client should actually be present in the Alpha package set. > > But we wouldn't say the release should be blocked if there's a bug which > > causes it to fail to launch, even though this arguably makes it 'not > > testable'. The theory is that there's no point holding the Alpha release > > to fix something we can fix equally well in post-Alpha updates, since > > there's no net benefit to anyone. But we should probably discuss this in > > more detail. > > > Big +1 to that. I don't care too much what the criteria is as long as its > consistent and doesn't put package maintainers in an impossible position wrt > getting their development done and into the next release. OK, cool. How do you want to move this forward? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
