FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 03-04-2010, 07:53 PM
Toshio Kuratomi
 
Default Fedora 13 Alpha Go/No-Go Meeting: 2010-03-04 @ 01:00 UTC Recap

On Thu, Mar 04, 2010 at 12:01:42PM -0800, Adam Williamson wrote:
> On Thu, 2010-03-04 at 14:22 -0500, Toshio Kuratomi wrote:
> > On Thu, Mar 04, 2010 at 10:47:28AM -0800, Adam Williamson wrote:
> > > On Thu, 2010-03-04 at 14:17 +0100, Kevin Kofler wrote:
> > > > On one hand we have people complaining about the quality of updates, on the
> > > > other hand we're happily releasing crap we know is broken.
> > >
> > > It's an *alpha*. 'Crap we know is broken' is more or less the definition
> > > of alphas. =)
> > >
> > Just a clarification point:
> >
> > http://fedoraproject.org/wiki/Alpha_Freeze_Policy
> > # At Alpha Milestone, all packages should testable and feature
> > complete--whether they are "official features" of the release or not
> >
> > So broken, yes. But the extent of breakage is important. Breakage that
> > results in core components being untestable would seem to be blockers under
> > the current policy -- the result of discussing them would be whether to get
> > an update into the Alpha Release, revert the broken package, or simply ship
> > with the untestable piece documented and remember to add more extensive
> > testing for that at a later point in the cycle.
> >
> > (Pointing out since F-12 cycle we had people confused about what was
> > expected of the Alpha release).
>
> We have various different definitions of the Alpha, it seems. The
> working definition that QA / rel-eng have always worked on when deciding
> whether to ship it is, broadly, 'can you install it, boot it, get a
> network connection, and install updates'. That's what the current Alpha
> release criteria and validation tests aim to explicitly codify and
> verify.
>
> 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.

>
> 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.

-Toshio
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-04-2010, 08:05 PM
Adam Williamson
 
Default Fedora 13 Alpha Go/No-Go Meeting: 2010-03-04 @ 01:00 UTC Recap

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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-04-2010, 08:17 PM
Kevin Kofler
 
Default Fedora 13 Alpha Go/No-Go Meeting: 2010-03-04 @ 01:00 UTC Recap

James Laska wrote:
> To re-emphasize a point Adam made above, users of other desktop
> environments are strongly encouraged to participate in community test
> runs during release milestones. As it stands, we have one test result
> [1] from the a desktop environment other than GNOME.
>
> While it was explained that the release criteria do not pertain to all
> desktop environments for Fedora 13, it would really help to have a more
> complete picture of how the criteria might apply to other desktop
> environments. Without the data, it makes deciding whether to extend the
> release criteria to these environments a difficult decision.

The problem is that "please test this, but we will ignore the results" is
not the way to get people to do testing.

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-04-2010, 08:42 PM
Toshio Kuratomi
 
Default Fedora 13 Alpha Go/No-Go Meeting: 2010-03-04 @ 01:00 UTC Recap

On Thu, Mar 04, 2010 at 01:05:29PM -0800, Adam Williamson wrote:
> On Thu, 2010-03-04 at 15:53 -0500, Toshio Kuratomi wrote:
>
> > > 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?
>
I think Jesse was the creator of the Alpha Freeze Policy. So maybe it's
just something for releng and QA to hash out a definition of testable or
wording that better describes the current situation?

-Toshio
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-05-2010, 01:05 AM
Adam Williamson
 
Default Fedora 13 Alpha Go/No-Go Meeting: 2010-03-04 @ 01:00 UTC Recap

On Thu, 2010-03-04 at 22:17 +0100, Kevin Kofler wrote:
> James Laska wrote:
> > To re-emphasize a point Adam made above, users of other desktop
> > environments are strongly encouraged to participate in community test
> > runs during release milestones. As it stands, we have one test result
> > [1] from the a desktop environment other than GNOME.
> >
> > While it was explained that the release criteria do not pertain to all
> > desktop environments for Fedora 13, it would really help to have a more
> > complete picture of how the criteria might apply to other desktop
> > environments. Without the data, it makes deciding whether to extend the
> > release criteria to these environments a difficult decision.
>
> The problem is that "please test this, but we will ignore the results" is
> not the way to get people to do testing.

The tests don't solely exist for the purpose of deciding the release
go/no-go. If that were the case, we wouldn't do the Beta and Final tests
on the Alpha release, as we do.

The tests have other purposes: they alert us to breakages we may care
about for future release points, and they allow us to document
non-blocker problems. Although we did not commit to applying the
criteria in full to non-default desktops, as I explained when I asked
for the testing, we would consider extremely serious problems in
alternative desktops ('it doesn't boot') for blocker status, and we can
also document bugs exposed by the testing (as we have for the KDE update
issue). The intention is that it will also be useful simply as a way to
find bugs in desktops that ought to be fixed, regardless of the release
process.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-05-2010, 03:31 AM
Kevin Kofler
 
Default Fedora 13 Alpha Go/No-Go Meeting: 2010-03-04 @ 01:00 UTC Recap

Adam Williamson wrote:
> We have various different definitions of the Alpha, it seems. The
> working definition that QA / rel-eng have always worked on when deciding
> whether to ship it is, broadly, 'can you install it, boot it, get a
> network connection, and install updates'. That's what the current Alpha
> release criteria and validation tests aim to explicitly codify and
> verify.

But it also fails that definition and this was ignored just because it
didn't happen in the GNOME spin (which will always be the GNOME spin, not
the "desktop spin", but *A* desktop spin; FESCo, the Board or any other
committee deciding otherwise doesn't change this, it's like deciding that
apples are "fruit" and any other fruit can only be an "orange fruit", a
"pear fruit" etc., but not a "fruit" because only apples are that). :-/

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-05-2010, 03:32 AM
Kevin Kofler
 
