Re: Onboarding package

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Oct 6, 2021 at 5:21 AM Vít Ondruch <vondruch@xxxxxxxxxx> 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/
>
> https://copr.fedorainfracloud.org/coprs/vondruch/dummy-onboarding-contributors-pr/
>
> 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.
_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux