On Mon, Apr 6, 2020 at 2:36 PM Dominik 'Rathann' Mierzejewski < domi...@greysector.net> wrote:
> On Monday, 06 April 2020 at 12:29, Leigh Griffin wrote: > [...] > > > Yes, this whole "decision" is in dictatorship relation to the > > > community. > > > > > > Not following the standard procedures caused that I and probably > > > many people in the community didn't pay much attention to it. > > > > We followed the procedures that were outlined to us. > > So you think "just following procedures" makes it all right and gives > you mandate to continuing to pursue a decision that the community is > telling you was wrong despite your following procedures? > Our stakeholder and engagement point as a team is Fedora Council. If you have issues with how this was handled from a relationship perspective then please take that up with the Council. We have engaged with fesco in the past at the request of Council and will engage with them in the future in a similar manner. > > > > I thought you are simply going to collect requirements and then we > > > will talk. Collecting the requirements was actually very useful. > > > Providing the analysis for the requirements would be useful. > > > Providing a recommendation would be ok. Providing a "decision" like > > > that crosses the line. > > > > > > It sends quite a bad message that no matter what you start doing for > > > the community and how useful it becomes, RH management can come at > > > any time and make your work vanish, which is what is happening here > > > with pagure on dist-git effort and probably also zuul efforts might > > > get replaced by Gitlab CI. > > > > We have nothing to do with zuul and Gitlab CI may be made available as > > a service if folks want to use it. > > It's not just about CI. You only commented about the least significant > point of the above paragraph and ignored the rest. That seems to be the > pattern with your communication. Please change that. > What point would you like me to comment on? Red Hat is not making work vanish, we are not deleting Pagure from the internet. > > [...] > > > But still, please, listen to what the community is telling you. > > > > We are. > > That's not the impression you are giving here. > > > > While you may have means to force your decision as RH management > > > representative, doing so can be damaging for both sides (RH and > > > Fedora). > > > > We are not forcing a decision. We are still engaged with the Fedora > > Council on next steps and factoring in the requirements of the > > community. Right now, our wider needs are saying we cannot support > > Pagure and we intend on replacing that with Gitlab from a CPE > > perspective. > > You are forcing a decision because you're refusing to revisit the > decision you have made *for* the community without the engagement that > the community feels was required. This decision is made for 2x communities, 1x internal stakeholder and the CPE team. This decision is impacting 4 groups. If you feel so strongly that the decision should be revisited in some way shape or form, make your protests known to the Fedora Council. We engage at that level. > If you had stopped at the first > objections and revisited the decision making process with the rest of > the community involved in an open manner, you would have been forgiven, > because everyone here is trying to assume good faith. Alas, you haven't > done that. Apologizing for your mistakes is a necessary step, but it's > not sufficient. > Ok let's scenario this out so as several people want us to restart and go again, largely because they disagree with the decision and Pagure is the choice that they would have made. If we re-engage now, I firmly believe we will get a whole new set of requirements to complement the existing requirements but scoped deliberately (as has been suggested by numerous replies) to a situation where Pagure is the only choice for Fedora. How do we accommodate that when our other stakeholders' needs are now not being met as a whole and when the original requirements needs are being satisfied by the choice of Gitlab (which will most likely be CE for Fedora). What happens then, how do you suggest we proceed at that point? The other stakeholder groups are already progressing with Gitlab and we can do that for them and pause the Fedora move in this direction if that was the scenario. What happens after months of debate if we cannot bridge that divide? What happens when Pagure is sunset as the CPE team cannot run it / maintain it? I'm genuinely curious here as if this is a path the community want to go down then engage with Council on it but I think it could be harmful for the project as a whole. That's not my choice though and until otherwise told, we are progressing in this direction. > > Regards, > Dominik > -- > Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org > There should be a science of discontent. People need hard times and > oppression to develop psychic muscles. > -- from "Collected Sayings of Muad'Dib" by the Princess Irulan > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@redhat.com M: +353877545162 IM: lgriffin @redhatjobs <https://twitter.com/redhatjobs> redhatjobs <https://www.facebook.com/redhatjobs> @redhatjobs <https://instagram.com/redhatjobs> <https://red.ht/sig>
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
