When the policy is not being followed and/or not enforced it means nothing. Only someone who is in love with the policy would say otherwise and actively defend it. I am going to guess you helped write large parts of the policy and that is why you defined it. Yes, lets enforce the policy against the everyone until you have no community. Since there are packages going unmaintained it not like they are that easily replaceable. It is you as a "insider" that seems to be denying the "perfect" policy is not functioning as often as you like and not admitting that it can be made to work with the staff you had. If the maintainer for the kernel package is not following it, I doubt many are following it. And while you are calling me an outsider, I have been using what became fedora for years before the first fedora version was released, and have been using it almost every version since then. On the fedora side we should probably be directing anyone with software bugs to upstream. I am going to guess that the guidelines were copied from the enterprise side where they are maintaining packages that are years behind upstream, were as fedora would rarely be in that position, and it would be best to direct them to upstream. And then create a BZ to backport a patch and/or uplift to the new version. Getting the package maintainer in the middle seems to only add either failure or at best friction to the process. Setting the standards too high removes viable resources of people that may have just retired from a job and don't want a job with hard defined guidelines. Don't get me started about generally negative value automated response from the PAID distribution vendors, they seem to be an extension of the generally worthless process were the exact same information is asked to be collected for each bug for it to progress to the next level, even if that information is not pertinent to the given bug. The automation does not solve the problem, it only pisses everyone off more with its negative value added messages, and arbitrary requirements that may have no useful reason to be done for the bug in question. The distribution vendors love sosreport for anything even for clear bugs that an sosreport is useless. On Sun, May 31, 2020 at 3:14 AM Michael Schwendt <mschwendt@xxxxxxxxx> wrote: > > On Sat, 30 May 2020 16:42:10 -0500, Roger Heflin wrote: > > > The policy means nothing when > > Only an "outsider" would say that. That policy has been refined multiple > times since the fedora.us era with its strict QA policies. That policy is > also reason why potential "maintainers" shy away from the community > project, because as volunteers they can't tell whether they would be able > to meet the requirements. I could point you at the related "non-responsive > maintainer policy", but so far you aren't listening. > > > the staffing is not there to actually do the tasks. > > Sweet how you try to dance around the problem. Where bugzilla components > are literally flooded with tickets, automation would be the way to go. > That has been pointed out before. Meaningful, early responses that give > bug reporters some guidance on where and how they could escalate an issue, > where they could discuss an issue in order to gather more details and to > confirm a problem, and and and. > > > And clearly there is limited staffing. And if they are a volenteer > > then tell them they arent doing their job and kick them out. Repeat until > > there is no community and you have no staff. > > Key components are still maintained by Red Hat. That is an essential and > important contribution to this project. Offer a distribution that doesn't > satisfy users, and you lose (or reduce) the user part of the community > including most of the guinea pigs. > _______________________________________________ > users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to users-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/users@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-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/users@xxxxxxxxxxxxxxxxxxxxxxx
