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/
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@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
_______________________________________________
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
