council April 2020

council-discuss@lists.fedoraproject.org

12 participants
11 discussions

Fedora Council Video Meeting: May 2020 - Lenovo
by Ben Cotton 30 Apr '20

30 Apr '20

Hi everyone, As a reminder, our monthly video meeting[1] on 13 May will feature Mark Pearson from Lenovo. I'd like to pre-collection some questions and topics we'd like him to cover. If you have suggestions, please let me know by next Thursday so that I can give him some time to prepare. If you have suggestions for future video meetings, please add them to the wiki page. [1] https://fedoraproject.org/wiki/Council/Video_Meetings -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

1 0

[Fedocal] Reminder meeting : Council meeting
by bcotton＠redhat.com 28 Apr '20

28 Apr '20

Dear all, You are kindly invited to the meeting: Council meeting on 2020-04-29 from 10:00:00 to 11:00:00 America/Indiana/Indianapolis At fedora-meeting-1(a)irc.freenode.net The meeting will be about: The Fedora Council will hold our regular meeting at 10:00am US/Eastern in #fedora-meeting-1 on irc.freenode.net. All are welcome! To convert to your local time, run: date -d 'TZ="US/Eastern" 10am tomorrow' We will begin with a review of open tickets and then have open floor time for discussion. The primary chair for this meeting (usually the FPgM, FPL, or FCAIC) should reply to this message with this week's agenda. More information available at: [https://fedoraproject.org/wiki/Council_Meetings](https://fedoraproject.org/… Source: https://apps.fedoraproject.org/calendar/meeting/9580/

2 1

Fedora election schedule update
by Ben Cotton 23 Apr '20

23 Apr '20

TL;DR: The Fedora 32 Election cycle will be delayed due to an outage of the Elections app. For more information, see my Community Blog post[1]. Because the Elections app will be offline during the Fedora infrastructure move[2], the Election schedule had to be adjusted. This is a one-time adjustment, future election cycles will be on the normal schedule. This affects the Council, FESCo, and Mindshare elections. [1] https://communityblog.fedoraproject.org/fedora-32-election-schedule/ [2] https://hackmd.io/hpYYJQRjQy-oHxUS7IonIA -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

1 1

[Fedocal] Reminder meeting : Council meeting
by bcotton＠redhat.com 14 Apr '20

14 Apr '20

Dear all, You are kindly invited to the meeting: Council meeting on 2020-04-15 from 10:00:00 to 11:00:00 America/Indiana/Indianapolis At fedora-meeting-1(a)irc.freenode.net The meeting will be about: The Fedora Council will hold our regular meeting at 10:00am US/Eastern in #fedora-meeting-1 on irc.freenode.net. All are welcome! To convert to your local time, run: date -d 'TZ="US/Eastern" 10am tomorrow' We will begin with a review of open tickets and then have open floor time for discussion. The primary chair for this meeting (usually the FPgM, FPL, or FCAIC) should reply to this message with this week's agenda. More information available at: [https://fedoraproject.org/wiki/Council_Meetings](https://fedoraproject.org/… Source: https://apps.fedoraproject.org/calendar/meeting/9580/

2 1

A Community Change process to mirror the System Change process
by Ben Cotton 08 Apr '20

08 Apr '20

Ankur opened this ticket[1], but I want to bring the discussion to the mailing list because I think that's a better venue for open discussion. [1] https://pagure.io/Fedora-Council/tickets/issue/291 My initial response: The biggest question I have is "where is the whole community"? There's not a good way to reach everyone (assuming we even have a good definition of what "everyone" means, which I'd argue we don't). I think the bigger problem is people not paying attention to the broader community. I get this; many of us are volunteers and we only have so much time that we can devote. I'm not sure adding process gets us much value here until we have a better way of getting the message out. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

8 22

Fedora Council video meeting tomorrow
by Ben Cotton 07 Apr '20

07 Apr '20

Looks like I forgot to put this on Fedocal, but here's a reminder that the monthly Fedora Council video meeting is tomorrow (Wednesday). It will be held at 10am Eastern (1400 UTC) on Bluejeans: http://bluejeans.com/mattdm/ The guest this month is Peter Robinson, who will talk about Fedora IoT. For future topics and to suggest topics/guests, see the wiki: https://fedoraproject.org/wiki/Council/Video_Meetings -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

1 0

Re: CPE Git Forge Decision
by Adam Williamson 03 Apr '20

03 Apr '20

