launchpad-dev team mailing list archive

[Jonathan Lange <jml@xxxxxxxxxxxxx>]

On Wed, Oct 21, 2009 at 3:19 PM, Martin Albisetti
<martin.albisetti@xxxxxxxxxxxxx> wrote:
> Aaron Bentley wrote:
>>>
>>> - Show the relationship between bugtasks better. Where did the bug
>>> originate? Where was it fixed? What is it blocked on?  In general, if a
>>> bug has a bugtask on a package and on upstream, it's pretty safe to say
>>> that it depends on upstream fixing it first.
>>
>> Why?  I would think we have the option of fixing it first and then
>> propagating the fix to upstream?
>
> Absolutely. So this would be the default assumption, and if it got marked as
> fix committed/released in a package first, we would flip that around.
> I say we should assume that by default because, well, upstream bugs *are*
> upstream bugs, even if we fix them, ideally, we would fix them upstream.
>

Ideally, yes. Practically never.

An example, during the many years of Launchpad development we've come
across bugs in LP that were actually bugs in our dependencies. Rather
than fix the dependencies, wait for a release and use that, we'd often
fix or work-around the problem in Launchpad and send a patch upstream.
In the case of at least one bug I know, the patch only landed on
upstream trunk after a year.

What I mean is, getting things upstream is important but rarely ever urgent.


>>> - Adding attachments workflow needs to be finished off. Ajaxified, show
>>> them in a better way than squished in small a box on the bottom right,
>>> attached patches should be shown in the same place as linked branches,
>>> and images, in a perfect world, should show a thumbnail.
>>
>> And for patch attachments, provide a way to propose it for merging?
>
> That would rock, yes.
>

Or indeed, just turn it into a merge proposal right away.

There's a cluster of bugs that I've tagged with 'patch-tracking'. It's
something I'm personally quite interested in.


>
>> I think it would also be interesting to explore pinning a comment as the
>> description like web forms often pin posts, rather than having the
>> description and comments be completely separate things.
>
> Pinning comments would be great, yes. Especially for things like "this is
> the definitive answer for this bug".

Bugs don't have answers :)

jml