|
My opinion as a simple enthusiast, is that things should be separated in two
1 - Those who have a great piece of software, simply willing to make it available to the large public. In such case, there should be only quality barrier of the package + rules of duration (i.e. added packages are not kept in Fedora if not maintained for instance once a year)
2 - Those who wants to be much more involved into Fedora project, and this is in deed another story
For instance, personally, I am not using Fedora at all (Arch fan ;) ) but just willing to make my piece of software available widely for those interested. I am happy to maintain the package in the long run, but will not get involve to much into Fedora project except my small piece of software contribution.
On 2021-05-01 07:03, Otto Urpelainen wrote:
Bryce Carson kirjoitti 1.5.2021 klo 3.21:
For what it's worth, I'm trying to join and have a package included and
there are definitely some areas I would like to improve. Should we make a
thread on their mailing list?
On Fri., Apr. 30, 2021, 5:50 p.m. Bryce Carson, <bryce.a.carson@xxxxxxxxx>
wrote:
Perhaps we could improve the wiki page on Joining** to make it more clear
what the process is like?
I read through the guidelines and the Joining page a couple times, and
only near the end does it state that Joining is more about, well, joining
as a person than publishing a package. I believe it then recommendeds Copr
around that point for simple publishing.
Maybe we could ask Docs and some newer joiners to do a little review of
the wiki for Joining and see if we can rewrite and modernize?
I joined during 2021, and also I felt that the entry barrier was quite high. Long instructions involving complex toolset and buildsystem and socially scary things like writing introductory messages to mailing lists and publicly commenting on package reviews. I think a lot could be done to make Fedora packaging more approachable. A certain barrier will always be there, because you must have a) the expertise and b) the trust of the Fedora community to maintain your package and acquiring these requires some investment. Regarding joining as a person vs. adding a package, I think the page title "Join the package collection maintainers" already resolves that, as do the first two sentences: "So, you have decided to become a package maintainer in the Fedora Project? This guide will lead you through your first package submission." But I can understand how the page might seem confusing if you start from the "I just want to add this package to Fedora repositories" mindset. Do you think it would help if that page started with a an Overview section, that very briefly explains hwo the process goes and why the different steps are there? For me, the most difficult part was the suggestion that the aspiring packager should immediately comment on other package reviews to get sponsored. I see review as an expert task, so I did not feel secure to do that as the first task. Enough to that I used another method of getting sponsored [ 1]. It was not completely clear to me (even though the instructions actually say so) that I could have first get my package reviewed and approved, and only then start doing those preliminary reviews to get sponsored. I guess a simple edit on the "How to get sponsored into the packager group" page could clarify that. Otherwise, in case there are other newcomers who had the same apprehension of preliminary reviews, maybe alternative methods involving pull requests to existing packages etc. could be given more visibility? [1]: https://pagure.io/packager-sponsors/issue/455Otto _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxxTo unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxxFedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelinesList Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxxDo not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
|