On Fri, 2020-04-03 at 14:46 -0500, Michael Catanzaro wrote: > On Fri, Apr 3, 2020 at 12:10 pm, Adam Williamson > <adamwill(a)fedoraproject.org> wrote: > > I assume Gitlab likes money. :P > > $100/month per user for Ultimate (the only offering that meets the > "requirements")... 2339 packages in FAS... so $233900 * 12 works out to > roughly $3 million per year just for Fedora, assuming we never let > anybody other than approved Fedora packagers use the instance. Or in > terms of salary: a couple dozen software developers, more or less. > > I wonder if that's really more cost-effective than hiring a couple more > infrastructure devs.... I mean, I'm assuming we will be deploying RH's crack negotiating teams at this :) > > Another is requirement 19 ("As a Project > contributor...I want to be able to use kanban boards...So that my team > can easily schedule and prioritize work in a visible way"). > > Kanban is actually an open source feature: > https://gitlab.gnome.org/GNOME/epiphany/-/boards Hmm. Looking closer at the feature lists: https://about.gitlab.com/pricing/ it looks like maybe *basic* board capabilities are in Core but more advanced stuff - "Multiple Group Issue Boards", "Single level Epics", "Deploy Boards", "Multi-level Epics" - are in Premium and Ultimate? I'm not an expert. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

2 1

Re: CPE Git Forge Decision
by Adam Williamson 03 Apr '20

03 Apr '20

On Fri, 2020-04-03 at 12:07 -0400, Ben Cotton wrote: > On Fri, Apr 3, 2020 at 11:59 AM Leigh Griffin <lgriffin(a)redhat.com> wrote: > > > Can we *please* see the final actual definitely official Fedora list, > > > then? If this is supposed to be an open process? > > @Ben Cotton can oblige here, it's not my place to share it without a stakeholder approval. > > The list sent to CPE is below. While there was no intent to hide it > (it can be reconstructed from the council-discuss thread), it was a > mistake on my part to not explicitly post this at the end of the > discussion. > > As a Fedora contributor, I want the git forge to integrate with FAS so > that it can use FAS to provide authentication and authorization. > > As a Fedora contributor, I want the git forge to integrate with > fedora-messaging so that it can be a part of automatic workflows. > > As a Fedora contributor, I want it to be easy to add new contributors > to a project (and optionally to enable self-adding) so that joining > new teams is low-friction. [snip] Uh...wow. So, Leigh was correct, and the F/OSS and self-hosting requirements are entirely removed from this list. Not adjusted or de-emphasized or given nuance, but simply removed entirely. I highly dispute the idea that the removal of the F/OSS requirement could be "reconstructed" from that initial list plus the discussion at https://lists.fedoraproject.org/archives/list/council-discuss@lists.fedorap… . I do not believe that is the case at all. Matthew's comment is confusing and ambiguous, and there was no follow-up to it (at least, not the F/OSS part of it), and it seems extremely questionable to me that we would remove such a fundamental requirement based solely on one confused comment from Matthew. He is the FPL, he is not the Pope. The end result of this is that we (Fedora) have somehow indicated to CPE that we have no preference whatsoever for F/OSS tooling. I do not believe that should have been the case. The self-hosting requirement at least Matthew was more clear in opining should be removed, but it is still surprising to me that the process here went "gather a list of requirements from the community, then if Matt says he disagrees with one, take it out immediately but don't tell anyone you did that"! (also I'll note that his substitute requirement that out-migration be easy does not appear to be captured in the final list, although it seems this probably *is* the case with Gitlab so we don't have a problem there.) One thing I'll note here: this is *exactly* the kind of thing that would have come to light very quickly if the open process which was committed to at the start had actually been followed through on. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

4 10

Re: CPE Git Forge Decision
by Adam Williamson 03 Apr '20

03 Apr '20

