On Mon, Mar 30, 2020 at 9:55 PM Till Maas <opensource@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 <opensource@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 <opensource@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-discuss@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.

44 requirements were received from Ben Cotton on behalf of the Fedora Council. It's not for me to comment on whether the thread was copied verbatim or how it was rolled up, I dealt with the formal requirements that landed. 

> > 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.

Bear in mind the user stories we published were the amalgamated User Story list, we considered every single story as it was written and intended. 

> > 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-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/devel@lists.fedoraproject.org


--

Leigh Griffin

Engineering Manager

Red Hat Waterford

Communications House

Cork Road, Waterford City

lgriffin@redhat.com    
M: +353877545162    
 IM: lgriffin