On 2021-10-05 10:35 pm, Otto Urpelainen wrote:
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.
[1]:
https://docs.fedoraproject.org/en-US/quick-docs/creating-rpm-packages/
[2]: https://pagure.io/fedora-docs/package-maintainer-docs/issue/19
[3]:
https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#_package_review_process
packager to be already sponsored and they could go through the whole
process themeselves just with some light guidance if needed.
This could be extended in the future. E.g. next step could be:
3) Submit module update.
Apart from gaining experience, this could also help with the common
question "where should I start". And of course our sponsoring
guidelines
could be refreshed suggesting/requesting to take these steps at some
point.
Thoughts?
Personnaly I am for this type of approach since it is also clarifying
the roles a bit more too. It wouldn't hurt to outline what is expected
of a packager of Fedora Linux in general. You know expectations are
very often left unsaid thinking that roles and responsibilities fill
in
the info, but that is not always the case.
Are you aware of the page "Package maintainer responsibilities" [4]?
Is there some aspects of the responsibilities that are not covered
there?
[4]:
https://docs.fedoraproject.org/en-US/fesco/Package_maintainer_responsibilities/
_______________________________________________
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
As a novice packager and only slightly less green tester, the idea is
great!
Since onboarding I've noticed that the requisite knowledge needed to
achieve a goal
is often in the dialog between Fedora community members. Docs such as
"Package
maintainer responsibilities" [1] likely only are because of
conversations such
as this thread.
The onboarding package can easily be a place for new packagers to
demonstrate
to sponsors specific learned lessons in a way that less time consuming
for both
the new packager and the sponsor.
[1]:
https://docs.fedoraproject.org/en-US/fesco/Package_maintainer_responsibilities/
_______________________________________________
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
