On Thu, 12 Jul 2018, Miro Hrončok wrote: > > > The guidelines currently say: Are these Holy Writ, or just process, subject to amendment? > > > I think this guideline is bad and counterproductive, since many > > > packages clearly ignore it. There is a principle: Seek first to understand before ** suggesting ** what one feels are helpful suggestions It applies here > > > So what do we do? Take the package away from > > > (most likely) upstream developers? oh -- So forking, or adding (probably) unwanted co-maintainers, or continuing to fight that entropy with what are functionally an unknown number of 'provenpackagers' co-maintainers, pushing unwanted 'fixes' in, is proposed? and a peeve: NOT updating the changelog when literally thousands of packages are re-factored? I know I always love getting to play detective, when an encountered version does not match a prior SRPM of the same NEVR > > > Tell them no no no very sternly so > > > they can ignore us? If being ignored bothers you, perhaps the problem is not them, but your reaction at being ignored Perhaps offer of the carrot rather than use of the stick is in order. Maybe, just asking questions, and coming up with a rubric to annotate within a non-parsed field in a .spec file where 'upstream' is (as was suggested -- as was done with the various side adjunct repos -- dag, RF, more, to accommodate their tooling) > > projects. So we do have leverage. great -- using force always makes new friends ... NOT What happened to the Four Fedora F's ? > always a Red Hat maintained software, where people were > basically telling us: "no, we won't accept your PR here, we > maintain the specfile somewhere else". 'Always'? A fork of 'Spacewalk' just left because of the non-public approach to road-map by Red Hat insiders, and simply ignoring or not taking non @redhat commits. I spoke with Don Vosburg of SUSE at a conference about his frustration with having to do so just a week or two ago. He _wished_ the fork was not required, but to maintain the their implementation, which is productized as 'SUSE Manager', he had to get that fixes in See again, seeking to understand first before suggesting prescriptions to the person ** volunteering ** to do work which happens also to benefit the Fedoraproject The project is a social voluntary organization -- driving volunteers AWAY is trivially easy. I took heat in the CentOS project for working to keep the Signal to Noise ratio high, at the expense of intentionally (and by a rubric documented in the CentOS wiki) removing people unwilling to play by that set of rules. I'd do it the same way again tomorrow. But I knew I was not being welcoming to all, as not all were welcome, frankly. Immediate kick-bans of people using profanity, racist content, etc, seem to be a win to me > It was very unpleasant experience and usually such maintainers expects us to: Again, the location of the hurt feelings is not with the remote maintainer. Examining ** why ** you feel that way is in order. Perhaps an out of band discussion with the recalcitrant offender is in order ;) Looking at my sent folder, I see that I send 20 to 30 'off list' emails a month, to get at the reasoning of another behind things I do not understand I find that it is very unpleasant to encounter a auto-closed bug, doing research as to an error, and knowing full well that this close is saying: This bug (and the current item I am researching) is known, but we did not fix it, so we swept it under the rug. Perhaps it will fix itself At that point, I can solve my unhappiness by: committing a local fix, and NOT upstreaming it - or - committing a local fix, and upstreaming it Obviously one path is better than the other for 'improving the breed' -- but if I have been filing ignored bugs, which simply get auto-closed, it is easier to do less work > Some maintainers were kinder than others, taking the changes and applying them > in their god-knows-where maintained spec files. Some where not. And, frankly, that is their choice to make, rather than yours, unless you are proposing to excommunicate people from Fedoraproject > We don't need to make the rule less strict, we need to find a way to enforce > it. The current state (people ignoring this rule) makes contributing to Fedora > even harder than it already is. "The beatings will continue until morale improves" kindly, -- Russ herrold _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/QMHUKQNSCP65XNYWJOJREXQDDAQIKSEM/
