Merge lp:~bac/launchpad/bug-643538-code into lp:launchpad
| Status: | Merged | ||||
|---|---|---|---|---|---|
| Approved by: | Brad Crittenden on 2010-09-29 | ||||
| Approved revision: | no longer in the source branch. | ||||
| Merged at revision: | 11656 | ||||
| Proposed branch: | lp:~bac/launchpad/bug-643538-code | ||||
| Merge into: | lp:launchpad | ||||
| Diff against target: |
1761 lines (+770/-224) 22 files modified
lib/canonical/launchpad/icing/style.css (+19/-9) lib/lp/code/browser/branch.py (+35/-26) lib/lp/code/browser/branchlisting.py (+42/-13) lib/lp/code/browser/configure.zcml (+13/-1) lib/lp/code/browser/tests/test_branch.py (+6/-3) lib/lp/code/browser/tests/test_product.py (+166/-15) lib/lp/code/stories/branches/xx-branch-deletion.txt (+29/-15) lib/lp/code/stories/branches/xx-branchmergeproposal-listings.txt (+6/-6) lib/lp/code/stories/branches/xx-creating-branches.txt (+47/-3) lib/lp/code/stories/branches/xx-person-branches.txt (+2/-2) lib/lp/code/stories/branches/xx-private-branch-listings.txt (+20/-10) lib/lp/code/stories/branches/xx-product-branches.txt (+114/-40) lib/lp/code/stories/codeimport/xx-create-codeimport.txt (+21/-1) lib/lp/code/templates/branch-listing.pt (+4/-4) lib/lp/code/templates/product-branch-summary.pt (+70/-29) lib/lp/code/templates/product-branches.pt (+55/-29) lib/lp/code/templates/product-portlet-codestatistics-content.pt (+55/-0) lib/lp/code/templates/product-portlet-codestatistics.pt (+11/-0) lib/lp/registry/browser/product.py (+5/-10) lib/lp/registry/browser/tests/pillar-views.txt (+11/-0) lib/lp/registry/model/product.py (+2/-1) lib/lp/registry/tests/test_service_usage.py (+37/-7) |
||||
| To merge this branch: | bzr merge lp:~bac/launchpad/bug-643538-code | ||||
| Related bugs: |
|
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Guilherme Salgado (community) | 2010-09-24 | Approve on 2010-09-29 | |
| Curtis Hovey (community) | code | Approve on 2010-09-28 | |
| Matthew Revell (community) | text | Approve on 2010-09-24 | |
| Gavin Panella (community) | code | 2010-09-22 | Approve on 2010-09-23 |
| Matthew Revell | text | 2010-09-22 | Pending |
|
Review via email:
|
|||
Commit Message
State the project's code usage, either Launchpad or elsewhere.
Description of the Change
= Summary =
Launchpad must state the project's code usage. The product +code-index page needs to clearly state if the project is using Launchpad. If it isn't it should refer to where it is hosted.
== Proposed fix ==
Conditionally present the correct message. Also moved some of the code summary information into portlets in order to be more like the other application areas.
== Pre-implementation notes ==
Chats with Curtis, Edwin, and Jon.
== Implementation details ==
As above.
== Tests ==
Basically all of the code tests need to run:
bin/test -vvm lp.code
== Demo and Q/A ==
Create a new project and visit:
https:/
= Launchpad lint =
The lint issues are pretty much intractable. I cleaned up a lot.
Linting changed files:
lib/lp/
lib/canonical
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
./lib/lp/
83: want exceeds 78 characters.
93: want exceeds 78 characters.
./lib/lp/
409: Line exceeds 78 characters.
| Brad Crittenden (bac) wrote : | # |
| Brad Crittenden (bac) wrote : | # |
I've noticed on the screen where no code has been registered[1] there is a link to +set-branch (Configure code hosting) but no link to +add-branch (seen later as "Register a branch"). This seems like an oversight because using the former you cannot mirror a branch, only set in Launchpad and import.
[1] http://
| Gavin Panella (allenap) wrote : | # |
Cool branch :)
The comments I have are all really minor.
Gavin.
[1]
def getDistroDevelS
- """Since distribution.
+ """distribution
try:
return self._distro_
except KeyError:
result = distribution.
return result
I think your change doesn't describe what the code does... but that's
because the code is broken! The following line is the culprit:
Every time the method is called the cache gets reset. I think this
line can be removed.
[2]
+ self.branch = self.developmen
development_
be a property so that development_
it is needed.
[3]
+ self.assertEqua
...
+ self.assertNotE
I think this (and others that test against None) should be done with
assertIs(None, ...). Can't remember what difference is makes though :)
[4]
+ def test_portlets_
+ # If the BranchUsage is HOSTED then the portlets are shown.
s/HOSTED/EXTERNAL/
[5]
+ <a tal:attributes=
Doesn't really matter, but it might be clearer expressed as:
<a tal:attributes=
[6]
+ <div tal:condition=
+ <p>
+ New branches you create for <tal:name replace=
+ are <strong>
+ </p>
+ </div>
+ <div tal:condition=
+ <p>
+ New branches you create for <tal:name replace=
+ are <strong>
+ </p>
+ </div>
The tal:condition could go on the subordinate <p> tags, then there's
only one <div>.
[7]
+ <tal:comment condition=
+ The view/*_
+ template can be rendered by a view that does not have count
+ information available.
+ </tal:comment>
There aren't any view/*_
go.
[8]
+ configured = sum([1 for v in config_
Don't need the list comprehension.
| Brad Crittenden (bac) wrote : | # |
On Sep 23, 2010, at 11:49 , Gavin Panella wrote:
> Review: Approve code
> Cool branch :)
>
> The comments I have are all really minor.
Thanks for the helpful review Gavin.
>
> Gavin.
>
>
> [1]
>
> def getDistroDevelS
> - """Since distribution.
> + """distribution
> self._distro_
> try:
> return self._distro_
> except KeyError:
> result = distribution.
> self._distro_
> return result
>
> I think your change doesn't describe what the code does... but that's
> because the code is broken! The following line is the culprit:
>
> self._distro_
>
> Every time the method is called the cache gets reset. I think this
> line can be removed.
Thanks for looking. My change was just to stop lint from complaining about the comment being too long -- I didn't even see the broken code.
>
>
> [2]
>
> + self.branch = self.developmen
>
> development_
> be a property so that development_
> it is needed.
>
Good catch.
>
> [3]
>
> + self.assertEqua
> ...
> + self.assertNotE
>
> I think this (and others that test against None) should be done with
> assertIs(None, ...). Can't remember what difference is makes though :)
>
Done
>
> [4]
>
> + def test_portlets_
> + # If the BranchUsage is HOSTED then the portlets are shown.
>
> s/HOSTED/EXTERNAL/
>
Done
>
> [5]
>
> + <a tal:attributes=
>
> Doesn't really matter, but it might be clearer expressed as:
>
> <a tal:attributes=
> tal:content=
>
>
Yes, much nicer.
> [6]
>
> + <div tal:condition=
> + <p>
> + New branches you create for <tal:name replace=
> + are <strong>
> + </p>
> + </div>
> + <div tal:condition=
> + <p>
> + New branches you create for <tal:name replace=
> + are <strong>
> + </p>
> + </div>
>
> The tal:condition could go on the subordinate <p> tags, then there's
> only one <div>.
>
Done.
>
> [7]
>
> + <tal:comment condition=
> + The view/*_
> + template can be rendered by a view that does not have count
> + information available.
> + </tal:comment>
>
> There aren't any view/*_
> go.
>
>
c-n-p error
> [8]
>
> ...
| Matthew Revell (matthew.revell) wrote : | # |
Thanks for this work Brad. I have a couple of suggestions:
When no code hosting/mirroring is configured, I think the page would be easier to read if some of the text were split up.
For screen shots 0 and 1, I suggest the following:
There are no branches of ticktock in Launchpad. You can change this by:
* activating code hosting directly on Launchpad (read more)
* asking Launchpad to mirror a Bazaar branch hosted elsewhere (read more)
* asking Launchpad to import code from Git, Subversion or CVS into a Bazaar branch (read more).
I have removed Mercurial because Tim tells me it is still very much experimental (i.e. works in around 20% of cases).
Other than that, I'm Matthew Revell and I approve this message.
| Guilherme Salgado (salgado) wrote : | # |
This looks good but I'm not sure the portlets will work nice with real data. For instance, if you see https:/
Also, it looks a bit weird having the two different styles of links (the Register a branch one uses a bigger font and the icon is to its left while the others use a smaller font and have the icon to the right) on the portlet. And by the way, are we moving the action links that were once inlined back into portlets?
| Brad Crittenden (bac) wrote : | # |
Salgado thanks for the review and the questions.
I tried creating some branches with absurdly long names to see what happened. Using a browser that is almost 1400 pixels wide I get http://
Shrinking the browser from there causes bad behavior seen at http://
The other application pages have portlets similar to the one I'm proposing. The link styles are patterned after the involvement portlet on a project index page as seen by a project owner so it is on unprecedented. I think the layout needs some tweaking.
| Curtis Hovey (sinzui) wrote : | # |
The branch urls/names/
I think the font size difference in the links is a real problem. They should be the same, particularly since both presentations were added for 3.0. I do not know which is wrong. The problem might be hard to find because one might be using styles from the deprecated style sheet. I cannot judge the scope of this issue. it might be worthy of a separate bug, and it may be in launchpad-web if it is a universal issue.
| Brad Crittenden (bac) wrote : | # |
Hi Curtis, Matthew and Salgado.
I have made the changes as requested by you and they are shown in screenshots 7-9 at http://
* Bulleted list
* Capitalizing the items in the portlets
* Using break-long-words on the branch names in the table allows them to collapse when the window shrinks
* Don't
The requested changes required a number of test changes, especially the change to not show the portlets when code hosting has not yet been configured. Curtis in addition to mentoring the UI could you look at the latest code diff at http://
| Curtis Hovey (sinzui) wrote : | # |
The code looks fine. You fixed the sprite and comprehension issues I pointed out in the paste.
I was disappointed by the story additions, the stories did not really tell a story. I was also concerned that the /applets is owned by Foo Bar, so the test for an story about an owner was performed by an admin :(. We looked and did not see an intersection with the unittests in lp/code/
| Guilherme Salgado (salgado) wrote : | # |
On Tue, 2010-09-28 at 19:50 +0000, Brad Crittenden wrote:
> Hi Curtis, Matthew and Salgado.
>
> I have made the changes as requested by you and they are shown in
> screenshots 7-9 at http://
>
> * Bulleted list
> * Capitalizing the items in the portlets
> * Using break-long-words on the branch names in the table allows them
> to collapse when the window shrinks
That certainly improves things, but my main concern was with the
horizontal space that is now taken by the portlets. Given that the
portlets have virtually no content (just action links and 3 lines of
statistics), we're wasting a significant amount (IMHO) of real state,
which will make the branches list a bit too narrow on a 800px wide
browser window, like I tend to use[1]
(<http://
You've said that other application pages have portlets, and that's true
for the bugs app page, but in that case they have a significant amount
of content (the tag cloud, pre-defined searches and action links), which
is not the case here. Also, the translations app page, on the other
hand, doesn't have any portlets, so I'm still not convinced the code app
page should have them. Unless there's a policy I'm not aware of?
[1] Even though my monitor's resolution is higher than that, I tend to
use less than 800px wide browser windows because most pages work fine on
those and I think Launchpad should as well.
| Curtis Hovey (sinzui) wrote : | # |
On Tue, 2010-09-28 at 21:07 +0000, Guilherme Salgado wrote:
> You've said that other application pages have portlets, and that's
> true
> for the bugs app page, but in that case they have a significant amount
> of content (the tag cloud, pre-defined searches and action links),
> which
> is not the case here. Also, the translations app page, on the other
> hand, doesn't have any portlets, so I'm still not convinced the code
> app
> page should have them. Unless there's a policy I'm not aware of?
The intent of the features is to make the root pages for projects to use
the same layouts and conventions. Code is using a 2.0 layout still.
Translations remains a conundrum. The user should trust that global
actions and set searches are in the right portlets.
This feature work is driven by our own strategists complaint that users
see conflicting designs when they work across applications.
{{{
Hello Curtis, Strategons,
Attached are screenshots of each of the six tabs of Launchpad for a
newly created project.
I want you to look at them. Make a note of the fonts, the styling of
the action portlets, the alignment of cells, the busyness of the
pages, the balance of the layouts, the colours used, the amount of
text on each page.
You will notice that there is significant difference between each
page. If you look at the pages with a detached eye, you may well come
to the conclusion that none of them are very nice to look at.
I think that this is a problem. I don't mean to put down anyone on the
team, but I would be embarrassed to present on these pages at a
conference.
...
}}}
This lead to an extension of the bridging-the-gap theme in June.
Launchpad must state where services are hosted so that they can complete
their task. Launchpad must state when the service is unknown, hosted, or
external. The applications must behave the same way when unknown,
external, or hosted so that users know what to expect when they use
multiple applications.
--
__Curtis C. Hovey_________
http://
| Guilherme Salgado (salgado) wrote : | # |
Thanks for the explanation, Curtis.
Since it looks like this has been thought through carefully, I think
it's reasonable to trade some screen real estate with better
consistency.
review approve

Screenshots can be seen at: http:// people. canonical. com/~bac/ code_usage/