Re: CPE Git Forge Decision

[Paul Frields]

On Tue, Mar 31, 2020 at 5:23 PM Adam Williamson
 wrote:
>
> On Tue, 2020-03-31 at 17:06 -0400, Paul Frields wrote:
> >
> > > Sure. I tend to think of these as 'upstream projects' that we (Fedora)
> > > consume as a downstream. Project hosting has always been a kinda
> > > optional bolt-on, I think; going back to the days of fedorahosted.org I
> > > don't think we've ever hosted everything "Fedora-adjacent" in our own
> > > hosting service, it's always been a "use it if you want to" thing, and
> > > the rule for using a project in Fedora has always been "is it open
> > > source?", not "how is it hosted?".
> >
> > Although the Council changed that hard line some time ago.
>
> Someone told me that a few minutes ago; either I wasn't aware at the
> time or have forgotten, but my personal opinion is that this was a
> mistake.
>
> > > For that reason, I think the "what to do with Pagure.io?" element of
> > > this discussion is less critical than the src.fp.o part.
> > >
> > > >  A critical part of
> > > > our infrastructure the NFS shared storage also run an proprietary 
> > > > software
> > > > (NetApp).
> > >
> > > That's been covered already, and was why I put the "(more or less)"
> > > caveat into my quote. Of course, when you're getting to storage
> > > appliances, you're getting into pretty fuzzy territory, because we
> > > don't worry about the openness of the firmware running on our servers
> > > and stuff like that either...we've never quite been at FSF levels of
> > > ideological purity. But to me, this is at a different level to that.
> >
> > I see what we do for a dist-git fronting forge as far less compelling
> > for "purity level" tests because nearly all the meaningful content is
> > still easily copied and/or forked. Using open source for our specific
> > authentication needs (self-service groups, etc.), for instance, is a
> > recent example of a more compelling level, and the CPE group is
> > putting time into that project accordingly.
>
> I'm not sure I entirely understand the argument here. Are you saying we
> should only care if the specific things we need in Fedora are open
> source - like our CLI integrations and so on? If so, isn't that
> entirely naturally compatible with using Gitlab CE? After all, if all
> you want the external project to be is a generic git forge and you plan
> to write all the integration on top of that yourself, Gitlab CE does
> that job fine?

No, rather what I meant is that since git is git, and I still have my
data (and in the cases of all GitLab flavors AFAICT, nearly all the
meaningful metadata), I don't find it compelling whether the service
itself is fully open source. In fact, I wouldn't be opposed to using
GitHub if that were going to gain us some advantage for collaboration
that made it worthwhile.

-- 
Paul
___
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

Re: CPE Git Forge Decision

[Adam Williamson]

On Tue, 2020-03-31 at 17:06 -0400, Paul Frields wrote:
> 
> > Sure. I tend to think of these as 'upstream projects' that we (Fedora)
> > consume as a downstream. Project hosting has always been a kinda
> > optional bolt-on, I think; going back to the days of fedorahosted.org I
> > don't think we've ever hosted everything "Fedora-adjacent" in our own
> > hosting service, it's always been a "use it if you want to" thing, and
> > the rule for using a project in Fedora has always been "is it open
> > source?", not "how is it hosted?".
> 
> Although the Council changed that hard line some time ago.

Someone told me that a few minutes ago; either I wasn't aware at the
time or have forgotten, but my personal opinion is that this was a
mistake.

> > For that reason, I think the "what to do with Pagure.io?" element of
> > this discussion is less critical than the src.fp.o part.
> > 
> > >  A critical part of
> > > our infrastructure the NFS shared storage also run an proprietary software
> > > (NetApp).
> > 
> > That's been covered already, and was why I put the "(more or less)"
> > caveat into my quote. Of course, when you're getting to storage
> > appliances, you're getting into pretty fuzzy territory, because we
> > don't worry about the openness of the firmware running on our servers
> > and stuff like that either...we've never quite been at FSF levels of
> > ideological purity. But to me, this is at a different level to that.
> 
> I see what we do for a dist-git fronting forge as far less compelling
> for "purity level" tests because nearly all the meaningful content is
> still easily copied and/or forked. Using open source for our specific
> authentication needs (self-service groups, etc.), for instance, is a
> recent example of a more compelling level, and the CPE group is
> putting time into that project accordingly.

I'm not sure I entirely understand the argument here. Are you saying we
should only care if the specific things we need in Fedora are open
source - like our CLI integrations and so on? If so, isn't that
entirely naturally compatible with using Gitlab CE? After all, if all
you want the external project to be is a generic git forge and you plan
to write all the integration on top of that yourself, Gitlab CE does
that job fine?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
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

Re: CPE Git Forge Decision

[Paul Frields]

On Tue, Mar 31, 2020 at 3:25 PM Adam Williamson
 wrote:
