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 <mattdm@xxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
