Re: CPE Git Forge Decision

[Aleksandra Fedorova]

On Mon, 6 Apr 2020, 21:26 clime,  wrote:

> On Mon, 6 Apr 2020 at 17:52, Leigh Griffin  wrote:
> >
> >
> >
> > On Mon, Apr 6, 2020 at 4:25 PM Adam Williamson <
> adamw...@fedoraproject.org> wrote:
> >>
> >> On Mon, 2020-04-06 at 15:35 +0100, Leigh Griffin wrote:
> >> >
> >> > > Does it mean you didn't consider dist-git<->zuul integration vs.
> Gitlab
> >> > > CI? I.e. technical differences and advantages of each? If you did,
> can you,
> >> > > please, publish it? It would be valuable info for the community and
> >> > > something we can comment on.
> >> > >
> >> >
> >> > Gitlab CI was not part of our evaluation, we are aware it's a service
> that
> >> > is offered but did not evaluate it as it wasn't within the scope of
> our
> >> > exercise.
> >>
> >> So, how does that track with this quote from the decision blog post?
> >>
> >> "Some top level requirements which helped us arrive at this decision
> >> [to choose Gitlab]:
> >>
> >> There is a need for CentOS Stream to integrate with a kernel workflow
> >> that is an automated bot driven merging solution (merge trains). This
> >> allows for richer CI capabilities and minimises the need for human
> >> interaction"
> >>
> >> If you did not evaluate Gitlab CI (and presumably CI capabilities of
> >> the three systems more widely), how did the need for a CI feature -
> >> that is what "merge trains" are - act as a "top level requirement"
> >> which "helped us arrive at this decision"?
> >
> >
> > I'm talking specifically about CI as a capability, in that specific
> integrations at a CI level for hooks and other nice stuff which has several
> known issues in Pagure at an API level, we evaluated that high level
> requirement. Some stakeholders do not want to use the built in Gitlab CI as
> we have CentOS CI used extensively and some have homebrewed systems that
> they use. Hence why we did not go deep on CI at a very functional level
> outside of known limitations and desires that came up as direct
> requirements.
> >
> > Merge trains and that capability is plugin / CI based and was explicit
> in it's scope (it was called out as a need to have merge train
> functionality) Vs CI in general as it was named as a need. We had discussed
> that Zuul was a possibility around Pagure as part of that.
>
> Discussed with whom, do you have logs? You didn't provide any material
> from which the conclusions could be reproducibly drawn, you just came
> and told us: "Hey, we decided this and this, you don't have any other
> choice than to comply". It doesn't work like that or at least it
> shouldn't, in my opinion.
>
> It doesn't seem that you have considered CI future for Fedora _at
> all_, i.e. work needed for pagure-based solution vs. work needed for
> gitlab-based solution. Sorry but if you don't have a clear and
> presentable vision of the different setups and how they compare to
> each other with respect to initial setup, maintenance cost, and
> feature set relevant for packager workflows, you shouldn't be making
> decisions like those. Your "let's go to Gitlab" is shooting in the
> dark at best.
>

Let me add here: we had conversation on CI with CPE both as Fedora CI SIG
and as RHEL CI team.

We do want to keep existing CI infrastructure based on message exchange
with distributed CI systems. As Gitlab has API and messages in a certain
form, I don't expect huge problems here.

And we mentioned Zuul in that conversation. We discussed the possibility
for Zuul to work with Gitlab at Devconf in January. And my understanding
alignes with what Fabien said in this thread, that Zuul _can_ work with
Gitlab. Though it might require some adjustments.

Personally, I believe that Zuul is superior to any other CI system when it
comes to managing pull-requests workflow, and I would like to see its usage
increased in Fedora and beyond. But I think changing the Git Forge to
Gitlab doesn't on its own create a problem for this view.

What I would consider a problem: if we take Gitlab as GitForge, but then
users start to request more "nice features", more "easy integrations" and
more Gitlab-specific workflows... The git forge itself is not as harmful,
as the scope creep in can bring.

But this is not something the CPE team should manage alone, it is us as
users who need to be disciplined in the usage of this tool and our requests
to it.



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

[Matthew Miller]

For what it's worth, Jeremy, Randy, and others: I absolutely value your
contributions both now and in the past. Members of the the Fedora
Engineering team and CPE in all previous and current names and incarnations
have done and continue to do amazing things which have beeen *essentially*
valuable to the Fedora Project and community.

-- 
Matthew Miller

Fedora Project Leader
Not the Pope
___
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, 7 Apr 2020 at 03:08, Randy Barlow  wrote:
>
> On 4/6/20 6:37 AM, Leigh Griffin wrote:
> > I'm sorry if you took my mail up as implying a lack of value from how
> > the team historically worked. As a team we are being tasked more and
> > more with adding what I call real value which is at a new app / service
> > level that has scale, quality and requirements that historically a
> > single developer could not call on. We had some superhuman developers in
> > the past in the team that were able to do every single thing an
> > application needed and produced some wonderful applications that in
> > truth would have taken 10 or more developers to replicate. That team has
> > moved on now and the old style of working was not going to meet the
> > needs and wants of our stakeholders (in this case Fedora Council) and a
> > repurposing of the team to make visible impacts was undertaken. So while
> > we cannot have multiple commits across a plethora of services, we are
> > not focusing our efforts on singular services at a time to generate a
> > value proposition for the community. Sorry once again if you took my
> > comment up as being a sleight, it was most definitely not intended and
> > you have my sincere apologies.
>
> There's more wrong with the above than I already pointed out. In this
> paragraph, you:
>
> * Double down the message of implying the the work done in the past
>didn't add real value,
> * Insult your current team, implying that they haven't reached the
>apparently "superhuman" standards of the past,
> * Triple down on disparaging the efforts of past developers by implying
>that only now is the work of the CPE team having "visible impacts".

C'mon, he didn't imply anything or insult anyone, you are just
twisting his message for sport. He apologised several times already
about this. Move on.

-- 
Iñaki Úcar
___
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 Wed, 2020-04-01 at 09:54 -0700, Adam Williamson wrote:
> On Wed, 2020-04-01 at 15:08 +0100, Leigh Griffin wrote:
> > On Wed, Apr 1, 2020 at 2:47 PM Frank Ch. Eigler 
> > wrote:
> > 
> > > > [...] Nor would it have helped with the SLA requirements and
> > > > operational cost. [...]
> > > 
> > > What reason is there to believe that a gitlab commercial SaaS
> > > might a
> > > smaller operational cost?
> > > 
> > 
> > I meant that in the sense of the time we invest in it to develop
> > features,
> > fix bugs, keep it on the air etc.
> 
> Has an actual cost evaluation been done that suggests the cost of
> buying Gitlab SaaS will be less than the cost would be to hire
> sufficient people to do that work, though? Or is this simply a case
> where it's considered Good to spend money on outsourcing and Bad to
> spend it on paying people, based on only an *assumption* that the
> former is always cheaper?

Great question Adam, I would like to know that too.

Jirka
___
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 Mon, Apr 06, 2020 at 16:02:34 +0100,
 Leigh Griffin  wrote:


Our stakeholder and engagement point as a team is Fedora Council. If you
have issues with how this was handled from a relationship perspective then
please take that up with the Council. We have engaged with fesco in the
past at the request of Council and will engage with them in the future in a
similar manner.


I think this is a good idea. While it is clear a lot of people participating 
in this discussion don't like what or how things happened. We can't each 
decide how things are going to be or we will have a lot of conflicting 
action plans. Further arguing with Leigh doesn't seem likely to be very 
productive. Given the tone of some of the replies, Leigh has been 
surprisingly gracious in continuing to engage on this mailing list.


We should be taking this up with the council to see what is possible and 
how we might proceed forward. 
___

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

[Randy Barlow]

On 4/6/20 6:37 AM, Leigh Griffin wrote:
I'm sorry if you took my mail up as implying a lack of value from how 
the team historically worked. As a team we are being tasked more and 
more with adding what I call real value which is at a new app / service 
level that has scale, quality and requirements that historically a 
single developer could not call on. We had some superhuman developers in 
the past in the team that were able to do every single thing an 
application needed and produced some wonderful applications that in 
truth would have taken 10 or more developers to replicate. That team has 
moved on now and the old style of working was not going to meet the 
needs and wants of our stakeholders (in this case Fedora Council) and a 
repurposing of the team to make visible impacts was undertaken. So while 
we cannot have multiple commits across a plethora of services, we are 
not focusing our efforts on singular services at a time to generate a 
value proposition for the community. Sorry once again if you took my 
comment up as being a sleight, it was most definitely not intended and 
you have my sincere apologies.


There's more wrong with the above than I already pointed out. In this 
paragraph, you:


* Double down the message of implying the the work done in the past
  didn't add real value,
* Insult your current team, implying that they haven't reached the
  apparently "superhuman" standards of the past,
* Triple down on disparaging the efforts of past developers by implying
  that only now is the work of the CPE team having "visible impacts".
___
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

[Dan Čermák]

Leigh Griffin  writes:

>> If you had stopped at the first
>> objections and revisited the decision making process with the rest of
>> the community involved in an open manner, you would have been forgiven,
>> because everyone here is trying to assume good faith. Alas, you haven't
>> done that. Apologizing for your mistakes is a necessary step, but it's
>> not sufficient.
>>
>
> Ok let's scenario this out so as several people want us to restart and go
> again, largely because they disagree with the decision and Pagure is the
> choice that they would have made. If we re-engage now, I firmly believe we
> will get a whole new set of requirements to complement the existing
> requirements but scoped deliberately (as has been suggested by numerous
> replies) to a situation where Pagure is the only choice for Fedora.

And how will that be different from your initial set of requirements,
that had far too surprising similarities to GitLab EE's features?

I really don't like to jump in and start pointing fingers, but during
the initial discussion of the requirements, it was pointed out multiple
times that all of this looks like a pretense to ditch Pagure for
Gitlab. So honestly, I really don't see how that would make the process
so far more unfair (it would actually make it more fair to all Fedora
contributors who value Pagure & the associated values and who are
feeling increasingly ignored and betrayed).


Regards,

Dan


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

[clime]

On Mon, 6 Apr 2020 at 17:52, Leigh Griffin  wrote:
>
>
>
> On Mon, Apr 6, 2020 at 4:25 PM Adam Williamson  
> wrote:
>>
>> On Mon, 2020-04-06 at 15:35 +0100, Leigh Griffin wrote:
>> >
>> > > Does it mean you didn't consider dist-git<->zuul integration vs. Gitlab
>> > > CI? I.e. technical differences and advantages of each? If you did, can 
>> > > you,
>> > > please, publish it? It would be valuable info for the community and
>> > > something we can comment on.
>> > >
>> >
>> > Gitlab CI was not part of our evaluation, we are aware it's a service that
>> > is offered but did not evaluate it as it wasn't within the scope of our
>> > exercise.
>>
>> So, how does that track with this quote from the decision blog post?
>>
>> "Some top level requirements which helped us arrive at this decision
>> [to choose Gitlab]:
>>
>> There is a need for CentOS Stream to integrate with a kernel workflow
>> that is an automated bot driven merging solution (merge trains). This
>> allows for richer CI capabilities and minimises the need for human
>> interaction"
>>
>> If you did not evaluate Gitlab CI (and presumably CI capabilities of
>> the three systems more widely), how did the need for a CI feature -
>> that is what "merge trains" are - act as a "top level requirement"
>> which "helped us arrive at this decision"?
>
>
> I'm talking specifically about CI as a capability, in that specific 
> integrations at a CI level for hooks and other nice stuff which has several 
> known issues in Pagure at an API level, we evaluated that high level 
> requirement. Some stakeholders do not want to use the built in Gitlab CI as 
> we have CentOS CI used extensively and some have homebrewed systems that they 
> use. Hence why we did not go deep on CI at a very functional level outside of 
> known limitations and desires that came up as direct requirements.
>
> Merge trains and that capability is plugin / CI based and was explicit in 
> it's scope (it was called out as a need to have merge train functionality) Vs 
> CI in general as it was named as a need. We had discussed that Zuul was a 
> possibility around Pagure as part of that.

Discussed with whom, do you have logs? You didn't provide any material
from which the conclusions could be reproducibly drawn, you just came
and told us: "Hey, we decided this and this, you don't have any other
choice than to comply". It doesn't work like that or at least it
shouldn't, in my opinion.

It doesn't seem that you have considered CI future for Fedora _at
all_, i.e. work needed for pagure-based solution vs. work needed for
gitlab-based solution. Sorry but if you don't have a clear and
presentable vision of the different setups and how they compare to
each other with respect to initial setup, maintenance cost, and
feature set relevant for packager workflows, you shouldn't be making
decisions like those. Your "let's go to Gitlab" is shooting in the
dark at best.

clime

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

[Sheogorath via devel]

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 actually have just one question about this decision, because so far,
and I read a lot, but not all mails regarding this, haven't answered
that:

Let's say the scenario is that we run GitLab EE for Fedora. Can we
make sure that at least all customization and modifications that are
done by Fedora contributors or in the name of Fedora executed by the
Gitlab team, will end up in GitLab-foss i.e. open source?

And what really makes me wonder in the whole process: According to
various mails from the CPE the deal that will come out, like features,
price, … is not yet figured out. Not even the plan what GitLab version
CPE is about to go for. But the decision to go for GitLab is already
made? How does that work and isn't that basically torpedoing every
price negotiation?

Hope we can figure those questions out.

-- 
Signed
Sheogorath

OpenPGP: https://shivering-isles.com/openpgp/0xFCB98C2A3EC6F601.txt


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

[David Kaufmann]

On Mon, Apr 06, 2020 at 04:02:34PM +0100, Leigh Griffin wrote:
> Ok let's scenario this out so as several people want us to restart […]

In this context of "restarting the scenario":

> How do we accommodate that when our other stakeholders' needs are now
> not being met as a whole and when the original requirements needs are
> being satisfied by the choice of Gitlab (which will most likely be CE
> for Fedora).

This is to be taken with a grain of salt. There are quite a few people
in this thread mentioning that it conflicts with the Fedora mission
statement - which I'd see as being part of the original requirements
implicitely. This might be less problematic with GitLab CE, which I
assume seems to be the current plan.

> What happens then, how do you suggest we proceed at that point? The
> other stakeholder groups are already progressing with Gitlab and we
> can do that for them and pause the Fedora move in this direction if
> that was the scenario. What happens after months of debate if we
> cannot bridge that divide?

That is very easy. If it is not *possible* to have a common solution, it
is necessary to have separate solutions. Everything else would be
forcing a stakeholder to a solution not meeting their requirements.

And yes, if one stakeholder (eg. Fedora) just insists on Pagure, and
another stakeholder (maybe that internal RedHat group?) just insists on
GitLab, you can either force the decision, or have both.

> What happens when Pagure is sunset as the CPE team cannot run it /
> maintain it? I'm genuinely curious here as if this is a path the
> community want to go down then engage with Council on it but I think it
> could be harmful for the project as a whole.

If Fedora continues to use Pagure, and the RedHat internal group uses
GitLab, and CPE sunsets Pagure, this means, another team needs to take
over.
(Which is not a GDPR problem as long as there is no data in there which
is not allowed to be there anyway. Even then access can be provided, if
necessary)

After that the CPE does not have fedora-dist-management on their plate
anymore and can focus on different things.

Budget: Depending on what percentage of CPE teams duties are seen as
fedora-specific-dist-management that might also mean some reduction in
size of the CPE team in favor of the new fedora-dist-management-team.
(Can also be seen as some people switching from CPE to the new team)

Later it might be possible for migrating the RedHat internal group on
Pagure, or Fedora on GitLab, but that needs to come from inside the
community/team, and not be forced on a community/team.

> That's not my choice though and until otherwise told, we are
> progressing in this direction.

With this you're actively choosing to continue acting following *your*
decision.

