[Test-Announce] Fedora 15 Alpha TC2 Available Now!

[James Laska]

On Wed, 2011-02-16 at 11:43 -0400, Clyde E. Kunkel wrote:
> On 02/16/2011 10:25 AM, James Laska wrote:
> > On Wed, 2011-02-16 at 08:52 -0500, Clyde E. Kunkel wrote:
> >> On 02/16/2011 12:25 AM, Adam Williamson wrote:
> >>> On Tue, 2011-02-15 at 21:45 -0500, Clyde E. Kunkel wrote:
> >>>> On 02/15/2011 09:06 PM, Adam Williamson wrote:
> >>>>> On Tue, 2011-02-15 at 23:30 +0100, Michał Piotrowski wrote:
> >>>>>> <snip>
> >>>>>> that lettel "ł" caused it. Second issue - I don't have a "restart"
> >>>>>
> >>>>> We definitely need reports on such 'odd' (i.e. not US ASCII...)
> >>>>> character set issues, i18n issues etc - can you double-check it and file
> >>>>> the issue if it's reproducible? Thanks.
> >>>>>
> >>>>>> option in Gnome menu.
> >>>>>
> >>>>> That is a, ahem, policy decision.
> >>>>
> >>>> Hi, Adam,
> >>>>
> >>>> Could you say some more about the policy decision or point to a msg or
> >>>> whatever.  Need to understand what is going on.
> >>>
> >>> It was discussed during the Test Day. I don't have a web reference for
> >>> this exact issue, but the position of the design team is that they think
> >>> the only common use case for rebooting is to boot into a different
> >>> operating system in a multi-boot configuration, and they want to handle
> >>> that as a special case somehow (a direct 'reboot to Windows' option has
> >>> been suggested). They don't believe there are any sufficiently common
> >>> use cases for rebooting other than that one to justify the added
> >>> complexity of providing it as an option. (Desktop team, please correct
> >>> me if I'm representing this wrong).
> >>
> >> Well, I reboot after every kernel update, every time there are numerous
> >> updates from the repos, when debugging and testing changes to gdm,
> >> dracut, systemd, networking, and on-and-on.
> >>
> >> I am somehow now reminded of the early days of software design (I go
> >> back to second gen mainframes) when we sat in a room and designed
> >> software the way we thought it should be and then cursed the users who
> >> complained it wasn't the way they wanted it.  Heaven forbid that we even
> >> considered an upfront requirements definition phase that included the
> >> user community.  Of course, we blamed users for the additional costs
> >> involved in "correcting" errors late in the projects and after they were
> >> implemented.
> >>
> >> I am optimistic, however, since the Fedora project seems to always,
> >> somehow, make the right, even unpopular, decisions concerning features.
> >> I.e., deferring systemd to F15 late in the F14 cycle.
> >>
> >> I suppose gnome is too far down the path now to consider deferring it to
> >> F16?  Is it even possible?
> >
> > Development has been going on for some time now, so it would be a shame
> > for GNOME3 to miss Fedora 15.  The desktop team has set the bar in terms
> > of expected functionality and criteria for a successful GNOME3.0 +
> > Fedora 15 release.
> >
> > https://fedoraproject.org/wiki/Features/Gnome3#Scope
> >
> > QA is positioned well to provide feedback against the goals listed
> > above, by way of bugs and flame-free discussion, around those goals.
> >
> > Thanks,
> > James
> >
> 
> Not a flame.  Just frustration.  At least some discussion is now 
> underway and folks are expressing opinions.

Doh, sorry Clyde.  I didn't take your mail that way, or mean to imply it
was.  Just doing my best to encourage positive discussion on the
topic! :)


> Reminds me of the marketing folks during my business life:  "Tell
> them 
> three times what you want them to know.  Then keep telling them until 
> they buy."  Of course, your product has to work. :-)

I recall those same words in the context of public speaking.  So true :)

Thanks,
James
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/test/attachments/20110216/1ed39120/attachment.bin