Re: List of long term FTBFS packages to be retired in February

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

 



On 06. 01. 20 22:57, Peter Jones wrote:
On Mon, Jan 06, 2020 at 12:54:58PM +0100, Miro Hrončok wrote:

Regardless of different opinions about aggressiveness, having policies
and no enforcement makes no sense. Either the polices are too
aggressive and we need to change them, or they are not and we need to
enforce them.

That seems like a rather poor way to think about policy in general, and
I have some disagreements with it in this specific case as well.  In
general, you're not considering that it may be worth having policies
reflect our *ideal* situation, and acknowledge that they don't always
fit the real world precisely.

I'd rather have our polices fit the reality we want and agree on, rather than have polices that we know are contradicting it. In this particular case, you have presented arguments elsewhere in this thread for why those packages should be exempted from it. I will not go into detail whether those argument are or are not good enough (not here), but I think that this is a way to go - if we don't want a package to be part of the process, we should document why and exclude it. That way we can avoid unnecessary notifications, dead bugzillas and well... this discussion.

What you seem to prefer is that we simply do consider the enforcement on case by case basis every time this happens, which is almost impossible. (Sorry if that is not what you actually would prefer.)

I think that's a thing we need to consider, because both the mass
rebuild policy, and the crusade you're on to use it to drive your use of
the FTBFS policy.  In both cases the intent of the policy is clearly
good, but the way you're trying to handle enforcement has aggravated
quite a few people - I think I've witnessed at least 3 people tell you
this in general, and two of us have (more than once) about this specific
case.

As always, I invite those people (and specially you two) to discuss the necessary changes in the policy itself. Should there be specific changes in the policy? Do tell.

What you seem to ask is to stop enforcing policies, and I must
disagree with that.

I don't think this is in any way a reasonable conclusion *or* a
reasonable response.  Nobody said "we should never enforce any
policies", or even anything you might reasonably confuse for that.

There aren't very many things that are good "one size fits all" policies
with something as complex as a linux distro, and those are mostly very,
very core things, like "the stuff in your package has got to be open
source".  Most things, we can only make the policy fit everything so
well, and try to make it fit better when we can, and enforce it to the
appropriate extent.

The enforcing part is part of the policy itself. What is the appropriate extent here? We have recently made it so that it is possible to keep a package that fails to build for a reasonable time. Now we are only enforcing it after several releases. Is it too little time? Should it be more releases instead? Or forever?

But instead, you're talking about policy enforcement as if we should
send people to jail if they accidentally drop a candy wrapper when
they're putting it in their pocket to throw away later.

We are not sending anybody to jail. We are simply saying: Fedora package maintainers have responsibilities:

https://docs.fedoraproject.org/en-US/fesco/Package_maintainer_responsibilities/

And if you don't take those responsibilities, something happens and possibly somebody else will. In my experience, in many cases it is the enforcing that drives fixes. Packages get adopted by people who have the time to maintain them, "dead" packages get removed, broken dependencies get fixed.

Note that IMHO it's mostly Red Hat employees that are "forced" to fix their
packages by enforcing the polcies, not community members. The community
packagers either care about their packages and they fix them in timely
manner, or they are already gone. But I have no data to back this up, so
feel free to disagree there.

The insinuation that Red Hat employees, including me, don't care about
what we're working on is pretty seriously insulting.

I do sincerely apologize if I have insulted you or any other Red hat employee. All I presented is my personal experience. Probably too generalized, and I am sorry for that. There are excellent Red Hat employees Fedora packagers who care deeply and are standing by the responsibilities linked above and it is a pleasure to work with them.

Also said in the e-mail, if you think those packages need to be
exempted from the process, we can deal with that to, however there
must be a valid reason. I don't think "the maintainer didn't
actually maintain their Fedora packages for almost 2 years because
they have real stuff to do" is a valid reason, yet other FESCo
members might disagree with that statement.

Well the FTB from people pushing builds would be directly due to the
fact they're not on the ACL for the secure-boot, there is a handful
of packages like that.

So the people who has the rights should start actually doing it,
shouldn't they.

Again with the insulting insinuations.  Have you at all considered that
*not* rebuilding a package might be the correct action?  Have you
considered that when I say not to include shim-unsigned-aarch64,
shim-unsigned-x64, and shim in the mass rebuilds, since that will not
and *can not* ever produce the desired result, and in fact can *only*
result in more work that's *completely pointless*, I'm actually not just
being hopelessly lazy?

I have seriously considered that not rebuilding those packages might be the correct action. That is why my e-mail includes a section that says:

"If you see a package that should be exempted from the process, please let me know and we can work together to get a FESCo approval for that."

I have never said you are lazy. I have only said you are not responding to the reports whether it is trough bugzilla or e-mail here on devel. This is in fact the first time I have heard back from you, despite contacting you several times in the past half year throu several channels.

This particular maintainer ignores all bugzilla e-mail.

You appear to believe bugzilla is a good way to have any conversation
with any maintainer.  It isn't.  It's an archive for reporting bugs, and
treating it as a notification queue won't ever be a good interaction for
everyone.

I do believe that, yes. And so did the authors of "Package maintainer responsibilities" page and the authors of the FTBFS policy. OTOH that doesn't make it is correct and that is will always be correct.

If bugzilla shall not be the way to have conversations with the maintainers, lets have a discussion about a better way? And if we do have a better way, we can adapt the policy.

But having a policy that says "do this over bugzilla" and not doing it over bugzilla seems rather weird to me.

 From my perspective, you are abusing bugzilla in an overzealous attempt
to enforce a policy that you hold as absolute, but which does not fit
the situation at hand well *at all*, and mostly just generates extra
work *on top of* the noise the mass rebuild generated, and you're
insulting people when they tell you that.  Please stop.

From my perspective, I am simply executing a policy that was discussed with the Fedora Engineering community and approved by the elected representatives of it.
I am not abusing anything.

I am not intentionally insulting people. I will try to do my best to stop doing it unintentionally. In fact, when you call me an abuser, it might insult me, but I know e-mails like this should always be read with best intentions assumed, so I assume that is not what you had in mind. Please do me a favor and assume the same for me.

Well FESCo might agree that they want booting x86 images with
secure-boot so ¯\_(ツ)_/¯

Sure, let's build our policies around that. What about the following:

"If you maintain a critpath package, you don't need to to do anything,
because it will never be removed so ¯\_(ツ)_/¯"

I realize Peter was sarcastic in his response to you, but replying with
*ridicule* when others disagree with you is not respectful or considerate,
which are the two main requirements of Fedora's code of conduct.

Indeed, sorry for my disrespectful answer to a sarcastic note. I should stick to the facts next time.

If you want to talk even more about the actual details of what the plan
going forward for these two packages (really three, but whatever) is,
and try to understand why I want you to stop, we can.  You don't seem to
want to, though.

I do. Please, if those three packages (or any other packages) should be exempted from the policy, do open a new thread about it, where we can discuss it and hopefully gain a conclusion that would make things better for everybody involved. My intention is not to destroy things, but to make them better.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux