Note: There’s a newer blog post here with more mockups and features based on your feedback in this post!
Okay, quick recap. We’re working on a v2 of Fedora Community called “Fedora Packages.” The usual long-winded Mo blog post about it is available if you’d like to catch up.
Now that you’ve been caught up, here’s a little something I mocked up today:
And its friend, a version of it showing what happens if you click on the release / version number:
(Oh dear, I hope I’m not getting overly fond of accordian-style widgets; we’ve been using them in the Fedora installer redesign as well.)
Anyway, the story here is that you’ve searched for a package and want to poke into its sources. These screens show what you’ll see under the Sources > Patches tab… you’ll see a list of patch names and if you click on one, it’ll expand accordian style to show you the patch in its full glory.
Along the bottom of the patch is a toolbar you can use to paste the patch to fpaste, email it, or grab a link to it to send to someone else. Are these useful things you might want to do with a patch? Anything missing? Maybe a link to the raw patch you could download?
Another idea we had was to make the patch text selectable but don’t copy the line numbers to the clipboard / make them unselectable.
The other tabs under ‘Sources’ need to be worked out still; if you’ve got ideas for whawt you’d like to see, let us know in the comments!
Update
Folks in the comments suggested that a clean link to the raw patch would be useful, so here’s a mockup of what that might look like:
More coming based on your suggestions, so keep them coming!
Some ideas for the “Spec File” view:
* hyperlinks for the patches, taking you to the patches themselves. So:
Patch1: fix-memory-leak.patch
within the specfile would be a hyperlink to said patch in the other tab.
* some kind of way to break up the specfile into its constituent parts: the metadata, the %prep, the %build, the %check, the %changelog, etc.
I suppose I should mention my standard difficult-to-implement request here, which is a browser for the “prepped” sources, rather than just the src.rpm sources (which are essentially a script for getting at the former), allowing you to e.g. compare two builds, or compare against upstream. But I appreciate that this is hard to implement.
Hope this is helpful
This looks gorgeous, as does all of your work, Here’s my two cents
“Anything missing? Maybe a link to the raw patch you could download?”
Yeah, if you’re already logged in, a way to edit and submit a patch online would be nice, as well as hooks to do a git push, fedpkg build, fedpkg update and so on. Maybe not at first, but ideally it should support these features.
This is looking very nice ‘Mo, looking forward to actually using it!
“Anything missing? Maybe a link to the raw patch you could download?”
Clean URLs.
http://packages.fedoraproject.org/nautilus/f16/raw-patch/nautilus-2.91.8-selinux.patch
Would it be reasonable to provide this on-demand if you click on the ‘link’ link at the bottom of the patch or would you rather it be more visible?
I’m fine with anything. The main thing is that the URL is a UI too — I should be able to change “f16” to “f15” and get the same patch, or a non-existant patch error.
I should be able to delete the patch filename and have it redirect to “list-patches/”.
A textbox or a link button are both fine, but I should be able to navigate around the site by hacking apart the URL only.
Great looking mock-ups and can’t wait to given it a try. I’d like to second the clean urls comment. Makes things so much nicer.
BTW, accordion widgets are a great ui pattern. You can never use them too much:)
http://www.welie.com/patterns/showPattern.php?patternID=accordion
Yep, I’ve been working on clean URLS which are also dynamic (e.g. only a portion of the content is loaded instead of the whole page). The idea is that you can hit reload and it brings you to the same content without using hashes and parameters. There is difficultly doing that for every part of the UI but for things like patches and downloadable it should be easy.
Diffstat. I’d like an overall diffstat so that I can get an idea of just how much change is encompassed in the patches. This could go at the top of the list of patches. And then I’d like a diffstat for each patch, so I can see how the change is distibuted, which could go to the right of each patch.
Patches are ‘bad’ in the sense that they diverge from upstream and we work upstream first. Some times it can’t be helped, but sometimes we don’t do as good a job as we could. I’d like some kind of indication of whether the patch load for this package is going up or down. Does the diffstat for this version of the package look better or wors than the previous, and how’s it looking between f15 and f16, say?
It would also be useful to have an indication of the age of a patch. Some patches can’t be upstreamed and are carried from one release to the next. Others are relatively new fixes that Fedora was first to find. It would save a lot of time if we could indicate to our colleagues, at Debian say, which patches are new and interesting.
I would also like to see all patches categorized into one of a fixed set of acceptable criteria: security-backport, feature-backport, upstreamed-security-fix, etc. It would help browsing for interesting patches per-package, but we could also create interesting distro-wide stats: where are we slacking, which package upstreams are slow to fix bugs and therefore we need to keep an eye on, etc.
[…] So I posted some quick & dirty mockups of a patch view web interface for Fedora packages, and you gave me some great ideas, and here are most of them integrated into the mockups. […]
[…] by l1nux on October 6, 2011. Posted in Fedora Tutorials So I posted some quick dirty mockups of a patch view web interface for Fedora packages, and you gave me some great ideas, and here are most of them integrated into the […]