As mentioned in another post, it might be best to pause the whole thing
for some time, an then try another path on how to proceed forward.
(There is no reset, what has been done can't be just "reversed")

And yes, this means not pushing for a solution in the "pause time", and
yes, this also means no dicussions with GitLab, and no trying to make
Pagure more GitLab like, no waiting until the dust settles to just
continue with the GitLab path, and no forcing the "pause time" to be so
long, that Pagure is chosen due to process stalling.

That means first focussing on how to resolve the situation, before
taking another step. It's obvious that there is a big problem right now,
and it needs to be addressed first.

If it is important to you that some formal body pauses the process and
not yourself, please either name that entity or preferably request a
statement about pausing or continuing the planned process yourself.
From other emails it seems this formal body is the Council, but I'd like
to have a confirmation for that assumption.

All the best,
David


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

[clime]

On Mon, 6 Apr 2020 at 17:05, Leigh Griffin  wrote:

>
>
> On Mon, Apr 6, 2020 at 2:36 PM Dominik 'Rathann' Mierzejewski <
> domi...@greysector.net> wrote:
>
>> On Monday, 06 April 2020 at 12:29, Leigh Griffin wrote:
>> [...]
>> > > Yes, this whole "decision" is in dictatorship relation to the
>> > > community.
>> > >
>> > > Not following the standard procedures caused that I and probably
>> > > many people in the community didn't pay much attention to it.
>> >
>> > We followed the procedures that were outlined to us.
>>
>> So you think "just following procedures" makes it all right and gives
>> you mandate to continuing to pursue a decision that the community is
>> telling you was wrong despite your following procedures?
>>
>
> Our stakeholder and engagement point as a team is Fedora Council. If you
> have issues with how this was handled from a relationship perspective then
> please take that up with the Council. We have engaged with fesco in the
> past at the request of Council and will engage with them in the future in a
> similar manner.
>
>
>>
>> > > I thought you are simply going to collect requirements and then we
>> > > will talk. Collecting the requirements was actually very useful.
>> > > Providing the analysis for the requirements would be useful.
>> > > Providing a recommendation would be ok. Providing a "decision" like
>> > > that crosses the line.
>> > >
>> > > It sends quite a bad message that no matter what you start doing for
>> > > the community and how useful it becomes, RH management can come at
>> > > any time and make your work vanish, which is what is happening here
>> > > with pagure on dist-git effort and probably also zuul efforts might
>> > > get replaced by Gitlab CI.
>> >
>> > We have nothing to do with zuul and Gitlab CI may be made available as
>> > a service if folks want to use it.
>>
>> It's not just about CI. You only commented about the least significant
>> point of the above paragraph and ignored the rest. That seems to be the
>> pattern with your communication. Please change that.
>>
>
> What point would you like me to comment on? Red Hat is not making work
> vanish, we are not deleting Pagure from the internet.
>

Note that I was explicit:

"RH management can come at any
time and make your work vanish, which is what is happening here with
pagure on dist-git effort and probably also zuul efforts might get
replaced by Gitlab CI."

You took it completely somewhere else.

clime


>
>
>>
>> [...]
>> > > But still, please, listen to what the community is telling you.
>> >
>> > We are.
>>
>> That's not the impression you are giving here.
>>
>> > > While you may have means to force your decision as RH management
>> > > representative, doing so can be damaging for both sides (RH and
>> > > Fedora).
>> >
>> > We are not forcing a decision. We are still engaged with the Fedora
>> > Council on next steps and factoring in the requirements of the
>> > community. Right now, our wider needs are saying we cannot support
>> > Pagure and we intend on replacing that with Gitlab from a CPE
>> > perspective.
>>
>> You are forcing a decision because you're refusing to revisit the
>> decision you have made *for* the community without the engagement that
>> the community feels was required.
>
>
> This decision is made for 2x communities, 1x internal stakeholder and the
> CPE team. This decision is impacting 4 groups. If you feel so strongly that
> the decision should be revisited in some way shape or form, make your
> protests known to the Fedora Council. We engage at that level.
>
>
>> If you had stopped at the first
>> objections and revisited the decision making process with the rest of
>> the community involved in an open manner, you would have been forgiven,
>> because everyone here is trying to assume good faith. Alas, you haven't
>> done that. Apologizing for your mistakes is a necessary step, but it's
>> not sufficient.
>>
>
> Ok let's scenario this out so as several people want us to restart and go
> again, largely because they disagree with the decision and Pagure is the
> choice that they would have made. If we re-engage now, I firmly believe we
> will get a whole new set of requirements to complement the existing
> requirements but scoped deliberately (as has been suggested by numerous
> replies) to a situation where Pagure is the only choice for Fedora. How do
> we accommodate that when our other stakeholders' needs are now not being
> met as a whole and when the original requirements needs are being satisfied
> by the choice of Gitlab (which will most likely be CE for Fedora). What
> happens then, how do you suggest we proceed at that point? The other
> stakeholder groups are already progressing with Gitlab and we can do that
> for them and pause the Fedora move in this direction if that was the
> scenario. What happens after months of debate if we cannot bridge that
> divide? What happens when Pagure is sunset as the CPE team cannot run it /
> maintain it? I'm genuinely curious

Re: CPE Git Forge Decision

[Leigh Griffin]

On Mon, Apr 6, 2020 at 4:25 PM Adam Williamson 
wrote:

> On Mon, 2020-04-06 at 15:35 +0100, Leigh Griffin wrote:
> >
> > > Does it mean you didn't consider dist-git<->zuul integration vs. Gitlab
> > > CI? I.e. technical differences and advantages of each? If you did, can
> you,
> > > please, publish it? It would be valuable info for the community and
> > > something we can comment on.
> > >
> >
> > Gitlab CI was not part of our evaluation, we are aware it's a service
> that
> > is offered but did not evaluate it as it wasn't within the scope of our
> > exercise.
>
> So, how does that track with this quote from the decision blog post?
>
> "Some top level requirements which helped us arrive at this decision
> [to choose Gitlab]:
>
> There is a need for CentOS Stream to integrate with a kernel workflow
> that is an automated bot driven merging solution (merge trains). This
> allows for richer CI capabilities and minimises the need for human
> interaction"
>
> If you did not evaluate Gitlab CI (and presumably CI capabilities of
> the three systems more widely), how did the need for a CI feature -
> that is what "merge trains" are - act as a "top level requirement"
> which "helped us arrive at this decision"?
>

I'm talking specifically about CI as a capability, in that specific
integrations at a CI level for hooks and other nice stuff which has several
known issues in Pagure at an API level, we evaluated that high level
requirement. Some stakeholders do not want to use the built in Gitlab CI as
we have CentOS CI used extensively and some have homebrewed systems that
they use. Hence why we did not go deep on CI at a very functional level
outside of known limitations and desires that came up as direct
requirements.

Merge trains and that capability is plugin / CI based and was explicit in
it's scope (it was called out as a need to have merge train functionality)
Vs CI in general as it was named as a need. We had discussed that Zuul was
a possibility around Pagure as part of 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
>


-- 

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

[Randy Barlow]

On 4/6/20 11:17 AM, Leigh Griffin wrote:
It's a form of engagement among others that we are partaking in day in 
day out, week in week out.


Ironically, you have illustrated my point here with your response, which 
isn't engagement.


I have answered every question directly, if I missed one in the multiple 
threads and someone wants it answered, feel free to forward it onto me 
directly and I can answer it.


Much of what people are writing aren't questions, they are arguments. 
You have not been answering those, but have instead been replying with 
non-sequiters, like the above "It's a form of engagement among others…"



Everything is untrue when paraphrased to suit a narrative.


You said "The CPE relationship with stakeholders is unique, it's clear 
the visions are not aligned across all bodies (and we do not expect it 
to be) and we don't have a product." I've demonstrated that this is not 
true.


For sure 
stakeholder misalignment is part and parcel of Engineering life, CPEs 
stakeholder needs, our particular remit and how all of these things 
interact are industry unique in my experience and the kind of alignment 
needed might never be there that One would expect and hope for in a more 
traditional Engineering setting. I'm happy to debate that in a 
separate thread but I feel going into how the team is structured and how 
that relationship works is a distraction that this thread does not need. 


You introduced this distraction, I simply demonstrated that it was not true.
___
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 Mon, 2020-04-06 at 15:35 +0100, Leigh Griffin wrote:
> 
> > Does it mean you didn't consider dist-git<->zuul integration vs. Gitlab
> > CI? I.e. technical differences and advantages of each? If you did, can you,
> > please, publish it? It would be valuable info for the community and
> > something we can comment on.
> > 
> 
> Gitlab CI was not part of our evaluation, we are aware it's a service that
> is offered but did not evaluate it as it wasn't within the scope of our
> exercise.

So, how does that track with this quote from the decision blog post?

"Some top level requirements which helped us arrive at this decision
[to choose Gitlab]:

There is a need for CentOS Stream to integrate with a kernel workflow
that is an automated bot driven merging solution (merge trains). This
allows for richer CI capabilities and minimises the need for human
interaction"

If you did not evaluate Gitlab CI (and presumably CI capabilities of
the three systems more widely), how did the need for a CI feature -
that is what "merge trains" are - act as a "top level requirement"
which "helped us arrive at this decision"?
-- 
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

[Randy Barlow]

On 4/6/20 11:02 AM, Leigh Griffin wrote:
Ok let's scenario this out so as several people want us to restart and 
go again, largely because they disagree with the decision and Pagure is 
the choice that they would have made.


Much of the consternation is due to you not having employed an open 
process, not due to the decision itself. I personally like GitLab, but I 
object to the process used to arrive at it.

___
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, Apr 6, 2020 at 3:49 PM Randy Barlow 
wrote:

> On 4/6/20 10:36 AM, Leigh Griffin wrote:
> > Answering 100+ replies individually is engaging with the community.
> > Happy to stop that if people aren't seeing the benefit of it though.
>
> Writing 100 e-mails isn't automatically "engagement".
>

It's a form of engagement among others that we are partaking in day in day
out, week in week out.


> I could reply to what you wrote above with "If I had a world of my own,
> everything would be nonsense. Nothing would be what it is, because
> everything would be what it isn't. And contrary wise, what is, it
> wouldn't be. And what it wouldn't be, it would. You see?"
>
> But if I did that, it would be disingenuous to claim that I engaged with
> you.
>
> Your posts are not engaging with the community, but are instead an
> avoidance strategy.


I have answered every question directly, if I missed one in the multiple
threads and someone wants it answered, feel free to forward it onto me
directly and I can answer it.


> You aren't meaningfully answering what people are
> saying.


I'm answering to the best of my ability in a truthful and honest way, I
can't help how the responses are being received or interpreted. People are
forming their own opinions and I'm still happy to engage and try and answer
their concerns or thoughts.


> You are putting your fingers in your ears and stating things
> that are clearly untrue, like it being unique to be in a position where
> stakeholders are not aligned.
>

Everything is untrue when paraphrased to suit a narrative. For sure
stakeholder misalignment is part and parcel of Engineering life, CPEs
stakeholder needs, our particular remit and how all of these things
interact are industry unique in my experience and the kind of alignment
needed might never be there that One would expect and hope for in a more
traditional Engineering setting. I'm happy to debate that in a
separate thread but I feel going into how the team is structured and how
that relationship works is a distraction that this thread does not need.
Feel free to reach out directly though Randy if you have specific concerns
I am happy to help where I can.


> ___
> 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, Apr 6, 2020 at 2:36 PM Dominik 'Rathann' Mierzejewski <
domi...@greysector.net> wrote:

> On Monday, 06 April 2020 at 12:29, Leigh Griffin wrote:
> [...]
> > > Yes, this whole "decision" is in dictatorship relation to the
> > > community.
> > >
> > > Not following the standard procedures caused that I and probably
> > > many people in the community didn't pay much attention to it.
> >
> > We followed the procedures that were outlined to us.
>
> So you think "just following procedures" makes it all right and gives
> you mandate to continuing to pursue a decision that the community is
> telling you was wrong despite your following procedures?
>

Our stakeholder and engagement point as a team is Fedora Council. If you
have issues with how this was handled from a relationship perspective then
please take that up with the Council. We have engaged with fesco in the
past at the request of Council and will engage with them in the future in a
similar manner.


>
> > > I thought you are simply going to collect requirements and then we
> > > will talk. Collecting the requirements was actually very useful.
> > > Providing the analysis for the requirements would be useful.
> > > Providing a recommendation would be ok. Providing a "decision" like
> > > that crosses the line.
> > >
> > > It sends quite a bad message that no matter what you start doing for
> > > the community and how useful it becomes, RH management can come at
> > > any time and make your work vanish, which is what is happening here
> > > with pagure on dist-git effort and probably also zuul efforts might
> > > get replaced by Gitlab CI.
> >
> > We have nothing to do with zuul and Gitlab CI may be made available as
> > a service if folks want to use it.
>
> It's not just about CI. You only commented about the least significant
> point of the above paragraph and ignored the rest. That seems to be the
> pattern with your communication. Please change that.
>

What point would you like me to comment on? Red Hat is not making work
vanish, we are not deleting Pagure from the internet.

>
> [...]
> > > But still, please, listen to what the community is telling you.
> >
> > We are.
>
> That's not the impression you are giving here.
>
> > > While you may have means to force your decision as RH management
> > > representative, doing so can be damaging for both sides (RH and
> > > Fedora).
> >
> > We are not forcing a decision. We are still engaged with the Fedora
> > Council on next steps and factoring in the requirements of the
> > community. Right now, our wider needs are saying we cannot support
> > Pagure and we intend on replacing that with Gitlab from a CPE
> > perspective.
>
> You are forcing a decision because you're refusing to revisit the
> decision you have made *for* the community without the engagement that
> the community feels was required.


This decision is made for 2x communities, 1x internal stakeholder and the
CPE team. This decision is impacting 4 groups. If you feel so strongly that
the decision should be revisited in some way shape or form, make your
protests known to the Fedora Council. We engage at that level.


> If you had stopped at the first
> objections and revisited the decision making process with the rest of
> the community involved in an open manner, you would have been forgiven,
> because everyone here is trying to assume good faith. Alas, you haven't
> done that. Apologizing for your mistakes is a necessary step, but it's
> not sufficient.
>

Ok let's scenario this out so as several people want us to restart and go
again, largely because they disagree with the decision and Pagure is the
choice that they would have made. If we re-engage now, I firmly believe we
will get a whole new set of requirements to complement the existing
requirements but scoped deliberately (as has been suggested by numerous
replies) to a situation where Pagure is the only choice for Fedora. How do
we accommodate that when our other stakeholders' needs are now not being
met as a whole and when the original requirements needs are being satisfied
by the choice of Gitlab (which will most likely be CE for Fedora). What
happens then, how do you suggest we proceed at that point? The other
stakeholder groups are already progressing with Gitlab and we can do that
for them and pause the Fedora move in this direction if that was the
scenario. What happens after months of debate if we cannot bridge that
divide? What happens when Pagure is sunset as the CPE team cannot run it /
maintain it? I'm genuinely curious here as if this is a path the
community want to go down then engage with Council on it but I think it
could be harmful for the project as a whole. That's not my choice though
and until otherwise told, we are progressing in this direction.


>
> Regards,
> Dominik
> --
> Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
> There should be a science of discontent. People need hard times and
> oppression to develop psychic muscles.
> 

Re: CPE Git Forge Decision

[Randy Barlow]

On 4/6/20 10:36 AM, Leigh Griffin wrote:
Answering 100+ replies individually is engaging with the community. 
Happy to stop that if people aren't seeing the benefit of it though.


Writing 100 e-mails isn't automatically "engagement".

I could reply to what you wrote above with "If I had a world of my own, 
everything would be nonsense. Nothing would be what it is, because 
everything would be what it isn't. And contrary wise, what is, it 
wouldn't be. And what it wouldn't be, it would. You see?"


But if I did that, it would be disingenuous to claim that I engaged with 
you.


Your posts are not engaging with the community, but are instead an 
avoidance strategy. You aren't meaningfully answering what people are 
saying. You are putting your fingers in your ears and stating things 
that are clearly untrue, like it being unique to be in a position where 
stakeholders are not aligned.

___
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, Apr 6, 2020 at 2:14 PM Neal Gompa  wrote:

> On Mon, Apr 6, 2020 at 8:48 AM Josh Boyer 
> wrote:
> >
> > On Mon, Apr 6, 2020 at 8:42 AM Stasiek Michalski 
> wrote:
> > >
> > > > On Mon, Apr 6, 2020 at 8:26 AM Stasiek Michalski
>  > > >
> > > > Why is it disappointing?  The Pagure project isn't suddenly being
> > > > removed from the internet.  Is there a reason you can't contribute to
> > > > it to add the features you need?
> > >
> > > I can add features, sure, and I do, but I am also not able or willing
> to
> > > maintain everything else that goes with Pagure. My disappointment is
> > > much more of a manifestation of a fear that if CPE ends up going with
> > > Gitlab, there will be nobody else interested enough to maintain it,
> > > since Fedora will no longer have any interest in it.
> >
> > That's a reasonable fear.  However, the only way to guarantee that
> > fear becomes reality is to walk away from the project out of fear.
> >
> > Open source works because people contribute.  If you want the project
> > to live, keep contributing.  You can always reassess who is
> > contributing and what the health of the Pagure community is as you go.
> > Others have said they want to see it succeed, so hopefully they'll
> > also contribute.  If they don't, and Pagure stagnates, then maybe the
> > interest wasn't in building something, it was in having somebody else
> > build it for them.
> >
>
> Yes, but if part of the draw of using Pagure is to federate with other
> servers, the drop in the "network" weakens things.
>
> Folks have said it before on here and other places: they use
> GitHub.com for the network effect. They don't like GitHub, but they
> use it because they value the "network" more than their principles.
> But building a network is not a simple process, and takes time, too.
>
> It's interesting: if you look at the adoption curve for GitLab
> relative to when it was created, Pagure isn't doing that badly. GitLab
> was created in 2011 and most of its adoption/growth started at the end
> of 2015, rising much more dramatically after the end of 2016. Pagure
> was created in 2014 as progit, and then renamed a couple years later.
> Fedora itself only deployed Pagure in 2017, and the CentOS instance
> was rolled out in 2019. Around the same time last year, Pagure was
> introduced to the openSUSE community formally and packaged there.
> Mageia started looking at it in earnest only a month or so ago. The
> Free Software Foundation started working on their Pagure deployment
> last summer, and the intent is to launch it by this summer. Trisquel
> will be setting up their instance in a matter of weeks. And I'm
> ignoring the instances run by companies internally (who aren't even
> Red Hat and *do* send contributions upstream!) and the instances run
> by people for personal use. ForgeFed is securing funding to hire a
> developer to work on Pagure, even!
>
> When you look at the timeline, we're doing pretty damn well compared
> to GitLab on the adoption curve. That in itself says that Pagure is
> worth something to people. From my view, there are three things that
> make Pagure much more attractive:
>
> 1. Freedom/federated/decentralized philosophy
> 2. Fully FOSS as opposed to Open Core
> 3. Backed by a trusted organization (Fedora) that uses FOSS to support
> itself and stands for its principles while not being polarizing to the
> greater OSS community
>
> This whole CPE team debacle is attempting to destroy point number 3.
>

I disagree that we are destroying point 3. CPE cannot own everything and
the maintenance of a git forge was outside of our scope of responsibility
and Pagure can and should live on irrespective of the CPE teams involvement
-- an involvement that really ceased in late 2018 but was being carried on
by the passions of individuals in their spare time. The choice here was to
invest and become the Pagure team and build out a git forge and staff it
accordingly or to add features to Fedora and CentOS that users want / need.


> Whether that kills the slowly building momentum for the Pagure project
> or not, I don't know. But I'm hoping it doesn't.
>
>
>
> --
> 真実はいつも一つ！/ 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


___

Re: CPE Git Forge Decision

[Leigh Griffin]

On Mon, Apr 6, 2020 at 12:10 PM Julen Landa Alustiza <
jla...@fedoraproject.org> wrote:

>
> 
>
> 20/4/6 12:29(e)an, Leigh Griffin igorleak idatzi zuen:
>
> > Around 10 tickets a month is the average I believe for infra to deal
> > with / handle from direct pings.
> >
> Where?
>

Infra queue

has 6 and releng one in the last month, adding direct pings it's an average
of 10 which I got from the Sustaining team.

https://pagure.io/fedora-infrastructure/issues?status=all&tags=src.fp.o&tags=pagure&priority=0&close_status=
> lists 50 tickets for the last year and some of them are not actually
> pagure issues and some others have attached fixes from the community.
>
>
> --
> 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 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, Apr 6, 2020 at 11:59 AM Miro Hrončok  wrote:

> On 06. 04. 20 12:13, Leigh Griffin wrote:
> >
> > You certainly didn't engage with the community.
> >
> >
> > We did.
>
> Not enough. You did initially but than you've stopped. You repeating "we
> have
> made a decision" in various threads over and over is not "engaging with
> the
> community", it is the exact opposite. Please stop that.
>

Answering 100+ replies individually is engaging with the community. Happy
to stop that if people aren't seeing the benefit of it though.

>
> --
> 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, Apr 6, 2020 at 11:56 AM clime  wrote:

>
>
> On Monday, 6 April 2020, Leigh Griffin  wrote:
>
>>
>>
>> 
>>>
>>>
>>> Yes, this whole "decision" is in dictatorship relation to the community.
>>>
>>> Not following the standard procedures caused that I and probably many
>>> people in the community didn't pay much attention to it.
>>>
>>
>> We followed the procedures that were outlined to us.
>>
>>>
>>> I thought you are simply going to collect requirements and then we
>>> will talk. Collecting the requirements was actually very useful.
>>> Providing the analysis for the requirements would be useful. Providing
>>> a recommendation would be ok. Providing a "decision" like that crosses
>>> the line.
>>>
>>> It sends quite a bad message that no matter what you start doing for
>>> the community and how useful it becomes, RH management can come at any
>>> time and make your work vanish, which is what is happening here with
>>> pagure on dist-git effort and probably also zuul efforts might get
>>> replaced by Gitlab CI.
>>>
>>
>> We have nothing to do with zuul and Gitlab CI may be made available as a
>> service if folks want to use it.
>>
>
> Does it mean you didn't consider dist-git<->zuul integration vs. Gitlab
> CI? I.e. technical differences and advantages of each? If you did, can you,
> please, publish it? It would be valuable info for the community and
> something we can comment on.
>

Gitlab CI was not part of our evaluation, we are aware it's a service that
is offered but did not evaluate it as it wasn't within the scope of our
exercise.


>
> Please, also read what Fabien wrote.
>

I did.

>
>
>>
>>> Additionally, I think that disruption you will cause will take so much
>>> time that it would several-times cover the time needed for
>>> implementation of all of the features people want to see in pagure.
>>>
>>> I also don't see people on IRC complaining that pagure.io or src.fp.o
>>> doesn't work so maintenance-wise it doesn't seem to be causing
>>> problems (there might be some but I didn't notice).
>>>
>>
>> Around 10 tickets a month is the average I believe for infra to deal with
>> / handle from direct pings.
>>
>>>
>>> In other words, the change you are suggesting won't be imho good for
>>> Fedora. What would be good is to continue doing incremental
>>> well-thought changes and not give up on our products. That might
>>> result in them coming on top at one point.
>>>
>>> I consider this whole situation my mistake. For quite some time I
>>> wanted to bring improvements to the packaging area to show that we can
>>> have top-notch stuff ourselves but it got seriously delayed by me not
>>> being always on top of my game. I still want to finish this
>>> (https://github.com/rpm-software-management/mock/pull/526) but I
>>> regret I didn't go for it earlier.
>>>
>>> But still, please, listen to what the community is telling you.
>>
>>
>> We are.
>>
>>> While
>>> you may have means to force your decision as RH management
>>> representative, doing so can be damaging for both sides (RH and
>>> Fedora).
>>
>>
>> We are not forcing a decision. We are still engaged with the Fedora
>> Council on next steps and factoring in the requirements of the community.
>> Right now, our wider needs are saying we cannot support Pagure and we
>> intend on replacing that with Gitlab from a CPE perspective.
>>
>>
>>> Slower but more careful progress is OK.
>>>
>>> clime
>>>
>>> >
>>> > --
>>> > 真実はいつも一つ！/ 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
>>>
>>
>>
>> --
>>
>> 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 

Re: CPE Git Forge Decision

[Josh Boyer]

On Mon, Apr 6, 2020 at 10:15 AM Vít Ondruch  wrote:
>
>
> Dne 06. 04. 20 v 14:34 Josh Boyer napsal(a):
> > On Mon, Apr 6, 2020 at 8:26 AM Stasiek Michalski  
> > wrote:
> >>> On Fri, Apr 3, 2020 at 12:10 pm, Adam Williamson
> >>>  >>>
> >>> $100/month per user for Ultimate (the only offering that meets the
> >>> "requirements")... 2339 packages in FAS... so $233900 * 12 works out to
> >>> roughly $3 million per year just for Fedora, assuming we never let
> >>> anybody other than approved Fedora packagers use the instance. Or in
> >>> terms of salary: a couple dozen software developers, more or less.
> >>>
> >>> I wonder if that's really more cost-effective than hiring a couple more
> >>> infrastructure devs
> >> Ignoring the core values and wasting money on outsourcing the problems
> >> at the same time? Sounds like capitalism to me ;)
> >>
> >> Joking aside, openSUSE will not be publicly deploying GitLab due to
> >> many of our contributors disagreeing with the open core development
> >> model, and we were hoping to use Pagure, since it does have the features
> >> our contributors wanted to have in the forge. Also some of my excitement
> >> for the forgefed is showing through. However reading through this thread
> >> I do get the feeling that there is largely no interest in developing
> >> Pagure, despite the fact it is pretty much the only forge with the
> >> features that make it easy to replace GitHub with it (and even moreso
> >> since Microsoft started getting GitHub to actually focus on similar
> >> areas as Pagure has been for years). Disappointing.
> > Why is it disappointing?  The Pagure project isn't suddenly being
> > removed from the internet.  Is there a reason you can't contribute to
> > it to add the features you need?
>
>
> This is like saying that if RH reassigns all Python maintainers
> currently working on Python in Fedora to something else, that Python in
> Fedora will prosper the same way as it always did.

No, actually that isn't what I said.  I never said anything about
Pagure *prospering*.  I said it exists for contributions today and it
will continue to exist going forward as long as people want it to.
Further replies in the thread elaborate more.

> Or maybe reassigning Java maintainers  oh, sorry, that already
> happened ...

Sure.  To acknowledge your point, losing a large contributor to any
project is a blow.  That's 100% true.  That doesn't mean it kills the
project immediately, and those that want to see it continue need to
put in the work to make that happen.  In some cases, it can actually
have net positive effects by making the community that is interested
now empowered as well.  It really all depends on what those
contributors are willing to do though.

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

[Vít Ondruch]

Dne 06. 04. 20 v 14:34 Josh Boyer napsal(a):
> On Mon, Apr 6, 2020 at 8:26 AM Stasiek Michalski  wrote:
>>> On Fri, Apr 3, 2020 at 12:10 pm, Adam Williamson
>>> >>
>>> $100/month per user for Ultimate (the only offering that meets the
>>> "requirements")... 2339 packages in FAS... so $233900 * 12 works out to
>>> roughly $3 million per year just for Fedora, assuming we never let
>>> anybody other than approved Fedora packagers use the instance. Or in
>>> terms of salary: a couple dozen software developers, more or less.
>>>
>>> I wonder if that's really more cost-effective than hiring a couple more
>>> infrastructure devs
>> Ignoring the core values and wasting money on outsourcing the problems
>> at the same time? Sounds like capitalism to me ;)
>>
>> Joking aside, openSUSE will not be publicly deploying GitLab due to
>> many of our contributors disagreeing with the open core development
>> model, and we were hoping to use Pagure, since it does have the features
>> our contributors wanted to have in the forge. Also some of my excitement
>> for the forgefed is showing through. However reading through this thread
>> I do get the feeling that there is largely no interest in developing
>> Pagure, despite the fact it is pretty much the only forge with the
>> features that make it easy to replace GitHub with it (and even moreso
>> since Microsoft started getting GitHub to actually focus on similar
>> areas as Pagure has been for years). Disappointing.
> Why is it disappointing?  The Pagure project isn't suddenly being
> removed from the internet.  Is there a reason you can't contribute to
> it to add the features you need?


This is like saying that if RH reassigns all Python maintainers
currently working on Python in Fedora to something else, that Python in
Fedora will prosper the same way as it always did.

Or maybe reassigning Java maintainers  oh, sorry, that already
happened ...


Vít


>
> The disappointing thing would be if everyone that was so interested in
> using Pagure walked away from it because somebody else stopped doing
> most of the work.
>
> josh
> ___
> 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

[Randy Barlow]

On 4/6/20 6:37 AM, Leigh Griffin wrote:
I'm sorry if you took my mail up as implying a lack of value from how 
the team historically worked.


It's a classic no-no to start an apology with "I'm sorry *if you*". It's 
not an apology at all, it's a defense disguised as an apology. It is 
thus dishonest.


https://www.psychologytoday.com/us/blog/understand-other-people/201607/i-m-sorry-you-were-offended-is-not-really-apology
___
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

[Randy Barlow]

On 4/6/20 6:13 AM, Leigh Griffin wrote:
CPE is entirely unique in this industry and is not perfectly aligned to 
the idealistic software engineering process, we are getting there.
No software team is perfectly aligned to the idealistic software 
engineering process. CPE is not unique in that either.


You also didn't address the core of my argument, which means it still 
stands: it's completely ordinary for software products to have 
stakeholders who do not agree. Your claim otherwise is not honest.



You do have a product: it's called dist-git.

That's not a product.


It is. The output of an engineering team is called a product. You should 
know that. If you do know that, writing the above is not honest. If you 
don't know that, you are missing fundamentals.


You wrote in another post, "It's a shame that the perception is that I'm 
not correct or truthful on points like this." It's messages like the 
above that generate that perception. You've been saying things that are 
obviously untrue, like it being unique to be in a situation where people 
don't agree. People won't believe you if you keep saying things that are 
clearly untrue.

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

On Mon, Apr 06, 2020 at 08:34:07AM -0400, Josh Boyer wrote:

> Why is it disappointing?  The Pagure project isn't suddenly being
> removed from the internet.  Is there a reason you can't contribute to
> it to add the features you need?

From my experience, I know that many of my contributions are triggered
by improving something that affects me. Therefore I submitted patches to
several Fedora Infra services when I was doing more packaging or rel-eng
work. As soon as pagure is not used anymore for Fedora's dist-git, at
lot of motivation to contribute it for Fedora contributors is gone.

I hope it will still be easy to contribute to the future dist-git
solution for interested Fedora contributors.

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

[Dominik 'Rathann' Mierzejewski]

On Monday, 06 April 2020 at 12:29, Leigh Griffin wrote:
[...]
> > Yes, this whole "decision" is in dictatorship relation to the
> > community.
> >
> > Not following the standard procedures caused that I and probably
> > many people in the community didn't pay much attention to it.
> 
> We followed the procedures that were outlined to us.

So you think "just following procedures" makes it all right and gives
you mandate to continuing to pursue a decision that the community is
telling you was wrong despite your following procedures?

> > I thought you are simply going to collect requirements and then we
> > will talk. Collecting the requirements was actually very useful.
> > Providing the analysis for the requirements would be useful.
> > Providing a recommendation would be ok. Providing a "decision" like
> > that crosses the line.
> >
> > It sends quite a bad message that no matter what you start doing for
> > the community and how useful it becomes, RH management can come at
> > any time and make your work vanish, which is what is happening here
> > with pagure on dist-git effort and probably also zuul efforts might
> > get replaced by Gitlab CI.
> 
> We have nothing to do with zuul and Gitlab CI may be made available as
> a service if folks want to use it.

It's not just about CI. You only commented about the least significant
point of the above paragraph and ignored the rest. That seems to be the
pattern with your communication. Please change that.

[...]
> > But still, please, listen to what the community is telling you.
> 
> We are.

That's not the impression you are giving here.

> > While you may have means to force your decision as RH management
> > representative, doing so can be damaging for both sides (RH and
> > Fedora).
> 
> We are not forcing a decision. We are still engaged with the Fedora
> Council on next steps and factoring in the requirements of the
> community. Right now, our wider needs are saying we cannot support
> Pagure and we intend on replacing that with Gitlab from a CPE
> perspective.

You are forcing a decision because you're refusing to revisit the
decision you have made *for* the community without the engagement that
the community feels was required. If you had stopped at the first
objections and revisited the decision making process with the rest of
the community involved in an open manner, you would have been forgiven,
because everyone here is trying to assume good faith. Alas, you haven't
done that. Apologizing for your mistakes is a necessary step, but it's
not sufficient.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
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, Apr 6, 2020 at 8:48 AM Josh Boyer  wrote:
>
> On Mon, Apr 6, 2020 at 8:42 AM Stasiek Michalski  wrote:
> >
> > > On Mon, Apr 6, 2020 at 8:26 AM Stasiek Michalski 
> > >  > >
> > > Why is it disappointing?  The Pagure project isn't suddenly being
> > > removed from the internet.  Is there a reason you can't contribute to
> > > it to add the features you need?
> >
> > I can add features, sure, and I do, but I am also not able or willing to
> > maintain everything else that goes with Pagure. My disappointment is
> > much more of a manifestation of a fear that if CPE ends up going with
> > Gitlab, there will be nobody else interested enough to maintain it,
> > since Fedora will no longer have any interest in it.
>
> That's a reasonable fear.  However, the only way to guarantee that
> fear becomes reality is to walk away from the project out of fear.
>
> Open source works because people contribute.  If you want the project
> to live, keep contributing.  You can always reassess who is
> contributing and what the health of the Pagure community is as you go.
> Others have said they want to see it succeed, so hopefully they'll
> also contribute.  If they don't, and Pagure stagnates, then maybe the
> interest wasn't in building something, it was in having somebody else
> build it for them.
>

Yes, but if part of the draw of using Pagure is to federate with other
servers, the drop in the "network" weakens things.

Folks have said it before on here and other places: they use
GitHub.com for the network effect. They don't like GitHub, but they
use it because they value the "network" more than their principles.
But building a network is not a simple process, and takes time, too.

It's interesting: if you look at the adoption curve for GitLab
relative to when it was created, Pagure isn't doing that badly. GitLab
was created in 2011 and most of its adoption/growth started at the end
of 2015, rising much more dramatically after the end of 2016. Pagure
was created in 2014 as progit, and then renamed a couple years later.
Fedora itself only deployed Pagure in 2017, and the CentOS instance
was rolled out in 2019. Around the same time last year, Pagure was
introduced to the openSUSE community formally and packaged there.
Mageia started looking at it in earnest only a month or so ago. The
Free Software Foundation started working on their Pagure deployment
last summer, and the intent is to launch it by this summer. Trisquel
will be setting up their instance in a matter of weeks. And I'm
ignoring the instances run by companies internally (who aren't even
Red Hat and *do* send contributions upstream!) and the instances run
by people for personal use. ForgeFed is securing funding to hire a
developer to work on Pagure, even!

When you look at the timeline, we're doing pretty damn well compared
to GitLab on the adoption curve. That in itself says that Pagure is
worth something to people. From my view, there are three things that
make Pagure much more attractive:

1. Freedom/federated/decentralized philosophy
2. Fully FOSS as opposed to Open Core
3. Backed by a trusted organization (Fedora) that uses FOSS to support
itself and stands for its principles while not being polarizing to the
greater OSS community

This whole CPE team debacle is attempting to destroy point number 3.
Whether that kills the slowly building momentum for the Pagure project
or not, I don't know. But I'm hoping it doesn't.



--
真実はいつも一つ！/ 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

[Neal Gompa]

On Mon, Apr 6, 2020 at 8:42 AM Stasiek Michalski  wrote:
>
> > On Mon, Apr 6, 2020 at 8:26 AM Stasiek Michalski 
> >  >
> > Why is it disappointing?  The Pagure project isn't suddenly being
> > removed from the internet.  Is there a reason you can't contribute to
> > it to add the features you need?
>
> I can add features, sure, and I do, but I am also not able or willing to
> maintain everything else that goes with Pagure. My disappointment is
> much more of a manifestation of a fear that if CPE ends up going with
> Gitlab, there will be nobody else interested enough to maintain it,
> since Fedora will no longer have any interest in it.
>

For what it's worth, I'll be around. And I'm hopeful that Pierre-Yves
will stick around to help the rest of the Pagure community support
itself and grow. But it is a bit of a blow if Fedora stops using it.
One of the more "pie-in-the-sky" ideas I had was to make it so that
all the major RPM distributions would have federated their Git servers
using Pagure to make it so that fixes across RPM distro families would
be easy to move around in a trackable way, which would help make it
easier for the best from each distribution to make it to all of them.

This is what I've been working toward in Mageia and OpenMandriva. And
I am still hoping openSUSE would join in on that.


-- 
真実はいつも一つ！/ 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

[Josh Boyer]

On Mon, Apr 6, 2020 at 8:42 AM Stasiek Michalski  wrote:
>
> > On Mon, Apr 6, 2020 at 8:26 AM Stasiek Michalski 
> >  >
> > Why is it disappointing?  The Pagure project isn't suddenly being
> > removed from the internet.  Is there a reason you can't contribute to
> > it to add the features you need?
>
> I can add features, sure, and I do, but I am also not able or willing to
> maintain everything else that goes with Pagure. My disappointment is
> much more of a manifestation of a fear that if CPE ends up going with
> Gitlab, there will be nobody else interested enough to maintain it,
> since Fedora will no longer have any interest in it.

That's a reasonable fear.  However, the only way to guarantee that
fear becomes reality is to walk away from the project out of fear.

Open source works because people contribute.  If you want the project
to live, keep contributing.  You can always reassess who is
contributing and what the health of the Pagure community is as you go.
Others have said they want to see it succeed, so hopefully they'll
also contribute.  If they don't, and Pagure stagnates, then maybe the
interest wasn't in building something, it was in having somebody else
build it for them.

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

[Stasiek Michalski]

> On Mon, Apr 6, 2020 at 8:26 AM Stasiek Michalski  wrote:
> 
> Why is it disappointing?  The Pagure project isn't suddenly being
> removed from the internet.  Is there a reason you can't contribute to
> it to add the features you need?

I can add features, sure, and I do, but I am also not able or willing to
maintain everything else that goes with Pagure. My disappointment is
much more of a manifestation of a fear that if CPE ends up going with
Gitlab, there will be nobody else interested enough to maintain it,
since Fedora will no longer have any interest in it.

LCP [Stasiek]
https://lcp.world
___
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

[Josh Boyer]

On Mon, Apr 6, 2020 at 8:26 AM Stasiek Michalski  wrote:
>
> > On Fri, Apr 3, 2020 at 12:10 pm, Adam Williamson
> >  >
> > $100/month per user for Ultimate (the only offering that meets the
> > "requirements")... 2339 packages in FAS... so $233900 * 12 works out to
> > roughly $3 million per year just for Fedora, assuming we never let
> > anybody other than approved Fedora packagers use the instance. Or in
> > terms of salary: a couple dozen software developers, more or less.
> >
> > I wonder if that's really more cost-effective than hiring a couple more
> > infrastructure devs
>
> Ignoring the core values and wasting money on outsourcing the problems
> at the same time? Sounds like capitalism to me ;)
>
> Joking aside, openSUSE will not be publicly deploying GitLab due to
> many of our contributors disagreeing with the open core development
> model, and we were hoping to use Pagure, since it does have the features
> our contributors wanted to have in the forge. Also some of my excitement
> for the forgefed is showing through. However reading through this thread
> I do get the feeling that there is largely no interest in developing
> Pagure, despite the fact it is pretty much the only forge with the
> features that make it easy to replace GitHub with it (and even moreso
> since Microsoft started getting GitHub to actually focus on similar
> areas as Pagure has been for years). Disappointing.

