Private comments for public bugs

See my comments on bug 179587 too; this would let us implement apport crash reports more gracefully, with fewer private bugs.

Yeah, especially for Apport bugs private attachments should be possible like described in my duplicate report.

Any idea of when this will be available, if at all? Right now we are trying to cleanup the private bugs on Ubuntu, and this is an extremely intensive piece of work (as Colin points out elsewhere, mainly due to apport attachments).

A priori, if apport could load the stacktrace and threadstacktrace (which carry the frames and parameter values) as private, there would be no need to mark the *whole* bug private.

We have more than 2,600 Ubuntu private bugs; granted, it is a small piece of the whole pie, but it is a piece needed is we are to do a good, er, job.

Finally, yes, I am aware of security implications, and classification procedures. Been involved with them for quite some long years.

From an email:

I'd like to get the group's input on something: I would
like to propose that functionality be added to LP to allow
private comments (only logins with @canonical.com addresses
can see them) in LP bugs which are otherwise public.

When working with commercial entities, the business context
of a bug is just as important as the technical context. And
it's important that the engineer working the ticket
understand that context.

What happens today is that those conversations have to
happen outside the ticket. For instance, a Platform manager
will ping me on IRC to say, "How bad is this to the
customer?" It would be much faster if I had a way of
proactively putting that information in the ticket in a
private comment.

The email from comment 4 is exactly right. This would be incredibly useful for working official Canonical support cases. In addition to the above reasons, there are times where you would like to allow the customer to subscribe and track the bug directly, but need to add internal-only comments. Even with a private bug, it's all or nothing if you are a subscriber.

@mark we're proposing to solve this with bug relationships: to have a private and public discussion, have two bugs.
Make the internal one be linked to the public one, or even the staff-only one be linked to a customer-facing one.

The reason we're proposing to do it this way is that it seems highly likely that there will be a cluster of related things folk want when they want partitioned discussions:
 - separate 'in progress' vs 'complete' status
 - different audiences

While we could teach a single bug to manage multiple discussion visibility rules (and a matching UI + bug mail handling) that would be a much bigger project and not solve the case where folk need different completion criteria in the same project.

For instance, consider a bug on the kernel package for folk getting bespoke engineering done; to one of those customers, its done when its shipped, but for the public area - the code change itself - its done when its uploaded to Ubuntu, and there may be N customers all wanted separate 'I'm done now' markers, totally ignorant of each other, and all on the same bug target.

Honestly I think corporate customers would be quite alright with the public status not reflecting their status. They know their own status from the SF case and they will each have their own case. I don't think this would be as much trouble as people might think (In social terms, of course. I obviously have no idea code-wise), but I understand the arguments.

That said, I think a link between the two bugs within LP would be better than no change and would be welcome. Thanks for the reply Rob!

"Make the internal one be linked to the public one, or even the staff-only one be linked to a customer-facing one."

Ah, and yes, both of these would be great options. That would help to put almost all of the relevant discussion effectively enough into "one place".

In some other support tickets, we create a second private bug for the
private conversation. You can mention the private bug number which
lets people know it exists but not what is in it.

It seems like email integration of this would need some care to make
sure replies to private comments don't become public.

Martin

As Robert says (number 6), we're not going to allow private comments for public bugs, but instead have linked bugs, which will go a large way to addressing the underlying need for this bug. Marking this one as WONTFIX for the time being.