On Thu, May 21, 2020 at 11:17 AM Artur Iwicki <suve(a)fedoraproject.org&gt; wrote: That's a good idea -- I could try to put one together. -- Kalev

Hello, As part of the marketing team, I think we could put a community campaign, with a video series (series means at least 3) posted properly on YouTube and promoted by Twitter, CommBlog and ML: "Package with us!" Wdyt! Br, El jue., 21 may. 2020 a las 6:12, Ankur Sinha (<sanjay.ankur(a)gmail.com>) escribió: -- Eduard Lucena Móvil: +56962318010 GNU/Linux User #589060 Ubuntu User #8749 Fedora Marketing Representative

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Thu, 2020-05-21 at 09:52 +0100, Ankur Sinha wrote: That would be useful I think. Though, we need to decide what kind of packaging we would like to teach people. There are many different languages / ecosystems, so everywhere it is different. - -- Igor Raits <ignatenkobrain(a)fedoraproject.org&gt;

Dne 21. 05. 20 v 10:52 Ankur Sinha napsal(a): There is already: https://docs.pagure.org/copr.copr/user_documentation.html#how-can-i-packa... It already includes two recordings of such workshops. And I encourage everyone to particapate on https://rpm-packaging-guide.github.io/ You can contribute to this at: https://github.com/redhat-developer/rpm-packaging-guide -- Miroslav Suchy, RHCA Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys

On Sat, Jun 6, 2020 at 5:54 AM Andy Mender <andymenderunix(a)gmail.com&gt; wrote: Yes, the move to docs.fp.o is frustrating because googling what I need often points me to the old location and then I have to click the link to get to the new location. And while the docs site looks "prettier", everything seems to be "bigger" so it takes more scrolling to find what I need. Also, we used to keep things like "since Fedora X, it's no longer necessary to use Y in your spec file." Now, if it gets removed because it's automatically handled by scriptlets or file triggers, it just "disappears" from the guidelines. That makes it confusing for long time packagers :) more up-to-date and more comprehensive. I used to work with FreeBSD a lot Not, packaging related, but under the same umbrella as general documentation, I often find myself using Arch docs as they seem to be quite detailed and comprehensive. We don't seem to have anything like that level of documentation. The Fedora Magazine articles are great to lower the barrier of entry, but YES PLEASE. Documentation isn't necessarily and afterthought, but it's not "fun" and not many people want to do it. Thanks, Richard

On Sat, 2020-06-06 at 08:54 -0700, stan via devel wrote: Well, I can just put my 2 cents in here... I've requested my first package not so long ago [1] and after I find the documentation [2] [3] it was rather "simple" to learn how to do a proper spec file. I was a Gentoo dev and an Arch AUR package and the difference was enormous since the other ones are basically bash scripts. RPM is whole different world. That being said, RPM packaging is not *that* difficult to grasp, everything is in one place and easy to understand and find what your looking for. What I find that it's missing is the actual tooling that's needed and how to use it. From fedmsg to mockbuilds to copr- cli you name it, let alone the actual workflow of merging a package, "forks, versions, bodhi", are some of the terms I read in this ML, but since I never actually merged one, everything is just "void" for now. All of this did not deter me from making a package and wanting it in the repos (I even have a few more to go along with it), but yes, this part I find that the information is lacking (or maybe I just didn't find it).

On Sat, Jun 06, 2020 06:40:43 -0500, Richard Shaw wrote: There's a bit of complexity here that makes it hard to put everything in one place: - rpm is a package management system, and it is not specific to Fedora. So the rpm docs, as expected, live outside of Fedora - The packaging guidelines are not "how to build rpms" in my book. They are the list of software development best practices that we follow while building rpms for inclusion in Fedora. So, our guidelines do not apply to other distributions using RPM. So, these live in the Fedora space. I see https://docs.fedoraproject.org/en-US/quick-docs/create-hello-world-rpm/ here, so perhaps the how to on the wiki can be merged there and a redirect set up? Would anyone like to work on this? <- docs contribution opportunity! Quite a few of these are known issues, but the docs team needs more manpower to solve them all. (In fact, the docs team seems to be barely scraping by at the moment) Related tickets and discussion: - adding search functions to docs.fp.o: https://pagure.io/fedora-docs/docs-fp-o/issue/2 - removal of old docs: https://pagure.io/fedora-docs/docs-fp-o/issue/128, https://pagure.io/fedora-docs/docs-fp-o/issue/67, https://pagure.io/fedora-docs/docs-fp-o/issue/30 https://pagure.io/fedora-docs/docs-fp-o/issue/53 https://lists.fedoraproject.org/archives/list/docs@lists.fedoraproject.or... So, as with the rest of Fedora, the primary issue here is lack of manpower. I personally don't have a solution to this, but we're trying to get more newbies involved using the Fedora Join SIG: https://pagure.io/fedora-join/Welcome-to-Fedora So if you run into newcomers, please send them to us. If you are community member, please spare some time to help newcomers. From AskFedora too, we try to get "users" to contribute to quick-docs as a gateway to general contribution to Fedora: https://ask.fedoraproject.org/t/optimus-setting-the-nvidia-gpu-as-primary... -> https://pagure.io/fedora-docs/quick-docs/pull-request/240 -> https://docs.fedoraproject.org/en-US/quick-docs/how-to-set-nvidia-as-prim... So, if you do have time, please also keep an eye on AskFedora and suggest easy contribution tasks to "users". Since attracting newcomer to increase our contribution base has always been something we as a community tend to struggle with, this needs a general CommOps/Mindshare/Council level plan perhaps. I don't know. I don't make any proposals to them because I am unable to dedicate the time to work on them myself. (PS: I use "users" because I'm one of those people that do not believe in the "user" "developer" dichotomy in FOSS. It tends to give people outside the community a wrong sense of how we work---they treat us like corporations that provide software and service in return for ... what? So, I prefer to use "community members" for everyone: devs/users/non-dev folks) -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London

Hi Ankur, Ankur Sinha <sanjay.ankur(a)gmail.com&gt; writes: That is true, getting into packaging is not easy at all. Besides improving existing docs, how about having a individual packagers helping out newcomers in 1:1 chats, e.g. on IRC or Jitsi?

Am 21.05.20 um 10:52 schrieb Ankur Sinha: Agreed. There might be another simple thing how we could get new contributors: I noticed that sometimes users asked in bugzilla/on a mailing list if they could help in maintaining some (more or less orphaned/unmaintained) package. IIRC they never got an answer (as nobody reads bugzilla comments for unmaintained packages). Also there was a similar post on epel-devel. I think we have a pretty big hole in the process here - it is too easy for interested people to "fall through the cracks". Also requiring them to review some unrelated packages to demonstrate their knowlegde is a pretty big hurdle. Last year there was a user who submitted a review request (which was approved) but did not find a sponsor because reviewing more packages (without some guidance to ensure the efforts won't go unnoticed) seemed to be too time consuming. Instead he chose to spend more time in upstream development. I noticed that he seemed to be aware of the most important things about packaging in Fedora and was able to connect him with a sponsor (and vouched for him by ensuring that sponsor I would be co-maintaining the new package so I could fix any fallout). Long story short: He got sponsored soon after and maintains the application in Fedora since then pretty successfully. I tried to act as primary point of contact for any questions and help solving some minor issues. => Maybe we could also scale-out if regular packagers could "mentor" (not sponsor) new packagers. To do so it would be helpful to me which sponsors have free cycles to take new packagers. Felix