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.
Vít
_______________________________________________
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
