Null Ack wrote:
> On 27th of June I asked the MOTU mail list what it was and advised
> "The correct way to do this is to file a bug against the package and
> tag it "upgrade"." Since I've done this for 6+ bugs.
This is indeed the documented current process.
> Yesterday I filed two bugs complying with this, one of them was a MOTU
> package not a core dev one, and I was advised in the bug comments that
> "there is no need to open new version update request". Also when I
> asked a dev who's interested in this function area (video) on IRC if
> he could confirm the bug he felt it was'nt useful to bug upgrade
> requests.
There are a few cases where someone working on a package in Ubuntu
is also closely involved with upstream, and is actively pushing
upgrades as they appear (assuming the upgrade in question is
compatible with the current state of the development repositories).
In these cases, filing an upgrade bug has little benefit, as the
package upgrde will likely happen as soon as it would be feasible
regardless of the presence of a bug. In these cases, the filing of
such a bug has little benefit, as it does not identify work that was
not known to be needed. That said, it also carries little penalty,
other than the need for such a person to identify the bug number for
the upgrade bug when preparing the next update.
There are a much larger number of cases where nobody gets around
to upgrading the package in question, and perhaps a newer version is
imported from Debian during the autosync run at the beginning of the
next cycle. In these cases, it requires extra work for the triagers
to identify that the bug has now been addressed (without direct human
intervention), and mark it closed.
Some people consider the extra work of closing the upgrade bugs to
be sufficient that it's not worth having them filed. Others find that
having the upgrade bugs is indeed useful, and that it provides them
with a list of work to be done. Personally, I find upgrade bugs to be
most useful for packages where there has been no update in some time,
and for which there is no watch file, so automated identification of
newer upstream versions cannot be performed, and to rely on either
Debian or UEHS (1) in other cases.
1: http://qa.ubuntuwire.com/uehs/
--
Emmet HIKORY
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
