Re: Fedora 30 EOL

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux