On Sun, 2021-11-21 at 11:18 -0500, Matthew Miller wrote: -snip- > > I don't think we have a good process for the situation you're in. If > the > package you were interested in were entirely new, or if you were > reinstating > a package which wsa retired (the step beyond "orphan"), you'd file > and go > through the package review process in bugzilla, and at that point if > you > hadn't found a sponsor yet, the docs suggest that the sponsor's > ticketing > system is the next step. > So what I have figured out from the experiences of others who have shared with me is I can just do a PR for the fix I think will work for said package and submit it that way. Thus support in an unoffical capacity, which is entirely acceptable in my opinion, but it isn't a documented route nor a formal one, just one that works. > But without those first steps, how do you get there? > > Probably the most straightforward is to pick one of the other routes > -- ask > to become a co-maintainer of an existing package, or find something > new > you're interested in. Or, go through a number of code reviews for > similar > packages and get to know the folks who are working on those, at which > point > it should be easy to ask them personally to sponsor you. > I guess that is along the lines of what I was saying above and what others have suggested to me in the past on this topic. > I know this feels like kind of _a lot_, when you just want to help > out by > picking up something that's dropped. But the thing is, once you're in > the > pcakaging group, you have a lot of latitude to make a lot of > technical > decisions. It's not so much a matter of "do we trust you as a person" > as it > is "have you demonstrated that you understand a lot of the nuance and > complication of packaging and working in our environment." > Yeah so I get this without question and understand emphatically even. In what I do (Industrial Automation and Machine building) you can spend years doing the "same thing" differently each time. > If you'd prefer a less-heavy way to just make a package available, we > have > that too, in Copr. There, you can just get started and do it. Been thinking about that very thing for PLC4X maybe. > > > I do think we need to help build a greater pool of people with the > required > skills, time, and ability to mentor new packagers -- sponsorship with > support, not just as a checkbox. We've got some awesome folks who do > that, > but... it _is_ a special skill and _definitely_ time consuming. So > that's an > area I know we need to invest in. I still think a lot of what Mentors and Sponsors could be satisfied the applicant had a particular set of abilities if they had to get through some form of app based intruction and test possibly even broken down into the separate steps of packaging maintenance. With feedback to the newb and validation testing that would give at least a level of confidence to the community too. Let's be honest, we want involvement but all of us want a working Distro more than making it "easier" to get involved. And getting involved is what we're discussing here, whether me or others feeling like. To my way of thinking, it's not that the complexity is a deterent, normally the opposite for most technically oriented people AFAICT. It is really the lack of a map, which itself doesn't need to be a hand held journey, just sign posts. Maybe this is documentation, but I am really reluctant to just chalk it up to that entirely. So we are talking the same I think but from the opposite side of the discussion, and this does seem to be the way everyone feels when this topic comes up. > But... I hope the above helps explain how > things are now in practice. > > Yes, it is clear in some ways as to why it is done the way it is done WRT the packages themselves and the requirements of Fedora Linux, licensing included. What is not clear is how to get from the starting point most of us have. Which is not hired by RH, or not working at a company that specifically uses Fedora Linux as part of their business model. Don't take that wrong either, I entirely appreciate RH et al for their much needed support, as I would imagine the greater community does too. But I also appreciate the efforts of each and every non- business related contributor (ie they don't get paid directly to work on that thing for Fedora Linux), because quite frankly without them there likely wouldn't be a Fedora Linux and we'd just be running RHEL community, so not so delightedly near bleeding edge. In any case I will keep plugging away, maybe just try to get it to build and issue a PR with my solution. But it's currently orphaned with no maintainer AFAIK. Regards, Stephen > -- > Matthew Miller > <mattdm@xxxxxxxxxxxxxxxxx> > Fedora Project Leader > _______________________________________________ > 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