>
> On Tue, 2020-03-31 at 21:18 +0200, Clement Verna wrote:
> > On Tue, 31 Mar 2020 at 20:04, Adam Williamson 
> > wrote:
> >
> > > On Tue, 2020-03-31 at 13:55 -0400, Matthew Miller wrote:
> > > > On Tue, Mar 31, 2020 at 10:44:35AM -0700, Adam Williamson wrote:
> > > > > I'm sorry, but I have to agree with Kevin and Michael here to a
> > > > > significant extent. Running our own project on open source code has
> > > > > always been a very big bright line for Fedora.
> > > >
> > > > You don't have to be sorry! I think it's very clear that this is the 
> > > > general
> > > > community view.
> > > >
> > > > > I think Iñaki's take on the "oh, you contribute to Github projects so
> > > > > no problem right?" angle is correct.
> > > >
> > > > Let me be sorry, though. That wasn't mean to be a "oh you..." 
> > > > statement. It
> > > > was that other open source projects are not held to this standard, not 
> > > > to
> > > > "gotcha" Michael or anyone else for their contributions elsewhere.
> > >
> > > I mean, held by who? This is a standard we have (more or less) held
> > > ourselves to. Which, if you think about it, means it's a standard
> > > that's in our DNA: we're a group of people who *thought it was
> > > important enough to hold ourselves to that standard*. Would it be
> > > hypocritical for someone outside of Fedora who happily uses software
> > > from other projects that are hosted on Github or whatever to criticize
> > > us if we were to do this? Sure, it would be. But this here is not that,
> > > it's us holding ourselves to our own standards.
> > >
> > > Speaking personally, sure, I contribute to Github-hosted projects. I
> > > maintain one project on Github (because it's extremely adjacent to
> > > another project that's hosted on Github and the maintainers of that
> > > project asked me to have it there, so I did). Hell, I send in fixes for
> > > entirely proprietary things sometimes...because my overriding itch is,
> > > if something is there, at least it had better *work* properly. But I
> > > certainly would not consider hosting work that's a fundamental part of
> > > Fedora on a proprietary system, I've always seen that as a *complete*
> > > non-starter - whether we were considering test automation, result
> > > tracking, event organization, anything like that, the very first rule
> > > has always been, if it's not open source it's just not on the list at
> > > all. And as far as I've noticed, that has been the same for all other
> > > core Fedora stuff, for many years.
> > >
> >
> > To add some nuance to stat statement a quite big chunk of the Fedora Infra
> > apps are hosted on GitHub (https://github.com/fedora-infra), and relatively
> > critical things like Bodhi, FAS, mirrormanager, . As far as I know most
> > of Fedora CoreOS (and Silverblue ?) is also on GitHub.
>
> Sure. I tend to think of these as 'upstream projects' that we (Fedora)
> consume as a downstream. Project hosting has always been a kinda
> optional bolt-on, I think; going back to the days of fedorahosted.org I
> don't think we've ever hosted everything "Fedora-adjacent" in our own
> hosting service, it's always been a "use it if you want to" thing, and
> the rule for using a project in Fedora has always been "is it open
> source?", not "how is it hosted?".

Although the Council changed that hard line some time ago.

> For that reason, I think the "what to do with Pagure.io?" element of
> this discussion is less critical than the src.fp.o part.
>
> >  A critical part of
> > our infrastructure the NFS shared storage also run an proprietary software
> > (NetApp).
>
> That's been covered already, and was why I put the "(more or less)"
> caveat into my quote. Of course, when you're getting to storage
> appliances, you're getting into pretty fuzzy territory, because we
> don't worry about the openness of the firmware running on our servers
> and stuff like that either...we've never quite been at FSF levels of
> ideological purity. But to me, this is at a different level to that.

I see what we do for a dist-git fronting forge as far less compelling
for "purity level" tests because nearly all the meaningful content is
still easily copied and/or forked. Using open source for our specific
authentication needs (self-service groups, etc.), for instance, is a
recent example of a more compelling level, and the CPE group is
putting time into that project accordingly.

-- 
Paul
___
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

Re: CPE Git Forge Decision

[clime]

Dne út 31. bře 2020 21:00 uživatel Clement Verna 
napsal:

>
>
> On Tue, 31 Mar 2020 at 14:57, Neal Gompa  wrote:
>
>> On Tue, Mar 31, 2020 at 7:10 AM Clement Verna 
>> wrote:
>> >
>> > I just want to give a bit of insight from someone who is working day to
>> day on Fedora's infrastructure, since I believe that might help give a bit
>> more empathy towards the Why of this decision.
>> >
>> > For me the Fedora's Infrastructure is in a very bad shape there is a
>> fair load of technical debt and trying to change or improve anything
>> results in a long list of reason why we can do it because services X
>> depends on service Y which depends on Z.  Since I joined the CPE team
>> (little bit more than 2 years ago) we have not been able to make any kind
>> of significant progress towards fighting this technical debt. Every year we
>> fill a white board with what needs to be done :
>> >
>> > Python 3 apps migration,
>> > FAS replacement,
>> > fedmsg retirement,
>> > FMN replacement,
>> > Fedora-packages replacement,
>> > PDC replacement,
>> > Porting application to OIDC,
>> > Improve Releng automation,
>> > Improving Anitya and the-new-hotness,
>> > .
>> >
>> > Every single year the same items are coming back because we spend most
>> of our time firefighting services to keep users happy and keep Fedora
>> release schedule. This has a very demoralizing effect on the people working
>> in the team, it seems like we will never be able to make any significant
>> improvement, and our day to day job is to close couple tickets and you keep
>> watching the pile of tickets growing. There is no feeling of accomplishment
>> and a general sentiment that whatever we do, it will suck.
>> >
>> > A little over a year ago we have expressed our need to drop
>> applications, this is something we have to do to be able to stay sane and
>> keep a sustainable life-work balance. From that effort to handover
>> applications (Elections, Nuancier, Fedocal, Badges) to another group of
>> people in the community, not much happened mainly because of GDPR and the
>> legal responsibility of owning such applications, but as far as I know we
>> don't do much maintenance work on these applications any more since we now
>> have a few volunteers that are looking after them or helping with finding
>> an alternative solution.
>> >
>> > Now on the list of application we develop and run, I think Pagure is
>> logical candidate to try and find an alternative to it, but before doing
>> this it was important to make sure we captured all the use case and feature
>> needed from a git forge and see if any of these justified spending cycles
>> in development and maintenance work. My understanding of the decision is
>> that Pagure does not provide any significant advantage over GitLab. I know
>> that for many, the fact that Pagure is developed by Fedora is an advantage,
>> but from my perspective as someone that as to deal with all the other
>> services in Fedora's Infra this is a major disadvantage.
>> >
>> > Overall I think it is important to keep in mind that there is a lot of
>> work happening behind the scene to provide the people in the Fedora
>> community a good experience contributing to Fedora. I think we are doing a
>> good job at it, but that takes us an enormous effort and over the long term
>> this is not sustainable, also keeping in mind that we keep adding and want
>> to keep adding new things to Fedora.
>> >
>> > I hope that my perspective helps a little.
>> >
>>
>> Clement,
>>
>> I want to say thank you for all the hard work you do as a member of
>> the Fedora community and as a member of the CPE team. You've done
>> fantastic work for the community and it's always a pleasure to work
>> with you. And that goes for all the members of the CPE team. I totally
>> understand where you are coming from. And it *is* very demoralizing to
>> see the same things over and over again, looking as if you've made no
>> progress on these things. I've been there with my work at $DAYJOB
>> before, many times. And as you and others are aware, I've been poking
>> around throughout infrastructure projects to help with some of these
>> initiatives over the years, so I'm keenly aware of the size and scope
>> of many of these.
>>
>> However, I think some of this is self-inflicted. I don't want to
>> entirely rehash my original email with my thoughts on this, so please
>> read that for more detail[1], but I think we *really* should consider
>> that the lack of community exposure to to the codebases themselves
>> (especially as an avenue for contributing to the Fedora Project!) is
>> an underlying problem here. This has created a persistent cycle of
>> "community member makes cool project to support Fedora" → "it gets
>> adopted silently and no one really talks about it or advertises it" →
>> "nobody knows about it and the community member is the only one
>> working on it" → "the community member burns out and it gets piled
>> onto Fedora Engineering/CPE to 

Re: CPE Git Forge Decision

[Robbie Harwood]

Clement Verna  writes:

> Neal Gompa  wrote:
>> Clement Verna  wrote:
>>
>> As for Pagure itself, I think this is where we fundamentally
>> disagree.  I think it behooves us to own and provide an experience
>> tailored for our community from beginning to end. That's why we have
>> Koji, Bodhi, Dist-Git, and many other tools in that part of the
>> lifecycle. The packager experience is literally the lifeblood of the
>> project, and our contributors are the core of what makes Fedora
>> successful. Pagure gives us an opportunity to do right by them that I
>> *really* don't think we can do with any alternatives.
>
> I am not convinced that having a custom git forge is mandatory to
> provide an great experience to the community. I wasn't really around
> the community before Pagure, but I as far as I understand it the
> experience was better before Pagure and people were able to do more
> self servicing. I believe that there is an alternative to having the
> packager workflow tightly coupled to the git forge, this is also maybe
> a good opportunity to rethink some of that workflow and explore
> different solutions.

Well, this continues to conflate "git forge" and "solution for
dist-git".

Before pagure, we had a (no-webui) git serving dist-git with other
services (e.g., pkgdb) stapled on.  More self-servicing was possible
because it was a more mature project.  In my opinion, the move to pagure
happened prematurely due to lack of feature parity - a problem we're
still dealing with today, which I think is what your "self servicing" is
in reference to.

Before pagure, we also had fedorahosted, which was our solution for
hosting projects, combining trac and a few other things.  Migration was
*painful*, and there have been many rocky parts along the way, but the
experience now is definitely better than fedorahosted.  It's far less
pleasant than a github project, though.

My impression is that most folks on this thread are more worried about
dist-git and its integrations than a general git forge, while it feels
like all CPE wants to talk about is the git forge.  You can't just use a
git forge as a dist-git: it takes a lot of integration work, which is
invisible because right now it's been done and just works™.  The refusal
to consider that this work exists in the decision worries me.

So long as it's open and we host it, I don't personally care what we
choose - as long as we can actually use it.

Thanks,
--Robbie


signature.asc
Description: PGP signature
___
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

Re: CPE Git Forge Decision

[Przemek Klosowski via devel]

On 3/31/20 1:40 PM, Bruno Wolff III wrote:

On Tue, Mar 31, 2020 at 13:08:05 -0400,
 Matthew Miller  wrote:


We did communicate as the very top line of our gathered requirements 
that
open source is essential to our community and central to our 
feedback. I'm

not trying to be soft on that. Let's just not do purity-test level
assessments and instead focus on our goals.


The response from CPE made it sound like they just counted 
requirements rather than evalutating how important each requirement 
was to each group. Perhaps that was not intended, but that's they way 
it sounds. I think that being able to theorectically switch from 
hosted to self-hosted in short order (like in a month), should have 
been a deal breaking requirement from Fedora in case something at 
Gitlab changed that prevented using their hosted service. That implies 
having access to the source (capable of running our instance) with a 
free license and regular exports of the data in our hands. It doesn't 
sound like that is a requirement from the response provided by CPE.


Because of switching costs, this is likely to prevent us from going 
back to Pagure if it does develop a vibrant independent community. 
That would be unfortunate. 


This particular dilemma reminds me very much of the time when the LInux 
kernel developers weren't using version control, and it became clear 
that one is needed. Linus just refused to use CVS, and after some 
controversy, the core developers decided to use Larry McVoy's 
proprietary BitKeeper distributed VCS. This solved the technical problem 
and was successfully used for few years (2002 to 2005, IIRC).


Bitkeeper critics were pointing out that while the Linux community was 
free to use it to keep the source code, the Bitkeeper terms of use 
prohibited the non-commercial users from extracting the metadata 
(history, logs, etc). This issue kept causing problems, finally spurring 
Linus to sit down and invent git, and the rest is history.


It is important to remember that BitKeeper, while proprietary, had a 
very friendly and close relationship with the FOSS community, both when 
they joined forces and even when they were parting ways.  Still, the 
official Linux git log ( 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?ofs=905000 
) lacks the development history preceding 2005-04-16, and starts with 
one heck of a commit:


2005-04-16 	[PATCH] mmtimer build fix 
 
	Christoph Lameter 	1 	-1/+1
2005-04-16 	Linux-2.6.12-rc2 
v2.6.12-rc2 
 
	Linus Torvalds 	17291 	-0/+6718755


Perhaps the relevant lesson is that the only permanent thing is that 
nothing is permanent. Decisions that seem inevitable and superior do not 
necessarily continue to be so, and it's good to have a contingency plan 
for such eventalthough I am pretty sure that Linus did NOT plan to 
work on git in 2002.


Disclaimer: I wrote down my personal best recollections and opinions. 
Please draw your own conclusions and analogies; I ask for your 
indulgence hoping that it will be enlightening to at least someone.


___
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

Re: CPE Git Forge Decision

[Adam Williamson]

On Tue, 2020-03-31 at 21:18 +0200, Clement Verna wrote:
> On Tue, 31 Mar 2020 at 20:04, Adam Williamson 
> wrote:
> 
> > On Tue, 2020-03-31 at 13:55 -0400, Matthew Miller wrote:
> > > On Tue, Mar 31, 2020 at 10:44:35AM -0700, Adam Williamson wrote:
> > > > I'm sorry, but I have to agree with Kevin and Michael here to a
> > > > significant extent. Running our own project on open source code has
> > > > always been a very big bright line for Fedora.
> > > 
> > > You don't have to be sorry! I think it's very clear that this is the
> > general
> > > community view.
> > > 
> > > > I think Iñaki's take on the "oh, you contribute to Github projects so
> > > > no problem right?" angle is correct.
> > > 
> > > Let me be sorry, though. That wasn't mean to be a "oh you..." statement.
> > It
> > > was that other open source projects are not held to this standard, not to
> > > "gotcha" Michael or anyone else for their contributions elsewhere.
> > 
> > I mean, held by who? This is a standard we have (more or less) held
> > ourselves to. Which, if you think about it, means it's a standard
> > that's in our DNA: we're a group of people who *thought it was
> > important enough to hold ourselves to that standard*. Would it be
> > hypocritical for someone outside of Fedora who happily uses software
> > from other projects that are hosted on Github or whatever to criticize
> > us if we were to do this? Sure, it would be. But this here is not that,
> > it's us holding ourselves to our own standards.
> > 
> > Speaking personally, sure, I contribute to Github-hosted projects. I
> > maintain one project on Github (because it's extremely adjacent to
> > another project that's hosted on Github and the maintainers of that
> > project asked me to have it there, so I did). Hell, I send in fixes for
> > entirely proprietary things sometimes...because my overriding itch is,
> > if something is there, at least it had better *work* properly. But I
> > certainly would not consider hosting work that's a fundamental part of
> > Fedora on a proprietary system, I've always seen that as a *complete*
> > non-starter - whether we were considering test automation, result
> > tracking, event organization, anything like that, the very first rule
> > has always been, if it's not open source it's just not on the list at
> > all. And as far as I've noticed, that has been the same for all other
> > core Fedora stuff, for many years.
> > 
> 
> To add some nuance to stat statement a quite big chunk of the Fedora Infra
> apps are hosted on GitHub (https://github.com/fedora-infra), and relatively
> critical things like Bodhi, FAS, mirrormanager, . As far as I know most
> of Fedora CoreOS (and Silverblue ?) is also on GitHub.

Sure. I tend to think of these as 'upstream projects' that we (Fedora)
consume as a downstream. Project hosting has always been a kinda
optional bolt-on, I think; going back to the days of fedorahosted.org I
don't think we've ever hosted everything "Fedora-adjacent" in our own
hosting service, it's always been a "use it if you want to" thing, and
the rule for using a project in Fedora has always been "is it open
source?", not "how is it hosted?".

For that reason, I think the "what to do with Pagure.io?" element of
this discussion is less critical than the src.fp.o part.

>  A critical part of
> our infrastructure the NFS shared storage also run an proprietary software
> (NetApp).

That's been covered already, and was why I put the "(more or less)"
caveat into my quote. Of course, when you're getting to storage
appliances, you're getting into pretty fuzzy territory, because we
don't worry about the openness of the firmware running on our servers
and stuff like that either...we've never quite been at FSF levels of
ideological purity. But to me, this is at a different level to that.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
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

Re: CPE Git Forge Decision

[Clement Verna]

On Tue, 31 Mar 2020 at 20:04, Adam Williamson 
wrote:

> On Tue, 2020-03-31 at 13:55 -0400, Matthew Miller wrote:
> > On Tue, Mar 31, 2020 at 10:44:35AM -0700, Adam Williamson wrote:
> > > I'm sorry, but I have to agree with Kevin and Michael here to a
> > > significant extent. Running our own project on open source code has
> > > always been a very big bright line for Fedora.
> >
> > You don't have to be sorry! I think it's very clear that this is the
> general
> > community view.
> >
> > > I think Iñaki's take on the "oh, you contribute to Github projects so
> > > no problem right?" angle is correct.
> >
> > Let me be sorry, though. That wasn't mean to be a "oh you..." statement.
> It
> > was that other open source projects are not held to this standard, not to
> > "gotcha" Michael or anyone else for their contributions elsewhere.
>
> I mean, held by who? This is a standard we have (more or less) held
> ourselves to. Which, if you think about it, means it's a standard
> that's in our DNA: we're a group of people who *thought it was
> important enough to hold ourselves to that standard*. Would it be
> hypocritical for someone outside of Fedora who happily uses software
> from other projects that are hosted on Github or whatever to criticize
> us if we were to do this? Sure, it would be. But this here is not that,
> it's us holding ourselves to our own standards.
>
> Speaking personally, sure, I contribute to Github-hosted projects. I
> maintain one project on Github (because it's extremely adjacent to
> another project that's hosted on Github and the maintainers of that
> project asked me to have it there, so I did). Hell, I send in fixes for
> entirely proprietary things sometimes...because my overriding itch is,
> if something is there, at least it had better *work* properly. But I
> certainly would not consider hosting work that's a fundamental part of
> Fedora on a proprietary system, I've always seen that as a *complete*
> non-starter - whether we were considering test automation, result
> tracking, event organization, anything like that, the very first rule
> has always been, if it's not open source it's just not on the list at
> all. And as far as I've noticed, that has been the same for all other
> core Fedora stuff, for many years.
>

To add some nuance to stat statement a quite big chunk of the Fedora Infra
apps are hosted on GitHub (https://github.com/fedora-infra), and relatively
critical things like Bodhi, FAS, mirrormanager, . As far as I know most
of Fedora CoreOS (and Silverblue ?) is also on GitHub. A critical part of
our infrastructure the NFS shared storage also run an proprietary software
(NetApp).


>
> So, is it a high standard? Sure. Is it one many other projects don't
> try to meet? Sure. But it's one that, as I see it, we have held for a
> long time and that in itself creates a context and an expectation that
> we can't just dismiss and say "oh, hey, about that? yeah, that doesn't
> matter any more."
> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
> ___
> 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

Re: CPE Git Forge Decision

[Tomasz Torcz]

On Tue, Mar 31, 2020 at 11:34:35AM -0700, Adam Williamson wrote:
> On Tue, 2020-03-31 at 12:55 +0200, Tomasz Torcz wrote:
> > > 
> > > What really worries to me is that:
> > > * using GitLab as SaaS is being considered, and
> > > * for self-hosting, using the proprietary "enterprise" editions is not
> > >   excluded.
> > > 
> > > I think that using anything other than Free Software as the hosting 
> > > platform 
> > > for Fedora should be an absolute no go. In other words, self-hosted 
> > > GitLab 
> > > CE or Pagure, no other options.
> > 
> >   Being self-hosted is a nice goal, but not important enough.
> > There are parts of Fedora infrastructure which are not using Fedora,
> > but other distributions like RHEL.  We seem to have not problem in
> > using proprietary SAAS solutions for critical stuff.
> 
> What 'proprietary SAAS solutions' are we 'using for critical stuff'?

  GitLab Ultimate editon for managing source code of distribution.
We are not using it yet, but it looks very plausible that we will in the
future.


> Bruno explained the RHEL point. To his explanation I'd add, don't
> forget that EPEL is part of Fedora - in fact it's the most widely-used
> thing the Fedora project produces. And we use a lot of EPEL packages on
> the infra systems we (still) have running RHEL and/or CentOS. So this
> is also an important element of dogfooding.

  Personally I'd prefer people wanting to use Fedora packages just
to use Fedora distribution.


-- 
Tomasz TorczOnly gods can safely risk perfection,
to...@pipebreaker.pl it's a dangerous thing for a man.  — Alia
___
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

Re: CPE Git Forge Decision

[Adam Williamson]

On Tue, 2020-03-31 at 20:59 +0200, Clement Verna wrote:
> 
> > The Fedora community itself has indicated that they want to keep on
> > with Pagure, and many Fedorans are Pythonistas, which means that
> > everyone can easily contribute to help make it better for everyone.
> > 
> 
> Genuine question, from the people that have participated in this thread,
> How many could dedicated couple hours a week to work on Pagure ? I think
> many community member are already struggling to keep up with their current
> level of contribution, I am not sure than everyone can easily contribute to
> Pagure. But I am happy to wrong :-).

I could, I've written patches for it before in fact. I would actually
be doing this already except that I knew this process was going on and
didn't want to burn work on it, and it's a little difficult to know
what kind of work I can just jump in and do and expect to be accepted
beyond very straightforward bug fixes. But if there was a co-ordinated
effort around this and I could rely on there being someone I can bounce
"hey, is it OK if I do ?" or "what do we really need to try and get
done right now?" type questions off, I'd certainly be able to find a
couple of hours to do some stuff.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
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

Re: CPE Git Forge Decision

[Chris Murphy]

On Tue, Mar 31, 2020 at 2:37 AM Leigh Griffin  wrote:
>
>
>
> On Mon, Mar 30, 2020 at 10:38 PM Chris Murphy  wrote:
>>
>> On Mon, Mar 30, 2020 at 5:56 AM Leigh Griffin  wrote:
>> >
>> > We haven't ironed out the full details but what was incredibly clear to us 
>> > was that Gitlab was the decision to make. The next step in getting there 
>> > is what we are engaging in now to get thoughts and suggestions and expect 
>> > several threads in that capacity from a technical perspective in the 
>> > coming weeks and months.
>>
>>
>> It is not incredibly clear to the respondents on devel@. I don't care
>> to imagine what stronger disagreement on this particular point looks
>> like.
>
>
> I respect that there is disagreement but Gitlab is the choice we are making.


Why this choice? That's what's not clear. And it's not fair to call
this mere disagreement, because the decision can't even be properly
absorbed. It is prima facie not an open or transparent process, yet is
being claimed to have been. That contradiction is not trust enhancing.



>>
>> On Mon, Mar 30, 2020 at 4:27 AM Iñaki Ucar  wrote:
>> >
>> > I was referring to, and I was expecting, an open conversation about
>> > the User Story list, an open analysis of the requirements list. In
>> > other words:
>> >
>> > 1. Open conversation to gather requirements. Done.
>> > 2. Publication of User Story list.
>> > 3. Open conversation to discuss (2).
>> > 4. Publication of the final decision.
>> >
>> > I was expecting (3), and it's missing.
>>
>>
>> I concur, and don't think the missing piece has been adequately
>> addressed. There's a reason why there's bewilderment at the decision,
>> it's not ignorable.
>
>
> How would you like us to address it more clearly? Fedora has had the 
> publication of its User Story list, a threads worth of discussion on it 
> occured and it was submitted. As have other stakeholder groups. I think the 
> crux here is that we didn't publish the entire stakeholder User Stories for 
> dissemination to each individual stakeholder group. With each group valuing 
> something different, as is obvious from the discussion around individual 
> requirements that has occured in several threads here, we didn't feel the 
> value would have been there. That's on me for not looping the comms back in 
> and I apologise for that.
>
>>
>> Were there deliberations by CPE Team in between (2) and (4)?
>
> Yes, several hundred person hours worth of analysis, meetings and dissecting 
> the requirements.

It would be addressed more clearly by seeing the summary,
distillation, metric, method, by which those hundreds of hours were
turned into the decision.

These entire threads are a verbose way of saying "show your work."

>
>>
>> Is there
>> a record of those deliberations?
>
>
> No, they were mostly video calls / in person meetings and the result is the 
> User Story list and decision document for sharing.

I think a summary of the first hour of these several hundred hours,
and the last hour, would be useful. There's no way to reconstruct
this? Deliberative bodies should be keeping notes, summary of major
decisions, pros, cons, liabilities, prioritization of conflicting
requirements, what things are in and out of scope, etc. There must be
something to show.


-- 
Chris Murphy
___
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

Re: CPE Git Forge Decision

[Clement Verna]

On Tue, 31 Mar 2020 at 14:57, Neal Gompa  wrote:

> On Tue, Mar 31, 2020 at 7:10 AM Clement Verna 
> wrote:
> >
> > I just want to give a bit of insight from someone who is working day to
> day on Fedora's infrastructure, since I believe that might help give a bit
> more empathy towards the Why of this decision.
> >
> > For me the Fedora's Infrastructure is in a very bad shape there is a
> fair load of technical debt and trying to change or improve anything
> results in a long list of reason why we can do it because services X
> depends on service Y which depends on Z.  Since I joined the CPE team
> (little bit more than 2 years ago) we have not been able to make any kind
> of significant progress towards fighting this technical debt. Every year we
> fill a white board with what needs to be done :
> >
> > Python 3 apps migration,
> > FAS replacement,
> > fedmsg retirement,
> > FMN replacement,
> > Fedora-packages replacement,
> > PDC replacement,
> > Porting application to OIDC,
> > Improve Releng automation,
> > Improving Anitya and the-new-hotness,
> > .
> >
> > Every single year the same items are coming back because we spend most
> of our time firefighting services to keep users happy and keep Fedora
> release schedule. This has a very demoralizing effect on the people working
> in the team, it seems like we will never be able to make any significant
> improvement, and our day to day job is to close couple tickets and you keep
> watching the pile of tickets growing. There is no feeling of accomplishment
> and a general sentiment that whatever we do, it will suck.
> >
> > A little over a year ago we have expressed our need to drop
> applications, this is something we have to do to be able to stay sane and
> keep a sustainable life-work balance. From that effort to handover
> applications (Elections, Nuancier, Fedocal, Badges) to another group of
> people in the community, not much happened mainly because of GDPR and the
> legal responsibility of owning such applications, but as far as I know we
> don't do much maintenance work on these applications any more since we now
> have a few volunteers that are looking after them or helping with finding
> an alternative solution.
> >
> > Now on the list of application we develop and run, I think Pagure is
> logical candidate to try and find an alternative to it, but before doing
> this it was important to make sure we captured all the use case and feature
> needed from a git forge and see if any of these justified spending cycles
> in development and maintenance work. My understanding of the decision is
> that Pagure does not provide any significant advantage over GitLab. I know
> that for many, the fact that Pagure is developed by Fedora is an advantage,
> but from my perspective as someone that as to deal with all the other
> services in Fedora's Infra this is a major disadvantage.
> >
> > Overall I think it is important to keep in mind that there is a lot of
> work happening behind the scene to provide the people in the Fedora
> community a good experience contributing to Fedora. I think we are doing a
> good job at it, but that takes us an enormous effort and over the long term
> this is not sustainable, also keeping in mind that we keep adding and want
> to keep adding new things to Fedora.
> >
> > I hope that my perspective helps a little.
> >
>
> Clement,
>
> I want to say thank you for all the hard work you do as a member of
> the Fedora community and as a member of the CPE team. You've done
> fantastic work for the community and it's always a pleasure to work
> with you. And that goes for all the members of the CPE team. I totally
> understand where you are coming from. And it *is* very demoralizing to
> see the same things over and over again, looking as if you've made no
> progress on these things. I've been there with my work at $DAYJOB
> before, many times. And as you and others are aware, I've been poking
> around throughout infrastructure projects to help with some of these
> initiatives over the years, so I'm keenly aware of the size and scope
> of many of these.
>
> However, I think some of this is self-inflicted. I don't want to
> entirely rehash my original email with my thoughts on this, so please
> read that for more detail[1], but I think we *really* should consider
> that the lack of community exposure to to the codebases themselves
> (especially as an avenue for contributing to the Fedora Project!) is
> an underlying problem here. This has created a persistent cycle of
> "community member makes cool project to support Fedora" → "it gets
> adopted silently and no one really talks about it or advertises it" →
> "nobody knows about it and the community member is the only one
> working on it" → "the community member burns out and it gets piled
> onto Fedora Engineering/CPE to maintain". This is basically how CPE
> team got >100 codebases.
>

I agree with that, but for me there also a bit of a chicken and egg
problem. I think we don't 

Re: CPE Git Forge Decision

[Kevin Fenzi]

On Tue, Mar 31, 2020 at 12:40:55PM -0500, Bruno Wolff III wrote:
...snip...
> 
> Because of switching costs, this is likely to prevent us from going back to
> Pagure if it does develop a vibrant independent community. That would be
> unfortunate.

So, currently we are using pagure on src.fedoraproject.org, but it's not
just pagure, it's a integration layer over the top of pagure too. 

I'd like to see if we can, as part of this: a) adjust our packaging
workflow (as many threads on this list have talked about) and b) after
that, try and reduce that integration layer as much as we can and c)
hopefully make it so we could move the backend git repos / forge later
if we wanted to without recreating a big integration layer.