Why is it disappointing?  The Pagure project isn't suddenly being
removed from the internet.  Is there a reason you can't contribute to
it to add the features you need?

The disappointing thing would be if everyone that was so interested in
using Pagure walked away from it because somebody else stopped doing
most of the work.

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

[Stasiek Michalski]

> On Fri, Apr 3, 2020 at 12:10 pm, Adam Williamson 
>  
> $100/month per user for Ultimate (the only offering that meets the 
> "requirements")... 2339 packages in FAS... so $233900 * 12 works out to 
> roughly $3 million per year just for Fedora, assuming we never let 
> anybody other than approved Fedora packagers use the instance. Or in 
> terms of salary: a couple dozen software developers, more or less.
> 
> I wonder if that's really more cost-effective than hiring a couple more 
> infrastructure devs

Ignoring the core values and wasting money on outsourcing the problems
at the same time? Sounds like capitalism to me ;)

Joking aside, openSUSE will not be publicly deploying GitLab due to
many of our contributors disagreeing with the open core development
model, and we were hoping to use Pagure, since it does have the features
our contributors wanted to have in the forge. Also some of my excitement
for the forgefed is showing through. However reading through this thread
I do get the feeling that there is largely no interest in developing
Pagure, despite the fact it is pretty much the only forge with the
features that make it easy to replace GitHub with it (and even moreso
since Microsoft started getting GitHub to actually focus on similar
areas as Pagure has been for years). Disappointing.

LCP [Stasiek]
https://lcp.world
___
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/4/6 12:29(e)an, Leigh Griffin igorleak idatzi zuen:

> Around 10 tickets a month is the average I believe for infra to deal
> with / handle from direct pings.
> 
Where?
https://pagure.io/fedora-infrastructure/issues?status=all&tags=src.fp.o&tags=pagure&priority=0&close_status=
lists 50 tickets for the last year and some of them are not actually
pagure issues and some others have attached fixes from the community.


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

[Miro Hrončok]

On 06. 04. 20 12:13, Leigh Griffin wrote:


You certainly didn't engage with the community.


We did.


Not enough. You did initially but than you've stopped. You repeating "we have 
made a decision" in various threads over and over is not "engaging with the 
community", it is the exact opposite. Please stop 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

[clime]

On Monday, 6 April 2020, Leigh Griffin  wrote:

>
>
> 
>>
>>
>> Yes, this whole "decision" is in dictatorship relation to the community.
>>
>> Not following the standard procedures caused that I and probably many
>> people in the community didn't pay much attention to it.
>>
>
> We followed the procedures that were outlined to us.
>
>>
>> I thought you are simply going to collect requirements and then we
>> will talk. Collecting the requirements was actually very useful.
>> Providing the analysis for the requirements would be useful. Providing
>> a recommendation would be ok. Providing a "decision" like that crosses
>> the line.
>>
>> It sends quite a bad message that no matter what you start doing for
>> the community and how useful it becomes, RH management can come at any
>> time and make your work vanish, which is what is happening here with
>> pagure on dist-git effort and probably also zuul efforts might get
>> replaced by Gitlab CI.
>>
>
> We have nothing to do with zuul and Gitlab CI may be made available as a
> service if folks want to use it.
>

Does it mean you didn't consider dist-git<->zuul integration vs. Gitlab CI?
I.e. technical differences and advantages of each? If you did, can you,
please, publish it? It would be valuable info for the community and
something we can comment on.

Please, also read what Fabien wrote.


