Fedora

Does Fedora Project want new packagers?

Last week, we held a Fedora Packaging Workshop in Brno office of Red Hat. 16 participants showed up. Some of them were interested in just creating an RPM, some wanted to get their packages to Fedora and some were interested in creating RPMs for RHEL (we had quite a few participants from companies). I and four lecturers (Ondrej Vasik, Jaroslav Reznik, Stano Ochotnicky, Mirek Suchy) prepared an all-day intensive workshop.

But I don’t want to talk about the workshop in this blogpost. The workshop just made me wonder “do we really want new packagers?”. I often hear complaints in the community that the number of community packagers is decreasing and the Red Hat vs. community packagers ratio is not healthy. But I wonder if we’re doing (at least remotely) our best to get new packagers. We’ve already held several packaging workshops and most participants agreed that packaging for Fedora is a very complex thing, maybe unnecessarily complex. Documentation is outdated and scattered. There are tons of tools that are not integrated. And when we introduce COPRs we will even have more than one build system. And if someone is willing to go through all this, he hits the review process which is handled by Red Hat bugzilla which is not integrated with the rest, again. There are hundreds of review requests waiting and the lucky ones get the process done in months. There was one participant at the workshop who made a package of his tool for Fedora around Fedora 15 and never got it to Fedora. When you learn such a complex thing as packaging, get familiar with all the tools, it must be really frustrating not to make it all the way. And that guys was indeed frustrated.

So when someone starts complaining that the number of new packagers is decreasing and saying it must be a sign of decreasing number of people interested in Fedora, I will tell him to look at what new packagers have to through. In the time when other platforms are trying to make inclusion of new software, if not as easy as possible, at least as streamlined as possible, Fedora stands out and people are not willing to through all the hassle any more. But maybe we just don’t want and need new packagers…

Advertisements

