On Mon, 30 Mar 2020 at 22:55, Till Maas <opensou...@till.name> wrote:
> Hi, > > On Mon, Mar 30, 2020 at 02:40:13PM +0000, Leigh Griffin wrote: > > On Mon, Mar 30, 2020 at 3:26 PM Till Maas <opensou...@till.name> wrote: > > > > > Hi, > > > > > > On Mon, Mar 30, 2020 at 01:59:07PM +0000, Leigh Griffin wrote: > > > > On Mon, Mar 30, 2020 at 2:18 PM Till Maas <opensou...@till.name> > wrote: > > > > > > > > > Hi, > > > > > > > > > > On Mon, Mar 30, 2020 at 11:04:03AM +0100, Leigh Griffin wrote: > > > > > > > > > > > For transparency, we have published the full User Story list > which is > > > > > > linked within the blog and for ease of searching is here: > > > > > > https://hackmd.io/@My419-DISUGgo4gcmO1D6A/HJB74lcL8 > > > > > > > > > > the user stories list does not seem to include the original user > > > stories > > > > > that I submitted regarding package life-cycle and permission > > > management. > > > > > These are requirements for dist-git but not necessarily for a > > > git-forge. > > > > > In the past they were fulfilled by package db, now pagure is > solving > > > > > this more. > > > > > > > > > > > > We received a summarised User Story list from the Fedora Council, I > would > > > > suggest reaching out with your concerns. > > > > > > What is the list that you got. The list on the council discuss list > > > contained these items, for example for FESCo members, proven packagers > > > and dist-git repo admins: > > > > > > > https://lists.fedoraproject.org/archives/list/council-disc...@lists.fedoraproject.org/thread/OEPDGVKYAJIQ6YYZU5J3XT3LHXFROFI5/ > > > > > > We received a Google Doc with the summation of the 44 requirements from > > Fedora Council. > > Please be more specific. Are these the requirements from the discussion > different ones? The discussion had 47 requirements, 1 and 2 were > challenged and 47 mentioned as nice-to-have. Who submitted them? I guess > it was Ben. > > > > In the hackmd story list, there are is only infosec, RH Legal Rep, RH > > > Infocsec Rep, RH Developer, RHEL engineer and general users, project > > > contributor, CPE team member. Nothing really maps to the user groups I > > > mentioned. > > > > > > As mentioned, we rolled in stories together and General Users / > > contributors map to the majority of the Fedora projects requirements > > (similar for CentOS) and a lot of individual stakeholder requirements > ended > > up in the general bucket. > > > > > > > There is only > > > > > > | 41 > > > | As a General User > > > | I want groups and group membership and management > > > | to allow me create access control on a suite of repositories > > > > > > but this is very vague. > > > > > > > The User Stories are deliberately vague and that represents around 10 > > unique requirements that boil down to having group membership and > > management capabilities. > > IMHO the problem with this vague requirement is that it probably fits > every gitforge. But for Fedora, the package management aspects are more > important than generic gitforge capabilities that any gitforge can > provide. > I don't think this is necessarily true, in fact Fedora existed before Pagure( using cgit as a git interface). I am not necessarily proposing to recreate something like packageDB but I believe that there might be a possible middle ground between using a generic git forge and some tooling around to support the package management aspects. And yes this will require some work, but my feeling is that on the longer term this will be easier to maintain than a code base like Pagure. > > > > Also there seems to be nothing about orphaning/adopting/retiring > > > packages, not even in a vague way. > > > > > > > We have stories relating to specific workflow requirements (from multiple > > stakeholders including RHEL, CentOS and Fedora) for dist-git. We have > > represented a requirement (number 18 on the list) about viewing orphaned > > packages. The requirements received around this process were very much > > aligned with permissions and visibility to allow actions. They are > covered > > through other User Stories and what I feel needs to be made clear, we are > > presenting the amalgamated list and as a team we read every single User > > Story that came in and processed them accordingly in making this > decision. > > From the experience with the migration from Packagedb to pagure, the > specific requirements for Fedora seem to require more effort than just > providing generic gitforge capabilities. For example, the adopting an > orphaned package process needs to be a self service instead of a manual > process for release engineering. And the requirements seem to be so > vague that providing GIT repos with config files for workflows appears > as a valid solution but there should be a proper user interface. > > Adapting a git forge to properly provide the workflow for Fedora > dist-git seems to me to be one of the major tasks, so assessing whether > a gitforge simplifies this seems to me to be rather important to make an > informed decision. > > Kind regards > Till > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org >
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
