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(a)fedoraproject.org>
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-contri...
https://copr.fedorainfracloud.org/coprs/vondruch/dummy-onboarding-contrib...
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.