>
>> Additionally, I think that disruption you will cause will take so much
>> time that it would several-times cover the time needed for
>> implementation of all of the features people want to see in pagure.
>>
>> I also don't see people on IRC complaining that pagure.io or src.fp.o
>> doesn't work so maintenance-wise it doesn't seem to be causing
>> problems (there might be some but I didn't notice).
>>
>
> Around 10 tickets a month is the average I believe for infra to deal with
> / handle from direct pings.
>
>>
>> In other words, the change you are suggesting won't be imho good for
>> Fedora. What would be good is to continue doing incremental
>> well-thought changes and not give up on our products. That might
>> result in them coming on top at one point.
>>
>> I consider this whole situation my mistake. For quite some time I
>> wanted to bring improvements to the packaging area to show that we can
>> have top-notch stuff ourselves but it got seriously delayed by me not
>> being always on top of my game. I still want to finish this
>> (https://github.com/rpm-software-management/mock/pull/526) but I
>> regret I didn't go for it earlier.
>>
>> But still, please, listen to what the community is telling you.
>
>
> We are.
>
>> While
>> you may have means to force your decision as RH management
>> representative, doing so can be damaging for both sides (RH and
>> Fedora).
>
>
> We are not forcing a decision. We are still engaged with the Fedora
> Council on next steps and factoring in the requirements of the community.
> Right now, our wider needs are saying we cannot support Pagure and we
> intend on replacing that with Gitlab from a CPE perspective.
>
>
>> Slower but more careful progress is OK.
>>
>> clime
>>
>> >
>> > --
>> > 真実はいつも一つ！/ 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
>>
>
>
> --
>
> 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 Fri, Apr 3, 2020 at 8:15 PM Jeremy Cline  wrote:

> Hi Leigh,
>
> On Fri, 2020-04-03 at 17:00 +0100, Leigh Griffin wrote:
> >
> >
> > On Fri, Apr 3, 2020 at 4:20 PM Jeremy Cline 
> > wrote:
> > > On Fri, 2020-04-03 at 05:38 -0400, Neal Gompa wrote:
> > > > On Fri, Apr 3, 2020 at 5:29 AM Michal Konecny <
> > > mkone...@redhat.com>
> > > > wrote:
> > > > > On 03/04/2020 01:25, Jeremy Cline wrote:
> > > > > > On Thu, 2020-04-02 at 11:52 +0100, Leigh Griffin wrote:
> > > > > > > The number of active developers on Fedora initiatives has
> > > gone
> > > > > > > up
> > > > > > > drastically since I joined the team in 2019. You are
> > > possibly
> > > > > > > not
> > > > > > > seeing that as the team have moved from a model of siloed
> > > work
> > > > > > > on
> > > > > > > multiple apps, swimming against the tid working 16 hour
> > > days,
> > > > > > > to
> > > > > > > working on team oriented initiatives to add real value to
> > > the
> > > > > > > ecosystem. So the noise of working on multiple small things
> > > at
> > > > > > > once
> > > > > > > is not as loud as it was in 2018 which is giving that
> > > illusion.
> > > > > > I'd always suspected my work added no real value, but never
> > > had
> > > > > > the
> > > > > > proof. I appreciate the validation .
> >
> > Sorry I missed this among the thread splits and dozens of other
> > replies. Ping me offlist if you have specific concerns as I do not
> > believe my comment infers a lack of value in your work or any other
> > contributor for that matter and the wealth of positive comments since
> > is validating that your contributions were indeed most welcome and
> > appreciative. If I did somehow infer that your work had no value, I
> > do apologise, lets connect though if you have concerns.
> >
>
> I'm not sure how to be more specific, but here goes:
>
> When you said "the team have moved from a model of siloed work on
> multiple apps, swimming against the tid[e] working 16 hour days, to
> working on team oriented initiatives to add *real value* to the
> ecosystem" (emphasis is mine in order to be more specific), it made me
> feel that what you are saying is prior work didn't add "real value".
> Other comments you have made in this thread (e.g. "We aren't in the
> habit of inventing work to do for ourselves anymore") re-enforce this
> feeling.
>
> While you may believe your comments never implied a lack of value,
> I'm not sure how else to interpret your comments throughout this
> thread.
>

Thanks for the clarity Jeremy, I'm sorry if you took my mail up as implying
a lack of value from how the team historically worked. As a team we are
being tasked more and more with adding what I call real value which is at a
new app / service level that has scale, quality and requirements that
historically a single developer could not call on. We had some superhuman
developers in the past in the team that were able to do every single thing
an application needed and produced some wonderful applications that in
truth would have taken 10 or more developers to replicate. That team has
moved on now and the old style of working was not going to meet the needs
and wants of our stakeholders (in this case Fedora Council) and a
repurposing of the team to make visible impacts was undertaken. So while we
cannot have multiple commits across a plethora of services, we are not
focusing our efforts on singular services at a time to generate a value
proposition for the community. Sorry once again if you took my comment up
as being a sleight, it was most definitely not intended and you have my
sincere apologies.


>
> - Jeremy
>
>

-- 

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]

>
>
> Yes, this whole "decision" is in dictatorship relation to the community.
>
> Not following the standard procedures caused that I and probably many
> people in the community didn't pay much attention to it.
>

We followed the procedures that were outlined to us.

>
> I thought you are simply going to collect requirements and then we
> will talk. Collecting the requirements was actually very useful.
> Providing the analysis for the requirements would be useful. Providing
> a recommendation would be ok. Providing a "decision" like that crosses
> the line.
>
> It sends quite a bad message that no matter what you start doing for
> the community and how useful it becomes, RH management can come at any
> time and make your work vanish, which is what is happening here with
> pagure on dist-git effort and probably also zuul efforts might get
> replaced by Gitlab CI.
>

We have nothing to do with zuul and Gitlab CI may be made available as a
service if folks want to use it.

>
> Additionally, I think that disruption you will cause will take so much
> time that it would several-times cover the time needed for
> implementation of all of the features people want to see in pagure.
>
> I also don't see people on IRC complaining that pagure.io or src.fp.o
> doesn't work so maintenance-wise it doesn't seem to be causing
> problems (there might be some but I didn't notice).
>

Around 10 tickets a month is the average I believe for infra to deal with /
handle from direct pings.

>
> In other words, the change you are suggesting won't be imho good for
> Fedora. What would be good is to continue doing incremental
> well-thought changes and not give up on our products. That might
> result in them coming on top at one point.
>
> I consider this whole situation my mistake. For quite some time I
> wanted to bring improvements to the packaging area to show that we can
> have top-notch stuff ourselves but it got seriously delayed by me not
> being always on top of my game. I still want to finish this
> (https://github.com/rpm-software-management/mock/pull/526) but I
> regret I didn't go for it earlier.
>
> But still, please, listen to what the community is telling you.


We are.

> While
> you may have means to force your decision as RH management
> representative, doing so can be damaging for both sides (RH and
> Fedora).


We are not forcing a decision. We are still engaged with the Fedora Council
on next steps and factoring in the requirements of the community. Right
now, our wider needs are saying we cannot support Pagure and we intend on
replacing that with Gitlab from a CPE perspective.


> Slower but more careful progress is OK.
>
> clime
>
> >
> > --
> > 真実はいつも一つ！/ 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
>


-- 

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

[Neal Gompa]

On Mon, Apr 6, 2020 at 6:14 AM Dominik 'Rathann' Mierzejewski
 wrote:
>
> On Wednesday, 01 April 2020 at 12:37, Miro Hrončok wrote:
> > On 01. 04. 20 10:53, Vít Ondruch wrote:
> > > Dne 01. 04. 20 v 10:37 Michal Konecny napsal(a):
> [...]
> > > > To be clear, you mean something like app above the dist-git where
> > > > you could do most of the things that are needed for dist-git with
> > > > git forge only being a package source with various branches?
> > > >
> > > > Something like web UI that allows you to do retirement, change
> > > > notification settings, has links to various other systems, with on
> > > > of them the git that is hosting the code for package, without
> > > > actually thinking what git forge is used for the hosting?
> > >
> > > Do you mean https://github.com/fedora-infra/pkgdb2/ ? :)
> >
> > That's actually what rpmfusion is doing. They have pkgdb + github repos.
> >
> > (Not sure if still, but it was the case around a year ago.)
>
> No, we don't. Github repos are only mirrors. To the best of my
> knowledge, RPM Fusion never used Github as a primary dist-git hosting.
>

This is true. I have also spoken to Nicolas Chauvet about getting RPM
Fusion to use Pagure. That one simply came down to time, and the more
urgent problem of dealing with EL8 was more important then (late last
year).



-- 
真実はいつも一つ！/ 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 Sat, Apr 4, 2020 at 2:43 AM Randy Barlow 
wrote:

> On 4/3/20 4:41 PM, Leigh Griffin wrote:
> > This is how a specific flavour of software development works centered on
> > a singular product, with a shared vision. The CPE relationship with
> > stakeholders is unique, it's clear the visions are not aligned across
> > all bodies (and we do not expect it to be) and we don't have a product.
> > We have taken a more formal project requirements elicitation approach
> > for this phase.
>
> It is not unique, it is entirely common. It is typical for software
> products to have a variety of stakeholders with different competing
> visions. I've not worked on any software product in my career that had a
> single aligned vision among stakeholders, at Red Hat or anywhere else,
> companies large and small. Nothing about this project is out of the
> ordinary in this regard.
>

CPE is entirely unique in this industry and is not perfectly aligned to the
idealistic software engineering process, we are getting there.

>
> You do have a product: it's called dist-git.
>

That's not a product.


> > That is what we are doing right now by engaging on the specific needs
> > for our Gitlab instance(s). We are doing this and over the next 2 weeks
> > will be engaging with each group on specifics now that a path has been
> > set. At that point the real disagreements can be decided upon by our
> > product owner in conjunction with stakeholders, this will not be a
> > decision in a vacuum.
>
> Specific needs are evaluated before making a decision, not after. That's
> engineering basics.
>

We evaluated the needs necessary to make a decision.

>
> > We didn't quash communication for reasons already mentioned. We didn't
> > facilitate it is a more accurate assessment, for which we have
> > acknowledged and apologized.
>
> You certainly didn't engage with the community.


We did.


> Fedora has a change
> process, and every other significant change goes through it.


We were instructed to go through Council, which we did.

Sure, not
> everyone is happy with the results of every decision, but there is at
> least open discussion. That open discussion often influences the
> decision. You didn't do that here, and the only communication of the
> decision was buried in an e-mail that many people don't read.


The blog post went out later than intended due to real life issues the
volunteers who publish it had, that was outside of our control and less
than ideal. I opened the thread first thing on Monday

That
> communication was also a decision, not an invitation for discussion.
> There is no process now for discussion to influence the decision, a
> cornerstone of open development.
>
> This is not open.
> ___
> 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

[Dominik 'Rathann' Mierzejewski]

On Wednesday, 01 April 2020 at 12:37, Miro Hrončok wrote:
> On 01. 04. 20 10:53, Vít Ondruch wrote:
> > Dne 01. 04. 20 v 10:37 Michal Konecny napsal(a):
[...]
> > > To be clear, you mean something like app above the dist-git where
> > > you could do most of the things that are needed for dist-git with
> > > git forge only being a package source with various branches?
> > > 
> > > Something like web UI that allows you to do retirement, change
> > > notification settings, has links to various other systems, with on
> > > of them the git that is hosting the code for package, without
> > > actually thinking what git forge is used for the hosting?
> > 
> > Do you mean https://github.com/fedora-infra/pkgdb2/ ? :)
> 
> That's actually what rpmfusion is doing. They have pkgdb + github repos.
> 
> (Not sure if still, but it was the case around a year ago.)

No, we don't. Github repos are only mirrors. To the best of my
knowledge, RPM Fusion never used Github as a primary dist-git hosting.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
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

[Fabien Boucher]

On Fri, Apr 3, 2020 at 9:11 PM Adam Williamson
 wrote:
>
> I also hope there will be an opportunity for discussion (with input
> from the community) of whether those requirements can be fulfilled in
> some way *other* than using a non-free Gitlab product. To take the
> 'merge train' example - as Neal and I have mentioned, Pagure now in
> fact *does* have some impressive capabilities in this area, thanks to
> the Pagure<->Zuul integration that the Software Factory folks have been
> working on, and presented at Devconf. I am personally using this for
> multiple projects, and blogged about it here:
>
> https://www.happyassassin.net/2020/02/12/using-zuul-ci-with-pagure-io/
>

As far as I understand the "merge train" feature from Gitlab, it seems to be
similar to Zuul's "speculative merging" feature, except that Zuul is
multi-repository aware by design, and thus Zuul is able to gate changes
in their order of approval across a logical (user defined) set of repositories.

When a project's code is spread across multiple repositories then Zuul's
approach is invaluable. A striking example of a project spanning multiple
repositories is of course Fedora where all packages are in their own
dist-git repository.

Another feature offered by Zuul that might be relevant in the dist-git context
is the ability to have Zuul test PRs that require other (still unmerged) PRs.
This allows creating CI jobs capable of handling build and runtime
dependencies of RPMs.


> an obvious avenue to explore here would be "can we work with Software
> Factory folks to do a similar integration between Gitlab Core and
> Zuul"? On the face of it, that would offer a way to achieve these
> capabilities in a fully F/OSS way.
>

As for Gitlab integration, a driver is available for Zuul, but it is
not as feature
complete compared to the other drivers like the Pagure one. It might take
some time to cover the missing bits; it might also be necessary to submit
feature requests to gitlab's APIs themselves. I have been involved in writing
those drivers and I fear it might not be as "easy" as it was for the Pagure
driver. I might be wrong, but I don't expect any support from the gitlab side,
for an obvious reason: offering "free" integration with Zuul would effectively
kill their effort on monetizing "merge train", a similar in-house feature.

On the other hand, I'd like to point out that working with Pagure maintainers to
discuss missing features (mainly API endpoints) was really productive.
Pagure folks are welcoming and provide guidance so it was easy for me
to implement most of the missing pieces in the code to integrate with Zuul.
___
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]

On Sat, 4 Apr 2020 at 14:04, Neal Gompa  wrote:
>
> On Fri, Apr 3, 2020 at 9:42 PM Randy Barlow
>  wrote:
> >
> > On 4/3/20 4:41 PM, Leigh Griffin wrote:
> > > We didn't quash communication for reasons already mentioned. We didn't
> > > facilitate it is a more accurate assessment, for which we have
> > > acknowledged and apologized.
> >
> > You certainly didn't engage with the community. Fedora has a change
> > process, and every other significant change goes through it. Sure, not
> > everyone is happy with the results of every decision, but there is at
> > least open discussion. That open discussion often influences the
> > decision. You didn't do that here, and the only communication of the
> > decision was buried in an e-mail that many people don't read. That
> > communication was also a decision, not an invitation for discussion.
> > There is no process now for discussion to influence the decision, a
> > cornerstone of open development.
> >
> > This is not open.
>
> I'd like to point out *every other major infrastructure change* has
> gone through the change process, debated publicly, and approved by
> FESCo before implementing:
>
> * Merged Core and Extras in our CVS:
> https://fedoraproject.org/wiki/Releases/FeatureMergeSCM
> * Deployment of Koji:
> https://fedoraproject.org/wiki/Releases/FeatureNewBuildSystem
> * Deployment of Bodhi:
> https://fedoraproject.org/wiki/Releases/FeatureUpdateSystem
> * Deployment of Dist-Git: https://fedoraproject.org/wiki/Dist_Git_Proposal
> * Koji signed repos: https://fedoraproject.org/wiki/Changes/KojiSignedRepos
> * Deployment of Pagure:
> https://fedoraproject.org/wiki/Changes/ArbitraryBranching
> * Deployment of MBS: https://fedoraproject.org/wiki/Changes/ModuleBuildService
> * Added Modular Compose: https://fedoraproject.org/wiki/Changes/ModularCompose
> * Added Zchunk repodata: 
> https://fedoraproject.org/wiki/Changes/Zchunk_Metadata
> * Gated Rawhide: https://fedoraproject.org/wiki/Changes/GatingRawhidePackages
> * Dropped i686 content:
> https://fedoraproject.org/wiki/Changes/Noi686Repositories
> * Fedora active user metrics:
> https://fedoraproject.org/wiki/Changes/DNF_Better_Counting
> * Using Taiga for the Change proposals:
> https://fedoraproject.org/wiki/Changes/fedora-change-wrangler
> * Enabling modules in the regular buildroot:
> https://fedoraproject.org/wiki/Changes/Modules_In_Non-Modular_Buildroot
>
> If we were to consider this as the requisite community discussion and
> the decision as a "proposal", then the resounding negative feedback
> would be sufficient to *not* do this without going back to the drawing
> board and improving the proposal.
>
> But of course, that's not what is happening. And that's a problem in
> itself. We accepted the deviation in procedure for Fedora
> infrastructure changes for *this* change because there was a described
> process that was considered functionally equivalent. But then *that*
> process was not followed. You've effectively shattered the trust with
> the community that you attempted to create with this.

Yes, this whole "decision" is in dictatorship relation to the community.

Not following the standard procedures caused that I and probably many
people in the community didn't pay much attention to it.

I thought you are simply going to collect requirements and then we
will talk. Collecting the requirements was actually very useful.
Providing the analysis for the requirements would be useful. Providing
a recommendation would be ok. Providing a "decision" like that crosses
the line.

It sends quite a bad message that no matter what you start doing for
the community and how useful it becomes, RH management can come at any
time and make your work vanish, which is what is happening here with
pagure on dist-git effort and probably also zuul efforts might get
replaced by Gitlab CI.

Additionally, I think that disruption you will cause will take so much
time that it would several-times cover the time needed for
implementation of all of the features people want to see in pagure.

I also don't see people on IRC complaining that pagure.io or src.fp.o
doesn't work so maintenance-wise it doesn't seem to be causing
problems (there might be some but I didn't notice).

In other words, the change you are suggesting won't be imho good for
Fedora. What would be good is to continue doing incremental
well-thought changes and not give up on our products. That might
result in them coming on top at one point.

I consider this whole situation my mistake. For quite some time I
wanted to bring improvements to the packaging area to show that we can
have top-notch stuff ourselves but it got seriously delayed by me not
being always on top of my game. I still want to finish this
(https://github.com/rpm-software-management/mock/pull/526) but I
regret I didn't go for it earlier.

But still, please, listen to what the community is telling you. While
you may have means to force your decision as RH management
representative, doing so can be da

Re: CPE Git Forge Decision

[Neal Gompa]

On Fri, Apr 3, 2020 at 9:42 PM Randy Barlow
 wrote:
>
> On 4/3/20 4:41 PM, Leigh Griffin wrote:
> > We didn't quash communication for reasons already mentioned. We didn't
> > facilitate it is a more accurate assessment, for which we have
> > acknowledged and apologized.
>
> You certainly didn't engage with the community. Fedora has a change
> process, and every other significant change goes through it. Sure, not
> everyone is happy with the results of every decision, but there is at
> least open discussion. That open discussion often influences the
> decision. You didn't do that here, and the only communication of the
> decision was buried in an e-mail that many people don't read. That
> communication was also a decision, not an invitation for discussion.
> There is no process now for discussion to influence the decision, a
> cornerstone of open development.
>
> This is not open.

I'd like to point out *every other major infrastructure change* has
gone through the change process, debated publicly, and approved by
FESCo before implementing:

* Merged Core and Extras in our CVS:
https://fedoraproject.org/wiki/Releases/FeatureMergeSCM
* Deployment of Koji:
https://fedoraproject.org/wiki/Releases/FeatureNewBuildSystem
* Deployment of Bodhi:
https://fedoraproject.org/wiki/Releases/FeatureUpdateSystem
* Deployment of Dist-Git: https://fedoraproject.org/wiki/Dist_Git_Proposal
* Koji signed repos: https://fedoraproject.org/wiki/Changes/KojiSignedRepos
* Deployment of Pagure:
https://fedoraproject.org/wiki/Changes/ArbitraryBranching
* Deployment of MBS: https://fedoraproject.org/wiki/Changes/ModuleBuildService
* Added Modular Compose: https://fedoraproject.org/wiki/Changes/ModularCompose
* Added Zchunk repodata: https://fedoraproject.org/wiki/Changes/Zchunk_Metadata
* Gated Rawhide: https://fedoraproject.org/wiki/Changes/GatingRawhidePackages
* Dropped i686 content:
https://fedoraproject.org/wiki/Changes/Noi686Repositories
* Fedora active user metrics:
https://fedoraproject.org/wiki/Changes/DNF_Better_Counting
* Using Taiga for the Change proposals:
https://fedoraproject.org/wiki/Changes/fedora-change-wrangler
* Enabling modules in the regular buildroot:
https://fedoraproject.org/wiki/Changes/Modules_In_Non-Modular_Buildroot

If we were to consider this as the requisite community discussion and
the decision as a "proposal", then the resounding negative feedback
would be sufficient to *not* do this without going back to the drawing
board and improving the proposal.

But of course, that's not what is happening. And that's a problem in
itself. We accepted the deviation in procedure for Fedora
infrastructure changes for *this* change because there was a described
process that was considered functionally equivalent. But then *that*
process was not followed. You've effectively shattered the trust with
the community that you attempted to create with this.

-- 
真実はいつも一つ！/ 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

[Randy Barlow]

On 4/3/20 4:41 PM, Leigh Griffin wrote:
This is how a specific flavour of software development works centered on 
a singular product, with a shared vision. The CPE relationship with 
stakeholders is unique, it's clear the visions are not aligned across 
all bodies (and we do not expect it to be) and we don't have a product. 
We have taken a more formal project requirements elicitation approach 
for this phase.


It is not unique, it is entirely common. It is typical for software 
products to have a variety of stakeholders with different competing 
visions. I've not worked on any software product in my career that had a 
single aligned vision among stakeholders, at Red Hat or anywhere else, 
companies large and small. Nothing about this project is out of the 
ordinary in this regard.


You do have a product: it's called dist-git.

That is what we are doing right now by engaging on the specific needs 
for our Gitlab instance(s). We are doing this and over the next 2 weeks 
will be engaging with each group on specifics now that a path has been 
set. At that point the real disagreements can be decided upon by our 
product owner in conjunction with stakeholders, this will not be a 
decision in a vacuum.


Specific needs are evaluated before making a decision, not after. That's
engineering basics.

We didn't quash communication for reasons already mentioned. We didn't 
facilitate it is a more accurate assessment, for which we have 
acknowledged and apologized.


You certainly didn't engage with the community. Fedora has a change 
process, and every other significant change goes through it. Sure, not 
everyone is happy with the results of every decision, but there is at 
least open discussion. That open discussion often influences the 
decision. You didn't do that here, and the only communication of the 
decision was buried in an e-mail that many people don't read. That 
communication was also a decision, not an invitation for discussion. 
There is no process now for discussion to influence the decision, a 
cornerstone of open development.


This is not open.
___
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 Fri, Apr 3, 2020, 20:26 Randy Barlow 
wrote:

> On 4/3/20 3:08 PM, Leigh Griffin wrote:
> > It may have caught that for sure but it would have opened a lot more
> > problems as stakeholders try to counter each others requirements with
> > new more specific requirements to influence the decision.
>
> This is how software development is *supposed* to work.


This is how a specific flavour of software development works centered on a
singular product, with a shared vision. The CPE relationship with
stakeholders is unique, it's clear the visions are not aligned across all
bodies (and we do not expect it to be) and we don't have a product. We have
taken a more formal project requirements elicitation approach for this
phase.

It is the job of
> the product owner to resolve disagreements between stakeholders


That is what we are doing right now by engaging on the specific needs for
our Gitlab instance(s). We are doing this and over the next 2 weeks will be
engaging with each group on specifics now that a path has been set. At that
point the real disagreements can be decided upon by our product owner in
conjunction with stakeholders, this will not be a decision in a vacuum.

not to
> quash communication between them.
>

We didn't quash communication for reasons already mentioned. We didn't
facilitate it is a more accurate assessment, for which we have acknowledged
and apologized.

> ___
> 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 Fri, Apr 3, 2020 at 3:57 PM Adam Williamson
 wrote:
>
> On Fri, 2020-04-03 at 14:46 -0500, Michael Catanzaro wrote:
> > On Fri, Apr 3, 2020 at 12:10 pm, Adam Williamson
> >  wrote:
> >  > Another is requirement 19 ("As a Project
> > contributor...I want to be able to use kanban boards...So that my team
> > can easily schedule and prioritize work in a visible way").
> >
> > Kanban is actually an open source feature:
> > https://gitlab.gnome.org/GNOME/epiphany/-/boards
>
> Hmm. Looking closer at the feature lists:
>
> https://about.gitlab.com/pricing/
>
> it looks like maybe *basic* board capabilities are in Core but more
> advanced stuff - "Multiple Group Issue Boards", "Single level Epics",
> "Deploy Boards", "Multi-level Epics" - are in Premium and Ultimate? I'm
> not an expert.

You're correct. If you want the functionality equivalent to what we
get with Taiga, you'll need GitLab Ultimate.




--
真実はいつも一つ！/ 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

[Adam Williamson]

On Fri, 2020-04-03 at 14:46 -0500, Michael Catanzaro wrote:
> On Fri, Apr 3, 2020 at 12:10 pm, Adam Williamson 
>  wrote:
> > I assume Gitlab likes money. :P
> 
> $100/month per user for Ultimate (the only offering that meets the 
> "requirements")... 2339 packages in FAS... so $233900 * 12 works out to 
> roughly $3 million per year just for Fedora, assuming we never let 
> anybody other than approved Fedora packagers use the instance. Or in 
> terms of salary: a couple dozen software developers, more or less.
> 
> I wonder if that's really more cost-effective than hiring a couple more 
> infrastructure devs

I mean, I'm assuming we will be deploying RH's crack negotiating teams
at this :)

>  > Another is requirement 19 ("As a Project
> contributor...I want to be able to use kanban boards...So that my team
> can easily schedule and prioritize work in a visible way").
> 
> Kanban is actually an open source feature: 
> https://gitlab.gnome.org/GNOME/epiphany/-/boards

Hmm. Looking closer at the feature lists:

https://about.gitlab.com/pricing/

it looks like maybe *basic* board capabilities are in Core but more
advanced stuff - "Multiple Group Issue Boards", "Single level Epics",
"Deploy Boards", "Multi-level Epics" - are in Premium and Ultimate? I'm
not an expert.
-- 
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

[Kevin Fenzi]

On Fri, Apr 03, 2020 at 01:53:18PM -0400, Neal Gompa wrote:
> On Fri, Apr 3, 2020 at 1:28 PM Kevin Fenzi  wrote:
> >
> > On Fri, Apr 03, 2020 at 09:55:48AM +0200, Clement Verna wrote:
> >
> > ...snip...
> >
> > (side note: can people please try and trim their replies to this list?
> > I know gmail makes that hard, but it's anoying to read a thread where
> > you have to keep hitting page down to get the next few lines of new
> > text. Thanks in advance for anyone who can do this. :)
> >
> 
> I'm trying. There's a lot to reply to now... :)

Yeah, indeed. ;( 
...snip...

> 
> I don't know if that's really true. You have a number of interesting
> apps, you have relatively popular infrastructure methods. There are a
> lot of people who'd like to learn and build skills in this sort of
> thing. There's even containers and OpenShift stuff now, so you can
> attract those people too!

It's not all about the apps and methods tho. Sometimes is tedious or
difficult work integrating things. 

...snip...

> 
> Well, there's potentially an opportunity here with all these people
> being affected by... uhh... current global events?

Could be. 

...snip

> Do we have any formal docs on this?

Yes. 

https://fedoraproject.org/wiki/Infrastructure/GettingStarted
is the landing page, there's bunches of stuff off those. 

We have a section in every weekly meeting when we talk to newcomers. 

We have daily irc standups reviewing incoming tickets and discussing
ones anyone has questions on.

We have mailing list and irc channels happy to answer questions as time
permits. 

> Could we even just get the pagure ansible repo working[1] so I have
> somewhere to send people to submit contributions? I'd love to be able
> to just fork the repo, do some fixes, test it somewhere, and then
> submit it for inclusion.
> 
> [1]: https://pagure.io/Fedora-Infra/ansible

We could, but I was waiting for this gitforge thing to settle down. 
Do we really want to move to there and then move to gitlab again in a
short time?

> If *I* had a magic wand, I'd be using it now. :)
> 
> Sadly, creating viable communities takes hard work. It requires
> research and outreach effort. What's worse, growth and sustainability
> curves are usually exponential (phase 1), then logarithmic (phase 2).

yes, and different communities have different needs and requirements
too.

...snip talk about apps and communities...
> 
> Honestly, the main app I have trouble seeing a broader community for
> is Bodhi. It *could* be done, but I'd have to sit down and do a fair
> bit of work to figure out what parts are "Fedora-only" verses
> "Fedora-favored". It speaks volumes that even *Red Hat* doesn't use
> Bodhi, and nor does RPM Fusion.

Ironically I think there's some companies that use bodhi internally. 
I don't know who they were/are, but former developers told me they were
actually using it. 

> Is there something else you'd like to see broader adoption on? I can
> try to help push it along if I can identify folks that could be
> interested in it.

Let me try again... some apps we have indeed are of general interest or
at least interest to people in fedora and you can form a community
around that. Infrastructure is different. It's harder to ramp people up
fast becasue you can't easily review everything that they would do
before they do it. A lot of work is integration of those apps, day to
day provisioning, collecting data for upstream bugs, etc. So, the needs
are different. Not impossible, just different. We know in the past
some of the people who appeared and started contributing worked
themselves all the way up to our main group and root access on
everything (off the top of my head: Jon Stanley, Randy, Rick Elrod, Me, 
Patrick, Pingou, Tflink, Luke Macken, Toshio, mizdebsk, Peter Robinson,
and probibly others I am missing). If they all did it, whats missing
today? 

anyhow, I have a bunch of stuff to do, so probibly my last reply today.

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

[Michael Catanzaro]

On Fri, Apr 3, 2020 at 2:46 pm, Michael Catanzaro 
 wrote:

packages


Sorry, I meant: packagers

Probably only packagers need access to dist-git, but we have other 
Fedora teams besides packagers that will need to use the instance too. 
So that's a minimum


___
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 Fri, Apr 3, 2020 at 12:10 pm, Adam Williamson 
 wrote:

I assume Gitlab likes money. :P


$100/month per user for Ultimate (the only offering that meets the 
"requirements")... 2339 packages in FAS... so $233900 * 12 works out to 
roughly $3 million per year just for Fedora, assuming we never let 
anybody other than approved Fedora packagers use the instance. Or in 
terms of salary: a couple dozen software developers, more or less.


I wonder if that's really more cost-effective than hiring a couple more 
infrastructure devs


> Another is requirement 19 ("As a Project
contributor...I want to be able to use kanban boards...So that my team
can easily schedule and prioritize work in a visible way").

Kanban is actually an open source feature: 
https://gitlab.gnome.org/GNOME/epiphany/-/boards


___
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 Fri, 2020-04-03 at 14:41 -0500, Chris Adams wrote:
> Once upon a time, Kevin Fenzi  said:
> > Fedora Infrastructure has always been open and welcoming of community
> > work. The VAST majority of folks who have worked on it (at least the
> > operations side) in the past or are now, started out in the community
> > and eventually ended up doing it full time. 
> 
> I have considered trying to join in to help infra a couple of times...
> I used to run a public mirror and then changed jobs (actually might have
> equipment to do it again soon) and would still like to contribute.  One
> thing that I've found daunting is that, as a small-time packager that
> has to look up how to update my stuff every single time, I don't know
> many of the pieces or how they fit together.  So the "self starter"
> aspect is difficult because I don't think I'd know where to start.

FWIW, just as a personal take..mmy usual answer to this conundrum is:
find something broken that's annoying you. (This is usually not too
hard! :>) Then try and fix it.

I usually find it's possible to find the bit that's broken (because the
exact nature of the error gives you clues) and work out enough to fix
that, without learning the whole system at once. But you get a hold of
a 'corner piece', so to speak. And then I usually wind up thinking
"well, hmm, if *that* bit is here, what does *that* bit over there
do?", or find something else that just looks possibly broken or weird,
and look into that, and keep going from there...
-- 
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 Adams]

Once upon a time, Kevin Fenzi  said:
> Fedora Infrastructure has always been open and welcoming of community
> work. The VAST majority of folks who have worked on it (at least the
> operations side) in the past or are now, started out in the community
> and eventually ended up doing it full time. 

I have considered trying to join in to help infra a couple of times...
I used to run a public mirror and then changed jobs (actually might have
equipment to do it again soon) and would still like to contribute.  One
thing that I've found daunting is that, as a small-time packager that
has to look up how to update my stuff every single time, I don't know
many of the pieces or how they fit together.  So the "self starter"
aspect is difficult because I don't think I'd know where to start.

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

[Randy Barlow]

On 4/3/20 3:08 PM, Leigh Griffin wrote:
It may have caught that for sure but it would have opened a lot more 
problems as stakeholders try to counter each others requirements with 
new more specific requirements to influence the decision.


This is how software development is *supposed* to work. It is the job of 
the product owner to resolve disagreements between stakeholders, not to 
quash communication between them.

___
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 Fri, 2020-04-03 at 19:28 +0100, Leigh Griffin wrote:
> On Fri, Apr 3, 2020, 18:21 Adam Williamson 
> wrote:
> 
> > On Fri, 2020-04-03 at 13:04 -0400, Ben Cotton wrote:
> > 
> > > One thing I'll note here: this is *exactly* the kind of thing that
> > > > would have come to light very quickly if the open process which was
> > > > committed to at the start had actually been followed through on.
> > > 
> > > You are absolutely right. I screwed up.
> > 
> > Just to be clear, by that comment I was referring to the whole stuff
> > about open meetings and calls and things that were supposed to happen
> > before the decision was made, but which CPE called off because the
> > decision was "obvious".
> > 
> 
> That was not the case and I have explained this several times. There was an
> open discussion on the Fedora requirements before they were finalized.

But there wasn't an open discussion on the finalized list, or on the
summarized list. That would have been the point at which this gap could
have been spotted.

Still, if the F/OSS requirement was communicated in some other way and
was not *entirely* lost in the process of user story evaluation (as, to
be fair, the rejection of Github implies), the situation is certainly
not as bad as it first seemed.

> There was not an open discussion on the entire list end to end for reasons
> I have already stated as cross stakeholder analysis with no recourse for
> all stakeholders involved was not something that would have added value. I
> stand over that and again I apologise for not looping the entire
> stakeholder group in.

I'm referring to this specific promise which was made in the initial
description of the process:

"Additionally, a live video call and associated IRC meetings will be
held and advertised in advance to discuss the requirements, talk about
concerns and address any questions."

That, AFAIK, did not happen. If it *had* happened, that would have been
precisely the point at which someone would have looked at the list and
said "hey, wait, why does it not say anything at all about F/OSS?", and
the discussion we've had here over the last two days could have
happened there instead. Which, I'm pretty sure, would have added quite
a lot of value.
-- 
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

[Jeremy Cline]

Hi Leigh,

On Fri, 2020-04-03 at 17:00 +0100, Leigh Griffin wrote:
> 
> 
> On Fri, Apr 3, 2020 at 4:20 PM Jeremy Cline 
> wrote:
> > On Fri, 2020-04-03 at 05:38 -0400, Neal Gompa wrote:
> > > On Fri, Apr 3, 2020 at 5:29 AM Michal Konecny <
> > mkone...@redhat.com>
> > > wrote:
> > > > On 03/04/2020 01:25, Jeremy Cline wrote:
> > > > > On Thu, 2020-04-02 at 11:52 +0100, Leigh Griffin wrote:
> > > > > > The number of active developers on Fedora initiatives has
> > gone
> > > > > > up
> > > > > > drastically since I joined the team in 2019. You are
> > possibly
> > > > > > not
> > > > > > seeing that as the team have moved from a model of siloed
> > work
> > > > > > on
> > > > > > multiple apps, swimming against the tid working 16 hour
> > days,
> > > > > > to
> > > > > > working on team oriented initiatives to add real value to
> > the
> > > > > > ecosystem. So the noise of working on multiple small things
> > at
> > > > > > once
> > > > > > is not as loud as it was in 2018 which is giving that
> > illusion.
> > > > > I'd always suspected my work added no real value, but never
> > had
> > > > > the
> > > > > proof. I appreciate the validation .
> 
> Sorry I missed this among the thread splits and dozens of other
> replies. Ping me offlist if you have specific concerns as I do not
> believe my comment infers a lack of value in your work or any other
> contributor for that matter and the wealth of positive comments since
> is validating that your contributions were indeed most welcome and
> appreciative. If I did somehow infer that your work had no value, I
> do apologise, lets connect though if you have concerns.
>  

I'm not sure how to be more specific, but here goes:

When you said "the team have moved from a model of siloed work on
multiple apps, swimming against the tid[e] working 16 hour days, to
working on team oriented initiatives to add *real value* to the
ecosystem" (emphasis is mine in order to be more specific), it made me
feel that what you are saying is prior work didn't add "real value".
Other comments you have made in this thread (e.g. "We aren't in the
habit of inventing work to do for ourselves anymore") re-enforce this
feeling.

While you may believe your comments never implied a lack of value, 
I'm not sure how else to interpret your comments throughout this
thread.

- Jeremy
___
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 Fri, 2020-04-03 at 19:30 +0100, Leigh Griffin wrote:
> On Fri, Apr 3, 2020, 18:22 Adam Williamson 
> wrote:
> 
> > On Fri, 2020-04-03 at 13:18 -0400, Matthew Miller wrote:
> > > On Fri, Apr 03, 2020 at 01:04:33PM -0400, Ben Cotton wrote:
> > > > For what it's worth, when I sent the list I included a reminder that
> > > > FOSS is always our strong preference where viable. It was a mistake to
> > > > not leave that in as a user story. I own that. I did that because of
> > > 
> > > Eh, I remember it somewhat differently. I don't think that _it is our
> > strong
> > > preference and very important to our community that this be open source_
> > is
> > > a _functional_ requirement, and doesn't really fit as a user story. So we
> > > pulled that out and emphasized it separately rather than leaving it as
> > one
> > > among many in the list.
> > 
> > Can Leigh comment on whether this was then considered in the decision
> > process based on the summarized user stories, or was it lost?
> > 
> 
> We read it and like the wording implied it was a strong preference. It was
> not a requirement and it did not bind our decision not did emotive
> discussions or other comments, we dealt with the requirements at hand. It
> will certainly influence our decision to opt for Gitlab CE for the Fedora
> preference to stay open source.

Thanks for stating that, it's helpful.
-- 
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 Fri, 2020-04-03 at 20:12 +0200, Markus Larsson wrote:
> 
> On 3 April 2020 19:18:57 CEST, Matthew Miller  
> wrote:
> > On Fri, Apr 03, 2020 at 01:04:33PM -0400, Ben Cotton wrote:
> > > For what it's worth, when I sent the list I included a reminder that
> > > FOSS is always our strong preference where viable. It was a mistake to
> > > not leave that in as a user story. I own that. I did that because of
> > 
> > Eh, I remember it somewhat differently. I don't think that _it is our strong
> > preference and very important to our community that this be open source_ is
> > a _functional_ requirement, and doesn't really fit as a user story. So we
> > pulled that out and emphasized it separately rather than leaving it as one
> > among many in the list.
> > 
> > 
> 
> I would dare to say that going with a proprietary solution not only
> reflects poorly on Fedora but also on Red Hat since it's basically
> saying "we needed proper stuff so we couldn't use FOSS".

Snipping the more general stuff - just to keep things grounded here, my
understanding of the current situation is that we have decided on
"Gitlab" for Fedora dist-git going forwards, and possibly also setting
up some kind of generic project hosting-type "Gitlab" instance to live
alongside pagure.io and potentially replace it if pagure.io winds up
being unsustainable without CPE resources behind it.

Up front, a note: maybe we should at least be happy that Github was
roundly rejected! That would have been a lot worse!

The specifics of what choosing "Gitlab" means, *exactly*, ostensibly
remain undecided or at least uncommunicated. That's my reading of
https://communityblog.fedoraproject.org/making-a-git-forge-decision/ at
least. It specifies a choice of "Gitlab", and says the "plan going
forward" is to:

"Engage with GitLab on the possibility of a SaaS offering so that CPE
can attain key requirements of uptime, availability and throughput as
well as ensuring tooling integrations (such as Fedora Messaging among
others) are preserved. Legal considerations with respect to control of
code will be our first discussion point with them enabling us to make a
SaaS versus self-hosted decision."

(the other items relate to Pagure). That's really as much detail as is
on offer.

So, as I mentioned in another email, "Gitlab" isn't really one thing.
You can see Gitlab's various offerings here:

https://about.gitlab.com/handbook/marketing/product-marketing/tiers/

(which makes things much clearer than
https://about.gitlab.com/pricing/ ).

As you can see there, Gitlab's model is open core: the 'Core' product
(hosted version 'Free') is open source, the other three products are
not.

To me the decision blog post *implies* that we would prefer hosted
(SaaS) to self-hosted, if these "legal considerations" can be managed.
Nothing I've seen in the decision blog or the discussion here suggests
that a decision has been as to *which Gitlab product* we want, or
subsidiary questions such as "does it have to be the same product for
all instances we are going to wind up with?", "do we actually know how
many instances we are going to wind up with for all our stakeholders?",
"are some or all of those instances going to be shared between
stakeholders, and how does that affect the evaluation of
requirements?", and so on.

Another interesting question is obviously whether we can negotiate with
Gitlab for a custom hosted solution where we get the (open source) Core
*product*, but pay for the higher levels of *capacity* and *service*
available at the higher tiers (which are usually tied to the non-open-
source products). I am not experienced in such matters, but on the face
of it, it doesn't seem like an unreasonable request. I assume Gitlab
likes money. :P

A thing that is making people worried about these questions, I think,
is that the *summarized list of user stories* includes several items
that *imply* the choice might be tilted in favour of the non-open-
source Gitlab products. One instance of this that Neal cited is the
"merge trains" requirement. Another is requirement 19 ("As a Project
contributor...I want to be able to use kanban boards...So that my team
can easily schedule and prioritize work in a visible way"). There may
be others, but I'm not 100% sure, so I won't cite them.

The fact that these requirements are cited in the blog post and the
blog post does *not* delve into these questions at all leaves a big
space for uncertainty and doubt, which we are (as is the way of these
things) pleased to fill with speculation. I think it would be great if
CPE could lay out its take on these questions and give us more detail
about its plan going forward. I would also hope we (Fedora) can make it
*very very clear* that our strong preference for F/OSS software should
be taken into account in this: if there are only a few requirements
beyond what could be provided by the open source Gitlab Core, I'd hope
we would think long and hard about whether fulfilling those
requirements justified co

Re: CPE Git Forge Decision

[Leigh Griffin]

On Fri, Apr 3, 2020, 17:42 Adam Williamson 
wrote:

> On Fri, 2020-04-03 at 12:07 -0400, Ben Cotton wrote:
> > On Fri, Apr 3, 2020 at 11:59 AM Leigh Griffin 
> wrote:
> > > > Can we *please* see the final actual definitely official Fedora list,
> > > > then? If this is supposed to be an open process?
> > > @Ben Cotton can oblige here, it's not my place to share it without a
> stakeholder approval.
> >
> > The list sent to CPE is below. While there was no intent to hide it
> > (it can be reconstructed from the council-discuss thread), it was a
> > mistake on my part to not explicitly post this at the end of the
> > discussion.
> >
> > As a Fedora contributor, I want the git forge to integrate with FAS so
> > that it can use FAS to provide authentication and authorization.
> >
> > As a Fedora contributor, I want the git forge to integrate with
> > fedora-messaging so that it can be a part of automatic workflows.
> >
> > As a Fedora contributor, I want it to be easy to add new contributors
> > to a project (and optionally to enable self-adding) so that joining
> > new teams is low-friction.
>
> [snip]
>
> Uh...wow.
>
> So, Leigh was correct,


Disclaimer that this is not aimed at you Adam, it's a broad statement. It's
a shame that the perception is that I'm not correct or truthful on points
like this. I can see why that might be the case given problems with the
communication flow but know this, what I stated in all of my replies is
truthful and up front about how we evaluated and discussed this. Whether we
got it perfect or could have done things differently is another discussion.

and the F/OSS and self-hosting requirements are
> entirely removed from this list. Not adjusted or de-emphasized or given
> nuance, but simply removed entirely.
>
> I highly dispute the idea that the removal of the F/OSS requirement
> could be "reconstructed" from that initial list plus the discussion at
>
> https://lists.fedoraproject.org/archives/list/council-disc...@lists.fedoraproject.org/thread/OEPDGVKYAJIQ6YYZU5J3XT3LHXFROFI5/
> . I do not believe that is the case at all. Matthew's comment is
> confusing and ambiguous, and there was no follow-up to it (at least,
> not the F/OSS part of it), and it seems extremely questionable to me
> that we would remove such a fundamental requirement based solely on one
> confused comment from Matthew. He is the FPL, he is not the Pope.
>
> The end result of this is that we (Fedora) have somehow indicated to
> CPE that we have no preference whatsoever for F/OSS tooling. I do not
> believe that should have been the case.
>
> The self-hosting requirement at least Matthew was more clear in opining
> should be removed, but it is still surprising to me that the process
> here went "gather a list of requirements from the community, then if
> Matt says he disagrees with one, take it out immediately but don't tell
> anyone you did that"! (also I'll note that his substitute requirement
> that out-migration be easy does not appear to be captured in the final
> list, although it seems this probably *is* the case with Gitlab so we
> don't have a problem there.)
>
> One thing I'll note here: this is *exactly* the kind of thing that
> would have come to light very quickly if the open process which was
> committed to at the start had actually been followed through on.
>

It may have caught that for sure but it would have opened a lot more
problems as stakeholders try to counter each others requirements with new
more specific requirements to influence the decision. The approach taken,
for better or worse evaluated it at a functional level without that noise
factor. The trade off is losing an opportunity like this, however it could
have been picked up several other ways and Ben has already apologised for
not sharing back the final list.

> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
> ___
> council-discuss mailing list -- council-disc...@lists.fedoraproject.org
> To unsubscribe send an email to
> council-discuss-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/council-disc...@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

[Randy Barlow]

On 4/3/20 1:53 PM, Neal Gompa wrote:

Honestly, the main app I have trouble seeing a broader community for
is Bodhi. It*could*  be done, but I'd have to sit down and do a fair
bit of work to figure out what parts are "Fedora-only" verses
"Fedora-favored". It speaks volumes that even*Red Hat*  doesn't use
Bodhi, and nor does RPM Fusion.


I think of Bodhi as basically being a robotic Koji admin that implements 
Fedora's update workflow. It is so Koji oriented that I think it would 
be a lot of work to abstract it to make sense for other build systems. 
It's also very Fedora oriented, to where it would also be a lot of work 
to abstract it to accommodate workflows for other distros.


Red Hat doesn't use it because they have different workflows than Fedora.

None of this is to say that the abstractions could not or should not be 
done, but more than it wouldn't be a small task.

___
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 Fri, Apr 3, 2020, 18:22 Adam Williamson 
wrote:

> On Fri, 2020-04-03 at 13:18 -0400, Matthew Miller wrote:
> > On Fri, Apr 03, 2020 at 01:04:33PM -0400, Ben Cotton wrote:
> > > For what it's worth, when I sent the list I included a reminder that
> > > FOSS is always our strong preference where viable. It was a mistake to
> > > not leave that in as a user story. I own that. I did that because of
> >
> > Eh, I remember it somewhat differently. I don't think that _it is our
> strong
> > preference and very important to our community that this be open source_
> is
> > a _functional_ requirement, and doesn't really fit as a user story. So we
> > pulled that out and emphasized it separately rather than leaving it as
> one
> > among many in the list.
>
> Can Leigh comment on whether this was then considered in the decision
> process based on the summarized user stories, or was it lost?
>

We read it and like the wording implied it was a strong preference. It was
not a requirement and it did not bind our decision not did emotive
discussions or other comments, we dealt with the requirements at hand. It
will certainly influence our decision to opt for Gitlab CE for the Fedora
preference to stay open source.

> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
> ___
> council-discuss mailing list -- council-disc...@lists.fedoraproject.org
> To unsubscribe send an email to
> council-discuss-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/council-disc...@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 Fri, Apr 3, 2020, 18:21 Adam Williamson 
wrote:

> On Fri, 2020-04-03 at 13:04 -0400, Ben Cotton wrote:
>
> > One thing I'll note here: this is *exactly* the kind of thing that
> > > would have come to light very quickly if the open process which was
> > > committed to at the start had actually been followed through on.
> >
> > You are absolutely right. I screwed up.
>
> Just to be clear, by that comment I was referring to the whole stuff
> about open meetings and calls and things that were supposed to happen
> before the decision was made, but which CPE called off because the
> decision was "obvious".
>

That was not the case and I have explained this several times. There was an
open discussion on the Fedora requirements before they were finalized.
There was not an open discussion on the entire list end to end for reasons
I have already stated as cross stakeholder analysis with no recourse for
all stakeholders involved was not something that would have added value. I
stand over that and again I apologise for not looping the entire
stakeholder group in.

-- 
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
> ___
> council-discuss mailing list -- council-disc...@lists.fedoraproject.org
> To unsubscribe send an email to
> council-discuss-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/council-disc...@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

[Markus Larsson]

On 3 April 2020 19:18:57 CEST, Matthew Miller  wrote:
>On Fri, Apr 03, 2020 at 01:04:33PM -0400, Ben Cotton wrote:
>> For what it's worth, when I sent the list I included a reminder that
>> FOSS is always our strong preference where viable. It was a mistake to
>> not leave that in as a user story. I own that. I did that because of
>
>Eh, I remember it somewhat differently. I don't think that _it is our strong
>preference and very important to our community that this be open source_ is
>a _functional_ requirement, and doesn't really fit as a user story. So we
>pulled that out and emphasized it separately rather than leaving it as one
>among many in the list.
>
>

I would dare to say that going with a proprietary solution not only reflects 
poorly on Fedora but also on Red Hat since it's basically saying "we needed 
proper stuff so we couldn't use FOSS".
I can see that the team is strained, what I don't understand is why that exact 
team needs to run all infra. If the team doesn't have the capacity to take care 
of everything on their plate they either need more resources or a smaller scope.
This puts an unnecessary strain on the RH - Fedora relationship.
Anyone involved here wants things to work well and everyone is involved because 
they want to.
We have built an odd structure that creates friction and conflict though.
There needs to some talks about how the CPE should work and what services they 
should deliver. The CPE team does great work and works hard to deliver working 
solutions but often get met with suspicion and even hostility when they push 
for changes.
They play the part of corporate IT in any large corporation. They are staffed 
to do way less than what they are asked and the users they serve can't really 
go to someone else if they feel they aren't getting what they need.
Sadly that is rather built in to the current model, it's basically a negative 
feedback loop.
I think the lofty goals of the Fedora project can't be realized if we aren't 
organized to promote them.
Sorry for the rant, it's has been brewing for quite a while and I really don't 
know where to turn with it.

Br
Markus

___
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 Fri, Apr 3, 2020 at 1:28 PM Kevin Fenzi  wrote:
>
> On Fri, Apr 03, 2020 at 09:55:48AM +0200, Clement Verna wrote:
>
> ...snip...
>
> (side note: can people please try and trim their replies to this list?
> I know gmail makes that hard, but it's anoying to read a thread where
> you have to keep hitting page down to get the next few lines of new
> text. Thanks in advance for anyone who can do this. :)
>

I'm trying. There's a lot to reply to now... :)

> > Yes, indeed I see your point and this whole thread made me realize that
> > maybe we have not been good enough at communicating that we need help. I
> > mean one way to see it, is that Red Hat should be investing more in the
> > team but another way is that we are failing to get more support from within
> > our community.
> > As Neal and Smooge mentioned it is difficult to contribute and help in the
> > infra and releng activities, it is not impossible but there is a very high
> > entry fee to pay which is to understand how all the tools and services
> > interact together + the history of why this was done that way.
>
> Well, I am not sure I would say it's difficult at all, but it does have
> a lot of challenges.
>
> Fedora Infrastructure has always been open and welcoming of community
> work. The VAST majority of folks who have worked on it (at least the
> operations side) in the past or are now, started out in the community
> and eventually ended up doing it full time.
>
> On our side we want:
> * people who are reliable. Who commit to doing things and do them.
> * people who are willing to learn. No one knows everything, someone who
> is able to learn is much nicer than someone who knows a ton and won't do
> things other than the way they know.
> * self motivated folks. Since we don't have much free time, we have
> typically heavily weighted toward self starters. People who ask
> questions, people who provide patches, people who ask if they can do X,
> etc.
>
> Unfortunately, this filters almost everyone out these days.
>
> There were a lot more folks a number of years back, I think because back
> then infrastructure was the hot thing. puppet and ansible and vm's!
> But now more people are interested in containers/openshift/cloud
> services, etc. We just aren't that interesting anymore.
>

I don't know if that's really true. You have a number of interesting
apps, you have relatively popular infrastructure methods. There are a
lot of people who'd like to learn and build skills in this sort of
thing. There's even containers and OpenShift stuff now, so you can
attract those people too!

It took a long time before I even knew about these parts of Fedora! I
found out in 2014 as part of a job posting that I applied to and
ultimately was rejected for. I started doing work in Fedora
infrastructure in 2016, and have been progressively building up what
I've been doing since.

I even personally know of a few folks who might be interested in
contributing in this manner if they knew how.

> > In the same time, I honestly think the team does a good job at being
> > transparent and welcoming to people willing to help, we have weekly and
> > daily "standup" style meetings on IRC (infra and releng), we have started
> > to do backlog prioritization on the infra list. We have also tried in the
> > past to have office hours or apprentice day to help people make some
> > contribution. Unfortunately the reality is that we don't have much
> > participation to these initiatives. I am very happy to think that we are
> > doing something wrong, and if anyone has ideas on how we could improve or
> > make it easier to contribute to infra and releng please reach out.
>
> Ditto. Happy to try new things or ideas.
>

Well, there's potentially an opportunity here with all these people
being affected by... uhh... current global events?

> On Thu, Apr 02, 2020 at 11:43:15AM -0400, Neal Gompa wrote:
> >
> > For what it's worth, I think some of the problem here is that I don't
> > see many avenues for the Fedora community to take an active part in
> > the infrastructure. In the openSUSE Project, I'm involved in the
> > openSUSE Heroes team, and with that, I actually *do* have the
> > opportunity to actively assist with the deployment, management, and
> > basic maintenance of solutions used by the openSUSE Project. The
> > Fedora equivalent team doesn't exist. There is the releng and
> > infrastructure teams, but those are gradually being absorbed by the
> > Red Hat CPE team, and as indicated earlier somewhere, CPE team is not
> > a community team. The codebases and effort involved when not being
> > able to share it with the community is high.
>
> We have groups for many/most of our applications that let people in that
> group commit to ansible and run the playbooks to deploy things.
>
> We have an apprentice group that has access to machines, so they can
> look at things and propose patches.
>

Do we have any formal docs on this?

Could we even just get the pagure ansible repo working[

Re: CPE Git Forge Decision

[Kevin Fenzi]

On Fri, Apr 03, 2020 at 09:55:48AM +0200, Clement Verna wrote:

...snip...

(side note: can people please try and trim their replies to this list? 
I know gmail makes that hard, but it's anoying to read a thread where
you have to keep hitting page down to get the next few lines of new
text. Thanks in advance for anyone who can do this. :) 

> Yes, indeed I see your point and this whole thread made me realize that
> maybe we have not been good enough at communicating that we need help. I
> mean one way to see it, is that Red Hat should be investing more in the
> team but another way is that we are failing to get more support from within
> our community.
> As Neal and Smooge mentioned it is difficult to contribute and help in the
> infra and releng activities, it is not impossible but there is a very high
> entry fee to pay which is to understand how all the tools and services
> interact together + the history of why this was done that way.

Well, I am not sure I would say it's difficult at all, but it does have
a lot of challenges. 

Fedora Infrastructure has always been open and welcoming of community
work. The VAST majority of folks who have worked on it (at least the
operations side) in the past or are now, started out in the community
and eventually ended up doing it full time. 

On our side we want: 
* people who are reliable. Who commit to doing things and do them. 
* people who are willing to learn. No one knows everything, someone who
is able to learn is much nicer than someone who knows a ton and won't do
things other than the way they know. 
* self motivated folks. Since we don't have much free time, we have
typically heavily weighted toward self starters. People who ask
questions, people who provide patches, people who ask if they can do X,
etc. 

Unfortunately, this filters almost everyone out these days. 

There were a lot more folks a number of years back, I think because back
then infrastructure was the hot thing. puppet and ansible and vm's! 
But now more people are interested in containers/openshift/cloud
services, etc. We just aren't that interesting anymore. 

> In the same time, I honestly think the team does a good job at being
> transparent and welcoming to people willing to help, we have weekly and
> daily "standup" style meetings on IRC (infra and releng), we have started
> to do backlog prioritization on the infra list. We have also tried in the
> past to have office hours or apprentice day to help people make some
> contribution. Unfortunately the reality is that we don't have much
> participation to these initiatives. I am very happy to think that we are
> doing something wrong, and if anyone has ideas on how we could improve or
> make it easier to contribute to infra and releng please reach out.

Ditto. Happy to try new things or ideas.

On Thu, Apr 02, 2020 at 11:43:15AM -0400, Neal Gompa wrote:
> 
> For what it's worth, I think some of the problem here is that I don't
> see many avenues for the Fedora community to take an active part in
> the infrastructure. In the openSUSE Project, I'm involved in the
> openSUSE Heroes team, and with that, I actually *do* have the
> opportunity to actively assist with the deployment, management, and
> basic maintenance of solutions used by the openSUSE Project. The
> Fedora equivalent team doesn't exist. There is the releng and
> infrastructure teams, but those are gradually being absorbed by the
> Red Hat CPE team, and as indicated earlier somewhere, CPE team is not
> a community team. The codebases and effort involved when not being
> able to share it with the community is high.

We have groups for many/most of our applications that let people in that
group commit to ansible and run the playbooks to deploy things. 

We have an apprentice group that has access to machines, so they can
look at things and propose patches. 

> Of course, as long as Fedora is using FOSS solutions that have low
> barriers to entry for contributors (like Pagure, Noggin, Ipsilon,
> Fedocal, fedora-packages, anitya, nuancier, etc.) and those projects
> are advertised as ways to contribute to the Fedora Project, then a
> good chunk of the burden on the CPE team can probably be lowered
> organically. As I said in my original email, Fedora needs to be a
> better steward and umbrella organization. By doing so, we can support
> our enthusiastic contributors and make for a stronger community.

The problem is that a lot of our apps have a very limited userbase and
an even smaller community. 

How would you setup a community around 'pagure-dist-git'? we are the
only ones likely to run that. fedora-messaging? all the various apps
that bridge messages onto the bus, etc.

If you have a magic wand that can create long term viable communities,
please let me borrow it. ;) 

kevin


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproje

Re: CPE Git Forge Decision

[Adam Williamson]

On Fri, 2020-04-03 at 10:08 -0700, Kevin Fenzi wrote:
> On Fri, Apr 03, 2020 at 11:11:52AM +0200, Vít Ondruch wrote:
> > I see one more trend nobody is really talking about.
> > 
> > Once there appears somebody brilliant in community, sooner or later Red
> > Hat hires him. Unfortunately, this rarely means that the person keeps
> > their independence. This also means that later we are missing the "pure"
> > community. May be Fedora should sponsor some volunteers to do some work,
> > without Red Hat hiring them.
> 
> Yeah, man, it was horrible when Red Hat hired me to work on Fedora full
> time, I'm sure I lost my independence right away, but I sure have
> (mostly) enjoyed it. :) 

Yeah, as you can tell from this thread, those of us who work for Red
Hat have a restraining collar and censorship chip fitted on day one ;)
-- 
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 Fri, 2020-04-03 at 13:18 -0400, Matthew Miller wrote:
> On Fri, Apr 03, 2020 at 01:04:33PM -0400, Ben Cotton wrote:
> > For what it's worth, when I sent the list I included a reminder that
> > FOSS is always our strong preference where viable. It was a mistake to
> > not leave that in as a user story. I own that. I did that because of
> 
> Eh, I remember it somewhat differently. I don't think that _it is our strong
> preference and very important to our community that this be open source_ is
> a _functional_ requirement, and doesn't really fit as a user story. So we
> pulled that out and emphasized it separately rather than leaving it as one
> among many in the list.

Can Leigh comment on whether this was then considered in the decision
process based on the summarized user stories, or was it lost?
-- 
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 Fri, 2020-04-03 at 13:04 -0400, Ben Cotton wrote:

> One thing I'll note here: this is *exactly* the kind of thing that
> > would have come to light very quickly if the open process which was
> > committed to at the start had actually been followed through on.
> 
> You are absolutely right. I screwed up.

Just to be clear, by that comment I was referring to the whole stuff
about open meetings and calls and things that were supposed to happen
before the decision was made, but which CPE called off because the
decision was "obvious".
-- 
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

[Matthew Miller]

On Fri, Apr 03, 2020 at 01:04:33PM -0400, Ben Cotton wrote:
> For what it's worth, when I sent the list I included a reminder that
> FOSS is always our strong preference where viable. It was a mistake to
> not leave that in as a user story. I own that. I did that because of

Eh, I remember it somewhat differently. I don't think that _it is our strong
preference and very important to our community that this be open source_ is
a _functional_ requirement, and doesn't really fit as a user story. So we
pulled that out and emphasized it separately rather than leaving it as one
among many in the list.


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

[Kevin Fenzi]

On Fri, Apr 03, 2020 at 11:11:52AM +0200, Vít Ondruch wrote:
> 
> I see one more trend nobody is really talking about.
> 
> Once there appears somebody brilliant in community, sooner or later Red
> Hat hires him. Unfortunately, this rarely means that the person keeps
> their independence. This also means that later we are missing the "pure"
> community. May be Fedora should sponsor some volunteers to do some work,
> without Red Hat hiring them.

Yeah, man, it was horrible when Red Hat hired me to work on Fedora full
time, I'm sure I lost my independence right away, but I sure have
(mostly) enjoyed it. :) 

As far as I can tell the clause in the Red Hat business
ethics document still applies: 

"Participation in an open source community project, whether maintained by the 
Company or by 
another commercial or non-commercial entity or organization, does not 
constitute a conflict of 
interest even where you may make a determination in the interest of the project 
that is adverse to 
the Company’s interests."

> Also, for project such as Pagure, I don't think we benefit enough from
> programs such as GSoC. I'm not saying that we don't do this and of
> course such participants needs mentors etc ...

Perhaps, but those projects often do shiny new development rather than
needed reworking or day to day maintaining. 

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

[Matthew Miller]

On Fri, Apr 03, 2020 at 09:42:12AM -0700, Adam Williamson wrote:
> He is the FPL, he is not the Pope.

I think we can all agree that this is for the best. :)

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

[Ben Cotton]

On Fri, Apr 3, 2020 at 12:42 PM Adam Williamson
 wrote:
>
> The end result of this is that we (Fedora) have somehow indicated to
> CPE that we have no preference whatsoever for F/OSS tooling. I do not
> believe that should have been the case.
>
For what it's worth, when I sent the list I included a reminder that
FOSS is always our strong preference where viable. It was a mistake to
not leave that in as a user story. I own that. I did that because of
the unanimously-adopted[1] Council position that "The Fedora Project
wants to advance free and open source software and as a pragmatic
matter we recognize that some infrastructure needs may be best served
by using closed source or non-free tools today. Therefore the Council
is willing to accept closed source or non-free tools in Fedora’s
infrastructure where free and open source tools are not viable or not
available."

You're right that it should have remained in.

> One thing I'll note here: this is *exactly* the kind of thing that
> would have come to light very quickly if the open process which was
> committed to at the start had actually been followed through on.

You are absolutely right. I screwed up.

[1] 
https://communityblog.fedoraproject.org/fedora-council-december-2018-hackfest-report/

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

[Adam Williamson]

On Fri, 2020-04-03 at 12:07 -0400, Ben Cotton wrote:
> On Fri, Apr 3, 2020 at 11:59 AM Leigh Griffin  wrote:
> > > Can we *please* see the final actual definitely official Fedora list,
> > > then? If this is supposed to be an open process?
> > @Ben Cotton can oblige here, it's not my place to share it without a 
> > stakeholder approval.
> 
> The list sent to CPE is below. While there was no intent to hide it
> (it can be reconstructed from the council-discuss thread), it was a
> mistake on my part to not explicitly post this at the end of the
> discussion.
> 
> As a Fedora contributor, I want the git forge to integrate with FAS so
> that it can use FAS to provide authentication and authorization.
> 
> As a Fedora contributor, I want the git forge to integrate with
> fedora-messaging so that it can be a part of automatic workflows.
> 
> As a Fedora contributor, I want it to be easy to add new contributors
> to a project (and optionally to enable self-adding) so that joining
> new teams is low-friction.

[snip]

Uh...wow.

So, Leigh was correct, and the F/OSS and self-hosting requirements are
entirely removed from this list. Not adjusted or de-emphasized or given
nuance, but simply removed entirely.

I highly dispute the idea that the removal of the F/OSS requirement
could be "reconstructed" from that initial list plus the discussion at
 
https://lists.fedoraproject.org/archives/list/council-disc...@lists.fedoraproject.org/thread/OEPDGVKYAJIQ6YYZU5J3XT3LHXFROFI5/
. I do not believe that is the case at all. Matthew's comment is
confusing and ambiguous, and there was no follow-up to it (at least,
not the F/OSS part of it), and it seems extremely questionable to me
that we would remove such a fundamental requirement based solely on one
confused comment from Matthew. He is the FPL, he is not the Pope.

The end result of this is that we (Fedora) have somehow indicated to
CPE that we have no preference whatsoever for F/OSS tooling. I do not
believe that should have been the case.

The self-hosting requirement at least Matthew was more clear in opining
should be removed, but it is still surprising to me that the process
here went "gather a list of requirements from the community, then if
Matt says he disagrees with one, take it out immediately but don't tell
anyone you did that"! (also I'll note that his substitute requirement
that out-migration be easy does not appear to be captured in the final
list, although it seems this probably *is* the case with Gitlab so we
don't have a problem there.)

One thing I'll note here: this is *exactly* the kind of thing that
would have come to light very quickly if the open process which was
committed to at the start had actually been followed through on.
-- 
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

[Ben Cotton]

On Fri, Apr 3, 2020 at 11:59 AM Leigh Griffin  wrote:
>
>> Can we *please* see the final actual definitely official Fedora list,
>> then? If this is supposed to be an open process?
> @Ben Cotton can oblige here, it's not my place to share it without a 
> stakeholder approval.

The list sent to CPE is below. While there was no intent to hide it
(it can be reconstructed from the council-discuss thread), it was a
mistake on my part to not explicitly post this at the end of the
discussion.

As a Fedora contributor, I want the git forge to integrate with FAS so
that it can use FAS to provide authentication and authorization.

As a Fedora contributor, I want the git forge to integrate with
fedora-messaging so that it can be a part of automatic workflows.

As a Fedora contributor, I want it to be easy to add new contributors
to a project (and optionally to enable self-adding) so that joining
new teams is low-friction.

As a Fedora community member, I want to self-organize my personal and
team work by creating projects and groups of projects, by defining
different access levels, and by having basic contribution allowed for
everyone by default, so that I can contribute in full autonomy.

[dist-git] As a Fedora contributor, I want the dist-git to integrate
with other packaging services (anitya, koji, Bodhi, etc) so that it
can be a part of automatic workflows.

[code hosting] As a Fedora contributor, I want to encourage new
contributors with easyfix-like functionality so that newcomers can
find easy tasks to get started with.

[code hosting] As anyone, I want good search of code, commits, and
issues so that I can find particular parts of the code or project
history.

[code hosting] As a software maintainer, I want pull requests to allow
me to rebase so that I can accept pull requests without waiting for
the submitter to rebase.

As anyone, I want the URI to the archive (tar.xz, tar.bz2, etc)
corresponding to various code states (commit/tag/release/fork…) to be
regular and stable (ideally, identical to the Pagure URIs to avoid
reimplementing existing automation) so that I can point to
point-in-time snapshots of the repository.

As a Fedora contributor, I want the git repos to be fully accessible
over https (read and write) so that I can contribute from environments
where ssh is filtered for security reasons.

As a drive-by reader of Fedora docs, I want to click through to make a
suggested improvement without needing to set up a whole
code-development infrastructure so that I can make low-friction
contributions.

As a Fedora user, I want to easily create pull requests to any
dist-git repo so that I can make contributions to repos that I am not
a maintainer of.

As a package maintainer, I can only commit to a dist-git repo if I am
in the Fedora packager group so that non-packagers cannot directly
affect packages.

As a package maintainer, I can only commit to a dist-git repo if I am
a maintainer of the branch so that EPEL maintainers and Fedora
maintainers can be separate.

As a proven packager, I can commit to all dist-git repos that do not
have special restrictions set by FESCo or are retired so that I can
make bulk package updates or step in as directed by FESCo.

As a FESCO member, I can configure exceptions to disallow proven
packager access to a dist-git repo so that I can protect key packages.

As dist-git repo admin, I can easily add other maintainers to allow
commit or admin access for dist-git repo by using their FAS username
so that I can enable others to co-maintain a package.

As a dist-git repo admin, I cannot remove access to the repo from
Fedora infra, Releng or proven packagers without FESCo approval so
that Releng, infra, and provenpackagers have the ability to perform
their functions.

As a package maintainer, I can easily orphan a dist-git repo or branch
to show that it is not maintained anymore so that other maintainers
can adopt it.

As a package maintainer, I can adopt any orphaned dist-git repo or
branch so that it has an active maintainer.

As a package maintainer, I can easily unretire a retired dist-git repo
or branch so that it has an active maintainer.

As a release engineer, I can easily approve unretire requests for a
dist-git repo or branch so that it has an active maintainer.

As anybody, I can easily see the FAS usernames of maintainers for all
branches of a dist-git repo so that I know who to contact.

As a non-releng member, I cannot remove any commits from any dist-git
repo that were used to build a Fedora package so that the release
history remains intact.

As an external user, I can easily get a list of all orphaned or
retired dist-git repos and branches so that I know what packages need
maintainers.

As anybody, I can watch for issues or pull requests that are created
for a dist-git repository so that I can stay up-to-date on
repositories I care about.

As anybody, I can easily get a list of all dist-git repos that I am
watching so that I can be sure it matches my current needs.

Re: CPE Git Forge Decision

[Leigh Griffin]

On Fri, Apr 3, 2020 at 4:20 PM Jeremy Cline  wrote:

> On Fri, 2020-04-03 at 05:38 -0400, Neal Gompa wrote:
> > On Fri, Apr 3, 2020 at 5:29 AM Michal Konecny 
> > wrote:
> > > On 03/04/2020 01:25, Jeremy Cline wrote:
> > > > On Thu, 2020-04-02 at 11:52 +0100, Leigh Griffin wrote:
> > > > > The number of active developers on Fedora initiatives has gone
> > > > > up
> > > > > drastically since I joined the team in 2019. You are possibly
> > > > > not
> > > > > seeing that as the team have moved from a model of siloed work
> > > > > on
> > > > > multiple apps, swimming against the tid working 16 hour days,
> > > > > to
> > > > > working on team oriented initiatives to add real value to the
> > > > > ecosystem. So the noise of working on multiple small things at
> > > > > once
> > > > > is not as loud as it was in 2018 which is giving that illusion.
> > > > I'd always suspected my work added no real value, but never had
> > > > the
> > > > proof. I appreciate the validation .
>

Sorry I missed this among the thread splits and dozens of other replies.
Ping me offlist if you have specific concerns as I do not believe my
comment infers a lack of value in your work or any other contributor for
that matter and the wealth of positive comments since is validating that
your contributions were indeed most welcome and appreciative. If I did
somehow infer that your work had no value, I do apologise, lets connect
though if you have concerns.


> > > >
> > > > - Jeremy
> > > I bow before you mighty Jeremy and the work you did. The fedora
> > > messaging is really nice replacement of the fedmsg, although is not
> > > used
> > > by every application yet.
> > >
> > > I also want to thank you for handing me off the Anitya and
> > > the-new-hotness. It helped me grow my wizard realm in Fedora
> > > Universe. :-)
> >
> > I would also like to echo my appreciation of Jeremy and his work. In
> > particular, anitya is one of the tools I literally rely on to keep
> > track of my packages and keep them fresh. Without anitya, I would be
> > unable to do so. And we've slowly started to see other distributions
> > starting to rely on it too (Arch, Alpine, PLD, Mageia, openSUSE).
> >
> > So, thank you for building such an awesome tool, and thank you Michal
> > for taking up the reigns after that.
> >
>
> I can hardly take credit for anitya. pingou started it as far as I know
> and the project has over 50 contributors to the code, not to mention
> all the issues and work to map projects on release-monitoring.org
> itself.
>
> I appreciate all the kind words from folks and I do know that my work
> has, on occasion, provided more value than the trouble it caused.
>
> - Jeremy
> ___
> 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 Fri, Apr 3, 2020 at 4:04 PM Adam Williamson 
wrote:

> On Fri, 2020-04-03 at 13:18 +0100, Leigh Griffin wrote:
> >
> > > What I'm looking at is the commit logs. That's all that ultimately
> > > matters. But see above revisions, of course.
> > >
> >
> > I think that's a very narrow view of the world to base your assertions on
> > commit logs only, I don't see the value in it. If your end argument here
> is
> > that CPE do not spend enough time working on Fedora things then you are
> > very mistaken. Almost 80% of our team capacity is on Fedora and our
> > upcoming Q2 initiatives this is the same.
>
> Just to make sure this is really clear, no, that's not my intent at
> all. I was only following up on the question of whether the amount of
> resources available for what was previously referred to as "Fedora
> infra" (as opposed, for instance, to "Fedora release engineering") had
> increased, decreased or stayed the same (with "stayed the same" seeming
> to be the ultimate conclusion). By including or excluding anyone from
> the lists I absolutely did not mean to imply anything about the value
> of their contributions, or whether those contributions were to "Fedora"
> in a larger sense - I was only trying to keep it a like-for-like
> comparison. It's obvious from your and Clement's emails that this idea
> got lost somewhere as we got into the weeds of commit logs and the
> like, so I apologize for that, particularly as it turns out my initial
> impression that the resources available had declined was incorrect. I
> probably work closer with the releng folks than anyone and I certainly
> value their work highly!
>

I accept that apology and I'm glad I could straight out the state of CPE
for others to see, so it was a positive contribution to the discussion.

>
> The initial suggestion I made that triggered this subthread was not
> "perhaps CPE isn't spending enough time on Fedora" (I certainly don't
> believe that or intend to suggest it) but "perhaps Red Hat is not
> providing enough resources to CPE and other teams in order for Fedora
> to be run the way the Fedora community believes it should be run". As I
> said to Clement, I think the suggestion still bears consideration,
> given that Clement says the workload has increased appreciably.
>

+1 I'd make that representation to Fedora Council who in turn can take it
to the right folks in Red Hat.


>
> > > > Can you help me understand what the mystery is about? We took in 300+
> > > > requirements that we distilled down into the generic list that we
> came
> > > > up
> > > > with, many of which are buckets / Epics. Every single requirement was
> > > > analysed. I have said this multiple times but please, if this is
> still
> > > > a
> > > > mystery to you, let me know how I can help clarify it.
> > >
> > > The specific gap I am talking about is the gap between this list
> > > submitted by Ben Cotton on behalf of Fedora:
> > >
> > >
> > >
> https://lists.fedoraproject.org/archives/list/council-disc...@lists.fedoraproject.org/thread/OEPDGVKYAJIQ6YYZU5J3XT3LHXFROFI5/
> >
> > The thread you reference is not the list that was submitted. The first
> post
> > on that is not the final list, the final list was a result of the debates
> > and discussions that occurred on that thread and was submitted directly
> to
> > CPE. To be clear, we did not pull our Fedora requirements from that list
> > you are referencing.
>
> Well, that's interesting. I got that link from earlier in this thread,
> where Julen asked if that was the list you meant:
>
>
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/O4GHD2AH2E55JE45H6NUJ46JEDZAKBWY/
>
> and you said "yes":
>
>
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/F4HMYWOCACQAJY57G3ZNXMC7PSBRQPZ3/
>
> so, I'm only going on what you told us. If it is *not* in fact the
> final list, where *is* that final list?
>

It's in a Google Doc I received, I don't know where the public version is
but I think it's only the requirements that were debated that changed.

>
> There is a substantial comment from Matt in which he downplays the
> self-hosting requirement:
>
>
> https://lists.fedoraproject.org/archives/list/council-disc...@lists.fedoraproject.org/message/E5R55AS3Z7QLGRXAT6RGQKJNVXLTAJHJ/
>
> and kind of prevaricates a lot on the F/OSS requirement, first
> saying that he wants to emphasize it and then kind of saying the
> opposite for three paragraphs. So I can see where that might have
> caused some confusion. But without seeing this "final list" that you're
> now saying exists, it's hard to be sure.
>
> > >
> > > and the 'summarized' list you have pointed to here:
> > >
> > > https://hackmd.io/@My419-DISUGgo4gcmO1D6A/HJB74lcL8
> > >
> > > Now, right off the bat, we have a huge problem. The "summarized" list
> > > claims this:
> > >
> > > "after duplications and similar in theme requirements were merged
> > > together, we were left with the following unique User S

Re: CPE Git Forge Decision

[Jeremy Cline]

On Fri, 2020-04-03 at 05:38 -0400, Neal Gompa wrote:
> On Fri, Apr 3, 2020 at 5:29 AM Michal Konecny 
> wrote:
> > On 03/04/2020 01:25, Jeremy Cline wrote:
> > > On Thu, 2020-04-02 at 11:52 +0100, Leigh Griffin wrote:
> > > > The number of active developers on Fedora initiatives has gone
> > > > up
> > > > drastically since I joined the team in 2019. You are possibly
> > > > not
> > > > seeing that as the team have moved from a model of siloed work
> > > > on
> > > > multiple apps, swimming against the tid working 16 hour days,
> > > > to
> > > > working on team oriented initiatives to add real value to the
> > > > ecosystem. So the noise of working on multiple small things at
> > > > once
> > > > is not as loud as it was in 2018 which is giving that illusion.
> > > I'd always suspected my work added no real value, but never had
> > > the
> > > proof. I appreciate the validation .
> > > 
> > > - Jeremy
> > I bow before you mighty Jeremy and the work you did. The fedora
> > messaging is really nice replacement of the fedmsg, although is not
> > used
> > by every application yet.
> > 
> > I also want to thank you for handing me off the Anitya and
> > the-new-hotness. It helped me grow my wizard realm in Fedora
> > Universe. :-)
> 
> I would also like to echo my appreciation of Jeremy and his work. In
> particular, anitya is one of the tools I literally rely on to keep
> track of my packages and keep them fresh. Without anitya, I would be
> unable to do so. And we've slowly started to see other distributions
> starting to rely on it too (Arch, Alpine, PLD, Mageia, openSUSE).
> 
> So, thank you for building such an awesome tool, and thank you Michal
> for taking up the reigns after that.
> 

I can hardly take credit for anitya. pingou started it as far as I know
and the project has over 50 contributors to the code, not to mention
all the issues and work to map projects on release-monitoring.org
itself.

I appreciate all the kind words from folks and I do know that my work
has, on occasion, provided more value than the trouble it caused.

- Jeremy
___
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 Fri, 2020-04-03 at 12:45 +0100, Leigh Griffin wrote:
> On Thu, Apr 2, 2020 at 3:58 PM Michael Catanzaro 
> wrote:
> 
> > On Wed, Apr 1, 2020 at 8:16 pm, Paul Frields 
> > wrote:
> > > For a solution to be viable it needs to meet requirements.
> > 
> > Of course, but the problem is that the requirements identified by CPE
> > are wildly inconsistent with the actual requirements of the Fedora
> > community. The Pagure we have right now seems to be working fine for
> > Fedora. All we really need is occasional light maintenance and ensuring
> > the infrastructure keeps running. I don't think we'd be having this
> > conversation now at all if "dist-git must be open source" was a listed
> > requirement, as it should have been from the beginning.
> > 
> > We don't need merge trains or MR approvals or mobile apps (seriously?)
> > or private comments or gists or analytics or basically any of the other
> > requirements that Neal has lampooned. I understand CentOS and RHEL
> > really want merge trains, so maybe that one is a good faith
> > requirement, but I honestly don't think most of the rest of them are.
> > The list seems to have been concocted by looking at GitLab features
> > exclusive to Enterprise and Ultimate editions and then listing as many
> > as possible, not by actually listing features that are really actually
> > needed to make things work. I know the requirements came from
> > stakeholders and not from CPE, but the requirements are so far removed
> > from Fedora's actual needs that it has jeopardized the legitimacy of
> > the rest of the process. Fedora simply doesn't need any of it. To the
> > extent that CentOS or RHEL actually needs a non-OSS feature -- and I
> > don't think they *really* do, because those look like nice-to-haves --
> > then that just means that their needs are incompatible with Fedora's.
> > 
> > So let's fix the requirements first. Attempting to share requirements
> > with CentOS and RHEL has clearly failed.
> 
> The CPE team are at the intersection point of CentOS, Fedora and RHEL. We
> cannot escape that so any requirements gathered needs to respect that. We
> cannot sustain a service of feature for multiple individual stakeholders of
> this breadth. This was a driving factor in the exercise and decision.

But if the decision is ultimately to go with a hosted service, there's
no particular reason it needs to be the exact same hosted service for
all three stakeholders, is there? OK, dealing with multiple entirely
different forges could be a drag, but it has been suggested in the
thread that we could ask Gitlab for a hosted Gitlab CE. That doesn't
seem like it'd be difficult.
-- 
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 Fri, 2020-04-03 at 13:18 +0100, Leigh Griffin wrote:
> 
> > What I'm looking at is the commit logs. That's all that ultimately
> > matters. But see above revisions, of course.
> > 
> 
> I think that's a very narrow view of the world to base your assertions on
> commit logs only, I don't see the value in it. If your end argument here is
> that CPE do not spend enough time working on Fedora things then you are
> very mistaken. Almost 80% of our team capacity is on Fedora and our
> upcoming Q2 initiatives this is the same.

Just to make sure this is really clear, no, that's not my intent at
all. I was only following up on the question of whether the amount of
resources available for what was previously referred to as "Fedora
infra" (as opposed, for instance, to "Fedora release engineering") had
increased, decreased or stayed the same (with "stayed the same" seeming
to be the ultimate conclusion). By including or excluding anyone from
the lists I absolutely did not mean to imply anything about the value
of their contributions, or whether those contributions were to "Fedora"
in a larger sense - I was only trying to keep it a like-for-like
comparison. It's obvious from your and Clement's emails that this idea
got lost somewhere as we got into the weeds of commit logs and the
like, so I apologize for that, particularly as it turns out my initial
impression that the resources available had declined was incorrect. I
probably work closer with the releng folks than anyone and I certainly
value their work highly!

The initial suggestion I made that triggered this subthread was not
"perhaps CPE isn't spending enough time on Fedora" (I certainly don't
believe that or intend to suggest it) but "perhaps Red Hat is not
providing enough resources to CPE and other teams in order for Fedora
to be run the way the Fedora community believes it should be run". As I
said to Clement, I think the suggestion still bears consideration,
given that Clement says the workload has increased appreciably.

> > > Can you help me understand what the mystery is about? We took in 300+
> > > requirements that we distilled down into the generic list that we came
> > > up
> > > with, many of which are buckets / Epics. Every single requirement was
> > > analysed. I have said this multiple times but please, if this is still
> > > a
> > > mystery to you, let me know how I can help clarify it.
> > 
> > The specific gap I am talking about is the gap between this list
> > submitted by Ben Cotton on behalf of Fedora:
> > 
> > 
> > https://lists.fedoraproject.org/archives/list/council-disc...@lists.fedoraproject.org/thread/OEPDGVKYAJIQ6YYZU5J3XT3LHXFROFI5/
> 
> The thread you reference is not the list that was submitted. The first post
> on that is not the final list, the final list was a result of the debates
> and discussions that occurred on that thread and was submitted directly to
> CPE. To be clear, we did not pull our Fedora requirements from that list
> you are referencing.

Well, that's interesting. I got that link from earlier in this thread,
where Julen asked if that was the list you meant:

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

and you said "yes":

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

so, I'm only going on what you told us. If it is *not* in fact the
final list, where *is* that final list?

There is a substantial comment from Matt in which he downplays the
self-hosting requirement:

https://lists.fedoraproject.org/archives/list/council-disc...@lists.fedoraproject.org/message/E5R55AS3Z7QLGRXAT6RGQKJNVXLTAJHJ/

and kind of prevaricates a lot on the F/OSS requirement, first
saying that he wants to emphasize it and then kind of saying the
opposite for three paragraphs. So I can see where that might have
caused some confusion. But without seeing this "final list" that you're
now saying exists, it's hard to be sure.

> > 
> > and the 'summarized' list you have pointed to here:
> > 
> > https://hackmd.io/@My419-DISUGgo4gcmO1D6A/HJB74lcL8
> > 
> > Now, right off the bat, we have a huge problem. The "summarized" list
> > claims this:
> > 
> > "after duplications and similar in theme requirements were merged
> > together, we were left with the following unique User Story list:"
> > 
> > you've also phrased the same thing slightly differently on the mailing
> > list:
> > 
> > "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."
> > However, the top three points on the Fedora list relate to F/OSS and
> > self-hosting principles. These points are entirely missing from the
> > "summarized" list.
> 
> They were never formal requirements as submitted by Ben. I'm assuming you
> did not read Matthews reply
> 

Re: CPE Git Forge Decision

[Matthew Miller]

On Thu, Apr 02, 2020 at 11:49:43AM -0700, Adam Williamson wrote:
> > Marie is also working on reforming the web, design, and marketing teams
> > and building those up so we don't have to be directly dependent on Red
> > Hat in those areas (where, let's face it, Red Hat has historically
> > under-invested).
> And has that process been synchronized with this "git forge decision"
> process?

Not specifically, no.

-- 
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 Fri, Apr 3, 2020 at 8:15 am, Michael Catanzaro 
 wrote:
Much of the strongest criticism in this thread (and the ELN thread) 
is coming from Red Hat employees (often using personal email 
addresses).


Vit, I spent quite some time composing that mail, yet managed to send 
it *before* looking at your email address. Case in point, I suppose


___
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 Fri, Apr 3, 2020 at 11:11 am, Vít Ondruch  
wrote:
Once there appears somebody brilliant in community, sooner or later 
Red

Hat hires him. Unfortunately, this rarely means that the person keeps
their independence. This also means that later we are missing the 
"pure"

community.


Much of the strongest criticism in this thread (and the ELN thread) is 
coming from Red Hat employees (often using personal email addresses). 
Hi. Not many employers would allow airing criticism of a company 
decision in public, and yet here we are, writing essays about how badly 
this situation has been mismanaged.


Obviously we can't be *independent*, but we're not being gagged or 
anything. The alignment between community needs and company needs is 
(usually) very high. The forge decision is an anomaly, not the rule.


___
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 Fri, Apr 3, 2020 at 4:24 AM Julen Landa Alustiza
 wrote:
>
>
>
> 20/4/3 10:06(e)an, Michal Konecny igorleak idatzi zuen:
> >
> >
> > On 02/04/2020 23:51, Björn Persson wrote:
> >> Paul Frields wrote:
> >>> That statement rings hollow for me, when Github is arguably the single
> >>> biggest vendor of open source in the world, no part of itself is open
> >>> source, and thanks to its pervasiveness, open source has won the war
> >>> of how development should work.
> >> Github shows that *proprietary centralized services* are winning the war
> >> of how development should work. Gitlab is a smaller, competing,
> >> proprietary centralized service.
> >>
> >> This trend is not in any way unique to software development. Pretty much
> >> everything is being consolidated into centralized services governed by a
> >> small number of corporate behemoths. Every new thing is launched as a
> >> proprietary service that captures the market before anyone has a chance
> >> to develop a decentralized competitor. Even those decentralized networks
> >> that have existed since the Internet was young are now degenerating into
> >> centralized services. The smaller players will continue to be bought by
> >> bigger competitors until there are only one or two services in the world
> >> for doing whatever you want to do.
> > There is plenty of decentralized open source solutions for plenty of
> > services [0]. Unfortunately not for git forge.
> >
> > Michal
> >
> > [0] - https://fediverse.party/
>
> But there is an initiative to federate git forges, and they plan to
> implement it on gitlab. Oh sorry, I meant on pagure :)
>
> https://forgefed.peers.community/
>

