creating identical (private) bugs with different viewers is tedious and manual

[Nicolas Valcarcel]

* Scenario:
  - In the OEM Solutions group we maintain several projects for different costumers, each project has a project and team in Launchpad, including the costumer engineers.

* Current workflow:
  - For security vulnerabilities i need to report a bug for each project to keep track separately (we don't want dell engineers to see hp bugs or progress in security issues).

* Desired Workflow:
  - Report one "mother" bug and clone it to several projects, so each project has it's own and independent comments board and use the "mother" bug to track all the others (as we track for several releases/distros in ubuntu)

[Nicolas Valcarcel (nvalcarcel)]

Marked as security vulnerability to be private by default, please treat it as a normal bug.

[Ursula Junque (ursinha)]

Hi Nicolas,

I have one script I implemented, after discussing briefly with Cody, that given a reported bug, create bugtasks for all other projects in a project group, inheriting the "mother bug"'s Status and Importance.

I'm not sure I understood your desired workflow:
  - Report one "mother" bug and clone it to several projects, so each project has it's own and independent comments board and use the "mother" bug to track all the others (as we track for several releases/distros in ubuntu)

Wanting to have independent comments board makes me think you want to have several bug numbers, and not a bug number with several bug tasks (one for each project). Did I understand wrong?
The latter would make possible to track the related bugs through only one bug number, the original one, but the comments board would be the same for all bug tasks. The way Launchpad works today, it would only be possible to track the "sons", if you want the other way, with manual work - adding the bug numbers in the mother bug description field, for instance.

Maybe my script could be useful to you, please, let me know if you're interested.

Cheers!

Úrsula

[Ursula Junque (ursinha)]

According to Nicolas, Graham asked him to open a bug to log a conversation they had in Barcelona about it.

[Nicolas Valcarcel (nvalcarcel)]

Yes, i need different bug numbers. I think with an example it will be clearer:
Let's say i've 2 projects, X from Dell, and Y from HP
For launchpad project X i've canonical engineers and Dell engineers with access to the bug tracker
For launchpad project Y i've canonical engineers and HP engineers with access to the bug tracker
I need to create a bug against X, where Canonical and Dell engineers can comment
And a different bug against Y, where Canonical and HP engineers can comment
I need to avoid HP and Dell engineers to comment on the same bug.

[Graham Binns (gmb)]

This is completely antithetical to the way that Launchpad Bugs are meant to work. Though it could be done very simply, I suspect this needs quite some thinking about; we won't be able to think much about it until after Launchpad 3.0.

[Robert Collins (lifeless)]

Can we please unprivate this? there is no private data in it, nor any indication that we need private data in it.

[Joey Stanford (joey)]

Made public to allow for dups

[Gavin Panella (allenap)]

Is it possible, right now, to create the desired work-flow with copy-and-paste and some manual work? If so, then I think an API script would be the right solution here, to do the mundane manual stuff.

If a more complex relationship between master and clone is needed then we need to understand exactly what that is. For example, do the comments of the master bug need to be copied into the clone? Do they need to be synced after the first clone?

[Graham Binns (gmb)]

On 14 December 2010 14:52, Gavin Panella <email address hidden> wrote:
> For example, do the comments
> of the master bug need to be copied into the clone? Do they need to be
> synced after the first clone

AIUI (long ago, anyway) the copying of comments isn't a necessity,
certainly for the OEM use case where two vendors may want to work on a
bug but neither should be able to see the other's comments.

I still think that we need to do bug relationships first before we
implement this, otherwise we're going to have a lot of orphaned
duplicates knocking around.