Re: Onboarding package

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

 



Hello Vit,
I was one of those potential packagers who started a conversation here
regarding the apparent dificulies experienced by some to varying
degrees. In my simple non-packager perspective, There needs to be some
tool used to help sponsors feel comfortable with the potential
packagers capability and also for the packager to help them guage their
own competence.

(snip)

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

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

Looking forward to this progress,

Stephen
> 
> Vít
> _______________________________________________
> 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

_______________________________________________
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