Fedora Council Video Meeting: May 2020 - Lenovo
by Ben Cotton
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
3 years, 12 months
A Community Change process to mirror the System Change process
by Ben Cotton
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
4 years
Re: CPE Git Forge Decision
by Adam Williamson
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
4 years
Re: CPE Git Forge Decision
by Adam Williamson
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.fedor...
. 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 years
Re: CPE Git Forge Decision
by Adam Williamson
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
4 years
Git Forge Discussion: What can we do now?
by Marie Nordin
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>
4 years
