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
<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...
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