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, 12:46 AM
James Laska
 
Default Fedora 13 Alpha Go/No-Go Meeting: 2010-03-04 @ 01:00 UTC Recap

Greetings,

Representatives from Fedora QA, Rel-Eng and Development met on IRC to
review determine whether the Fedora 13 Alpha release criteria [1] have
been met. The team agreed that the Alpha criteria have been met, and to
proceed with releasing F-13-Alpha-RC4. For additional details, please
refer to the attached minutes.

Thanks,
James

[1] https://fedoraproject.org/wiki/Fedora_13_Alpha_Release_Criteria
================================================== =======
#fedora-meeting: F-13-Alpha engineering readiness meeting
================================================== =======


Meeting started by jlaska at 01:00:03 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting/2010-03-04/f-13-alpha-eng-readiness.2010-03-04-01.00.log.html
.



Meeting summary
---------------
* Waiting for critical mass ... (jlaska, 01:00:25)
* adamw representing QA (jlaska, 01:03:02)
* Oxf13 representing Rel-Eng (jlaska, 01:03:07)
* Oxf13 wearing the notting mask, representing Devel (jlaska,
01:03:21)

* Why are we here? (jlaska, 01:03:44)
* The purpose is to decide whether the alpha has met the release
criteria (jlaska, 01:03:49)
* LINK:
https://fedoraproject.org/wiki/Fedora_13_Alpha_Release_Criteria
(jlaska, 01:03:54)

* Go or No Go? (jlaska, 01:04:57)
* all desktop and install validation tests for alpha point have been
run (jlaska, 01:08:36)
* only bug blocking alpha is
https://bugzilla.redhat.com/show_bug.cgi?id=567346 - we have decided
it's okay as it has a usable workaround, so we should take it off
the list (jlaska, 01:08:52)
* ACTION: Decided that bug#567346 can be removed from F13Alpha
(jlaska, 01:13:10)
* LINK: https://fedoraproject.org/wiki/Common_F13_bugs#yum-langpacks
(jlaska, 01:15:09)
* IDEA: should KDE Live image be respun to address kpackagekit issue?
(jlaska, 01:16:44)
* source DVD is 5.0G (Oxf13, 01:20:49)
* IDEA: need to determine how to handle source ISO's for F-13-Final
(jlaska, 01:24:01)
* ACTION: several remaining CommonBugs? needing documentation
(jlaska, 01:25:15)
* AGREED: QA + Rel-Eng + Devel* agreed to proceed with releasing
F-13-Alpha-RC4 as the Alpha (jlaska, 01:26:09)

* What's next? (jlaska, 01:26:38)
* ACTION: adamw + jlaska to document remaining CommonBugs? issues
(jlaska, 01:28:44)
* LINK: http://fedoraproject.org/wiki/Fedora_12_Alpha_Announcement
(Oxf13, 01:32:06)
* ACTION: jlaska - send out the meeting minutes to devel-announce@
test-announce@ and logistics@ (jlaska, 01:33:34)
* expect to be fully staged for mirrors by tomorrow (Oxf13, 01:34:16)

* Open Discussion (jlaska, 01:34:45)

Meeting ended at 01:36:45 UTC.




Action Items
------------
* Decided that bug#567346 can be removed from F13Alpha
* several remaining CommonBugs? needing documentation
* adamw + jlaska to document remaining CommonBugs? issues
* jlaska - send out the meeting minutes to devel-announce@
test-announce@ and logistics@




Action Items, by person
-----------------------
* adamw
* adamw + jlaska to document remaining CommonBugs? issues
* jlaska
* adamw + jlaska to document remaining CommonBugs? issues
* jlaska - send out the meeting minutes to devel-announce@
test-announce@ and logistics@
* **UNASSIGNED**
* Decided that bug#567346 can be removed from F13Alpha
* several remaining CommonBugs? needing documentation




People Present (lines said)
---------------------------
* jlaska (67)
* Oxf13 (41)
* adamw (32)
* juhp (10)
* poelcat (6)
* rhe (4)
* zodbot (4)
* skvidal (2)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot
_______________________________________________
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-04-2010, 12:17 PM
Kevin Kofler
 
Default Fedora 13 Alpha Go/No-Go Meeting: 2010-03-04 @ 01:00 UTC Recap

James Laska wrote:
> Representatives from Fedora QA, Rel-Eng and Development met on IRC to
> review determine whether the Fedora 13 Alpha release criteria [1] have
> been met. The team agreed that the Alpha criteria have been met, and to
> proceed with releasing F-13-Alpha-RC4.

