Re: Git Forge Requirements: Please see the Community Blog

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Wed, Jan 29, 2020 at 10:35 AM Iñaki Ucar <iucar@xxxxxxxxxxxxxxxxx> wrote:
On Wed, 29 Jan 2020 at 00:08, Leigh Griffin <lgriffin@xxxxxxxxxx> wrote:
>
> On Tue, Jan 28, 2020, 22:06 Iñaki Ucar <iucar@xxxxxxxxxxxxxxxxx> wrote:
>>
>> On Tue, 28 Jan 2020 at 20:58, Leigh Griffin <lgriffin@xxxxxxxxxx> wrote:
>> >
>> > This thread is serving as a source of requirements (although it has meandered dramatically away from that)
>>
>> When I first read the post, my thought was: wow, what a convoluted and
>> abstruse way of saying "we want to abandon Pagure". Probably this
>> wasn't your intent, but that's what I got. And given the reactions,
>> other people too.
>
> The linked blog to the ODF is very explicit that Pagure is one of the 3 forge options we are considering. I can't stress enough that it's a viable choice and ultimately what we opt for will come down to an analysis driven by the requirements gathered. I'm unsure how the blog has been interpreted any other way but hopefully this clears it up.

The ODF is very explicit in the problem statement, and it specifically
and clearly says that:

1. Pagure does not align with CPE.

Correct and it's why we said this line, which you might have missed:
"While we can make exceptions to the mission statement, we first need to know why we should consider a specific exception."
 
2. CPE is not gonna commit a development team to Pagure.

CPE has not committed a team to it in over a year, we do state that as a driving factor to why we want to engage in this conversation but your assumption here is based on a particular outcome that sees Pagure not chosen. If Pagure is chosen, we will commit a team. We are very clear on that.
 
3. The feature gap is big and growing, and basically Pagure is gonna
die because of this (and the document goes on saying that you're not
trying to solve the feature gap).

Pagure is a standalone community project. Our choice is not killing Pagure and irrespective of the decision we make I personally hope it stays strong and grows. Stating the feature gap is big and growing is factual, with no committed team we are behind on it. 

Then the ODF lists Pagure as a solution. How am I supposed to
interpret the above?


This is why we are opening it to be very explicit that for the past year we have not focused on Pagure but we now need to make a decision going forward. If Pagure is the choice we staff it accordingly and de-priortise other initiatives and include it within our scope going forward. That is why Pagure is listed as a choice and it is why the ODF is laid out like that.
 

> If you (and others) elaborate on how you use Pagure (and other forges) and what you value from your day to day usage, we will take that on board and use it to drive our decision making.

Asking for requirements for a *forge* is pointless. A forge doesn't
have requirements. What you do with a forge has requirements.
 
Tell me what you do and how you interact with a forge? That's the point of this exercise.
 
As
others have already pointed out, Pagure is being used at the very
least for 3 distinct use cases: to maintain rpm packages, to maintain
upstream projects, and as an issue tracker. And they all have distinct
requirements.

And we wish to hear all 3 as ultimately CPE become the owner of the solution that satisfies those requirements.
 
Only that, as it happens, Pagure has grown to cover
their necessities with more or less success, which doesn't necessarily
mean that a forge is the best solution for all of them (as, again,
others have pointed out already). But the ODF only lists forges as
solutions.

And if the requirements are stated we can have an open conversation about what does suit it. I get that things have organically grown around a forge that may / may not be the best fit for it now, lets examine that as a conversation when we know how people are using it. This topic is focused on what git forge the CPE team will choose based on requirements gathered but if there is a means to address a requirement gap by another tool that is not a forge, then that's a really good outcome of the conversation.

So solutions for what? What are we talking about here? Requirements
for src.fp.org? Requirements for things that are in pagure.io? All?
Other?

Iñaki
_______________________________________________
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


--

Leigh Griffin

Engineering Manager

Red Hat Waterford

Communications House

Cork Road, Waterford City

lgriffin@xxxxxxxxxx    
M: +353877545162    
 IM: lgriffin

_______________________________________________
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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux