needs-packaging Example

[Reinhard Tartler]

"Emmet Hikory" <persia at ubuntu.com> writes:

>> That about sums up what I've read here. Also, valid statuses are: New,
>> In Progress, Fix released, or Invalid. Other statuses have no use on
>> needs-packaging bugs.
>
>     What meaning is attached to "Invalid"?  Also, might we want "Won't
> Fix" when there is a request for packaging of something that has a
> license that prohibits distribution (which status could be changed if
> the upstream licensing changed).

TBH, these cases would apply to me as 'invalid'.  'wontfix' is a
restricted status to triagers and developers, and I see no reason to
prevent random users to put their request to this state.

In the end, a 'need-packaging' bug is not a real bug report, but rather
a packaging request. It has basically 3 states, with two being final:

 - package is waiting to for someone to package it (new)
 - the package has reached the archive (fixreleased, final)
 - the software cannot or should not be packaged (license reasons,
   obsoleted software, is buggy/unmaintainable etc.) (invalid, final)

I'd like to reduce the number of statuses we use on 'needs-packaging'
bugs to a minimum to reduce complexity in this process.

> Additionally, I like the use of "Fix Committed" to indicate that a
> package has been reviewed and uploaded to the archive, but is
> currently in the NEW queue: this is helpful to indicate where to seek
> a package, especially as the common procedure is to archive a package
> from REVU when it is uploaded, even though the archive-admins may be
> very busy, and might take a couple weeks to accept the package.

Indeed, this could be done, I think this should be done automatically by
soyuz then with a proper message in the bug. If we agree on a
'needs-packaging' bug procedure, I will file a bug against launchpad
requesting this.

>     That said, "Incomplete" isn't a very interesting status for a
> needs-packaging bug; although the bug report may be incomplete (not
> have upstream homepage, not have license stated, etc.), we never want
> these to expire.

The only case where I can remotely imagine that the status 'incomplete'
might make sense is the case that the submitter mentiones a software
which cannot be found by google. I'd expect this particular case to be
so pathological that I wouldn't explicitly mention it in the
documentation, but rather just close such reports. If the submitter
really cares, he can still set the bug from 'invalid' back to 'new' again.

>  Where a needs-packaging bug is not assigned, using Google to complete
> the bug report is a very useful triage action, as this often provides
> enough context that someone looking for something to package will be
> able to review the bug.

Indeed, this could motivate potential packagers.

>     Thinking on that, "Triaged" might be a good way to indicate that a
> given needs-packaging bug does have all the right information, and
> that further information is not required prior to assignment to a
> packager.

With 'triaged' being a restricted status, this might make sense. However
I don't really see the benefit for that. It's not like motu's are
continuely looking at all bugs not assigned to any package tagged
'needs-packaging' in status 'triaged' and start packaging random
crack. That's why I don't think the triaging documentation should
mandate this status, it's just waste of time doing this, IMO.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4