← Back to team overview

launchpad-dev team mailing list archive

Re: Quick'n'dirty solution sought: Locking down certain bugs even further

 

On Fri, Mar 25, 2011 at 10:49 PM, Martin Pool <mbp@xxxxxxxxxxxxx> wrote:
> On 26 March 2011 05:56, Jonathan Lange <jml@xxxxxxxxxxxxx> wrote:
>> Hello Launchpadders,
>>
>> I recently had a chat with the Kernel developers about how they use
>> Launchpad. They posed me an interesting problem.
>>
>> They have bugs that they must keep public, for reasons of both
>> principle and practicality. However, they don't really want anyone
>> outside of an authorized set of people actually *doing* anything to
>> those bugs. Outsiders change tags, statuses and add unhelpful comments
>> and the Ubuntu developers would like to stop that from happening.
>>
>> What options do they have with Launchpad as it stands? What could we
>> cheaply change in Launchpad to meet that need better?
>
> I think it would be interesting and perhaps reasonably cheap to add
> two checkboxes per bug: "lock status" and "lock comments".  They can
> be changed by bug supervisors of any task.  If the former is set, task
> fields (status, importance, etc) can't be changed and new tasks can't
> be created, except by bug supervisors.  If the latter is set, comments
> and attachments can't be added, again except by bug supervisors.
> (Perhaps s/bug supervisors/some other role/; the intention being that
> only developers can change it.)
>
> I don't anticipate this would be set on many bugs but there are some
> very hot bugs where it could be useful.
>
> I like this idea because it may be a path to removing some special
> case ACLs that exist at the moment (eg limits on moving into triage
> state; wishes for limits on moving out of triage state; opinion state;
> wishes for locking to wontfix).  Unlike those ACLs this can be put in
> place only when something is actually a problem rather than slowing
> down community triage in general.  (There is some similarity to
> Wikipedia page protection.)
>
> If combined with a final comment by a developer explaining where the
> bug ought to be discussed, how people can express their desire it be
> fixed, or what else people can do, it might help.

How long do you reckon it would take to do?

jml



References