Re: Onboarding package
On Tue, Nov 30, 2021 at 2:41 PM Otto Urpelainen wrote: > > Have you considered submitting a link to this to the Koji docs? A while > ago, I tried to set up a dev Koji environment just by following the > docs. Having a pointer to this would have been very useful. No, but that's a good idea! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Onboarding package
Ken Dreyer kirjoitti 30.11.2021 klo 20.56: On Sun, Oct 10, 2021 at 2:33 PM Dan Čermák wrote: Maybe we can make a VM image (for KVM/qemu + VirtualBox) with a small set of Fedora infra, including Koji+Bodhi. How about a vagrant box or a docker-compose file :) However, I'm a little worried that this might be too fat or not too simple to set up automatically (koji itself uses Kerberos for auth, which by itself is a huge beast…) Here's my Vagrant file that sets up Kerberos and Koji. https://github.com/ktdreyer/koji-playbooks/tree/master/vagrant It's overkill for new Fedora contributors but it helps with setting up dev Koji environments. Have you considered submitting a link to this to the Koji docs? A while ago, I tried to set up a dev Koji environment just by following the docs. Having a pointer to this would have been very useful. Otto ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Onboarding package
Could be useful for me to do too, I'm new to infra as an apprentice. On Tue, 30 Nov 2021 at 18:57, Ken Dreyer wrote: > On Sun, Oct 10, 2021 at 2:33 PM Dan Čermák > wrote: > > > Maybe we can make a VM image (for KVM/qemu + VirtualBox) with a small > > > set of Fedora infra, including Koji+Bodhi. > > > > How about a vagrant box or a docker-compose file :) > > > > However, I'm a little worried that this might be too fat or not too > > simple to set up automatically (koji itself uses Kerberos for auth, > > which by itself is a huge beast…) > > Here's my Vagrant file that sets up Kerberos and Koji. > https://github.com/ktdreyer/koji-playbooks/tree/master/vagrant > > It's overkill for new Fedora contributors but it helps with setting up > dev Koji environments. > > - Ken > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Onboarding package
On Sun, Oct 10, 2021 at 2:33 PM Dan Čermák wrote: > > Maybe we can make a VM image (for KVM/qemu + VirtualBox) with a small > > set of Fedora infra, including Koji+Bodhi. > > How about a vagrant box or a docker-compose file :) > > However, I'm a little worried that this might be too fat or not too > simple to set up automatically (koji itself uses Kerberos for auth, > which by itself is a huge beast…) Here's my Vagrant file that sets up Kerberos and Koji. https://github.com/ktdreyer/koji-playbooks/tree/master/vagrant It's overkill for new Fedora contributors but it helps with setting up dev Koji environments. - Ken ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Onboarding package
Hello Otto, I like the "Web based course" idea alot. I had thought of creating something as a pod of containerized parts of the whole to be used in a cloud server environment, or on a single machine and would be a reactive app, or collection of say. Anyway, I am very receptive to these ideas, the actual implementation I think we would need to sort out after we collective decide what it is that needs to be made, improved, dropped. I would like to start at it smaller per se', not try to get it all right at first. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Onboarding package
On Wed, Oct 6, 2021 at 5:21 AM Vít Ondruch wrote: > > > Dne 06. 10. 21 v 9:44 Zbigniew Jędrzejewski-Szmek napsal(a): > > On Wed, Oct 06, 2021 at 09:39:46AM +0200, Vít Ondruch wrote: > >> Dne 05. 10. 21 v 18:04 Stephen John Smoogen napsal(a): > >>> On Tue, 5 Oct 2021 at 11:28, Matthew Miller > >>> wrote: > On Mon, Oct 04, 2021 at 09:17:30PM +0200, Vitaly Zaitsev via devel wrote: > >> Is this really necessary? > > Yes. Because anyone can add something like this: > > %post > > rm -rf / > > > > And it will destroy the installed system or even the hardware. > Yeah, but... that's not going get through the PR process? In fact, that > specific thing should fail in CI before a human gets to it even. > > Overall, we put a lot of trust in maintainers. I don't see this > _particular_ > route as a likely one for violating that trust. > > >>> I think part of the problem is that I don't think the proposal has > >>> enough flesh on its bones for people not to see it causing all kinds > >>> of problems somewhere. Or vice versa seeing not enough to see it being > >>> worthwhile for a beginner. [For many a developer, PR's aren't that > >>> interesting to most developers and not what they think about when > >>> looking at packaging. Running fedpkg and making a spec file work on my > >>> system and through the complicated koji+bodhi+mbs+.. stack is real > >>> packaging.] So we need a real proposal with an end to end idea of what > >>> is being done, what is to be learned, and how it is to be 'watched' by > >>> real developers to make sure people are learning things. > >>> > >>> > >> This was proposed in the "release early, release often" spirit. So I > >> am glad for the generally positive feedback for this idea and I also > >> appreciate the concerns which were risen. > >> > >> And as I said, this targets the newcomers, so start with the PR is > >> probably the right thing to do. But even "start with PR" has more > >> degrees of freedom, e.g. should the contributors modify the > >> changelog manually or should the `%autorelease` / `%autochangelog` > >> be used as proposed by Matt? Maybe this could be two scenarios after > >> all. But it is hard to judge where the line is between being useful > >> to learn something and being tedious, boring, unattractive or > >> discouraging. > > I'd very much lean on the side of %autorelease/%autochangelog. > > That workflow isn't perfect yet, but it's certainly the feature, and > > in general, newcomers should learn the new workflows. > > (There's also the issue raised by Matt that with traditional > > %changelog pretty much each and every parallel pull request would > > conflict.) > > > I have put together very naive concept here: > > https://fedorapeople.org/cgit/vondruch/public_git/dummy-onboarding-contributors-pr.git/ > > https://copr.fedorainfracloud.org/coprs/vondruch/dummy-onboarding-contributors-pr/ > > However, with more traffic commits like [1] will conflict anyway. > Matthew recommended that it be a functional package and others have suggested that it should also be part of a Badge series. I think we could make this work fairly easily: 1) We write a simple application to include in the package. Its purpose will be to display a web page that lists the names of all of the CONTRIBUTORS up to this point and then, after 30 seconds, automatically redirects to the badge-claim link. 2) The application would also be designed to throw an error if the binary is located anywhere but /usr/bin. Essentially "you built the package and were able to install it successfully". 3) The application would generate the list of CONTRIBUTORS from a drop directory (CONTRIBUTORS.d) instead of a single file, so we can avoid the potential conflicts. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Onboarding package
Vitaly Zaitsev via devel writes: > On 05/10/2021 18:04, Stephen John Smoogen wrote: >> So we need a real proposal with an end to end idea of what >> is being done, what is to be learned, and how it is to be 'watched' by >> real developers to make sure people are learning things. > > Maybe we can make a VM image (for KVM/qemu + VirtualBox) with a small > set of Fedora infra, including Koji+Bodhi. How about a vagrant box or a docker-compose file :) However, I'm a little worried that this might be too fat or not too simple to set up automatically (koji itself uses Kerberos for auth, which by itself is a huge beast…) Cheers, Dan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Onboarding package
Kevin Fenzi writes: > Another possible way we could do this is have this setup in our staging > env. ie, they do the same things, but it's in staging (which we never > compose anyhow). That has the danger of something being broken in stg > without us realizing it, or them diverging. +1 on having this just in staging. While it will make it a little less like "the real deal", it will definitely lower the barrier for experimentation. And we could also periodically reset the package, so that newcomers can go wild ;-) Cheers, Dan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Onboarding package
Dne 06. 10. 21 v 20:06 Stephen Snow napsal(a): On Wed, 2021-10-06 at 18:39 +0200, Vít Ondruch wrote: --snip-- So it seems we are in agreement with the `dummy-onboarding-` prefix No, it should be something more appropriate like `entry-level-tutor-` Keep it coming please :) or something equally as nuetrally offensive. Dummy is a very negative word with no value of positive connotations in the English language. I have chosen this name mainly to be inline with what we already have: https://fedoraproject.org/wiki/DummyTestPackages and I'd like to avoid conflicts with other packages. However, you are right that there are probably better options. Vít regards, Stephen ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Onboarding package
Vít Ondruch kirjoitti 6.10.2021 klo 10.51: Dne 06. 10. 21 v 7:35 Otto Urpelainen napsal(a): Stephen Snow kirjoitti 5.10.2021 klo 15.39: we were initially discussing that it could be useful to have some package one can experiment with without being too much worried about the result. However, discussing this back and forth, we figured that it might also where new coming package maintainer could gradually gain experience with the packaging workflows. So the simplest tasks could be: 1) Add changelog entry into onboarding package and open PR with the change. This would not require too many privileges. Alternatively this current Fedora contributors might be interested to send such PR ;) I like this approach, but I was also thinking of a small tutorial/app to actually package a piece of software as required, going through the various steps but be a "fake" package that is only used to teach and test with. This app could record the FAS user ID and assign a badge to it once they complete the tutorial successfully. Sort of a base starting point for all new packagersd that give both them some confidence going in and the sponsors some confidence too about the level of the new committers capabilities. Well, in the Quick Docs, we already have Creating RPM packages [1]. It has subpage "Publishing your software on Copr", which somehow covers the publishing aspect. But honestly, when I was starting out, I spent some time with those instructions, but could not understand them or complete the tutorials. So one thing would be to revisit these instructions and make the better — there is a task about moving them over to Package Maintainer Docs [2], it was in progress at some point, but apparently stalled now. After that, improvement could happen. About every packager publishing their own test package, in Copr that can be done for sure. If it is deemed too far from the official Fedora repositories, the perhaps it could be done in staging. I have never really used it, I cannot say if that is a good idea or not. A similar but different idea I have is to create a "Fedora Packaging Guidelines Web Course" that you can complete by yourself. It could be implemented as a Git repository. For each entry in the the Review Guidelines [3], there would be a directory with a specfile and a srpm. For simplicity, we could first implement cases which fedora-review can check automatically. The student's assignment would be to run fedora-review on the specfile, find the error it gives, refer to the Packaging Guidelines to figure out how to fix it, modify the specfile as needed and run fedora-review again to check their answer. The assignment is completed when fedora-review does not complain any more. Later, the course could be expanded also to cases where there is no automated check available, either by involving a mentor, or simply by adding a SOLUTION file. Awarding a badge for completing this course would be a good idea, if a technical solution can be found. I see this course as complementary to Vít's original proposal about the onboarding package. The orboarding package tasks are about learning the build system, certainly a required skill for packages. The course is about learning the Guidelines. Currently the recommended method to do that is to submit inofficial reviews to live Review Requests. That has the advantage of exposing the applicant to real packages with real problems, but 1) has no guarantee of producing an effective learning path, the package that is picked may well be a very tricky case and thus unsuitable for starting out and 2) is psychologically unsafe, because a total newcomer must participate in discussion of two experts who are actually trying to get a package into Fedora, not educating the packagers. Just FTR, I like these ideas. Nevertheless, as with every idea, they need to be implemented and maintained. Therefore, from the experience, I think that onboarding package could survive longer, because it (hopefully) needs less maintenance. It is a valid concern. The onboarding package is just a single package, whereas if the would be N assignments, there would be also N specfiles to maintain as the guidelines change. Starting from the sections that are the least probable to change would help. Also note that I did not intend to propose to do something like this instead of the onboarding package, which is a good idea. Rather, this could be done in addition to that, and serves a different need. If there is another way, requiring less maintenance work, that allows learning how to apply the Packaging Guidelines, even better. It is just that the the current method of "just read the Guidelines" is too theoretical, and "comment on live reviews" is too hands-on. Otto ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le
Re: Onboarding package
On Wed, 2021-10-06 at 18:39 +0200, Vít Ondruch wrote: --snip-- > So it > seems we are in agreement with the `dummy-onboarding-` prefix No, it should be something more appropriate like `entry-level-tutor-` or something equally as nuetrally offensive. Dummy is a very negative word with no value of positive connotations in the English language. regards, Stephen ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Onboarding package
Dne 06. 10. 21 v 15:08 Zbigniew Jędrzejewski-Szmek napsal(a): On Wed, Oct 06, 2021 at 11:20:47AM +0200, Vít Ondruch wrote: Dne 06. 10. 21 v 9:44 Zbigniew Jędrzejewski-Szmek napsal(a): On Wed, Oct 06, 2021 at 09:39:46AM +0200, Vít Ondruch wrote: Dne 05. 10. 21 v 18:04 Stephen John Smoogen napsal(a): On Tue, 5 Oct 2021 at 11:28, Matthew Miller wrote: On Mon, Oct 04, 2021 at 09:17:30PM +0200, Vitaly Zaitsev via devel wrote: Is this really necessary? Yes. Because anyone can add something like this: %post rm -rf / And it will destroy the installed system or even the hardware. Yeah, but... that's not going get through the PR process? In fact, that specific thing should fail in CI before a human gets to it even. Overall, we put a lot of trust in maintainers. I don't see this _particular_ route as a likely one for violating that trust. I think part of the problem is that I don't think the proposal has enough flesh on its bones for people not to see it causing all kinds of problems somewhere. Or vice versa seeing not enough to see it being worthwhile for a beginner. [For many a developer, PR's aren't that interesting to most developers and not what they think about when looking at packaging. Running fedpkg and making a spec file work on my system and through the complicated koji+bodhi+mbs+.. stack is real packaging.] So we need a real proposal with an end to end idea of what is being done, what is to be learned, and how it is to be 'watched' by real developers to make sure people are learning things. This was proposed in the "release early, release often" spirit. So I am glad for the generally positive feedback for this idea and I also appreciate the concerns which were risen. And as I said, this targets the newcomers, so start with the PR is probably the right thing to do. But even "start with PR" has more degrees of freedom, e.g. should the contributors modify the changelog manually or should the `%autorelease` / `%autochangelog` be used as proposed by Matt? Maybe this could be two scenarios after all. But it is hard to judge where the line is between being useful to learn something and being tedious, boring, unattractive or discouraging. I'd very much lean on the side of %autorelease/%autochangelog. That workflow isn't perfect yet, but it's certainly the feature, and in general, newcomers should learn the new workflows. (There's also the issue raised by Matt that with traditional %changelog pretty much each and every parallel pull request would conflict.) I have put together very naive concept here: https://fedorapeople.org/cgit/vondruch/public_git/dummy-onboarding-contributors-pr.git/ master → main I just went with defaults. Why does the package have "-pr" in the name? We want people to contribute to it through PRs, but I don't think this needs to be part of the name. Remember that my initial proposal consisted at least from two scenarios. Submitting (as simple as possible) PR was just the first one. So it seems we are in agreement with the `dummy-onboarding-` prefix and I am open to better suggestion for the rest (including what other scenarios we can think of, Copr was mentioned already ;) ). BTW should the PR be preceded by opening BZ ticket against the component? However, with more traffic commits like [1] will conflict anyway. That's true. Maybe we can figure out some non-conflicting format, e.g. concatenate all files in contributors.d/ directory? Interesting idea. I'll try to look into this (and patches are welcomed). Also, I think the default license should be CC by-sa 4.0, the same as the default for Fedora [2]. +1 Vít Zbyszek [2] https://communityblog.fedoraproject.org/fedoras-default-license-for-content-is-now-cc-by-sa-4-0/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Onboarding package
On Wed, Oct 06, 2021 at 11:20:47AM +0200, Vít Ondruch wrote: > > Dne 06. 10. 21 v 9:44 Zbigniew Jędrzejewski-Szmek napsal(a): > >On Wed, Oct 06, 2021 at 09:39:46AM +0200, Vít Ondruch wrote: > >>Dne 05. 10. 21 v 18:04 Stephen John Smoogen napsal(a): > >>>On Tue, 5 Oct 2021 at 11:28, Matthew Miller > >>>wrote: > On Mon, Oct 04, 2021 at 09:17:30PM +0200, Vitaly Zaitsev via devel wrote: > >>Is this really necessary? > >Yes. Because anyone can add something like this: > >%post > >rm -rf / > > > >And it will destroy the installed system or even the hardware. > Yeah, but... that's not going get through the PR process? In fact, that > specific thing should fail in CI before a human gets to it even. > > Overall, we put a lot of trust in maintainers. I don't see this > _particular_ > route as a likely one for violating that trust. > > >>>I think part of the problem is that I don't think the proposal has > >>>enough flesh on its bones for people not to see it causing all kinds > >>>of problems somewhere. Or vice versa seeing not enough to see it being > >>>worthwhile for a beginner. [For many a developer, PR's aren't that > >>>interesting to most developers and not what they think about when > >>>looking at packaging. Running fedpkg and making a spec file work on my > >>>system and through the complicated koji+bodhi+mbs+.. stack is real > >>>packaging.] So we need a real proposal with an end to end idea of what > >>>is being done, what is to be learned, and how it is to be 'watched' by > >>>real developers to make sure people are learning things. > >>> > >>> > >>This was proposed in the "release early, release often" spirit. So I > >>am glad for the generally positive feedback for this idea and I also > >>appreciate the concerns which were risen. > >> > >>And as I said, this targets the newcomers, so start with the PR is > >>probably the right thing to do. But even "start with PR" has more > >>degrees of freedom, e.g. should the contributors modify the > >>changelog manually or should the `%autorelease` / `%autochangelog` > >>be used as proposed by Matt? Maybe this could be two scenarios after > >>all. But it is hard to judge where the line is between being useful > >>to learn something and being tedious, boring, unattractive or > >>discouraging. > >I'd very much lean on the side of %autorelease/%autochangelog. > >That workflow isn't perfect yet, but it's certainly the feature, and > >in general, newcomers should learn the new workflows. > >(There's also the issue raised by Matt that with traditional > >%changelog pretty much each and every parallel pull request would > >conflict.) > > > I have put together very naive concept here: > > https://fedorapeople.org/cgit/vondruch/public_git/dummy-onboarding-contributors-pr.git/ master → main Why does the package have "-pr" in the name? We want people to contribute to it through PRs, but I don't think this needs to be part of the name. > However, with more traffic commits like [1] will conflict anyway. That's true. Maybe we can figure out some non-conflicting format, e.g. concatenate all files in contributors.d/ directory? Also, I think the default license should be CC by-sa 4.0, the same as the default for Fedora [2]. Zbyszek [2] https://communityblog.fedoraproject.org/fedoras-default-license-for-content-is-now-cc-by-sa-4-0/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Onboarding package
On 2021-10-05 10:35 pm, Otto Urpelainen wrote: Stephen Snow kirjoitti 5.10.2021 klo 15.39: we were initially discussing that it could be useful to have some package one can experiment with without being too much worried about the result. However, discussing this back and forth, we figured that it might also where new coming package maintainer could gradually gain experience with the packaging workflows. So the simplest tasks could be: 1) Add changelog entry into onboarding package and open PR with the change. This would not require too many privileges. Alternatively this current Fedora contributors might be interested to send such PR ;) I like this approach, but I was also thinking of a small tutorial/app to actually package a piece of software as required, going through the various steps but be a "fake" package that is only used to teach and test with. This app could record the FAS user ID and assign a badge to it once they complete the tutorial successfully. Sort of a base starting point for all new packagersd that give both them some confidence going in and the sponsors some confidence too about the level of the new committers capabilities. Well, in the Quick Docs, we already have Creating RPM packages [1]. It has subpage "Publishing your software on Copr", which somehow covers the publishing aspect. But honestly, when I was starting out, I spent some time with those instructions, but could not understand them or complete the tutorials. So one thing would be to revisit these instructions and make the better — there is a task about moving them over to Package Maintainer Docs [2], it was in progress at some point, but apparently stalled now. After that, improvement could happen. About every packager publishing their own test package, in Copr that can be done for sure. If it is deemed too far from the official Fedora repositories, the perhaps it could be done in staging. I have never really used it, I cannot say if that is a good idea or not. A similar but different idea I have is to create a "Fedora Packaging Guidelines Web Course" that you can complete by yourself. It could be implemented as a Git repository. For each entry in the the Review Guidelines [3], there would be a directory with a specfile and a srpm. For simplicity, we could first implement cases which fedora-review can check automatically. The student's assignment would be to run fedora-review on the specfile, find the error it gives, refer to the Packaging Guidelines to figure out how to fix it, modify the specfile as needed and run fedora-review again to check their answer. The assignment is completed when fedora-review does not complain any more. Later, the course could be expanded also to cases where there is no automated check available, either by involving a mentor, or simply by adding a SOLUTION file. Awarding a badge for completing this course would be a good idea, if a technical solution can be found. I see this course as complementary to Vít's original proposal about the onboarding package. The orboarding package tasks are about learning the build system, certainly a required skill for packages. The course is about learning the Guidelines. Currently the recommended method to do that is to submit inofficial reviews to live Review Requests. That has the advantage of exposing the applicant to real packages with real problems, but 1) has no guarantee of producing an effective learning path, the package that is picked may well be a very tricky case and thus unsuitable for starting out and 2) is psychologically unsafe, because a total newcomer must participate in discussion of two experts who are actually trying to get a package into Fedora, not educating the packagers. [1]: https://docs.fedoraproject.org/en-US/quick-docs/creating-rpm-packages/ [2]: https://pagure.io/fedora-docs/package-maintainer-docs/issue/19 [3]: https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#_package_review_process packager to be already sponsored and they could go through the whole process themeselves just with some light guidance if needed. This could be extended in the future. E.g. next step could be: 3) Submit module update. Apart from gaining experience, this could also help with the common question "where should I start". And of course our sponsoring guidelines could be refreshed suggesting/requesting to take these steps at some point. Thoughts? Personnaly I am for this type of approach since it is also clarifying the roles a bit more too. It wouldn't hurt to outline what is expected of a packager of Fedora Linux in general. You know expectations are very often left unsaid thinking that roles and responsibilities fill in the info, but that is not always the case. Are you aware of the page "Package maintainer responsibilities" [4]? Is there some aspects of the responsibilities that are not covered there? [4]: https://docs.fedoraproject.o
Re: Onboarding package
Dne 06. 10. 21 v 9:44 Zbigniew Jędrzejewski-Szmek napsal(a): On Wed, Oct 06, 2021 at 09:39:46AM +0200, Vít Ondruch wrote: Dne 05. 10. 21 v 18:04 Stephen John Smoogen napsal(a): On Tue, 5 Oct 2021 at 11:28, Matthew Miller wrote: On Mon, Oct 04, 2021 at 09:17:30PM +0200, Vitaly Zaitsev via devel wrote: Is this really necessary? Yes. Because anyone can add something like this: %post rm -rf / And it will destroy the installed system or even the hardware. Yeah, but... that's not going get through the PR process? In fact, that specific thing should fail in CI before a human gets to it even. Overall, we put a lot of trust in maintainers. I don't see this _particular_ route as a likely one for violating that trust. I think part of the problem is that I don't think the proposal has enough flesh on its bones for people not to see it causing all kinds of problems somewhere. Or vice versa seeing not enough to see it being worthwhile for a beginner. [For many a developer, PR's aren't that interesting to most developers and not what they think about when looking at packaging. Running fedpkg and making a spec file work on my system and through the complicated koji+bodhi+mbs+.. stack is real packaging.] So we need a real proposal with an end to end idea of what is being done, what is to be learned, and how it is to be 'watched' by real developers to make sure people are learning things. This was proposed in the "release early, release often" spirit. So I am glad for the generally positive feedback for this idea and I also appreciate the concerns which were risen. And as I said, this targets the newcomers, so start with the PR is probably the right thing to do. But even "start with PR" has more degrees of freedom, e.g. should the contributors modify the changelog manually or should the `%autorelease` / `%autochangelog` be used as proposed by Matt? Maybe this could be two scenarios after all. But it is hard to judge where the line is between being useful to learn something and being tedious, boring, unattractive or discouraging. I'd very much lean on the side of %autorelease/%autochangelog. That workflow isn't perfect yet, but it's certainly the feature, and in general, newcomers should learn the new workflows. (There's also the issue raised by Matt that with traditional %changelog pretty much each and every parallel pull request would conflict.) I have put together very naive concept here: https://fedorapeople.org/cgit/vondruch/public_git/dummy-onboarding-contributors-pr.git/ https://copr.fedorainfracloud.org/coprs/vondruch/dummy-onboarding-contributors-pr/ However, with more traffic commits like [1] will conflict anyway. Vít [1] https://fedorapeople.org/cgit/vondruch/public_git/dummy-onboarding-contributors-pr.git/commit/?id=606ff9d7ff7672ad2692102c7a078ceaacaeeb9b Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Onboarding package
On 05/10/2021 18:04, Stephen John Smoogen wrote: So we need a real proposal with an end to end idea of what is being done, what is to be learned, and how it is to be 'watched' by real developers to make sure people are learning things. Maybe we can make a VM image (for KVM/qemu + VirtualBox) with a small set of Fedora infra, including Koji+Bodhi. Users can make "official" builds and then push them to the "repositories". -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Onboarding package
Dne 06. 10. 21 v 7:35 Otto Urpelainen napsal(a): Stephen Snow kirjoitti 5.10.2021 klo 15.39: we were initially discussing that it could be useful to have some package one can experiment with without being too much worried about the result. However, discussing this back and forth, we figured that it might also where new coming package maintainer could gradually gain experience with the packaging workflows. So the simplest tasks could be: 1) Add changelog entry into onboarding package and open PR with the change. This would not require too many privileges. Alternatively this current Fedora contributors might be interested to send such PR ;) I like this approach, but I was also thinking of a small tutorial/app to actually package a piece of software as required, going through the various steps but be a "fake" package that is only used to teach and test with. This app could record the FAS user ID and assign a badge to it once they complete the tutorial successfully. Sort of a base starting point for all new packagersd that give both them some confidence going in and the sponsors some confidence too about the level of the new committers capabilities. Well, in the Quick Docs, we already have Creating RPM packages [1]. It has subpage "Publishing your software on Copr", which somehow covers the publishing aspect. But honestly, when I was starting out, I spent some time with those instructions, but could not understand them or complete the tutorials. So one thing would be to revisit these instructions and make the better — there is a task about moving them over to Package Maintainer Docs [2], it was in progress at some point, but apparently stalled now. After that, improvement could happen. About every packager publishing their own test package, in Copr that can be done for sure. If it is deemed too far from the official Fedora repositories, the perhaps it could be done in staging. I have never really used it, I cannot say if that is a good idea or not. A similar but different idea I have is to create a "Fedora Packaging Guidelines Web Course" that you can complete by yourself. It could be implemented as a Git repository. For each entry in the the Review Guidelines [3], there would be a directory with a specfile and a srpm. For simplicity, we could first implement cases which fedora-review can check automatically. The student's assignment would be to run fedora-review on the specfile, find the error it gives, refer to the Packaging Guidelines to figure out how to fix it, modify the specfile as needed and run fedora-review again to check their answer. The assignment is completed when fedora-review does not complain any more. Later, the course could be expanded also to cases where there is no automated check available, either by involving a mentor, or simply by adding a SOLUTION file. Awarding a badge for completing this course would be a good idea, if a technical solution can be found. I see this course as complementary to Vít's original proposal about the onboarding package. The orboarding package tasks are about learning the build system, certainly a required skill for packages. The course is about learning the Guidelines. Currently the recommended method to do that is to submit inofficial reviews to live Review Requests. That has the advantage of exposing the applicant to real packages with real problems, but 1) has no guarantee of producing an effective learning path, the package that is picked may well be a very tricky case and thus unsuitable for starting out and 2) is psychologically unsafe, because a total newcomer must participate in discussion of two experts who are actually trying to get a package into Fedora, not educating the packagers. Just FTR, I like these ideas. Nevertheless, as with every idea, they need to be implemented and maintained. Therefore, from the experience, I think that onboarding package could survive longer, because it (hopefully) needs less maintenance. Vít [1]: https://docs.fedoraproject.org/en-US/quick-docs/creating-rpm-packages/ [2]: https://pagure.io/fedora-docs/package-maintainer-docs/issue/19 [3]: https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#_package_review_process packager to be already sponsored and they could go through the whole process themeselves just with some light guidance if needed. This could be extended in the future. E.g. next step could be: 3) Submit module update. Apart from gaining experience, this could also help with the common question "where should I start". And of course our sponsoring guidelines could be refreshed suggesting/requesting to take these steps at some point. Thoughts? Personnaly I am for this type of approach since it is also clarifying the roles a bit more too. It wouldn't hurt to outline what is expected of a packager of Fedora Linux in general. You know expectations are very often left unsaid
Re: Onboarding package
On Wed, Oct 06, 2021 at 09:39:46AM +0200, Vít Ondruch wrote: > > Dne 05. 10. 21 v 18:04 Stephen John Smoogen napsal(a): > >On Tue, 5 Oct 2021 at 11:28, Matthew Miller wrote: > >>On Mon, Oct 04, 2021 at 09:17:30PM +0200, Vitaly Zaitsev via devel wrote: > Is this really necessary? > >>>Yes. Because anyone can add something like this: > >>>%post > >>>rm -rf / > >>> > >>>And it will destroy the installed system or even the hardware. > >>Yeah, but... that's not going get through the PR process? In fact, that > >>specific thing should fail in CI before a human gets to it even. > >> > >>Overall, we put a lot of trust in maintainers. I don't see this _particular_ > >>route as a likely one for violating that trust. > >> > >I think part of the problem is that I don't think the proposal has > >enough flesh on its bones for people not to see it causing all kinds > >of problems somewhere. Or vice versa seeing not enough to see it being > >worthwhile for a beginner. [For many a developer, PR's aren't that > >interesting to most developers and not what they think about when > >looking at packaging. Running fedpkg and making a spec file work on my > >system and through the complicated koji+bodhi+mbs+.. stack is real > >packaging.] So we need a real proposal with an end to end idea of what > >is being done, what is to be learned, and how it is to be 'watched' by > >real developers to make sure people are learning things. > > > > > > This was proposed in the "release early, release often" spirit. So I > am glad for the generally positive feedback for this idea and I also > appreciate the concerns which were risen. > > And as I said, this targets the newcomers, so start with the PR is > probably the right thing to do. But even "start with PR" has more > degrees of freedom, e.g. should the contributors modify the > changelog manually or should the `%autorelease` / `%autochangelog` > be used as proposed by Matt? Maybe this could be two scenarios after > all. But it is hard to judge where the line is between being useful > to learn something and being tedious, boring, unattractive or > discouraging. I'd very much lean on the side of %autorelease/%autochangelog. That workflow isn't perfect yet, but it's certainly the feature, and in general, newcomers should learn the new workflows. (There's also the issue raised by Matt that with traditional %changelog pretty much each and every parallel pull request would conflict.) Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Onboarding package
Dne 05. 10. 21 v 18:04 Stephen John Smoogen napsal(a): On Tue, 5 Oct 2021 at 11:28, Matthew Miller wrote: On Mon, Oct 04, 2021 at 09:17:30PM +0200, Vitaly Zaitsev via devel wrote: Is this really necessary? Yes. Because anyone can add something like this: %post rm -rf / And it will destroy the installed system or even the hardware. Yeah, but... that's not going get through the PR process? In fact, that specific thing should fail in CI before a human gets to it even. Overall, we put a lot of trust in maintainers. I don't see this _particular_ route as a likely one for violating that trust. I think part of the problem is that I don't think the proposal has enough flesh on its bones for people not to see it causing all kinds of problems somewhere. Or vice versa seeing not enough to see it being worthwhile for a beginner. [For many a developer, PR's aren't that interesting to most developers and not what they think about when looking at packaging. Running fedpkg and making a spec file work on my system and through the complicated koji+bodhi+mbs+.. stack is real packaging.] So we need a real proposal with an end to end idea of what is being done, what is to be learned, and how it is to be 'watched' by real developers to make sure people are learning things. This was proposed in the "release early, release often" spirit. So I am glad for the generally positive feedback for this idea and I also appreciate the concerns which were risen. And as I said, this targets the newcomers, so start with the PR is probably the right thing to do. But even "start with PR" has more degrees of freedom, e.g. should the contributors modify the changelog manually or should the `%autorelease` / `%autochangelog` be used as proposed by Matt? Maybe this could be two scenarios after all. But it is hard to judge where the line is between being useful to learn something and being tedious, boring, unattractive or discouraging. Vít ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Onboarding package
Stephen Snow kirjoitti 5.10.2021 klo 15.39: we were initially discussing that it could be useful to have some package one can experiment with without being too much worried about the result. However, discussing this back and forth, we figured that it might also where new coming package maintainer could gradually gain experience with the packaging workflows. So the simplest tasks could be: 1) Add changelog entry into onboarding package and open PR with the change. This would not require too many privileges. Alternatively this current Fedora contributors might be interested to send such PR ;) I like this approach, but I was also thinking of a small tutorial/app to actually package a piece of software as required, going through the various steps but be a "fake" package that is only used to teach and test with. This app could record the FAS user ID and assign a badge to it once they complete the tutorial successfully. Sort of a base starting point for all new packagersd that give both them some confidence going in and the sponsors some confidence too about the level of the new committers capabilities. Well, in the Quick Docs, we already have Creating RPM packages [1]. It has subpage "Publishing your software on Copr", which somehow covers the publishing aspect. But honestly, when I was starting out, I spent some time with those instructions, but could not understand them or complete the tutorials. So one thing would be to revisit these instructions and make the better — there is a task about moving them over to Package Maintainer Docs [2], it was in progress at some point, but apparently stalled now. After that, improvement could happen. About every packager publishing their own test package, in Copr that can be done for sure. If it is deemed too far from the official Fedora repositories, the perhaps it could be done in staging. I have never really used it, I cannot say if that is a good idea or not. A similar but different idea I have is to create a "Fedora Packaging Guidelines Web Course" that you can complete by yourself. It could be implemented as a Git repository. For each entry in the the Review Guidelines [3], there would be a directory with a specfile and a srpm. For simplicity, we could first implement cases which fedora-review can check automatically. The student's assignment would be to run fedora-review on the specfile, find the error it gives, refer to the Packaging Guidelines to figure out how to fix it, modify the specfile as needed and run fedora-review again to check their answer. The assignment is completed when fedora-review does not complain any more. Later, the course could be expanded also to cases where there is no automated check available, either by involving a mentor, or simply by adding a SOLUTION file. Awarding a badge for completing this course would be a good idea, if a technical solution can be found. I see this course as complementary to Vít's original proposal about the onboarding package. The orboarding package tasks are about learning the build system, certainly a required skill for packages. The course is about learning the Guidelines. Currently the recommended method to do that is to submit inofficial reviews to live Review Requests. That has the advantage of exposing the applicant to real packages with real problems, but 1) has no guarantee of producing an effective learning path, the package that is picked may well be a very tricky case and thus unsuitable for starting out and 2) is psychologically unsafe, because a total newcomer must participate in discussion of two experts who are actually trying to get a package into Fedora, not educating the packagers. [1]: https://docs.fedoraproject.org/en-US/quick-docs/creating-rpm-packages/ [2]: https://pagure.io/fedora-docs/package-maintainer-docs/issue/19 [3]: https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#_package_review_process packager to be already sponsored and they could go through the whole process themeselves just with some light guidance if needed. This could be extended in the future. E.g. next step could be: 3) Submit module update. Apart from gaining experience, this could also help with the common question "where should I start". And of course our sponsoring guidelines could be refreshed suggesting/requesting to take these steps at some point. Thoughts? Personnaly I am for this type of approach since it is also clarifying the roles a bit more too. It wouldn't hurt to outline what is expected of a packager of Fedora Linux in general. You know expectations are very often left unsaid thinking that roles and responsibilities fill in the info, but that is not always the case. Are you aware of the page "Package maintainer responsibilities" [4]? Is there some aspects of the responsibilities that are not covered there? [4]: https://docs.fedoraproject.o
Re: Onboarding package
On Tue, Oct 5, 2021 at 11:27 AM Matthew Miller wrote: > > On Mon, Oct 04, 2021 at 09:17:30PM +0200, Vitaly Zaitsev via devel wrote: > > >Is this really necessary? > > > > Yes. Because anyone can add something like this: > > %post > > rm -rf / > > > > And it will destroy the installed system or even the hardware. > > Yeah, but... that's not going get through the PR process? In fact, that > specific thing should fail in CI before a human gets to it even. So you're going to ensure that the people using this package to experiment/learn can *only* submit via PR? I like that. I find it to be better, but not sufficient depending on how that works. > Overall, we put a lot of trust in maintainers. I don't see this _particular_ > route as a likely one for violating that trust. I think I'd like to see a more sketched out flow. This isn't for maintainers, it's for people trying to learn to be maintainers. They're still building that trust via this whole thing, right? josh ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Onboarding package
On Tue, 5 Oct 2021 at 11:28, Matthew Miller wrote: > > On Mon, Oct 04, 2021 at 09:17:30PM +0200, Vitaly Zaitsev via devel wrote: > > >Is this really necessary? > > > > Yes. Because anyone can add something like this: > > %post > > rm -rf / > > > > And it will destroy the installed system or even the hardware. > > Yeah, but... that's not going get through the PR process? In fact, that > specific thing should fail in CI before a human gets to it even. > > Overall, we put a lot of trust in maintainers. I don't see this _particular_ > route as a likely one for violating that trust. > I think part of the problem is that I don't think the proposal has enough flesh on its bones for people not to see it causing all kinds of problems somewhere. Or vice versa seeing not enough to see it being worthwhile for a beginner. [For many a developer, PR's aren't that interesting to most developers and not what they think about when looking at packaging. Running fedpkg and making a spec file work on my system and through the complicated koji+bodhi+mbs+.. stack is real packaging.] So we need a real proposal with an end to end idea of what is being done, what is to be learned, and how it is to be 'watched' by real developers to make sure people are learning things. -- Stephen J Smoogen. I've seen things you people wouldn't believe. Flame wars in sci.astro.orion. I have seen SPAM filters overload because of Godwin's Law. All those moments will be lost in time... like posts on a BBS... time to shutdown -h now. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Onboarding package
On Mon, Oct 04, 2021 at 09:17:30PM +0200, Vitaly Zaitsev via devel wrote: > >Is this really necessary? > > Yes. Because anyone can add something like this: > %post > rm -rf / > > And it will destroy the installed system or even the hardware. Yeah, but... that's not going get through the PR process? In fact, that specific thing should fail in CI before a human gets to it even. Overall, we put a lot of trust in maintainers. I don't see this _particular_ route as a likely one for violating that trust. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Onboarding package
Hello Vit, I was one of those potential packagers who started a conversation here regarding the apparent dificulies experienced by some to varying degrees. In my simple non-packager perspective, There needs to be some tool used to help sponsors feel comfortable with the potential packagers capability and also for the packager to help them guage their own competence. (snip) > we were initially discussing that it could be useful to have some > package one can experiment with without being too much worried about > the > result. > > However, discussing this back and forth, we figured that it might > also > where new coming package maintainer could gradually gain experience > with > the packaging workflows. So the simplest tasks could be: > > 1) Add changelog entry into onboarding package and open PR with the > change. This would not require too many privileges. Alternatively > this > current Fedora contributors might be interested to send such PR ;) > I like this approach, but I was also thinking of a small tutorial/app to actually package a piece of software as required, going through the various steps but be a "fake" package that is only used to teach and test with. This app could record the FAS user ID and assign a badge to it once they complete the tutorial successfully. Sort of a base starting point for all new packagersd that give both them some confidence going in and the sponsors some confidence too about the level of the new committers capabilities. > packager to be already sponsored and they could go through the whole > process themeselves just with some light guidance if needed. > > This could be extended in the future. E.g. next step could be: > > 3) Submit module update. > > Apart from gaining experience, this could also help with the common > question "where should I start". And of course our sponsoring > guidelines > could be refreshed suggesting/requesting to take these steps at some > point. > > Thoughts? > Personnaly I am for this type of approach since it is also clarifying the roles a bit more too. It wouldn't hurt to outline what is expected of a packager of Fedora Linux in general. You know expectations are very often left unsaid thinking that roles and responsibilities fill in the info, but that is not always the case. Looking forward to this progress, Stephen > > Vít > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Onboarding package
On Tue, Oct 05, 2021 at 12:28:03PM +0200, Petr Menšík wrote: > I like the idea. > > I think we can even setup tests namespace repo for it, which would > ensure all content in this package is %doc only. It does not contain > %post scripts and no executable, unless strictly predefined content. > That CI repo would have more strict access to ensure newcomers cannot > avoid automated checks. > > We could ask new contributors to review PRs of candidates and merge and > build them. > > I think this package definitely should be part of the distribution. > Other packages should not depend on it, so it would get installed only > by those who want it. New contributors could also be proud once they > have their name in a real package. Don't force anyone, but blocking is > not needed IMHO. Yep. In particular, changes should generate a visible %changelog entry, so that prospective maintainers can see how their commit message are visible to users. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Onboarding package
I like the idea. I think we can even setup tests namespace repo for it, which would ensure all content in this package is %doc only. It does not contain %post scripts and no executable, unless strictly predefined content. That CI repo would have more strict access to ensure newcomers cannot avoid automated checks. We could ask new contributors to review PRs of candidates and merge and build them. I think this package definitely should be part of the distribution. Other packages should not depend on it, so it would get installed only by those who want it. New contributors could also be proud once they have their name in a real package. Don't force anyone, but blocking is not needed IMHO. Cheers, Petr On 10/4/21 21:09, Kevin Fenzi wrote: > On Mon, Oct 04, 2021 at 02:42:58PM -0400, Matthew Miller wrote: >> On Mon, Oct 04, 2021 at 05:52:33PM +, Zbigniew Jędrzejewski-Szmek wrote: I like the idea! We can block such a package from ever appearing in a compose in pungi. >>> Is this really necessary? The package will not be open to anyone, >>> but only for approved contributors. Malicious behaviour is not more >>> likely then in any other package (and would be immediately caught). >>> I think we're thinking up technical solutions to something that is >>> not a problem. >> Yeah, I think making it a real package is a good idea. Maybe even a little >> packaged script that runs >> >> xdg-open https://docs.fedoraproject.org/en-US/fedora-join/ >> >> ? >> >> The package itself can even be a gateway to onboarding for the curious, but >> more importantly, it'd act more like a real package. > True. As long as there's a group of experenced folks watching it, that > should be ok. > > kevin > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Onboarding package
Dne 04. 10. 21 v 16:22 Vitaly Zaitsev via devel napsal(a): On 04/10/2021 10:57, Vít Ondruch wrote: Recently, there have been a lot of discussions on this list as well as we have internally about onboarding. During our internal brainstorming, we were initially discussing that it could be useful to have some package one can experiment with without being too much worried about the result. I like this idea, but such packages shouldn't be pushed to the official Fedora repositories. 2) Second step could be something similar, but that would require the packager to be already sponsored and they could go through the whole process themeselves just with some light guidance if needed. We have COPR. It doesn't require anything other than the FAS account. I was thinking about this in my follow up, but I am not sure if Copr workflow is separate case or if it should precede the fokflow (2). The thing is that these two are quite distinct. While submitting package into Copr is definitely good step introducing new package into Fedora, I don't know how to integrate this into onboarding to not be side step. Vít ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Onboarding package
On Mon, Oct 04, 2021 at 09:17:30PM +0200, Vitaly Zaitsev via devel wrote: > On 04/10/2021 19:52, Zbigniew Jędrzejewski-Szmek wrote: > >Is this really necessary? > > Yes. Because anyone can add something like this: > %post > rm -rf / > > And it will destroy the installed system or even the hardware. Eh, please don't overtrim the message you are replying to. > The package will not be open to anyone, but only for approved contributors. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Onboarding package
On Mon, Oct 4, 2021 at 8:58 AM Vít Ondruch wrote: > Thoughts? Anything that improves the onboarding process can only be a good thing. I would recommend that before going too deep into weeds that you need a small group of "non-packagers"(*) to see if this is the right approach from their perspective, and whether they can successfully navigate it with the resources that will be available to help. If so declare success, and if not iterate based on the feedback. (*) The problem is that the people that tend to be part of this discussion have mostly completely forgotten about the details and lessons they learned along the way and that are now part of muscle memory. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Onboarding package
On 04/10/2021 19:52, Zbigniew Jędrzejewski-Szmek wrote: Is this really necessary? Yes. Because anyone can add something like this: %post rm -rf / And it will destroy the installed system or even the hardware. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Onboarding package
On Mon, Oct 04, 2021 at 02:42:58PM -0400, Matthew Miller wrote: > On Mon, Oct 04, 2021 at 05:52:33PM +, Zbigniew Jędrzejewski-Szmek wrote: > > > I like the idea! > > > We can block such a package from ever appearing in a compose in pungi. > > Is this really necessary? The package will not be open to anyone, > > but only for approved contributors. Malicious behaviour is not more > > likely then in any other package (and would be immediately caught). > > I think we're thinking up technical solutions to something that is > > not a problem. > > Yeah, I think making it a real package is a good idea. Maybe even a little > packaged script that runs > > xdg-open https://docs.fedoraproject.org/en-US/fedora-join/ > > ? > > The package itself can even be a gateway to onboarding for the curious, but > more importantly, it'd act more like a real package. True. As long as there's a group of experenced folks watching it, that should be ok. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Onboarding package
On Mon, Oct 04, 2021 at 05:52:33PM +, Zbigniew Jędrzejewski-Szmek wrote: > > I like the idea! > > We can block such a package from ever appearing in a compose in pungi. > Is this really necessary? The package will not be open to anyone, > but only for approved contributors. Malicious behaviour is not more > likely then in any other package (and would be immediately caught). > I think we're thinking up technical solutions to something that is > not a problem. Yeah, I think making it a real package is a good idea. Maybe even a little packaged script that runs xdg-open https://docs.fedoraproject.org/en-US/fedora-join/ ? The package itself can even be a gateway to onboarding for the curious, but more importantly, it'd act more like a real package. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Onboarding package
On Mon, Oct 04, 2021 at 10:10:35AM -0700, Kevin Fenzi wrote: > On Mon, Oct 04, 2021 at 10:57:42AM +0200, Vít Ondruch wrote: > > Thoughts? > > I like the idea! > > We can block such a package from ever appearing in a compose in pungi. Is this really necessary? The package will not be open to anyone, but only for approved contributors. Malicious behaviour is not more likely then in any other package (and would be immediately caught). I think we're thinking up technical solutions to something that is not a problem. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Onboarding package
On Mon, Oct 04, 2021 at 03:15:24PM +0100, Richard W.M. Jones wrote: > On Mon, Oct 04, 2021 at 10:57:42AM +0200, Vít Ondruch wrote: > > Hi, > > > > Recently, there have been a lot of discussions on this list as well > > as we have internally about onboarding. During our internal > > brainstorming, we were initially discussing that it could be useful > > to have some package one can experiment with without being too much > > worried about the result. > > > > However, discussing this back and forth, we figured that it might > > also be good idea to actually have something such as "onboarding" > > package, where new coming package maintainer could gradually gain > > experience with the packaging workflows. So the simplest tasks could > > be: > > > > 1) Add changelog entry into onboarding package and open PR with the > > change. This would not require too many privileges. Alternatively > > this could include change to "CONTRIBUTORS" file. I suspect that > > also some current Fedora contributors might be interested to send > > such PR ;) > > > > 2) Second step could be something similar, but that would require > > the packager to be already sponsored and they could go through the > > whole process themeselves just with some light guidance if needed. > > > > This could be extended in the future. E.g. next step could be: > > > > 3) Submit module update. > > > > Apart from gaining experience, this could also help with the common > > question "where should I start". And of course our sponsoring > > guidelines could be refreshed suggesting/requesting to take these > > steps at some point. > > > > Thoughts? > > It's a good idea, but it's probably also a good idea to block it from > installation at the dnf level. If it was open to everyone even > non-sponsored then someone could anonymously put something nasty in it, > like a %post script. I don't think it'll be "open to anyone". In the described workflow, non-approved packagers can only open PRs (like they already can against any package). Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Onboarding package
On Mon, 4 Oct 2021 at 13:25, Josh Boyer wrote: > > On Mon, Oct 4, 2021 at 1:10 PM Kevin Fenzi wrote: > > > > On Mon, Oct 04, 2021 at 10:57:42AM +0200, Vít Ondruch wrote: > > > Thoughts? > > > > I like the idea! > > It's indeed a good idea. > > > We can block such a package from ever appearing in a compose in pungi. > > You'd need to block it from ever appearing in the buildroots. You > wouldn't want someone adding something to it that injected code that > impacted the builds of other packages. > Would it be better if this happened in stg.fedoraproject.org environment to triply make sure it didn't affect production? -- Stephen J Smoogen. I've seen things you people wouldn't believe. Flame wars in sci.astro.orion. I have seen SPAM filters overload because of Godwin's Law. All those moments will be lost in time... like posts on a BBS... time to shutdown -h now. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Onboarding package
On Mon, Oct 04, 2021 at 10:57:42AM +0200, Vít Ondruch wrote: > However, discussing this back and forth, we figured that it might > also be good idea to actually have something such as "onboarding" > package, where new coming package maintainer could gradually gain > experience with the packaging workflows. So the simplest tasks could > be: Like others, I like the idea. > 1) Add changelog entry into onboarding package and open PR with the > change. This would not require too many privileges. Alternatively > this could include change to "CONTRIBUTORS" file. I suspect that > also some current Fedora contributors might be interested to send > such PR ;) Let's make this package use rpmautospec with %autorelease and %autochangelog. This will keep simultaneous PRs from new contributors from arbitrarily conflicting _every time_, and also help introduce people to the new way of doing things. So given that, let's make the actual change to CONTRIBUTORS. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Onboarding package
On Mon, Oct 4, 2021 at 1:10 PM Kevin Fenzi wrote: > > On Mon, Oct 04, 2021 at 10:57:42AM +0200, Vít Ondruch wrote: > > Thoughts? > > I like the idea! It's indeed a good idea. > We can block such a package from ever appearing in a compose in pungi. You'd need to block it from ever appearing in the buildroots. You wouldn't want someone adding something to it that injected code that impacted the builds of other packages. josh > So, perhaps we seperate it into: > > > open a bug, submit a pr, do a scratch build, look at ci > > > get added as commit to onboarding package > create pr, merge pr, do official build, submit update, etc > > Another possible way we could do this is have this setup in our staging > env. ie, they do the same things, but it's in staging (which we never > compose anyhow). That has the danger of something being broken in stg > without us realizing it, or them diverging. > > Great idea tho, I like it. > > kevin > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Onboarding package
On Mon, Oct 04, 2021 at 10:57:42AM +0200, Vít Ondruch wrote: > Thoughts? I like the idea! We can block such a package from ever appearing in a compose in pungi. So, perhaps we seperate it into: open a bug, submit a pr, do a scratch build, look at ci get added as commit to onboarding package create pr, merge pr, do official build, submit update, etc Another possible way we could do this is have this setup in our staging env. ie, they do the same things, but it's in staging (which we never compose anyhow). That has the danger of something being broken in stg without us realizing it, or them diverging. Great idea tho, I like it. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Onboarding package
On 04/10/2021 10:57, Vít Ondruch wrote: Recently, there have been a lot of discussions on this list as well as we have internally about onboarding. During our internal brainstorming, we were initially discussing that it could be useful to have some package one can experiment with without being too much worried about the result. I like this idea, but such packages shouldn't be pushed to the official Fedora repositories. 2) Second step could be something similar, but that would require the packager to be already sponsored and they could go through the whole process themeselves just with some light guidance if needed. We have COPR. It doesn't require anything other than the FAS account. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Onboarding package
This is a great idea. I've been reading through the new packager documentation this weekend and attempting to get my first package submitted. It would be really nice if there was a way to go all the way through the process with a "real" package, but without effecting anything, to help those who "learn by doing". ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Onboarding package
On Mon, Oct 04, 2021 at 10:57:42AM +0200, Vít Ondruch wrote: > Hi, > > Recently, there have been a lot of discussions on this list as well > as we have internally about onboarding. During our internal > brainstorming, we were initially discussing that it could be useful > to have some package one can experiment with without being too much > worried about the result. > > However, discussing this back and forth, we figured that it might > also be good idea to actually have something such as "onboarding" > package, where new coming package maintainer could gradually gain > experience with the packaging workflows. So the simplest tasks could > be: > > 1) Add changelog entry into onboarding package and open PR with the > change. This would not require too many privileges. Alternatively > this could include change to "CONTRIBUTORS" file. I suspect that > also some current Fedora contributors might be interested to send > such PR ;) > > 2) Second step could be something similar, but that would require > the packager to be already sponsored and they could go through the > whole process themeselves just with some light guidance if needed. > > This could be extended in the future. E.g. next step could be: > > 3) Submit module update. > > Apart from gaining experience, this could also help with the common > question "where should I start". And of course our sponsoring > guidelines could be refreshed suggesting/requesting to take these > steps at some point. > > Thoughts? It's a good idea, but it's probably also a good idea to block it from installation at the dnf level. If it was open to everyone even non-sponsored then someone could anonymously put something nasty in it, like a %post script. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Onboarding package
Dne 04. 10. 21 v 11:34 Zbigniew Jędrzejewski-Szmek napsal(a): On Mon, Oct 04, 2021 at 10:57:42AM +0200, Vít Ondruch wrote: Hi, Recently, there have been a lot of discussions on this list as well as we have internally about onboarding. During our internal brainstorming, we were initially discussing that it could be useful to have some package one can experiment with without being too much worried about the result. However, discussing this back and forth, we figured that it might also be good idea to actually have something such as "onboarding" package, where new coming package maintainer could gradually gain experience with the packaging workflows. So the simplest tasks could be: 1) Add changelog entry into onboarding package and open PR with the change. This would not require too many privileges. Alternatively this could include change to "CONTRIBUTORS" file. I suspect that also some current Fedora contributors might be interested to send such PR ;) 2) Second step could be something similar, but that would require the packager to be already sponsored and they could go through the whole process themeselves just with some light guidance if needed. Forgot to mention these could be rewarded by appropriate badges ;) +1. We already have some test-only packages (for ci testing?), and one more wouldn't really matter. It'd be nice to match the naming pattern. https://fedoraproject.org/wiki/DummyTestPackages I assume that 1) above would be be done with the sponsor/mentor doing the merge and actual build, and 2) would be done with no direct sponsor/mentor interaction. The question always is how far we would go. E.g. would be some or mutliple of those scenarios enough to be sponsored? There could also be Copr scenarios, or it could be incorporated in the (1). This package should have multiple release branches, to exercise multi-release updates. Good idea, right. Vít This could be extended in the future. E.g. next step could be: 3) Submit module update. Apart from gaining experience, this could also help with the common question "where should I start". And of course our sponsoring guidelines could be refreshed suggesting/requesting to take these steps at some point. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Onboarding package
Hi! I like this idea. As a new contributor, I am really scared to touch anything related to committing the package, for fear of screwing up, so something that is not screwable as onboarding sounds great. On 10/4/21 5:57 AM, Vít Ondruch wrote: Hi, Recently, there have been a lot of discussions on this list as well as we have internally about onboarding. During our internal brainstorming, we were initially discussing that it could be useful to have some package one can experiment with without being too much worried about the result. However, discussing this back and forth, we figured that it might also be good idea to actually have something such as "onboarding" package, where new coming package maintainer could gradually gain experience with the packaging workflows. So the simplest tasks could be: 1) Add changelog entry into onboarding package and open PR with the change. This would not require too many privileges. Alternatively this could include change to "CONTRIBUTORS" file. I suspect that also some current Fedora contributors might be interested to send such PR ; 2) Second step could be something similar, but that would require the packager to be already sponsored and they could go through the whole process themeselves just with some light guidance if needed. I like the first task a lot. The second task could be you merging your PR, or someone else's if someone has already merged yours. This could be extended in the future. E.g. next step could be: 3) Submit module update. Apart from gaining experience, this could also help with the common question "where should I start". And of course our sponsoring guidelines could be refreshed suggesting/requesting to take these steps at some point. Thoughts? Vít ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure -- Cheers! Bruno Larsen ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Onboarding package
On Mon, Oct 04, 2021 at 10:57:42AM +0200, Vít Ondruch wrote: > Hi, > > Recently, there have been a lot of discussions on this list as well > as we have internally about onboarding. During our internal > brainstorming, we were initially discussing that it could be useful > to have some package one can experiment with without being too much > worried about the result. > > However, discussing this back and forth, we figured that it might > also be good idea to actually have something such as "onboarding" > package, where new coming package maintainer could gradually gain > experience with the packaging workflows. So the simplest tasks could > be: > > 1) Add changelog entry into onboarding package and open PR with the > change. This would not require too many privileges. Alternatively > this could include change to "CONTRIBUTORS" file. I suspect that > also some current Fedora contributors might be interested to send > such PR ;) > > 2) Second step could be something similar, but that would require > the packager to be already sponsored and they could go through the > whole process themeselves just with some light guidance if needed. +1. We already have some test-only packages (for ci testing?), and one more wouldn't really matter. It'd be nice to match the naming pattern. I assume that 1) above would be be done with the sponsor/mentor doing the merge and actual build, and 2) would be done with no direct sponsor/mentor interaction. This package should have multiple release branches, to exercise multi-release updates. > This could be extended in the future. E.g. next step could be: > > 3) Submit module update. > > Apart from gaining experience, this could also help with the common > question "where should I start". And of course our sponsoring > guidelines could be refreshed suggesting/requesting to take these > steps at some point. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Onboarding package
Hi, Recently, there have been a lot of discussions on this list as well as we have internally about onboarding. During our internal brainstorming, we were initially discussing that it could be useful to have some package one can experiment with without being too much worried about the result. However, discussing this back and forth, we figured that it might also be good idea to actually have something such as "onboarding" package, where new coming package maintainer could gradually gain experience with the packaging workflows. So the simplest tasks could be: 1) Add changelog entry into onboarding package and open PR with the change. This would not require too many privileges. Alternatively this could include change to "CONTRIBUTORS" file. I suspect that also some current Fedora contributors might be interested to send such PR ;) 2) Second step could be something similar, but that would require the packager to be already sponsored and they could go through the whole process themeselves just with some light guidance if needed. This could be extended in the future. E.g. next step could be: 3) Submit module update. Apart from gaining experience, this could also help with the common question "where should I start". And of course our sponsoring guidelines could be refreshed suggesting/requesting to take these steps at some point. Thoughts? Vít ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
