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 09-23-2010, 11:58 AM
Adam Williamson
 
Default Review request: Nice-to-have bug process documentation proposal

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 nice-to-have process (and, incidentally, extend
documentation of the blocker process, since we don't seem to have much
of it beyond the blocker meeting SOP right now). All the pages can be
found here:

https://fedoraproject.org/wiki/Category:NTH_adjustment_drafts

it should be pretty obvious which are new and which are modifications of
existing pages. I hope this is mostly straightforward and
non-controversial.

A quick five-minute summary is that we will now have (in fact, we
already do) trackers for nice-to-have bugs for Alpha, Beta and Final
releases as well as trackers for blocker bugs. Bugs on these NTH lists
will be given priority after blocker bugs for QA, devel and releng work
for releases. Fixes for these bugs - and *only* these bugs, if a fix is
to be taken through a freeze, there must be a matching accepted NTH bug
- will be taken through release freezes. Proposing, reviewing and
monitoring NTH bugs will work exactly as it does for blocker bugs, and
mostly happen in the blocker meetings, but of course after consideration
of the blocker lists.

In practice this is a formalization of existing procedure - until F14
Beta, QA and releng did much the same process but entirely informally,
we just kept lists of bugs we'd take fixes for either in our heads or in
the RC creation trac tickets. This process is meant to be more robust,
documented and discoverable.

Some releng SOP pages may require minor updates, I figured I'd leave
that to releng. The process for creating blocker trackers should also be
updated to cover creating NTH trackers (I couldn't find that; poelcat,
where is it?)

Comments, questions, suggestions welcome!
--
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 09-24-2010, 08:22 PM
James Laska
 
Default Review request: Nice-to-have bug process documentation proposal

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 proposed new wiki pages and modifications to existing ones to
> document the nice-to-have process (and, incidentally, extend
> documentation of the blocker process, since we don't seem to have much
> of it beyond the blocker meeting SOP right now). All the pages can be
> found here:
>
> https://fedoraproject.org/wiki/Category:NTH_adjustment_drafts

Thanks for providing draft wiki edits with the proposal. I've made a
few _minor_ tweaks to the wiki pages.

> it should be pretty obvious which are new and which are modifications of
> existing pages. I hope this is mostly straightforward and
> non-controversial.
>
> A quick five-minute summary is that we will now have (in fact, we
> already do) trackers for nice-to-have bugs for Alpha, Beta and Final
> releases as well as trackers for blocker bugs. Bugs on these NTH lists
> will be given priority after blocker bugs for QA, devel and releng work
> for releases. Fixes for these bugs - and *only* these bugs, if a fix is
> to be taken through a freeze, there must be a matching accepted NTH bug
> - will be taken through release freezes. Proposing, reviewing and
> monitoring NTH bugs will work exactly as it does for blocker bugs, and
> mostly happen in the blocker meetings, but of course after consideration
> of the blocker lists.

I like the idea of formalizing the 'nice-to-have' process. I recall
tension during the F-13-RC phase regarding the decision making process
that allowed a selection of non-Blocker fixes into the release. I hope
that this process helps clarify the acceptable exceptions to the blocker
process.

> In practice this is a formalization of existing procedure - until F14
> Beta, QA and releng did much the same process but entirely informally,
> we just kept lists of bugs we'd take fixes for either in our heads or in
> the RC creation trac tickets. This process is meant to be more robust,
> documented and discoverable.

Perhaps the pending rel-eng SOP documents would cover this, but I'm
unclear how FXX-accepted bugs are treated during at compose time. For
our current 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 available in bodhi
updates-testing
* The bodhi update has received the required karma
* The accepted bug is in VERIFIED state?

To summarize, what instructions can we provide maintainers with so they
can be confident an tested, packaged and approved nice-to-have fix will
be pulled into any (re)compose? Perhaps, more of a question for the
release-engineering team.

Different topic ...

In the days of using *only* Blocker bugs, it's now somewhat confusing to
look at the F14Beta-accepted tracker, after we started mirroring
F14Beta, and see 12 open bugs (some trackers) [1]. I don't think this
is a bad thing, but perhaps another item to manage based on the result
of the go/no-go meeting ... move any pending FXX-accepted bugs into the
next milestone (so open FXXBeta-accepted bugs would move to
FXX-accepted)?

[1]
https://bugzilla.redhat.com/showdependencytree.cgi?id=F14Beta-accepted&hide_resolved=1

> Some releng SOP pages may require minor updates, I figured I'd leave
> that to releng. The process for creating blocker trackers should also be
> updated to cover creating NTH trackers (I couldn't find that; poelcat,
> where is it?)

https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Trackers


I assume "User:Adamwill/QA:SOP_blocker_bug_meeting_nth_draft" is
intended to replace "QA:SOP_Blocker_Bug_Meeting", and not define an
additional blocker review meeting?

