Screenshot, front page of Fedora Packages
The story up ’till now
You might remember some earlier posts I’ve made about Fedora package social networking. The background here is that we built a web application called Fedora Community a couple of years ago. With Luya Tshimbalanga’s help, I ran a number of usability tests on this initial version at FUDcon Toronto. The results pointed out some key problems that over the past couple of years have definitely negatively impacted user adoption, including slow search and loading times.
Late this summer Luke Macken, John Palmieri, Spot, and myself went through those all of those issues and formulated a plan to try again and build a better application for package maintainers. We launched a beta version at FUDcon Blacksburg this past Saturday, and it’s called Fedora Packages.
We wanted to build only the most core functionality and keep things very light and speedy, being overly cautious towards adding features beyond the initial core to avoid the problems we ran into with the first version. I want to emphasize this because a lot of you provided great suggestions for functionality but we decided to focus just on the core functionality for now and have planned to work on several of your suggestions in future releases.
Fedora Packages
Screenshot, front page of Inkscape’s profile
You can think of Fedora Packages like a social networking system, where instead of profiles of people, you’ll find profiles of packages. We load the package’s icon in the upper left. Right now, we just load the icon if we have it, and if it’s too low-resolution, we blow it up. For some packages like clonekeen, this looks pretty awesome but for others, not so much. We very much appreciated your suggestions on an earlier blog post about package categories and how to display icons for packages that don’t have icons or high-quality icons, but again in keeping with our focus on the core and having something ready for you to check out by FUDcon Blacksburg, we decided to shelve that for now and focus on higher-priority features like optimizing our searches.
We also display basic details in the left sidebar such as like the latest version of the package in Fedora, the package owner, any packages in its family tree, and these pieces of information persist across the package’s profile tabs.
The front overview page shows the description of the package, what versions of the package are in what Fedora and/or EPEL releases, and a link to the upstream. I am hoping that in the next cut we can work with Vincent and the OpenSuSE folks on extending our upstream metadata; Luke has some ideas on this as well (more on that later.)
One core piece of functionality we definitely heard loud and clear from your feedback on Fedora Community, including during the FUDcon Toronto usability tests, was that the Fedora Community URL structure was complicated and made it difficult to go directly to the page you wanted. With Fedora packages, you need only append the name of the package you are interested in after the /packages/ portion of the URL and it will take you straight there. You can go directly to a particular tab of the package profile by appending the name of the tab after the package name portion of the URL (for example, https://community.dev.fedoraproject.org/packages/inkscape/bugs to go to the Inkscape bugs tab.)
Some new goodies: Patch Viewer and Contents Viewer
Fedora Packages’ patch viewer
You may recognize some of the tabs in Fedora Packages – both the builds and updates tabs are widgets Luke and J5 had built for Fedora Community. They have been cleaned up and optimized for inclusion here. We put some new goodies for you to work with as well.
Luke worked with me on the patch viewer, which not only gives you a full listing of all Fedora patches against any given patch with the committer and commit date, but also lets you view a diffstat per patch as well as across all patches for the package. You can also view the full content of the patches with code syntax highlighting inline in the page.
Expanded view on a patch from Fedora Packages’ patch viewer
J5 worked on the package contents tab, which displays the contents of the RPM binary for the package (see screenshot below.)
There are of course more nooks and crannies of useful information in each package profile: please try Fedora Packages out and let us know what you think!
http://community.dev.fedoraproject.org/packages/
Inkscape’s contents tab in Fedora Packages
Optimized search via playing games: Fedora Tagger
Fedora Packages search results for ’email’
So how did we get our search to work so quickly this time, and how are we getting better search results?
Luke did a lot of research on how to best improve our search and concluded that the GPL-licensed Xapian Open Source Search Engine Library was the way to do it. Xapian searches package names, summaries, descriptions, and tags, and it shold weight the search results in the following manner (although John is still tweaking it, and I’m not 100% sure where tags are in the ordering):
- If the search term(s) appear in the package name.
- If the search term(s) appear in the package tags.
- If the search term(s) appear in the package summary.
- If the search term(s) appear in the package description.
“Where do the tags come from, though?” you might ask. Good question! 🙂 Fedora PackageDB has a tagging system and yum is able to access those tags, so Ralph Bean pre-populated the Xapian index with the tags from Fedora PackageDB. Not all packages in PackageDB have tags, though. What to do?
Fedora Tagger
Well, Spot had this great idea for us to build a game that would let you both add tags to packages in Fedora as well as vote up or down those tags added by others, and win points (and hopefully soon badges – more on that later) for your efforts. It was a stretch goal for us because we really weren’t sure if we’d have Fedora Packages up and running in a development environment and all the core features ready in time – time was very short, especially with the Christmas holiday break – but we managed to pull it together with J5’s initial javascript prototype and a Herculean effort by Ralph Bean, who not only got the basic game mechanics and prototype in tip-top shape but who also implemented gravatar icon support, a leader board, and even vim keybindings!
Other features include a naughty-words filter (no, Tagger is not a dumping ground for your drama 🙂 ) and anonymous tag voting, although you can’t add tags if you are anonymous. Log in and try Tagger, and let us know what you think!
http://community.dev.fedoraproject.org/tagger/
Planning whiteboard for Fedora Packages and Fedora Tagger
Where we go from here
Our FUDcon presentation, “Making Fedora Package Maintenance Easier”, was (thankfully! phew!) given to a completely full room and the initial reception seemed to be very positive. Here’s a rundown of the comments and feedback we got during the session from those that attended:
Colin explaining his upstream package metadata ideas
- Would it be possible to show which patches were sent upstream and are pending, which were refused by upstream, and which have not yet been submitted? (Colin Walters & Nathaniel McCallum)
- One proposed solution during the discussion was to create additional rules/regulations for package maintainers to note this information in their package commits. This was noted to be an extra burden on maintainers, though.
- Another proposed solution that Luke has been looking into is called DOAP files.
- Colin noted that he was upset when people fix bugs downstream in code he is the upstream for and don’t even let him know about it. He ends up putting time into fixing bugs that have already been fixed because he just didn’t know.
- Both Nathaniel and Casey Dahlin noted that there is some functionality available in git where it can tell you if your lines of code from a patch is available in a given repo.
- Nathaniel suggested adding something to the DOAP files, such that whenever someone builds a patch and commits it, it would automatically notify upstream. Spot noted that there are quite a few patches that are not suitable for upstream and wouldn’t be useful to them because they are Fedora-specific. He suggested noting the upstream contact on the page of each package. Ben Boeckel suggested that maybe Fedora-specific packages could start with numbers in the 1,000 range, but Spot thought the kernel maintainers wouldn’t like that very much.
- Ben also mentioned an upstream version checker called ‘fever.’ Spot noted that Luke has been investigating its inclusion and it’s now called cnucnu. (More details on the Fedora wiki.)
- Cool, this is like extensions.gnome.org for Fedora! (Paul Frields)
- It’s not a store, though (Spot)
- With a few small tweaks–filtering down to apps only, and adding a install button–we could build a separate app like that using this codebase, though. (J5)
- What about screenshots? (Rahul Sundaram)
- We don’t have auth on the site, so we couldn’t let users upload screenshots. (Spot)
- Maybe we could set up a separate service to allow that. (J5)
- Can yum use the tags? Can other applications use the tags? (Kevin Fenzi)
- Yum already uses tags from PackageDB … (lmacken)
- Maybe we could get rid of the extraneous pkgdb stuff so we don’t have duplicate / separate functionality (Toshio)
- What about using the tags in the package spec files? (Colin)
- We could take the tag cloud that we generate… if the tag achieves a certain amount of weight, we could take those tags with those mappings and use in the GNOME shell search logistics.
- Is there a JSON API for this? (Casey Dahlin)
- It’s definitely do-able since it’s built using TurboGears (lmacken)
- Actually, I think it’s not documented yet but you could go to the connectors directory directly. (J5)
- Could we use this to better document specs? (Toshio)
- Toshio had the idea of looking at adding the ability to annotate spec files. There was a project proposal to do this through the Google Summer of Code; the Django project documentation does it now, where you can comment on specific chunks/parts of the documentation rather than leave comments in a generic area. What if we added that ability to specs, so maintainers could document their specs when asked questions to new packagers they were mentoring? We could have a toggle to turn them on or off. The challenge is that we don’t have auth in Fedora Packages – maybe we could get around that by having the maintainer receive patches to the spec file with annotation via bugzilla?
Spot showing off Tagger
Some ideas we discussed adding, but have held back thus far because of our committment to implement the core first:
- Full package description text available in tagger – We noticed while playing Tagger that there were many packages we had never heard of and we opened up new browser tabs to do research on them in Fedora Packager. It would be more streamlined to display the package description and upstream link right in Tagger (upon request, after clicking ‘more details’) to save time and effort.
- Mozilla Badge Support – Mozilla’s Open Badges Project is something we could deploy to reward folks submitting tags and voting on tags in Tagger, as well as a way of rewarding our package maintainers and other Fedora contributors.
- PackageKit integration – We could provide an API for PackageKit to use Fedora Packages and its optimized search results for returning package data rather than querying yum for this information. One advantage to this approach is that PackageKit could get the icons from Fedora Packages, even for packages not already installed on the system.
- GNOME Shell integration – As mentioned earlier, the idea came up to allow GNOME shell to access the optimized search including tags to display appropraite applications directly in the shell.
- A query language – We could implement a query language for the search to make it even more efficient to find what you are looking for.
- Subpackage display in search results – This is a minor bug, but right now if your search terms match a subpackage, we display both the subpackage, its parent, and all of its sublings. We should only be displaying the subpackage(s) that match the search terms and its parent.
- Newly-added tags don’t display on the package card right away in tagger – another minor bug we can address.
- Improved linkage to bugs mentioned in spec files and patches – we have some links working now, but folks aren’t incredibly consistent with how they refer to bug numbers in their commit messages and comments so we missed a few.
- Diffs between versions for spec files – is this something you’d be interested in seeing?
- Diffs between the spec and its patches – this could show if you’re carrying patches for a package that aren’t even referenced in your spec (I think we saw a few instances of this too.
- Interaction with the Fedora system accessing Fedora Packages – we talked about possibly having an icon or notification on a package’s profile if we detected that you have it installed, or if you have it installed and there’s an update available for your version. (In the released versions table we could even highlight your release.) We could also pre-populate the release dropdown filters across the UI with your current version. For updates, it might be cool to show which ones you have installed and allow you to easily given them karma.
- Default or not? – some kind of indication on a package profile to show whether or not it is installed by default.
- Timestamp the screens – we could display a timestamp on each page of packages… since we’re working from cached data.
- Subpackage versions bug – right now we give subpackages the same version number as the parent even though they might not have the same version number as their parent, in active releases overview, might fall over in some edge cases on the relationships / contents tabs
- Off-site upstream summary link indicator – this is a super-minor designery desire here, but I thought it would be nice to add an ‘offsite’ icon to indicate the upstream webpage links are outside of Fedora infrastructure (see “Patterns for Expressing Expansion Link Weights in Web Applications” and “More Link Treatments”.
- Maintainer mail-to links – Right now we don’t link the maintainer’s name, it’s just plain text. Pingou suggested that we use the maintainer alias email addresses. We also discussed potentially providing, in a panel that pops up when you hover over the maintainer’s name, showing their IRC nick, emailaddress, and buglist. We opted to not do anything yet because we wanted to see what you might ask for here. What do you think?
- Alpha-sort subpackages list – we don’t do this now I don’t think.
- [NEW] Type-ahead in the searchbox – (idea from CodeBlock) this would be especially awesome once you’re already at a package profile page because you won’t have to bounce to the front page, you can go directly to the page you want
Summary & Where the Action is At
So we hopefully have provided Fedora package maintainers (and users? Maybe?) a better tool for managing information about packages this time. We now also have Tagger, which allows those of us (like me! 🙂 ) who are less technical but still want to help Fedora a way to contribute and learn more about what’s available in Fedora along the way.
My life is now complete, and Tagger made it happen: I discovered xteddy!
I do think it was the right call to keep things as minimal as possible first. I think it left the slate open for a huge number of ideas (as you can see above) directly from you. We still have a lot further to go, though: your help, suggestions, and feedback all this time have of course been critical and we’ll need more. 🙂 If you’d like to get involved, here’s the rundown:
Fedora Packages
| URL | http://community.dev.fedoraproject.org/packages |
|---|---|
| Mockups | http://community.dev.fedoraproject.org/packages |
| Bug Tracker | https://fedorahosted.org/fedoracommunity/ |
| IRC | #fedora-admin on irc.freenode.net |
| Mailing list | Fedora infrastructure list |
Fedora Tagger
| URL | http://community.dev.fedoraproject.org/tagger |
|---|---|
| Bug Tracker | https://github.com/ralphbean/fedora-tagger/issues |
| IRC | #fedora-admin on irc.freenode.net |
| Mailing list | Fedora infrastructure list |
Oh, what about that weird radioactive panda post?
Remember that weird hot-dog-seemingly-with-a-grudge-with-a-panda post? Well, check this out (it will get even cooler soon with Fotios’ parallax animation… heh, heh, heh.)
2 things.
The big thing is that when you find a package and click on it, the URL goes to admin-prod.fedoraproject.org, which doesn’t exist. admin.fedoraproject.org does.
also, the search button is small, and off-center. This looks just terrible.
I don’t mean to rag on you, but this just looks like it was thrown over the wall without any real world testing, and it’s probably not the image that Fedora wants to present.
Hi,
3 things.
First, qualifying your rags with a statement saying you don’t mean to rag isn’t actually useful. You did mean to because you wrote it and posted it. 🙂
Secondly, the search button smallness and off-centered ness is a minor CSS bug. You’re the first person of over 100 who’ve already checked out the site to mention it. We will definitely fix it, thank you for bringing it to my attention. It does not exhibit that behavior in my local instance so it may be an artifact of the development environment it is hosted on, or the fact that one of our labs had a minor network outage and the server the CSS is hosted on (some of it cascades from the main fedora project CSS which is served up by a different host)
Thirdly, I cannot reproduce your admin-prod.fedoraproject.org issue. Can you give me more specific information about what you clicked on so we can try to reproduce it? Again, that may be some kind of symptom of our outage and our admins would be grateful if you could get us more details so we can figure out what’s going on.
This is definitely a development environment and is not production-ready yet, thus the dev URL it’s currently hosted on. After we finish working out the kinks we’ll move it to a better location – I was thinking packages.fedoraproject.org since other distros have that format URL for their equivalent systems.
I just found an admin-prod URL as well. To reproduce you can go to the page for the eigen3 package. If you try to click on any of links in the “Latest Released Version” column, you’ll see that they want you to go to admin-prod.fedoraproject.org/updates instead of admin.fedoraproject.org/updates.
Thanks! 🙂
3 responses 🙂
1. All right, you got me. I did mean to rag. In my defense, these are valid issues. Saying I don’t mean to rag is just my lovely way of saying that I’m trying to bring up the issues in the most constructive way I can, in my own jerky way. Sorry I came across as more critical than I intended.
2. Honestly, I thought it was a weird chrome problem too, until I saw the screenshots you posted, where the button is also shorter than the search field, and slightly off-center vertically. The fact that I’m the first to mention it doesn’t necessarily mean I’m the first to notice, just the first to mention it. It seems minor but it’s one of three major elements on the page. Where I work QA guys would be jumping all over that.
3. the problem I was having was with postgresql package links, but Rich seems to have fixed that.
If I seem prickly and hostile, I apologize. I really admire what I’ve seen of what you’re doing with anaconda, but I have a love/hate relationship with the Fedora Project in general most days.
When I saw your post about the Package Tracker I got so excited, because it solves a problem I was having, and I wanted to check out the postgresql changes that Tom Lane and I had discussed in bugzilla.redhat.com, but I didn’t want to necessarily check out the entire src rpm and unpack it.
I didn’t realize that it was a development area and not yet ready for prime-time, as there’s nothing in your post to indicate that, and I’m not familiar enough with your hostname schema to realize it just from the URL.
Imagine my dismay when it didn’t work.
It would have been nice to have QA resources, completely agreed. Then again, I’m a *designer* and I don’t think the height setting missing in the CSS for the button is all that big a deal. 🙂
That being said, Luke fixed the issue pretty much within minutes of you reporting it; if I wasn’t on my way out the door from my office to go out to dinner with my husband when you first posted the CSS issue, I probably would have fixed that already as well.
Having worked on many web applications, I think having ‘dev’ or ‘devel’ in a URL is pretty a standard indication of the environment, but to each his own: I absolutely could have made it more clear in the language of this post. The model we follow with a lot of projects in Fedora is to develop things completely open even if it’s not fully-baked, not just shove out polished, already-baked products. That means you get exposed to issues and bugs you wouldn’t normally, yes. It also means you get more of a say and a stake in the direction of the project.
I appreciate your kind words about the Anaconda redesign and I am very disappointed that you appear to be so let down by this app that I have worked very hard on over the past 6 months; I hope that you would be willing to explain a little bit more about how you feel that this application that I thought was pretty functional and feature-ful “doesn’t work” so that we can fix it.
I am absolutely blown away by the speed that you had that fixed, especially considering that it’s Monday evening and I’m at home carping on random blog posts 🙂
My disappointment came because the first thing I saw didn’t work. My use case may or may not be typical, but as I said, I wanted to use the site for something, and I get tantalizingly close, and then I get a bad DNS entry. Now that that problem is fixed, I can start exploring it more.
My say and stake in this product has already started, and your engagement with me has gotten it off to a great start. So far, the only criticisms I have are the ones I’ve expressed in the comments here. If I come across any more I’ll be sure to mention them. I try not to hide my light under a bushel 🙂
My criticisms are only to try and help make it the best product possible.
Okay cool, it wasn’t a big deal then. It sounded like there were more major problems so I was really worried. Thanks for being a good sport!
Nope, just me being ornery.
I just fixed the admin-prod linkage issue
Ray suggested that I rib you about it 😉
I’ve seen that admin-prod URL problem, too. For instance, going to one of my packages at:
https://community.dev.fedoraproject.org/packages/BEDTools
the links to updates use the admin-prod address.
Other than that small problem, it looks very good and has been very responsive in my brief testing.
first off, this looks great. I plan to spend some time playing with this in the next few days. One feature request I have (as I have had with a few other products), if a package is in RHEL proper, is there a way to know that? Look at rubygems for example, it says what version is in Fedora, and EPEL5, but in EL6, it was pulled into RHEL. It looks like it’s just not anywhere.
I realize that request might not flow from pkgdb well, but I thought I’d ask 🙂
Keep up the great work.
Ah, you caught a very interesting situation. We will definitely take a look at what we can do here. Thanks for the kinds words and good idea!
This stuff is great. Search is fast compared to fedora community.
Good luck!
One more feature request, since I’m sure you absolutely *love* me now, but I was wondering if you could make the patch viewer for packages in testing as well, as it looks like I’ll have to download the src rpm and unpack it to check out Tom’s changes and give the package the karma it deserves.
If I could see the packages in testing, I could give it karma that much easier.
To me, the button doesn’t seem to be styled at all, in Chrome on Linux and Mac I get the standard form submit button
Hey, you didn’t send me a death threat or mention my mother, so you’re not doing that bad, really. (or I guess that good, depending on how you’re looking at it) 😉
I think having the patch viewer show patches applied in testing sounds like a good idea. Do you know if Tom made the fix via a patch, or did he make a change in the upstream code and rebuild with a fresh upstream tarball? Your situation is the kind of situation I think we could support easily but I’m not sure of all the details here. Is this update he submitted to testing 5 days ago the one of interest to you?
https://community.dev.fedoraproject.org/packages/postgresql/updates/
If so I can talk to Luke and see what we can do. We definitely have a long-term goal of making granting packages karma easier.
Re: the button, it wasn’t ‘styled’ – I actually really dislike overly styled buttons and kind of like sticking to the browser defaults. However, the height was set to match the height of the search bar and it looks like maybe some other button style is overriding it. (You can set dimensions, padding, and margins for buttons in CSS while still maintaining the native browser look & feel.) I will try to look at it after this or tomorrow.
The patch viewer does, I think, show the patches for the package in testing ( at least it shows the spec for the version in testing), after discovering that, I think I see what’s going on now. When I look at the specfile I see Tom’s changes in the specfile changelog, and I think I can determine which file he changed, but that file is not in the list of patches, but in the list of sources. Consequently, it doesn’t show up in the list of patches on the site.
So having said that, I need to revise my feature request, and ask instead to have local source files (ie, ones not prepended by a url) , like systemd files added, maybe as a separate section in the sources tab.
Re: the button: In general, I think you’re right about not overriding default browser buttons, but in this case, where you are overriding the dimensions for the text entry field, but not overriding the button dimensions, the button looks a little out of place to me. It comes down to a matter of personal preference, I guess. Not really something to make that big a deal out of.
I do love the spirit of openness that you guys are putting out there, and hope it never stops, but when you do that you’re opening yourself up to some criticism as well. I saw two things that I thought could be improved, and, in that same spirit of openness, I shared them 🙂 Maybe not in the nicest way possible, but I am also imperfect, and I hope you don’t hold it against me.
It’s way past my bedtime now, so I’ll bid you adieu for tonight, and hopefully I can find more nits to pick in the future.
All the best.
When a specific version of a package is in “testing”, that means it is the spec & patches from the HEAD for that particular release branch in git. So, if you want to see patches for something in F16 testing, selecting F16 in the patches dropdown will show it. To confirm this, you can view that release in the specfile viewer to verify that the version matches up with whatever is in testing.
– Tagger
Fun tool. But perhaps hide (or give less weight) to the packages that are not “apps”?
– Maintainer mail-to links
Yes pls. A few times now I’ve searched through the koji, pkgs, etc pages desperately looking for a way to contact a MIA packager owner.
– Interaction with the Fedora system accessing Fedora Packages
That would be awesome. I have no idea how the browser can query the system like that, but somehow extensions.gnome.org can. Magic.
– Other ideas
I’d be interested in a list (preferrably an RSS) of the latest entirely new packages (not updates) introduced to Fedora.
Great work.
With regard to keeping up with new packages introduced to Fedora, I currently know of 2 different feeds that you could potentially monitor for that.
1) Closed Fedora Package Review Bugs
https://bugzilla.redhat.com/buglist.cgi?bug_status=CLOSED&classification=Fedora&component=Package%20Review&product=Fedora&query_format=advanced&title=Bug%20List&ctype=atom&limit=10
2) Fedora “new package” updates from bodhi.
https://admin.fedoraproject.org/updates/rss/rss2.0?type=newpackage
Looks good, potentially useful too.
Please find a better.. cleaner shorter url for it?
Dave
+1 I always use google to find fedora pkgdb (“fedora packages” is my friend). As oposed to packages.debian.org, which I have no problem to remember.
And thanks for this. This new interface is *much better*. Althought for Content tab, I would prefer just plain list of files. When the file list is huge I can search there using Ctrl+F better if it is not hierarchic and each line has full path.
When we deploy to our production environment, we’ll try and give it a nice clean URL. In the mean time, I setup these shortcuts that you can use:
http://j.mp/FedoraPackages
http://j.mp/FedoraTagger
[…] Více informací naleznete v blogu Máirín Duffy. […]
Hi. I’m glad to see Fedora getting tags and screenshots. I find it a missed opportunity, though, that debtags and screenshots.debian.net haven’t been mentioned here. Since the AppStream http://distributions.freedesktop.org/wiki/AppStream meeting a year ago, I have been trying my best to enable distributions to exchange of this kind of data:
http://enricozini.org/2011/debian/distromatch-deploy/
“What does this mean? For example it means that if another distribution has some data (categories, screenshots…) that your distribution doesn’t have, you can use distromatch to translate package names, then go and get it!”
I offered a working Xapian index implementation a year ago: http://distributions.freedesktop.org/wiki/AppStream/XapianIndexHOWTO as well as a method, via distromatch, to mass import into Fedora all the contents of screenshots.debian.net and debtags.debian.net.
It is totally not your fault, though: I’ve probably been failing to reach out to the right people. Will you or some other person involved in these efforts be at Fosdem? We should definitely talk.
Hi Enrico, our manager Tom “Spot” Callaway will be at FOSDEM representing Fedora, and I’m sure he would be happy to talk with you about some collaboration.
Ack, cool. I’ll email him.
Could we add the functionality to also include subpackages in the search results so that one could see to which src.rpm it belongs!
Otherwise it’s just fine and I really like the interface.
The subpackages should be in the search results. They display indented below their parent. If you’re not seeing a particular subpackage let me know which one and we’ll look into it.
The package search does not show results for obsoletes ( could be a bug or intentional )
The “Bugs” section could should display graph instead of digits to notice trends in reporting.
Average life time of a bug as in from new to closed. ( relates to reporters expectation ) is missing feature.
Another feature that is missing is package ( maintaince ) health status.
The “Source” could link to the srpm along with the Fedora git path.
Other than that it looks pretty good…
Hi Jóhann, I’m not sure if it should be showing obsoletes or not although to me it seems a good idea to note them and redirect to whatever replaced them. What do you think about that?
The bugs tab is one of the ones we had to de-prioritize to get stuff ready. Actually there is a new mockup for it that hasn’t been implemented yet:
https://fedoraproject.org/wiki/Fedora_Packager#Package_details_.3E_bugs
I love the idea of displaying graphs for the bugs. I don’t know if we have the ability to pull or calculate average lifetime of a bug from what Bugzilla’s API offers us but Luke can probably look into that – it seems a really useful statistic.
Package maintenance health status is also an excellent idea that had come up but I forgot to note in the list of ideas in the post. Although I think we have to toe a line that might be kind of thin between being helpful to developers and being really annoying / nagging to them on that feature 🙂
Thanks for the suggestions and ideas; they are great! 🙂
Package maintenance health is more for the rest of the community and Fedora user base then it is for the maintainer(s) as far as I see it.
From an end user perspective it would be very useful to determen which application to choose if both the application I’m looking for provide same or similar functionality.
From a maintainer stand point I could see a healt status of a package and see if I could assist in any shape or form ( fix bugs, become a co-maintaner etc ).
But I can understand the concerns that some of the maintainers would display about having such an health monitor but in the end those that do worry about this usually are the ones that aren’t doing a good job of maintaining their component.
I really regeret I didn’t attent this session. Looks like you and all the people involved in this project did a really outstanding job!
Cool .. will there be some sort of RESful service for ppl to query for package information from the server?
I would love to hook this into apprepo.org .. for example a link to this official package site if user want to view more info of packages contained in an app group..
oops .. my bad .. i read the post too fast .. just noticed that there will be a JSON api for it 🙂
/me shall wait with anticipation 🙂
[…] the background behind the idea, its implementation and future plans for Fedora Packages, in a detailed blog posting. The post also introduces the Fedora Tagger web site, which has been set up in parallel to Fedora […]
[…] der Quelltext. Um die Suche von Fedora-Packages weiter zu verbessern wurde ein Tagging-Projekt gestartet, in dessen Rahmen Anwender Pakete mit Schlagwörtern versehen können. This entry was […]
[…] weiteren Planungen von Fedora Packages erläutert die Fedora-Entwicklerin Máirín Duffy in einem detaillierten Blog-Eintrag. Dort stellt sie auch die parallel vorgestellte Website “Fedora Tagger” vor, mit der […]
This is spectacular. >.>; I’m seeing so much potential for both users and packagers here.
Is there any chance we’ll see some cool stuff for developers looking to bring their apps to Fedora users, as well?
I just want to say that this looks really great! I checked out the site, and it was really responsive when I looked at a couple of packages.
And, since I don’t think I’ve mentioned it before, I really enjoy reading your blog posts. I appreciate your attention to detail and how much you care about how stuff looks.
Initial feedback from quick smoke testing:
– When there is only one search result, why not go directly to that package? Basically, a “I’m feeling lucky” feature.
– The pitivi icon shows up stretched/pixellated… yet I’m pretty sure it bundles an SVG icon along the various PNG versions. Bug in “Packages” or bug in the package?
Just checked: gtg, abiword, gnumeric also have the same problem with their scalable icon not being used.
[…] Fedora has launched a new site that acts as a portal to view all packages within the Fedora repositories. They have also created a system that lets you tag packages in the repositories as part of a social gaming experience. […]
[…] mendiskusikan latar belakang proyek ini, implementasi dan masa depan Fedora Packages, dalam sebuah posting blog. Posting tersebut juga memperkenalkan Fedora Tagger, yang diset parallel dengan Fedora PAckages dan […]