On 11/05/2012 09:39 AM, drago01 wrote:
On Mon, Nov 5, 2012 at 5:57 AM, Dennis Gilmore <dennis@xxxxxxxx> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
El Wed, 31 Oct 2012 10:59:54 -0700
Jesse Keating <jkeating@xxxxxxxxxxxxxxx> 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.
If/when the "real work" behind a feature has been done early enough,
getting from Fedora alpha to final consists of just a few bugfixes that
can only be found with sufficiently large test-audience. That's very
different from the way things some things land: known very incomplete
work submitted at very last minute, followed by a mad scramble to try
and scrape it to somehow acceptable state in time. It's avoidable by
simply resisting the urge to slip stuff in on the last minute, the
release cycle is short enough that world does not end if you postpone
something to the next 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.
No disagreement there - features with no feasible contingency plan
should be treated very cautiously and if accepted anyway, should have
stricter completeness-requirements and much earlier deadlines than
easily reversible things.
- Panu -
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