As part of that we could also provide whats needed for the integration
and the pagure community could add anything they don't already have on
their roadmap. 

kevin 


signature.asc
Description: PGP signature
___
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

Re: CPE Git Forge Decision

[Chris Murphy]

On Tue, Mar 31, 2020 at 11:45 AM Adam Williamson
 wrote:
>
> On Tue, 2020-03-31 at 13:08 -0400, Matthew Miller wrote:
> > On Tue, Mar 31, 2020 at 10:48:55AM -0500, Michael Catanzaro wrote:
> > > Some failure of process or communication must have occurred
> > > somewhere along the lines, because open source should have been the
> > > first and most important requirement. A proprietary software
> > > solution is incompatible with the ethos and purpose of the Fedora
> > > project. I ask CPE to revise its requirements list to include open
> > > source as the first and most important requirement from the Fedora
> > > community. If that's incompatible with CentOS's need for merge
> > > request approvals or whatever else, then we need to accept that
> > > sharing the same forge is simply not going to work.
> >
> > Obviously open source is one of our key foundations. And it is part of who
> > we are even before those foundations were drafted. Nonetheless, I want to
> > gently discuss this a little bit. We make an entirely open source and free
> > software operating system. We support and promote and advocate for open
> > source and free content. But we can't do everything, and at some point, this
> > becomes "this is why we can't have nice things". I see that you've made
> > contributions to other open source projects on GitHub and (hosted) GitLab
> > this month. Lots of Fedora contributors have and will continue to do so.
> > Many use that as their main hosting. It's not ideal, but it's not the end of
> > the world. I don't see Fedora making use of non-open hosted services as the
> > end of the world either, if that is what is best for us.
> >
> > We did communicate as the very top line of our gathered requirements that
> > open source is essential to our community and central to our feedback. I'm
> > not trying to be soft on that. Let's just not do purity-test level
> > assessments and instead focus on our goals.
>
> I'm sorry, but I have to agree with Kevin and Michael here to a
> significant extent. Running our own project on open source code has
> always been a very big bright line for Fedora.
>
> I'm not necessarily saying it's a hill we should die on, but at the
> very least, choosing a proprietary hosted solution for something as
> fundamental as our dist-git needs to be treated as a Very Big Deal and
> needs to be a decision that is handled a *lot* better than this one has
> been handled.
>
> You said in another email that the tooling choice ultimately has to be
> largely made by the team that is responsible for the work and it
> wouldn't really work for Council to order them to do something they
> can't practically do, and I see the truth in that, but at the same time
> I think there has to be a balance there. Does this "the team decides
> what works for them" principle extend as far as the team being able to
> choose unilaterally to go against principles Fedora has been working
> very hard to maintain for about as long as it has existed, and that are
> listed right up there front and centre as our Foundations? That, to me,
> seems like a decision that Council ought at the very least to be deeply
> involved in - much more than seems to have been the case here (which
> seems to have been that we wrote up some requirements and sent them off
> to "the team", which smooshed them into some kind of summary and then
> made a decision - a decision which seems to have had a rather confused
> context, as various people don't seem to be on the same page about
> whether a choice was supposed to be made about "dist-git", or
> "pagure.io", or "Pagure", or CentOS's or Red Hat's use of Pagure, or
> any or all of these things somehow smooshed together).
>
> I think if I turned up tomorrow and said that QA had decided we're
> going to use a proprietary hosted service for managing release
> validation testing there would be significant pushback against that,
> and I think that pushback would be valid, and I'm not sure it would be
> appropriate for us to say "tough, we made that decision so that's
> what's happening". I don't think it's necessarily appropriate for that
> to happen here either.
>
> I understand there are practical resource considerations and so on
> here, but I still think this merits more high level and serious
> consideration. At the very least, if we have somehow reached a point
> where Red Hat is no longer willing to provide sufficient resources to
> run Fedora on the lines the Fedora community wants it to be run, we
> need to recognize that this is a significant problem that needs to be
> properly aired and discussed and resolved. In this context I'll note
> that the apparent significant headcount reduction of RH people working
> on Fedora infrastructure over the last few years is in itself a
> worrying trend, particularly if you consider it while reading Clement's
> email.
>
> I think Iñaki's take on the "oh, you contribute to Github projects so
> no problem right?" angle is correct.

I concur with 

Re: CPE Git Forge Decision

[Adam Williamson]

On Tue, 2020-03-31 at 12:55 +0200, Tomasz Torcz wrote:
> On Tue, Mar 31, 2020 at 12:42:18PM +0200, Kevin Kofler wrote:
> > Leigh Griffin wrote:
> > > Thank you for your patience while the CPE Team worked through an
> > > incredible number of requirements from multiple stakeholder sources. On
> > > Friday evening we announced on the Community Blog
> > >  our
> > > decision to adopt Gitlab as our Git Forge and to retain pagure.io to
> > > ultimately hand over to the Community to maintain. It wasn't an easy
> > > decision by any stretch of the imagination and we hope that the compromise
> > > that we are striking will help to allow Pagure flourish and to give a
> > > choice of Forges for your usage. I'm happy to field any questions or
> > > comments about this decision.
> > 
> > What really worries to me is that:
> > * using GitLab as SaaS is being considered, and
> > * for self-hosting, using the proprietary "enterprise" editions is not
> >   excluded.
> > 
> > I think that using anything other than Free Software as the hosting 
> > platform 
> > for Fedora should be an absolute no go. In other words, self-hosted GitLab 
> > CE or Pagure, no other options.
> 
>   Being self-hosted is a nice goal, but not important enough.
> There are parts of Fedora infrastructure which are not using Fedora,
> but other distributions like RHEL.  We seem to have not problem in
> using proprietary SAAS solutions for critical stuff.

What 'proprietary SAAS solutions' are we 'using for critical stuff'?

Bruno explained the RHEL point. To his explanation I'd add, don't
forget that EPEL is part of Fedora - in fact it's the most widely-used
thing the Fedora project produces. And we use a lot of EPEL packages on
the infra systems we (still) have running RHEL and/or CentOS. So this
is also an important element of dogfooding.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
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

Re: CPE Git Forge Decision

[Adam Williamson]

On Tue, 2020-03-31 at 13:55 -0400, Matthew Miller wrote:
> On Tue, Mar 31, 2020 at 10:44:35AM -0700, Adam Williamson wrote:
> > I'm sorry, but I have to agree with Kevin and Michael here to a
> > significant extent. Running our own project on open source code has
> > always been a very big bright line for Fedora.
> 
> You don't have to be sorry! I think it's very clear that this is the general
> community view.
> 
> > I think Iñaki's take on the "oh, you contribute to Github projects so
> > no problem right?" angle is correct.
> 
> Let me be sorry, though. That wasn't mean to be a "oh you..." statement. It
> was that other open source projects are not held to this standard, not to
> "gotcha" Michael or anyone else for their contributions elsewhere.

I mean, held by who? This is a standard we have (more or less) held
ourselves to. Which, if you think about it, means it's a standard
that's in our DNA: we're a group of people who *thought it was
important enough to hold ourselves to that standard*. Would it be
hypocritical for someone outside of Fedora who happily uses software
from other projects that are hosted on Github or whatever to criticize
us if we were to do this? Sure, it would be. But this here is not that,
it's us holding ourselves to our own standards.

Speaking personally, sure, I contribute to Github-hosted projects. I
maintain one project on Github (because it's extremely adjacent to
another project that's hosted on Github and the maintainers of that
project asked me to have it there, so I did). Hell, I send in fixes for
entirely proprietary things sometimes...because my overriding itch is,
if something is there, at least it had better *work* properly. But I
certainly would not consider hosting work that's a fundamental part of
Fedora on a proprietary system, I've always seen that as a *complete*
non-starter - whether we were considering test automation, result
tracking, event organization, anything like that, the very first rule
has always been, if it's not open source it's just not on the list at
all. And as far as I've noticed, that has been the same for all other
core Fedora stuff, for many years.

So, is it a high standard? Sure. Is it one many other projects don't
try to meet? Sure. But it's one that, as I see it, we have held for a
long time and that in itself creates a context and an expectation that
we can't just dismiss and say "oh, hey, about that? yeah, that doesn't
matter any more."
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
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

Re: CPE Git Forge Decision

[Bruno Wolff III]

On Tue, Mar 31, 2020 at 13:08:05 -0400,
 Matthew Miller  wrote:


We did communicate as the very top line of our gathered requirements that
open source is essential to our community and central to our feedback. I'm
not trying to be soft on that. Let's just not do purity-test level
assessments and instead focus on our goals.


The response from CPE made it sound like they just counted requirements 
rather than evalutating how important each requirement was to each group. 
Perhaps that was not intended, but that's they way it sounds. I think that 
being able to theorectically switch from hosted to self-hosted in short 
order (like in a month), should have been a deal breaking requirement from 
Fedora in case something at Gitlab changed that prevented using their 
hosted service. That implies having access to the source (capable of running 
our instance) with a free license and regular exports of the data in our 
hands. It doesn't sound like that is a requirement from the response 
provided by CPE.


Because of switching costs, this is likely to prevent us from going back 
to Pagure if it does develop a vibrant independent community. That would 
be unfortunate.

___
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

Re: CPE Git Forge Decision

[Matthew Miller]

On Tue, Mar 31, 2020 at 10:44:35AM -0700, Adam Williamson wrote:
> I'm sorry, but I have to agree with Kevin and Michael here to a
> significant extent. Running our own project on open source code has
> always been a very big bright line for Fedora.

You don't have to be sorry! I think it's very clear that this is the general
community view.

> I think Iñaki's take on the "oh, you contribute to Github projects so
> no problem right?" angle is correct.

Let me be sorry, though. That wasn't mean to be a "oh you..." statement. It
was that other open source projects are not held to this standard, not to
"gotcha" Michael or anyone else for their contributions elsewhere.


-- 
Matthew Miller

Fedora Project Leader
___
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

Re: CPE Git Forge Decision

[Matthew Miller]

On Tue, Mar 31, 2020 at 10:31:21AM -0700, Adam Williamson wrote:
> I specifically mentioned at least the FSF angle on this mailing list,
> over a month ago:
> 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/EJAKU3MO4T5ZEWEBUWIRSGBWTFQU44QK/
> 
> so at least that part certainly *should* have been, if we assume it's
> reasonable to expect those making this decision to be paying attention
> to this list.

I did forward that on to Leigh and Jim.

-- 
Matthew Miller

Fedora Project Leader
___
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

Re: CPE Git Forge Decision

[Matthew Miller]

On Tue, Mar 31, 2020 at 07:30:16PM +0200, Iñaki Ucar wrote:
> That's a false equivalence. Yes, many of us maintain projects on
> GitHub and/or GitLab due to a variety of reasons, but if any of them
> die tomorrow, I simply change the "upstream" in my clones and keep
> going. If Fedora starts using GitLab EE for its dist-git, for example,
> and GitLab dies tomorrow, then we have a very big problem.

Bigger scale, but isn't it basically the same problem?


-- 
Matthew Miller

Fedora Project Leader
___
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

Re: CPE Git Forge Decision

[Adam Williamson]

On Tue, 2020-03-31 at 13:08 -0400, Matthew Miller wrote:
> On Tue, Mar 31, 2020 at 10:48:55AM -0500, Michael Catanzaro wrote:
> > Some failure of process or communication must have occurred
> > somewhere along the lines, because open source should have been the
> > first and most important requirement. A proprietary software
> > solution is incompatible with the ethos and purpose of the Fedora
> > project. I ask CPE to revise its requirements list to include open
> > source as the first and most important requirement from the Fedora
> > community. If that's incompatible with CentOS's need for merge
> > request approvals or whatever else, then we need to accept that
> > sharing the same forge is simply not going to work.
> 
> Obviously open source is one of our key foundations. And it is part of who
> we are even before those foundations were drafted. Nonetheless, I want to
> gently discuss this a little bit. We make an entirely open source and free
> software operating system. We support and promote and advocate for open
> source and free content. But we can't do everything, and at some point, this
> becomes "this is why we can't have nice things". I see that you've made
> contributions to other open source projects on GitHub and (hosted) GitLab
> this month. Lots of Fedora contributors have and will continue to do so.
> Many use that as their main hosting. It's not ideal, but it's not the end of
> the world. I don't see Fedora making use of non-open hosted services as the
> end of the world either, if that is what is best for us.
> 
> We did communicate as the very top line of our gathered requirements that
> open source is essential to our community and central to our feedback. I'm
> not trying to be soft on that. Let's just not do purity-test level
> assessments and instead focus on our goals.

I'm sorry, but I have to agree with Kevin and Michael here to a
significant extent. Running our own project on open source code has
always been a very big bright line for Fedora.

I'm not necessarily saying it's a hill we should die on, but at the
very least, choosing a proprietary hosted solution for something as
fundamental as our dist-git needs to be treated as a Very Big Deal and
needs to be a decision that is handled a *lot* better than this one has
been handled.

You said in another email that the tooling choice ultimately has to be
largely made by the team that is responsible for the work and it
wouldn't really work for Council to order them to do something they
can't practically do, and I see the truth in that, but at the same time
I think there has to be a balance there. Does this "the team decides
what works for them" principle extend as far as the team being able to
choose unilaterally to go against principles Fedora has been working
very hard to maintain for about as long as it has existed, and that are
listed right up there front and centre as our Foundations? That, to me,
seems like a decision that Council ought at the very least to be deeply
involved in - much more than seems to have been the case here (which
seems to have been that we wrote up some requirements and sent them off
to "the team", which smooshed them into some kind of summary and then
made a decision - a decision which seems to have had a rather confused
context, as various people don't seem to be on the same page about
whether a choice was supposed to be made about "dist-git", or
"pagure.io", or "Pagure", or CentOS's or Red Hat's use of Pagure, or
any or all of these things somehow smooshed together).

I think if I turned up tomorrow and said that QA had decided we're
going to use a proprietary hosted service for managing release
validation testing there would be significant pushback against that,
and I think that pushback would be valid, and I'm not sure it would be
appropriate for us to say "tough, we made that decision so that's
what's happening". I don't think it's necessarily appropriate for that
to happen here either.

I understand there are practical resource considerations and so on
here, but I still think this merits more high level and serious
consideration. At the very least, if we have somehow reached a point
where Red Hat is no longer willing to provide sufficient resources to
run Fedora on the lines the Fedora community wants it to be run, we
need to recognize that this is a significant problem that needs to be
properly aired and discussed and resolved. In this context I'll note
that the apparent significant headcount reduction of RH people working
on Fedora infrastructure over the last few years is in itself a
worrying trend, particularly if you consider it while reading Clement's
email.

I think Iñaki's take on the "oh, you contribute to Github projects so
no problem right?" angle is correct.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- 

Re: CPE Git Forge Decision

[Adam Williamson]

On Tue, 2020-03-31 at 17:47 +0200, jkone...@redhat.com wrote:
> -- snip --
> > As for Pagure itself, I think this is where we fundamentally
> > disagree.
> > I think it behooves us to own and provide an experience tailored for
> > our community from beginning to end. That's why we have Koji, Bodhi,
> > Dist-Git, and many other tools in that part of the lifecycle. The
> > packager experience is literally the lifeblood of the project, and
> > our
> > contributors are the core of what makes Fedora successful. Pagure
> > gives us an opportunity to do right by them that I *really* don't
> > think we can do with any alternatives.
> > 
> > That does *not* mean that CPE team should be the sole owner of the
> > Pagure *codebase*. On that point, I agree. And that's why I've spent
> > a
> > lot of time and energy since late 2018 working on building up that
> > community. It's finally starting to bear fruit too: there's at least
> > one entity interested in building a product around it and
> > contributing
> > to help support that product, there's the FSF preparing to launch a
> > new forge using Pagure, there's the Trisquel GNU+Linux distribution
> > working on a Pagure deployment to host their code and packaging, and
> > there's a few other things I've got up my sleeve to help broaden the
> > community with not just users, but also contributors.
> 
> It's great to hear this. Thanks a lot Neal for trying to find
> consumers. I'm not sure if this information was available to Fedora
> infrastructure during the decision. It means that we may have another
> contributors.

