launchpad-dev team mailing list archive

[Jonathan Lange <jml@xxxxxxxxxxxxx>]

On Thu, Dec 10, 2009 at 7:43 AM, Martin Albisetti
<martin.albisetti@xxxxxxxxxxxxx> wrote:
> On 12/06/2009 06:45 PM, Jonathan Lange wrote:
>>
>> On Thu, Dec 3, 2009 at 8:34 AM, Martin Albisetti
>> <martin.albisetti@xxxxxxxxxxxxx>  wrote:
>>>
>>> So, bugtasks.
>>>
>>> I'd like to bring forward a problem that seems to be popping up more and
>>> more as we focus on breaching the gap: bugtasks and context.
>>>
>>> As it stands today, if you're looking at an upstream bug that also has a
>>> bugtask for a package in Ubuntu, and you want to nominate that bug, you
>>> can't. You need to start hacking around to get to the bug from the
>>> package
>>> context (if you manage to figure out that's what you need to do).
>>> A quick hack^fix would be to let people click on bugtasks and the context
>>> gets automagically changed.
>>>
>>
>> Interesting.
>>
>> This might be a naive question, but why do bugs need to have a context at
>> all?
>
> We discussed context-less bugs during our UI sprint as well, it solved a few
> problems, but introduced others like:
> - What's the URL like?

That one is easy, I think, since https://bugs.launchpad.net/bugs/ID
already is a valid URL for the bug.

> - What happens when I click on, say, code?

Yeah, that one's tougher. I can think of some solutions though, but
maybe they are worse than the problem.

> ...and other that are not at the top of my head
>
>
>>> A profound fix could be to collapse targeting to milestones and series
>>> into
>>> one column/widget, and offering nomination for those who are
>>> permission-less, and optionally for those permission-ful(?).
>>>
>>
>> Do you think this would help newer users "get" milestones and series?
>> My kneejerk reaction is that this will make them more confusing
>
> Agreed, but it would also hide the complexity for people who just don't
> care.
> My feeling is that the default path should be clear with not many questions
> on how
> to proceed, and people caring about more complex structures when, well, they
> care.
>

I agree with the principle, certainly.

>
>
>>> The "target" is the only bit that is context-specific outside of the
>>> bugtask
>>> row (creating this problem).
>>>
>>> Collapsing these two ties into an additional change that slipped 3.0,
>>> which
>>> was to *not* automatically create a new bugtask when targeting a series,
>>> as
>>> the only case that seems to make sense is backports.
>>> I'd be happy to hash out the UI, I've had a gazillion discussions already
>>> around this, and have a pretty clear idea of what it could look like
>>>
>>
>> Seeing a UI would really help me, since I haven't been a part of those
>> discussions and don't have a clear idea.
>
> I'll try and make time for it then. It's mostly being able to show a series
> in the same place we show milestones today. If you really want another
> bugtask because you need to track a status separately, you can say so
> explicitly.
>
> To help you visualize the problem, I'll give you a quick story on how I
> manage bugs in loggerhead:
> - At some point I decide to release, and create a series for that release
> - I target all the bugs that absolutely need to be fixed in that release to
> the series (a loose target)
> - As I get to the bugs, I target them to specific milestones
>
> Launchpad today makes me create a separate bugtask for the series target,
> but in reality, there aren't 2 statuses there, only 1.
>

Thanks. I'm going to have to think more about this.

>>> I'd love to argue that collapsing the two "Also affects" into one is part
>>> of
>>> this, but it probably isn't (but please do).
>>>
>>
>> It isn't. We should do it. Bridging the gap and all that.
>
> /me stares at over-worked Deryck
>

I didn't say we should do it *now*. :)

jml