On Fri, 2020-04-03 at 20:12 +0200, Markus Larsson wrote:
>
> On 3 April 2020 19:18:57 CEST, Matthew Miller <mattdm@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
_______________________________________________
council-discuss mailing list -- council-discuss@lists.fedoraproject.org
To unsubscribe send an email to council-discuss-leave@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/council-discuss@lists.fedoraproject.org
No comments:
Post a Comment