On Fri, 2020-04-03 at 20:12 +0200, Markus Larsson wrote: > > On 3 April 2020 19:18:57 CEST, Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> 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 _______________________________________________ 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
