On Tue, Jan 28, 2020 at 04:10:17PM -0500, Robbie Harwood wrote: > Stephen John Smoogen <smooge@xxxxxxxxx> writes: > > > On Tue, 28 Jan 2020 at 13:01, Robbie Harwood <rharwood@xxxxxxxxxx> wrote: > >> > >> "Richard W.M. Jones" <rjones@xxxxxxxxxx> writes: > >> > >> > I always think that Fedora works fine if you maintain 1-5 packages. > >> > It's possible to maintain 20 with a lot of work. And if you want to > >> > maintain 100+ (things like the ocaml-* set that I help to maintain) > >> > then you have to write your own automation. Could we do things > >> > better? No one asked for them, but here are my ideas ... > >> > > >> > --- > >> > > >> > * CVE bugs should autoclose when a package is rebased > >> > > >> > Fabiano built the mingw-openssl package recently, but there are still > >> > a load of open CVE bugs against this package referring to the older > >> > version. These should be closed automatically. I think this will > >> > require collecting the version of the package that fixes a CVE and > >> > recording that in Bugzilla (or in the package itself in some standard > >> > way). > >> > >> This is an interesting idea, and I appreciate you're considering ways to > >> resolve this problem. However, I'm concerned that this will lead to > >> maintainers not actually checking whether a version fixes an issue - > >> since we don't have automatic verification (or even usually manual > >> verification) of security fixes, that wouldn't get caught. > >> > > > > You are assuming that maintainers actually check to see if a version > > fixes an issue already. If a packager has 100's or 1000's of > > packages.. there is no way they will have done so except on a 1 in a > > million case set. I think if are going to aim that a packager can > > 'maintain' hundreds or thousands of packages that we also assume that > > this security is not going to be checked by the maintainer. If it > > needs to be checked it will need to be 'outsourced' to some group who > > can do so. > > Per Package Maintainer Responsibilities [1], maintainers are expected to > "deal with reported bugs in a timely manner" and reach out if they > cannot handle the load. I think it's reasonable to expect maintainers > to be close to compliance with the policy they agreed to when becoming > maintainers :) > > Personally, I think if you have enough packages that you cannot actually > triage your own bugtracker, you have too many packages. I don't think > it's at all reasonable for one person to be responsible for "100's or > 1000s of packages", and I think not knowing whether security issues are > or are not fixed in a given version of them is a perfect illustration of > why that doesn't work. > > What I would like us to do is move away from needing to do that. > Whether that involves more SIG-like maintainer groups, or a different > format, I don't know; but one thing we do need is more monitoring of the > security issues than we have right now. I fundamentally disagree. These things are entirely possible if there is more automation, and I've shown how I think it could be done. AND we need to do this too, increasing packager productivity is the number 1 issue with Fedora packaging and has knock-on benefits everywhere. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW _______________________________________________ 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
