Needs Packaging bug reports

[Emmet Hikory]

Fabian Rodriguez wrote:
> Brian Murray wrote:
>> As a part of the managing needs-packaging bug reports specification[1]
>> it was decided that all needs-packaging bug reports should have an
>> importance of wishlist.  Subsequently, I've written a script using the
>> Launchpad API that will set the importance of almost all needs-packaging
>> bugs to wishlist.
> 
> 
> I see some needs-packaging bug reports will not be given enough
> importance if this change goes through. For example:
> https://bugs.launchpad.net/ubuntu/+bug/120576
> 
> As a bug reviewer I'd probable go back and make this kind of bug
> Importance: Medium.

    Why would this be "Medium"?  In general, we've historically taken
the attitude that Ubuntu is (mostly) complete, and adding new things,
while possibly desirable, does not represent a measurable defect in the
existing system (hence Wishlist).  As much as some needs-packaging bugs
are probably more important than others, I'm not sure that this
variation is best tracked as bugs, and believe that Wishlist accurately
reflects the defect concerned when these requests are tracked as bugs.

    That said, there exist a class of bugs that are meaningful defects
(e.g. spellchecker cannot handle Canadian English) which might be best
solved by adding a new package, but I'm not sure we want to track the
defect and the desire for the package the same way.  In the specific
case of 120576, I'd probably consider the OpenOffice task Medium, but
the Ubuntu needs-packaging task Wishlist.  Moreso, in this case, I'm not
sure how 120576 is not duplicate to 44100.  We probably ought determine
how we want to track these pairs better: are they duplicates?  Should
one be used to track the problem, and the other the addition of a new
package as a solution?

   In some ideal world, we'd have a more comprehensive workflow for
package requests, where requestors would register the request along with
the upstream URL and license information.  This would then receive
manual review by someone, who would draft debian/copyright and
debian/watch to pull the file.  These approved packages would then be
available in a queue for people to add debian/control, debian/rules, and
debian/copyright (along with any other supplemental files), which would
then feed into something like REVU.  While there's no reason that the
same person couldn't do both these things, initial verification of the
licensing and setup of the watch file are things which typically do not
require the same level of knowledge of packaging as the control or rules
files.  Such a system could ideally be referenced from Malone to
indicate that a potential solution for a bug exists as packaging work in
progress, and perhaps reference Malone to indicate which bugs are
attempted to be fixed by the inclusion of a package.

    Unfortunately, this requires someone to design and administer such a
system, and migration of current outstanding requests.  Until then, we
use bugs, and as they aren't really defects, we give them an importance
of Wishlist, although we may prioritise certain packages to meet other
goals (either planned feature goals or to address discovered defects
that manifest in another package).

-- 
Emmet HIKORY