The unifdef package had become orphaned due to an FTBFS, https://bugzilla.redhat.com/show_bug.cgi?id=51153. I took it over, updated it to the latest upstream code, verified that it builds with Koji, and committed it. I'm not sure what to do about the Status field of the bug. I looked for relevant documentation on the bug lifecycle or practices in the Fedora wiki, but didn't really find anything useful. Is there such documentation? And if not, to what should I set the bug status?
Thanks! Eric
On Thu, Feb 11, 2010 at 05:36:23PM -0800, Eric Smith wrote:
The unifdef package had become orphaned due to an FTBFS, https://bugzilla.redhat.com/show_bug.cgi?id=51153. I took it over, updated it to the latest upstream code, verified that it builds with Koji, and committed it. I'm not sure what to do about the Status field of the bug. I looked for relevant documentation on the bug lifecycle or practices in the Fedora wiki, but didn't really find anything useful. Is there such documentation? And if not, to what should I set the bug status?
Looks like you've linked to the wrong bug.
From the description, it now builds from source, at least in rawhide. I think you want to Close Rawhide in that case.
-Toshio
Toshio Kuratomi wrote:
Looks like you've linked to the wrong bug.
Sorry, it was a typo. The correct bug is https://bugzilla.redhat.com/show_bug.cgi?id=511553
From the description, it now builds from source, at least in rawhide. I think you want to Close Rawhide in that case.
Great, thanks!
Eric
On Thu, Feb 11, 2010 at 05:36:23PM -0800, Eric Smith wrote:
The unifdef package had become orphaned due to an FTBFS, https://bugzilla.redhat.com/show_bug.cgi?id=51153. I took it over, updated it to the latest upstream code, verified that it builds with Koji, and committed it. I'm not sure what to do about the Status field of the bug. I looked for relevant documentation on the bug lifecycle or practices in the Fedora wiki, but didn't really find anything useful. Is there such documentation? And if not, to what should I set the bug status?
http://fedoraproject.org/wiki/FTBFS
has the process. CLOSED RAWHIDE generally.
However, check if unifdef is really needed. The kernel team knew it was going to be orphaned, and said "that's OK, as the kernel tree has its own copy that's maintained there." or somesuch. If not, letting it stay dead is fine - desireable in fact.
Matt Domsch wrote:
However, check if unifdef is really needed. The kernel team knew it was going to be orphaned, and said "that's OK, as the kernel tree has its own copy that's maintained there." or somesuch. If not, letting it stay dead is fine - desireable in fact.
What is the criteria for whether a Fedora package is "really needed" and for which staying dead is "desirable"? I picked it up because I use it myself; I had no idea that it had anything whatsoever to do with the "kernel team", and I don't have any use for a "copy that's maintained there".
Thanks, Eric
On Thu, Feb 11, 2010 at 10:42:04PM -0800, Eric Smith wrote:
Matt Domsch wrote:
However, check if unifdef is really needed. The kernel team knew it was going to be orphaned, and said "that's OK, as the kernel tree has its own copy that's maintained there." or somesuch. If not, letting it stay dead is fine - desireable in fact.
What is the criteria for whether a Fedora package is "really needed" and for which staying dead is "desirable"? I picked it up because I use it myself; I had no idea that it had anything whatsoever to do with the "kernel team", and I don't have any use for a "copy that's maintained there".
If you need/use it and want to maintain it, you are free to do so. If the kernel team knows a better alternative that you should consider, then the package should be retired instead of just orphaned and an explanation about why it was retired should be added to a dead.package file in the CVS devel branch. Usually the latter is not done, so you can only ask the previous maintainers. Nevertheless, having a "copy that's maintained there" sounds like bad packaging practice.
Regards Till
On Fri, 2010-02-12 at 10:38 +0100, Till Maas wrote:
If you need/use it and want to maintain it, you are free to do so. If the kernel team knows a better alternative that you should consider, then the package should be retired instead of just orphaned and an explanation about why it was retired should be added to a dead.package file in the CVS devel branch. Usually the latter is not done, so you can only ask the previous maintainers. Nevertheless, having a "copy that's maintained there" sounds like bad packaging practice.
Regards Till
Maybe it was retired or orphaned because unifdef was superseded by sunifdef (which is packaged in fedora), which is now superseded by coan [1] (which is not yet packaged in fedora)?
Krzesimir
Krzesimir Nowak wrote:
Maybe [unifdef] was retired or orphaned because unifdef was superseded by sunifdef (which is packaged in fedora), which is now superseded by coan [1] (which is not yet packaged in fedora)?
Krzesimir
OK, I've submitted a coan package for review:
https://bugzilla.redhat.com/show_bug.cgi?id=565251
(and if anyone has a bit of spare time, I could also use reviewers for meshlab [1], which I packaged because it's useful when working with 3D printers, and the Free42 calculator [2].)
Eric
[1] https://bugzilla.redhat.com/show_bug.cgi?id=561243 [2] https://bugzilla.redhat.com/show_bug.cgi?id=560380
On Thu, 2010-02-11 at 17:36 -0800, Eric Smith wrote:
The unifdef package had become orphaned due to an FTBFS, https://bugzilla.redhat.com/show_bug.cgi?id=51153. I took it over, updated it to the latest upstream code, verified that it builds with Koji, and committed it. I'm not sure what to do about the Status field of the bug. I looked for relevant documentation on the bug lifecycle or practices in the Fedora wiki, but didn't really find anything useful. Is there such documentation? And if not, to what should I set the bug status?
The bug lifecycle documentation is here:
https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow
it's linked extensively from the Bugzilla HOWTO, the QA Wiki section, and also if you get to https://bugzilla.redhat.com/page.cgi?id=fields.html by clicking on a field name in a bug, it has a note at the top - "Note: Bugs reported against Fedora products have a slightly different life cycle which is described in more detail here." - with a link to the Fedora page.
Adam Williamson wrote:
The bug lifecycle documentation is here:
https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow
it's linked extensively from the Bugzilla HOWTO, the QA Wiki section, and also if you get to [...]
Great, thanks! Now I feel really dumb for not having found it on my own, but somehow my efforts at searching the wiki didn't turn it up.
Eric
On Sat, 2010-02-13 at 20:28 -0800, Eric Smith wrote:
Adam Williamson wrote:
The bug lifecycle documentation is here:
https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow
it's linked extensively from the Bugzilla HOWTO, the QA Wiki section, and also if you get to [...]
Great, thanks! Now I feel really dumb for not having found it on my own, but somehow my efforts at searching the wiki didn't turn it up.
I should probably stick the word 'lifecycle' into it somewhere, as it doesn't really show up if you search for that.
It's also worth noting that mediawiki's internal search really isn't that great. I tend to search Google with 'site:fedoraproject.org' instead of using the mediawiki search, it seems to do better.
On Mon, Feb 15, 2010 at 21:01, Adam Williamson awilliam@redhat.com wrote:
It's also worth noting that mediawiki's internal search really isn't that great. I tend to search Google with 'site:fedoraproject.org' instead of using the mediawiki search, it seems to do better.
IIRC Mediawiki can't separate words, i.e it won't see « bug » or « status » in the title of a page called « BugStatus ».
Using natural language in page title should help, for example « Bug status workflow ». (yes Mediawiki can deal with spaces in URL)
---------- Mathieu Bridon
On Mon, 2010-02-15 at 21:08 +0100, Mathieu Bridon wrote:
On Mon, Feb 15, 2010 at 21:01, Adam Williamson awilliam@redhat.com wrote:
It's also worth noting that mediawiki's internal search really isn't that great. I tend to search Google with 'site:fedoraproject.org' instead of using the mediawiki search, it seems to do better.
IIRC Mediawiki can't separate words, i.e it won't see « bug » or « status » in the title of a page called « BugStatus ».
Using natural language in page title should help, for example « Bug status workflow ». (yes Mediawiki can deal with spaces in URL)
I know, but there's a lot of pages which have CamelCase names and I don't want to start renaming them haphazardly. There are risks to renaming Wiki pages.
On 15 February 2010 21:08, Adam Williamson awilliam@redhat.com wrote:
On Mon, 2010-02-15 at 21:08 +0100, Mathieu Bridon wrote:
On Mon, Feb 15, 2010 at 21:01, Adam Williamson awilliam@redhat.com wrote:
It's also worth noting that mediawiki's internal search really isn't that great. I tend to search Google with 'site:fedoraproject.org' instead of using the mediawiki search, it seems to do better.
IIRC Mediawiki can't separate words, i.e it won't see « bug » or « status » in the title of a page called « BugStatus ».
Using natural language in page title should help, for example « Bug status workflow ». (yes Mediawiki can deal with spaces in URL)
I know, but there's a lot of pages which have CamelCase names and I don't want to start renaming them haphazardly. There are risks to renaming Wiki pages. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net
But you can have page aliases in Media Wiki, right?
On Tue, 2010-02-16 at 12:52 +0000, Mat Booth wrote:
But you can have page aliases in Media Wiki, right?
Aliases? I don't know. MW automatically sets up redirects when you move a page, but it breaks at more than one level of nesting (so if you rename a page twice, trying to access the *first* name doesn't work any more, unless you manually fix the redirect).
On 16 February 2010 18:43, Adam Williamson awilliam@redhat.com wrote:
On Tue, 2010-02-16 at 12:52 +0000, Mat Booth wrote:
But you can have page aliases in Media Wiki, right?
Aliases? I don't know. MW automatically sets up redirects when you move a page, but it breaks at more than one level of nesting (so if you rename a page twice, trying to access the *first* name doesn't work any more, unless you manually fix the redirect).
Ah, redirects must have been what I was thinking of.