Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27

[Conan Kudo (ニール・ゴンパ)]

On Thu, Nov 8, 2012 at 4:55 AM, Adam Williamson <awilliam at redhat.com> wrote:

> On Thu, 2012-11-08 at 05:44 -0500, Jaroslav Reznik wrote:
> > ----- Original Message -----
> > > On Thu, 2012-11-08 at 06:31 +0100, Kevin Kofler wrote:
> > > > Adam Williamson wrote:
> > > > > The new anaconda UI and related features are more or less
> > > > > entirely the
> > > > > cause of the slip.
> > > >
> > > > This shows that those changes should not have been done, or at
> > > > least not in
> > > > this way.
> > >
> > > I think it's widely agreed by now that they could have been done
> > > better,
> > > the question is now exactly how we can improve the process.
> >
> > We have bigger issue with features that are OUT OF the process,
> > not communicated at all. If you take a look on New Installer UI,
> > it fits current design, it was a late as the scope was bigger
> > than Anaconda team thought but it's there.
> >
> > But the new upgrade process - it should be standalone feature,
> > we missed dracut feature, same for LVM in Anaconda (again, not
> > UI), live medias etc. So most of the problems were caused not by
> > proposed/accepted features but by real features we weren't aware of.
> >
> > How to avoid it? Honestly I don't know.
>
> Well, a more stringent review process for the New UI feature would
> likely have identified this problem ahead of time.
> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
> http://www.happyassassin.net
>
> --
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>

My problem isn't that the cycles are longer, it's that Fedora as a project
hasn't gotten better at scheduling releases.

I know that over the years, Anaconda has been rewritten at nearly all
levels, and that the UI part is pretty much one of the few things left from
the older codebase. With the experience that the Fedora team has and that
Red Hat has with developing UI code in Python, I'm still surprised that
estimating the challenges of rewriting the UI and beating it into shape for
release wasn't fully possible.

I know that software development is hard. Software Engineering is an
extremely difficult process. I just thought that with all the wonderful,
experienced people here, Fedora as a whole would have had a better idea of
how *hard* this would be and properly account for it.

The other problem is that it continues to make Fedora as a project look
bad. I've talked to people who use Fedora (who aren't involved in the
project in any form or fashion), and it's a rather annoying pain point that
they *don't know when to expect the next Fedora release*. The fact that
we've cultivated that expectation is highly disappointing for a project
that does the traditional biannual stable release model. It's a pretty
large motivator to keep talking about moving to the rolling release model.
And yes, I've read all the threads, and I know all the reasons.

Regardless of all that, we need to be better about communicating that we
use a feature-based release scheme as opposed to a time-based release
scheme. There are trade-offs to both approaches, but at least with clear
communication, we set the right expectations.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20121108/6c03204a/attachment.html>