Package Maintainers! I want to make your life easier

This week I’ve been cranking out mockups for the Fedora Community Project (read the recent fedora-announce-list announcement, or view the Moksha presentation given earlier this month at FUDcon 11).

The mockups I’ve been working on this week have focused around the metadata and tabs surrounding one particular package. I used nautilus as an example in the mockups. What I would love to hear from you is if you have any particular wants/desires/needs around getting information or discovering things about a particular package that you maintain. I would really appreciate if you had the time to look over these mockups (currently there are five) and let me know if they seem like they would be useful to you, or if they have any useless information on them, or if you think there is anything missing or not quite right about them:
Also, if you haven’t gotten a chance to yet and have the time/inclination, I would love to hear your feedback on any or all of the full set of Fedora Community mockups.
Peace! 🙂


  1. Anonymous says:


    Hi mihmo,

    I really like the look. It would definitely help new maintainers but really comes into its own where people are looking after multiple packages I feel. Also big fan of the community aspect of it – seeing who is online at the time.


    Not sure about the top bar _and_ sidebar. The latter reminds me of the old wiki – I’ve just never been keen on having stuff on the right of the screen. Prefer mediawiki style menu system. Other than that, its looking great!


    1. Re: Sidebar

      Ah okay cool. Yeh I’m not really totally happy with the chrome/layout around the main content area. I think that is definitely going to evolve and change. For example, the tabs on the left side take up a lot of space in addition to the sidebars on the right. They should maybe be on the same side.

  2. Anonymous says:


    Very launchpad-like! (not a bad thing)

    1. Re: Nice

      fwiw I’ve never used launchpad… 🙂


    I don’t know how this project relates to other pages. My main pet peeve is missing equivalent of — both in its search ability (take a look at for example) and showing the dependencies. I think at least the latter would be good additional page in your package viewer. Or how does your project relates to (currently rather lame)

    1. Re:
      Ah okay, that view might be more appropriate maybe for a per-release listing outside of the individual package listings. Altho Nicolas Mailhot had the cool idea of per package, listing out what spins it's a member of. Maybe we could list out what package groups its a member of too! Although comps and package groupings I think are a bit of a mess – I think the directory of applications on really relies on that package grouping directory for you to find what you're looking for. I am not sure that is metadata we have solidly in Fedora unfortunately 🙁 Do you have any ideas on where to get it from? Would comps package groups work for you?

      1. Re:
        In whatever comps related questions I would rely probably on jkeating … 😉

      2. Anonymous says:


        Debian also has which is more developer-focused and probably worth stealing ideas from for this project.

  4. Anonymous says:

    space for project icon/logo

    In terms of ensuring user recognition in a world with many confusingly named projects, maybe space for an icon would be useful? I know I regularly use the icons to separate the linux distribution from fedora the digital library software.

    1. Re: space for project icon/logo
      Hey I think that's a great idea! Nicolas Mailhot was telling me Richard Hughes is looking at having thumbnails for apps in Package Kit so maybe we can use those here as well.

  5. Build logs

    Something which would be really useful would be quick (one-click) access to the latest build log for the package on each branch. I use those build logs often to check not only for the causes of build failures, but also for missing optional dependencies in successful builds.

    1. Re: Build logs

      Ooh interesting. So right now I’ve just got, per package, the list of builds (per release eg rawhide | fedora 10 | fedora 9) in chronological order, most recent to least recent:

      Does that page look like it will be helpful, or is it just not that useful-looking? I’m not sure if you would even care about build failures for a build that happened 6 builds ago? It sounds like the way you’re posing it would be a more useful display.

      It almost feels like what you’re suggesting could be another column in the “Active Releases Overview” section of right now that is more updates-centric with the testing status of each release… maybe an updates-specific one could go on the updates tab for the package, and the one you’re talking about could go on the top of the builds tab (the first mockup linked above)?

      This is really great feedback, so thank you for taking the time!

  6. Anonymous says:

    Big fan of your work…

    Mo, I continue to be a big fan of your work. Keep on rocking it.

    1. Re: Big fan of your work…

      thank you 🙂 🙂 what a nice message!

  7. Like it!

    Love it, actually!

    1. Re: Like it!

      Yay!!! 🙂

  8. grouped updates?
    How is this supposed to handled grouped updates?
    (ex: push foo and bar which depends on foo in a single update to prevent broken deps.)
    Also because of this I don't think that the related packages view is really useful (but it doesn't hurt either)
    Besides this it looks good, having all this infos collected in a view like that might indeed make maintaining packages easier.

    1. Anonymous says:

      Re: grouped updates?
      I've been wanting to create the concept of a "stack" within this dashboard that will allow people to easily push groups of updates (ie: firefox, gnome, etc) through koji and bodhi. Mo and I discussed this a little while back, but we have yet to throw together any mockups for it.

  9. Anonymous says:

    Great work.

    Hi, I think you are on the way for a useful tool.

    But I ‘d like to dream a little : 3 more great info :

    – EPEL status (so probably RH status for core package)

    – the “weight”/”success” of the package. I understand than exact download stats isn’t possible, but a relative figure about how many users of it.

    – an “upstream” line. Yes difficult, but doable for some large family (php, perl, R, …). Examples of what can be done :

    See also :


  10. […] the term ‘paintain’ – I love it! Possibly related posts: (automatically generated)Package Maintainers! I want to make your life easierAnother Shameless Font Packaging RequestGeneral-Purpose Fedora PostersHow the Fedora Project works […]

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.