I specifically mentioned at least the FSF angle on this mailing list,
over a month ago:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/EJAKU3MO4T5ZEWEBUWIRSGBWTFQU44QK/

so at least that part certainly *should* have been, if we assume it's
reasonable to expect those making this decision to be paying attention
to this list.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
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

Re: CPE Git Forge Decision

[Iñaki Ucar]

On Tue, 31 Mar 2020 at 19:15, Matthew Miller  wrote:
>
> On Tue, Mar 31, 2020 at 10:48:55AM -0500, Michael Catanzaro wrote:
> > Some failure of process or communication must have occurred
> > somewhere along the lines, because open source should have been the
> > first and most important requirement. A proprietary software
> > solution is incompatible with the ethos and purpose of the Fedora
> > project. I ask CPE to revise its requirements list to include open
> > source as the first and most important requirement from the Fedora
> > community. If that's incompatible with CentOS's need for merge
> > request approvals or whatever else, then we need to accept that
> > sharing the same forge is simply not going to work.
>
> Obviously open source is one of our key foundations. And it is part of who
> we are even before those foundations were drafted. Nonetheless, I want to
> gently discuss this a little bit. We make an entirely open source and free
> software operating system. We support and promote and advocate for open
> source and free content. But we can't do everything, and at some point, this
> becomes "this is why we can't have nice things". I see that you've made
> contributions to other open source projects on GitHub and (hosted) GitLab
> this month. Lots of Fedora contributors have and will continue to do so.
> Many use that as their main hosting. It's not ideal, but it's not the end of
> the world. I don't see Fedora making use of non-open hosted services as the
> end of the world either, if that is what is best for us.

That's a false equivalence. Yes, many of us maintain projects on
GitHub and/or GitLab due to a variety of reasons, but if any of them
die tomorrow, I simply change the "upstream" in my clones and keep
going. If Fedora starts using GitLab EE for its dist-git, for example,
and GitLab dies tomorrow, then we have a very big problem.

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

Re: CPE Git Forge Decision

[Matthew Miller]

On Tue, Mar 31, 2020 at 10:48:55AM -0500, Michael Catanzaro wrote:
> Some failure of process or communication must have occurred
> somewhere along the lines, because open source should have been the
> first and most important requirement. A proprietary software
> solution is incompatible with the ethos and purpose of the Fedora
> project. I ask CPE to revise its requirements list to include open
> source as the first and most important requirement from the Fedora
> community. If that's incompatible with CentOS's need for merge
> request approvals or whatever else, then we need to accept that
> sharing the same forge is simply not going to work.

Obviously open source is one of our key foundations. And it is part of who
we are even before those foundations were drafted. Nonetheless, I want to
gently discuss this a little bit. We make an entirely open source and free
software operating system. We support and promote and advocate for open
source and free content. But we can't do everything, and at some point, this
becomes "this is why we can't have nice things". I see that you've made
contributions to other open source projects on GitHub and (hosted) GitLab
this month. Lots of Fedora contributors have and will continue to do so.
Many use that as their main hosting. It's not ideal, but it's not the end of
the world. I don't see Fedora making use of non-open hosted services as the
end of the world either, if that is what is best for us.

We did communicate as the very top line of our gathered requirements that
open source is essential to our community and central to our feedback. I'm
not trying to be soft on that. Let's just not do purity-test level
assessments and instead focus on our goals.



-- 
Matthew Miller

Fedora Project Leader
___
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

Re: CPE Git Forge Decision

[Michael Catanzaro]

On Tue, Mar 31, 2020 at 12:42 pm, Kevin Kofler  
wrote:

What really worries to me is that:
* using GitLab as SaaS is being considered, and
* for self-hosting, using the proprietary "enterprise" editions is not
  excluded.

I think that using anything other than Free Software as the hosting 
platform
for Fedora should be an absolute no go. In other words, self-hosted 
GitLab

CE or Pagure, no other options.


Very rare for me to say this, but: I agree with Kevin.

As I see it, the Fedora community was not interested in GitHub because 
it's not open source. It seemed like we all agreed on that, and I 
assume Council communicated that to CPE. Now, GitLab Community Edition 
(GitLab CE) is open source (and high-quality), but it seems almost 
certain that the plan is to use GitLab Enterprise Edition (GitLab EE). 
Although CPE says they continue to evaluate which edition will used and 
how it will be hosted, the identified requirements clearly cannot be 
satisfied by GitLab CE.


Some failure of process or communication must have occurred somewhere 
along the lines, because open source should have been the first and 
most important requirement. A proprietary software solution is 
incompatible with the ethos and purpose of the Fedora project. I ask 
CPE to revise its requirements list to include open source as the first 
and most important requirement from the Fedora community. If that's 
incompatible with CentOS's need for merge request approvals or whatever 
else, then we need to accept that sharing the same forge is simply not 
going to work.


If open source is really not going to be a requirement, then we can ask 
Council to politely reject CPE's offer to continue hosting our forge, 
and instead round up some budget to keep Pagure running without help 
from CPE.


Michael

___
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

Re: CPE Git Forge Decision

[jkonecny]

-- snip --
> 
> As for Pagure itself, I think this is where we fundamentally
> disagree.
> I think it behooves us to own and provide an experience tailored for
> our community from beginning to end. That's why we have Koji, Bodhi,
> Dist-Git, and many other tools in that part of the lifecycle. The
> packager experience is literally the lifeblood of the project, and
> our
> contributors are the core of what makes Fedora successful. Pagure
> gives us an opportunity to do right by them that I *really* don't
> think we can do with any alternatives.
> 
> That does *not* mean that CPE team should be the sole owner of the
> Pagure *codebase*. On that point, I agree. And that's why I've spent
> a
> lot of time and energy since late 2018 working on building up that
> community. It's finally starting to bear fruit too: there's at least
> one entity interested in building a product around it and
> contributing
> to help support that product, there's the FSF preparing to launch a
> new forge using Pagure, there's the Trisquel GNU+Linux distribution
> working on a Pagure deployment to host their code and packaging, and
> there's a few other things I've got up my sleeve to help broaden the
> community with not just users, but also contributors.

It's great to hear this. Thanks a lot Neal for trying to find
consumers. I'm not sure if this information was available to Fedora
infrastructure during the decision. It means that we may have another
contributors.

I think Fedora Infra should talk to these potential contributors to
find out how much they are willing to contribute to Pagure and re-think 
the decision based on that. It's big difference if this is just a
Fedora tool or if it is used and developed by others too.

Jirka

> 
> Are there deficiencies in Pagure? Of course there are. I'm not
> claiming that Pagure is perfect. But I think that keeping on with
> Pagure and giving that community an opportunity to close the gap on
> needed features for Fedora/CentOS/Red Hat is the right way to go.
> Right now, I don't *know* what the important gaps are. I can make
> some
> guesses, but it'd be a lot better if we had a list of missing
> features
> and their relative important and why. That would help focus
> development to meet those needs.
> 
> The Fedora community itself has indicated that they want to keep on
> with Pagure, and many Fedorans are Pythonistas, which means that
> everyone can easily contribute to help make it better for everyone.
> 
> Anyway, I hope this helps clarify my position on the matter!
> 
> [1]: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/Y5XXXHJCSDMOHA7FEZ3DNZYPGCTZBVH6/
> 
> 
> 
> 
> -- 
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> 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

Re: CPE Git Forge Decision

[jkonecny]

On Tue, 2020-03-31 at 12:47 +0200, Felix Schwarz wrote:
> Am 31.03.20 um 12:42 schrieb Kevin Kofler:
> > I think that using anything other than Free Software as the hosting
> > platform 
> > for Fedora should be an absolute no go. In other words, self-hosted 
> > GitLab 
> > CE or Pagure, no other options.
> 
> +1 with one minor(?) exception:
> I'm ok with using a hosted version provided that the software (and
> its
> dependencies) is part of the Fedora repos and there are provisions to
> extract
> the data (e.g. database) from the hosted version without any data
> loss and
> load it in a self-hosted version using Fedora RPMs.

+1 from me too. We really should not use proprietary for Fedora. It's
similar to use Windows machines to build Linux kernel.


> 
> Felix
> ___
> 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

Re: CPE Git Forge Decision

[Neal Gompa]

On Tue, Mar 31, 2020 at 10:37 AM Bruno Wolff III  wrote:
>
> On Tue, Mar 31, 2020 at 12:55:39 +0200,
>   Tomasz Torcz  wrote:
> >
> >  Being self-hosted is a nice goal, but not important enough.
> >There are parts of Fedora infrastructure which are not using Fedora,
> >but other distributions like RHEL.  We seem to have not problem in
> >using proprietary SAAS solutions for critical stuff.
>
> RHEL is a special case, as CENTOS provides a free drop in replacement and
> switching from CENTOS to Fedora shouldn't be much work. Is there other
> proprietary software at the OS level or above, that is used for Fedora
> infrastructure?
>

The only part of Fedora Infrastructure itself that is proprietary (to
the best of my knowledge) is the NetApp storage appliances that have
been in place since Koji was deployed back in 2007. I think if we were
to do this all over again today, we would be using Gluster or Ceph,
but it's a ton of work for no gain to change storage stuff right now.

The change to SaaS GitLab will make a user-facing visible change to a
proprietary solution for the core of the distribution. And even
ignoring that, I sincerely think the user experience will be much
worse with almost no avenue to fix it.

> >  I truly envy Debian and their ability to dogfood, running their
> >infra on Debian. With minor exception: although they self-host GitLab,
> >it seems to be different than their distribution packages.
>
> I think the difference is the support window for Fedora. In a way CENTOS
> is an LTS version of Fedora.

Over the years, more of Fedora Infrastructure has migrated from RHEL
to Fedora because RHEL doesn't work out very well for some of our
infrastructure.

For example, all the Koji builders are on Fedora, as is Bodhi. While
it is true that RHEL/CentOS can be considered somewhat as an LTS of
Fedora, it's not an equivalent distribution. Red Hat makes different
choices and cuts down what's available dramatically. The discussion
about ELN pushes that distinction to the forefront.




--
真実はいつも一つ！/ Always, there's only one truth!
___
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

Re: CPE Git Forge Decision

[Bruno Wolff III]

On Tue, Mar 31, 2020 at 12:55:39 +0200,
 Tomasz Torcz  wrote:


 Being self-hosted is a nice goal, but not important enough.
There are parts of Fedora infrastructure which are not using Fedora,
but other distributions like RHEL.  We seem to have not problem in
using proprietary SAAS solutions for critical stuff.


RHEL is a special case, as CENTOS provides a free drop in replacement and 
switching from CENTOS to Fedora shouldn't be much work. Is there other 
proprietary software at the OS level or above, that is used for Fedora 
infrastructure?



 I truly envy Debian and their ability to dogfood, running their
infra on Debian. With minor exception: although they self-host GitLab,
it seems to be different than their distribution packages.


I think the difference is the support window for Fedora. In a way CENTOS 
is an LTS version of Fedora.

___
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

Re: CPE Git Forge Decision

[Neal Gompa]

On Tue, Mar 31, 2020 at 7:10 AM Clement Verna  wrote:
>
> I just want to give a bit of insight from someone who is working day to day 
> on Fedora's infrastructure, since I believe that might help give a bit more 
> empathy towards the Why of this decision.
>
> For me the Fedora's Infrastructure is in a very bad shape there is a fair 
> load of technical debt and trying to change or improve anything results in a 
> long list of reason why we can do it because services X depends on service Y 
> which depends on Z.  Since I joined the CPE team (little bit more than 2 
> years ago) we have not been able to make any kind of significant progress 
> towards fighting this technical debt. Every year we fill a white board with 
> what needs to be done :
>
> Python 3 apps migration,
> FAS replacement,
> fedmsg retirement,
> FMN replacement,
> Fedora-packages replacement,
> PDC replacement,
> Porting application to OIDC,
> Improve Releng automation,
> Improving Anitya and the-new-hotness,
> .
>
> Every single year the same items are coming back because we spend most of our 
> time firefighting services to keep users happy and keep Fedora release 
> schedule. This has a very demoralizing effect on the people working in the 
> team, it seems like we will never be able to make any significant 
> improvement, and our day to day job is to close couple tickets and you keep 
> watching the pile of tickets growing. There is no feeling of accomplishment 
> and a general sentiment that whatever we do, it will suck.
>
> A little over a year ago we have expressed our need to drop applications, 
> this is something we have to do to be able to stay sane and keep a 
> sustainable life-work balance. From that effort to handover applications 
> (Elections, Nuancier, Fedocal, Badges) to another group of people in the 
> community, not much happened mainly because of GDPR and the legal 
> responsibility of owning such applications, but as far as I know we don't do 
> much maintenance work on these applications any more since we now have a few 
> volunteers that are looking after them or helping with finding an alternative 
> solution.
>
> Now on the list of application we develop and run, I think Pagure is logical 
> candidate to try and find an alternative to it, but before doing this it was 
> important to make sure we captured all the use case and feature needed from a 
> git forge and see if any of these justified spending cycles in development 
> and maintenance work. My understanding of the decision is that Pagure does 
> not provide any significant advantage over GitLab. I know that for many, the 
> fact that Pagure is developed by Fedora is an advantage, but from my 
> perspective as someone that as to deal with all the other services in 
> Fedora's Infra this is a major disadvantage.
>
> Overall I think it is important to keep in mind that there is a lot of work 
> happening behind the scene to provide the people in the Fedora community a 
> good experience contributing to Fedora. I think we are doing a good job at 
> it, but that takes us an enormous effort and over the long term this is not 
> sustainable, also keeping in mind that we keep adding and want to keep adding 
> new things to Fedora.
>
> I hope that my perspective helps a little.
>

Clement,

I want to say thank you for all the hard work you do as a member of
the Fedora community and as a member of the CPE team. You've done
fantastic work for the community and it's always a pleasure to work
with you. And that goes for all the members of the CPE team. I totally
understand where you are coming from. And it *is* very demoralizing to
see the same things over and over again, looking as if you've made no
progress on these things. I've been there with my work at $DAYJOB
before, many times. And as you and others are aware, I've been poking
around throughout infrastructure projects to help with some of these
initiatives over the years, so I'm keenly aware of the size and scope
of many of these.

However, I think some of this is self-inflicted. I don't want to
entirely rehash my original email with my thoughts on this, so please
read that for more detail[1], but I think we *really* should consider
that the lack of community exposure to to the codebases themselves
(especially as an avenue for contributing to the Fedora Project!) is
an underlying problem here. This has created a persistent cycle of
"community member makes cool project to support Fedora" → "it gets
adopted silently and no one really talks about it or advertises it" →
"nobody knows about it and the community member is the only one
working on it" → "the community member burns out and it gets piled
onto Fedora Engineering/CPE to maintain". This is basically how CPE
team got >100 codebases.

This is a cycle that I've been *trying* to break. I'll be the first to
admit that I'm not the greatest programmer in the world, but I try to
contribute in terms of code, code reviews, testing, etc. But one thing
I've been 

Re: CPE Git Forge Decision

[Guido Aulisi]

Il giorno mar, 31/03/2020 alle 12.42 +0200, Kevin Kofler ha scritto:
> Leigh Griffin wrote:
> > Thank you for your patience while the CPE Team worked through an
> > incredible number of requirements from multiple stakeholder
> > sources. On
> > Friday evening we announced on the Community Blog
> > <
> > https://communityblog.fedoraproject.org/making-a-git-forge-decision/
> > > our
> > decision to adopt Gitlab as our Git Forge and to retain pagure.io
> > to
> > ultimately hand over to the Community to maintain. It wasn't an
> > easy
> > decision by any stretch of the imagination and we hope that the
> > compromise
> > that we are striking will help to allow Pagure flourish and to give
> > a
> > choice of Forges for your usage. I'm happy to field any questions
> > or
> > comments about this decision.
> 
> What really worries to me is that:
> * using GitLab as SaaS is being considered, and
> * for self-hosting, using the proprietary "enterprise" editions is
> not
>   excluded.
> 
> I think that using anything other than Free Software as the hosting
> platform 
> for Fedora should be an absolute no go. In other words, self-hosted
> GitLab 
> CE or Pagure, no other options.
> 
> Kevin Kofler

