On Wed, Apr 1, 2020 at 11:33 AM Fabio Valentini <decathorpe@xxxxxxxxx> wrote:
On Wed, Apr 1, 2020 at 12:24 PM Leigh Griffin <lgriffin@xxxxxxxxxx> wrote:
>
>
>
> On Tue, Mar 31, 2020 at 7:44 PM Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote:
>>
>> On Tue, Mar 31, 2020 at 11:45 AM Adam Williamson
>> <adamwill@xxxxxxxxxxxxxxxxx> 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@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
>
> Red Hat Waterford
>
> Communications House
>
> Cork Road, Waterford City
>
> lgriffin@xxxxxxxxxx
> M: +353877545162 IM: lgriffin
>
> @redhatjobs redhatjobs @redhatjobs
> _______________________________________________
> 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