I don't know if this was mentioned yet, but the Forgefed community is
getting funding to do paid work on Pagure[1] specifically because
Pagure has the framework to support decentralized, federated
development.

[1]: https://floss.social/@forgefed/103844664664981845



-- 
真実はいつも一つ！/ 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

[Michael Catanzaro]

On Thu, Apr 2, 2020 at 4:48 pm, Erich Eickmeyer 
 wrote:

It's very possible that the Fedora Council has
failed too for allowing this situation to happen.


I don't think this is entirely fair... Council hasn't had enough time 
to react to this yet. It seems they failed to adequately communicate 
their very strong preference for a FLOSS solution. But they haven't 
approved the CPE decision yet either. I suspect they're blindsided by 
this too.


___
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 Thu, Apr 2, 2020 at 7:48 PM Adam Williamson 
wrote:

> On Thu, 2020-04-02 at 11:52 +0100, Leigh Griffin wrote:
>
> [up front: apologies for any weird formatting in this email, Evolution
> is crashing on me like crazy while I try to edit it, so I'm sending it
> from Roundcube which I don't normally do]
>
> > I'm also not entirely sure about Adam Saleh, but he does not have any
> > > infra activity I can find since the end of January and lists himself as
> > > working for Exponea on Github and his personal blog.
> > >
> >
> > Adam is working in CPE. CPE isn't entirely about Infra, he is working
> > on CI
> > improvements at the moment alongside some others
>
> Okay, well, next time I see him I'll mention he might want to update the
> Exponea references :P
>
> I just pinged him on it :)

