On Thu, 2020-04-02 at 11:47 -0700, Adam Williamson wrote: > > > Can you help me understand what the mystery is about? We took in 300+ > > requirements that we distilled down into the generic list that we came > > up > > with, many of which are buckets / Epics. Every single requirement was > > analysed. I have said this multiple times but please, if this is still > > a > > mystery to you, let me know how I can help clarify it. > > The specific gap I am talking about is the gap between this list > submitted by Ben Cotton on behalf of Fedora: > > https://lists.fedoraproject.org/archives/list/council-discuss@xxxxxxxxxxxxxxxxxxxxxxx/thread/OEPDGVKYAJIQ6YYZU5J3XT3LHXFROFI5/ > > and the 'summarized' list you have pointed to here: > > https://hackmd.io/@My419-DISUGgo4gcmO1D6A/HJB74lcL8 > > Now, right off the bat, we have a huge problem. The "summarized" list > claims this: > > "after duplications and similar in theme requirements were merged > together, we were left with the following unique User Story list:" > > you've also phrased the same thing slightly differently on the mailing > list: > > "As a team we evaluated every single requirement (over 300 of them) and > the presentation in the combined User Story list is an amalgamation of > like for like User Stories to capture at a high level the spirit of the > requests." > > However, the top three points on the Fedora list relate to F/OSS and > self-hosting principles. These points are entirely missing from the > "summarized" list. They have not been "merged" with "duplications" or > "similar in theme requirements". The "spirit" of them has not been > "captured" in a "User Story". They are just *not there*. They have not > been summarized. They were dropped. So the claim is false, and there was > not just a summarization process here, there was some sort of filtering > process. Things from the stakeholder lists were outright left out of the > "summarization". I'll pick this up again later. > > Of the other 44 points on the Fedora list, 23 mention dist-git > specifically. The term "dist-git" is mentioned 40 times. Some of these > aren't truly "dist-git" specific, and are really just generic git or > forge requirements, but many of them *are* specific to dist-git and the > packager workflow integration; I'd count at least points 9, 17, 18, 19, > 20, 22, 23, 24, 25, 26, 28, 29, and maybe 37 in this bucket. In the > "summarized" list, the string "dist-git" does not appear once. I can buy > that a few of the requirements are *possibly* "summarized" into the > points about access control, but generic access control requirements do > not at all cover all the details of dist-git integration. Effectively, > all the details relating to dist-git and packager workflow interaction - > which constitute the large majority of significant requirements on the > Fedora list that wouldn't be satisfied by all of the candidates - are > lost in the summarized list. Sorry, just to join up the thinking here a little more: this isn't just theoretical after-the-fact point-scoring and Monday morning quarterbacking, either. It's still very important as this decision making process goes forward. As we've been sort of dancing around, if we accept that the "Pagure vs. Gitlab" decision has been made in favour of Gitlab, we still ostensibly have two very important and interrelated choices to make: 1. Which Gitlab product? 2. Self-hosted or SaaS? (it actually doesn't seem at all clear whether 2) is really outstanding or not, but for the purpose of this email I'm going to assume it is). If those decisions get made based on this summarized list of User Stories, then all of the Fedora requirements which have been lost or transmogrified beyond recognition (as detailed in the other post) will not be taken into account in making that decision. As Neal has pointed out, if the summarized list is taken at face value, it's very difficult to imagine the decision coming out as anything other than 'Gitlab Ultimate Saas'. But those Fedora requirements that are not properly captured are *very* germane to this decision. Most obviously, the strong Fedora preference for F/OSS software - which I think should be obvious from the fact that this is item #2 in Fedora's list! - will not be considered at all. Neither will Fedora's desire for self-hosting, which is item #1 in Fedora's list. Both of those requirements bear *directly* on these decisions, yet are not captured in the summarized list *at all*. Beyond that, the dist-git integration issues are *also* very germane to these decisions. I would suggest that it is likely that this integration work would go easier and faster on a self-hosted forge as compared to an SaaS forge, for two main reasons: 1) We can patch a self-hosted forge at will 2) We control the deployment choices for a self-hosted forge These are both things that make deploying deep and complex integrations much easier. If the integration requires a change to be made in the forge, and we're using a hosted solution, we are at the mercy of the provider to merge and deploy it. I suppose it's *possible* that you could negotiate a hosting contract which gives us the ability to demand that our deployments be patched with certain changes, or to dictate when a new version be deployed, but it doesn't seem *likely*. That doesn't seem to be how hosting generally works. At best I can imagine we could get the ability to *ask* for these things, but I doubt very much the responsiveness would be anywhere near the control you have over a self-hosted deployment. I would like to have much more confidence than I currently do that these issues are going to be considered in deciding these two questions. -- 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