I've queued
https://fedoraproject.org/wiki/User:Adamwill/QA:SOP_nth_process_nth_draft up for some additional reading, I'll reply later with any additional comments.

Thanks,
James
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-27-2010, 10:44 PM
Adam Williamson
 
Default Review request: Nice-to-have bug process documentation proposal

On Fri, 2010-09-24 at 16:22 -0400, James Laska wrote:

> > In practice this is a formalization of existing procedure - until F14
> > Beta, QA and releng did much the same process but entirely informally,
> > we just kept lists of bugs we'd take fixes for either in our heads or in
> > the RC creation trac tickets. This process is meant to be more robust,
> > documented and discoverable.
>
> Perhaps the pending rel-eng SOP documents would cover this, but I'm
> unclear how FXX-accepted bugs are treated during at compose time. For
> our current 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 available in bodhi
> updates-testing
> * The bodhi update has received the required karma
> * The accepted bug is in VERIFIED state?
>
> To summarize, what instructions can we provide maintainers with so they
> can be confident an tested, packaged and approved nice-to-have fix will
> be pulled into any (re)compose? Perhaps, more of a question for the
> release-engineering team.

So far, we haven't been that strict; the process has been that I've
listed any builds currently available in Koji which address nth issues
in the RC compose request ticket, and then it's been up to rel-eng to
take them or not. I agree we should nail this down a little better, and
your list seems reasonable (though I'd probably say it's not necessary
that the build be *available* in updates-testing, just that it have been
*submitted* there; waiting for an updates-testing compose is an
arbitrary limitation). Indeed this is probably something to co-ordinate
with releng's SOPs on.

> Different topic ...
>
> In the days of using *only* Blocker bugs, it's now somewhat confusing to
> look at the F14Beta-accepted tracker, after we started mirroring
> F14Beta, and see 12 open bugs (some trackers) [1]. I don't think this
> is a bad thing, but perhaps another item to manage based on the result
> of the go/no-go meeting ... move any pending FXX-accepted bugs into the
> next milestone (so open FXXBeta-accepted bugs would move to
> FXX-accepted)?

Yes, I meant to include that and forgot about it. Indeed this should be
the process.

> [1]
> https://bugzilla.redhat.com/showdependencytree.cgi?id=F14Beta-accepted&hide_resolved=1
>
> > Some releng SOP pages may require minor updates, I figured I'd leave
> > that to releng. The process for creating blocker trackers should also be
> > updated to cover creating NTH trackers (I couldn't find that; poelcat,
> > where is it?)
>
> https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Trackers
>
>
> I assume "User:Adamwill/QA:SOP_blocker_bug_meeting_nth_draft" is
> intended to replace "QA:SOP_Blocker_Bug_Meeting", and not define an
> additional blocker review meeting?

Yes. I considered creating a separate page detailing a 'nice-to-have
review meeting' and noting that in practice it could be combined with
the blocker meeting, but that just felt like over-engineering.

> I've queued
> https://fedoraproject.org/wiki/User:Adamwill/QA:SOP_nth_process_nth_draft up for some additional reading, I'll reply later with any additional comments.

Thanks!
--
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 10-06-2010, 05:32 PM
Adam Williamson
 
Default Review request: Nice-to-have bug process documentation proposal

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 proposed new wiki pages and modifications to existing ones to
> document the nice-to-have process (and, incidentally, extend
> documentation of the blocker process, since we don't seem to have much
> of it beyond the blocker meeting SOP right now). All the pages can be
> found here:
>
> https://fedoraproject.org/wiki/Category:NTH_adjustment_drafts