Default Fedora 13 Alpha Go/No-Go Meeting: 2010-03-04 @ 01:00 UTC Recap

Adam Williamson wrote:
> On Thu, 2010-03-04 at 15:53 -0500, Toshio Kuratomi wrote:
>> 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.

Well, the Freeze Policy page is about targets feature owners should meet,
not about Alpha blockers.

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-05-2010, 07:51 AM
Richard Hughes
 
Default Fedora 13 Alpha Go/No-Go Meeting: 2010-03-04 @ 01:00 UTC Recap

On 4 March 2010 19:59, Kevin Kofler <kevin.kofler@chello.at> wrote:
> I think we
> really need to be more conservative about what version of our default
> updating tool we include in our releases (and in fact pushing PackageKit 0.6
> as a post-release enhancement update once the issues with it are resolved
> and there is an actual kpackagekit release to go with it, while shipping F13
> GA with 0.5, would probably have been much less disruptive).

PackageKit, as in the daemon has been pretty stable for ages.
PackageKit-glib2 has been stable up until recently, where we broke API
to fix a bug in a little-used piece of API (most applications,
including GPK, unaffected). PackageKit-qt has had wild changes, which
the QT and KDE guys said they needed to fix bugs in KPackageKit.
KPackageKit has a much smaller community base than GNOME PackageKit
(which is expected, it's a younger project) and so the developers only
have the resources and desire to work on git master, rather than
stable branches.

If you want to talk to anybody about stability, it's probably the
PackageKit-qt guys you need to talk to, and offer help. I'm pretty
sure the situation will get better over time, as the -qt library
settles down and the kpackagekit project gains momentum.

Richard.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-05-2010, 12:49 PM
James Laska
 
Default Fedora 13 Alpha Go/No-Go Meeting: 2010-03-04 @ 01:00 UTC Recap

On Thu, 2010-03-04 at 21:06 +0100, Kevin Kofler wrote:
> Adam Williamson wrote:
> > I did explicitly explain to you and the other desktop SIGs at the start
> > of the F13 cycle that, because we just hadn't had time to discuss all
> > the thorny implications of the question, the desktop criteria would be
> > considered only with regards to the default desktop. Which is GNOME.
>
> I don't think that makes sense. I didn't back then and still don't.
>
> > The desktop criteria and validation tests did not exist before F13. It's
> > extremely unlikely we would ever have blocked any previous Alpha release
> > because graphical updating failed in *any* desktop. This reflects a
> > tightening of our release quality standards, not a loosening. In future
> > I'd like to have all the major desktops (KDE, XFCE, LXDE) considered as
> > well as just GNOME, but doing so in F13 would have been premature.
>
> How would it have been premature to consider our 2 permanent spins equally?
> Our users expect the KDE spin to be working.

Kevin, I understand your frustration. Like everything, it's an
iterative process. Nothing comes out of the gate perfect. It takes
time to mature and develop into something everyone can be proud of.

At this point, my recommendation would be to follow the lead other spins
have done and actively engage the QA team to solicit testing against
your preferred spin. Help provide the data needed to support any
decision around extending the existing release criteria.

> > I'd hope it would be obvious I *do* care, since I took the trouble to go
> > around to you and the LXDE and XFCE SIGs and ask if you'd have time to
> > kindly help fill in the results tables. By the same token, as explained
> > above, I *did* explain that we're unfortunately not considering the
> > results as binding on the release schedule for F13. However, having the
> > results is very useful for us all to know where the release stands, for
> > us to document significant issues in CommonBugs (I'll document the KDE
> > update issue there), and to establish the process for future releases
> > where hopefully it can become binding.
>
> But why would I (or anybody else) be motivated to spend my time testing
> things when I was told upfront that the results would be ignored?

Quality isn't something you staff and hope they cover all your testing
needs. Quality practices are expected of everyone at all stages of the
process. In the QA team, we work to provide a framework and guidelines
so people interested in making a difference have an opportunity to
succeed. I can tell you are passionate about KDE. I hope we can find a
way to convert this energy into something actionable that will provide
more insight into how the release criteria apply to KDE.

Thanks,
James


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-05-2010, 01:04 PM
Kevin Kofler
 
Default Fedora 13 Alpha Go/No-Go Meeting: 2010-03-04 @ 01:00 UTC Recap

James Laska wrote:
> Quality isn't something you staff and hope they cover all your testing
> needs. Quality practices are expected of everyone at all stages of the
> process. In the QA team, we work to provide a framework and guidelines
> so people interested in making a difference have an opportunity to
> succeed. I can tell you are passionate about KDE. I hope we can find a
> way to convert this energy into something actionable that will provide
> more insight into how the release criteria apply to KDE.

How much "insight" do you need to figure out that if the updater doesn't
start at all because of unresolved symbols, that's not any more acceptable
for KDE than it is for GNOME or any other desktop?

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 12:51 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org