← Back to team overview

launchpad-dev team mailing list archive

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

 

Agreed we need to be careful. What is "inline editing of lists of bugs"? Or
is that a hypothetical future feature?

It seems to me we already have to evaluate membership rules to know whether
a person can change importance. Reading one boolean off the bug and using
that to cause the same rules to apply to status and other metadata fields
should be no slower?
On 28/03/2011 11:06 PM, "Robert Collins" <robertc@xxxxxxxxxxxxxxxxx> wrote:
> On Sat, Mar 26, 2011 at 11:49 AM, Martin Pool <mbp@xxxxxxxxxxxxx> wrote:
>
>> 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.)
>
> We need to be very careful adding per-bug policy from a purely
> performance aspect. Lists of bugs that can be edited inline will incur
> substantial costs if not done well. I have no immediate view on
> whether per-bug is better than per-context, but we have less contexts
> than bugs, so likely to be easier to get acceptable performance out of
> it.
>
> -Rob
>
> _______________________________________________
> Mailing list: https://launchpad.net/~launchpad-dev
> Post to : launchpad-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~launchpad-dev
> More help : https://help.launchpad.net/ListHelp
>

Follow ups

References