I totally agree with Kevin +1.

Guido Aulisi


signature.asc
Description: This is a digitally signed message part
___
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

Re: CPE Git Forge Decision

[Clement Verna]

On Tue, 31 Mar 2020 at 13:46, Miro Hrončok  wrote:

> On 31. 03. 20 13:09, Clement Verna wrote:
> > On Tue, 31 Mar 2020 at 11:41, Miro Hrončok  > > wrote:
> >
> > On 31. 03. 20 10:36, Leigh Griffin wrote:
> >  > I respect that there is disagreement but Gitlab is the choice we
> are making.
> >
> > I always try to assume good intentions, but this is very hard now. I
> understand
> > this statement as follows:
> >
> > "After collecting the requirements, we have not discussed the
> decision with the
> > Fedora community, it was discussed in private. We have decided for
> Gitlab and
> > only once we have already decided, we have announced our decision to
> Fedora.
> > Now
> > when the people who will be actually using the thing are trying to
> participate
> > in the discussion, their arguments no longer matter to us, because
> the decision
> > was already made, whatever you say won't change it, this discussion
> is
> > pointless."
> >
> > Am I wrong?
> >
> >
> > I just want to give a bit of insight from someone who is working day to
> day on
> > Fedora's infrastructure, since I believe that might help give a bit more
> empathy
> > towards the Why of this decision.
> >
> > For me the Fedora's Infrastructure is in a very bad shape there is a
> fair load
> > of technical debt and trying to change or improve anything results in a
> long
> > list of reason why we can do it because services X depends on service Y
> which
> > depends on Z.  Since I joined the CPE team (little bit more than 2 years
> ago) we
> > have not been able to make any kind of significant progress towards
> fighting
> > this technical debt. Every year we fill a white board with what needs to
> be done :
> >
> >   * Python 3 apps migration,
> >   * FAS replacement,
> >   * fedmsg retirement,
> >   * FMN replacement,
> >   * Fedora-packages replacement,
> >   * PDC replacement,
> >   * Porting application to OIDC,
> >   * Improve Releng automation,
> >   * Improving Anitya and the-new-hotness,
> >   * .
> >
> > Every single year the same items are coming back because we spend most
> of our
> > time firefighting services to keep users happy and keep Fedora release
> schedule.
> > This has a very demoralizing effect on the people working in the team,
> it seems
> > like we will never be able to make any significant improvement, and our
> day to
> > day job is to close couple tickets and you keep watching the pile of
> tickets
> > growing. There is no feeling of accomplishment and a general sentiment
> that
> > whatever we do, it will suck.
> >
> > A little over a year ago we have expressed our need to drop
> applications, this
> > is something we have to do to be able to stay sane and keep a
> sustainable
> > life-work balance. From that effort to handover applications (Elections,
> > Nuancier, Fedocal, Badges) to another group of people in the community,
> not much
> > happened mainly because of GDPR and the legal responsibility of owning
> such
> > applications, but as far as I know we don't do much maintenance work on
> these
> > applications any more since we now have a few volunteers that are
> looking after
> > them or helping with finding an alternative solution.
> >
> > Now on the list of application we develop and run, I think Pagure is
> logical
> > candidate to try and find an alternative to it, but before doing this it
> was
> > important to make sure we captured all the use case and feature needed
> from a
> > git forge and see if any of these justified spending cycles in
> development and
> > maintenance work. My understanding of the decision is that Pagure does
> not
> > provide any significant advantage over GitLab. I know that for many, the
> fact
> > that Pagure is developed by Fedora is an advantage, but from my
> perspective as
> > someone that as to deal with all the other services in Fedora's Infra
> this is a
> > major disadvantage.
> >
> > Overall I think it is important to keep in mind that there is a lot of
> work
> > happening behind the scene to provide the people in the Fedora community
> a good
> > experience contributing to Fedora. I think we are doing a good job at
> it, but
> > that takes us an enormous effort and over the long term this is not
> sustainable,
> > also keeping in mind that we keep adding and want to keep adding new
> things to
> > Fedora.
> >
> > I hope that my perspective helps a little.
>
> Thanks. Just to clarify, I am not criticism the decision per se, I am just
> very
> sad with the communication around it.
>
> Most importantly the following:
>
> 1) At the beginning, it appeared that Fedora will be in the loop when the
> decision will be made, but it wasn't. After collecting the requirements,
> there
> was no Fedora involvement.
>
> 2) The use cases Fedora collected were (IMHO artificially) merged to "more
> general" requirements.
>
> 3) The "I respect that there is disagreement but Gitlab is the choice we
> are

Re: CPE Git Forge Decision

[Miro Hrončok]

On 31. 03. 20 13:09, Clement Verna wrote:
On Tue, 31 Mar 2020 at 11:41, Miro Hrončok > wrote:


On 31. 03. 20 10:36, Leigh Griffin wrote:
 > I respect that there is disagreement but Gitlab is the choice we are 
making.

I always try to assume good intentions, but this is very hard now. I 
understand
this statement as follows:

"After collecting the requirements, we have not discussed the decision with 
the
Fedora community, it was discussed in private. We have decided for Gitlab 
and
only once we have already decided, we have announced our decision to Fedora.
Now
when the people who will be actually using the thing are trying to 
participate
in the discussion, their arguments no longer matter to us, because the 
decision
was already made, whatever you say won't change it, this discussion is
pointless."

Am I wrong?


I just want to give a bit of insight from someone who is working day to day on 
Fedora's infrastructure, since I believe that might help give a bit more empathy 
towards the Why of this decision.


For me the Fedora's Infrastructure is in a very bad shape there is a fair load 
of technical debt and trying to change or improve anything results in a long 
list of reason why we can do it because services X depends on service Y which 
depends on Z.  Since I joined the CPE team (little bit more than 2 years ago) we 
have not been able to make any kind of significant progress towards fighting 
this technical debt. Every year we fill a white board with what needs to be done :


  * Python 3 apps migration,
  * FAS replacement,
  * fedmsg retirement,
  * FMN replacement,
  * Fedora-packages replacement,
  * PDC replacement,
  * Porting application to OIDC,
  * Improve Releng automation,
  * Improving Anitya and the-new-hotness,
  * .

Every single year the same items are coming back because we spend most of our 
time firefighting services to keep users happy and keep Fedora release schedule. 
This has a very demoralizing effect on the people working in the team, it seems 
like we will never be able to make any significant improvement, and our day to 
day job is to close couple tickets and you keep watching the pile of tickets 
growing. There is no feeling of accomplishment and a general sentiment that 
whatever we do, it will suck.


A little over a year ago we have expressed our need to drop applications, this 
is something we have to do to be able to stay sane and keep a sustainable 
life-work balance. From that effort to handover applications (Elections, 
Nuancier, Fedocal, Badges) to another group of people in the community, not much 
happened mainly because of GDPR and the legal responsibility of owning such 
applications, but as far as I know we don't do much maintenance work on these 
applications any more since we now have a few volunteers that are looking after 
them or helping with finding an alternative solution.


Now on the list of application we develop and run, I think Pagure is logical 
candidate to try and find an alternative to it, but before doing this it was 
important to make sure we captured all the use case and feature needed from a 
git forge and see if any of these justified spending cycles in development and 
maintenance work. My understanding of the decision is that Pagure does not 
provide any significant advantage over GitLab. I know that for many, the fact 
that Pagure is developed by Fedora is an advantage, but from my perspective as 
someone that as to deal with all the other services in Fedora's Infra this is a 
major disadvantage.


Overall I think it is important to keep in mind that there is a lot of work 
happening behind the scene to provide the people in the Fedora community a good 
experience contributing to Fedora. I think we are doing a good job at it, but 
that takes us an enormous effort and over the long term this is not sustainable, 
also keeping in mind that we keep adding and want to keep adding new things to 
Fedora.


I hope that my perspective helps a little.


Thanks. Just to clarify, I am not criticism the decision per se, I am just very 
sad with the communication around it.


Most importantly the following:

1) At the beginning, it appeared that Fedora will be in the loop when the 
decision will be made, but it wasn't. After collecting the requirements, there 
was no Fedora involvement.


2) The use cases Fedora collected were (IMHO artificially) merged to "more 
general" requirements.


3) The "I respect that there is disagreement but Gitlab is the choice we are 
making" attitude.


I totally respect that this is a choice the CPE needs to make. I am just not 
happy with the way it was handled.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 

Re: CPE Git Forge Decision

[Miro Hrončok]

On 31. 03. 20 12:41, Leigh Griffin wrote:

Am I wrong?
Yes.


Thanks for clarifying that.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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

Re: CPE Git Forge Decision

[Kevin Kofler]

Tomasz Torcz wrote:
> We seem to have not problem in using proprietary SAAS solutions for
> critical stuff.

And that is exactly what I am complaining about.

Kevin Kofler
___
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

Re: CPE Git Forge Decision

[Clement Verna]

On Tue, 31 Mar 2020 at 11:41, Miro Hrončok  wrote:

> On 31. 03. 20 10:36, Leigh Griffin wrote:
> > I respect that there is disagreement but Gitlab is the choice we are
> making.
>
> I always try to assume good intentions, but this is very hard now. I
> understand
> this statement as follows:
>
> "After collecting the requirements, we have not discussed the decision
> with the
> Fedora community, it was discussed in private. We have decided for Gitlab
> and
> only once we have already decided, we have announced our decision to
> Fedora. Now
> when the people who will be actually using the thing are trying to
> participate
> in the discussion, their arguments no longer matter to us, because the
> decision
> was already made, whatever you say won't change it, this discussion is
> pointless."
>
> Am I wrong?
>

I just want to give a bit of insight from someone who is working day to day
on Fedora's infrastructure, since I believe that might help give a bit more
empathy towards the Why of this decision.

For me the Fedora's Infrastructure is in a very bad shape there is a fair
load of technical debt and trying to change or improve anything results in
a long list of reason why we can do it because services X depends on
service Y which depends on Z.  Since I joined the CPE team (little bit more
than 2 years ago) we have not been able to make any kind of significant
progress towards fighting this technical debt. Every year we fill a white
board with what needs to be done :

   - Python 3 apps migration,
   - FAS replacement,
   - fedmsg retirement,
   - FMN replacement,
   - Fedora-packages replacement,
   - PDC replacement,
   - Porting application to OIDC,
   - Improve Releng automation,
   - Improving Anitya and the-new-hotness,
   - .

Every single year the same items are coming back because we spend most of
our time firefighting services to keep users happy and keep Fedora release
schedule. This has a very demoralizing effect on the people working in the
team, it seems like we will never be able to make any significant
improvement, and our day to day job is to close couple tickets and you keep
watching the pile of tickets growing. There is no feeling of accomplishment
and a general sentiment that whatever we do, it will suck.

A little over a year ago we have expressed our need to drop applications,
this is something we have to do to be able to stay sane and keep a
sustainable life-work balance. From that effort to handover applications
(Elections, Nuancier, Fedocal, Badges) to another group of people in the
community, not much happened mainly because of GDPR and the legal
responsibility of owning such applications, but as far as I know we don't
do much maintenance work on these applications any more since we now have a
few volunteers that are looking after them or helping with finding an
alternative solution.

Now on the list of application we develop and run, I think Pagure is
logical candidate to try and find an alternative to it, but before doing
this it was important to make sure we captured all the use case and feature
needed from a git forge and see if any of these justified spending cycles
in development and maintenance work. My understanding of the decision is
that Pagure does not provide any significant advantage over GitLab. I know
that for many, the fact that Pagure is developed by Fedora is an advantage,
but from my perspective as someone that as to deal with all the other
services in Fedora's Infra this is a major disadvantage.

Overall I think it is important to keep in mind that there is a lot of work
happening behind the scene to provide the people in the Fedora community a
good experience contributing to Fedora. I think we are doing a good job at
it, but that takes us an enormous effort and over the long term this is not
sustainable, also keeping in mind that we keep adding and want to keep
adding new things to Fedora.

I hope that my perspective helps a little.


> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> 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

Re: CPE Git Forge Decision

[Tomasz Torcz]

On Tue, Mar 31, 2020 at 12:42:18PM +0200, Kevin Kofler wrote:
> Leigh Griffin wrote:
> > Thank you for your patience while the CPE Team worked through an
> > incredible number of requirements from multiple stakeholder sources. On
> > Friday evening we announced on the Community Blog
> >  our
> > decision to adopt Gitlab as our Git Forge and to retain pagure.io to
> > ultimately hand over to the Community to maintain. It wasn't an easy
> > decision by any stretch of the imagination and we hope that the compromise
> > that we are striking will help to allow Pagure flourish and to give a
> > choice of Forges for your usage. I'm happy to field any questions or
> > comments about this decision.
> 
> What really worries to me is that:
> * using GitLab as SaaS is being considered, and
> * for self-hosting, using the proprietary "enterprise" editions is not
>   excluded.
> 
> I think that using anything other than Free Software as the hosting platform 
> for Fedora should be an absolute no go. In other words, self-hosted GitLab 
> CE or Pagure, no other options.

  Being self-hosted is a nice goal, but not important enough.
There are parts of Fedora infrastructure which are not using Fedora,
but other distributions like RHEL.  We seem to have not problem in
using proprietary SAAS solutions for critical stuff.
  I truly envy Debian and their ability to dogfood, running their
infra on Debian. With minor exception: although they self-host GitLab,
it seems to be different than their distribution packages.


-- 
Tomasz TorczOnly gods can safely risk perfection,
to...@pipebreaker.pl it's a dangerous thing for a man.  — Alia
___
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

Re: CPE Git Forge Decision

[Leigh Griffin]

On Tue, Mar 31, 2020 at 11:48 AM Felix Schwarz 
wrote:

>
> Am 31.03.20 um 12:42 schrieb Kevin Kofler:
> > I think that using anything other than Free Software as the hosting
> platform
> > for Fedora should be an absolute no go. In other words, self-hosted
> GitLab
> > CE or Pagure, no other options.
>
> +1 with one minor(?) exception:
> I'm ok with using a hosted version provided that the software (and its
> dependencies) is part of the Fedora repos and there are provisions to
> extract
> the data (e.g. database) from the hosted version without any data loss and
> load it in a self-hosted version using Fedora RPMs.
>

We can certainly bring that forward as a requirement, thank you for this.

>
> Felix
> ___
> 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 

Communications House

Cork Road, Waterford City

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


___
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

Re: CPE Git Forge Decision

[Leigh Griffin]

On Tue, Mar 31, 2020 at 11:43 AM Kevin Kofler 
wrote:

> Leigh Griffin wrote:
> > Thank you for your patience while the CPE Team worked through an
> > incredible number of requirements from multiple stakeholder sources. On
> > Friday evening we announced on the Community Blog
> > 
> our
> > decision to adopt Gitlab as our Git Forge and to retain pagure.io to
> > ultimately hand over to the Community to maintain. It wasn't an easy
> > decision by any stretch of the imagination and we hope that the
> compromise
> > that we are striking will help to allow Pagure flourish and to give a
> > choice of Forges for your usage. I'm happy to field any questions or
> > comments about this decision.
>
> What really worries to me is that:
> * using GitLab as SaaS is being considered, and
> * for self-hosting, using the proprietary "enterprise" editions is not
>   excluded.
>
> I think that using anything other than Free Software as the hosting
> platform
> for Fedora should be an absolute no go. In other words, self-hosted GitLab
> CE or Pagure, no other options.
>

No option is off the table right now as we haven't sat down with Gitlab to
evaluate options yet, that is scheduled for this week. SaaS and all
variants of licensing are an option right now until we evaluate the tooling
needs and process the valuable feedback in this thread (and others) will be
brought to Gitlab and in our public facing ticket we would most welcome
engagement to have your voice and say heard by the Gitlab folks directly.


> Kevin Kofler
> ___
> 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 

Communications House

Cork Road, Waterford City

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


___
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

Re: CPE Git Forge Decision

[Felix Schwarz]

Am 31.03.20 um 12:42 schrieb Kevin Kofler:
> I think that using anything other than Free Software as the hosting platform 
> for Fedora should be an absolute no go. In other words, self-hosted GitLab 
> CE or Pagure, no other options.

+1 with one minor(?) exception:
I'm ok with using a hosted version provided that the software (and its
dependencies) is part of the Fedora repos and there are provisions to extract
the data (e.g. database) from the hosted version without any data loss and
load it in a self-hosted version using Fedora RPMs.

Felix
___
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

Re: CPE Git Forge Decision

