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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Nov 8, 2012 at 4:55 AM, Adam Williamson <awilliam@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx
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.
-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux