On Wed, Jan 29, 2020 at 10:35 AM Iñaki Ucar <iu...@fedoraproject.org> wrote:
> On Wed, 29 Jan 2020 at 00:08, Leigh Griffin <lgrif...@redhat.com> wrote: > > > > On Tue, Jan 28, 2020, 22:06 Iñaki Ucar <iu...@fedoraproject.org> wrote: > >> > >> On Tue, 28 Jan 2020 at 20:58, Leigh Griffin <lgrif...@redhat.com> > 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@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 > -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@redhat.com M: +353877545162 IM: lgriffin @redhatjobs <https://twitter.com/redhatjobs> redhatjobs <https://www.facebook.com/redhatjobs> @redhatjobs <https://instagram.com/redhatjobs> <https://red.ht/sig>
_______________________________________________ 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