Oh, because a KDE live image which can't be updated without resorting to the
command line is <SARCASM>obviously</SARCASM> ready for release, and because
there was <SARCASM>clearly</SARCASM> no way a RC5 could have been spun in
the several days between the availability of the updated kpackagekit build
(to match the PackageKit snapshot used in RC4) and this meeting.

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.

But of course the GNOME spin "works" (for some definition of "works", they
also have a PackageKit issue which was declared not a blocker –
https://bugzilla.redhat.com/show_bug.cgi?id=567346 , which I guess also
affects KPackageKit, by the way –, and they fail pretty much all the tests
for beta or release quality, which I think the KDE spin would actually pass,
given that this is the same 4.4.0 we pushed as F11 and F12 updates and works
fine there, though I didn't bother testing this as clearly nobody cares
about the KDE spin test results anyway), so nobody cares.

Kevin Kofler

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

On 4 March 2010 13:17, Kevin Kofler <kevin.kofler@chello.at> wrote:
> But of course the GNOME spin "works" (for some definition of "works", they
> also have a PackageKit issue which was declared not a blocker –

For the record, it is a yum-langpacks issue.

If you're running an up to date gnome-packagekit you get a nice
message telling you so.

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

On Thu, 4 Mar 2010, Richard Hughes wrote:


On 4 March 2010 13:17, Kevin Kofler <kevin.kofler@chello.at> wrote:

But of course the GNOME spin "works" (for some definition of "works", they
also have a PackageKit issue which was declared not a blocker –


For the record, it is a yum-langpacks issue.

If you're running an up to date gnome-packagekit you get a nice
message telling you so.


And there is a patch in upstream yum that let's skip-broken work around
that problem.


I'm glad to put another yum out with this patch in it for f13 but I asked
yesterday at the go/nogo meeting and was asked to wait until the alpha was
out.


I'm happy to do so whenever, though.

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

On Thu, 2010-03-04 at 14:17 +0100, Kevin Kofler wrote:
> James Laska wrote:
> > Representatives from Fedora QA, Rel-Eng and Development met on IRC to
> > review determine whether the Fedora 13 Alpha release criteria [1] have
> > been met. The team agreed that the Alpha criteria have been met, and to
> > proceed with releasing F-13-Alpha-RC4.
>
> Oh, because a KDE live image which can't be updated without resorting to the
> command line is <SARCASM>obviously</SARCASM> ready for release, and because
> there was <SARCASM>clearly</SARCASM> no way a RC5 could have been spun in
> the several days between the availability of the updated kpackagekit build
> (to match the PackageKit snapshot used in RC4) and this meeting.

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.

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.

I would have liked to do a respin of the KDE live image with the new
kpackagekit, and we did have a brief discussion with releng about that
at the initial go/no-go meeting, but we kind of dropped the ball in the
next few days on that, for which I'm sorry. It wasn't intentional.

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

> But of course the GNOME spin "works" (for some definition of "works", they
> also have a PackageKit issue which was declared not a blocker –
> https://bugzilla.redhat.com/show_bug.cgi?id=567346 , which I guess also
> affects KPackageKit, by the way –,

Yeah, it probably does. It's been declared not-blocker because it's
ultimately caused by the langpacks plugin, so there's an acceptable
workaround - uninstall that - which is documented on the CommonBugs
page. Also, it will only happen in a case where there's dependency
problems, so when the available F13 update set is actually *coherent*,
it won't fail.

> and they fail pretty much all the tests
> for beta or release quality, which I think the KDE spin would actually pass,

Yup. We don't block Alpha release if it fails the criteria for Beta or
Final. That's the pre-release process working. =) If you look at the
linked bug reports, most of the failures are fairly minor. For instance,
one test 'fails' because if you open System Tools - CD/DVD Creator, drag
in some files and hit 'burn', it crashes nautilus instead of running
Brasero. You can easily run Brasero directly and burn a disc, though.
I'd hope you'd agree that's a perfectly acceptable level of
functionality for an *Alpha* release.

> given that this is the same 4.4.0 we pushed as F11 and F12 updates and works
> fine there, though I didn't bother testing this as clearly nobody cares
> about the KDE spin test results anyway), so nobody cares.

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. Also, if any of the non-default
desktops had been known to be really horribly broken - as in, 'the damn
thing won't start up', or something - we would have considered making
that an Alpha blocker.
--
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, 06:22 PM
Toshio Kuratomi
 
Default Fedora 13 Alpha Go/No-Go Meeting: 2010-03-04 @ 01:00 UTC Recap

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

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

On Thu, 2010-03-04 at 10:47 -0800, Adam Williamson wrote:
> On Thu, 2010-03-04 at 14:17 +0100, Kevin Kofler wrote:
> > James Laska wrote:
> > > Representatives from Fedora QA, Rel-Eng and Development met on IRC to
> > > review determine whether the Fedora 13 Alpha release criteria [1] have
> > > been met. The team agreed that the Alpha criteria have been met, and to
> > > proceed with releasing F-13-Alpha-RC4.
> >
> > Oh, because a KDE live image which can't be updated without resorting to the
> > command line is <SARCASM>obviously</SARCASM> ready for release, and because
> > there was <SARCASM>clearly</SARCASM> no way a RC5 could have been spun in
> > the several days between the availability of the updated kpackagekit build
> > (to match the PackageKit snapshot used in RC4) and this meeting.
>
> 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.
>
> 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.
>
> I would have liked to do a respin of the KDE live image with the new
> kpackagekit, and we did have a brief discussion with releng about that
> at the initial go/no-go meeting, but we kind of dropped the ball in the
> next few days on that, for which I'm sorry. It wasn't intentional.
>
> > 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. =)
>
> > But of course the GNOME spin "works" (for some definition of "works", they
> > also have a PackageKit issue which was declared not a blocker –
> > https://bugzilla.redhat.com/show_bug.cgi?id=567346 , which I guess also
> > affects KPackageKit, by the way –,
>
> Yeah, it probably does. It's been declared not-blocker because it's
> ultimately caused by the langpacks plugin, so there's an acceptable
> workaround - uninstall that - which is documented on the CommonBugs
> page. Also, it will only happen in a case where there's dependency
> problems, so when the available F13 update set is actually *coherent*,
> it won't fail.
>
> > and they fail pretty much all the tests
> > for beta or release quality, which I think the KDE spin would actually pass,
>
> Yup. We don't block Alpha release if it fails the criteria for Beta or
> Final. That's the pre-release process working. =) If you look at the
> linked bug reports, most of the failures are fairly minor. For instance,
> one test 'fails' because if you open System Tools - CD/DVD Creator, drag
> in some files and hit 'burn', it crashes nautilus instead of running
> Brasero. You can easily run Brasero directly and burn a disc, though.
> I'd hope you'd agree that's a perfectly acceptable level of
> functionality for an *Alpha* release.
>
> > given that this is the same 4.4.0 we pushed as F11 and F12 updates and works
> > fine there, though I didn't bother testing this as clearly nobody cares
> > about the KDE spin test results anyway), so nobody cares.
>
> 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. Also, if any of the non-default
> desktops had been known to be really horribly broken - as in, 'the damn
> thing won't start up', or something - we would have considered making
> that an Alpha blocker.

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.

Thanks,
James

[1]
https://fedoraproject.org/wiki/Test_Results:Fedora_13_Alpha_RC4_Desktop
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-04-2010, 06:59 PM
Kevin Kofler
 
Default Fedora 13 Alpha Go/No-Go Meeting: 2010-03-04 @ 01:00 UTC Recap

Toshio Kuratomi wrote:
> 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

And kpackagekit is hardly testable if it doesn't work at all due to
unresolved symbols.

In fact, the only reason it didn't fail the live image compose outright is
that we've been shipping unreleased snapshots of PackageKit in the middle of
PackageKit-qt ABI changes, and the soname bump was only done for the actual
0.6.2 release.

I'll also note that the reason we had this breakage is that F13 is shipping
PackageKit 0.6.x which is clearly not ready for production use (as evidenced
by the issues seen; in fact, PackageKit reportedly didn't work at all until
Alpha RC3) and which includes a PackageKit-qt binding considered an unstable
development version (to the point its ABI is changing wildly and there's no
official kpackagekit release to go with it yet, we've been forced to package
SVN snapshots of kpackagekit, and even sometimes the exact right old
revision to match that particular snapshot of PackageKit-qt). 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).

Kevin Kofler

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

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

I'd say our practical take on it is that the freeze policy definition
means the maintainers should basically have the major chunks of code
that they're aiming to ship in place by Alpha, but if there's a bug
making it not possible to really use some of them in practice - but that
bug doesn't stop the basic 'install Alpha, get updates' procedure from
working - we're not going to hold the release for that.

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.
--
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, 07:06 PM
Kevin Kofler
 
Default Fedora 13 Alpha Go/No-Go Meeting: 2010-03-04 @ 01:00 UTC Recap

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.

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

> Also, if any of the non-default desktops had been known to be really
> horribly broken - as in, 'the damn thing won't start up', or something -
> we would have considered making that an Alpha blocker.

But "the damn thing won't update, so if anything's broken, I can't get the
fix" is not? Weird. Also makes me wonder why to bother with putting that as
an alpha blocker anyway if you try to discuss it away just because it
doesn't happen in GNOME.

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 04:43 PM.

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