Vít Ondruch kirjoitti 6.10.2021 klo 10.51:
Dne 06. 10. 21 v 7:35 Otto Urpelainen napsal(a):
> Stephen Snow kirjoitti 5.10.2021 klo 15.39:
>>> we were initially discussing that it could be useful to have some
>>> package one can experiment with without being too much worried about
>>> the
>>> result.
>>>
>>> However, discussing this back and forth, we figured that it might
>>> also
>>> where new coming package maintainer could gradually gain experience
>>> with
>>> the packaging workflows. So the simplest tasks could be:
>>>
>>> 1) Add changelog entry into onboarding package and open PR with the
>>> change. This would not require too many privileges. Alternatively
>>> this
>>> current Fedora contributors might be interested to send such PR ;)
>>>
>> I like this approach, but I was also thinking of a small tutorial/app
>> to actually package a piece of software as required, going through the
>> various steps but be a "fake" package that is only used to teach and
>> test with. This app could record the FAS user ID and assign a badge to
>> it once they complete the tutorial successfully. Sort of a base
>> starting point for all new packagersd that give both them some
>> confidence going in and the sponsors some confidence too about the
>> level of the new committers capabilities.
>
> Well, in the Quick Docs, we already have Creating RPM packages [1]. It
> has subpage "Publishing your software on Copr", which somehow covers
> the publishing aspect. But honestly, when I was starting out, I spent
> some time with those instructions, but could not understand them or
> complete the tutorials. So one thing would be to revisit these
> instructions and make the better — there is a task about moving them
> over to Package Maintainer Docs [2], it was in progress at some point,
> but apparently stalled now. After that, improvement could happen.
>
> About every packager publishing their own test package, in Copr that
> can be done for sure. If it is deemed too far from the official Fedora
> repositories, the perhaps it could be done in staging. I have never
> really used it, I cannot say if that is a good idea or not.
>
> A similar but different idea I have is to create a "Fedora Packaging
> Guidelines Web Course" that you can complete by yourself. It could be
> implemented as a Git repository. For each entry in the the Review
> Guidelines [3], there would be a directory with a specfile and a srpm.
> For simplicity, we could first implement cases which fedora-review can
> check automatically. The student's assignment would be to run
> fedora-review on the specfile, find the error it gives, refer to the
> Packaging Guidelines to figure out how to fix it, modify the specfile
> as needed and run fedora-review again to check their answer. The
> assignment is completed when fedora-review does not complain any more.
>
> Later, the course could be expanded also to cases where there is no
> automated check available, either by involving a mentor, or simply by
> adding a SOLUTION file.
>
> Awarding a badge for completing this course would be a good idea, if a
> technical solution can be found.
>
> I see this course as complementary to Vít's original proposal about
> the onboarding package. The orboarding package tasks are about
> learning the build system, certainly a required skill for packages.
> The course is about learning the Guidelines. Currently the recommended
> method to do that is to submit inofficial reviews to live Review
> Requests. That has the advantage of exposing the applicant to real
> packages with real problems, but 1) has no guarantee of producing an
> effective learning path, the package that is picked may well be a very
> tricky case and thus unsuitable for starting out and 2) is
> psychologically unsafe, because a total newcomer must participate in
> discussion of two experts who are actually trying to get a package
> into Fedora, not educating the packagers.
Just FTR, I like these ideas. Nevertheless, as with every idea, they
need to be implemented and maintained. Therefore, from the experience, I
think that onboarding package could survive longer, because it
(hopefully) needs less maintenance.
It is a valid concern. The onboarding package is just a single package,
whereas if the would be N assignments, there would be also N specfiles
to maintain as the guidelines change. Starting from the sections that
are the least probable to change would help.
Also note that I did not intend to propose to do something like this
instead of the onboarding package, which is a good idea. Rather, this
could be done in addition to that, and serves a different need.
If there is another way, requiring less maintenance work, that allows
learning how to apply the Packaging Guidelines, even better. It is just
that the the current method of "just read the Guidelines" is too
theoretical, and "comment on live reviews" is too hands-on.
Otto