On Thu, 30 Jan 2020 at 17:59, Robbie Harwood <rharwood(a)redhat.com> wrote:
Richard Shaw <hobbes1069(a)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?
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
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.