> But "CPE isn't entirely about Infra" is sort of the point here: my
> initial assertion was that there are fewer people working on
> *Fedora-relevant app development* than there were before.


Rightly or wrongly our span of control is:
- Infrastructure service and hardware keep alive
- Service maintenance / bug fixes etc

The above two are lights on work

- Service creation

Across 2 distros. The rough breakdowns are >50% of our resourcing just on
lights on work.


> I'm happy to
> accept that there may be more people in the CPE team than there were at
> some point in its past, but that's not what I'm actually interested in
> here. CI is great (whichever CI you mean, I lose track sometimes :>) but
> someone working on CI is not someone working on the Fedora app
> infrastructure, or on sourcing/deploying/integrating/maintaining
> outsourced replacements for it, which is the actual problem space here.
>

Anything we do benefits the infrastructure or the services that make it up,
the CI work here is improvements that take a lot of the manual work out for
us / the community and a lot of our initiatives are geared towards easing
that pressure on us while offering a value add.

>
> > > If I'm missing anyone, please do correct me.
> >
> > Other developers in our pool right now are:
> > - Ryan Lerch
>
> I mentioned already that Ryan could go in either list or neither - he
> was around at both times but I wasn't sure whether to count him as a
> developer or not. But he can't count to one list but not the other, as
> he's been here all along. :)
>
> > - Michal Konecny
> > - Mohan Boddu
> > - Tomas Hrcka
> > - Nils Philippsen
> > - Vipul Siddharth
> > - James Richardson
> >
> > We additionally have 2 new Ops folks joining us over the next 2 weeks.
> >
> > Across them, the majority are working on the Fedora aspects (Infra,
> > Dev,
> > Releng) of the CPE remit.
>
> So yeah, let's discount the releng folks first, because releng has
> existed all along


