launchpad-dev team mailing list archive
-
launchpad-dev team
-
Mailing list archive
-
Message #02904
Re: Status of "+patches" view (story-patch-report)
On Wed, Feb 03, 2010 at 09:07:13AM +0000, Martin Pool wrote:
> Thanks. (Links are missing twiddles.)
>
> What does the 'patch age' link to?
>
> Spelling out the counts in words is a bit odd.
>
> I think if I was using this I'd like to see the attachment names, with
> direct links to the attachments.
Hi Martin,
Karl and I discussed this earlier. Both in my mockup and in his early
work on this, we'd included the patch names. The problems are that
first, attachments can have quite lengthy filenames and this consumes a
huge amount of column space, and second, many times patch names aren't
that descriptive anyway. The compromise was to show it in the tooltip
where we have a bit more room.
I agree having direct links to being able to see the attachment content
is going to be really useful.
> I realize you probably already thought about it but at some point we
> need to give people a clearer way to distinguish between patches that
> need to be merged and those that are not really useful. There is a
> workaround to edit the attachment and make it not a patch but this is
> not discoverable. As a kludge we could just say this in a help bubble
> on the +patches page.
> Eventually it would be nice to see discarded patches crossed out. I
> think Bugzilla does that?
Yes, a way to track review status for attachments would be really
handy. I use the work around of marking patches as non-patch when I
determine the patch to be not valid for merging into Ubuntu, but that's
kludgy.
There's several stateful attributes that apply to patches in the bug
tracker. Something like:
* "New" (unreviewed)
* "Invalid"
* "Needs improvement"
* "Needs packaged" - i.e. .patch needs turned into a .debdiff
* "Needs verified"
* "Superseded"
* "Committed"
There's probably a strong overlap with bzr branch merge status stuff.
In fact, in a perfect world launchpad would automatically generate a
merge proposal for each proposed patch, and would identify whether the
patch applies cleanly.
Bryce
Follow ups
References