Merge lp:~edwin-grubbs/launchpad/bug-597738-bug-service-status into lp:launchpad
| Status: | Merged |
|---|---|
| Approved by: | Edwin Grubbs on 2010-09-14 |
| Approved revision: | no longer in the source branch. |
| Merged at revision: | 11547 |
| Proposed branch: | lp:~edwin-grubbs/launchpad/bug-597738-bug-service-status |
| Merge into: | lp:launchpad |
| Prerequisite: | lp:~jcsackett/launchpad/deprecate-official_codehosting |
| Diff against target: |
550 lines (+193/-107) 13 files modified
lib/lp/answers/browser/questiontarget.py (+0/-16) lib/lp/answers/browser/tests/test_questiontarget.py (+0/-24) lib/lp/answers/templates/unknown-support.pt (+4/-5) lib/lp/bugs/browser/bugtarget.py (+11/-6) lib/lp/bugs/model/bugtask.py (+1/-0) lib/lp/bugs/stories/bugs/xx-front-page-info.txt (+21/-8) lib/lp/bugs/templates/bugtarget-bugs.pt (+62/-24) lib/lp/registry/browser/productseries.py (+19/-2) lib/lp/registry/doc/product.txt (+6/-0) lib/lp/registry/interfaces/product.py (+3/-0) lib/lp/registry/model/product.py (+38/-21) lib/lp/testing/factory.py (+27/-0) lib/lp/testing/menu.py (+1/-1) |
| To merge this branch: | bzr merge lp:~edwin-grubbs/launchpad/bug-597738-bug-service-status |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Curtis Hovey (community) | ui | Approve on 2010-09-13 | |
| Henning Eggers (community) | ui* | Approve on 2010-09-02 | |
| Deryck Hodge (community) | ui | 2010-09-01 | Abstain on 2010-09-02 |
| Jelmer Vernooij (community) | code | 2010-08-31 | Approve on 2010-09-01 |
|
Review via email:
|
|||
Description of the Change
Summary
-------
This branch provides the user with more information about filing bugs on
the bugs.launchpad.
of the new bug_tracking_usage attribute that returns an enum as opposed
to the old official_malone boolean. If the project is not using
Launchpad as the bug tracker, the page will also inform the user of any
ubuntu packages linked to the project under which bugs can be filed.
This branch is dependent on
lp:~jcsackett/launchpad/deprecate-official_codehosting
Implementation details
-------
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
Tests
-----
./bin/test -vv -t 'xx-front-
Demo and Q/A
------------
* Open http://
* Switch the "Bugs are tracked" field between the values.
* Open http://
* If bugs are tracked in launchpad, a bug table should be shown.
* If bugs are tracked externally, the page should contain:
<meta name="robots" content=
<strong>Bugs are tracked in _SOME BUGTRACKER_
<a>Getting started with bug tracking in Launchpad.</a>
Firefox bug reports are also tracked in <a>mozilla-firefox in Ubuntu</a>.
* If launchpad doesn't know where bugs are tracked, it should contain:
<meta name="robots" content=
<strong>
Launchpad does not know where to forward bug reports to contact the*
developers of Mozilla Firefox.
</strong>
<a>Getting started with bug tracking in Launchpad.</a>
Firefox bug reports are tracked in <a>mozilla-firefox in Ubuntu</a>.
| Edwin Grubbs (edwin-grubbs) wrote : | # |
> The text "Mozilla Firefox bug reports are tracked in: mozilla-firefox in
> ubuntu, mozilla-firefox in ubuntu." is a bit confusing. The text is repeated,
> but I would also argue that the text should mention somehow that those places
> are not for the bugs for upstream Firefox.
>
> Perhaps something like: "Launchpad keeps track of bug reports for <a>mozilla-
> firefox in Ubuntu</a>."
Hi Jelmer,
Thanks for the review. I've made the wording changes you suggested, and I resolved the merge conflict with devel. When I removed the code that made the results distinct on the distro, I didn't realize that what was really necessary was to make it distinct on the distro/
-Edwin
| Deryck Hodge (deryck) wrote : | # |
Since I'm not a UI reviewer, I'll abstain from review; however, as a bugs guy looking at the change, I'm not sure the language is quite right for the case where we don't know where bugs are tracked. Saying Launchpad "does not know where to forward bug reports" assumes the project doesn't host itself on Launchpad. I think it would read better as Launchpad "does not know where $project tracks its bugs." Or something like that.
Just my .02c. :-) Nice work, otherwise.
Cheers,
deryck
| Henning Eggers (henninge) wrote : | # |
Hi Edwin!
Thanks for adding these helpful comments. I think the help link is very important. Although you don't mention it it looks like you did the same for answers. Generally this looks good to me although I have a few small comments.
"Launchpad does not know where to forward bug reports to contact the developers of Mozilla Firefox."
That sentence seems to either be missing a "to" or I am misunderstanding it. Maybe it should simply be "Launchpad does not know where to forward bug reports to." or even just "Bugs are not tracked in Launchpad". The latter is consistent with "Bugs are tracked in The Mozilla.org Bug Tracker."
I wonder if the next line should be prefixed with "Hint: Launchpad keeps track of ..." to make clear it's a hint and not contradicting the previous line. The same line on the answers page should be worded similarly.
Actually, I think these wording questions are Matt Revell's domain .... ;-)
OK, here is the real UI issue I have:
"Launchpad allows your project to track questions and create FAQs." sits right on top the helpful links. There should at least be some padding in between those but really I think that line should go away completely. It can be integrated in the help link, e.g. "Getting started with offering support for your project." which explains a bit more what this is about.
With that last change in place, I can approve the UI here. That's it. ;-)
Henning
| Edwin Grubbs (edwin-grubbs) wrote : | # |
> Hi Edwin!
> Thanks for adding these helpful comments. I think the help link is very
> important. Although you don't mention it it looks like you did the same for
> answers. Generally this looks good to me although I have a few small comments.
>
> "Launchpad does not know where to forward bug reports to contact the
> developers of Mozilla Firefox."
> That sentence seems to either be missing a "to" or I am misunderstanding it.
> Maybe it should simply be "Launchpad does not know where to forward bug
> reports to." or even just "Bugs are not tracked in Launchpad". The latter is
> consistent with "Bugs are tracked in The Mozilla.org Bug Tracker."
The reason for the wordiness is that I'm trying to explain to the user the difference between reporting a bug on ubuntu's firefox package and reporting a bug to the actual developers, since this page will suggest reporting a bug on the package if the project doesn't use Launchpad as their bug tracker. I want to avoid saying "Bugs are not tracked in Launchpad. You can submit a bug for the firefox package." since that sounds contradictory.
How does this sound? "Mozilla Firefox must be configured in order for Launchpad to forward bugs to the project's developers."
> I wonder if the next line should be prefixed with "Hint: Launchpad keeps track
> of ..." to make clear it's a hint and not contradicting the previous line. The
> same line on the answers page should be worded similarly.
>
> Actually, I think these wording questions are Matt Revell's domain .... ;-)
>
> OK, here is the real UI issue I have:
> "Launchpad allows your project to track questions and create FAQs." sits right
> on top the helpful links. There should at least be some padding in between
> those but really I think that line should go away completely. It can be
> integrated in the help link, e.g. "Getting started with offering support for
> your project." which explains a bit more what this is about.
I think that getting rid of the text looks cleaner than integrating it with the help link, but I don't know how important it is to explain that "offering support" means tracking questions and creating FAQs.
I'll let the secondary UI reviewer weigh in before I change the branch.
> With that last change in place, I can approve the UI here. That's it. ;-)
>
> Henning
| Curtis Hovey (sinzui) wrote : | # |
Hi Edwin, et al.
I have some concerns about the consistency of the unknown/external/lp
states for all bug targets and some of their states. I think we need to
address all of these and I think we need to plan one or more branches to
complete the bugs app front page for bugtargets
(distro) https:/
I see a message about forwarding bugs, but I know distros cannot
have remote bug trackers. The choice is Launchpad or does not use
Launchpad. The current message is better
This is a fair example of why we do not use context/title inline.
I see "_Enable bug tracking._" I think there should be an edit icon
preceding it.
(dsp) https:/
Oh my! This implies kubuntu does use bugs. I get an oops if I try to
report bug.
/me looks at fedora on lpnet.
https:/
also prompts me to report a bug and it too oopses :(
^ This is a separate issue but this is exactly the kind of
mis-
done until we address this.
https:/
(project) https:/
Looks good.
(project) https:/
I see
Launchpad keeps track of bug reports for _cnews in ubuntu_,
_pmount in ubuntu_.
which is very odd. Some projects produce 20 packages and some have
names nothing like the upstream project in Lp. I am not sure Launchpad
is tracking this bugs, Ubuntu is. Maybe
Ubuntu tracks bugs related to packages derived from this project:
_cnews in ubuntu_, _pmount in ubuntu_.
(project group) https:/
Implies the project groups has projects that track bugs. This is not
True. The page should state that none of the group's project use
Launchpad to track bugs. There is nothing to configure since the behaviour
is derived from the state of member projects. The answers app tells the
user that Lp does not know where support is managed.
> === modified file 'lib/lp/
> --- lib/lp/
> +++ lib/lp/
> ...
>
> @@ -162,27 +166,55 @@
>
> <p id="no-
> </tal:no_hot_bugs>
> - </tal:uses_malone>
> -
> - <tal:not_
> - tal:define ="configure_
> - <p id="no-
> - bug tracking.
> - <p tal:condition=
> - id="bugtracker"
> - <tal:bugtracker replace="structure view/bugtracker" />.</strong>
> - </p>
> -
> - <p tal:condition=
| Curtis Hovey (sinzui) wrote : | # |
> > Hi Edwin!
> > Thanks for adding these helpful comments. I think the help link is very
> > important. Although you don't mention it it looks like you did the same for
> > answers. Generally this looks good to me although I have a few small
> comments.
> >
> > "Launchpad does not know where to forward bug reports to contact the
> > developers of Mozilla Firefox."
> > That sentence seems to either be missing a "to" or I am misunderstanding
> it.
> > Maybe it should simply be "Launchpad does not know where to forward bug
> > reports to." or even just "Bugs are not tracked in Launchpad". The latter is
> > consistent with "Bugs are tracked in The Mozilla.org Bug Tracker."
>
>
> The reason for the wordiness is that I'm trying to explain to the user the
> difference between reporting a bug on ubuntu's firefox package and reporting a
> bug to the actual developers, since this page will suggest reporting a bug on
> the package if the project doesn't use Launchpad as their bug tracker. I want
> to avoid saying "Bugs are not tracked in Launchpad. You can submit a bug for
> the firefox package." since that sounds contradictory.
>
> How does this sound? "Mozilla Firefox must be configured in order for
> Launchpad to forward bugs to the project's developers."
I think this text is fine. I think part of the problem is really about the Ubuntu case. Ubuntu is not tracking project bugs, it is tracking package bugs:
Ubuntu tracks bugs related to packages derived from this project:
_cnews in ubuntu_, _pmount in ubuntu_.
...
> > integrated in the help link, e.g. "Getting started with offering support for
> > your project." which explains a bit more what this is about.
>
>
> I think that getting rid of the text looks cleaner than integrating it with
> the help link, but I don't know how important it is to explain that "offering
> support" means tracking questions and creating FAQs.
Instead of support, maybe we should just say "questions and FAQs", because that is what we want to know. I will be adding fields for mailing lists and forums for answers in my after hours, so I expect the external page will clearly state where the user can find the answers to his or her questions.
| Edwin Grubbs (edwin-grubbs) wrote : | # |
> Hi Edwin, et al.
>
> I have some concerns about the consistency of the unknown/external/lp
> states for all bug targets and some of their states. I think we need to
> address all of these and I think we need to plan one or more branches to
> complete the bugs app front page for bugtargets
>
> (distro) https:/
>
> I see a message about forwarding bugs, but I know distros cannot
> have remote bug trackers. The choice is Launchpad or does not use
> Launchpad. The current message is better
I have added a conditional to display the old message if the context cannot have an external bug tracker.
> This is a fair example of why we do not use context/title inline.
>
> I see "_Enable bug tracking._" I think there should be an edit icon
> preceding it.
I have added the sprite to this link.
> (dsp) https:/
>
> Oh my! This implies kubuntu does use bugs. I get an oops if I try to
> report bug.
> /me looks at fedora on lpnet.
> https:/
> also prompts me to report a bug and it too oopses :(
> ^ This is a separate issue but this is exactly the kind of
> mis-communication we are trying to fix. bridging the grape is not
> done until we address this.
> https:/
The DSP's default view is +bugs instead of +bugs-index, so it has no logic to inform the user that Launchpad doesn't track bugs for the DSP.
> (project) https:/
>
> Looks good.
>
> (project) https:/
>
> I see
> Launchpad keeps track of bug reports for _cnews in ubuntu_,
> _pmount in ubuntu_.
> which is very odd. Some projects produce 20 packages and some have
> names nothing like the upstream project in Lp. I am not sure Launchpad
> is tracking this bugs, Ubuntu is. Maybe
> Ubuntu tracks bugs related to packages derived from this project:
> _cnews in ubuntu_, _pmount in ubuntu_.
I have made that change to the wording.
> (project group) https:/
>
> Implies the project groups has projects that track bugs. This is not
> True. The page should state that none of the group's project use
> Launchpad to track bugs. There is nothing to configure since the behaviour
> is derived from the state of member projects. The answers app tells the
> user that Lp does not know where support is managed.
Just like DSPs, ProjectGroups use +bugs instead of +bugs-index, so it will take some work in a later branch to fix.
> > === modified file 'lib/lp/
> > --- lib/lp/
> > +++ lib/lp/
> > ...
> >
> > @@ -162,27 +166,55 @@
> >
> > <p id="no-
> > </tal:no_hot_bugs>
> > - </tal:uses_malone>
> > -
> > - <tal:not_uses_...
| Curtis Hovey (sinzui) wrote : | # |
Thanks for examining these issue and explaining what is happening. I think your branch is fine to land. We can discuss next steps in a separate thread. The series.title is an interesting issue because the attr is in the process of being removed from distroseries as a part of the Derivative distro work.

The text "Mozilla Firefox bug reports are tracked in: mozilla-firefox in ubuntu, mozilla-firefox in ubuntu." is a bit confusing. The text is repeated, but I would also argue that the text should mention somehow that those places are not for the bugs for upstream Firefox.
Perhaps something like: "Launchpad keeps track of bug reports for <a>mozilla-firefox in Ubuntu</a>."