On Tue, Apr 14, 2015 at 10:51 PM, Jim Perrin <jperrin at centos.org> wrote: > > > On 04/14/2015 03:17 PM, Marcin Dulak wrote: > > Hi, > > > > i would like to add some more to the discussion started at > > http://lists.centos.org/pipermail/centos-devel/2015-April/013163.html > > > > 1. > > On the plot attached to http://bugs.centos.org/view.php?id=8447 > > one can see that since the CentOS 7 release the number of unresolved > > issues on bugs.centos.org has increased, > > and the number is currently more than 50 unresolved issues per month. > > Many issues do not obtain any attention (nothing in the notes). > > This continues for several months, and is an unprecedented situation. > > How is it unprecedented? > it looks unprecedented to me on the plot. There has never been a time on bugs.centos.org with that many bugs left open per month for such a long period of time. Best regards, Marcin > > > For me it shows that the CentOS community has not enough resources to > > deal with the reported issues. > > You're right. We could absolutely use more community members willing to > step up and help triage/fix/duplicate the bugs. > > > From this point of view it would be better to have CentOS issues > > integrated into RHEL's bugzilla, > > Unsure what you mean here. Putting our bugs in bugzilla would simply > mean we move from not responding to them on bugs.centos to not > responding to them in bugzilla. We don't get any additional resources > simply by using bugzilla. > > > > > > > > 2. > > A single example I would like to bring up is the fate of > > http://bugs.centos.org/view.php?id=8249 > > The reporter made a substantial effort to collect usability issues > > encountered during an installation of CentOS, > > got asked to report the issues at bugzilla what he did, and there this > > got (politely) closed > https://bugzilla.redhat.com/show_bug.cgi?id=1197377 > > This seems to be his only bug at bugzilla.redhat.com. > > > > Maybe if CentOS was at bugzilla then CentOS developers could focus more > > on the "open-source" way of dealing with people's reports, > > which will counteract a bit Red Hat's enforcement of compliance with > > it's strategies. > > Elaborate here please? The core system does not change. That's been a > distro fundamental from the beginning. If RH closes a bug, we inherit > their change (or lack thereof). SIGs are the way for groups of > interested people to work together and make those changes themselves. > > > > > 3. > > One more point, and it has to do with the way Fedora/EPEL package > > updates are handled. > > When I update an RPM package fixing a bug for Fedora/EPEL the update > > almost never gets any reviews. > > This is a Fedora/EPEL issue, and is something we as a distro don't have > any control over. We've had discussions a few times with the Fedora/EPEL > folks about this but there is no simple answer or immediate fix. > > > The update is sitting for some fixed amount of time (2 weeks for EPEL) > > and after that I push it to stable (still without any review). > > I'll bring the famous case here what the result of such releases could > > potentially be: > > https://bugzilla.redhat.com/show_bug.cgi?id=1054350 (actually I don't > > know if the offending release was reviewed or not). > > Or another case which affected me: > > https://bugzilla.redhat.com/show_bug.cgi?id=1063493 > > Red Hat changed major version of software (mpich2 -> mpich3) which > > resulted in a couple months of empty running reviews > > (2 weeks each) at EPEL in order to fix all dependencies. > > So step in. Contribute feedback, jump on the EPEL-devel mailing list and > request feedback for packages. Join the relevant irc channels and > request/give feedback. > > > I'm not familiar with the role CentOS could have in the process of > > preparation of new RHEL updates, > > Effectively 0. We see the updates when they land in git, the same as > everyone else. > > > but if there is anything that could be done to improve the RPM package > > update process, > > it should be considered as an important factor in case of merging CentOS > > issues to bugzilla. > > RHEL and EPEL are quite separate, so I don't really follow what you mean > here. > > In my eyes, there are two benefits from using rh's bugzilla vs our own > tracker. > > 1. It's one less thing to manage. > 2. Bugs that have upstream relevance could (in theory) be more easily > tagged/cloned without asking the user to duplicate as we currently do. > This is still a hypothetical, as we've not talked with the bugzilla > folks yet to see how any of this would work, or what would be possible. > > > > -- > Jim Perrin > The CentOS Project | http://www.centos.org > twitter: @BitIntegrity | GPG Key: FA09AD77 > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20150415/3a6780c4/attachment-0008.html>