9:51 p.m.
Hi,
Being somewhat new to the Fedora releases I'm looking for a better understanding of
how the release process works and the methodology Fedora uses to determine when a release
is ready to ship. I'd like to document this if it isn't done already.
Earlier in the week this page was discussed:
http://fedoraproject.org/wiki/Releases/7/MustHave
I am curious how we determine which open bugs must also be fixed in order to reach GA? I
would think some of these bugs are tied to the "MustHaves?" I ran a few queries
and was left wondering how bugs really do play into the GA of a new release when there are
so many open bugs from the previous releases and "Development."
I ran a quick query of the Fedora Core and found the following number of *unresolved* bugs
in the state of: "NEW" "ASSIGNED" or "MODIFIED."
Product: "Fedora Core"
Version:
FC5T1 20
FC5T2 24
FC5T3 80
FC5GA 1,545 --------
FC5 Total 1,669
FC6T1 37
FC6T2 82
FC6T3 153
FC6GA 2,315 --------
FC6 Total 2,587
Development 2,859
----------
Total Bugs 7,115
==========
This raised a few questions for me:
1) Is there a mechanism to know which of the bugs above must be fixed or FC7 to GA?
2) What process do we go through to close these bugs?
3) How does Fedora decide a release is ready to GA?
4) How are bugs from previous releases considered in the planning process?
Thanks,
John
10:04 p.m.
On Wednesday 21 March 2007 22:51:39 John Poelstra wrote:
This raised a few questions for me:
1) Is there a mechanism to know which of the bugs above must be fixed or
FC7 to GA?
Nothing formal. As we start looking that way a few people generally shuffle
through the "Blocker" list to look for actual blockers and get rid of the
noise. Since there is no committee that decides what is or isn't a blocker
we can't just take every bug as an actual blocker.
2) What process do we go through to close these bugs?
Really, that depends on the bug. Generally we fix it, or find a suitable work
around.
3) How does Fedora decide a release is ready to GA?
Release Engineering in conjunction with QA typically come to an agreement that
the tree is "good enough". Sometimes we have to kick decisions up to the
board on what to do about remaining issues.
4) How are bugs from previous releases considered in the planning
process?
They aren't really, officially. We try to fix the big glaring ones
immediately after the release to prevent them from happening again the next
time. Some previous "blockers" are moved to the next blocker set to be
reviewed later.
Unlike with RHEL, there is no real good management of the blocker/target bugs
for Fedora.
--
Jesse Keating
Release Engineer: Fedora
11:29 a.m.
Jesse Keating said the following on 03/21/2007 08:04 PM Pacific Time:
On Wednesday 21 March 2007 22:51:39 John Poelstra wrote:
> 4) How are bugs from previous releases considered in the planning process?
They aren't really, officially. We try to fix the big glaring ones
immediately after the release to prevent them from happening again the next
time. Some previous "blockers" are moved to the next blocker set to be
reviewed later.
Unlike with RHEL, there is no real good management of the blocker/target bugs
for Fedora.
Has the project discussed or determined how we will:
1) Close out the approximately 7,000+ open bugs?
2) Handle future releases in a way that the backlog doesn't get so high?
Having tried to report more bugs myself recently, I wondered to myself if some people are
not motivated to file bugs because they have the perception that nothing happens when they
do? Naturally I'm not trying to increase the *quantity* of open bugs we have, but I
wonder if with more volume we would see higher *quality* issues?
Perhaps a better question to ask is if other bug reporters have the feeling that bugs they
file will be addressed in one way or another (acknowledged, fixed, CLOSED_WONT_FIX,
etc.)?
Not wanting to place too much weight on a "number"... 7,000+ bugs jumped out at
me as possibly raising this question, but I'd love to hear what other people think. I
readily acknowledge that the manpower needed to address these bugs is a completely
different (complex) matter and maybe it has already been discussed (thus questions #1 and
#2 above).
Thanks,
John
12:10 p.m.
On Thursday 22 March 2007 12:29:42 John Poelstra wrote:
Has the project discussed or determined how we will:
1) Close out the approximately 7,000+ open bugs?
2) Handle future releases in a way that the backlog doesn't get so high?
Do you have any ideas? You're part of the projet.
--
Jesse Keating
Release Engineer: Fedora
1 p.m.
Jesse Keating wrote:
On Thursday 22 March 2007 12:29:42 John Poelstra wrote:
> Has the project discussed or determined how we will:
> 1) Close out the approximately 7,000+ open bugs?
> 2) Handle future releases in a way that the backlog doesn't get so high?
Do you have any ideas? You're part of the projet.
This is something which has amazed / annoyed me too, I've tried several times
to start a community effort to something about this metric, but sofar with
little success.
These bugs fall into 2 categories:
1) Bugs which are simply being ignored by @redhat.com people who need to be hit
with the cluebat (repeatedly)
2) Really really hard bugs (think xorg / kernel / hal /mkinitrd)
Most likely a lot of 1) bugs are already solved but never got closed /
retested, others should be taken upstream (and thus closed in Fedora BZ), etc.
/me thinks we really should do something about the category 1 bugs....
Regards,
Hans
1:07 p.m.
On Thu, 2007-03-22 at 19:00 +0100, Hans de Goede wrote:
Jesse Keating wrote:
> On Thursday 22 March 2007 12:29:42 John Poelstra wrote:
>> Has the project discussed or determined how we will:
>> 1) Close out the approximately 7,000+ open bugs?
>> 2) Handle future releases in a way that the backlog doesn't get so high?
>
> Do you have any ideas? You're part of the projet.
>
>
This is something which has amazed / annoyed me too, I've tried several times
to start a community effort to something about this metric, but sofar with
little success.
These bugs fall into 2 categories:
1) Bugs which are simply being ignored by @redhat.com people who need to be hit
with the cluebat (repeatedly)
Don't make statements like that. They aren't helpful in any manner.
You cannot claim that they are intentionally ignoring them. Hitting
people with the "update your bugs" cluebat that have a massive amount of
bugs simply does not work and does not help solve the problem.
2) Really really hard bugs (think xorg / kernel / hal /mkinitrd)
Most likely a lot of 1) bugs are already solved but never got closed /
retested, others should be taken upstream (and thus closed in Fedora BZ), etc.
If a lot of 1) bugs are already solved, anyone within the 'fedorabugs'
group can act as a proxy to close them out. Team effort would be a very
good thing I think.
josh
1:16 p.m.
Josh Boyer wrote:
On Thu, 2007-03-22 at 19:00 +0100, Hans de Goede wrote:
> Jesse Keating wrote:
>> On Thursday 22 March 2007 12:29:42 John Poelstra wrote:
>>> Has the project discussed or determined how we will:
>>> 1) Close out the approximately 7,000+ open bugs?
>>> 2) Handle future releases in a way that the backlog doesn't get so high?
>> Do you have any ideas? You're part of the projet.
>>
>>
> This is something which has amazed / annoyed me too, I've tried several times
> to start a community effort to something about this metric, but sofar with
> little success.
>
> These bugs fall into 2 categories:
> 1) Bugs which are simply being ignored by @redhat.com people who need to be hit
> with the cluebat (repeatedly)
Don't make statements like that. They aren't helpful in any manner.
You cannot claim that they are intentionally ignoring them. Hitting
people with the "update your bugs" cluebat that have a massive amount of
bugs simply does not work and does not help solve the problem.
> 2) Really really hard bugs (think xorg / kernel / hal /mkinitrd)
I have a different opinion and experience on this, I deliberately created 2
categories. The people with lots of bugs generally have bugs that fall into
category 2 and despite the large number of these bugs they have, they respond
more often to bugs of mine then people with packages with mainly category 1 bugs.
Wether you like it or not, there are some people both in FC and FE, who do a
bad job of responding to bugs. This is something which needs to be addressed,
covering this with the blanket of love is not going to help!
>
> Most likely a lot of 1) bugs are already solved but never got closed /
> retested, others should be taken upstream (and thus closed in Fedora BZ), etc.
If a lot of 1) bugs are already solved, anyone within the 'fedorabugs'
group can act as a proxy to close them out. Team effort would be a very
good thing I think.
Agreed, as said I've tried to start a team / group effort on this already
several times, do you want to try this one more time together with me? Maybe
with combined forces we have more luck.
Regards,
Hans
1:23 p.m.
On Thu, 2007-03-22 at 13:07 -0500, Josh Boyer wrote:
On Thu, 2007-03-22 at 19:00 +0100, Hans de Goede wrote:
>
> This is something which has amazed / annoyed me too, I've tried several times
> to start a community effort to something about this metric, but sofar with
> little success.
>
> These bugs fall into 2 categories:
> 1) Bugs which are simply being ignored by @redhat.com people who need to be hit
> with the cluebat (repeatedly)
Hey now. We're really, really, really busy sometimes *coughRHEL5cough*.
Be nice.
> Most likely a lot of 1) bugs are already solved but never got
closed /
> retested, others should be taken upstream (and thus closed in Fedora BZ), etc.
If a lot of 1) bugs are already solved, anyone within the 'fedorabugs'
group can act as a proxy to close them out. Team effort would be a very
good thing I think.
Well then - let's start friday Bug Days again. This friday (and possibly
next friday) we can try to work through the FC5 and FC6 test release
bugs. It's only 380 bugs! Here's the link:
http://rdr.to/W8
That's (currently) 460 ASSIGNED, MODIFIED, NEEDINFO and NEW bugs against
all the FC5 and FC6 test releases.
Next week: FC5, or FC6?
This might be a good time to mention the recently-created
fedora-qa-list:
http://www.redhat.com/mailman/listinfo/fedora-qa-list
Further discussion of this topic should go there.
-w
2:06 p.m.
On Thu, 22 Mar 2007 14:23:19 -0400
wwoods(a)redhat.com (Will Woods) wrote:
On Thu, 2007-03-22 at 13:07 -0500, Josh Boyer wrote:
> On Thu, 2007-03-22 at 19:00 +0100, Hans de Goede wrote:
...snipp...
> > Most likely a lot of 1) bugs are already solved but never
got
> > closed / retested, others should be taken upstream (and thus
> > closed in Fedora BZ), etc.
>
> If a lot of 1) bugs are already solved, anyone within the
> 'fedorabugs' group can act as a proxy to close them out. Team
> effort would be a very good thing I think.
Well then - let's start friday Bug Days again. This friday (and
possibly next friday) we can try to work through the FC5 and FC6 test
release bugs. It's only 380 bugs! Here's the link:
http://rdr.to/W8
That's (currently) 460 ASSIGNED, MODIFIED, NEEDINFO and NEW bugs
against all the FC5 and FC6 test releases.
Sounds like a good idea to me. I would be happy to help.
What time? Coordinate on #fedora-devel irc?
Is there more info for people who would like to help?
Next week: FC5, or FC6?
Possibly. ;)
If this is a weekly thing I would also like to see trying to help out
some of the packages that just have way too many bugs for any single
mantainer to deal with... rpm, kernel, etc.
This might be a good time to mention the recently-created
fedora-qa-list:
http://www.redhat.com/mailman/listinfo/fedora-qa-list
Another list? :( Is that really needed? or couldn't discussions take
place here?
Further discussion of this topic should go there.
ok. I will after this I suppose.
-w
kevin
2:14 p.m.
On Thu, 2007-03-22 at 13:06 -0600, Kevin Fenzi wrote:
On Thu, 22 Mar 2007 14:23:19 -0400
wwoods(a)redhat.com (Will Woods) wrote:
> On Thu, 2007-03-22 at 13:07 -0500, Josh Boyer wrote:
> > On Thu, 2007-03-22 at 19:00 +0100, Hans de Goede wrote:
...snipp...
> > > Most likely a lot of 1) bugs are already solved but never got
> > > closed / retested, others should be taken upstream (and thus
> > > closed in Fedora BZ), etc.
> >
> > If a lot of 1) bugs are already solved, anyone within the
> > 'fedorabugs' group can act as a proxy to close them out. Team
> > effort would be a very good thing I think.
>
> Well then - let's start friday Bug Days again. This friday (and
> possibly next friday) we can try to work through the FC5 and FC6 test
> release bugs. It's only 380 bugs! Here's the link:
>
> http://rdr.to/W8
>
> That's (currently) 460 ASSIGNED, MODIFIED, NEEDINFO and NEW bugs
> against all the FC5 and FC6 test releases.
Sounds like a good idea to me. I would be happy to help.
What time? Coordinate on #fedora-devel irc?
Is there more info for people who would like to help?
Usually we do this in #fedora-qa. The following wiki pages should also
be helpful:
http://fedoraproject.org/wiki/BugZappers
http://fedoraproject.org/wiki/TriagingGuidelines
> This might be a good time to mention the recently-created
> fedora-qa-list:
> http://www.redhat.com/mailman/listinfo/fedora-qa-list
Another list? :( Is that really needed? or couldn't discussions take
place here?
Plenty of discussions *could* take place here - in fact, 10,000 unread
emails indicate that plenty of them *do* take place here - but there was
nowhere to discuss QA-specific things like bug triaging and bugzilla
improvements and regression testing. So yes, it is really needed.
-w
2:25 p.m.
On Thu, Mar 22, 2007 at 01:06:41PM -0600, Kevin Fenzi wrote:
If this is a weekly thing I would also like to see trying to help
out
some of the packages that just have way too many bugs for any single
mantainer to deal with... rpm, kernel, etc.
I've been toying with the idea of a 'kernel bug day' thing for a while.
Whilst a lot of those bugs are really nasty horrible bugs that you
really need to understand kernel code for, there's quite a bit of
grunt work that I'd be happy to farm out to eager helpers.
Things like ..
* marking bugs that have patches in them more prominently,
* adding bugs to the 'meta' bugs (cf, the alias 'FCMETA_ACPI'),
* making sure relevant people are cc'd/assigned.
* going through old bugs and asking reporters to retest with
the latest updates
* closing out bugs that have been in NEEDINFO forever.
* forwarding bug reports upstream to linux-kernel / maintainers / kernel.org
bugzilla.
It's real painstaking work to do that sort of thing, and I'd rather
be actually fixing bugs.
The last time I did some stats, the kernel had more bugs assigned
against it than any other package. It's constantly inundated
with new reports coming in faster than we can close out old ones,
so any help on keeping this managable so that we can actually
see the bugs that matter would be much appreciated.
I'm on pseudo-vacation next week, but I think we should give
this a shot when I get back.
Dave
--
http://www.codemonkey.org.uk
2:37 p.m.
On Thu, 2007-03-22 at 15:25 -0400, Dave Jones wrote:
On Thu, Mar 22, 2007 at 01:06:41PM -0600, Kevin Fenzi wrote:
> If this is a weekly thing I would also like to see trying to help out
> some of the packages that just have way too many bugs for any single
> mantainer to deal with... rpm, kernel, etc.
I've been toying with the idea of a 'kernel bug day' thing for a while.
Whilst a lot of those bugs are really nasty horrible bugs that you
really need to understand kernel code for, there's quite a bit of
grunt work that I'd be happy to farm out to eager helpers.
Things like ..
* marking bugs that have patches in them more prominently,
* adding bugs to the 'meta' bugs (cf, the alias 'FCMETA_ACPI'),
* making sure relevant people are cc'd/assigned.
* going through old bugs and asking reporters to retest with
the latest updates
* closing out bugs that have been in NEEDINFO forever.
* forwarding bug reports upstream to linux-kernel / maintainers / kernel.org
bugzilla.
It's real painstaking work to do that sort of thing, and I'd rather
be actually fixing bugs.
We've got plenty of eager helpers (myself included!). We'll just need
some guidance to know which bucket to put stuff in.
I'm on pseudo-vacation next week, but I think we should give
this a shot when I get back.
Absolutely! I dunno which time zone you're in at the moment, so pick a
time next Friday (or whatever day works for you). We'll get the word
out. Hopefully we can do this regularly.
-w
3:33 p.m.
Will Woods wrote:
On Thu, 2007-03-22 at 15:25 -0400, Dave Jones wrote:
> I've been toying with the idea of a 'kernel bug day' thing for a while.
> Whilst a lot of those bugs are really nasty horrible bugs that you
> really need to understand kernel code for, there's quite a bit of
> grunt work that I'd be happy to farm out to eager helpers.
>
> Things like ..
> * marking bugs that have patches in them more prominently,
> * adding bugs to the 'meta' bugs (cf, the alias 'FCMETA_ACPI'),
> * making sure relevant people are cc'd/assigned.
> * going through old bugs and asking reporters to retest with
> the latest updates
> * closing out bugs that have been in NEEDINFO forever.
> * forwarding bug reports upstream to linux-kernel / maintainers / kernel.org
> bugzilla.
>
> It's real painstaking work to do that sort of thing, and I'd rather
> be actually fixing bugs.
We've got plenty of eager helpers (myself included!).
Count me in too. I already try to do whatever I can, sweeping through
open bugs from time to time, but would love to do more.
--
Jarod Wilson
jwilson(a)redhat.com
4:37 p.m.
tor, 22 03 2007 kl. 16:33 -0400, skrev Jarod Wilson:
Will Woods wrote:
> On Thu, 2007-03-22 at 15:25 -0400, Dave Jones wrote:
>> I've been toying with the idea of a 'kernel bug day' thing for a
while.
>> Whilst a lot of those bugs are really nasty horrible bugs that you
>> really need to understand kernel code for, there's quite a bit of
>> grunt work that I'd be happy to farm out to eager helpers.
>>
>> Things like ..
>> * marking bugs that have patches in them more prominently,
>> * adding bugs to the 'meta' bugs (cf, the alias 'FCMETA_ACPI'),
>> * making sure relevant people are cc'd/assigned.
>> * going through old bugs and asking reporters to retest with
>> the latest updates
>> * closing out bugs that have been in NEEDINFO forever.
>> * forwarding bug reports upstream to linux-kernel / maintainers / kernel.org
>> bugzilla.
>>
>> It's real painstaking work to do that sort of thing, and I'd rather
>> be actually fixing bugs.
>
> We've got plenty of eager helpers (myself included!).
Count me in too. I already try to do whatever I can, sweeping through
open bugs from time to time, but would love to do more.
Me too, I'd love to have some guidelines to getting better information
out of the kernel to say report unworking suspend situations. The kernel
is a rather special package and I doubt many of us wield it's strange
magic.
- David Nielsen
--
"Ridicule is the only weapon that can be used against unintelligible
propositions. Ideas must be distinct before reason can act upon them.”
-Thomas Jefferson
2:34 p.m.
Kevin Fenzi wrote:
On Thu, 22 Mar 2007 14:23:19 -0400
wwoods(a)redhat.com (Will Woods) wrote:
> On Thu, 2007-03-22 at 13:07 -0500, Josh Boyer wrote:
>> On Thu, 2007-03-22 at 19:00 +0100, Hans de Goede wrote:
...snipp...
>>> Most likely a lot of 1) bugs are already solved but never got
>>> closed / retested, others should be taken upstream (and thus
>>> closed in Fedora BZ), etc.
>> If a lot of 1) bugs are already solved, anyone within the
>> 'fedorabugs' group can act as a proxy to close them out. Team
>> effort would be a very good thing I think.
> Well then - let's start friday Bug Days again. This friday (and
> possibly next friday) we can try to work through the FC5 and FC6 test
> release bugs. It's only 380 bugs! Here's the link:
>
> http://rdr.to/W8
>
> That's (currently) 460 ASSIGNED, MODIFIED, NEEDINFO and NEW bugs
> against all the FC5 and FC6 test releases.
Sounds like a good idea to me. I would be happy to help.
What time?
I'll be available from 8u00 (CET / GMT +1) till 17u00 and maybe
sometime in
the evening too.
Coordinate on #fedora-devel irc?
+1
Is there more info for people who would like to help?
Good question, for example what should we do with bugs like:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214864
Assigned by reporter to reporter, no valid summary / description, most likely
caused by a messed up install, invalid component. Slam close?
> Next week: FC5, or FC6?
Possibly. ;)
I say start with the newest bugs first, those contain much more low hanging
fruit, so I "vote" to work on this list coming friday:
http://rdr.to/W9
If this is a weekly thing I would also like to see trying to help
out
some of the packages that just have way too many bugs for any single
mantainer to deal with... rpm, kernel, etc.
kernel is very hard to help with (I've written and maintain some kernel
drivers, and I'm lost in there). Helping rpm starts with getting rpm an active
maintainer, I've filed and watched many rpm bugs and comments to the by pnasrat
(the current maintainer) are very scarce. I think that choosing one package and
then working on it is a good idea, but again low hanging fruit. For example
ImagaMagick has quite a few bugs which should be fixable.
Also an important question to ask ourselves is triage or fixing or both? I'm
quite good at debugging C-code (no race conditions please), and have already
fixed quite a few bugs. Now if we could combine a few triagers with a few
fixers on friday, that might work very well.
> This might be a good time to mention the recently-created
> fedora-qa-list:
> http://www.redhat.com/mailman/listinfo/fedora-qa-list
Another list? :( Is that really needed? or couldn't discussions take
place here?
+1 +1 +1
> Further discussion of this topic should go there.
ok. I will after this I suppose.
Please don't, -ETOOMANYLISTS.
Regards,
Hans
2:50 p.m.
On Thu, 2007-03-22 at 20:34 +0100, Hans de Goede wrote:
> What time?
I'll be available from 8u00 (CET / GMT +1) till 17u00 and maybe sometime in
the evening too.
> Coordinate on #fedora-devel irc?
+1
If you want to keep it on #fedora-devel that's fine - eventually I
suspect (hope?) that bug triaging will get too big to stay there without
drowning out normal -devel work. At that point, we should move to
#fedora-qa.
> Is there more info for people who would like to help?
>
Good question, for example what should we do with bugs like:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214864
Assigned by reporter to reporter, no valid summary / description, most likely
caused by a messed up install, invalid component. Slam close?
Very yes. There's nothing to fix, hence the problem is solved.
I say start with the newest bugs first, those contain much more low
hanging
fruit, so I "vote" to work on this list coming friday:
http://rdr.to/W9
Noted.
Also an important question to ask ourselves is triage or fixing or
both? I'm
quite good at debugging C-code (no race conditions please), and have already
fixed quite a few bugs. Now if we could combine a few triagers with a few
fixers on friday, that might work very well.
Triage + fixing is awesome but I can't speak for developers. There will
definitely be weekly triage sessions every Friday - at least US Eastern
business hours, when I'm around (~1400-2200UTC). If developers come and
help fix the low-hanging fruit, so much the better.
>> This might be a good time to mention the recently-created
>> fedora-qa-list:
>> http://www.redhat.com/mailman/listinfo/fedora-qa-list
>
> Another list? :( Is that really needed? or couldn't discussions take
> place here?
>
+1 +1 +1
>> Further discussion of this topic should go there.
>
> ok. I will after this I suppose.
>
Please don't, -ETOOMANYLISTS.
Feh. This wasn't just a gratuitous "Hey let's make a new list!!"
decision - we decided this in January:
http://www.redhat.com/archives/fedora-advisory-board/2007-January/msg0010...
Except nobody seems to be able to agree on whether we need more or less
lists, and what they should be named, and so on. I'm sick of discussing
whether we need new lists or not.
Development is not the same as QA and I refuse to require
fedora-devel-list membership for the QA team. That's why they're
separate - to reduce apparent signal/noise problems and prevent people
who aren't developers from having to pick QA stuff out of 10,000 unread
development messages.
-w
2:10 p.m.
Will Woods wrote:
On Thu, 2007-03-22 at 13:07 -0500, Josh Boyer wrote:
> On Thu, 2007-03-22 at 19:00 +0100, Hans de Goede wrote:
>> This is something which has amazed / annoyed me too, I've tried several times
>> to start a community effort to something about this metric, but sofar with
>> little success.
>>
>> These bugs fall into 2 categories:
>> 1) Bugs which are simply being ignored by @redhat.com people who need to be hit
>> with the cluebat (repeatedly)
Hey now. We're really, really, really busy sometimes *coughRHEL5cough*.
Be nice.
>> Most likely a lot of 1) bugs are already solved but never got closed /
>> retested, others should be taken upstream (and thus closed in Fedora BZ), etc.
> If a lot of 1) bugs are already solved, anyone within the 'fedorabugs'
> group can act as a proxy to close them out. Team effort would be a very
> good thing I think.
Well then - let's start friday Bug Days again. This friday (and possibly
next friday) we can try to work through the FC5 and FC6 test release
bugs. It's only 380 bugs! Here's the link:
http://rdr.to/W8
That's (currently) 460 ASSIGNED, MODIFIED, NEEDINFO and NEW bugs against
all the FC5 and FC6 test releases.
Next week: FC5, or FC6?
This might be a good time to mention the recently-created
fedora-qa-list:
http://www.redhat.com/mailman/listinfo/fedora-qa-list
Further discussion of this topic should go there.
Sounds like a plan to me (friday bugs day) but may I suggest starting with F7
test bugs so that we can get F7 in as good a shape as possible before release.
Regards,
Hans
2:04 p.m.
On Thu, 2007-03-22 at 20:10 +0100, Hans de Goede wrote:
Will Woods wrote:
> Well then - let's start friday Bug Days again. This friday
(and possibly
> next friday) we can try to work through the FC5 and FC6 test release
> bugs. It's only 380 bugs! Here's the link:
>
> http://rdr.to/W8
>
> That's (currently) 460 ASSIGNED, MODIFIED, NEEDINFO and NEW bugs against
> all the FC5 and FC6 test releases.
>
> Next week: FC5, or FC6?
>
> This might be a good time to mention the recently-created
> fedora-qa-list:
> http://www.redhat.com/mailman/listinfo/fedora-qa-list
>
> Further discussion of this topic should go there.
>
Sounds like a plan to me (friday bugs day) but may I suggest starting with F7
test bugs so that we can get F7 in as good a shape as possible before release.
F7 bugs on Friday? Isn't that what the other 6 days a week are for?
Besides, we don't have F7 test releases in bugzilla - it's all just
under 'devel' (i.e. rawhide).
For reference, here's the link for "rawhide bugs active this week":
http://rdr.to/W9
-w
3:15 p.m.
On Thu, 2007-03-22 at 13:07 -0500, Josh Boyer wrote:
>
> These bugs fall into 2 categories:
> 1) Bugs which are simply being ignored by @redhat.com people who need to be hit
> with the cluebat (repeatedly)
Don't make statements like that. They aren't helpful in any manner.
You cannot claim that they are intentionally ignoring them. Hitting
people with the "update your bugs" cluebat that have a massive amount of
bugs simply does not work and does not help solve the problem.
If you want to be helpful, add a comment "fixed in x.y.z" if you find
bugs that no longer apply. That will make it much easier to quickly
close it the next time the package maintainer comes across the bug.
4:02 p.m.
Matthias Clasen wrote:
On Thu, 2007-03-22 at 13:07 -0500, Josh Boyer wrote:
>> These bugs fall into 2 categories:
>> 1) Bugs which are simply being ignored by @redhat.com people who need to be hit
>> with the cluebat (repeatedly)
> Don't make statements like that. They aren't helpful in any manner.
> You cannot claim that they are intentionally ignoring them. Hitting
> people with the "update your bugs" cluebat that have a massive amount of
> bugs simply does not work and does not help solve the problem.
>
If you want to be helpful, add a comment "fixed in x.y.z" if you find
bugs that no longer apply. That will make it much easier to quickly
close it the next time the package maintainer comes across the bug.
I always do that (and close them) for bugs I fixed myself.
Matthias, you're one of the @redhat.com people I know to be pretty responsive
most of the time. However unfortunately you have colleagues who aren't response
to BZ entries, this is not good and someone needs to talk to these people about
it. I understand that there are busy times and very busy times @redhat, still I
see a huge differences between individual @redhat people in how responsive they
are. I can give a list of positive examples (you included), but funny enough
not negative examples, because I have so little interaction with these people
that I don't know / remember there names! Still I know they exist because some
of the bugs I file get assigned to them and then completely disappear of the radar.
Regards,
Hans
4:13 p.m.
Jesse Keating said the following on 03/22/2007 10:10 AM Pacific Time:
On Thursday 22 March 2007 12:29:42 John Poelstra wrote:
> Has the project discussed or determined how we will:
> 1) Close out the approximately 7,000+ open bugs?
> 2) Handle future releases in a way that the backlog doesn't get so high?
Do you have any ideas? You're part of the projet.
I was trying to be polite by not rehashing or pushing something that had already been
discussed. If work has already been done I thought it would better build on it instead
starting from scratch.
I'm still trying to understand exactly what processes and decisions go into creating a
Fedora release... from the planning process all the way to GA and maintenance. I'd
like to think that eventually we could have a document explaining this entire process,
including how bugs are handled. I think this is an important aspect of being transparent
as a project.
John
4:24 p.m.
On Thursday 22 March 2007 17:13:01 John Poelstra wrote:
I'm still trying to understand exactly what processes and
decisions go into
creating a Fedora release... from the planning process all the way to GA
and maintenance. I'd like to think that eventually we could have a
document explaining this entire process, including how bugs are handled. I
think this is an important aspect of being transparent as a project.
Absolutely. The horror of it is that there IS no real concrete method to
determine this. Isn't it fun?
--
Jesse Keating
Release Engineer: Fedora
4:47 p.m.
On Thu, 2007-03-22 at 17:24 -0400, Jesse Keating wrote:
On Thursday 22 March 2007 17:13:01 John Poelstra wrote:
> I'm still trying to understand exactly what processes and decisions go into
> creating a Fedora release... from the planning process all the way to GA
> and maintenance. I'd like to think that eventually we could have a
> document explaining this entire process, including how bugs are handled. I
> think this is an important aspect of being transparent as a project.
Absolutely. The horror of it is that there IS no real concrete method to
determine this. Isn't it fun?
On the plus side, you can't get much more transparent than "nothing".
-w
12:10 p.m.
On Wed, 2007-03-21 at 23:04 -0400, Jesse Keating wrote:
On Wednesday 21 March 2007 22:51:39 John Poelstra wrote:
> This raised a few questions for me:
> 1) Is there a mechanism to know which of the bugs above must be fixed or
> FC7 to GA?
Nothing formal. As we start looking that way a few people generally shuffle
through the "Blocker" list to look for actual blockers and get rid of the
noise. Since there is no committee that decides what is or isn't a blocker
we can't just take every bug as an actual blocker.
We do actually have some guidelines for this:
http://fedoraproject.org/wiki/QA/ReleaseCriteria
Comments and suggestions gratefully accepted.
> 2) What process do we go through to close these bugs?
Really, that depends on the bug. Generally we fix it, or find a suitable work
around.
> 3) How does Fedora decide a release is ready to GA?
Release Engineering in conjunction with QA typically come to an agreement that
the tree is "good enough". Sometimes we have to kick decisions up to the
board on what to do about remaining issues.
Again, see the Release Criteria, and also the Tree Testing matrix:
http://fedoraproject.org/wiki/QA/TreeTestingTemplate
> 4) How are bugs from previous releases considered in the
planning process?
They aren't really, officially. We try to fix the big glaring ones
immediately after the release to prevent them from happening again the next
time. Some previous "blockers" are moved to the next blocker set to be
reviewed later.
Unlike with RHEL, there is no real good management of the blocker/target bugs
for Fedora.
The Release Criteria should help with this, but it would be good to have
slightly more work done on tracking bugs so we can do metrics and figure
out some guesses on how much we can actually handle in a given release.
I say "slightly more work" but there's actually a whole load of stuff
that would be required there: triaging, mass-moving bugs at release
time, gathering bug stats, helping enforce proper bug state changes,
etc.
If someone wants to be the official BugzillaKeeper, I'm sure we've all
got ideas on where that person could start.
-w
11:22 a.m.
On 22/03/07, Will Woods <wwoods(a)redhat.com> wrote:
We do actually have some guidelines for this:
http://fedoraproject.org/wiki/QA/ReleaseCriteria
I'm surprised that install to dmraid is classed as MUST, yet install
to mdraid isn't even mentioned as SHOULD.
Of course I'm biased by the fact that I currently can't achieve a
bootable mdraid1 installation
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230136
I've never known whether it's a tester's "job" to flag a bug as a
blocker, and allow developers to un-flag it where they disagree, or if
the developers prefer to triage the bugs themselves and do the
flagging.
2:57 p.m.
On 3/23/07, Andy Burns <fedora.lists(a)burns.me.uk> wrote:
On 22/03/07, Will Woods <wwoods(a)redhat.com> wrote:
> We do actually have some guidelines for this:
> http://fedoraproject.org/wiki/QA/ReleaseCriteria
I'm surprised that install to dmraid is classed as MUST, yet install
to mdraid isn't even mentioned as SHOULD.
good point I disagree on some others mentioned on this page too:
"Rescue mode SHOULD also be able to detect/mount RAID/LVM/dmraid/mdraid
installations"
no it MUST else we ship a release with a useless rescue mode for many setups
"All other services available in Core SHOULD start as well. "
if a service don't even start!! how could we even _think_ of shipping it?
and also update without reinstall should be a MUST....
4:49 p.m.
On Fri, 2007-03-23 at 20:57 +0100, dragoran dragoran wrote:
On 3/23/07, Andy Burns <fedora.lists(a)burns.me.uk> wrote:
On 22/03/07, Will Woods <wwoods(a)redhat.com> wrote:
> We do actually have some guidelines for this:
> http://fedoraproject.org/wiki/QA/ReleaseCriteria
I'm surprised that install to dmraid is classed as MUST, yet
install
to mdraid isn't even mentioned as SHOULD.
good point I disagree on some others mentioned on this page too:
"Rescue mode SHOULD also be able to detect/mount
RAID/LVM/dmraid/mdraid installations"
no it MUST else we ship a release with a useless rescue mode for many
setups
Did you actually read the big fat warning at the top of the page?
"Items described with the word "MUST" are required to work for all
releases, including Test releases. Additionally, the items described
with the word "SHOULD" are required for all final releases."
In short, "SHOULD" means "REQUIRED FOR FINAL RELEASE".
and also update without reinstall should be a MUST....
We're looking into it.
-w
2:48 a.m.
Will Woods wrote:
Did you actually read the big fat warning at the top of the page?
"Items described with the word "MUST" are required to work for all
releases, including Test releases. Additionally, the items described
with the word "SHOULD" are required for all final releases."
In short, "SHOULD" means "REQUIRED FOR FINAL RELEASE".
oops... sry ; so just ignore this mail please ;)
6241
days inactive
6243
days old
27 comments
12 participants
participants (12)
-
Andy Burns -
Dave Jones -
David Nielsen -
drago01 -
Hans de Goede -
Jarod Wilson -
Jesse Keating -
John Poelstra -
Josh Boyer -
Kevin Fenzi -
Matthias Clasen -
Will Woods