On Tue, 2013-01-22 at 19:30 -0800, Adam Williamson wrote:
> The 'new style' tracker bug aliases are as follows:
>
> AlphaBlocker
> AlphaFreezeException
> BetaBlocker
> BetaFreezeException
> FinalBlocker
> FinalFreezeException
> Versioned aliases will still be applied to all the tracker bugs, so
> There was a very solid consensus that the old scheme sucked and the
> final form of the new proposal was miles better, and this is not the
> first time the topic has come up (there are various proposals in the
> list archives). So I decided to go ahead and Just Do It, putting the
> proposal into
Thanks and support+1:).
- Original Message -
From: "Adam Williamson"
To: test@lists.fedoraproject.org, de...@lists.fedoraproject.org
Sent: Tuesday, January 22, 2013 10:30:25 PM
Subject: 'Nice to have' process is now 'Freeze exception' process,
im
On Tue, Jan 22, 2013 at 19:30:25 -0800,
Adam Williamson wrote:
There was a very solid consensus that the old scheme sucked and the
final form of the new proposal was miles better, and this is not the
first time the topic has come up (there are various proposals in the
list archives). So I dec
On Tue, 2013-01-22 at 19:30 -0800, Adam Williamson wrote:
> I can think of a couple of potential issues with the 'dynamic' tracker
> names (I'm not sure whether nominations will 'transfer' from one release
> to the next when we change where the alias points, and if so, whether we
> want that, espe
Hey folks!
At FUDCon Lawrence, Tim Flink presented on the Fedora blocker bug and
'NTH' processes, and we got some interesting and useful feedback. People
felt that the 'nice to have' / 'accepted' name used in that process was
confusing and difficult to understand,
On Fri, 2012-05-11 at 21:58 -0700, Rob Healey wrote:
> Hello...
>
> This is a bug that has been around since the very biginning of F17,
> and it is still here...
>
> It is NOT life-threathening or a crasher of any sort, but it is
> irritating nevertheless...
One of the key definitions of an NTH
Hello...
This is a bug that has been around since the very biginning of F17, and it
is still here...
It is NOT life-threathening or a crasher of any sort, but it is irritating
nevertheless...
Here it is...
[root@RockingRobin metacity-1]# gedit metacity-theme-3.xml
(gedit:1987): Gtk-WARNING **:
s for tracking
nice-to-have bugs live. (We've actually been applying the system in practice
since F14 Beta, and it's been working well). This also involved creating a page
to document the blocker bug process, since we didn't have one before.
The new pages are:
https://fe
progressively more important as a release nears,
so bugs may be downgraded from nice-to-have status late in the release
process if it transpires that the fix is complex and hard to test)"
it's always been a trade-off between how much benefit we get from taking
the fix and how compl
On Fri, 2010-10-08 at 12:42 -0700, Adam Williamson wrote:
> On Fri, 2010-10-08 at 11:23 -0400, James Laska wrote:
>
> > > Would it be overkill to put more explicit testing sign-off around NTH
> > > bugs?
> >
> > I don't see why not. I think this topic came up in a previous mail.
> > I'd propose
On Fri, 2010-10-08 at 11:23 -0400, James Laska wrote:
> > Would it be overkill to put more explicit testing sign-off around NTH bugs?
>
> I don't see why not. I think this topic came up in a previous mail.
> I'd propose that NTH bugs must be tested and have appropriate bodhi
> karma for them to
On Fri, 2010-10-08 at 07:12 -0400, John Poelstra wrote:
> Adam Williamson said the following on 10/07/2010 01:24 PM Pacific Time:
> >>> https://fedoraproject.org/wiki/User:Adamwill/QA:SOP_nth_process_nth_draft
> >>> is a proposed new page which covers the whole
think this is an important section in the guidelines that will help
> cover this concern:
>
> "In general, nice-to-have bugs are usually bugs for which an update is
> not an optimal solution, and for which the fix is reasonably small and
> testable (this consideration become
Adam Williamson said the following on 10/07/2010 01:24 PM Pacific Time:
>>> https://fedoraproject.org/wiki/User:Adamwill/QA:SOP_nth_process_nth_draft
>>> is a proposed new page which covers the whole nice-to-have review process
>>> much as the above proposed pag
cation.
Yeah, they'll work after the pages are all put live.
> > https://fedoraproject.org/wiki/User:Adamwill/QA:SOP_nth_process_nth_draft
> > is a proposed new page which covers the whole nice-to-have review process
> > much as the above proposed page covers the blocker
veryone. So we partly used the proposed new nice-to-have bug
> > >> tracking system during the F14 Beta process, and it seemed to go well.
> > >> In a quick burst of airport productivity, I've quickly written up a
> > >> bunch of proposed new wiki pages
On Thu, 2010-09-23 at 12:58 +0100, Adam Williamson wrote:
> Hi, everyone. So we partly used the proposed new nice-to-have bug
> tracking system during the F14 Beta process, and it seemed to go well.
> In a quick burst of airport productivity, I've quickly written up a
> bunch of
nt Blocker bug process, it's established that if the
> appropriate blocker bug list is not empty, we can't compose. With
> non-blocker nice-to-have (NTH) bugs, how would that fix get into a
> compose?
>
> Guessing ...
> * The fix would have to be packaged and avai
On Thu, 2010-09-23 at 12:58 +0100, Adam Williamson wrote:
> Hi, everyone. So we partly used the proposed new nice-to-have bug
> tracking system during the F14 Beta process, and it seemed to go well.
> In a quick burst of airport productivity, I've quickly written up a
> bunch of
Hi, everyone. So we partly used the proposed new nice-to-have bug
tracking system during the F14 Beta process, and it seemed to go well.
In a quick burst of airport productivity, I've quickly written up a
bunch of proposed new wiki pages and modifications to existing ones to
document the ni
Seems like a fine idea if the release engineering people actually use it
and the overhead to maintain it isn't excessive.
It would be nice to eliminate the "nice to have" in a different sense
bug trackers - like F15Target (which isn't currently blocking anything)
to prevent
ays disabled on startup
>> https://bugzilla.redhat.com/show_bug.cgi?id=634205
>
> That's on the list already.
Sweet :)
>> ghostscript error printing PDF with image.
>> https://bugzilla.redhat.com/show_bug.cgi?id=633848
>
> Mmmf...printing stuff can be handled fine with updat
That's on the list already.
> ghostscript error printing PDF with image.
> https://bugzilla.redhat.com/show_bug.cgi?id=633848
Mmmf...printing stuff can be handled fine with updates. One of the main
guidelines for nice-to-have bugs that we have followed so far (without
writing it do
I'd like to see these as nice-to-be-fixed bugs before F14 - otherwise
F13 will be a more polished release than F14 imho...
Bluetooth always disabled on startup
https://bugzilla.redhat.com/show_bug.cgi?id=634205
ghostscript error printing PDF with image.
https://bugzilla.redhat.com/show_bug.cgi?i
Hi, everyone. I'd just like to point up a new process we just put in
place: tracking nice-to-have bugs for pre- and final releases.
Sorry not to have proposed this on the list, but I wanted to try and get
it done for the Beta so I just went ahead and put it in. The idea is to
track bugs
26 matches
Mail list logo
