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?

> 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@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel