Upstream bug tasks assigned to MPs should be marked as "Fix Committed" after merge

[Marco Trevisan (Treviño)]

In unity7 we track bugs for the upstream project and the ubuntu package separately.

When we do releases with ci-train, the bugs assigned to the selected merge proposals aren't correctly updated, in fact while the downstream side is correctly marked as "Fix Released", the upstream task is not marked as "Fix Committed" as soon as the related branch is merged.

[Robert Bruce Park (robru)]

Ah yes, the code that did this had been broken for a very long time (over a year) and nobody had complained about it so i just deleted it instead of fixing it. I'll look into resurrecting that now that i see somebody is actually wanting this.

[Marco Trevisan (Treviño) (3v1n0)]

Great!

I guess it's a little bit trickier when not targeting trunk, and then you've to mark the task that is linked to that series (if any), but even a simple version would be nice to avoid me to do this half-manually every time. :)

[Robert Bruce Park (robru)]

Can you show me an example merge proposal with the bugs you want closed?

And can you tell me more specifically exactly what you want to happen? Like the train should detect if a bug has both an packaging bug & upstream bug and set the upstream status to match the packaging status?

[Robert Bruce Park (robru)]

This was the code I was thinking of that was broken for a long time that I dropped instead of fixing:

http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro/trunk/revision/1013#cupstream2distro/launchpadmanager.py

Basically in every log it would just say "Failed to sync..." so I got rid of it. That was removed 15 months ago, and was broken even for a long time before that, and nobody complained in all this time. Is that the feature you want restored? Or are you asking for something new? I thought from the IRC log that you thought the train already had this feature but I'm not sure if this code does quite what you're asking for.

[Robert Bruce Park (robru)]

Trying to understand that code a bit more. It looks like it takes bugs that only have upstream components and then also adds the ubuntu source package for those bugs. Not quite what you're asking I think.

What you want is for the train to mark all the bugs on an MP as "Fix Committed" when the branch merges? I can do that but I don't recall the train ever having a feature like that (the thing about the ubuntu package bug getting marked 'Fix Released' is done by LP itself, train doesn't do that at all).

[Marco Trevisan (Treviño) (3v1n0)]

No, I never saw this in the CI-train, I'm sure it was there at time we had the auto-lander (when branches were merged as soon as they were top-approved). I think didrocks might know better the internals of that.

However, examples of MPs...
 - under review: lp:~3v1n0/unity/force-resize-gtk-icons/+merge/273313

What I expect when a such MP gets processed by train is
 1) When the package is built and released:
   - Downstream task for bugs #1446081 and #1501973
      (now they're duplicated here, but let's pretend they're not) is marked
      as "Fix Released"
 2) When the MP is merged with trunk (or with any other series):
   - Upstream task (targeting trunk or the matching series) for bugs #1446081
      and #1501973 should be marked as "Fix Committed".

Right now 1) works well, but there's no kind of 2) (so the same I manually did with lp:~3v1n0/unity/gnome-keygrabber-refactor/+merge/272858) implemented.

[Marco Trevisan (Treviño) (3v1n0)]

Ah, something quite raw I use for match upstream and downstream bugs is here:
 - http://bazaar.launchpad.net/~unity-team/+junk/bugtools/view/head:/lp-unity-bug-updown-match.py

[Robert Bruce Park (robru)]

How can i know which branch is for which series without hard-coding
lp:unity branch names?

It seems it would be easy to mark whole bugs as fixed when merging but i
don't see how to determine which bug task is the correct one for the given
series being merged.

[Marco Trevisan (Treviño) (3v1n0)]

Can't you check wether the task is targeted to a "trunk" series (or other generic names used fo that)? It should be the common name for dev branch.

[Robert Bruce Park (robru)]

Well that would work to say whether a branch is trunk or not but there's no
way i know of to correlate a series branch with the series it's for,
because there's no standard naming scheme for that. Some people use the
series name, some the series version, and there's a lot of variation too.
On Oct 5, 2015 6:30 PM, "Marco Trevisan (Treviño)" <[e-mail]> wrote:

> Can't you check wether the task is targeted to a "trunk" series (or
> other generic names used fo that)? It should be the common name for dev
> branch.
>
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/1502897
>
> Title:
> Upstream bug tasks assigned to MPs should be marked as "Fix Committed"
> after merge
>
> Status in CI Train [cu2d]:
> Incomplete
>
> Bug description:
> In unity7 we track bugs for the upstream project and the ubuntu
> package separately.
>
> When we do releases with ci-train, the bugs assigned to the selected
> merge proposals aren't correctly updated, in fact while the downstream
> side is correctly marked as "Fix Released", the upstream task is not
> marked as "Fix Committed" as soon as the related branch is merged.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/cupstream2distro/+bug/1502897/+subscriptions
>

[Marco Trevisan (Treviño) (3v1n0)]

> Well that would work to say whether a branch is trunk or not but there's no
> way i know of to correlate a series branch with the series it's for,
> because there's no standard naming scheme for that. Some people use the
> series name, some the series version, and there's a lot of variation too.

That's right... Well, having this automated at least for trunk
landings would be a very nice addition. I was guessing that doing this
kind of matching would have been a little tricky, but I thought that
using the `branch_link` from https://api.launchpad.net/devel/unity/7.3
or https://api.launchpad.net/devel/unity/7.2 would have been enough.