We can't really discount them when their workload extends beyond Tomas and
Mohan, that workload hits Smooge, Kevin, Clement and others. Their work is
now within the lights on category to help with the workload, look at
improving how they operate and ultimately trying to not leave them drown.
If they drown, we miss releases. This is a much bigger workload on the team
than folks realise.


> and - as I said - my original statement was not about
> "people who are organizationally in the same team as the people who work
> on Fedora app stuff" but "people who work on Fedora app stuff". So that
> lets out Mohan and Tomas.
>

Granted, but I wanted to clarify the above.

>
> As for the others: so, I didn't count Michal at first as I could not
> find any infra-related activity for him, but since you included him I
> looked closer, and found he's just hiding himself really well - his
> github account name, for some inaccountable reason, is "Zlopez", and his
> profile doesn't have his real name in it.


I really want to know the story behind that name, I must ask him!

> So I finally got his logs:
>
> https://github.com/Zlopez
> https://pagure.io/user/zlopez
>
> ...and yeah, there's some infra activity there, so add him to the list.
>
> Initially I was just looking at Github logs, as all the infra stuff I
> could find was hosted there, and Nils' list is:
>
> https://github.com/nphilipp
>
> which was busy up to the end of December but looked extremely empty all
> of this year, so I figured he'd switched track or role or something and
> didn't count him. But now I look closer, it seems what happened is he's
> been working almost exclusively on a thing called rpmautospec, which is
> hosted on Pagure:
>
> https://pagure.io/Fedora-Infra/rpmautospec
>
> so, he's clearly working hard on something, although I'm not sure it's
> directly a part of Fedora app/infra stuff - it's an automatic packaging
> thingy, it looks like, I'm not sure what it's being used for. In fact,
> it seems like pingou and Adam Saleh are doing quite a bit of work on
> this thing too, so it's clearly sucking up quite a lot of developer
> time. It's also a fairly new project, which seems interesting given that
> "we don't have time t

