Git forge requirements discussion

[Adam Williamson]

Hey folks!

There's a post on the Community Blog:

https://communityblog.fedoraproject.org/git-forge-requirements

and a thread on devel@:

https://lists.fedoraproject.org/archives/list/[e-mail]/...

explaining that CPE is considering 'the future of a git forge solution
which will be run by the CPE team on behalf of the Fedora Community',
i.e. possibly ditching Pagure. The named contenders so far are Pagure,
Gitlab and Github.

The devel@ thread is going to be the usual tire fire, but I think we
should write up something on this and send it to the Council (who are
supposed to represent the interests of Fedora 'communities' in this
process). Obviously we use Pagure for project hosting, issue tracking,
and we're also working on the new async blockerbugs process, which
relies on integration with Pagure.

Can folks (especially those working on the blockerbugs stuff) read
through the posts and think about what requirements we have here? I
don't think it's going to be useful to have a big argument about the
specific contenders here (see devel@ for that!) but it would be good to
write up what QA actually needs in a forge. I'll try and gather the
feedback and organize it into something to send to Council.

Thanks everyone!

[Kamil Paral]

On Wed, Jan 22, 2020 at 10:00 AM Adam Williamson 
wrote:
> Hey folks!
>
> There's a post on the Community Blog:
>
> https://communityblog.fedoraproject.org/git-forge-requirements
>
> and a thread on devel@:
>
> https://lists.fedoraproject.org/archives/list/[e-mail]/...
>
> explaining that CPE is considering 'the future of a git forge solution
> which will be run by the CPE team on behalf of the Fedora Community',
> i.e. possibly ditching Pagure. The named contenders so far are Pagure,
> Gitlab and Github.
>
> The devel@ thread is going to be the usual tire fire, but I think we
> should write up something on this and send it to the Council (who are
> supposed to represent the interests of Fedora 'communities' in this
> process). Obviously we use Pagure for project hosting, issue tracking,
> and we're also working on the new async blockerbugs process, which
> relies on integration with Pagure.
>
> Can folks (especially those working on the blockerbugs stuff) read
> through the posts and think about what requirements we have here? I
> don't think it's going to be useful to have a big argument about the
> specific contenders here (see devel@ for that!) but it would be good to
> write up what QA actually needs in a forge. I'll try and gather the
> feedback and organize it into something to send to Council.

(Replying here and not devel list to consolidate our thoughts first)

Hmm,
I don't think we have some very special requirements. For the planned
blocker review async discussion, we need API to be able to add comments and
edit the ticket description, ideally also adjust ticket tags, milestones or
some other properties. We need a webhook support to get notified of changes
or access to a message bus. Nothing unusual I think. Or, of course, native
support for voting/polls (ideally multiple per a single ticket) would be
even better :-)

As for general requirements, or at least very nice to have's, I'd probably
repeat what was already mentioned in devel list: open source, with a good
integration to Fedora core services (the account system, messaging).

[Matthew Miller]

On Thu, Jan 23, 2020 at 04:02:42PM +0100, Kamil Paral wrote:
> I don't think we have some very special requirements. For the planned
> blocker review async discussion, we need API to be able to add comments and
> edit the ticket description, ideally also adjust ticket tags, milestones or
> some other properties. We need a webhook support to get notified of changes
> or access to a message bus. Nothing unusual I think. Or, of course, native
> support for voting/polls (ideally multiple per a single ticket) would be
> even better :-)

Can you put the voting/polls idea in the form of a user story?