[Kevin Kofler]

Leigh Griffin wrote:
> Thank you for your patience while the CPE Team worked through an
> incredible number of requirements from multiple stakeholder sources. On
> Friday evening we announced on the Community Blog
>  our
> decision to adopt Gitlab as our Git Forge and to retain pagure.io to
> ultimately hand over to the Community to maintain. It wasn't an easy
> decision by any stretch of the imagination and we hope that the compromise
> that we are striking will help to allow Pagure flourish and to give a
> choice of Forges for your usage. I'm happy to field any questions or
> comments about this decision.

What really worries to me is that:
* using GitLab as SaaS is being considered, and
* for self-hosting, using the proprietary "enterprise" editions is not
  excluded.

I think that using anything other than Free Software as the hosting platform 
for Fedora should be an absolute no go. In other words, self-hosted GitLab 
CE or Pagure, no other options.

Kevin Kofler
___
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

Re: CPE Git Forge Decision

[Leigh Griffin]

On Tue, Mar 31, 2020 at 10:41 AM Miro Hrončok  wrote:

> On 31. 03. 20 10:36, Leigh Griffin wrote:
> > I respect that there is disagreement but Gitlab is the choice we are
> making.
>
> I always try to assume good intentions, but this is very hard now. I
> understand
> this statement as follows:
>
> "After collecting the requirements, we have not discussed the decision
> with the
> Fedora community, it was discussed in private.


The requirements were analysed in private which we indicated they would be
evaluated by the CPE Management.

We have decided for Gitlab and
> only once we have already decided, we have announced our decision to
> Fedora.


We have announced our decision to all stakeholders.

Now
> when the people who will be actually using the thing are trying to
> participate
> in the discussion, their arguments no longer matter to us, because the
> decision
> was already made, whatever you say won't change it, this discussion is
> pointless."
>

The thoughts and arguments matter and will influence how the technical
implementation will go for us. I already have pulled some good information
from the responses for our consideration. It's not altering the decision as
the overall balance of requirements is still pointing to Gitlab as the
choice.

>
> Am I wrong?
>

Yes.

>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> 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 

Communications House

Cork Road, Waterford City

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


___
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

Re: CPE Git Forge Decision

[Miro Hrončok]

On 31. 03. 20 10:36, Leigh Griffin wrote:

I respect that there is disagreement but Gitlab is the choice we are making.


I always try to assume good intentions, but this is very hard now. I understand 
this statement as follows:


"After collecting the requirements, we have not discussed the decision with the 
Fedora community, it was discussed in private. We have decided for Gitlab and 
only once we have already decided, we have announced our decision to Fedora. Now 
when the people who will be actually using the thing are trying to participate 
in the discussion, their arguments no longer matter to us, because the decision 
was already made, whatever you say won't change it, this discussion is pointless."


Am I wrong?

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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

Re: CPE Git Forge Decision

[Leigh Griffin]

On Tue, Mar 31, 2020 at 8:10 AM Petr Kubat  wrote:

> From the community blog this decision seems more like a "what can we use
> to make CentOS Stream work" rather than an open community-made choice of
> what is best for Fedora.
>

The needs of Fedora, CentOS, RHEL and the CPE team were weighed equally in
our decision. Fedora had very few specific needs in their requirements
where as some stakeholder groups had. The balance of the decision was for
Gitlab.

> On 3/30/20 11:17 AM, Leigh Griffin wrote:
>
> Hi everyone,
>
> Thank you for your patience while the CPE Team worked through an
> incredible number of requirements from multiple stakeholder sources. On
> Friday evening we announced on the Community Blog
>  our
> decision to adopt Gitlab as our Git Forge and to retain pagure.io to
> ultimately hand over to the Community to maintain. It wasn't an easy
> decision by any stretch of the imagination and we hope that the compromise
> that we are striking will help to allow Pagure flourish and to give a
> choice of Forges for your usage. I'm happy to field any questions or
> comments about this decision.
>
> Kind regards,
> Leigh, on behalf of the CPE Team
>
> --
>
> Leigh Griffin
>
> Engineering Manager
>
> Red Hat Waterford 
>
> Communications House
>
> Cork Road, Waterford City
>
> lgrif...@redhat.com
> M: +353877545162 IM: lgriffin
> @redhatjobs    redhatjobs
>  @redhatjobs
> 
> 
>
> ___
> 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
>


-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford 

Communications House

Cork Road, Waterford City

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


___
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

Re: CPE Git Forge Decision

[Leigh Griffin]

On Mon, Mar 30, 2020 at 10:38 PM Chris Murphy 
wrote:

> On Mon, Mar 30, 2020 at 5:56 AM Leigh Griffin  wrote:
> >
> > We haven't ironed out the full details but what was incredibly clear to
> us was that Gitlab was the decision to make. The next step in getting there
> is what we are engaging in now to get thoughts and suggestions and expect
> several threads in that capacity from a technical perspective in the coming
> weeks and months.
>
>
> It is not incredibly clear to the respondents on devel@. I don't care
> to imagine what stronger disagreement on this particular point looks
> like.
>

I respect that there is disagreement but Gitlab is the choice we are making.

>
>
> On Mon, Mar 30, 2020 at 4:27 AM Iñaki Ucar 
> wrote:
> >
> > I was referring to, and I was expecting, an open conversation about
> > the User Story list, an open analysis of the requirements list. In
> > other words:
> >
> > 1. Open conversation to gather requirements. Done.
> > 2. Publication of User Story list.
> > 3. Open conversation to discuss (2).
> > 4. Publication of the final decision.
> >
> > I was expecting (3), and it's missing.
>
>
> I concur, and don't think the missing piece has been adequately
> addressed. There's a reason why there's bewilderment at the decision,
> it's not ignorable.
>

How would you like us to address it more clearly? Fedora has had the
publication of its User Story list, a threads worth of discussion on it
occured and it was submitted. As have other stakeholder groups. I think the
crux here is that we didn't publish the entire stakeholder User Stories for
dissemination to each individual stakeholder group. With each group valuing
something different, as is obvious from the discussion around individual
requirements that has occured in several threads here, we didn't feel the
value would have been there. That's on me for not looping the comms back in
and I apologise for that.


> Were there deliberations by CPE Team in between (2) and (4)?

Yes, several hundred person hours worth of analysis, meetings and
dissecting the requirements.


> Is there
> a record of those deliberations?
>

No, they were mostly video calls / in person meetings and the result is the
User Story list and decision document for sharing.

>
>
>
> --
> Chris Murphy
> ___
> 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 

Communications House

Cork Road, Waterford City

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


___
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

Re: CPE Git Forge Decision

[Leigh Griffin]

On Mon, Mar 30, 2020 at 9:55 PM Till Maas  wrote:

> Hi,
>
> On Mon, Mar 30, 2020 at 02:40:13PM +, Leigh Griffin wrote:
> > On Mon, Mar 30, 2020 at 3:26 PM Till Maas  wrote:
> >
> > > Hi,
> > >
> > > On Mon, Mar 30, 2020 at 01:59:07PM +, Leigh Griffin wrote:
> > > > On Mon, Mar 30, 2020 at 2:18 PM Till Maas 
> 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.
>

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
> 

Re: CPE Git Forge Decision

[Vít Ondruch]

Dne 30. 03. 20 v 17:41 Pavel Raiskup napsal(a):
> The only problem of GitLab is that Fedora - for years - was not able to
> package it.  I'm not a able to judge where the packaging problem is/was,
> any more info?  Are we going invest into packaging it?


It was lot of dependencies, bundling, lack of man power. The usual
stuff. Nothing exceptional.

BTW Axil, who used to work on this is now employed by GitLab [1].


Vít



[1] https://gitlab.com/axil

___
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

Re: CPE Git Forge Decision

[Petr Kubat]

From the community blog this decision seems more like a "what can we 
use to make CentOS Stream work" rather than an open community-made 
choice of what is best for Fedora.


On 3/30/20 11:17 AM, Leigh Griffin wrote:

Hi everyone,

Thank you for your patience while the CPE Team worked through an 
incredible number of requirements from multiple stakeholder sources. 
On Friday evening we announced on the Community Blog 
 our 
decision to adopt Gitlab as our Git Forge and to retain pagure.io 
 to ultimately hand over to the Community to 
maintain. It wasn't an easy decision by any stretch of the imagination 
and we hope that the compromise that we are striking will help to 
allow Pagure flourish and to give a choice of Forges for your usage. 
I'm happy to field any questions or comments about this decision.


Kind regards,
Leigh, on behalf of the CPE Team

--

Leigh Griffin

Engineering Manager

Red Hat Waterford 

Communications House

Cork Road, Waterford City

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

@redhatjobs  redhatjobs 
 @redhatjobs 





___
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

Re: CPE Git Forge Decision

[Clement Verna]

On Mon, 30 Mar 2020 at 22:55, Till Maas  wrote:

> Hi,
>
> On Mon, Mar 30, 2020 at 02:40:13PM +, Leigh Griffin wrote:
> > On Mon, Mar 30, 2020 at 3:26 PM Till Maas  wrote:
> >
> > > Hi,
> > >
> > > On Mon, Mar 30, 2020 at 01:59:07PM +, Leigh Griffin wrote:
> > > > On Mon, Mar 30, 2020 at 2:18 PM Till Maas 
> 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

Re: CPE Git Forge Decision

[Chris Murphy]

On Mon, Mar 30, 2020 at 5:56 AM Leigh Griffin  wrote:
>
> We haven't ironed out the full details but what was incredibly clear to us 
> was that Gitlab was the decision to make. The next step in getting there is 
> what we are engaging in now to get thoughts and suggestions and expect 
> several threads in that capacity from a technical perspective in the coming 
> weeks and months.


It is not incredibly clear to the respondents on devel@. I don't care
to imagine what stronger disagreement on this particular point looks
like.


On Mon, Mar 30, 2020 at 4:27 AM Iñaki Ucar  wrote:
>
> I was referring to, and I was expecting, an open conversation about
> the User Story list, an open analysis of the requirements list. In
> other words:
>
> 1. Open conversation to gather requirements. Done.
> 2. Publication of User Story list.
> 3. Open conversation to discuss (2).
> 4. Publication of the final decision.
>
> I was expecting (3), and it's missing.


I concur, and don't think the missing piece has been adequately
addressed. There's a reason why there's bewilderment at the decision,
it's not ignorable.

Were there deliberations by CPE Team in between (2) and (4)? Is there
a record of those deliberations?



-- 
Chris Murphy
___
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

Re: CPE Git Forge Decision

[Ben Cotton]

On Mon, Mar 30, 2020 at 4:55 PM Till Maas  wrote:
>
> 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.
>
Yes, I sent Aoife the user stories after they were discussed on the
council-discuss thread[1]. The original version had 47. One was added,
two were removed, and a few were edited to get the final count.

[1] 
https://lists.fedoraproject.org/archives/list/council-disc...@lists.fedoraproject.org/thread/OEPDGVKYAJIQ6YYZU5J3XT3LHXFROFI5/

-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
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

Re: CPE Git Forge Decision

[Till Maas]

Hi,

On Mon, Mar 30, 2020 at 02:40:13PM +, Leigh Griffin wrote:
> On Mon, Mar 30, 2020 at 3:26 PM Till Maas  wrote:
> 
> > Hi,
> >
> > On Mon, Mar 30, 2020 at 01:59:07PM +, Leigh Griffin wrote:
> > > On Mon, Mar 30, 2020 at 2:18 PM Till Maas  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.

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

Re: CPE Git Forge Decision

[Simo Sorce]

On Mon, 2020-03-30 at 17:41 +0200, Pavel Raiskup wrote:
> On Monday, March 30, 2020 11:17:21 AM CEST Leigh Griffin wrote:
> > Thank you for your patience while the CPE Team worked through an incredible
> > number of requirements from multiple stakeholder sources. On Friday evening
> > we announced on the Community Blog
> >  our
> > decision to adopt Gitlab as our Git Forge and to retain pagure.io to
> > ultimately hand over to the Community to maintain. It wasn't an easy
> > decision by any stretch of the imagination and we hope that the compromise
> > that we are striking will help to allow Pagure flourish and to give a
> > choice of Forges for your usage. I'm happy to field any questions or
> > comments about this decision.
> 
> Is there some tool to automatically migrate PRs->MRs and issues?
> 
> The only problem of GitLab is that Fedora - for years - was not able to
> package it.  I'm not a able to judge where the packaging problem is/was,
> any more info?  Are we going invest into packaging it?
> 
> Please make us 100% confident we are not going to be locked-in.  If we
> aren't able to package it reasonably well, it means that we have no option
> to decide to self-host GitLab in future.

If you carefully read between the lines you'd find there is no
intention of hosting or anything, we are locking ourselves into gitlab
and the benevolence of the the gitlab company, and they ability to
survive. When they will go away we'll be left with the pieces. But then
it will be some future people that will have to deal with it. Good
luck.

/me absolutely not happy with the way this affair has been handled.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



___
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

Re: CPE Git Forge Decision

[Matthias Runge]

On 30/03/2020 17:41, Pavel Raiskup wrote:

> The only problem of GitLab is that Fedora - for years - was not able to
> package it.  I'm not a able to judge where the packaging problem is/was,
> any more info?  Are we going invest into packaging it?
> 
> Please make us 100% confident we are not going to be locked-in.  If we
> aren't able to package it reasonably well, it means that we have no option
> to decide to self-host GitLab in future.
> 

Self-hosting was not desired. You could, if you are trusting

curl
https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.rpm.sh
| sudo bash