Thanks to James for his feedback on this. I haven't had much feedback
from anyone else. However, given that in practice everyone involved in
the release review process has been happy using the NTH system drafted
here so far, I intend to make the draft changes final (with
modifications to reflect James' feedback) by the end of the week, so if
you have any feedback you've been sitting on, now would be the perfect
time to send it Thanks everyone!
--
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 10-06-2010, 06:58 PM
John Poelstra
 
Default Review request: Nice-to-have bug process documentation proposal

Adam Williamson said the following on 10/06/2010 01:32 PM Pacific Time:
> 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 proposed new wiki pages and modifications to existing ones to
>> document the nice-to-have process (and, incidentally, extend
>> documentation of the blocker process, since we don't seem to have much
>> of it beyond the blocker meeting SOP right now). All the pages can be
>> found here:
>>
>> https://fedoraproject.org/wiki/Category:NTH_adjustment_drafts
>
> Thanks to James for his feedback on this. I haven't had much feedback
> from anyone else. However, given that in practice everyone involved in
> the release review process has been happy using the NTH system drafted
> here so far, I intend to make the draft changes final (with
> modifications to reflect James' feedback) by the end of the week, so if
> you have any feedback you've been sitting on, now would be the perfect
> time to send it Thanks everyone!

Can you be more specific as to which page we are actually giving
feedback on? There are five of them there and they almost all look the
same.

John
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-06-2010, 07:32 PM
Adam Williamson
 
Default Review request: Nice-to-have bug process documentation proposal

On Wed, 2010-10-06 at 14:58 -0400, John Poelstra wrote:
> Adam Williamson said the following on 10/06/2010 01:32 PM Pacific Time:
> > 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 proposed new wiki pages and modifications to existing ones to
> >> document the nice-to-have process (and, incidentally, extend
> >> documentation of the blocker process, since we don't seem to have much
> >> of it beyond the blocker meeting SOP right now). All the pages can be
> >> found here:
> >>
> >> https://fedoraproject.org/wiki/Category:NTH_adjustment_drafts
> >
> > Thanks to James for his feedback on this. I haven't had much feedback
> > from anyone else. However, given that in practice everyone involved in
> > the release review process has been happy using the NTH system drafted
> > here so far, I intend to make the draft changes final (with
> > modifications to reflect James' feedback) by the end of the week, so if
> > you have any feedback you've been sitting on, now would be the perfect
> > time to send it Thanks everyone!
>
> Can you be more specific as to which page we are actually giving
> feedback on? There are five of them there and they almost all look the
> same.

All of them. They're mostly modifications of existing pages. I'm not
quite sure how you get that they look the same, they're very different.

https://fedoraproject.org/wiki/User:Adamwill/Draft_desktop_results_nth_adjust is a proposed change to https://fedoraproject.org/wiki/QAesktop_validation_results_template .

https://fedoraproject.org/wiki/User:Adamwill/Draft_desktop_validation_nth_adjust is a proposed change to https://fedoraproject.org/wiki/QAesktop_validation_testing .

https://fedoraproject.org/wiki/User:Adamwill/QA:SOP_blocker_bug_meeting_nth_draft is a proposed change to https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting .

https://fedoraproject.org/wiki/User:Adamwill/QA:SOP_blocker_bug_process_nth_draft is a proposed new page; it's not particularly specific to the nice-to-have proposal, actually, it just became apparent while I was doing this that we have no page which explains the entire blocker bug review process, and we should have one. This is it.

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

I included a summary of the whole proposed NTH process in my initial
review request mail. These are the wiki changes necessary to document
that 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 10-07-2010, 03:07 PM
James Laska
 
Default Review request: Nice-to-have bug process documentation proposal

On Wed, 2010-10-06 at 12:32 -0700, Adam Williamson wrote:
> On Wed, 2010-10-06 at 14:58 -0400, John Poelstra wrote:
> > Adam Williamson said the following on 10/06/2010 01:32 PM Pacific Time:
> > > 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 proposed new wiki pages and modifications to existing ones to
> > >> document the nice-to-have process (and, incidentally, extend
> > >> documentation of the blocker process, since we don't seem to have much
> > >> of it beyond the blocker meeting SOP right now). All the pages can be
> > >> found here:
> > >>
> > >> https://fedoraproject.org/wiki/Category:NTH_adjustment_drafts
> > >
> > > Thanks to James for his feedback on this. I haven't had much feedback
> > > from anyone else. However, given that in practice everyone involved in
> > > the release review process has been happy using the NTH system drafted
> > > here so far, I intend to make the draft changes final (with
> > > modifications to reflect James' feedback) by the end of the week, so if
> > > you have any feedback you've been sitting on, now would be the perfect
> > > time to send it Thanks everyone!
> >
> > Can you be more specific as to which page we are actually giving
> > feedback on? There are five of them there and they almost all look the
> > same.
>
> All of them. They're mostly modifications of existing pages. I'm not
> quite sure how you get that they look the same, they're very different.

General note ... There are a few broken links on this page. I didn't
inspect *all* of them, but it looks like they will resolve once you've
moved the documents into their proposed locations. So probably not a
big deal, I can understand the desire to not change the links before and
after moving the pages into their final location.

> https://fedoraproject.org/wiki/User:Adamwill/Draft_desktop_results_nth_adjust is a proposed change to https://fedoraproject.org/wiki/QAesktop_validation_results_template .

Good stuff.

> https://fedoraproject.org/wiki/User:Adamwill/Draft_desktop_validation_nth_adjust is a proposed change to https://fedoraproject.org/wiki/QAesktop_validation_testing .

Same as above, equally as wholesome

> https://fedoraproject.org/wiki/User:Adamwill/QA:SOP_blocker_bug_meeting_nth_draft is a proposed change to https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting .
>
> https://fedoraproject.org/wiki/User:Adamwill/QA:SOP_blocker_bug_process_nth_draft is a proposed new page; it's not particularly specific to the nice-to-have proposal, actually, it just became apparent while I was doing this that we have no page which explains the entire blocker bug review process, and we should have one. This is it.

Funny how when you've been involved in a process for a while, you forget
which parts aren't clearly documented/described for others to engage.
Nice addition.

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

My first reaction looking at the proposed blocker and nth process SOP
pages was that they should be combined into a single page, since there
is a lot of duplicate document structure/format. But I can't think of
any good proposals to offer at the moment that make it better (not
worse). It seems you've already been down this route too.

Perhaps a reflection on my visual learning habit, I've been playing
around with some minor edits of the 2 previous wiki pages that make it a
bit easier for me to rapidly locate/grok information without too much
reading. Of course, let me know if the edits are too invasive or
detract from your intended message.

> I included a summary of the whole proposed NTH process in my initial
> review request mail. These are the wiki changes necessary to document
> that process.

Thanks,
James
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-07-2010, 05:24 PM
Adam Williamson
 
Default Review request: Nice-to-have bug process documentation proposal

On Thu, 2010-10-07 at 11:07 -0400, James Laska wrote:

> > All of them. They're mostly modifications of existing pages. I'm not
> > quite sure how you get that they look the same, they're very different.
>
> General note ... There are a few broken links on this page. I didn't
> inspect *all* of them, but it looks like they will resolve once you've
> moved the documents into their proposed locations. So probably not a
> big deal, I can understand the desire to not change the links before and
> after moving the pages into their final location.

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 review process.
>
> My first reaction looking at the proposed blocker and nth process SOP
> pages was that they should be combined into a single page, since there
> is a lot of duplicate document structure/format. But I can't think of
> any good proposals to offer at the moment that make it better (not
> worse). It seems you've already been down this route too.

Yeah, I went back and forth. If you make them one page some of the
phrasing gets very long and clunky and possibly hard to parse, I was
happier with it as two pages.

> Perhaps a reflection on my visual learning habit, I've been playing
> around with some minor edits of the 2 previous wiki pages that make it a
> bit easier for me to rapidly locate/grok information without too much
> reading. Of course, let me know if the edits are too invasive or
> detract from your intended message.

Thanks, I'll revert them all later
--
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 10-08-2010, 11:12 AM
John Poelstra
 
Default Review request: Nice-to-have bug process documentation proposal

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 page covers the blocker review process.

Thanks for doing all this Adam.

The "Nice-to-have bug principles" guidelines feels a little mushy and
subjective to me, though after thinking about it for a while I can't
propose anything better--you've done a good job putting some structure
around what they might be.

And since they can't block the release they won't be able to cause that
many problems. I suppose if NTH bugs were to ever become a big
distraction from addressing blocker bugs we could re-evaluate.

On the other hand it has taken us a *long* time to get to the place
where we are today where churn in RC has been reduced to a bare minimum.
I still subscribe to the theory (realizing some in Fedora don't) that
every additional change adds a level of risk of delaying the release.
So my hope is that by formalizing the NTH we aren't encouraging an
increased amount of churn.

I DO 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 becomes 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)."

Would it be overkill to put more explicit testing sign-off around NTH bugs?

John
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-08-2010, 03:23 PM
James Laska
 
Default Review request: Nice-to-have bug process documentation proposal

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 nice-to-have review process much as the above proposed page covers the blocker review process.
>
> Thanks for doing all this Adam.
>
> The "Nice-to-have bug principles" guidelines feels a little mushy and
> subjective to me, though after thinking about it for a while I can't
> propose anything better--you've done a good job putting some structure
> around what they might be.
>
> And since they can't block the release they won't be able to cause that
> many problems. I suppose if NTH bugs were to ever become a big
> distraction from addressing blocker bugs we could re-evaluate.
>
> On the other hand it has taken us a *long* time to get to the place
> where we are today where churn in RC has been reduced to a bare minimum.
> I still subscribe to the theory (realizing some in Fedora don't) that
> every additional change adds a level of risk of delaying the release.
> So my hope is that by formalizing the NTH we aren't encouraging an
> increased amount of churn.
>
> I DO 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 becomes 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)."
>
> 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 be included. But as noted in a previous mail, I
*think* this might be something that release engineering will need to
specify on their documentation regarding how to compose release
candidates (jkeating or dgilmore can correct me here). Is there an SOP
for that process now?

Another distinction to consider
1. Using the language you noted earlier that "[NTH] bugs are
usually bugs for which an update is not an optimal solution".
To me this implicitly states that NTH packages must be on the
media. If it's not on the media, it's not eligible.
2. Extending the above ... I wonder if it's reasonable that NTH
cannot be accepted for critical path components. For critical
path, it's a blocker or not, let's not fiddle with critpath if a
respin is needed to address blocker issues.

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

Thread Tools




All times are GMT. The time now is 02:57 PM.

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