On Fri, 2020-04-03 at 20:12 +0200, Markus Larsson wrote: > > On 3 April 2020 19:18:57 CEST, Matthew Miller <mattdm(a)fedoraproject.org> wrote: > > On Fri, Apr 03, 2020 at 01:04:33PM -0400, Ben Cotton wrote: > > > For what it's worth, when I sent the list I included a reminder that > > > FOSS is always our strong preference where viable. It was a mistake to > > > not leave that in as a user story. I own that. I did that because of > > > > Eh, I remember it somewhat differently. I don't think that _it is our strong > > preference and very important to our community that this be open source_ is > > a _functional_ requirement, and doesn't really fit as a user story. So we > > pulled that out and emphasized it separately rather than leaving it as one > > among many in the list. > > > > > > I would dare to say that going with a proprietary solution not only > reflects poorly on Fedora but also on Red Hat since it's basically > saying "we needed proper stuff so we couldn't use FOSS". Snipping the more general stuff - just to keep things grounded here, my understanding of the current situation is that we have decided on "Gitlab" for Fedora dist-git going forwards, and possibly also setting up some kind of generic project hosting-type "Gitlab" instance to live alongside pagure.io and potentially replace it if pagure.io winds up being unsustainable without CPE resources behind it. Up front, a note: maybe we should at least be happy that Github was roundly rejected! That would have been a lot worse! The specifics of what choosing "Gitlab" means, *exactly*, ostensibly remain undecided or at least uncommunicated. That's my reading of https://communityblog.fedoraproject.org/making-a-git-forge-decision/ at least. It specifies a choice of "Gitlab", and says the "plan going forward" is to: "Engage with GitLab on the possibility of a SaaS offering so that CPE can attain key requirements of uptime, availability and throughput as well as ensuring tooling integrations (such as Fedora Messaging among others) are preserved. Legal considerations with respect to control of code will be our first discussion point with them enabling us to make a SaaS versus self-hosted decision." (the other items relate to Pagure). That's really as much detail as is on offer. So, as I mentioned in another email, "Gitlab" isn't really one thing. You can see Gitlab's various offerings here: https://about.gitlab.com/handbook/marketing/product-marketing/tiers/ (which makes things much clearer than https://about.gitlab.com/pricing/ ). As you can see there, Gitlab's model is open core: the 'Core' product (hosted version 'Free') is open source, the other three products are not. To me the decision blog post *implies* that we would prefer hosted (SaaS) to self-hosted, if these "legal considerations" can be managed. Nothing I've seen in the decision blog or the discussion here suggests that a decision has been as to *which Gitlab product* we want, or subsidiary questions such as "does it have to be the same product for all instances we are going to wind up with?", "do we actually know how many instances we are going to wind up with for all our stakeholders?", "are some or all of those instances going to be shared between stakeholders, and how does that affect the evaluation of requirements?", and so on. Another interesting question is obviously whether we can negotiate with Gitlab for a custom hosted solution where we get the (open source) Core *product*, but pay for the higher levels of *capacity* and *service* available at the higher tiers (which are usually tied to the non-open- source products). I am not experienced in such matters, but on the face of it, it doesn't seem like an unreasonable request. I assume Gitlab likes money. :P A thing that is making people worried about these questions, I think, is that the *summarized list of user stories* includes several items that *imply* the choice might be tilted in favour of the non-open- source Gitlab products. One instance of this that Neal cited is the "merge trains" requirement. Another is requirement 19 ("As a Project contributor...I want to be able to use kanban boards...So that my team can easily schedule and prioritize work in a visible way"). There may be others, but I'm not 100% sure, so I won't cite them. The fact that these requirements are cited in the blog post and the blog post does *not* delve into these questions at all leaves a big space for uncertainty and doubt, which we are (as is the way of these things) pleased to fill with speculation. I think it would be great if CPE could lay out its take on these questions and give us more detail about its plan going forward. I would also hope we (Fedora) can make it *very very clear* that our strong preference for F/OSS software should be taken into account in this: if there are only a few requirements beyond what could be provided by the open source Gitlab Core, I'd hope we would think long and hard about whether fulfilling those requirements justified compromising on our F/OSS principles. I also hope there will be an opportunity for discussion (with input from the community) of whether those requirements can be fulfilled in some way *other* than using a non-free Gitlab product. To take the 'merge train' example - as Neal and I have mentioned, Pagure now in fact *does* have some impressive capabilities in this area, thanks to the Pagure<->Zuul integration that the Software Factory folks have been working on, and presented at Devconf. I am personally using this for multiple projects, and blogged about it here: https://www.happyassassin.net/2020/02/12/using-zuul-ci-with-pagure-io/ an obvious avenue to explore here would be "can we work with Software Factory folks to do a similar integration between Gitlab Core and Zuul"? On the face of it, that would offer a way to achieve these capabilities in a fully F/OSS way. Or to take the "Kanban" requirement - obviously there are existing F/OSS Kanban implementations, some of which are available as SaaS, like Taiga. Is it really so important to have this feature implemented *within our git forge* that it outweighs our F/OSS principles? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

1 0

Git Forge Discussion: What can we do now?
by Marie Nordin 01 Apr '20

01 Apr '20

Hi all, I have been keeping up with the threads surrounding the git forge move from Pagure to Gitlab. There are three things I would like the council to address: Evaluating this situation, taking some time to document what went badly, what maybe went well, how we can roll out decisions like this more effectively in the future. Perhaps even writing something publicly so that the community sees we see it went badly, and that we are listening. For the teams that want to stay on Pagure, is that an option? How do we ease the path of acceptance around Gitlab for those teams that have to and/or want to move there. The decision to go with it has been made. We need to help the community see, understand, and accept why the decision was made, and then hopefully become inspired to contribute to it. We are working against a lot for this second piece, though I have a couple ideas. I would really love to get input from everyone else. Looking forward to everyone's thoughts. Best, Marie Nordin Fedora Community Action and Impact Coordinator Red Hat <https://www.redhat.com/> • Fedora Project <https://getfedora.org/> She/Her/Hers T: +1.973.800.4967 IRC: riecatnor <https://red.ht/sig>

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

MOVED to https://discussion.fedoraproject.org/tag/council April 2020