documentation on Bugzilla bug lifecycle/developer procedures?

[Eric Smith]

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

[Toshio Kuratomi]

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

[Eric Smith]

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

[Matt Domsch]

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
Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux

[Eric Smith]

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

[Till Maas]

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

[Krzesimir Nowak]

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

[1] http://coan2.sourceforge.net/

Coan package for review (was Re: documentation on Bugzilla bug lifecycle/developer procedures?)

[Eric Smith]

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
>
>  [1] http://coan2.sourceforge.net/
>     
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

[Adam Williamson]

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
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

[Eric Smith]

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

[Adam Williamson]

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.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

[Mathieu Bridon]

On Mon, Feb 15, 2010 at 21:01, Adam Williamson <awilliam(a)redhat.com&gt; 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

[Adam Williamson]

On Mon, 2010-02-15 at 21:08 +0100, Mathieu Bridon wrote:
>  On Mon, Feb 15, 2010 at 21:01, Adam Williamson
> <awilliam(a)redhat.com&gt; 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

[Mat Booth]

On 15 February 2010 21:08, Adam Williamson <awilliam(a)redhat.com&gt; wrote:
>  On Mon, 2010-02-15 at 21:08 +0100, Mathieu Bridon wrote:
> > On Mon, Feb 15, 2010 at 21:01, Adam Williamson <awilliam(a)redhat.com&gt; 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?

-- 
Mat Booth

[Adam Williamson]

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).
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

[Mat Booth]

On 16 February 2010 18:43, Adam Williamson <awilliam(a)redhat.com&gt; 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.


-- 
Mat Booth