Re: CPE Git Forge Decision

[Martin Kolman]

- Original Message -
> From: "Michal Konecny" 
> To: devel@lists.fedoraproject.org
> Sent: Friday, April 3, 2020 10:06:26 AM
> Subject: Re: CPE Git Forge Decision
> 
> 
> 
> On 02/04/2020 23:51, Björn Persson wrote:
> 
> 
> 
> Paul Frields wrote:
> 
> 
> 
> That statement rings hollow for me, when Github is arguably the single
> biggest vendor of open source in the world, no part of itself is open
> source, and thanks to its pervasiveness, open source has won the war
> of how development should work.
> Github shows that *proprietary centralized services* are winning the war
> of how development should work. Gitlab is a smaller, competing,
> proprietary centralized service.
> 
> This trend is not in any way unique to software development. Pretty much
> everything is being consolidated into centralized services governed by a
> small number of corporate behemoths. Every new thing is launched as a
> proprietary service that captures the market before anyone has a chance
> to develop a decentralized competitor. Even those decentralized networks
> that have existed since the Internet was young are now degenerating into
> centralized services. The smaller players will continue to be bought by
> bigger competitors until there are only one or two services in the world
> for doing whatever you want to do.
> There is plenty of decentralized open source solutions for plenty of services
> [0]. Unfortunately not for git forge.
Actually, I would say Pagure by having all project metadata in git as well
(not just code but also issues, pull request review, etc.) it is the most
decentralised forge at the moment as in, you can just pick up your project
and put it to another Pagure instance without complicated data exporting
and importing, which is more complicated by other forges generally holding
project metadata in a centralized database.

> 
> Michal
> 
> [0] - https://fediverse.party/
> 
> 
> 
> I speak only for myself but it seems to me that concern over this
> ongoing centralization is why people are objecting to moving to Github
> or Gitlab.
> 
> Björn Persson
> 
> ___
> 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
> 
> --
> Role: Fedora CPE Team - Software Engineer
> IRC: mkonecny
> FAS: zlopez
> 
> ___
> 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 Thu, Apr 2, 2020 at 3:58 PM Michael Catanzaro 
wrote:

> On Wed, Apr 1, 2020 at 8:16 pm, Paul Frields 
> wrote:
> > For a solution to be viable it needs to meet requirements.
>
> Of course, but the problem is that the requirements identified by CPE
> are wildly inconsistent with the actual requirements of the Fedora
> community. The Pagure we have right now seems to be working fine for
> Fedora. All we really need is occasional light maintenance and ensuring
> the infrastructure keeps running. I don't think we'd be having this
> conversation now at all if "dist-git must be open source" was a listed
> requirement, as it should have been from the beginning.
>
> We don't need merge trains or MR approvals or mobile apps (seriously?)
> or private comments or gists or analytics or basically any of the other
> requirements that Neal has lampooned. I understand CentOS and RHEL
> really want merge trains, so maybe that one is a good faith
> requirement, but I honestly don't think most of the rest of them are.
> The list seems to have been concocted by looking at GitLab features
> exclusive to Enterprise and Ultimate editions and then listing as many
> as possible, not by actually listing features that are really actually
> needed to make things work. I know the requirements came from
> stakeholders and not from CPE, but the requirements are so far removed
> from Fedora's actual needs that it has jeopardized the legitimacy of
> the rest of the process. Fedora simply doesn't need any of it. To the
> extent that CentOS or RHEL actually needs a non-OSS feature -- and I
> don't think they *really* do, because those look like nice-to-haves --
> then that just means that their needs are incompatible with Fedora's.
>
> So let's fix the requirements first. Attempting to share requirements
> with CentOS and RHEL has clearly failed.


The CPE team are at the intersection point of CentOS, Fedora and RHEL. We
cannot escape that so any requirements gathered needs to respect that. We
cannot sustain a service of feature for multiple individual stakeholders of
this breadth. This was a driving factor in the exercise and decision.


> A corrected requirements list
> would start with OSS so that we don't consider non-OSS solutions as
> viable for Fedora; they are not. If CPE is dead set on hosted GitLab,
> then we should ask GitLab to set up a GitLab CE instance for us, and
> let them know that's the only product we're willing to pay for.
>
> 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
>


-- 

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

[Neal Gompa]

On Fri, Apr 3, 2020 at 5:29 AM Michal Konecny  wrote:
>
> On 03/04/2020 01:25, Jeremy Cline wrote:
> > On Thu, 2020-04-02 at 11:52 +0100, Leigh Griffin wrote:
> >> The number of active developers on Fedora initiatives has gone up
> >> drastically since I joined the team in 2019. You are possibly not
> >> seeing that as the team have moved from a model of siloed work on
> >> multiple apps, swimming against the tid working 16 hour days, to
> >> working on team oriented initiatives to add real value to the
> >> ecosystem. So the noise of working on multiple small things at once
> >> is not as loud as it was in 2018 which is giving that illusion.
> > I'd always suspected my work added no real value, but never had the
> > proof. I appreciate the validation .
> >
> > - Jeremy
> I bow before you mighty Jeremy and the work you did. The fedora
> messaging is really nice replacement of the fedmsg, although is not used
> by every application yet.
>
> I also want to thank you for handing me off the Anitya and
> the-new-hotness. It helped me grow my wizard realm in Fedora Universe. :-)

I would also like to echo my appreciation of Jeremy and his work. In
particular, anitya is one of the tools I literally rely on to keep
track of my packages and keep them fresh. Without anitya, I would be
unable to do so. And we've slowly started to see other distributions
starting to rely on it too (Arch, Alpine, PLD, Mageia, openSUSE).

So, thank you for building such an awesome tool, and thank you Michal
for taking up the reigns after that.


-- 
真実はいつも一つ！/ 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

[Michal Konecny]

On 03/04/2020 01:25, Jeremy Cline wrote:

On Thu, 2020-04-02 at 11:52 +0100, Leigh Griffin wrote:

The number of active developers on Fedora initiatives has gone up
drastically since I joined the team in 2019. You are possibly not
seeing that as the team have moved from a model of siloed work on
multiple apps, swimming against the tid working 16 hour days, to
working on team oriented initiatives to add real value to the
ecosystem. So the noise of working on multiple small things at once
is not as loud as it was in 2018 which is giving that illusion.

I'd always suspected my work added no real value, but never had the
proof. I appreciate the validation 🙂.

- Jeremy
I bow before you mighty Jeremy and the work you did. The fedora 
messaging is really nice replacement of the fedmsg, although is not used 
by every application yet.


I also want to thank you for handing me off the Anitya and 
the-new-hotness. It helped me grow my wizard realm in Fedora Universe. :-)


Michal
Wizard from release-monitoring.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


--
Role: Fedora CPE Team - Software Engineer
IRC: mkonecny
FAS: zlopez
___
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

[Vít Ondruch]

Dne 02. 04. 20 v 19:26 Matthew Miller napsal(a):
> On Wed, Apr 01, 2020 at 11:34:08AM -0700, Adam Williamson wrote:
>
>>> Yeah -- and this bigger picture is still the Fedora Project's overall
>>> goal. The change is in the mission of CPE vs. the previous Fedora
>>> Engineering team structure, not in what we want to do as a project.
>> If there's a gap there, though, have we systematically considered how
>> it should be filled? Including whether RH still wants to contribute to
>> filling it, outside of the CPE team's remit?
> Red Hat does. We're working with OSPO (formerly OSAS) to help bring in Red
> Hat contributions from the CTO's office. 
>
> Peeling back the corporate structure: the CPE team reports into the Linux
> platform engineering organization at Red Hat, the same one that makes RHEL.
> So it's natural for the goals of that group to be squeezed towards the
> practical matters of OS pipelines and engineering bits. The Office of the
> CTO, however, has a much wider remit, and a lot of this "actual functioning
> health of our community so that we have a reason to produce those bits"
> stuff does fit there. So Marie and I are actively working with OSPO to
> formalize this.
>
> Marie is also working on reforming the web, design, and marketing teams and
> building those up so we don't have to be directly dependent on Red Hat in
> those areas (where, let's face it, Red Hat has historically under-invested).
>

I see one more trend nobody is really talking about.

Once there appears somebody brilliant in community, sooner or later Red
Hat hires him. Unfortunately, this rarely means that the person keeps
their independence. This also means that later we are missing the "pure"
community. May be Fedora should sponsor some volunteers to do some work,
without Red Hat hiring them.

Also, for project such as Pagure, I don't think we benefit enough from
programs such as GSoC. I'm not saying that we don't do this and of
course such participants needs mentors etc ...


Vít

___
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

[Markus Larsson]

On 3 April 2020 10:23:58 CEST, Julen Landa Alustiza  
wrote:

>
>But there is an initiative to federate git forges, and they plan to
>implement it on gitlab. Oh sorry, I meant on pagure :)
>
>https://forgefed.peers.community/

Oh that is quite the opportunity right there. The CPE team could get an 
opportunity to do things right, Fedora gets to be at the forefront, it's rather 
nextlevel instead of being just another boring old gitforge workflow, those who 
wants to integrate can do so in a ordered fashion.

BR
M
___
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/4/3 10:06(e)an, Michal Konecny igorleak idatzi zuen:
> 
> 
> On 02/04/2020 23:51, Björn Persson wrote:
>> Paul Frields wrote:
>>> That statement rings hollow for me, when Github is arguably the single
>>> biggest vendor of open source in the world, no part of itself is open
>>> source, and thanks to its pervasiveness, open source has won the war
>>> of how development should work.
>> Github shows that *proprietary centralized services* are winning the war
>> of how development should work. Gitlab is a smaller, competing,
>> proprietary centralized service.
>>
>> This trend is not in any way unique to software development. Pretty much
>> everything is being consolidated into centralized services governed by a
>> small number of corporate behemoths. Every new thing is launched as a
>> proprietary service that captures the market before anyone has a chance
>> to develop a decentralized competitor. Even those decentralized networks
>> that have existed since the Internet was young are now degenerating into
>> centralized services. The smaller players will continue to be bought by
>> bigger competitors until there are only one or two services in the world
>> for doing whatever you want to do.
> There is plenty of decentralized open source solutions for plenty of
> services [0]. Unfortunately not for git forge.
> 
> Michal
> 
> [0] - https://fediverse.party/

But there is an initiative to federate git forges, and they plan to
implement it on gitlab. Oh sorry, I meant on pagure :)

https://forgefed.peers.community/

Pagure's decentralized PR workflow capabilities are great for this.
>> I speak only for myself but it seems to me that concern over this
>> ongoing centralization is why people are objecting to moving to Github
>> or Gitlab.
>>
>> Björn Persson
>>
>> ___
>> 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
> 
> -- 
> Role: Fedora CPE Team - Software Engineer
> IRC: mkonecny
> FAS: zlopez
> 
> 
> ___
> 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

[Michal Konecny]

On 02/04/2020 23:51, Björn Persson wrote:

Paul Frields wrote:

That statement rings hollow for me, when Github is arguably the single
biggest vendor of open source in the world, no part of itself is open
source, and thanks to its pervasiveness, open source has won the war
of how development should work.

Github shows that *proprietary centralized services* are winning the war
of how development should work. Gitlab is a smaller, competing,
proprietary centralized service.

This trend is not in any way unique to software development. Pretty much
everything is being consolidated into centralized services governed by a
small number of corporate behemoths. Every new thing is launched as a
proprietary service that captures the market before anyone has a chance
to develop a decentralized competitor. Even those decentralized networks
that have existed since the Internet was young are now degenerating into
centralized services. The smaller players will continue to be bought by
bigger competitors until there are only one or two services in the world
for doing whatever you want to do.
There is plenty of decentralized open source solutions for plenty of 
services [0]. Unfortunately not for git forge.


Michal

[0] - https://fediverse.party/


I speak only for myself but it seems to me that concern over this
ongoing centralization is why people are objecting to moving to Github
or Gitlab.

Björn Persson

___
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


--
Role: Fedora CPE Team - Software Engineer
IRC: mkonecny
FAS: zlopez

___
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 ven, 03/04/2020 alle 09.20 +0200, Miro Hrončok ha scritto:
> On 03. 04. 20 1:25, Jeremy Cline wrote:
> > On Thu, 2020-04-02 at 11:52 +0100, Leigh Griffin wrote:
> > > The number of active developers on Fedora initiatives has gone up
> > > drastically since I joined the team in 2019. You are possibly not
> > > seeing that as the team have moved from a model of siloed work on
> > > multiple apps, swimming against the tid working 16 hour days, to
> > > working on team oriented initiatives to add real value to the
> > > ecosystem. So the noise of working on multiple small things at
> > > once
> > > is not as loud as it was in 2018 which is giving that illusion.
> > 
> > I'd always suspected my work added no real value, but never had the
> > proof. I appreciate the validation 🙂.
> 
> Jeremy, rest assure that your work added real value.
> 
> I must concur with Erich in everything that they replied to this.

I would like to add that personally I like Pagure UX much more that
Gitlab.
If any help is needed to improve Pagure, I could add some of my little
fre time, it would be a reason to learn some more python programming.

Ciao
Guido Aulisi
FAS: tartina


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 Thu, 2 Apr 2020 at 22:33, Adam Williamson 
wrote:

> On Thu, 2020-04-02 at 21:58 +0200, Clement Verna wrote:
>
> [evolution is still crashing. sigh. such is life. apologies for
> formatting, again]
>
> > > So yeah, let's discount the releng folks first, because releng has
> > > existed all along, and - as I said - my original statement was not
> about
> > > "people who are organizationally in the same team as the people who
> work
> > > on Fedora app stuff" but "people who work on Fedora app stuff". So
> that
> > > lets out Mohan and Tomas.
> > >
> >
> > I don't think this is fair at all, Tomas and Mohan are doing a lot of
> > development and trying to improve a lot of the tooling around releng
> so
> > that we move from a manual heavy process to a more automated or at
> least
> > tool assisted process. If you consider that releng tooling is not
> > application work, then please explain to me what is bodhi,
> > release-monitoring, anitya, mdapi etc ... It seems to me that these
> > services are 100% release engineering focused.
>
> I think we've more or less beaten this list thing to death and maybe we
> don't actually disagree at all (can we say it actually turns out to be
> more or less a wash and move on? I am at this point willing to concede
> that my impression that the headcount was *higher* before was
> mistaken), but I didn't mean "discount them" in the sense of "discount
> their contributions", I meant "discount them from the comparison",
> because I didn't include the people working in releng two years ago in
> the "before" list. We could add the current releng people to the "now"
> list and the previous releng people to the "before" list, but what
> would be the point, beyond beating this dead horse even harder? :)
>
> > Here's Vipul's lists:
> > > https://github.com/siddharthvipul
> > > https://pagure.io/user/siddharthvipul1
> > >
> > > he seems to work exclusively on CentOS CI. Okay, Fedora *uses*
> CentOS
> > > CI, but presumably back in the 2018 timeframe, someone (whether
> that's
> > > Vipul or someone else) was working on CentOS CI who wasn't included
> in
> > > my list, because I only listed people working on Fedora stuff. So
> this
> > > still seems like a wash.
> > >
> >
> > Vipul and I have done extensive work to add the OSBS aarch64 cluster
> in
> > staging, and it might comes as a surprise but yes we are working as a
> team
> > and even sometimes pair programing and sharing knowledge. But you
> will find
> > some of Vipul's contribution on the ansible repo git logs. Also this
> work
> > is directly coming as a request from the council to support the IOT
> > objective, so I think it is fair to count it as "development" work
> even if
> > this was mostly operation work and deploying a new OpenShift cluster
> for
> > OSBS, since this time could have been spend on other application if
> that
> > was asked by the council.
>
> Same point: I wasn't meaning to dismiss anyone's contributions, only to
> try and keep the *comparison* valid, so it's not valid to include
> "people working on CentOS CI" in the 'now' list (as they're now
> accounted as part of 'CPE') but not include people who were working on
> CentOS CI in the "then" list (because they weren't part of 'Fedora
> infra'). But please let's just leave this point now? :)
>
> > Yeah we are even, and we have 2 new persons joining the team next
> week with
> > a more sysadmin/operation profile because we really need to support
> nirik
> > and smooge in that area. I think what you are failing to see is that
> for
> > roughly the same team, there is much more thing to do. The project
> keeps
> > adding new things, we now have containers, flatpaks, IoT, silverblue,
> > CoreOS and this is good thing but it adds more work on the team for
> example
> > the releng work that was needed 5 years ago has now triple, same
> thing on
> > the infra side. On the application development, tools and application
> have
> > to be adapted to take care of these new deliverables. I am pretty
> sure you
> > know this very well because that must impact you also on the QA side.
>
> Yeah, you're right, so I'm certainly not "failing to see" that. But I
> think we may have lost track of where this discussion got started. Let
> me quote myself from right back at the start:
>
> "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."
>
> *that's* where this whole "headcount" subthread kicked off. As I
> mentioned above, I'm now willing to admit that my impression that th

Re: CPE Git Forge Decision

[Miro Hrončok]

On 03. 04. 20 1:25, Jeremy Cline wrote:

On Thu, 2020-04-02 at 11:52 +0100, Leigh Griffin wrote:


The number of active developers on Fedora initiatives has gone up
drastically since I joined the team in 2019. You are possibly not
seeing that as the team have moved from a model of siloed work on
multiple apps, swimming against the tid working 16 hour days, to
working on team oriented initiatives to add real value to the
ecosystem. So the noise of working on multiple small things at once
is not as loud as it was in 2018 which is giving that illusion.


I'd always suspected my work added no real value, but never had the
proof. I appreciate the validation 🙂.


Jeremy, rest assure that your work added real value.

I must concur with Erich in everything that they replied to this.

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

[Charalampos Stratakis]

- Original Message -
> From: "Erich Eickmeyer" 
> To: devel@lists.fedoraproject.org
> Sent: Friday, April 3, 2020 2:02:23 AM
> Subject: Re: CPE Git Forge Decision
> 
> On Thursday, April 2, 2020 4:56:33 PM PDT Adam Williamson wrote:
> > Correction here: the decision process *was* actually initiated quite
> > publicly. It was announced in January, in a thread titled "Git Forge
> > Requirements: Please see the Community Blog", which (as you'd guess)
> > linked to a Community Blog post announcing that a decision was to be
> > made under the Open Decision Framework:
> > 
> > https://communityblog.fedoraproject.org/git-forge-requirements/
> 
> Ok, I stand corrected then. :)
> 
> > thus far, I'd say that was an example of good process, on the face of
> > it.
> 
> Yes, on the face, and with good intentions nonetheless. :)
> 
> > It can be argued that things went wrong later.
> 
> I agree 100% with that. Either way, Jeremy should not have been made to feel
> the way he is feeling, and I would guess that applies to many people in this
> thread. My point still stands that there was a failure at the leadership
> level.
> 

I concur with that. The way this was handled later in the process is a great 
example on how to not do things and how the decision is being communicated is 
an utter mess.

I don't have a strong preference in respect to Gitlab or Pagure, however the 
memories are still fresh of when we had to move from pkgdb to pagure because 
modularity needed it, and now after such a long time that we have a feature 
parity, compared to our previous workflows, we will have that changed again. 
But the negative feelings and memories of the previous change do not go away 
that easily and proposing such a change could very well bring up strong 
emotions. Adding to it the way this was handled afterwards, included being at 
odds with the Fedora's project statements only adds fuel to the fire.

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

-- 
Regards,

Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat
___
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

[Erich Eickmeyer]

On Thursday, April 2, 2020 4:56:33 PM PDT Adam Williamson wrote:
> Correction here: the decision process *was* actually initiated quite
> publicly. It was announced in January, in a thread titled "Git Forge
> Requirements: Please see the Community Blog", which (as you'd guess)
> linked to a Community Blog post announcing that a decision was to be
> made under the Open Decision Framework:
> 
> https://communityblog.fedoraproject.org/git-forge-requirements/

Ok, I stand corrected then. :)

> thus far, I'd say that was an example of good process, on the face of
> it.

Yes, on the face, and with good intentions nonetheless. :)

> It can be argued that things went wrong later. 

I agree 100% with that. Either way, Jeremy should not have been made to feel 
the way he is feeling, and I would guess that applies to many people in this 
thread. My point still stands that there was a failure at the leadership 
level.

Erich

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

[Adam Williamson]

On Thu, 2020-04-02 at 16:48 -0700, Erich Eickmeyer wrote:
> 
> The root of this leadership failure seems to be that the discussion happened 
> mostly behind closed doors without any announcement *to this list* that this 
> was being discussed. Transparency is *key* in leadership.

Correction here: the decision process *was* actually initiated quite
publicly. It was announced in January, in a thread titled "Git Forge
Requirements: Please see the Community Blog", which (as you'd guess)
linked to a Community Blog post announcing that a decision was to be
made under the Open Decision Framework:

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

thus far, I'd say that was an example of good process, on the face of
it. It can be argued that things went wrong later. Earlier posts in
this thread have more details on 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