On Sat, 4 Apr 2020 at 14:04, Neal Gompa <ngompa13@xxxxxxxxx> wrote: > > On Fri, Apr 3, 2020 at 9:42 PM Randy Barlow > <bowlofeggs@xxxxxxxxxxxxxxxxx> wrote: > > > > On 4/3/20 4:41 PM, Leigh Griffin wrote: > > > We didn't quash communication for reasons already mentioned. We didn't > > > facilitate it is a more accurate assessment, for which we have > > > acknowledged and apologized. > > > > You certainly didn't engage with the community. Fedora has a change > > process, and every other significant change goes through it. Sure, not > > everyone is happy with the results of every decision, but there is at > > least open discussion. That open discussion often influences the > > decision. You didn't do that here, and the only communication of the > > decision was buried in an e-mail that many people don't read. That > > communication was also a decision, not an invitation for discussion. > > There is no process now for discussion to influence the decision, a > > cornerstone of open development. > > > > This is not open. > > I'd like to point out *every other major infrastructure change* has > gone through the change process, debated publicly, and approved by > FESCo before implementing: > > * Merged Core and Extras in our CVS: > https://fedoraproject.org/wiki/Releases/FeatureMergeSCM > * Deployment of Koji: > https://fedoraproject.org/wiki/Releases/FeatureNewBuildSystem > * Deployment of Bodhi: > https://fedoraproject.org/wiki/Releases/FeatureUpdateSystem > * Deployment of Dist-Git: https://fedoraproject.org/wiki/Dist_Git_Proposal > * Koji signed repos: https://fedoraproject.org/wiki/Changes/KojiSignedRepos > * Deployment of Pagure: > https://fedoraproject.org/wiki/Changes/ArbitraryBranching > * Deployment of MBS: https://fedoraproject.org/wiki/Changes/ModuleBuildService > * Added Modular Compose: https://fedoraproject.org/wiki/Changes/ModularCompose > * Added Zchunk repodata: https://fedoraproject.org/wiki/Changes/Zchunk_Metadata > * Gated Rawhide: https://fedoraproject.org/wiki/Changes/GatingRawhidePackages > * Dropped i686 content: > https://fedoraproject.org/wiki/Changes/Noi686Repositories > * Fedora active user metrics: > https://fedoraproject.org/wiki/Changes/DNF_Better_Counting > * Using Taiga for the Change proposals: > https://fedoraproject.org/wiki/Changes/fedora-change-wrangler > * Enabling modules in the regular buildroot: > https://fedoraproject.org/wiki/Changes/Modules_In_Non-Modular_Buildroot > > If we were to consider this as the requisite community discussion and > the decision as a "proposal", then the resounding negative feedback > would be sufficient to *not* do this without going back to the drawing > board and improving the proposal. > > But of course, that's not what is happening. And that's a problem in > itself. We accepted the deviation in procedure for Fedora > infrastructure changes for *this* change because there was a described > process that was considered functionally equivalent. But then *that* > process was not followed. You've effectively shattered the trust with > the community that you attempted to create with this. 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. 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. Additionally, I think that disruption you will cause will take so much time that it would several-times cover the time needed for implementation of all of the features people want to see in pagure. I also don't see people on IRC complaining that pagure.io or src.fp.o doesn't work so maintenance-wise it doesn't seem to be causing problems (there might be some but I didn't notice). In other words, the change you are suggesting won't be imho good for Fedora. What would be good is to continue doing incremental well-thought changes and not give up on our products. That might result in them coming on top at one point. I consider this whole situation my mistake. For quite some time I wanted to bring improvements to the packaging area to show that we can have top-notch stuff ourselves but it got seriously delayed by me not being always on top of my game. I still want to finish this (https://github.com/rpm-software-management/mock/pull/526) but I regret I didn't go for it earlier. But still, please, listen to what the community is telling you. While you may have means to force your decision as RH management representative, doing so can be damaging for both sides (RH and Fedora). Slower but more careful progress is OK. clime > > -- > 真実はいつも一つ！/ Always, there's only one truth! > _______________________________________________ > 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 _______________________________________________ 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