12 thoughts on “Does Fedora Project want new packagers?

  1. Looks like my first attempt failed so here I go again 🙂

    One of the best place to learn how to improve things are these kind of workshops. Most of us, old packager, do not really realize what is blocking new packager or how things can be improved to help them.

    Did you have such discussion at the workshop?
    Do you have a list of action points that we (as a community) could try to tackle to improve things for new comer?

  2. You are spot on and thank you for pointing this out.

    I have been packaging for a very long time, maintain hundreds of large and small packages outside of the Fedora/EPEL repo and can very much relate to the frustration. The process is extremely tedious, slow, unclear, needlessly complex and if I had a bad day I would almost call it hostile by design. It’s an embarrassing mess, not a positive experience for a newcomer and not in sync with “Freedom, Friends, Features, First”. Friends don’t let friends suffer through the Fedora Packaging/Packager process…

    So I have given up. And I think it’s Fedora’s loss. I’ll happily maintain my packages and won’t even bother any more to submit a BZ for bugs or changes so the package for example also works on EL (why is that not a requirement?!). I’d rather maintain and use my own packages then to have to go through Fedora’s Packaging & Packager process. Who needs that crap? If someone wants to give his/her time and efforts for free to the project then the Fedora Community should be way more welcoming, facilitating, efficient and expedient than it currently is.

    The problem to me seems the human factor. AFAIK there is no incentive or obligation for approved Packagers to review packages so any attempt to become an approved Packager can take eons. Which genius came up with that process? Then there are approved Packagers who are at best junior and think they know packaging better than the new experienced guy and come up with silly reviews which delay the whole process by more eons. Why should anyone want to suffer through that?

    The whole Packaging & Packager process is in serious need of a big overhaul. Here are some ideas: anyone who has been approved as a Packager should be required to review at least 10 packages and become a co-maintainer of another 10 packages within say 3 months of becoming a packager (guided by a senior Packager aka mentor through public clue-by-4). Secondly anyone who applies as a Packager should be approved (or disapproved) within 2 weeks. No exceptions, period.

    Once the powers that be have put some sanity back into the Packaging & Packager process I’ll happily revisit the possibility of becoming a Packager.

    1. You just can’t wave rules like that around in a volunteer project. “Everyone must be accepted or rejected in two months” will simply lead to people getting rejected-by-default because the clock ran out: why is it better to be rejected in two months than accepted in six?

      Your rule about maintaining a certain number of packages is also absurd. Take, for instance, the libreoffice maintainers:

      It’s always interesting to me how many Fedora people’s first response to ‘process X sucks’ is ‘let’s pass a law that everyone must do X on pain of pain!’ I didn’t realize we had such a tinpot dictator mentality. The more sensible approach, surely, to ‘process X sucks’ is ‘let’s make process X simpler and smoother for people to be a part of’, not ‘let’s force people to use process X by punishing them if they don’t’.

  3. I really agree with Pieter.

    As a recent (as of yesterday) “new” package maintainer I do find it very very difficult to answer any questions I have on packaging and getting the process right.

    The documentation on the process (not so much on actual rpm building) has a lot of background information but very little direct details on a simple step by step process on what needs to be done and what end result it gives.

    So far, if it wasn’t for the assistance of my sponsor, I would have been better off just packaging rpms myself and not actually throwing them into Fedora at all.

    I was really disappointed I couldn’t make it to this workshop, but I think it would be invaluable for the future, to have more of a focus on helping those in the community get involved and not scaring them off with difficulties at the first hurdle.

    Dale

  4. I got an e-mail from a I-want-to-be-a-packager today. He has submitted a package for a review, he’s looking for a sponsor. Unfortunately he does not know how to reach a sponsor who understands packaging Perl modules.

    I know one such sponsor accidentally, so I redirected the packager to him.

    However I did a quick search and I found only this . It points to , but there is no way how to tell which sponsor is interested in what.

    Would it be possible link maintain the SIG and sponsorship relation somehow? Maybe this data could be listed on each SIG web page?

    BTW I counted 120 sponsors. Does Fedora needs more sponsors or does Fedora needs sponsors who do sponsor actually?

    1. I think we have enough sponsors, but I think being a sponsor should not only be a right, but also a duty. In Fedora Ambassadors, mentors are supposed to be active. If they are not and don’t reply to new candidates at all, they might end up being removed from the group or at least marked as inactive. But I don’t think sponsors are the only problems even though it’s probably the biggest bottleneck.
      In the ideal world, I imagine the whole process integrated in one system. Something like OBS, but even better 🙂 You could build your own packages in your private repo and when you think they’re good enough, you could just ask for a review that would be handled in the same system. You wouldn’t have to use several build systems, learn several work flows. The set of tools we have reminds me a bit of a snowball where more and more tools are added to fix or improve particular issues, but the whole system is a mess.

  5. So is there a distribution with an idealic packaging process? If yes then rather than inventing arbitrary rules we should adopt/adapt the principles that makes that distro packaging process good.

    Opensuse has also implemented something for the community that could be improved on. https://connect.opensuse.org/ a portal for users to connect, this very much supports the Friends in Fedora but also allow people to locate people/packagers(any role) and get assistance with what they aim to contribute.

  6. There are 150 sponsor, but only 82 people have been sponsored this year.
    I thing it can be good start to write script, which will be run every quoter and will send email to sponsor, which does not sponsor anybody this quoter with friendly message “Hi, it seems that you did not sponsore anybody. Can you please find some time and check the queue LINK and pick somebody for sponsoring?” No enforcing. Just friendly question.

  7. The topic ought to be discussed on a public mailing-list, such as Fedora “devel” list.

    Some new packagers find a sponsor quickly, because they are not too lazy to do a minimum of work, and they are responsive.

    1. That’s why my introduction to Fedora life time ended with communications section. Unfortunately reporting review to BZ is not enough, you have to try to find right people and talk to them directly. But that’s a huge barrier for (most) newcomers – to start talking to unknown people, being a bit afraid…

      What I really like to see would be some integration between Copr and Koji, you would use same tools to create initial package for review (using one set of tools), maintain it for some time aside main Fedora repos, once you’re ok with it, you probably talked to many people in community, you would just click on “Contribute to Fedora Repository” button in. Now automated review will start, for items that needs to be checked, there would be notification inside the system to packagers – better chance to spot new review, nice to have to send it to the right SIG… After review, it will be in the main repository, you would still use the same tools!, similar process, no need to learn new tools and new workflows…

      You know, I had a dream and now back to the reality :). I’m just not able to contribute to this project, so my talk is cheap…

      1. Some of the current [optional] requirements for new packagers, such as contributing a few reviews as some sort of “homework” and exercise, may be too much. Many new packagers are not willing to do such work, not even a self-review of an own package. Even simply responding in a bugzilla review ticket (or replying by private email to establish contact) seems to be a huge barrier for some newcomers already.

        Others easily find negative words about the entire process and the packaging guidelines. Either during review or in private replies. It’s hard to find common grounds then. People, who are unhappy with something related to the Fedora Project, are more likely to give up later, if not during review already. There are rules/guidelines not just for new package submitters, but also for reviewers and sponsors. Both sides need to accept that as a fact. If a package submitter considers the review as unneeded bureaucracy, that’s hard to fix. We don’t only aim at speed, but we have package quality in mind. The package review process reveals mistakes in packages, which often enough mean that something does not work (or does not work correctly) after installing it. Misplaced files as a common thing.

        There are enough approved packagers, who give up after some time anyway for different (or unknown) reasons. Sometimes because they are fed up with something else related to Fedora (e.g. lack of response to one of their bug reports).

        There also seem to be varying opinions about what it means “to maintain a package” in the Fedora package collection. Despite the existing “maintainer responsibilities” docs, which everybody may read prior to trying to join. Regularly, a package submitter needs to act like a maintainer already during review and talk to upstream about some issue. There are enough cases where a review stalls at that point because of no progress. That’s lack of interest in basic tasks related to package maintenance. There is no reason to assume that somebody, who drops the ball during review, would not have given up later.

        Reviewing new packages and introducing new contributors to the guidelines and processes is not always an easy task either. Especially not if the submitter spends less time on a package than the reviewer. Also, different sponsors handle the process differently and with varying effort. Some people are left alone already after a single review and approval of their one and only package submission. And once the first series of problem reports arrives in bugzilla, there is nobody who watches them and nobody who guides them. Unless they actively request for help (either from their sponsor or in some public communication channel), this can develop into an unfortunate situation for the packager and/or the users of the package -> unhandled bugzilla tickets, unhandled crashes, package users talking to /dev/null.

        > maintain it for some time aside main Fedora repos

        That could be helpful. However, some packagers stop already if their spec file manages to build a package. They are under a false impression of when a package would be up to Fedora’s requirements. More package submitters need to show interest in rpmlint, the fedora-review tool, and develop raising interest in the packaging related Wiki pages.

  8. IMHO, Fedora need to introduce an official “sandbox” repository for candidates, like Rawhide, but with lifted restrictions, e.g. all approved packagers can edit/comment/review/patch/etc. any package submitted by newcomers. Then let approved maintainers to pickup useful packages from this “sandbox” repository into “staging” repository, for “fast track” inclusion into Fedora Rawhide.

    PS.
    I submitted my package two years ago: https://bugzilla.redhat.com/show_bug.cgi?id=751411 . Now I just forgot what I should do next to finish this ticket. Maybe I need just to close that ticket 😦

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s