<snip>
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.
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.
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).
Around 10 tickets a month is the average I believe for infra to deal with / handle from direct pings.
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.
We are.
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.
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
Leigh Griffin
Engineering Manager
Communications House
Cork Road, Waterford City
lgriffin@xxxxxxxxxx
M: +353877545162 IM: lgriffin
_______________________________________________ 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
