On Wed, Apr 1, 2020 at 11:33 AM Fabio Valentini <decatho...@gmail.com> wrote:
> On Wed, Apr 1, 2020 at 12:24 PM Leigh Griffin <lgrif...@redhat.com> wrote: > > > > > > > > On Tue, Mar 31, 2020 at 7:44 PM Chris Murphy <li...@colorremedies.com> > wrote: > >> > >> On Tue, Mar 31, 2020 at 11:45 AM Adam Williamson > >> <adamw...@fedoraproject.org> wrote: > >> > > >> > On Tue, 2020-03-31 at 13:08 -0400, Matthew Miller wrote: > >> > > On Tue, Mar 31, 2020 at 10:48:55AM -0500, Michael Catanzaro wrote: > >> > > > Some failure of process or communication must have occurred > >> > > > somewhere along the lines, because open source should have been > the > >> > > > first and most important requirement. A proprietary software > >> > > > solution is incompatible with the ethos and purpose of the Fedora > >> > > > project. I ask CPE to revise its requirements list to include open > >> > > > source as the first and most important requirement from the Fedora > >> > > > community. If that's incompatible with CentOS's need for merge > >> > > > request approvals or whatever else, then we need to accept that > >> > > > sharing the same forge is simply not going to work. > >> > > > >> > > Obviously open source is one of our key foundations. And it is part > of who > >> > > we are even before those foundations were drafted. Nonetheless, I > want to > >> > > gently discuss this a little bit. We make an entirely open source > and free > >> > > software operating system. We support and promote and advocate for > open > >> > > source and free content. But we can't do everything, and at some > point, this > >> > > becomes "this is why we can't have nice things". I see that you've > made > >> > > contributions to other open source projects on GitHub and (hosted) > GitLab > >> > > this month. Lots of Fedora contributors have and will continue to > do so. > >> > > Many use that as their main hosting. It's not ideal, but it's not > the end of > >> > > the world. I don't see Fedora making use of non-open hosted > services as the > >> > > end of the world either, if that is what is best for us. > >> > > > >> > > We did communicate as the very top line of our gathered > requirements that > >> > > open source is essential to our community and central to our > feedback. I'm > >> > > not trying to be soft on that. Let's just not do purity-test level > >> > > assessments and instead focus on our goals. > >> > > >> > I'm sorry, but I have to agree with Kevin and Michael here to a > >> > significant extent. Running our own project on open source code has > >> > always been a very big bright line for Fedora. > >> > > >> > I'm not necessarily saying it's a hill we should die on, but at the > >> > very least, choosing a proprietary hosted solution for something as > >> > fundamental as our dist-git needs to be treated as a Very Big Deal and > >> > needs to be a decision that is handled a *lot* better than this one > has > >> > been handled. > >> > > >> > You said in another email that the tooling choice ultimately has to be > >> > largely made by the team that is responsible for the work and it > >> > wouldn't really work for Council to order them to do something they > >> > can't practically do, and I see the truth in that, but at the same > time > >> > I think there has to be a balance there. Does this "the team decides > >> > what works for them" principle extend as far as the team being able to > >> > choose unilaterally to go against principles Fedora has been working > >> > very hard to maintain for about as long as it has existed, and that > are > >> > listed right up there front and centre as our Foundations? That, to > me, > >> > seems like a decision that Council ought at the very least to be > deeply > >> > involved in - much more than seems to have been the case here (which > >> > seems to have been that we wrote up some requirements and sent them > off > >> > to "the team", which smooshed them into some kind of summary and then > >> > made a decision - a decision which seems to have had a rather confused > >> > context, as various people don't seem to be on the same page about > >> > whether a choice was supposed to be made about "dist-git", or > >> > "pagure.io", or "Pagure", or CentOS's or Red Hat's use of Pagure, or > >> > any or all of these things somehow smooshed together). > >> > > >> > I think if I turned up tomorrow and said that QA had decided we're > >> > going to use a proprietary hosted service for managing release > >> > validation testing there would be significant pushback against that, > >> > and I think that pushback would be valid, and I'm not sure it would be > >> > appropriate for us to say "tough, we made that decision so that's > >> > what's happening". I don't think it's necessarily appropriate for that > >> > to happen here either. > >> > > >> > I understand there are practical resource considerations and so on > >> > here, but I still think this merits more high level and serious > >> > consideration. At the very least, if we have somehow reached a point > >> > where Red Hat is no longer willing to provide sufficient resources to > >> > run Fedora on the lines the Fedora community wants it to be run, we > >> > need to recognize that this is a significant problem that needs to be > >> > properly aired and discussed and resolved. In this context I'll note > >> > that the apparent significant headcount reduction of RH people working > >> > on Fedora infrastructure over the last few years is in itself a > >> > worrying trend, particularly if you consider it while reading > Clement's > >> > email. > >> > > >> > I think Iñaki's take on the "oh, you contribute to Github projects so > >> > no problem right?" angle is correct. > >> > >> I concur with this, in its entirety. > >> > >> Lack of resources might supercede an open source requirement. But if > >> that is really the choice, that itself exposes a far bigger problem: > >> all other projects being maintained by CPE and Fedora Infrastructure > >> team are at risk. > > > > > > There is no doubt that they are at risk. We cannot sustain the level of > commitment to the volume of projects we have. The lights on work for just > the Fedora side is consuming over 50% of our team. That's pure > firefighting, responding to tickets and fixing problems with very little > time to pay down some of the debt that is causing the problems in the first > place. The team is spread too thin on just the Fedora commitments before we > consider the fact the team has another distribution in CentOS under our > remit as well. The reality is that most applications are constantly under > risk, if a person goes on PTO or leaves the team / company, we lose domain > knowledge. This has happened in the past year and will happen in the > future. Part of how we are structuring our work is to reduce our overhead, > cross train the team, get smarter on what we invest our time and effort > into in order to provide real value, not fighting fires constantly. That > might sound alarmist, but it's the reality that the team are living day to > day. > > > Would it be possible to publish the list of applications that the CPE > maintains / runs? > We are working on an updated list of those applications and should have it with the community over the coming 2 weeks. > I think having that information might lead to a better conversation > around what services can be replaced and/or shut down. Right now, I > don't have the foggiest idea what 75% of those applications you run > actually are, which makes this discussion a bit hard. > > Fabio > > > > > > >> > >> Why can't half or even all of them be rolled up into > >> proprietary equivalents and handed off for some other company to > >> manage? What's next? > >> > >> This is awkward, but not even 12 days ago the Council approved a new > >> vision statement: > >> > >> The Fedora Project envisions a world where everyone benefits from free > >> and open source software built by inclusive, welcoming, and > >> open-minded communities. > >> > >> I can't say for sure there is a conflict in the process used to arrive > >> at the decision, but I'm questioning whether there is incongruity, and > >> the nature of it. > >> > >> -- > >> Chris Murphy > >> _______________________________________________ > >> 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 > > > > Communications House > > > > Cork Road, Waterford City > > > > lgrif...@redhat.com > > M: +353877545162 IM: lgriffin > > > > @redhatjobs redhatjobs @redhatjobs > > _______________________________________________ > > 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 > _______________________________________________ > 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
