launchpad-dev team mailing list archive

[Bryce Harrington <bryce@xxxxxxxxxxxxx>]

On Tue, Jun 07, 2011 at 12:56:37PM +0100, Jonathan Lange wrote:
> On Thu, Jun 2, 2011 at 10:57 PM, Bryce Harrington <bryce@xxxxxxxxxxxxx> wrote:
> >
> ...
> > Some package maintainers may dislike the proposed change due to being
> > accustomed to having bugs auto-carried over.  It might be worthwhile
> > considering adding UI or tools to help address these needs.
> >
> 
> Good point. Would a command line tool, perhaps added as a part of
> ubuntu-dev-tools, be sufficient?

We probably need use cases defined.

The most common one I can think of is where a package is maintained by
Ubuntu engineers in Ubuntu and there is no separate upstream project
(for whatever reason).  So, when Ubuntu revs, there really is no reason
to think any of that package's bugs magically get solved, and not really
much point to require re-verification and re-targeting; this just adds
work and would be annoying.  (A similar use case exists for packages
with inactive or low-activity upstreams.)

For this use case a command line tool would be useful but probably not
seen as "sufficient", as the maintainers would need to think about
running this script every release or "lose" their bugs.  So, maintainers
would expect more of an opt-in checkbox to permanently turn on
"auto-promotion", or something, which would add new series to all open
bugs at the time the new series first opens.

In fact Launchpad might be able to identify these types of packages
programmatically by what ones aren't getting merges and don't have
upstream watches and so on.  Then the workaround could be selectively
applied to those packages without requiring maintainers having to think
about it.  Or, do the inverse and identify packages with fast moving
upstreams and apply the workaround everywhere else.  Or just apply the
workaround by default globally and let maintainers switch it off on a
case by case basis.

(Arguably, you'd probaby suggest that many of these types of packages
covered by this use case ought to be registered as upstream projects in
Launchpad.  I think that's probably true, and it's an interesting
question to ask why they're not.  Even if this is done I think the
essence of the original problem is still there.  But maybe it
generalizes the problem in an interesting way.)

Anyway, what do you think?  Colin Watson and Steve Langasek would
probably be good people to solicit feedback from for these oddball use
cases.

> ...
> > Presently in Ubuntu series nominations are often used for marking
> > "bugs with a fix worth backporting", and some package maintainers may
> > dislike the proposed change since this would be harder.  But use of
> > milestones should address this need, I think.
> >
> 
> Would we have to do something to help them adjust to using milestones?
> (Could be as simple as an announcement to ubuntu-dev)

Right, I don't think so.  This is probably more of a case where
education is sufficient.  I'd agree that raising this on ubuntu-devel@
to involve the userbase in the decision process could go a long way to
ensuring this change goes smoothly.  It isn't something you want to
surprise folks with.  ;-)

I would note that the current process of having to click 'Nominate for
series', wait on a page load, select from a list of series, and hit
apply is more mouse clicks than if the series was already present on the
bug (as will be the case >80% of the time), and you just needed to click
"Target to milestone" and pick.  So even in this case, this change makes
workflows more efficient for people.

> > Currently we tag bugs by release name.  If the proposed change is
> > implemented, it would be helpful to conduct a mass tag-to-nomination
> > change, to ensure bugs are properly targeted in the new system.
> >
> 
> That sounds like a thing we could help with / do as part of the migration.
> 
> > Anyway, this change could be a bit bumpy for Ubuntu but IMHO it ends up
> > providing a lot of benefit.
> >
> 
> Thanks for the great feedback!
> 
> jml

Bryce