please allow targeting a series and set a milestone

[Matthias Klose]

please allow targeting a series and set a milestone

[Mattias Backman (mabac)]

Would it be safe to assume that a specified series and milestone would be valid for all packages that may be found during a run against multiple archives?

Thanks,

Mattias

[Matthias Klose (doko)]

I currently don't have a use case for a run against multiple archives, so I assume it would be safe (maybe after once checking the milestone and series).

[James Westby (james-w)]

On Mon, 04 Apr 2011 09:01:47 -0000, Mattias Backman <email address hidden> wrote:
> Would it be safe to assume that a specified series and milestone would
> be valid for all packages that may be found during a run against
> multiple archives?

It's certianly safe from the point of view of Launchpad's data model,
assuming you are only filing against a single distribution.

Thanks,

James

[Steve Langasek (vorlon)]

> I currently don't have a use case for a run against multiple archives,

Yes, you do - Matthias, you need to explicitly include the primary archive when checking, this is why svammel filed bugs for you against already-superseded build failures in the test archive. :-)

But yes, I think this is something that's good to have. Also, setting an importance for the bug would help a lot with automation - should this be a separate bug report?

What should the behavior be when setting these attributes fails due to access control? I.e., if someone who's not a core-dev runs this script, they can't target to a series AFAIK; should the script abort at the first error then? should it rollback the freshly opened bug report that it can't set the requested state on (i.e., close the bug)?

[Steve Langasek (vorlon)]

> Also, setting an importance for the bug would help a lot
> with automation - should this be a separate bug report?

Nevermind, it already is :) (bug #749563)

[Mattias Backman (mabac)]

> What should the behavior be when setting these attributes fails due to access
> control? I.e., if someone who's not a core-dev runs this script, they can't
> target to a series AFAIK; should the script abort at the first error then?
> should it rollback the freshly opened bug report that it can't set the
> requested state on (i.e., close the bug)?

This seems to be a good example of something that the script can recover from if you like it to. Would it be more hassle for you to get all the bugs filed without the attributes and have to fix that afterwards than getting no bugs filed until you sort out what's blocking setting the attributes?

[Mattias Backman (mabac)]

How would you like to specify milestones? I can either take a milestone url option or a milestone name. If we go for name, I think it needs to be already present on the target package (if that means that the milestone must be registered some other way than just having a target milestone already I don't know yet).

The same question would apply for the series option, would you prefer name or url? Here I think it has to be a series that's registered on the project, at least the web UI only allows for choosing between the series on the project.

Thanks,

Mattias

[James Westby (james-w)]

Replying to my own message so that LP doesn't reject the Python code as
being commands to its email interface.

On Fri, 08 Apr 2011 09:56:01 -0400, James Westby <email address hidden> wrote:
> On Fri, 08 Apr 2011 11:37:44 -0000, Mattias Backman <email address hidden> wrote:
> > How would you like to specify milestones? I can either take a milestone
> > url option or a milestone name. If we go for name, I think it needs to
> > be already present on the target package (if that means that the
> > milestone must be registered some other way than just having a target
> > milestone already I don't know yet).
>
> As discussed on the phone, I suggest assuming that the milestone is
> already registered. They are infrequently added, especially for Ubuntu,
> and the person running the script doesn't necessarily have the
> permissions to create the milestone.
>
> Also, I suggest using names rather than URLs to be consistent with
> archives. If we want to also support URLs then we should do that across
> the board.
>
> > The same question would apply for the series option, would you prefer
> > name or url? Here I think it has to be a series that's registered on the
> > project, at least the web UI only allows for choosing between the series
> > on the project.
>
> Yep, the series has to already be present for the project/distribution,
> as does the milestone for the series.
>
> So you would do something like
>
> if series_name is not None:
> series = target.getSeries(name=series_name)
> else:
> series = target.current_series
>
> if milestone_name is not None:
> milestone = series.getMilestone(name=milestone_name)
>
> if series_name is not None:
> bug.addNomination(target=series)
>
> if milestone_name is not None:
> bug_task.milestone = milestone
> bug_task.lp_save()
>
> Assuming that you only create one bug task. If there is more than one
> I'm not sure how to decide which should get the series/milestone.
>
> Also, I'm not sure how milestones and nominations interact. If the
> person has certain permissions on the bug target then their nomination
> will immediately create a new bug task. If that happens then we again
> have to decide which gets the milestone. If it doesn't then the task
> that is present may be for a series that doesn't have the desired
> milestone.
>
> I think we are going to have to leave some of this up to the person
> running the script, e.g. they can't choose a milestone and series for
> which they can't immediately create the bugtask with addNomination.
>
> If I've made things unclear then let me know, and I'll try and help come
> up with a solution.
>
> Thanks,
>
> James

[Steve Langasek (vorlon)]

On Tue, Apr 05, 2011 at 06:35:18AM -0000, Mattias Backman wrote:
> > What should the behavior be when setting these attributes fails due to access
> > control? I.e., if someone who's not a core-dev runs this script, they can't
> > target to a series AFAIK; should the script abort at the first error then?
> > should it rollback the freshly opened bug report that it can't set the
> > requested state on (i.e., close the bug)?

> This seems to be a good example of something that the script can recover
> from if you like it to. Would it be more hassle for you to get all the
> bugs filed without the attributes and have to fix that afterwards than
> getting no bugs filed until you sort out what's blocking setting the
> attributes?

I think it's more hassle to have to fix up the bugs afterwards than to get
no bugs filed.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

[Mattias Backman (mabac)]

If an error is encountered when setting milestone or series, the script will close the last created bug and bail. Unless --ignore-errors is specified in which case the script will happily continue filing bugs and ignoring there errors along the way. If some bugs are filed properly before the first error, they will not be closed btw, since they probably are filed as intended and rerunning the script will not re-file them.

@James: thanks, but I'm not sure everything is crystal clear yet. I'll create a merge request with the current state of my change. It's not been tested but I need some fresh eyes on it to see if it's on the right track.

Thanks,

Mattias