(taken from https://about.gitlab.com/install/#centos-8 )


You can also export "most of your data" from hosted solutions, see
https://about.gitlab.com/pricing/
(there is an faq "Can I export my data")

The link is
https://docs.gitlab.com/ee/user/project/settings/import_export.html
where it says:

The following items will NOT be exported:

- Build traces and artifacts
- Container registry images
- CI variables
- Webhooks
- Any encrypted tokens
- Merge Request Approvers
- Push Rules
- Awards


Matthias
___
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

Re: CPE Git Forge Decision

[Pavel Raiskup]

On Monday, March 30, 2020 11:17:21 AM CEST Leigh Griffin wrote:
> Thank you for your patience while the CPE Team worked through an incredible
> number of requirements from multiple stakeholder sources. On Friday evening
> we announced on the Community Blog
>  our
> decision to adopt Gitlab as our Git Forge and to retain pagure.io to
> ultimately hand over to the Community to maintain. It wasn't an easy
> decision by any stretch of the imagination and we hope that the compromise
> that we are striking will help to allow Pagure flourish and to give a
> choice of Forges for your usage. I'm happy to field any questions or
> comments about this decision.

Is there some tool to automatically migrate PRs->MRs and issues?

The only problem of GitLab is that Fedora - for years - was not able to
package it.  I'm not a able to judge where the packaging problem is/was,
any more info?  Are we going invest into packaging it?

Please make us 100% confident we are not going to be locked-in.  If we
aren't able to package it reasonably well, it means that we have no option
to decide to self-host GitLab in future.

Pavel


___
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

Re: CPE Git Forge Decision

[Leigh Griffin]

On Mon, Mar 30, 2020 at 3:36 PM Matthias Runge 
wrote:

> On 30/03/2020 16:23, Till Maas 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
>
> >
> https://lists.fedoraproject.org/archives/list/council-disc...@lists.fedoraproject.org/thread/OEPDGVKYAJIQ6YYZU5J3XT3LHXFROFI5/
> >
> > 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. 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.
>
>
> Comparing the two lists Ben posted and the one on hackmd.io differ quite
> a bit. Was the list of requirements changed during the process?
>

As a team we evaluated every single requirement (over 300 of them) and the
presentation in the combined User Story list is an amalgamation of like for
like User Stories to capture at a high level the spirit of the requests.

>
>
> Matthias
> ___
> 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 

Communications House

Cork Road, Waterford City

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


___
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

Re: CPE Git Forge Decision

[Leigh Griffin]

On Mon, Mar 30, 2020 at 3:26 PM Till Maas  wrote:

> Hi,
>
> On Mon, Mar 30, 2020 at 01:59:07PM +, Leigh Griffin wrote:
> > On Mon, Mar 30, 2020 at 2:18 PM Till Maas  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.


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

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

>
> Thank you,
> 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
>


-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford 

Communications House

Cork Road, Waterford City

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


___
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

Re: CPE Git Forge Decision

[Matthias Runge]

On 30/03/2020 16:23, Till Maas 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

> https://lists.fedoraproject.org/archives/list/council-disc...@lists.fedoraproject.org/thread/OEPDGVKYAJIQ6YYZU5J3XT3LHXFROFI5/
> 
> 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. 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.


Comparing the two lists Ben posted and the one on hackmd.io differ quite
a bit. Was the list of requirements changed during the process?


Matthias
___
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

Re: CPE Git Forge Decision

[Leigh Griffin]

On Mon, Mar 30, 2020 at 3:07 PM Fabio Valentini 
wrote:

> On Mon, Mar 30, 2020 at 4:00 PM Leigh Griffin  wrote:
> >
> >
> >
> > On Mon, Mar 30, 2020 at 2:01 PM Miro Hrončok 
> wrote:
> >>
> >> On 30. 03. 20 14:13, Neal Gompa wrote:
> >> > And unlike Alioth, we have*serious*
> >> > integration across the board with Pagure, and a good chunk of it is
> >> > not possible to implement in GitLab. Features we have in here were
> >> > designed to meet the needs of Fedorans that we will be forced to give
> >> > up.
> >>
> >> I want to stress out that recently we even got more of it. Several
> years after
> >> the PackageDB sunset, we are finally getting to a matching packager
> experience.
> >>
> >> (For example with the Bugzilla default assignee or the
> unorphan/unretire buttons.)
> >>
> >> Is this going to be possible with GitLab?
>
>
> (snip)
>
> >
> >
> > I don't have an answer to this as we haven't done that deep level of
> tooling analysis and integration analysis yet.
>
> So you're basically saying that you've decided for GitLab (despite the
> fedora community obviously preferring pagure - whether you received
> that message or not),


It was not a formal requirement.

and you have not even looked at what that will
> mean?


We have looked into the capabilities of it to inform our decision but not
at a granular tooling level.


> And if it turns out that GitLab can't deliver some features you
> want, and not satisfy some "stakeholder user stories"?
>

Not all requirements can be satisfied in totality, we knew this before we
began and Gitlab satisfies the majority of the requirements needed.

>
> Am I crazy, or shouldn't have those problems have been taken into
> account *before* such a big decision is made?
> Your responses sound like "we made our decisions, and now we'll stick
> to them no matter what happens".
>

Like any technology decision that we as a team choose, we can revert our
decision if the service is not working as intended and not satisfying our
needs. Right now, we are proceeding with Gitlab as our choice.

And honestly, I shouldn't have expected anything else from this "kill
> pagure project".
>

Pagure was a viable choice and several hundred person hours went into
informing us of this decision because of how critical it was to get right.


>
> The way the fedora community - and the pagure project - are and were
> treated here is shameful, and you're going to lose fedora contributors
> because of it.
>
> Fabio
>
> >
> >>
> >> Will CPE implement this before we
> >> switch, or will GitLab be dumped on us and we will do toothless FESCo
> approved
> >> statements, such as "Missing Pagure features should be re-implemented in
> >> GitLab"?
> >
> >
> > CPE will take on a lot of the tooling work to ease the migration.
> >
> >>
> >> What measures will be taken to prevent yet another "open a releng
> >> ticket and a human will do this while we automate stuff" era?
> >>
> >> --
> >> Miro Hrončok
> >> --
> >> Phone: +420777974800
> >> IRC: mhroncok
> >> ___
> >> 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
> >
> > Communications House
> >
> > Cork Road, Waterford City
> >
> > lgrif...@redhat.com
> > M: +353877545162 IM: lgriffin
> >
> > @redhatjobs   redhatjobs @redhatjobs
> > ___
> > 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
>


-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford 

Communications House

Cork Road, Waterford City

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

Re: CPE Git Forge Decision

[Till Maas]

Hi,

On Mon, Mar 30, 2020 at 01:59:07PM +, Leigh Griffin wrote:
> On Mon, Mar 30, 2020 at 2:18 PM Till Maas  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/

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

Also there seems to be nothing about orphaning/adopting/retiring
packages, not even in a vague way.

Thank you,
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

Re: CPE Git Forge Decision

[Fabio Valentini]

On Mon, Mar 30, 2020 at 4:00 PM Leigh Griffin  wrote:
>
>
>
> On Mon, Mar 30, 2020 at 2:01 PM Miro Hrončok  wrote:
>>
>> On 30. 03. 20 14:13, Neal Gompa wrote:
>> > And unlike Alioth, we have*serious*
>> > integration across the board with Pagure, and a good chunk of it is
>> > not possible to implement in GitLab. Features we have in here were
>> > designed to meet the needs of Fedorans that we will be forced to give
>> > up.
>>
>> I want to stress out that recently we even got more of it. Several years 
>> after
>> the PackageDB sunset, we are finally getting to a matching packager 
>> experience.
>>
>> (For example with the Bugzilla default assignee or the unorphan/unretire 
>> buttons.)
>>
>> Is this going to be possible with GitLab?


(snip)

>
>
> I don't have an answer to this as we haven't done that deep level of tooling 
> analysis and integration analysis yet.

So you're basically saying that you've decided for GitLab (despite the
fedora community obviously preferring pagure - whether you received
that message or not), and you have not even looked at what that will
mean? And if it turns out that GitLab can't deliver some features you
want, and not satisfy some "stakeholder user stories"?

Am I crazy, or shouldn't have those problems have been taken into
account *before* such a big decision is made?
Your responses sound like "we made our decisions, and now we'll stick
to them no matter what happens".
And honestly, I shouldn't have expected anything else from this "kill
pagure project".

The way the fedora community - and the pagure project - are and were
treated here is shameful, and you're going to lose fedora contributors
because of it.

Fabio

>
>>
>> Will CPE implement this before we
>> switch, or will GitLab be dumped on us and we will do toothless FESCo 
>> approved
>> statements, such as "Missing Pagure features should be re-implemented in
>> GitLab"?
>
>
> CPE will take on a lot of the tooling work to ease the migration.
>
>>
>> What measures will be taken to prevent yet another "open a releng
>> ticket and a human will do this while we automate stuff" era?
>>
>> --
>> Miro Hrončok
>> --
>> Phone: +420777974800
>> IRC: mhroncok
>> ___
>> 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
>
> Communications House
>
> Cork Road, Waterford City
>
> lgrif...@redhat.com
> M: +353877545162 IM: lgriffin
>
> @redhatjobs   redhatjobs @redhatjobs
> ___
> 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

Re: CPE Git Forge Decision

[Leigh Griffin]

On Mon, Mar 30, 2020 at 2:18 PM Till Maas  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 plan for this in the future? Will there be a
> different solution instead of a git forge for this?


> Thank you
> 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
>


-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford 

Communications House

Cork Road, Waterford City

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


___
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

Re: CPE Git Forge Decision

[Leigh Griffin]

On Mon, Mar 30, 2020 at 2:01 PM Miro Hrončok  wrote:

> On 30. 03. 20 14:13, Neal Gompa wrote:
> > And unlike Alioth, we have*serious*
> > integration across the board with Pagure, and a good chunk of it is
> > not possible to implement in GitLab. Features we have in here were
> > designed to meet the needs of Fedorans that we will be forced to give
> > up.
>
> I want to stress out that recently we even got more of it. Several years
> after
> the PackageDB sunset, we are finally getting to a matching packager
> experience.
>
> (For example with the Bugzilla default assignee or the unorphan/unretire
> buttons.)
>
> Is this going to be possible with GitLab?


I don't have an answer to this as we haven't done that deep level of
tooling analysis and integration analysis yet.


> Will CPE implement this before we
> switch, or will GitLab be dumped on us and we will do toothless FESCo
> approved
> statements, such as "Missing Pagure features should be re-implemented in
> GitLab"?


CPE will take on a lot of the tooling work to ease the migration.


> What measures will be taken to prevent yet another "open a releng
> ticket and a human will do this while we automate stuff" era?
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> 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 

Communications House

Cork Road, Waterford City

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


___
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

Re: CPE Git Forge Decision

[Leigh Griffin]

On Mon, Mar 30, 2020 at 1:15 PM Neal Gompa  wrote:

> On Mon, Mar 30, 2020 at 7:56 AM Leigh Griffin  wrote:
> >
> > On Mon, Mar 30, 2020 at 11:31 AM Julen Landa Alustiza <
> jla...@fedoraproject.org> wrote:
> >>
> >> Sincelery, after reading the initial announcement, I was expecting a
> >> more visible and open to the community discussion scenario.
> >> >
> >> > 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
> >> >
> >> > This thread is also part of the open conversation on the decision.
> >>
> >> No, this is a post decision conversation, not the promised open and live
> >> discussions *during* the process.
> >
> >
> > We haven't ironed out the full details but what was incredibly clear to
> us was that Gitlab was the decision to make. The next step in getting there
> is what we are engaging in now to get thoughts and suggestions and expect
> several threads in that capacity from a technical perspective in the coming
> weeks and months.
>
> But that's the problem. It *wasn't* clear to all of us in Fedora and
> CentOS communities. This is why I'm upset about this more than
> anything else. This is a post-decision conversation that didn't follow
> the "open decision-making process" that you had described earlier.
>

We followed the process as laid out, we had open discussions of the problem
and concluded the ideation phase with a set of requirements delivered by
Ben Cotton on behalf of the Fedora Community. We are now engaging openly on
what the challenges and next steps are.

>
> You've made the decision that we're going to move to GitLab in a way
> that feels like we were only given lip service to. You also gave no
> chance for the Pagure community to respond to meet those needs in a
> way that we wouldn't be required to move to GitLab.


I'm unsure where you got the impression that there was an opportunity for
either Forge to respond to meet future needs? The exercise looked at our
short term needs and our long term investment. Had Pagure been the right
choice on both fronts, we would have engaged with the Pagure community to
bridge the feature gap.


> I would have been
> happier if you had said: "at this current time, GitLab makes sense for
> us. We will engage with GitLab to figure out some more details, but
> here are the things we considered critical gaps. Since we're not
> making this move this year anyway, if these gaps can be closed by the
> end of the year, we will consider staying on Pagure instead of going
> forward with a plan of a GitLab migration."
>

That sounds reasonable when taken in a vacuum. We have needs to service as
a team and delaying a decision by a year or more to possibly solve some of
the technical problem isn't going to change the operational overhead that
some of the requirements is mandating. They were requirements we didn't
quiet fully grasp until we carried out the exercise. It is our intention to
have something stood up on Gitlab in the coming weeks and made available
for consumption by our Communities and team ASAP.


> It feels like "welp GitLab because GitLab", ignoring that many folks
> in Fedora did not want GitLab.


The requirements presented to us by the Fedora Community made no reference
to Gitlab or Pagure so this was not a case of Gitlab because. If anything,
and as I stated in another reply, Github ticked more boxes.


> It's like the Debian Alioth replacement
> process all over again. And unlike Alioth, we have *serious*
> integration across the board with Pagure, and a good chunk of it is
> not possible to implement in GitLab. Features we have in here were
> designed to meet the needs of Fedorans that we will be forced to give
> up.
>
> We aim to keep feature parity and any gaps in requirements or tooling will
be put forward to Gitlab for their roadmap integreations.

>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> 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 

Communications House

Cork Road, Waterford City

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


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 

Re: CPE Git Forge Decision

[Till Maas]

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. What is the plan for this in the future? Will there be a
different solution instead of a git forge for this?

Thank you
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

Re: CPE Git Forge Decision

[Neal Gompa]

On Mon, Mar 30, 2020 at 9:00 AM Miro Hrončok  wrote:
>
> On 30. 03. 20 14:13, Neal Gompa wrote:
> > And unlike Alioth, we have*serious*
> > integration across the board with Pagure, and a good chunk of it is
> > not possible to implement in GitLab. Features we have in here were
> > designed to meet the needs of Fedorans that we will be forced to give
> > up.
>
> I want to stress out that recently we even got more of it. Several years after
> the PackageDB sunset, we are finally getting to a matching packager 
> experience.
>
> (For example with the Bugzilla default assignee or the unorphan/unretire 
> buttons.)
>
> Is this going to be possible with GitLab? Will CPE implement this before we
> switch, or will GitLab be dumped on us and we will do toothless FESCo approved
> statements, such as "Missing Pagure features should be re-implemented in
> GitLab"? What measures will be taken to prevent yet another "open a releng
> ticket and a human will do this while we automate stuff" era?
>

And for what it's worth, the only remaining feature gap from PackageDB
is in the process of being implemented in Pagure (per branch ACLs):
https://pagure.io/pagure/pull-request/4786

Once that's done, we'll have *total* parity with the previous packager
experience.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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

Re: CPE Git Forge Decision

[Miro Hrončok]

On 30. 03. 20 14:13, Neal Gompa wrote:

And unlike Alioth, we have*serious*
integration across the board with Pagure, and a good chunk of it is
not possible to implement in GitLab. Features we have in here were
designed to meet the needs of Fedorans that we will be forced to give
up.


I want to stress out that recently we even got more of it. Several years after 
the PackageDB sunset, we are finally getting to a matching packager experience.


(For example with the Bugzilla default assignee or the unorphan/unretire 
buttons.)

Is this going to be possible with GitLab? Will CPE implement this before we 
switch, or will GitLab be dumped on us and we will do toothless FESCo approved 
statements, such as "Missing Pagure features should be re-implemented in 
GitLab"? What measures will be taken to prevent yet another "open a releng 
ticket and a human will do this while we automate stuff" era?


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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

Re: CPE Git Forge Decision

[Neal Gompa]

On Mon, Mar 30, 2020 at 7:56 AM Leigh Griffin  wrote:
>
> On Mon, Mar 30, 2020 at 11:31 AM Julen Landa Alustiza 
>  wrote:
>>
>> Sincelery, after reading the initial announcement, I was expecting a
>> more visible and open to the community discussion scenario.
>> >
>> > 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
>> >
>> > This thread is also part of the open conversation on the decision.
>>
>> No, this is a post decision conversation, not the promised open and live
>> discussions *during* the process.
>
>
> We haven't ironed out the full details but what was incredibly clear to us 
> was that Gitlab was the decision to make. The next step in getting there is 
> what we are engaging in now to get thoughts and suggestions and expect 
> several threads in that capacity from a technical perspective in the coming 
> weeks and months.

But that's the problem. It *wasn't* clear to all of us in Fedora and
CentOS communities. This is why I'm upset about this more than
anything else. This is a post-decision conversation that didn't follow
the "open decision-making process" that you had described earlier.

You've made the decision that we're going to move to GitLab in a way
that feels like we were only given lip service to. You also gave no
chance for the Pagure community to respond to meet those needs in a
way that we wouldn't be required to move to GitLab. I would have been
happier if you had said: "at this current time, GitLab makes sense for
us. We will engage with GitLab to figure out some more details, but
here are the things we considered critical gaps. Since we're not
making this move this year anyway, if these gaps can be closed by the
end of the year, we will consider staying on Pagure instead of going
forward with a plan of a GitLab migration."

It feels like "welp GitLab because GitLab", ignoring that many folks
in Fedora did not want GitLab. It's like the Debian Alioth replacement
process all over again. And unlike Alioth, we have *serious*
integration across the board with Pagure, and a good chunk of it is
not possible to implement in GitLab. Features we have in here were
designed to meet the needs of Fedorans that we will be forced to give
up.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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

Re: CPE Git Forge Decision

[Leigh Griffin]

On Mon, Mar 30, 2020 at 11:31 AM Julen Landa Alustiza <
jla...@fedoraproject.org> wrote:

>
>
> 20/3/30 12:04(e)an, Leigh Griffin igorleak idatzi zuen:
> >
> >
> > On Mon, Mar 30, 2020 at 10:55 AM Iñaki Ucar  > > wrote:
> >
> > Hi Leigh,
> >
> > On Mon, 30 Mar 2020 at 11:30, Leigh Griffin  > > wrote:
> > >
> > > Hi everyone,
> > >
> > > Thank you for your patience while the CPE Team worked through an
> > incredible number of requirements from multiple stakeholder sources.
> > On Friday evening we announced on the Community Blog our decision to
> > adopt Gitlab as our Git Forge and to retain pagure.io
> >  to ultimately hand over to the Community to
> > maintain. It wasn't an easy decision by any stretch of the
> > imagination and we hope that the compromise that we are striking
> > will help to allow Pagure flourish and to give a choice of Forges
> > for your usage. I'm happy to field any questions or comments about
> > this decision.
> >
> > My question is, where's the open conversation about the requirements
> > gathered that you promised in the initial thread?
> >
> >
> > Hey Iñaki, we have had several rounds of open conversation facilitated
> > via the Council threads on it to arrive on what the requirements were
> > for the Fedora Project. This ultimately concluded with the formal
> > requirements received from the Fedora Council which were shaped by the
> > Community.
>
> Do you mean
>
> https://lists.fedoraproject.org/archives/list/council-disc...@lists.fedoraproject.org/thread/OEPDGVKYAJIQ6YYZU5J3XT3LHXFROFI5/
> ? I can't find anything else.
>

Yes.

>
> Sincelery, after reading the initial announcement, I was expecting a
> more visible and open to the community discussion scenario.
> >
> > 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
> >
> > This thread is also part of the open conversation on the decision.
>
> No, this is a post decision conversation, not the promised open and live
> discussions *during* the process.
>

We haven't ironed out the full details but what was incredibly clear to us
was that Gitlab was the decision to make. The next step in getting there is
what we are engaging in now to get thoughts and suggestions and expect
several threads in that capacity from a technical perspective in the coming
weeks and months.

>
> >
> >
> > Thanks,
> > 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 
> >
> > Communications House
> >
> > Cork Road, Waterford City
> >
> > lgrif...@redhat.com 
> > M: +353877545162  IM: lgriffin
> >
> > @redhatjobs    redhatjobs
> >  @redhatjobs
> > 
> > 
> >
> >
> > ___
> > 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
> >
>
> --
> Julen Landa Alustiza 
> ___
> 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 

Communications House

Cork Road, Waterford City

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


___
devel mailing 

Re: CPE Git Forge Decision

[Leigh Griffin]

On Mon, Mar 30, 2020 at 11:19 AM Daniel P. Berrangé 
wrote:

> On Mon, Mar 30, 2020 at 10:17:21AM +0100, Leigh Griffin wrote:
> > Hi everyone,
> >
> > Thank you for your patience while the CPE Team worked through an
> incredible
> > number of requirements from multiple stakeholder sources. On Friday
> evening
> > we announced on the Community Blog
> > 
> our
> > decision to adopt Gitlab as our Git Forge and to retain pagure.io to
> > ultimately hand over to the Community to maintain. It wasn't an easy
> > decision by any stretch of the imagination and we hope that the
> compromise
> > that we are striking will help to allow Pagure flourish and to give a
> > choice of Forges for your usage. I'm happy to field any questions or
> > comments about this decision.
>
> Overall I understand the decision to focus on GitLab & think it makes a lot
> of sense given the precedent of other large open source projects adopting
> it. I was always sceptical that there were enough resources invested to
> turn Pagure into a strong competitor, especially when other large projects
> that could have been potential users & contributors of Pagure (GNOME,
> FreeDesktop, KDE, etc) all picked GitLab.
>
>
> That said I have some issues with the blog. It doesn't distiguish very well
> between Pagure as the dist-git instance, and Pagure as a general "upstream"
> project hosting instance, so it is hard to intepret what applies to what.
> The language is murky & contradictory


>  "Keep Pagure running with our oversight while we analyse a sunset
>   timeline which will give a minimum of 12 months notice once we
>   have a plan firmed up. We will fix blocker bugs, address critical
>   vulnerabilities and keep the lights on in the same manner that we
>   have committed to over the last 14 months where Pagure has not
>   been a staffed and supported initiative."
>
The word "sunset" here tells me that pagure.io is going away and we'll need
> to move projects off it. Similarly the last sentence reinforces that Pagure
> is considered abandonware.
>

We will continue with Pagure as a dist-git AND as a project hosting service
for a minimum of 12 months once we have a timeline established. That could
see the status quo remain for several months on top of that 12 month clock.


>
> At the same time the blog says "we do not want to abandon Pagure" and
>
>"provide them with guidance and oversight to help the Pagure
> Community grow. We recognise that this is a growing and
> unique ecosystem and we genuinely want to see it succeed and
> will do our best to support it in that capacity"
>
> which says that pagure.io is intended to carry on living and even grow.
>

We will continue to host pagure.io for the foreseeable future but like all
apps that we currently host or maintain, we will evaluate the difficulty in
maintenance and strive for more community involvement in their upkeep as
CPE cannot own and maintain every single Fedora application.


>
> And
>
>   "Offer the maintenance of pagure.io to anyone in the community
>interested in leading it."
>
> which says we want to abandon it, but perhaps some kind person might step
> in to rescue it, but we've no idea who that will be aside from some
> community
> group yet to be clearly identified.
>

Put simply, CPE will not be driving the long term maintenance and growth of
Pagure. We want the community to drive this and lead the way and give it
the time and attention that we cannot. We will provide power and ping and
try our best to keep it on the air but we would hope to have assistance
with the latter as time goes on and if we get to a point where we can even
hand the power and ping aspects over, then we will certainly do that to
ensure Pagure has a future that is in the community's own hands.


>
> Overall I'm left with zero confidence about the future of general project
> hosting on pagure.io


I hope the above gives some clarity and confidence that pagure.io as a
project hosting service is not going away any time soon, if ever.

>
>
> Having lived through Fedora Hosted arriving and then being killed, and
> now Pagure arriving and then being killed, I don't have any confidence
> in the future. Better to accept now that general project hosting is never
> going to be a core deliverable of Fedora


I need to correct you here, is not a core deliverable of the CPE team. Our
mission statement does not extend to Pagure and project hosting and we made
that clear several months back. I can't speak for Fedora and would urge you
to take that conversation up with the Council.


> and projects should focus on the
> primary gitlab.com instance if they need hosting that has got a chance of
> still existing in 3-5 years time.
>
> Regards,
> Daniel
> --
> |: https://berrange.com  -o-
> https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org -o-
> https://fstop138.berrange.com :|
> |: 

Re: CPE Git Forge Decision

[Miro Hrončok]

On 30. 03. 20 11:17, Leigh Griffin wrote:

Hi everyone,

Thank you for your patience while the CPE Team worked through an incredible 
number of requirements from multiple stakeholder sources. On Friday evening we 
announced on the Community Blog 
 our 
decision to adopt Gitlab as our Git Forge and to retain pagure.io 
 to ultimately hand over to the Community to maintain. It 
wasn't an easy decision by any stretch of the imagination and we hope that the 
compromise that we are striking will help to allow Pagure flourish and to give a 
choice of Forges for your usage. I'm happy to field any questions or comments 
about this decision.



We are opting for GitLab for our dist git and project hosting and will continue
to run pagure.io with community assistance.
If no one steps up to pick the maintenance of pagure.io, it will be a candidate 
> application to sunset.



Let's consider what happens if/when pagure.io eventually dies, because there 
will be nobody to community-run it.


Ticketing instances of Fedora bodies (Council, FESCo, Mindshare, FPC, releng, 
infra...) need to be migrated away from pagure.io. Where do they go? Will there 
be a non-distgit GitLab Fedora instance as well?


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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

Re: CPE Git Forge Decision

[Julen Landa Alustiza]

20/3/30 12:04(e)an, Leigh Griffin igorleak idatzi zuen:
> 
> 
> On Mon, Mar 30, 2020 at 10:55 AM Iñaki Ucar  > wrote:
> 
> Hi Leigh,
> 
> On Mon, 30 Mar 2020 at 11:30, Leigh Griffin  > wrote:
> >
> > Hi everyone,
> >
> > Thank you for your patience while the CPE Team worked through an
> incredible number of requirements from multiple stakeholder sources.
> On Friday evening we announced on the Community Blog our decision to
> adopt Gitlab as our Git Forge and to retain pagure.io
>  to ultimately hand over to the Community to
> maintain. It wasn't an easy decision by any stretch of the
> imagination and we hope that the compromise that we are striking
> will help to allow Pagure flourish and to give a choice of Forges
> for your usage. I'm happy to field any questions or comments about
> this decision.
> 
> My question is, where's the open conversation about the requirements
> gathered that you promised in the initial thread?
> 
> 
> Hey Iñaki, we have had several rounds of open conversation facilitated
> via the Council threads on it to arrive on what the requirements were
> for the Fedora Project. This ultimately concluded with the formal
> requirements received from the Fedora Council which were shaped by the
> Community.

Do you mean
https://lists.fedoraproject.org/archives/list/council-disc...@lists.fedoraproject.org/thread/OEPDGVKYAJIQ6YYZU5J3XT3LHXFROFI5/
? I can't find anything else.

Sincelery, after reading the initial announcement, I was expecting a
more visible and open to the community discussion scenario.
> 
> 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
> 
> This thread is also part of the open conversation on the decision.

No, this is a post decision conversation, not the promised open and live
discussions *during* the process.

> 
> 
> Thanks,
> 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 
> 
> Communications House
> 
> Cork Road, Waterford City
> 
> lgrif...@redhat.com     
> M: +353877545162      IM: lgriffin
> 
> @redhatjobs    redhatjobs
>  @redhatjobs
>   
> 
> 
> 
> ___
> 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
> 

-- 
Julen Landa Alustiza 
___
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

Re: CPE Git Forge Decision

[Iñaki Ucar]

On Mon, 30 Mar 2020 at 12:15, Leigh Griffin  wrote:
>
> On Mon, Mar 30, 2020 at 10:55 AM Iñaki Ucar  wrote:
>>
>> Hi Leigh,
>>
>> On Mon, 30 Mar 2020 at 11:30, Leigh Griffin  wrote:
>> >
>> > Hi everyone,
>> >
>> > Thank you for your patience while the CPE Team worked through an 
>> > incredible number of requirements from multiple stakeholder sources. On 
>> > Friday evening we announced on the Community Blog our decision to adopt 
>> > Gitlab as our Git Forge and to retain pagure.io to ultimately hand over to 
>> > the Community to maintain. It wasn't an easy decision by any stretch of 
>> > the imagination and we hope that the compromise that we are striking will 
>> > help to allow Pagure flourish and to give a choice of Forges for your 
>> > usage. I'm happy to field any questions or comments about this decision.
>>
>> My question is, where's the open conversation about the requirements
>> gathered that you promised in the initial thread?
>
>
> Hey Iñaki, we have had several rounds of open conversation facilitated via 
> the Council threads on it to arrive on what the requirements were for the 
> Fedora Project. This ultimately concluded with the formal requirements 
> received from the Fedora Council which were shaped by the Community.
>
> 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
>
> This thread is also part of the open conversation on the decision.

I was referring to, and I was expecting, an open conversation about
the User Story list, an open analysis of the requirements list. In
other words:

1. Open conversation to gather requirements. Done.
2. Publication of User Story list.
3. Open conversation to discuss (2).
4. Publication of the final decision.

I was expecting (3), and it's missing.

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

Re: CPE Git Forge Decision

[Daniel P . Berrangé]

On Mon, Mar 30, 2020 at 10:17:21AM +0100, Leigh Griffin wrote:
> Hi everyone,
> 
> Thank you for your patience while the CPE Team worked through an incredible
> number of requirements from multiple stakeholder sources. On Friday evening
> we announced on the Community Blog
>  our
> decision to adopt Gitlab as our Git Forge and to retain pagure.io to
> ultimately hand over to the Community to maintain. It wasn't an easy
> decision by any stretch of the imagination and we hope that the compromise
> that we are striking will help to allow Pagure flourish and to give a
> choice of Forges for your usage. I'm happy to field any questions or
> comments about this decision.

Overall I understand the decision to focus on GitLab & think it makes a lot
of sense given the precedent of other large open source projects adopting
it. I was always sceptical that there were enough resources invested to
turn Pagure into a strong competitor, especially when other large projects
that could have been potential users & contributors of Pagure (GNOME,
FreeDesktop, KDE, etc) all picked GitLab.


That said I have some issues with the blog. It doesn't distiguish very well
between Pagure as the dist-git instance, and Pagure as a general "upstream"
project hosting instance, so it is hard to intepret what applies to what.
The language is murky & contradictory

 "Keep Pagure running with our oversight while we analyse a sunset 
  timeline which will give a minimum of 12 months notice once we 
  have a plan firmed up. We will fix blocker bugs, address critical 
  vulnerabilities and keep the lights on in the same manner that we
  have committed to over the last 14 months where Pagure has not 
  been a staffed and supported initiative."

The word "sunset" here tells me that pagure.io is going away and we'll need
to move projects off it. Similarly the last sentence reinforces that Pagure
is considered abandonware.

At the same time the blog says "we do not want to abandon Pagure" and

   "provide them with guidance and oversight to help the Pagure 
Community grow. We recognise that this is a growing and 
unique ecosystem and we genuinely want to see it succeed and
will do our best to support it in that capacity"

which says that pagure.io is intended to carry on living and even grow.

And 

  "Offer the maintenance of pagure.io to anyone in the community 
   interested in leading it."

which says we want to abandon it, but perhaps some kind person might step
in to rescue it, but we've no idea who that will be aside from some community
group yet to be clearly identified.

Overall I'm left with zero confidence about the future of general project
hosting on pagure.io

Having lived through Fedora Hosted arriving and then being killed, and
now Pagure arriving and then being killed, I don't have any confidence
in the future. Better to accept now that general project hosting is never
going to be a core deliverable of Fedora and projects should focus on the
primary gitlab.com instance if they need hosting that has got a chance of
still existing in 3-5 years time.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
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

Re: CPE Git Forge Decision

[Leigh Griffin]

On Mon, Mar 30, 2020 at 10:55 AM Iñaki Ucar  wrote:

> Hi Leigh,
>
> On Mon, 30 Mar 2020 at 11:30, Leigh Griffin  wrote:
> >
> > Hi everyone,
> >
> > Thank you for your patience while the CPE Team worked through an
> incredible number of requirements from multiple stakeholder sources. On
> Friday evening we announced on the Community Blog our decision to adopt
> Gitlab as our Git Forge and to retain pagure.io to ultimately hand over
> to the Community to maintain. It wasn't an easy decision by any stretch of
> the imagination and we hope that the compromise that we are striking will
> help to allow Pagure flourish and to give a choice of Forges for your
> usage. I'm happy to field any questions or comments about this decision.
>
> My question is, where's the open conversation about the requirements
> gathered that you promised in the initial thread?
>

Hey Iñaki, we have had several rounds of open conversation facilitated via
the Council threads on it to arrive on what the requirements were for the
Fedora Project. This ultimately concluded with the formal requirements
received from the Fedora Council which were shaped by the Community.

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

This thread is also part of the open conversation on the decision.

>
> Thanks,
> 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 

Communications House

Cork Road, Waterford City

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


___
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

Re: CPE Git Forge Decision

[Iñaki Ucar]

Hi Leigh,

On Mon, 30 Mar 2020 at 11:30, Leigh Griffin  wrote:
>
> Hi everyone,
>
> Thank you for your patience while the CPE Team worked through an incredible 
> number of requirements from multiple stakeholder sources. On Friday evening 
> we announced on the Community Blog our decision to adopt Gitlab as our Git 
> Forge and to retain pagure.io to ultimately hand over to the Community to 
> maintain. It wasn't an easy decision by any stretch of the imagination and we 
> hope that the compromise that we are striking will help to allow Pagure 
> flourish and to give a choice of Forges for your usage. I'm happy to field 
> any questions or comments about this decision.

My question is, where's the open conversation about the requirements
gathered that you promised in the initial thread?

Thanks,
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

Re: CPE Git Forge Decision

[Guido Aulisi]

Il giorno lun 30 mar 2020 alle 11:21 Leigh Griffin  ha
scritto:

> Hi everyone,
>
> Thank you for your patience while the CPE Team worked through an
> incredible number of requirements from multiple stakeholder sources. On
> Friday evening we announced on the Community Blog
>  our
> decision to adopt Gitlab as our Git Forge and to retain pagure.io to
> ultimately hand over to the Community to maintain. It wasn't an easy
> decision by any stretch of the imagination and we hope that the compromise
> that we are striking will help to allow Pagure flourish and to give a
> choice of Forges for your usage. I'm happy to field any questions or
> comments about this decision.
>

I don’t agree with this. Pagare is the right tool for all.

Kind regards,
> Leigh, on behalf of the CPE Team
>
> --
>
> Leigh Griffin
>
> Engineering Manager
>
> Red Hat Waterford 
>
> Communications House
>
> Cork Road, Waterford City
>
> lgrif...@redhat.com
> M: +353877545162 IM: lgriffin
> @redhatjobs    redhatjobs
>  @redhatjobs
> 
> 
> ___
> 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

CPE Git Forge Decision

[Leigh Griffin]

Hi everyone,

Thank you for your patience while the CPE Team worked through an incredible
number of requirements from multiple stakeholder sources. On Friday evening
we announced on the Community Blog
 our
decision to adopt Gitlab as our Git Forge and to retain pagure.io to
ultimately hand over to the Community to maintain. It wasn't an easy
decision by any stretch of the imagination and we hope that the compromise
that we are striking will help to allow Pagure flourish and to give a
choice of Forges for your usage. I'm happy to field any questions or
comments about this decision.

Kind regards,
Leigh, on behalf of the CPE Team

-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford 

Communications House

Cork Road, Waterford City

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


___
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