On Thu, 30 Jan 2020 at 17:59, Robbie Harwood <rharwood@redhat.com> wrote:
Richard Shaw <hobbes1069@gmail.com> writes:

> Not replying to anyone in particular but to the thead as a whole...
> 1. Nothing in the packager introduction process prepares a packager
> for what to do when they get a CVE filed against one of their
> packages. I found the whole ordeal rather stressful.

Agreed, this would be good to spell out.

> 4. I'm not a C/C++ programmer

Maybe I'm missing something, but why is being a C/C++ programmer
relevant to fixing security bugs?  Are you packaging programs in a
language you don't speak?

https://docs.fedoraproject.org/en-US/fesco/Package_maintainer_responsibilities/#_deal_with_reported_bugs_in_a_timely_manner :

    It is recommended that non-coder packagers should find
    co-maintainers who are familiar with the programming language used
    by their package(s)

That rule like many others was written and worked when Fedora was a small band of people where everyone knew each other.  However over time, the mix of people have changed and the ability to find a co-maintainer who has the the time and energy to help out is rare. 

There is also what does a 'non-coder' mean. I took some C/C++ but does that make a 'non-coder'? To some developers it does because I don't code in it every day. For others I am C coder because I can fake my way through a couple of programs in an hour. I supposedly maintain nagios which is mainly PHP, Perl, Python and C.. but I would not consider myself a 'coder' in any of them. I have to 're-teach' myself it every time I deal with bugs. I took it because it was going to get orphaned and I need it to get my job done.. should I have not been allowed to take it? Who would test me to see that I can? 

In practice there are about 200 active maintainers in Fedora with around 21,000 packages in them. There are probably 800 'weekend-packagers' who come in once a month and another 1000 who show up once a year. A lot of packages are maintained by people who have little coding clue about the package themselves and do not have any active co-maintainers to go ask questions on. Instead they needed this package to be in the OS so that they could do something else. Fixing a bug is going to be 'download latest, fedpkg yolo' versus 'review bug, review upstream fixes, backport fix to match old code, test fix, repeat, put through test program, fedpkg commit -c ; fedpkg push; fedpkg build;  fedpkg update'. The more packages you have, the less time you have, the more that is going to be the case.

Stephen J Smoogen.