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