CPE Git Forge Decision

[Leigh Griffin]

Hi everyone,

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

Kind regards,
Leigh, on behalf of the CPE Team

-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford <https://www.redhat.com/>

Communications House

Cork Road, Waterford City

lgriffin(a)redhat.com
M: [phone]     IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>

[Guido Aulisi]

Il giorno lun 30 mar 2020 alle 11:21 Leigh Griffin <lgriffin(a)redhat.com&gt; ha
scritto:

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

Kind regards,
>  Leigh, on behalf of the CPE Team
>
>  --
>
>  Leigh Griffin
>
>  Engineering Manager
>
>  Red Hat Waterford <https://www.redhat.com/>
>
>  Communications House
>
>  Cork Road, Waterford City
>
>  lgriffin(a)redhat.com
>  M: [phone]     IM: lgriffin
>  @redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
>  <https://www.facebook.com/redhatjobs> @redhatjobs
>  <https://instagram.com/redhatjobs>
>  <https://red.ht/sig>
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>

[Iñaki Ucar]

Hi Leigh,

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

Thanks,
Iñaki

[Leigh Griffin]

On Mon, Mar 30, 2020 at 10:55 AM Iñaki Ucar <iucar(a)fedoraproject.org&gt; wrote:

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

For transparency, we have published the full User Story list which is
linked within the blog and for ease of searching is here:
https://hackmd.io/@My419-DISUGgo4gcmO1D6A/HJB74lcL8

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

>  Thanks,
>  Iñaki
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  

-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford <https://www.redhat.com/>

Communications House

Cork Road, Waterford City

lgriffin(a)redhat.com
M: [phone]     IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>

[Daniel P. Berrangé]

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


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

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

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

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

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

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

And 

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

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

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

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

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

[Iñaki Ucar]

On Mon, 30 Mar 2020 at 12:15, Leigh Griffin <lgriffin(a)redhat.com&gt; wrote:
>  On Mon, Mar 30, 2020 at 10:55 AM Iñaki Ucar <iucar(a)fedoraproject.org&gt; wrote:
> >
> > Hi Leigh,
> >
> > On Mon, 30 Mar 2020 at 11:30, Leigh Griffin <lgriffin(a)redhat.com&gt; wrote:
> > >
> > > Hi everyone,
> > >
> > > Thank you for your patience while the CPE Team worked through an incredible
> number of requirements from multiple stakeholder sources. On Friday evening we announced
> on the Community Blog our decision to adopt Gitlab as our Git Forge and to retain
> pagure.io to ultimately hand over to the Community to maintain. It wasn't an easy
> decision by any stretch of the imagination and we hope that the compromise that we are
> striking will help to allow Pagure flourish and to give a choice of Forges for your usage.
> I'm happy to field any questions or comments about this decision.
> >
> > My question is, where's the open conversation about the requirements
> > gathered that you promised in the initial thread?
>
>
>  Hey Iñaki, we have had several rounds of open conversation facilitated via the Council
> threads on it to arrive on what the requirements were for the Fedora Project. This
> ultimately concluded with the formal requirements received from the Fedora Council which
> were shaped by the Community.
>
>  For transparency, we have published the full User Story list which is linked within the
> blog and for ease of searching is here:
> https://hackmd.io/@My419-DISUGgo4gcmO1D6A/HJB74lcL8
>
>  This thread is also part of the open conversation on the decision. 
I was referring to, and I was expecting, an open conversation about
the User Story list, an open analysis of the requirements list. In
other words:

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

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

Iñaki

[Julen Landa Alustiza]

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

Sincelery, after reading the initial announcement, I was expecting a
more visible and open to the community discussion scenario.
>  
>  For transparency, we have published the full User Story list which is
>  linked within the blog and for ease of searching is
>  here: https://hackmd.io/@My419-DISUGgo4gcmO1D6A/HJB74lcL8
>  
>  This thread is also part of the open conversation on the decision. 
No, this is a post decision conversation, not the promised open and live
discussions *during* the process.

>  
>  
>      Thanks,
>      Iñaki
>      _______________________________________________
>      devel mailing list -- devel(a)lists.fedoraproject.org
>      <mailto:[e-mail]>
>      To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>      <mailto:[e-mail]>
>      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/[e-mail]
>  
>  
>  
>  -- 
>  
>  Leigh Griffin
>  
>  Engineering Manager
>  
>  Red Hat Waterford <https://www.redhat.com/>
>  
>  Communications House
>  
>  Cork Road, Waterford City
>  
>  lgriffin(a)redhat.com <mailto:[e-mail]>    
>  M: [phone] <tel:[phone]>     IM: lgriffin
>  
>  @redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
>  <https://www.facebook.com/redhatjobs> @redhatjobs
>  <https://instagram.com/redhatjobs>  
>  <https://red.ht/sig>
>  
>  
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>   
-- 
Julen Landa Alustiza <jlanda(a)fedoraproject.org&gt;

[Miro Hrončok]

On 30. 03. 20 11:17, Leigh Griffin wrote:
>  Hi everyone,
>  
>  Thank you for your patience while the CPE Team worked through an incredible 
>  number of requirements from multiple stakeholder sources. On Friday evening we 
>  announced on the Community Blog 
>  <https://communityblog.fedoraproject.org/making-a-git-forge-decision/> our 
>  decision to adopt Gitlab as our Git Forge and to retain pagure.io 
>  <http://pagure.io/> to ultimately hand over to the Community to maintain. It 
>  wasn't an easy decision by any stretch of the imagination and we hope that the 
>  compromise that we are striking will help to allow Pagure flourish and to give a 
>  choice of Forges for your usage. I'm happy to field any questions or comments 
>  about this decision. 
>  We are opting for GitLab for our dist git and project hosting and
> will continue
>  to run pagure.io with community assistance.
>  If no one steps up to pick the maintenance of pagure.io, it will be a candidate >
> application to sunset. 

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

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

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Leigh Griffin]

On Mon, Mar 30, 2020 at 11:19 AM Daniel P. Berrangé <berrange(a)redhat.com&gt;
wrote:

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

>   "Keep Pagure running with our oversight while we analyse a
> sunset
>    timeline which will give a minimum of 12 months notice once we
>    have a plan firmed up. We will fix blocker bugs, address critical
>    vulnerabilities and keep the lights on in the same manner that we
>    have committed to over the last 14 months where Pagure has not
>    been a staffed and supported initiative."
>  
The word "sunset" here tells me that pagure.io is going away and
we'll need
>  to move projects off it. Similarly the last sentence reinforces that
> Pagure
>  is considered abandonware.
>  
We will continue with Pagure as a dist-git AND as a project hosting service
for a minimum of 12 months once we have a timeline established. That could
see the status quo remain for several months on top of that 12 month clock.


>  At the same time the blog says "we do not want to abandon Pagure" and
>
>     "provide them with guidance and oversight to help the Pagure
>      Community grow. We recognise that this is a growing and
>      unique ecosystem and we genuinely want to see it succeed and
>      will do our best to support it in that capacity"
>
>  which says that pagure.io is intended to carry on living and even grow.
>  
We will continue to host pagure.io for the foreseeable future but like all
apps that we currently host or maintain, we will evaluate the difficulty in
maintenance and strive for more community involvement in their upkeep as
CPE cannot own and maintain every single Fedora application.


>  And
>
>    "Offer the maintenance of pagure.io to anyone in the community
>     interested in leading it."
>
>  which says we want to abandon it, but perhaps some kind person might step
>  in to rescue it, but we've no idea who that will be aside from some
>  community
>  group yet to be clearly identified.
>  
Put simply, CPE will not be driving the long term maintenance and growth of
Pagure. We want the community to drive this and lead the way and give it
the time and attention that we cannot. We will provide power and ping and
try our best to keep it on the air but we would hope to have assistance
with the latter as time goes on and if we get to a point where we can even
hand the power and ping aspects over, then we will certainly do that to
ensure Pagure has a future that is in the community's own hands.


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

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

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

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


>  and projects should focus on the
>  primary gitlab.com instance if they need hosting that has got a chance of
>  still existing in 3-5 years time.
>
>  Regards,
>  Daniel
>  --
>  |: https://berrange.com      -o-
>  https://www.flickr.com/photos/dberrange :|
>  |: https://libvirt.org         -o-
>  https://fstop138.berrange.com :|
>  |: https://entangle-photo.org    -o-
>  https://www.instagram.com/dberrange :|
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  

-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford <https://www.redhat.com/>

Communications House

Cork Road, Waterford City

lgriffin(a)redhat.com
M: [phone]     IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>

[Leigh Griffin]

On Mon, Mar 30, 2020 at 11:31 AM Julen Landa Alustiza <
jlanda(a)fedoraproject.org&gt; wrote:

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

>  Sincelery, after reading the initial announcement, I was expecting a
>  more visible and open to the community discussion scenario.
>  >
>  > For transparency, we have published the full User Story list which is
>  > linked within the blog and for ease of searching is
>  > here: https://hackmd.io/@My419-DISUGgo4gcmO1D6A/HJB74lcL8
>  >
>  > This thread is also part of the open conversation on the decision.
>
>  No, this is a post decision conversation, not the promised open and live
>  discussions *during* the process.
>  
We haven't ironed out the full details but what was incredibly clear to us
was that Gitlab was the decision to make. The next step in getting there is
what we are engaging in now to get thoughts and suggestions and expect
several threads in that capacity from a technical perspective in the coming
weeks and months.

>  >
>  >
>  >     Thanks,
>  >     Iñaki
>  >     _______________________________________________
>  >     devel mailing list -- devel(a)lists.fedoraproject.org
>  >     <mailto:[e-mail]>
>  >     To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  >     <mailto:[e-mail]>
>  >     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/[e-mail]
>  >
>  >
>  >
>  > --
>  >
>  > Leigh Griffin
>  >
>  > Engineering Manager
>  >
>  > Red Hat Waterford <https://www.redhat.com/>
>  >
>  > Communications House
>  >
>  > Cork Road, Waterford City
>  >
>  > lgriffin(a)redhat.com <mailto:[e-mail]>
>  > M: [phone] <tel:[phone]>     IM: lgriffin
>  >
>  > @redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
>  > <https://www.facebook.com/redhatjobs> @redhatjobs
>  > <https://instagram.com/redhatjobs>
>  > <https://red.ht/sig>
>  >
>  >
>  > _______________________________________________
>  > devel mailing list -- devel(a)lists.fedoraproject.org
>  > To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  >
>
>  --
>  Julen Landa Alustiza <jlanda(a)fedoraproject.org&gt;
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  

-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford <https://www.redhat.com/>

Communications House

Cork Road, Waterford City

lgriffin(a)redhat.com
M: [phone]     IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>

[Neal Gompa]

On Mon, Mar 30, 2020 at 7:56 AM Leigh Griffin <lgriffin(a)redhat.com&gt; wrote:
>  On Mon, Mar 30, 2020 at 11:31 AM Julen Landa Alustiza <jlanda(a)fedoraproject.org&gt;
> wrote:
> >
> > Sincelery, after reading the initial announcement, I was expecting a
> > more visible and open to the community discussion scenario.
> > >
> > > For transparency, we have published the full User Story list which is
> > > linked within the blog and for ease of searching is
> > > here: https://hackmd.io/@My419-DISUGgo4gcmO1D6A/HJB74lcL8
> > >
> > > This thread is also part of the open conversation on the decision.
> >
> > No, this is a post decision conversation, not the promised open and live
> > discussions *during* the process.
>
>
>  We haven't ironed out the full details but what was incredibly clear to us was that
> Gitlab was the decision to make. The next step in getting there is what we are engaging in
> now to get thoughts and suggestions and expect several threads in that capacity from a
> technical perspective in the coming weeks and months. 
But that's the problem. It *wasn't* clear to all of us in Fedora and
CentOS communities. This is why I'm upset about this more than
anything else. This is a post-decision conversation that didn't follow
the "open decision-making process" that you had described earlier.

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

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



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Miro Hrončok]

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

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

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

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Neal Gompa]

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

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



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Till Maas]

Hi,

On Mon, Mar 30, 2020 at 11:04:03AM +0100, Leigh Griffin wrote:

>  For transparency, we have published the full User Story list which
> is
>  linked within the blog and for ease of searching is here:
>  https://hackmd.io/@My419-DISUGgo4gcmO1D6A/HJB74lcL8 
the user stories list does not seem to include the original user stories
that I submitted regarding package life-cycle and permission management.
These are requirements for dist-git but not necessarily for a git-forge.
In the past they were fulfilled by package db, now pagure is solving
this more. What is the plan for this in the future? Will there be a
different solution instead of a git forge for this?

Thank you
Till

[Leigh Griffin]

On Mon, Mar 30, 2020 at 1:15 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:

>  On Mon, Mar 30, 2020 at 7:56 AM Leigh Griffin
> <lgriffin(a)redhat.com&gt; wrote:
>  >
>  > On Mon, Mar 30, 2020 at 11:31 AM Julen Landa Alustiza <
>  jlanda(a)fedoraproject.org&gt; wrote:
>  >>
>  >> Sincelery, after reading the initial announcement, I was expecting a
>  >> more visible and open to the community discussion scenario.
>  >> >
>  >> > For transparency, we have published the full User Story list which is
>  >> > linked within the blog and for ease of searching is
>  >> > here: https://hackmd.io/@My419-DISUGgo4gcmO1D6A/HJB74lcL8
>  >> >
>  >> > This thread is also part of the open conversation on the decision.
>  >>
>  >> No, this is a post decision conversation, not the promised open and live
>  >> discussions *during* the process.
>  >
>  >
>  > We haven't ironed out the full details but what was incredibly clear to
>  us was that Gitlab was the decision to make. The next step in getting there
>  is what we are engaging in now to get thoughts and suggestions and expect
>  several threads in that capacity from a technical perspective in the coming
>  weeks and months.
>
>  But that's the problem. It *wasn't* clear to all of us in Fedora and
>  CentOS communities. This is why I'm upset about this more than
>  anything else. This is a post-decision conversation that didn't follow
>  the "open decision-making process" that you had described earlier.
>  
We followed the process as laid out, we had open discussions of the problem
and concluded the ideation phase with a set of requirements delivered by
Ben Cotton on behalf of the Fedora Community. We are now engaging openly on
what the challenges and next steps are.

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

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


>  I would have been
>  happier if you had said: "at this current time, GitLab makes sense for
>  us. We will engage with GitLab to figure out some more details, but
>  here are the things we considered critical gaps. Since we're not
>  making this move this year anyway, if these gaps can be closed by the
>  end of the year, we will consider staying on Pagure instead of going
>  forward with a plan of a GitLab migration."
>  
That sounds reasonable when taken in a vacuum. We have needs to service as
a team and delaying a decision by a year or more to possibly solve some of
the technical problem isn't going to change the operational overhead that
some of the requirements is mandating. They were requirements we didn't
quiet fully grasp until we carried out the exercise. It is our intention to
have something stood up on Gitlab in the coming weeks and made available
for consumption by our Communities and team ASAP.


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

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


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

>  --
>  真実はいつも一つ！/ Always, there's only one truth!
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  

-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford <https://www.redhat.com/>

Communications House

Cork Road, Waterford City

lgriffin(a)redhat.com
M: [phone]     IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>

[Leigh Griffin]

On Mon, Mar 30, 2020 at 2:01 PM Miro Hrončok <mhroncok(a)redhat.com&gt; wrote:

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

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


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

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


>  What measures will be taken to prevent yet another "open a
> releng
>  ticket and a human will do this while we automate stuff" era?
>
>  --
>  Miro Hrončok
>  --
>  Phone: [phone]
>  IRC: mhroncok
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  

-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford <https://www.redhat.com/>

Communications House

Cork Road, Waterford City

lgriffin(a)redhat.com
M: [phone]     IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>

[Leigh Griffin]

On Mon, Mar 30, 2020 at 2:18 PM Till Maas <opensource(a)till.name&gt; wrote:

>  Hi,
>
>  On Mon, Mar 30, 2020 at 11:04:03AM +0100, Leigh Griffin wrote:
>
>  > For transparency, we have published the full User Story list which is
>  > linked within the blog and for ease of searching is here:
>  > https://hackmd.io/@My419-DISUGgo4gcmO1D6A/HJB74lcL8
>
>  the user stories list does not seem to include the original user stories
>  that I submitted regarding package life-cycle and permission management.
>  These are requirements for dist-git but not necessarily for a git-forge.
>  In the past they were fulfilled by package db, now pagure is solving
>  this more. 

We received a summarised User Story list from the Fedora Council, I would
suggest reaching out with your concerns.


>  What is the plan for this in the future? Will there be a
>  different solution instead of a git forge for this? 

>  Thank you
>  Till
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  

-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford <https://www.redhat.com/>

Communications House

Cork Road, Waterford City

lgriffin(a)redhat.com
M: [phone]     IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>

[Fabio Valentini]

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

(snip)

>  I don't have an answer to this as we haven't done that deep level of tooling
> analysis and integration analysis yet. 
So you're basically saying that you've decided for GitLab (despite the
fedora community obviously preferring pagure - whether you received
that message or not), and you have not even looked at what that will
mean? And if it turns out that GitLab can't deliver some features you
want, and not satisfy some "stakeholder user stories"?

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

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

Fabio

>
>>
>> Will CPE implement this before we
>> switch, or will GitLab be dumped on us and we will do toothless FESCo approved
>> statements, such as "Missing Pagure features should be re-implemented in
>> GitLab"?
>
>
> CPE will take on a lot of the tooling work to ease the migration.
>
>>
>> What measures will be taken to prevent yet another "open a releng
>> ticket and a human will do this while we automate stuff" era?
>>
>> --
>> Miro Hrončok
>> --
>> Phone: [phone]
>> IRC: mhroncok
>> _______________________________________________
>> devel mailing list -- devel(a)lists.fedoraproject.org
>> To unsubscribe send an email to devel-leave(a)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/[e-mail]
>
>
>
> --
>
> Leigh Griffin
>
> Engineering Manager
>
> Red Hat Waterford
>
> Communications House
>
> Cork Road, Waterford City
>
> lgriffin(a)redhat.com
> M: [phone]     IM: lgriffin
>
> @redhatjobs   redhatjobs @redhatjobs
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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/[e-mail]

[Till Maas]

Hi,

On Mon, Mar 30, 2020 at 01:59:07PM +0000, Leigh Griffin wrote:
>  On Mon, Mar 30, 2020 at 2:18 PM Till Maas
> <opensource(a)till.name&gt; wrote:
>  
>  > Hi,
>  >
>  > On Mon, Mar 30, 2020 at 11:04:03AM +0100, Leigh Griffin wrote:
>  >
>  > > For transparency, we have published the full User Story list which is
>  > > linked within the blog and for ease of searching is here:
>  > > https://hackmd.io/@My419-DISUGgo4gcmO1D6A/HJB74lcL8
>  >
>  > the user stories list does not seem to include the original user stories
>  > that I submitted regarding package life-cycle and permission management.
>  > These are requirements for dist-git but not necessarily for a git-forge.
>  > In the past they were fulfilled by package db, now pagure is solving
>  > this more.
>  
>  
>  We received a summarised User Story list from the Fedora Council, I would
>  suggest reaching out with your concerns. 
What is the list that you got. The list on the council discuss list
contained these items, for example for FESCo members, proven packagers
and dist-git repo admins:
https://lists.fedoraproject.org/archives/list/[e-mail]...

In the hackmd story list, there are is only infosec, RH Legal Rep, RH
Infocsec Rep, RH Developer, RHEL engineer and general users, project
contributor, CPE team member. Nothing really maps to the user groups I
mentioned. There is only

| 41
| As a General User
| I want groups and group membership and management
| to allow me create access control on a suite of repositories

but this is very vague.

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

Thank you,
Till

[Leigh Griffin]

On Mon, Mar 30, 2020 at 3:07 PM Fabio Valentini <decathorpe(a)gmail.com&gt;
wrote:

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

It was not a formal requirement.

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

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


>  And if it turns out that GitLab can't deliver some features you
>  want, and not satisfy some "stakeholder user stories"?
>  
Not all requirements can be satisfied in totality, we knew this before we
began and Gitlab satisfies the majority of the requirements needed.

>  Am I crazy, or shouldn't have those problems have been taken into
>  account *before* such a big decision is made?
>  Your responses sound like "we made our decisions, and now we'll stick
>  to them no matter what happens".
>  
Like any technology decision that we as a team choose, we can revert our
decision if the service is not working as intended and not satisfying our
needs. Right now, we are proceeding with Gitlab as our choice.

And honestly, I shouldn't have expected anything else from this "kill
>  pagure project".
>  
Pagure was a viable choice and several hundred person hours went into
informing us of this decision because of how critical it was to get right.


>  The way the fedora community - and the pagure project - are and were
>  treated here is shameful, and you're going to lose fedora contributors
>  because of it.
>
>  Fabio
>
>  >
>  >>
>  >> Will CPE implement this before we
>  >> switch, or will GitLab be dumped on us and we will do toothless FESCo
>  approved
>  >> statements, such as "Missing Pagure features should be re-implemented in
>  >> GitLab"?
>  >
>  >
>  > CPE will take on a lot of the tooling work to ease the migration.
>  >
>  >>
>  >> What measures will be taken to prevent yet another "open a releng
>  >> ticket and a human will do this while we automate stuff" era?
>  >>
>  >> --
>  >> Miro Hrončok
>  >> --
>  >> Phone: [phone]
>  >> IRC: mhroncok
>  >> _______________________________________________
>  >> devel mailing list -- devel(a)lists.fedoraproject.org
>  >> To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  >
>  >
>  >
>  > --
>  >
>  > Leigh Griffin
>  >
>  > Engineering Manager
>  >
>  > Red Hat Waterford
>  >
>  > Communications House
>  >
>  > Cork Road, Waterford City
>  >
>  > lgriffin(a)redhat.com
>  > M: [phone]     IM: lgriffin
>  >
>  > @redhatjobs   redhatjobs @redhatjobs
>  > _______________________________________________
>  > devel mailing list -- devel(a)lists.fedoraproject.org
>  > To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  

-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford <https://www.redhat.com/>

Communications House

Cork Road, Waterford City

lgriffin(a)redhat.com
M: [phone]     IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>

[Matthias Runge]

On 30/03/2020 16:23, Till Maas wrote:

> >>> For transparency, we have published the full User Story
> list which is
> >>> linked within the blog and for ease of searching is here:
> >>> https://hackmd.io/@My419-DISUGgo4gcmO1D6A/HJB74lcL8 
> https://lists.fedoraproject.org/archives/list/[e-mail]...
>  
>  In the hackmd story list, there are is only infosec, RH Legal Rep, RH
>  Infocsec Rep, RH Developer, RHEL engineer and general users, project
>  contributor, CPE team member. Nothing really maps to the user groups I
>  mentioned. There is only
>  
>  | 41
>  | As a General User
>  | I want groups and group membership and management
>  | to allow me create access control on a suite of repositories
>  
>  but this is very vague. 

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


Matthias

[Leigh Griffin]

On Mon, Mar 30, 2020 at 3:26 PM Till Maas <opensource(a)till.name&gt; wrote:

>  Hi,
>
>  On Mon, Mar 30, 2020 at 01:59:07PM +0000, Leigh Griffin wrote:
>  > On Mon, Mar 30, 2020 at 2:18 PM Till Maas <opensource(a)till.name&gt; wrote:
>  >
>  > > Hi,
>  > >
>  > > On Mon, Mar 30, 2020 at 11:04:03AM +0100, Leigh Griffin wrote:
>  > >
>  > > > For transparency, we have published the full User Story list which is
>  > > > linked within the blog and for ease of searching is here:
>  > > > https://hackmd.io/@My419-DISUGgo4gcmO1D6A/HJB74lcL8
>  > >
>  > > the user stories list does not seem to include the original user
>  stories
>  > > that I submitted regarding package life-cycle and permission
>  management.
>  > > These are requirements for dist-git but not necessarily for a
>  git-forge.
>  > > In the past they were fulfilled by package db, now pagure is solving
>  > > this more.
>  >
>  >
>  > We received a summarised User Story list from the Fedora Council, I would
>  > suggest reaching out with your concerns.
>
>  What is the list that you got. The list on the council discuss list
>  contained these items, for example for FESCo members, proven packagers
>  and dist-git repo admins:
>
>
> https://lists.fedoraproject.org/archives/list/[e-mail]...

We received a Google Doc with the summation of the 44 requirements from
Fedora Council.


>  In the hackmd story list, there are is only infosec, RH Legal Rep, RH
>  Infocsec Rep, RH Developer, RHEL engineer and general users, project
>  contributor, CPE team member. Nothing really maps to the user groups I
>  mentioned. 

As mentioned, we rolled in stories together and General Users /
contributors map to the majority of the Fedora projects requirements
(similar for CentOS) and a lot of individual stakeholder requirements ended
up in the general bucket.


>  There is only
>
>  | 41
>  | As a General User
>  | I want groups and group membership and management
>  | to allow me create access control on a suite of repositories
>
>  but this is very vague.
>  
The User Stories are deliberately vague and that represents around 10
unique requirements that boil down to having group membership and
management capabilities.

>  Also there seems to be nothing about orphaning/adopting/retiring
>  packages, not even in a vague way.
>  
We have stories relating to specific workflow requirements (from multiple
stakeholders including RHEL, CentOS and Fedora) for dist-git. We have
represented a requirement (number 18 on the list) about viewing orphaned
packages. The requirements received around this process were very much
aligned with permissions and visibility to allow actions. They are covered
through other User Stories and what I feel needs to be made clear, we are
presenting the amalgamated list and as a team we read every single User
Story that came in and processed them accordingly in making this decision.

>  Thank you,
>  Till
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  

-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford <https://www.redhat.com/>

Communications House

Cork Road, Waterford City

lgriffin(a)redhat.com
M: [phone]     IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>

[Leigh Griffin]

On Mon, Mar 30, 2020 at 3:36 PM Matthias Runge <mrunge(a)matthias-runge.de&gt;
wrote:

>  On 30/03/2020 16:23, Till Maas wrote:
>
>  >>>> For transparency, we have published the full User Story list which is
>  >>>> linked within the blog and for ease of searching is here:
>  >>>> https://hackmd.io/@My419-DISUGgo4gcmO1D6A/HJB74lcL8
>
>  >
>
> https://lists.fedoraproject.org/archives/list/[e-mail]...
>  >
>  > In the hackmd story list, there are is only infosec, RH Legal Rep, RH
>  > Infocsec Rep, RH Developer, RHEL engineer and general users, project
>  > contributor, CPE team member. Nothing really maps to the user groups I
>  > mentioned. There is only
>  >
>  > | 41
>  > | As a General User
>  > | I want groups and group membership and management
>  > | to allow me create access control on a suite of repositories
>  >
>  > but this is very vague.
>
>
>  Comparing the two lists Ben posted and the one on hackmd.io differ quite
>  a bit. Was the list of requirements changed during the process?
>  
As a team we evaluated every single requirement (over 300 of them) and the
presentation in the combined User Story list is an amalgamation of like for
like User Stories to capture at a high level the spirit of the requests.

>  Matthias
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  

-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford <https://www.redhat.com/>

Communications House

Cork Road, Waterford City

lgriffin(a)redhat.com
M: [phone]     IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>

[Pavel Raiskup]

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

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

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

Pavel

[Matthias Runge]

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

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

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

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


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

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

The following items will NOT be exported:

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


Matthias

[Simo Sorce]

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

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

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc

[Till Maas]

Hi,

On Mon, Mar 30, 2020 at 02:40:13PM +0000, Leigh Griffin wrote:
>  On Mon, Mar 30, 2020 at 3:26 PM Till Maas
> <opensource(a)till.name&gt; wrote:
>  
>  > Hi,
>  >
>  > On Mon, Mar 30, 2020 at 01:59:07PM +0000, Leigh Griffin wrote:
>  > > On Mon, Mar 30, 2020 at 2:18 PM Till Maas <opensource(a)till.name&gt; wrote:
>  > >
>  > > > Hi,
>  > > >
>  > > > On Mon, Mar 30, 2020 at 11:04:03AM +0100, Leigh Griffin wrote:
>  > > >
>  > > > > For transparency, we have published the full User Story list which
> is
>  > > > > linked within the blog and for ease of searching is here:
>  > > > > https://hackmd.io/@My419-DISUGgo4gcmO1D6A/HJB74lcL8
>  > > >
>  > > > the user stories list does not seem to include the original user
>  > stories
>  > > > that I submitted regarding package life-cycle and permission
>  > management.
>  > > > These are requirements for dist-git but not necessarily for a
>  > git-forge.
>  > > > In the past they were fulfilled by package db, now pagure is solving
>  > > > this more.
>  > >
>  > >
>  > > We received a summarised User Story list from the Fedora Council, I would
>  > > suggest reaching out with your concerns.
>  >
>  > What is the list that you got. The list on the council discuss list
>  > contained these items, for example for FESCo members, proven packagers
>  > and dist-git repo admins:
>  >
>  >
> https://lists.fedoraproject.org/archives/list/[e-mail]...
>  
>  
>  We received a Google Doc with the summation of the 44 requirements from
>  Fedora Council. 
Please be more specific. Are these the requirements from the discussion
different ones? The discussion had 47 requirements, 1 and 2 were
challenged and 47 mentioned as nice-to-have. Who submitted them? I guess
it was Ben.

>  > In the hackmd story list, there are is only infosec, RH Legal
> Rep, RH
>  > Infocsec Rep, RH Developer, RHEL engineer and general users, project
>  > contributor, CPE team member. Nothing really maps to the user groups I
>  > mentioned.
>  
>  
>  As mentioned, we rolled in stories together and General Users /
>  contributors map to the majority of the Fedora projects requirements
>  (similar for CentOS) and a lot of individual stakeholder requirements ended
>  up in the general bucket.
>  
>  
>  > There is only
>  >
>  > | 41
>  > | As a General User
>  > | I want groups and group membership and management
>  > | to allow me create access control on a suite of repositories
>  >
>  > but this is very vague.
>  >
>  
>  The User Stories are deliberately vague and that represents around 10
>  unique requirements that boil down to having group membership and
>  management capabilities. 
IMHO the problem with this vague requirement is that it probably fits
every gitforge. But for Fedora, the package management aspects are more
important than generic gitforge capabilities that any gitforge can
provide.

>  > Also there seems to be nothing about
> orphaning/adopting/retiring
>  > packages, not even in a vague way.
>  >
>  
>  We have stories relating to specific workflow requirements (from multiple
>  stakeholders including RHEL, CentOS and Fedora) for dist-git. We have
>  represented a requirement (number 18 on the list) about viewing orphaned
>  packages. The requirements received around this process were very much
>  aligned with permissions and visibility to allow actions. They are covered
>  through other User Stories and what I feel needs to be made clear, we are
>  presenting the amalgamated list and as a team we read every single User
>  Story that came in and processed them accordingly in making this decision. 
From the experience with the migration from Packagedb to pagure, the
specific requirements for Fedora seem to require more effort than just
providing generic gitforge capabilities. For example, the adopting an
orphaned package process needs to be a self service instead of a manual
process for release engineering. And the requirements seem to be so
vague that providing GIT repos with config files for workflows appears
as a valid solution but there should be a proper user interface.

Adapting a git forge to properly provide the workflow for Fedora
dist-git seems to me to be one of the major tasks, so assessing whether
a gitforge simplifies this seems to me to be rather important to make an
informed decision.

Kind regards
Till

[Ben Cotton]

On Mon, Mar 30, 2020 at 4:55 PM Till Maas <opensource(a)till.name&gt; wrote:
>  Please be more specific. Are these the requirements from the discussion
>  different ones? The discussion had 47 requirements, 1 and 2 were
>  challenged and 47 mentioned as nice-to-have. Who submitted them? I guess
>  it was Ben.
>  
Yes, I sent Aoife the user stories after they were discussed on the
council-discuss thread[1]. The original version had 47. One was added,
two were removed, and a few were edited to get the final count.

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

-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis

[Chris Murphy]

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

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


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

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

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



-- 
Chris Murphy

[Clement Verna]

On Mon, 30 Mar 2020 at 22:55, Till Maas <opensource(a)till.name&gt; wrote:

>  Hi,
>
>  On Mon, Mar 30, 2020 at 02:40:13PM +0000, Leigh Griffin wrote:
>  > On Mon, Mar 30, 2020 at 3:26 PM Till Maas <opensource(a)till.name&gt; wrote:
>  >
>  > > Hi,
>  > >
>  > > On Mon, Mar 30, 2020 at 01:59:07PM +0000, Leigh Griffin wrote:
>  > > > On Mon, Mar 30, 2020 at 2:18 PM Till Maas <opensource(a)till.name&gt;
>  wrote:
>  > > >
>  > > > > Hi,
>  > > > >
>  > > > > On Mon, Mar 30, 2020 at 11:04:03AM +0100, Leigh Griffin wrote:
>  > > > >
>  > > > > > For transparency, we have published the full User Story list
>  which is
>  > > > > > linked within the blog and for ease of searching is here:
>  > > > > > https://hackmd.io/@My419-DISUGgo4gcmO1D6A/HJB74lcL8
>  > > > >
>  > > > > the user stories list does not seem to include the original user
>  > > stories
>  > > > > that I submitted regarding package life-cycle and permission
>  > > management.
>  > > > > These are requirements for dist-git but not necessarily for a
>  > > git-forge.
>  > > > > In the past they were fulfilled by package db, now pagure is
>  solving
>  > > > > this more.
>  > > >
>  > > >
>  > > > We received a summarised User Story list from the Fedora Council, I
>  would
>  > > > suggest reaching out with your concerns.
>  > >
>  > > What is the list that you got. The list on the council discuss list
>  > > contained these items, for example for FESCo members, proven packagers
>  > > and dist-git repo admins:
>  > >
>  > >
>
> https://lists.fedoraproject.org/archives/list/[e-mail]...
>  >
>  >
>  > We received a Google Doc with the summation of the 44 requirements from
>  > Fedora Council.
>
>  Please be more specific. Are these the requirements from the discussion
>  different ones? The discussion had 47 requirements, 1 and 2 were
>  challenged and 47 mentioned as nice-to-have. Who submitted them? I guess
>  it was Ben.
>
>  > > In the hackmd story list, there are is only infosec, RH Legal Rep, RH
>  > > Infocsec Rep, RH Developer, RHEL engineer and general users, project
>  > > contributor, CPE team member. Nothing really maps to the user groups I
>  > > mentioned.
>  >
>  >
>  > As mentioned, we rolled in stories together and General Users /
>  > contributors map to the majority of the Fedora projects requirements
>  > (similar for CentOS) and a lot of individual stakeholder requirements
>  ended
>  > up in the general bucket.
>  >
>  >
>  > > There is only
>  > >
>  > > | 41
>  > > | As a General User
>  > > | I want groups and group membership and management
>  > > | to allow me create access control on a suite of repositories
>  > >
>  > > but this is very vague.
>  > >
>  >
>  > The User Stories are deliberately vague and that represents around 10
>  > unique requirements that boil down to having group membership and
>  > management capabilities.
>
>  IMHO the problem with this vague requirement is that it probably fits
>  every gitforge. But for Fedora, the package management aspects are more
>  important than generic gitforge capabilities that any gitforge can
>  provide.
>  
I don't think this is necessarily true, in fact Fedora existed before
Pagure( using cgit as a git interface). I am not necessarily proposing to
recreate something like packageDB but I believe that there might be a
possible middle ground between using a generic git forge and some tooling
around to support the package management aspects. And yes this will require
some work, but my feeling is that on the longer term this will be easier to
maintain than a code base like Pagure.


>  > > Also there seems to be nothing about orphaning/adopting/retiring
>  > > packages, not even in a vague way.
>  > >
>  >
>  > We have stories relating to specific workflow requirements (from multiple
>  > stakeholders including RHEL, CentOS and Fedora) for dist-git. We have
>  > represented a requirement (number 18 on the list) about viewing orphaned
>  > packages. The requirements received around this process were very much
>  > aligned with permissions and visibility to allow actions. They are
>  covered
>  > through other User Stories and what I feel needs to be made clear, we are
>  > presenting the amalgamated list and as a team we read every single User
>  > Story that came in and processed them accordingly in making this
>  decision.
>
>  From the experience with the migration from Packagedb to pagure, the
>  specific requirements for Fedora seem to require more effort than just
>  providing generic gitforge capabilities. For example, the adopting an
>  orphaned package process needs to be a self service instead of a manual
>  process for release engineering. And the requirements seem to be so
>  vague that providing GIT repos with config files for workflows appears
>  as a valid solution but there should be a proper user interface.
>
>  Adapting a git forge to properly provide the workflow for Fedora
>  dist-git seems to me to be one of the major tasks, so assessing whether
>  a gitforge simplifies this seems to me to be rather important to make an
>  informed decision.
>
>  Kind regards
>  Till
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>

[Petr Kubat]

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

On 3/30/20 11:17 AM, Leigh Griffin wrote:
>  Hi everyone,
>
>  Thank you for your patience while the CPE Team worked through an 
>  incredible number of requirements from multiple stakeholder sources. 
>  On Friday evening we announced on the Community Blog 
>  <https://communityblog.fedoraproject.org/making-a-git-forge-decision/> our 
>  decision to adopt Gitlab as our Git Forge and to retain pagure.io 
>  <http://pagure.io/> to ultimately hand over to the Community to 
>  maintain. It wasn't an easy decision by any stretch of the imagination 
>  and we hope that the compromise that we are striking will help to 
>  allow Pagure flourish and to give a choice of Forges for your usage. 
>  I'm happy to field any questions or comments about this decision.
>
>  Kind regards,
>  Leigh, on behalf of the CPE Team
>
>  -- 
>
>  Leigh Griffin
>
>  Engineering Manager
>
>  Red Hat Waterford <https://www.redhat.com/>
>
>  Communications House
>
>  Cork Road, Waterford City
>
>  lgriffin(a)redhat.com <mailto:[e-mail]>
>  M: [phone] <tel:[phone]> IM: lgriffin
>
>  @redhatjobs <https://twitter.com/redhatjobs> redhatjobs 
>  <https://www.facebook.com/redhatjobs> @redhatjobs 
>  <https://instagram.com/redhatjobs>
>  <https://red.ht/sig>
>
>
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]

[Vít Ondruch]

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

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

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


Vít



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

[Leigh Griffin]

On Mon, Mar 30, 2020 at 9:55 PM Till Maas <opensource(a)till.name&gt; wrote:

>  Hi,
>
>  On Mon, Mar 30, 2020 at 02:40:13PM +0000, Leigh Griffin wrote:
>  > On Mon, Mar 30, 2020 at 3:26 PM Till Maas <opensource(a)till.name&gt; wrote:
>  >
>  > > Hi,
>  > >
>  > > On Mon, Mar 30, 2020 at 01:59:07PM +0000, Leigh Griffin wrote:
>  > > > On Mon, Mar 30, 2020 at 2:18 PM Till Maas <opensource(a)till.name&gt;
>  wrote:
>  > > >
>  > > > > Hi,
>  > > > >
>  > > > > On Mon, Mar 30, 2020 at 11:04:03AM +0100, Leigh Griffin wrote:
>  > > > >
>  > > > > > For transparency, we have published the full User Story list
>  which is
>  > > > > > linked within the blog and for ease of searching is here:
>  > > > > > https://hackmd.io/@My419-DISUGgo4gcmO1D6A/HJB74lcL8
>  > > > >
>  > > > > the user stories list does not seem to include the original user
>  > > stories
>  > > > > that I submitted regarding package life-cycle and permission
>  > > management.
>  > > > > These are requirements for dist-git but not necessarily for a
>  > > git-forge.
>  > > > > In the past they were fulfilled by package db, now pagure is
>  solving
>  > > > > this more.
>  > > >
>  > > >
>  > > > We received a summarised User Story list from the Fedora Council, I
>  would
>  > > > suggest reaching out with your concerns.
>  > >
>  > > What is the list that you got. The list on the council discuss list
>  > > contained these items, for example for FESCo members, proven packagers
>  > > and dist-git repo admins:
>  > >
>  > >
>
> https://lists.fedoraproject.org/archives/list/[e-mail]...
>  >
>  >
>  > We received a Google Doc with the summation of the 44 requirements from
>  > Fedora Council.
>
>  Please be more specific. Are these the requirements from the discussion
>  different ones? The discussion had 47 requirements, 1 and 2 were
>  challenged and 47 mentioned as nice-to-have. Who submitted them? I guess
>  it was Ben.
>  
44 requirements were received from Ben Cotton on behalf of the Fedora
Council. It's not for me to comment on whether the thread was copied
verbatim or how it was rolled up, I dealt with the formal requirements that
landed.

>  > > In the hackmd story list, there are is only infosec, RH Legal Rep, RH
>  > > Infocsec Rep, RH Developer, RHEL engineer and general users, project
>  > > contributor, CPE team member. Nothing really maps to the user groups I
>  > > mentioned.
>  >
>  >
>  > As mentioned, we rolled in stories together and General Users /
>  > contributors map to the majority of the Fedora projects requirements
>  > (similar for CentOS) and a lot of individual stakeholder requirements
>  ended
>  > up in the general bucket.
>  >
>  >
>  > > There is only
>  > >
>  > > | 41
>  > > | As a General User
>  > > | I want groups and group membership and management
>  > > | to allow me create access control on a suite of repositories
>  > >
>  > > but this is very vague.
>  > >
>  >
>  > The User Stories are deliberately vague and that represents around 10
>  > unique requirements that boil down to having group membership and
>  > management capabilities.
>
>  IMHO the problem with this vague requirement is that it probably fits
>  every gitforge. But for Fedora, the package management aspects are more
>  important than generic gitforge capabilities that any gitforge can
>  provide.
>  
Bear in mind the user stories we published were the amalgamated User Story
list, we considered every single story as it was written and intended.

>  > > Also there seems to be nothing about orphaning/adopting/retiring
>  > > packages, not even in a vague way.
>  > >
>  >
>  > We have stories relating to specific workflow requirements (from multiple
>  > stakeholders including RHEL, CentOS and Fedora) for dist-git. We have
>  > represented a requirement (number 18 on the list) about viewing orphaned
>  > packages. The requirements received around this process were very much
>  > aligned with permissions and visibility to allow actions. They are
>  covered
>  > through other User Stories and what I feel needs to be made clear, we are
>  > presenting the amalgamated list and as a team we read every single User
>  > Story that came in and processed them accordingly in making this
>  decision.
>
>  From the experience with the migration from Packagedb to pagure, the
>  specific requirements for Fedora seem to require more effort than just
>  providing generic gitforge capabilities. For example, the adopting an
>  orphaned package process needs to be a self service instead of a manual
>  process for release engineering. And the requirements seem to be so
>  vague that providing GIT repos with config files for workflows appears
>  as a valid solution but there should be a proper user interface.
>
>  Adapting a git forge to properly provide the workflow for Fedora
>  dist-git seems to me to be one of the major tasks, so assessing whether
>  a gitforge simplifies this seems to me to be rather important to make an
>  informed decision.
>
>  Kind regards
>  Till
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  

-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford <https://www.redhat.com/>

Communications House

Cork Road, Waterford City

lgriffin(a)redhat.com
M: [phone]     IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>

[Leigh Griffin]

On Mon, Mar 30, 2020 at 10:38 PM Chris Murphy <lists(a)colorremedies.com&gt;
wrote:

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

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


>  Were there deliberations by CPE Team in between (2) and (4)? 
Yes, several hundred person hours worth of analysis, meetings and
dissecting the requirements.


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

>  --
>  Chris Murphy
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  

-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford <https://www.redhat.com/>

Communications House

Cork Road, Waterford City

lgriffin(a)redhat.com
M: [phone]     IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>

[Leigh Griffin]

On Tue, Mar 31, 2020 at 8:10 AM Petr Kubat <pkubat(a)redhat.com&gt; wrote:

>  From the community blog this decision seems more like a "what
> can we use
>  to make CentOS Stream work" rather than an open community-made choice of
>  what is best for Fedora.
>  
The needs of Fedora, CentOS, RHEL and the CPE team were weighed equally in
our decision. Fedora had very few specific needs in their requirements
where as some stakeholder groups had. The balance of the decision was for
Gitlab.

>  On 3/30/20 11:17 AM, Leigh Griffin wrote:
>
>  Hi everyone,
>
>  Thank you for your patience while the CPE Team worked through an
>  incredible number of requirements from multiple stakeholder sources. On
>  Friday evening we announced on the Community Blog
>  <https://communityblog.fedoraproject.org/making-a-git-forge-decision/> our
>  decision to adopt Gitlab as our Git Forge and to retain pagure.io to
>  ultimately hand over to the Community to maintain. It wasn't an easy
>  decision by any stretch of the imagination and we hope that the compromise
>  that we are striking will help to allow Pagure flourish and to give a
>  choice of Forges for your usage. I'm happy to field any questions or
>  comments about this decision.
>
>  Kind regards,
>  Leigh, on behalf of the CPE Team
>
>  --
>
>  Leigh Griffin
>
>  Engineering Manager
>
>  Red Hat Waterford <https://www.redhat.com/>
>
>  Communications House
>
>  Cork Road, Waterford City
>
>  lgriffin(a)redhat.com
>  M: [phone]     IM: lgriffin
>  @redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
>  <https://www.facebook.com/redhatjobs> @redhatjobs
>  <https://instagram.com/redhatjobs>
>  <https://red.ht/sig>
>
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  

-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford <https://www.redhat.com/>

Communications House

Cork Road, Waterford City

lgriffin(a)redhat.com
M: [phone]     IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>

[Miro Hrončok]

On 31. 03. 20 10:36, Leigh Griffin wrote:
>  I respect that there is disagreement but Gitlab is the choice we are
> making. 
I always try to assume good intentions, but this is very hard now. I understand 
this statement as follows:

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

Am I wrong?

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Leigh Griffin]

On Tue, Mar 31, 2020 at 10:41 AM Miro Hrončok <mhroncok(a)redhat.com&gt; wrote:

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

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

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

We have announced our decision to all stakeholders.

Now
>  when the people who will be actually using the thing are trying to
>  participate
>  in the discussion, their arguments no longer matter to us, because the
>  decision
>  was already made, whatever you say won't change it, this discussion is
>  pointless."
>  
The thoughts and arguments matter and will influence how the technical
implementation will go for us. I already have pulled some good information
from the responses for our consideration. It's not altering the decision as
the overall balance of requirements is still pointing to Gitlab as the
choice.

>  Am I wrong?
>  
Yes.

>  --
>  Miro Hrončok
>  --
>  Phone: [phone]
>  IRC: mhroncok
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  

-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford <https://www.redhat.com/>

Communications House

Cork Road, Waterford City

lgriffin(a)redhat.com
M: [phone]     IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>

[Kevin Kofler]

Leigh Griffin wrote:
>  Thank you for your patience while the CPE Team worked through an
>  incredible number of requirements from multiple stakeholder sources. On
>  Friday evening we announced on the Community Blog
>  <https://communityblog.fedoraproject.org/making-a-git-forge-decision/> our
>  decision to adopt Gitlab as our Git Forge and to retain pagure.io to
>  ultimately hand over to the Community to maintain. It wasn't an easy
>  decision by any stretch of the imagination and we hope that the compromise
>  that we are striking will help to allow Pagure flourish and to give a
>  choice of Forges for your usage. I'm happy to field any questions or
>  comments about this decision. 
What really worries to me is that:
* using GitLab as SaaS is being considered, and
* for self-hosting, using the proprietary "enterprise" editions is not
  excluded.

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

        Kevin Kofler

[Felix Schwarz]

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

Felix

[Leigh Griffin]

On Tue, Mar 31, 2020 at 11:43 AM Kevin Kofler <kevin.kofler(a)chello.at&gt;
wrote:

>  Leigh Griffin wrote:
>  > Thank you for your patience while the CPE Team worked through an
>  > incredible number of requirements from multiple stakeholder sources. On
>  > Friday evening we announced on the Community Blog
>  > <https://communityblog.fedoraproject.org/making-a-git-forge-decision/>
>  our
>  > decision to adopt Gitlab as our Git Forge and to retain pagure.io to
>  > ultimately hand over to the Community to maintain. It wasn't an easy
>  > decision by any stretch of the imagination and we hope that the
>  compromise
>  > that we are striking will help to allow Pagure flourish and to give a
>  > choice of Forges for your usage. I'm happy to field any questions or
>  > comments about this decision.
>
>  What really worries to me is that:
>  * using GitLab as SaaS is being considered, and
>  * for self-hosting, using the proprietary "enterprise" editions is not
>    excluded.
>
>  I think that using anything other than Free Software as the hosting
>  platform
>  for Fedora should be an absolute no go. In other words, self-hosted GitLab
>  CE or Pagure, no other options.
>  
No option is off the table right now as we haven't sat down with Gitlab to
evaluate options yet, that is scheduled for this week. SaaS and all
variants of licensing are an option right now until we evaluate the tooling
needs and process the valuable feedback in this thread (and others) will be
brought to Gitlab and in our public facing ticket we would most welcome
engagement to have your voice and say heard by the Gitlab folks directly.


>          Kevin Kofler
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  

-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford <https://www.redhat.com/>

Communications House

Cork Road, Waterford City

lgriffin(a)redhat.com
M: [phone]     IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>

[Leigh Griffin]

On Tue, Mar 31, 2020 at 11:48 AM Felix Schwarz <fschwarz(a)fedoraproject.org&gt;
wrote:

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

>  Felix
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  

-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford <https://www.redhat.com/>

Communications House

Cork Road, Waterford City

lgriffin(a)redhat.com
M: [phone]     IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>

[Tomasz Torcz]

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


-- 
Tomasz Torcz                Only gods can safely risk perfection,
tomek(a)pipebreaker.pl     it's a dangerous thing for a man.  — Alia

[Clement Verna]

On Tue, 31 Mar 2020 at 11:41, Miro Hrončok <mhroncok(a)redhat.com&gt; wrote:

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

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

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

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

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

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

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

I hope that my perspective helps a little.


>  --
>  Miro Hrončok
>  --
>  Phone: [phone]
>  IRC: mhroncok
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>

[Kevin Kofler]

Tomasz Torcz wrote:
>  We seem to have not problem in using proprietary SAAS solutions for
>  critical stuff. 
And that is exactly what I am complaining about.

        Kevin Kofler

[Miro Hrončok]

On 31. 03. 20 12:41, Leigh Griffin wrote:
>      Am I wrong?
>  Yes. 
Thanks for clarifying that.

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Miro Hrončok]

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

Most importantly the following:

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

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

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

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

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Clement Verna]

On Tue, 31 Mar 2020 at 13:46, Miro Hrončok <mhroncok(a)redhat.com&gt; wrote:

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

As you said it always to good to assume best intentions and I honestly
think there was no intentions of making this decision without the community
involvement otherwise all the requirement gathering would have not
happened.

My understanding is that there was a Fedora involvement,  through the
council. I believe that the council represented the community and Fedora's
use cases during the discussion and decision. So I think that the role of
the council was not obvious to everyone in the community, and that makes
the all thing sound like the Fedora community was not involved.

After making a decision is never easy and communication is even harder, so
I think it is good to note what did not go well and try to understand why
so that it can be improved next time.


>  --
>  Miro Hrončok
>  --
>  Phone: [phone]
>  IRC: mhroncok
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>

[Guido Aulisi]

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

Guido Aulisi

[Neal Gompa]

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

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

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

This is a cycle that I've been *trying* to break. I'll be the first to
admit that I'm not the greatest programmer in the world, but I try to
contribute in terms of code, code reviews, testing, etc. But one thing
I've been doing for the past couple of years is *community project
advocacy*. I've been examining all the projects we have in Fedora and
seeing which ones I can help seed communities out of. My hope is that
by nurturing communities that are all interested in the success of
these projects, we can make them more independently sustainable.

As for Pagure itself, I think this is where we fundamentally disagree.
I think it behooves us to own and provide an experience tailored for
our community from beginning to end. That's why we have Koji, Bodhi,
Dist-Git, and many other tools in that part of the lifecycle. The
packager experience is literally the lifeblood of the project, and our
contributors are the core of what makes Fedora successful. Pagure
gives us an opportunity to do right by them that I *really* don't
think we can do with any alternatives.

That does *not* mean that CPE team should be the sole owner of the
Pagure *codebase*. On that point, I agree. And that's why I've spent a
lot of time and energy since late 2018 working on building up that
community. It's finally starting to bear fruit too: there's at least
one entity interested in building a product around it and contributing
to help support that product, there's the FSF preparing to launch a
new forge using Pagure, there's the Trisquel GNU+Linux distribution
working on a Pagure deployment to host their code and packaging, and
there's a few other things I've got up my sleeve to help broaden the
community with not just users, but also contributors.

Are there deficiencies in Pagure? Of course there are. I'm not
claiming that Pagure is perfect. But I think that keeping on with
Pagure and giving that community an opportunity to close the gap on
needed features for Fedora/CentOS/Red Hat is the right way to go.
Right now, I don't *know* what the important gaps are. I can make some
guesses, but it'd be a lot better if we had a list of missing features
and their relative important and why. That would help focus
development to meet those needs.

The Fedora community itself has indicated that they want to keep on
with Pagure, and many Fedorans are Pythonistas, which means that
everyone can easily contribute to help make it better for everyone.

Anyway, I hope this helps clarify my position on the matter!

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




-- 
真実はいつも一つ！/ Always, there's only one truth!

[Bruno Wolff III]

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

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

[Neal Gompa]

On Tue, Mar 31, 2020 at 10:37 AM Bruno Wolff III <bruno(a)wolff.to&gt; wrote:
>  On Tue, Mar 31, 2020 at 12:55:39 +0200,
>    Tomasz Torcz <tomek(a)pipebreaker.pl&gt; wrote:
>  >
>  >  Being self-hosted is a nice goal, but not important enough.
>  >There are parts of Fedora infrastructure which are not using Fedora,
>  >but other distributions like RHEL.  We seem to have not problem in
>  >using proprietary SAAS solutions for critical stuff.
>
>  RHEL is a special case, as CENTOS provides a free drop in replacement and
>  switching from CENTOS to Fedora shouldn't be much work. Is there other
>  proprietary software at the OS level or above, that is used for Fedora
>  infrastructure?
>  
The only part of Fedora Infrastructure itself that is proprietary (to
the best of my knowledge) is the NetApp storage appliances that have
been in place since Koji was deployed back in 2007. I think if we were
to do this all over again today, we would be using Gluster or Ceph,
but it's a ton of work for no gain to change storage stuff right now.

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

>  >  I truly envy Debian and their ability to dogfood, running
> their
>  >infra on Debian. With minor exception: although they self-host GitLab,
>  >it seems to be different than their distribution packages.
>
>  I think the difference is the support window for Fedora. In a way CENTOS
>  is an LTS version of Fedora. 
Over the years, more of Fedora Infrastructure has migrated from RHEL
to Fedora because RHEL doesn't work out very well for some of our
infrastructure.

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




--
真実はいつも一つ！/ Always, there's only one truth!

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


>  
>  Felix
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]

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

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

Jirka

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

[Michael Catanzaro]

On Tue, Mar 31, 2020 at 12:42 pm, Kevin Kofler <kevin.kofler(a)chello.at&gt; 
wrote:
>  What really worries to me is that:
>  * using GitLab as SaaS is being considered, and
>  * for self-hosting, using the proprietary "enterprise" editions is not
>    excluded.
>  
>  I think that using anything other than Free Software as the hosting 
>  platform
>  for Fedora should be an absolute no go. In other words, self-hosted 
>  GitLab
>  CE or Pagure, no other options. 
Very rare for me to say this, but: I agree with Kevin.

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

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

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

Michael

[Matthew Miller]

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

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



-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Iñaki Ucar]

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

Iñaki

[Adam Williamson]

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

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

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

[Bruno Wolff III]

On Tue, Mar 31, 2020 at 13:08:05 -0400,
  Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote:
> We did communicate as the very top line of our gathered requirements that
> open source is essential to our community and central to our feedback. I'm
> not trying to be soft on that. Let's just not do purity-test level
> assessments and instead focus on our goals. 
The response from CPE made it sound like they just counted requirements 
rather than evalutating how important each requirement was to each group. 
Perhaps that was not intended, but that's they way it sounds. I think that 
being able to theorectically switch from hosted to self-hosted in short 
order (like in a month), should have been a deal breaking requirement from 
Fedora in case something at Gitlab changed that prevented using their 
hosted service. That implies having access to the source (capable of running 
our instance) with a free license and regular exports of the data in our 
hands. It doesn't sound like that is a requirement from the response 
provided by CPE.

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

[Adam Williamson]

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

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

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

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

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

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

[Matthew Miller]

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


-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Matthew Miller]

On Tue, Mar 31, 2020 at 10:44:35AM -0700, Adam Williamson wrote:
>  I'm sorry, but I have to agree with Kevin and Michael here to a
>  significant extent. Running our own project on open source code has
>  always been a very big bright line for Fedora. 
You don't have to be sorry! I think it's very clear that this is the general
community view.

>  I think Iñaki's take on the "oh, you contribute to Github
> projects so
>  no problem right?" angle is correct. 
Let me be sorry, though. That wasn't mean to be a "oh you..." statement. It
was that other open source projects are not held to this standard, not to
"gotcha" Michael or anyone else for their contributions elsewhere.


-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Matthew Miller]

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

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Adam Williamson]

On Tue, 2020-03-31 at 13:55 -0400, Matthew Miller wrote:
>  On Tue, Mar 31, 2020 at 10:44:35AM -0700, Adam Williamson wrote:
>  > I'm sorry, but I have to agree with Kevin and Michael here to a
>  > significant extent. Running our own project on open source code has
>  > always been a very big bright line for Fedora.
>  
>  You don't have to be sorry! I think it's very clear that this is the general
>  community view.
>  
>  > I think Iñaki's take on the "oh, you contribute to Github projects so
>  > no problem right?" angle is correct.
>  
>  Let me be sorry, though. That wasn't mean to be a "oh you..." statement.
> It
>  was that other open source projects are not held to this standard, not to
>  "gotcha" Michael or anyone else for their contributions elsewhere. 
I mean, held by who? This is a standard we have (more or less) held
ourselves to. Which, if you think about it, means it's a standard
that's in our DNA: we're a group of people who *thought it was
important enough to hold ourselves to that standard*. Would it be
hypocritical for someone outside of Fedora who happily uses software
from other projects that are hosted on Github or whatever to criticize
us if we were to do this? Sure, it would be. But this here is not that,
it's us holding ourselves to our own standards.

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

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

[Adam Williamson]

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

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

[Chris Murphy]

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

Lack of resources might supercede an open source requirement. But if
that is really the choice, that itself exposes a far bigger problem:
all other projects being maintained by CPE and Fedora Infrastructure
team are at risk. Why can't half or even all of them be rolled up into
proprietary equivalents and handed off for some other company to
manage? What's next?

This is awkward, but not even 12 days ago the Council approved a new
vision statement:

The Fedora Project envisions a world where everyone benefits from free
and open source software built by inclusive, welcoming, and
open-minded communities.

I can't say for sure there is a conflict in the process used to arrive
at the decision, but I'm questioning whether there is incongruity, and
the nature of it.

-- 
Chris Murphy

[Kevin Fenzi]

On Tue, Mar 31, 2020 at 12:40:55PM -0500, Bruno Wolff III wrote:
...snip...
>  
>  Because of switching costs, this is likely to prevent us from going back to
>  Pagure if it does develop a vibrant independent community. That would be
>  unfortunate. 
So, currently we are using pagure on src.fedoraproject.org, but it's not
just pagure, it's a integration layer over the top of pagure too. 

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

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

kevin

[Clement Verna]

On Tue, 31 Mar 2020 at 14:57, Neal Gompa <ngompa13(a)gmail.com&gt; wrote:

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


>  This is a cycle that I've been *trying* to break. I'll be the first to
>  admit that I'm not the greatest programmer in the world, but I try to
>  contribute in terms of code, code reviews, testing, etc. But one thing
>  I've been doing for the past couple of years is *community project
>  advocacy*. I've been examining all the projects we have in Fedora and
>  seeing which ones I can help seed communities out of. My hope is that
>  by nurturing communities that are all interested in the success of
>  these projects, we can make them more independently sustainable.
>  
Thank you for all your work and efforts, this is really appreciated.


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


>  That does *not* mean that CPE team should be the sole owner of the
>  Pagure *codebase*. On that point, I agree. And that's why I've spent a
>  lot of time and energy since late 2018 working on building up that
>  community. It's finally starting to bear fruit too: there's at least
>  one entity interested in building a product around it and contributing
>  to help support that product, there's the FSF preparing to launch a
>  new forge using Pagure, there's the Trisquel GNU+Linux distribution
>  working on a Pagure deployment to host their code and packaging, and
>  there's a few other things I've got up my sleeve to help broaden the
>  community with not just users, but also contributors.
>
>  Are there deficiencies in Pagure? Of course there are. I'm not
>  claiming that Pagure is perfect. But I think that keeping on with
>  Pagure and giving that community an opportunity to close the gap on
>  needed features for Fedora/CentOS/Red Hat is the right way to go.
>  Right now, I don't *know* what the important gaps are. I can make some
>  guesses, but it'd be a lot better if we had a list of missing features
>  and their relative important and why. That would help focus
>  development to meet those needs.
>
>  The Fedora community itself has indicated that they want to keep on
>  with Pagure, and many Fedorans are Pythonistas, which means that
>  everyone can easily contribute to help make it better for everyone.
>  
Genuine question, from the people that have participated in this thread,
How many could dedicated couple hours a week to work on Pagure ? I think
many community member are already struggling to keep up with their current
level of contribution, I am not sure than everyone can easily contribute to
Pagure. But I am happy to wrong :-).


>  Anyway, I hope this helps clarify my position on the matter!
>  
>  [1]:
>
> https://lists.fedoraproject.org/archives/list/[e-mail].o...
>
>
>
>
>  --
>  真実はいつも一つ！/ Always, there's only one truth!
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>

[Chris Murphy]

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

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



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

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

> >
> > Is there
> > a record of those deliberations?
>
>
>  No, they were mostly video calls / in person meetings and the result is the User Story
> list and decision document for sharing. 
I think a summary of the first hour of these several hundred hours,
and the last hour, would be useful. There's no way to reconstruct
this? Deliberative bodies should be keeping notes, summary of major
decisions, pros, cons, liabilities, prioritization of conflicting
requirements, what things are in and out of scope, etc. There must be
something to show.


-- 
Chris Murphy

[Adam Williamson]

On Tue, 2020-03-31 at 20:59 +0200, Clement Verna wrote:
>  
>  > The Fedora community itself has indicated that they want to keep on
>  > with Pagure, and many Fedorans are Pythonistas, which means that
>  > everyone can easily contribute to help make it better for everyone.
>  > 
>  
>  Genuine question, from the people that have participated in this thread,
>  How many could dedicated couple hours a week to work on Pagure ? I think
>  many community member are already struggling to keep up with their current
>  level of contribution, I am not sure than everyone can easily contribute to
>  Pagure. But I am happy to wrong :-). 
I could, I've written patches for it before in fact. I would actually
be doing this already except that I knew this process was going on and
didn't want to burn work on it, and it's a little difficult to know
what kind of work I can just jump in and do and expect to be accepted
beyond very straightforward bug fixes. But if there was a co-ordinated
effort around this and I could rely on there being someone I can bounce
"hey, is it OK if I do <X>?" or "what do we really need to try and
get
done right now?" type questions off, I'd certainly be able to find a
couple of hours to do some stuff.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Tomasz Torcz]

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


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


-- 
Tomasz Torcz                Only gods can safely risk perfection,
tomek(a)pipebreaker.pl     it's a dangerous thing for a man.  — Alia

[Clement Verna]

On Tue, 31 Mar 2020 at 20:04, Adam Williamson <adamwill(a)fedoraproject.org&gt;
wrote:

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


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

[Adam Williamson]

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

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

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

[Przemek Klosowski]

On 3/31/20 1:40 PM, Bruno Wolff III wrote:
>  On Tue, Mar 31, 2020 at 13:08:05 -0400,
>   Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote:
> >
> > We did communicate as the very top line of our gathered requirements 
> > that
> > open source is essential to our community and central to our 
> > feedback. I'm
> > not trying to be soft on that. Let's just not do purity-test level
> > assessments and instead focus on our goals.
>
>  The response from CPE made it sound like they just counted 
>  requirements rather than evalutating how important each requirement 
>  was to each group. Perhaps that was not intended, but that's they way 
>  it sounds. I think that being able to theorectically switch from 
>  hosted to self-hosted in short order (like in a month), should have 
>  been a deal breaking requirement from Fedora in case something at 
>  Gitlab changed that prevented using their hosted service. That implies 
>  having access to the source (capable of running our instance) with a 
>  free license and regular exports of the data in our hands. It doesn't 
>  sound like that is a requirement from the response provided by CPE.
>
>  Because of switching costs, this is likely to prevent us from going 
>  back to Pagure if it does develop a vibrant independent community. 
>  That would be unfortunate.  
This particular dilemma reminds me very much of the time when the LInux 
kernel developers weren't using version control, and it became clear 
that one is needed. Linus just refused to use CVS, and after some 
controversy, the core developers decided to use Larry McVoy's 
proprietary BitKeeper distributed VCS. This solved the technical problem 
and was successfully used for few years (2002 to 2005, IIRC).

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

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

2005-04-16 	[PATCH] mmtimer build fix 
<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit...

	Christoph Lameter 	1 	-1/+1
2005-04-16 	Linux-2.6.12-rc2 
<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit...

<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tag/?h...

	Linus Torvalds 	17291 	-0/+6718755

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

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

[Robbie Harwood]

Clement Verna <cverna(a)fedoraproject.org&gt; writes:

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

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

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

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

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

Thanks,
--Robbie

[clime]

Dne út 31. bře 2020 21:00 uživatel Clement Verna <cverna(a)fedoraproject.org&gt;
napsal:

>  On Tue, 31 Mar 2020 at 14:57, Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>
> > On Tue, Mar 31, 2020 at 7:10 AM Clement Verna <cverna(a)fedoraproject.org&gt;
> > wrote:
> > >
> > > I just want to give a bit of insight from someone who is working day to
> > day on Fedora's infrastructure, since I believe that might help give a bit
> > more empathy towards the Why of this decision.
> > >
> > > For me the Fedora's Infrastructure is in a very bad shape there is a
> > fair load of technical debt and trying to change or improve anything
> > results in a long list of reason why we can do it because services X
> > depends on service Y which depends on Z.  Since I joined the CPE team
> > (little bit more than 2 years ago) we have not been able to make any kind
> > of significant progress towards fighting this technical debt. Every year we
> > fill a white board with what needs to be done :
> > >
> > > Python 3 apps migration,
> > > FAS replacement,
> > > fedmsg retirement,
> > > FMN replacement,
> > > Fedora-packages replacement,
> > > PDC replacement,
> > > Porting application to OIDC,
> > > Improve Releng automation,
> > > Improving Anitya and the-new-hotness,
> > > .....
> > >
> > > Every single year the same items are coming back because we spend most
> > of our time firefighting services to keep users happy and keep Fedora
> > release schedule. This has a very demoralizing effect on the people working
> > in the team, it seems like we will never be able to make any significant
> > improvement, and our day to day job is to close couple tickets and you keep
> > watching the pile of tickets growing. There is no feeling of accomplishment
> > and a general sentiment that whatever we do, it will suck.
> > >
> > > A little over a year ago we have expressed our need to drop
> > applications, this is something we have to do to be able to stay sane and
> > keep a sustainable life-work balance. From that effort to handover
> > applications (Elections, Nuancier, Fedocal, Badges) to another group of
> > people in the community, not much happened mainly because of GDPR and the
> > legal responsibility of owning such applications, but as far as I know we
> > don't do much maintenance work on these applications any more since we now
> > have a few volunteers that are looking after them or helping with finding
> > an alternative solution.
> > >
> > > Now on the list of application we develop and run, I think Pagure is
> > logical candidate to try and find an alternative to it, but before doing
> > this it was important to make sure we captured all the use case and feature
> > needed from a git forge and see if any of these justified spending cycles
> > in development and maintenance work. My understanding of the decision is
> > that Pagure does not provide any significant advantage over GitLab. I know
> > that for many, the fact that Pagure is developed by Fedora is an advantage,
> > but from my perspective as someone that as to deal with all the other
> > services in Fedora's Infra this is a major disadvantage.
> > >
> > > Overall I think it is important to keep in mind that there is a lot of
> > work happening behind the scene to provide the people in the Fedora
> > community a good experience contributing to Fedora. I think we are doing a
> > good job at it, but that takes us an enormous effort and over the long term
> > this is not sustainable, also keeping in mind that we keep adding and want
> > to keep adding new things to Fedora.
> > >
> > > I hope that my perspective helps a little.
> > >
> >
> > Clement,
> >
> > I want to say thank you for all the hard work you do as a member of
> > the Fedora community and as a member of the CPE team. You've done
> > fantastic work for the community and it's always a pleasure to work
> > with you. And that goes for all the members of the CPE team. I totally
> > understand where you are coming from. And it *is* very demoralizing to
> > see the same things over and over again, looking as if you've made no
> > progress on these things. I've been there with my work at $DAYJOB
> > before, many times. And as you and others are aware, I've been poking
> > around throughout infrastructure projects to help with some of these
> > initiatives over the years, so I'm keenly aware of the size and scope
> > of many of these.
> >
> > However, I think some of this is self-inflicted. I don't want to
> > entirely rehash my original email with my thoughts on this, so please
> > read that for more detail[1], but I think we *really* should consider
> > that the lack of community exposure to to the codebases themselves
> > (especially as an avenue for contributing to the Fedora Project!) is
> > an underlying problem here. This has created a persistent cycle of
> > "community member makes cool project to support Fedora" → "it gets
> > adopted silently and no one really talks about it or advertises it" →
> > "nobody knows about it and the community member is the only one
> > working on it" → "the community member burns out and it gets piled
> > onto Fedora Engineering/CPE to maintain". This is basically how CPE
> > team got >100 codebases.
> >
>
>  I agree with that, but for me there also a bit of a chicken and egg
>  problem. I think we don't make more promotion and help people to onboard
>  with the code base because we already don't have the time to maintain
>  properly all these services, half of them if not more (I might be
>  exaggerating a little :-) )  don't have an up to date Readme file with
>  instruction on how to setup the development environment.
>  Another aspect that does not help a lot of our code bases are legacy
>  application using technology stack from more than 10 years ago, try to find
>  anyone interested to learn about Turbogears2 and mako templates (tech stack
>  for fedora-packages).
>
>
> >
> > This is a cycle that I've been *trying* to break. I'll be the first to
> > admit that I'm not the greatest programmer in the world, but I try to
> > contribute in terms of code, code reviews, testing, etc. But one thing
> > I've been doing for the past couple of years is *community project
> > advocacy*. I've been examining all the projects we have in Fedora and
> > seeing which ones I can help seed communities out of. My hope is that
> > by nurturing communities that are all interested in the success of
> > these projects, we can make them more independently sustainable.
> >
>
>  Thank you for all your work and efforts, this is really appreciated.
>
>
> >
> > As for Pagure itself, I think this is where we fundamentally disagree.
> > I think it behooves us to own and provide an experience tailored for
> > our community from beginning to end. That's why we have Koji, Bodhi,
> > Dist-Git, and many other tools in that part of the lifecycle. The
> > packager experience is literally the lifeblood of the project, and our
> > contributors are the core of what makes Fedora successful. Pagure
> > gives us an opportunity to do right by them that I *really* don't
> > think we can do with any alternatives.
> >
>
>  I am not convinced that having a custom git forge is mandatory to provide
>  an great experience to the community. I wasn't really around the community
>  before Pagure, but I as far as I understand it the experience was better
>  before Pagure and people were able to do more self servicing. I believe
>  that there is an alternative to having the packager workflow tightly
>  coupled to the git forge, this is also maybe a good opportunity to rethink
>  some of that workflow and explore different solutions.
>
>
> >
> > That does *not* mean that CPE team should be the sole owner of the
> > Pagure *codebase*. On that point, I agree. And that's why I've spent a
> > lot of time and energy since late 2018 working on building up that
> > community. It's finally starting to bear fruit too: there's at least
> > one entity interested in building a product around it and contributing
> > to help support that product, there's the FSF preparing to launch a
> > new forge using Pagure, there's the Trisquel GNU+Linux distribution
> > working on a Pagure deployment to host their code and packaging, and
> > there's a few other things I've got up my sleeve to help broaden the
> > community with not just users, but also contributors.
> >
> > Are there deficiencies in Pagure? Of course there are. I'm not
> > claiming that Pagure is perfect. But I think that keeping on with
> > Pagure and giving that community an opportunity to close the gap on
> > needed features for Fedora/CentOS/Red Hat is the right way to go.
> > Right now, I don't *know* what the important gaps are. I can make some
> > guesses, but it'd be a lot better if we had a list of missing features
> > and their relative important and why. That would help focus
> > development to meet those needs.
> >
> > The Fedora community itself has indicated that they want to keep on
> > with Pagure, and many Fedorans are Pythonistas, which means that
> > everyone can easily contribute to help make it better for everyone.
> >
>
>  Genuine question, from the people that have participated in this thread,
>  How many could dedicated couple hours a week to work on Pagure ? I think
>  many community member are already struggling to keep up with their current
>  level of contribution, I am not sure than everyone can easily contribute to
>  Pagure. But I am happy to wrong :-).
>  
I can look at the search-related issues that were mentioned here...as a
starting point. But i am not going to be motivated by pagure being taken
down from the dist-git's deployments.

Also...using a proprietary solution for our git forge would be just totally
lame. That should be out of question completely.

clime


> >
> > Anyway, I hope this helps clarify my position on the matter!
> >
>
> > [1]:
> >
> https://lists.fedoraproject.org/archives/list/[e-mail].o...
> >
> >
> >
> >
> > --
> > 真実はいつも一つ！/ Always, there's only one truth!
> > _______________________________________________
> > devel mailing list -- devel(a)lists.fedoraproject.org
> > To unsubscribe send an email to devel-leave(a)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/[e-mail]
> >
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>

[Paul Frields]

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

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

-- 
Paul

[Adam Williamson]

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

>  > For that reason, I think the "what to do with
> Pagure.io?" element of
>  > this discussion is less critical than the src.fp.o part.
>  > 
>  > >  A critical part of
>  > > our infrastructure the NFS shared storage also run an proprietary software
>  > > (NetApp).
>  > 
>  > That's been covered already, and was why I put the "(more or less)"
>  > caveat into my quote. Of course, when you're getting to storage
>  > appliances, you're getting into pretty fuzzy territory, because we
>  > don't worry about the openness of the firmware running on our servers
>  > and stuff like that either...we've never quite been at FSF levels of
>  > ideological purity. But to me, this is at a different level to that.
>  
>  I see what we do for a dist-git fronting forge as far less compelling
>  for "purity level" tests because nearly all the meaningful content is
>  still easily copied and/or forked. Using open source for our specific
>  authentication needs (self-service groups, etc.), for instance, is a
>  recent example of a more compelling level, and the CPE group is
>  putting time into that project accordingly. 
I'm not sure I entirely understand the argument here. Are you saying we
should only care if the specific things we need in Fedora are open
source - like our CLI integrations and so on? If so, isn't that
entirely naturally compatible with using Gitlab CE? After all, if all
you want the external project to be is a generic git forge and you plan
to write all the integration on top of that yourself, Gitlab CE does
that job fine?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Paul Frields]

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

-- 
Paul

[Clement Verna]

On Tue, 31 Mar 2020 at 22:41, Robbie Harwood <rharwood(a)redhat.com&gt; wrote:

>  Clement Verna <cverna(a)fedoraproject.org&gt; writes:
>
>  > Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  >> Clement Verna <cverna(a)fedoraproject.org&gt; wrote:
>  >>
>  >> As for Pagure itself, I think this is where we fundamentally
>  >> disagree.  I think it behooves us to own and provide an experience
>  >> tailored for our community from beginning to end. That's why we have
>  >> Koji, Bodhi, Dist-Git, and many other tools in that part of the
>  >> lifecycle. The packager experience is literally the lifeblood of the
>  >> project, and our contributors are the core of what makes Fedora
>  >> successful. Pagure gives us an opportunity to do right by them that I
>  >> *really* don't think we can do with any alternatives.
>  >
>  > I am not convinced that having a custom git forge is mandatory to
>  > provide an great experience to the community. I wasn't really around
>  > the community before Pagure, but I as far as I understand it the
>  > experience was better before Pagure and people were able to do more
>  > self servicing. I believe that there is an alternative to having the
>  > packager workflow tightly coupled to the git forge, this is also maybe
>  > a good opportunity to rethink some of that workflow and explore
>  > different solutions.
>
>  Well, this continues to conflate "git forge" and "solution for
>  dist-git".
>  
Yeah sorry I was not very clear, communication is hard and communication
via email is awfully hard. Personally I do not think that git hosting is a
problem. In today's world it is very easy to find solution to host a
project on a git forge and there are plenty of solution available. Also I
think it is important to note that the plan is to keep pagure.io running as
long as there are people willing to do the maintenance and based on that
thread I don't think that will be a problem.


>  Before pagure, we had a (no-webui) git serving dist-git with other
>  services (e.g., pkgdb) stapled on.  More self-servicing was possible
>  because it was a more mature project.  In my opinion, the move to pagure
>  happened prematurely due to lack of feature parity - a problem we're
>  still dealing with today, which I think is what your "self servicing" is
>  in reference to.
>  
>  Before pagure, we also had fedorahosted, which was our solution for
>  hosting projects, combining trac and a few other things.  Migration was
>  *painful*, and there have been many rocky parts along the way, but the
>  experience now is definitely better than fedorahosted.  It's far less
>  pleasant than a github project, though.
>
>  My impression is that most folks on this thread are more worried about
>  dist-git and its integrations than a general git forge, while it feels
>  like all CPE wants to talk about is the git forge.  You can't just use a
>  git forge as a dist-git: it takes a lot of integration work, which is
>  invisible because right now it's been done and just works™.  The refusal
>  to consider that this work exists in the decision worries me .
>  
I think this feeling comes from the mixing of git forge and dist-git use
case that you have pointed out. In CPE there is awareness of the amount of
work needed for migrating dist-git and all the integration you are
mentioning. My personal opinion is that this will not be a small or easy
project but I still think that this is worth it on the long term. I also
agree with what Kevin Fenzi said earlier in this thread that we should take
the time to rethink that integration layer around dist-git and minimize the
dependencies to the git hosting solution, so that git hosting would simply
be git hosting and it would not really matter if this was done by Pagure,
GitLab, or any other solution.


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

[Petr Kubat]

On 3/31/20 8:59 PM, Clement Verna wrote:
>  On Tue, 31 Mar 2020 at 14:57, Neal Gompa <ngompa13(a)gmail.com 
>  <mailto:[e-mail]>> wrote:
>
>      On Tue, Mar 31, 2020 at 7:10 AM Clement Verna
>      <cverna(a)fedoraproject.org <mailto:[e-mail]>> wrote:
>      >
>      > I just want to give a bit of insight from someone who is working
>      day to day on Fedora's infrastructure, since I believe that might
>      help give a bit more empathy towards the Why of this decision.
>      >
>      > For me the Fedora's Infrastructure is in a very bad shape there
>      is a fair load of technical debt and trying to change or improve
>      anything results in a long list of reason why we can do it because
>      services X depends on service Y which depends on Z.  Since I
>      joined the CPE team (little bit more than 2 years ago) we have not
>      been able to make any kind of significant progress towards
>      fighting this technical debt. Every year we fill a white board
>      with what needs to be done :
>      >
>      > Python 3 apps migration,
>      > FAS replacement,
>      > fedmsg retirement,
>      > FMN replacement,
>      > Fedora-packages replacement,
>      > PDC replacement,
>      > Porting application to OIDC,
>      > Improve Releng automation,
>      > Improving Anitya and the-new-hotness,
>      > .....
>      >
>      > Every single year the same items are coming back because we
>      spend most of our time firefighting services to keep users happy
>      and keep Fedora release schedule. This has a very demoralizing
>      effect on the people working in the team, it seems like we will
>      never be able to make any significant improvement, and our day to
>      day job is to close couple tickets and you keep watching the pile
>      of tickets growing. There is no feeling of accomplishment and a
>      general sentiment that whatever we do, it will suck.
>      >
>      > A little over a year ago we have expressed our need to drop
>      applications, this is something we have to do to be able to stay
>      sane and keep a sustainable life-work balance. From that effort to
>      handover applications (Elections, Nuancier, Fedocal, Badges) to
>      another group of people in the community, not much happened mainly
>      because of GDPR and the legal responsibility of owning such
>      applications, but as far as I know we don't do much maintenance
>      work on these applications any more since we now have a few
>      volunteers that are looking after them or helping with finding an
>      alternative solution.
>      >
>      > Now on the list of application we develop and run, I think
>      Pagure is logical candidate to try and find an alternative to it,
>      but before doing this it was important to make sure we captured
>      all the use case and feature needed from a git forge and see if
>      any of these justified spending cycles in development and
>      maintenance work. My understanding of the decision is that Pagure
>      does not provide any significant advantage over GitLab. I know
>      that for many, the fact that Pagure is developed by Fedora is an
>      advantage, but from my perspective as someone that as to deal with
>      all the other services in Fedora's Infra this is a major disadvantage.
>      >
>      > Overall I think it is important to keep in mind that there is a
>      lot of work happening behind the scene to provide the people in
>      the Fedora community a good experience contributing to Fedora. I
>      think we are doing a good job at it, but that takes us an enormous
>      effort and over the long term this is not sustainable, also
>      keeping in mind that we keep adding and want to keep adding new
>      things to Fedora.
>      >
>      > I hope that my perspective helps a little.
>      >
>
>      Clement,
>
>      I want to say thank you for all the hard work you do as a member of
>      the Fedora community and as a member of the CPE team. You've done
>      fantastic work for the community and it's always a pleasure to work
>      with you. And that goes for all the members of the CPE team. I totally
>      understand where you are coming from. And it *is* very demoralizing to
>      see the same things over and over again, looking as if you've made no
>      progress on these things. I've been there with my work at $DAYJOB
>      before, many times. And as you and others are aware, I've been poking
>      around throughout infrastructure projects to help with some of these
>      initiatives over the years, so I'm keenly aware of the size and scope
>      of many of these.
>
>      However, I think some of this is self-inflicted. I don't want to
>      entirely rehash my original email with my thoughts on this, so please
>      read that for more detail[1], but I think we *really* should consider
>      that the lack of community exposure to to the codebases themselves
>      (especially as an avenue for contributing to the Fedora Project!) is
>      an underlying problem here. This has created a persistent cycle of
>      "community member makes cool project to support Fedora" → "it gets
>      adopted silently and no one really talks about it or advertises it" →
>      "nobody knows about it and the community member is the only one
>      working on it" → "the community member burns out and it gets piled
>      onto Fedora Engineering/CPE to maintain". This is basically how CPE
>      team got >100 codebases.
>
>
>  I agree with that, but for me there also a bit of a chicken and egg 
>  problem. I think we don't make more promotion and help people to 
>  onboard with the code base because we already don't have the time to 
>  maintain properly all these services, half of them if not more (I 
>  might be exaggerating a little :-) )  don't have an up to date Readme 
>  file with instruction on how to setup the development environment.
>  Another aspect that does not help a lot of our code bases are legacy 
>  application using technology stack from more than 10 years ago, try to 
>  find anyone interested to learn about Turbogears2 and mako templates 
>  (tech stack for fedora-packages).
>
>
>      This is a cycle that I've been *trying* to break. I'll be the first to
>      admit that I'm not the greatest programmer in the world, but I try to
>      contribute in terms of code, code reviews, testing, etc. But one thing
>      I've been doing for the past couple of years is *community project
>      advocacy*. I've been examining all the projects we have in Fedora and
>      seeing which ones I can help seed communities out of. My hope is that
>      by nurturing communities that are all interested in the success of
>      these projects, we can make them more independently sustainable.
>
>
>  Thank you for all your work and efforts, this is really appreciated.
>
>
>      As for Pagure itself, I think this is where we fundamentally disagree.
>      I think it behooves us to own and provide an experience tailored for
>      our community from beginning to end. That's why we have Koji, Bodhi,
>      Dist-Git, and many other tools in that part of the lifecycle. The
>      packager experience is literally the lifeblood of the project, and our
>      contributors are the core of what makes Fedora successful. Pagure
>      gives us an opportunity to do right by them that I *really* don't
>      think we can do with any alternatives.
>
>
>  I am not convinced that having a custom git forge is mandatory to 
>  provide an great experience to the community. I wasn't really around 
>  the community before Pagure, but I as far as I understand it the 
>  experience was better before Pagure and people were able to do more 
>  self servicing. I believe that there is an alternative to having the 
>  packager workflow tightly coupled to the git forge, this is also maybe 
>  a good opportunity to rethink some of that workflow and explore 
>  different solutions.
>
>
>      That does *not* mean that CPE team should be the sole owner of the
>      Pagure *codebase*. On that point, I agree. And that's why I've spent a
>      lot of time and energy since late 2018 working on building up that
>      community. It's finally starting to bear fruit too: there's at least
>      one entity interested in building a product around it and contributing
>      to help support that product, there's the FSF preparing to launch a
>      new forge using Pagure, there's the Trisquel GNU+Linux distribution
>      working on a Pagure deployment to host their code and packaging, and
>      there's a few other things I've got up my sleeve to help broaden the
>      community with not just users, but also contributors.
>
>      Are there deficiencies in Pagure? Of course there are. I'm not
>      claiming that Pagure is perfect. But I think that keeping on with
>      Pagure and giving that community an opportunity to close the gap on
>      needed features for Fedora/CentOS/Red Hat is the right way to go.
>      Right now, I don't *know* what the important gaps are. I can make some
>      guesses, but it'd be a lot better if we had a list of missing features
>      and their relative important and why. That would help focus
>      development to meet those needs.
>
>      The Fedora community itself has indicated that they want to keep on
>      with Pagure, and many Fedorans are Pythonistas, which means that
>      everyone can easily contribute to help make it better for everyone.
>
>
>  Genuine question, from the people that have participated in this 
>  thread, How many could dedicated couple hours a week to work on Pagure 
>  ? I think many community member are already struggling to keep up with 
>  their current level of contribution, I am not sure than everyone can 
>  easily contribute to Pagure. But I am happy to wrong :-). 
If I knew the alternative was Gitlab SAAS, then I would have gladly 
spent a few hours per week helping with Pagure (or some other 
self-hosted git forge). Alas, that ship has apparently already sailed 
due to how the decision was made...


>      Anyway, I hope this helps clarify my position on the matter!
>
>
>      [1]:
>     
> https://lists.fedoraproject.org/archives/list/[e-mail].o...
>
>
>
>
>      -- 
>      真実はいつも一つ！/ Always, there's only one truth!
>      _______________________________________________
>      devel mailing list -- devel(a)lists.fedoraproject.org
>      <mailto:[e-mail]>
>      To unsubscribe send an email to
>      devel-leave(a)lists.fedoraproject.org
>      <mailto:[e-mail]>
>      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/[e-mail]
>
>
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]

[Vít Ondruch]

Dne 01. 04. 20 v 8:42 Clement Verna napsal(a):
>  On Tue, 31 Mar 2020 at 22:41, Robbie Harwood <rharwood(a)redhat.com
>  <mailto:[e-mail]>> wrote:
>
>      Clement Verna <cverna(a)fedoraproject.org
>      <mailto:[e-mail]>> writes:
>
>      > Neal Gompa <ngompa13(a)gmail.com <mailto:[e-mail]>> wrote:
>      >> Clement Verna <cverna(a)fedoraproject.org
>      <mailto:[e-mail]>> wrote:
>      >>
>      >> As for Pagure itself, I think this is where we fundamentally
>      >> disagree.  I think it behooves us to own and provide an experience
>      >> tailored for our community from beginning to end. That's why we
>      have
>      >> Koji, Bodhi, Dist-Git, and many other tools in that part of the
>      >> lifecycle. The packager experience is literally the lifeblood
>      of the
>      >> project, and our contributors are the core of what makes Fedora
>      >> successful. Pagure gives us an opportunity to do right by them
>      that I
>      >> *really* don't think we can do with any alternatives.
>      >
>      > I am not convinced that having a custom git forge is mandatory to
>      > provide an great experience to the community. I wasn't really around
>      > the community before Pagure, but I as far as I understand it the
>      > experience was better before Pagure and people were able to do more
>      > self servicing. I believe that there is an alternative to having the
>      > packager workflow tightly coupled to the git forge, this is also
>      maybe
>      > a good opportunity to rethink some of that workflow and explore
>      > different solutions.
>
>      Well, this continues to conflate "git forge" and "solution for
>      dist-git".
>
>
>  Yeah sorry I was not very clear, communication is hard and
>  communication via email is awfully hard. Personally I do not think
>  that git hosting is a problem. In today's world it is very easy to
>  find solution to host a project on a git forge and there are plenty of
>  solution available. Also I think it is important to note that the plan
>  is to keep pagure.io <http://pagure.io> running as long as there are
>  people willing to do the maintenance and based on that thread I don't
>  think that will be a problem.
>   
>
>
>      Before pagure, we had a (no-webui) git serving dist-git with other
>      services (e.g., pkgdb) stapled on.  More self-servicing was possible
>      because it was a more mature project.  In my opinion, the move to
>      pagure
>      happened prematurely due to lack of feature parity - a problem we're
>      still dealing with today, which I think is what your "self
>      servicing" is
>      in reference to.
>
>
>      Before pagure, we also had fedorahosted, which was our solution for
>      hosting projects, combining trac and a few other things. 
>      Migration was
>      *painful*, and there have been many rocky parts along the way, but the
>      experience now is definitely better than fedorahosted.  It's far less
>      pleasant than a github project, though.
>
>      My impression is that most folks on this thread are more worried about
>      dist-git and its integrations than a general git forge, while it feels
>      like all CPE wants to talk about is the git forge.  You can't just
>      use a
>      git forge as a dist-git: it takes a lot of integration work, which is
>      invisible because right now it's been done and just works™.  The
>      refusal
>      to consider that this work exists in the decision worries me .
>
>
>  I think this feeling comes from the mixing of git forge and dist-git
>  use case that you have pointed out. In CPE there is awareness of the
>  amount of work needed for migrating dist-git and all the integration
>  you are mentioning. My personal opinion is that this will not be a
>  small or easy project but I still think that this is worth it on the
>  long term. I also agree with what Kevin Fenzi said earlier in this
>  thread that we should take the time to rethink that integration layer
>  around dist-git and minimize the dependencies to the git hosting
>  solution, so that git hosting would simply be git hosting and it would
>  not really matter if this was done by Pagure, GitLab, or any other
>  solution. 

This was actually done when Pagure was introduces as a dist-git
frontend, because Pagure at that time was generic git hosting. Due to
that, we lost all the PkgDB functionality. As soon as the functionality
is almost back after more than two years, we are going to loose it
again. This is saddening.


Vít

[Julen Landa Alustiza]

20/4/1 08:42(e)an, Clement Verna igorleak idatzi zuen:
>  
>  
>  On Tue, 31 Mar 2020 at 22:41, Robbie Harwood <rharwood(a)redhat.com
>  <mailto:[e-mail]>> wrote:
>  
>      Clement Verna <cverna(a)fedoraproject.org
>      <mailto:[e-mail]>> writes:
>  
>      > Neal Gompa <ngompa13(a)gmail.com <mailto:[e-mail]>> wrote:
>      >> Clement Verna <cverna(a)fedoraproject.org
>      <mailto:[e-mail]>> wrote:
>      >>
>      >> As for Pagure itself, I think this is where we fundamentally
>      >> disagree.  I think it behooves us to own and provide an experience
>      >> tailored for our community from beginning to end. That's why we have
>      >> Koji, Bodhi, Dist-Git, and many other tools in that part of the
>      >> lifecycle. The packager experience is literally the lifeblood of the
>      >> project, and our contributors are the core of what makes Fedora
>      >> successful. Pagure gives us an opportunity to do right by them that I
>      >> *really* don't think we can do with any alternatives.
>      >
>      > I am not convinced that having a custom git forge is mandatory to
>      > provide an great experience to the community. I wasn't really around
>      > the community before Pagure, but I as far as I understand it the
>      > experience was better before Pagure and people were able to do more
>      > self servicing. I believe that there is an alternative to having the
>      > packager workflow tightly coupled to the git forge, this is also maybe
>      > a good opportunity to rethink some of that workflow and explore
>      > different solutions.
>  
>      Well, this continues to conflate "git forge" and "solution for
>      dist-git".
>  
>  
>  Yeah sorry I was not very clear, communication is hard and communication
>  via email is awfully hard. Personally I do not think that git hosting is
>  a problem. In today's world it is very easy to find solution to host a
>  project on a git forge and there are plenty of solution available. Also
>  I think it is important to note that the plan is to keep pagure.io
>  <http://pagure.io> running as long as there are people willing to do the
>  maintenance and based on that thread I don't think that will be a problem.
>   
>  
>  
>      Before pagure, we had a (no-webui) git serving dist-git with other
>      services (e.g., pkgdb) stapled on.  More self-servicing was possible
>      because it was a more mature project.  In my opinion, the move to pagure
>      happened prematurely due to lack of feature parity - a problem we're
>      still dealing with today, which I think is what your "self servicing" is
>      in reference to.
>  
>  
>      Before pagure, we also had fedorahosted, which was our solution for
>      hosting projects, combining trac and a few other things.  Migration was
>      *painful*, and there have been many rocky parts along the way, but the
>      experience now is definitely better than fedorahosted.  It's far less
>      pleasant than a github project, though.
>  
>      My impression is that most folks on this thread are more worried about
>      dist-git and its integrations than a general git forge, while it feels
>      like all CPE wants to talk about is the git forge.  You can't just use a
>      git forge as a dist-git: it takes a lot of integration work, which is
>      invisible because right now it's been done and just works™.  The refusal
>      to consider that this work exists in the decision worries me .
>  
>  
>  I think this feeling comes from the mixing of git forge and dist-git use
>  case that you have pointed out. In CPE there is awareness of the amount
>  of work needed for migrating dist-git and all the integration you are
>  mentioning. My personal opinion is that this will not be a small or easy
>  project but I still think that this is worth it on the long term. I also
>  agree with what Kevin Fenzi said earlier in this thread that we should
>  take the time to rethink that integration layer around dist-git and
>  minimize the dependencies to the git hosting solution, so that git
>  hosting would simply be git hosting and it would not really matter if
>  this was done by Pagure, GitLab, or any other solution. 
I agree with you that this is something to explore and rethink, but I
wonder if the result won't be better if all that rethinking and
redesigning process would be done together and with participation of
*all* the community and looking for the best solution. Now we
autolimited the possibilities, part of the community already chose a
path to go forward for all the community, the rethinking and redesigning
proccess is tied to and limited by that decision.
>   
>  
>  
>      So long as it's open and we host it, I don't personally care what we
>      choose - as long as we can actually use it.
>  
>      Thanks,
>      --Robbie
>  
>  
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>   
-- 
Julen Landa Alustiza <jlanda(a)fedoraproject.org&gt;

[Panu Matilainen]

On 3/31/20 8:44 PM, Adam Williamson wrote:

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

As a user, I wont be shedding a single tear for GitLab over Pagure, BUT.

There's something very wrong with the picture here, and this forge 
business seems more like an abscess that finally burst rather than the 
disease itself. I really do not envy being in CPE's pants in this situation.

If the problem is lack of funding for Fedora infastructure, shouldn't we 
talking about that (finding additional sponsors or something) instead of 
which limb to saw off to ensure enough blood for the remaining organs?

	- Panu -

[Clement Verna]

On Wed, 1 Apr 2020 at 09:34, Julen Landa Alustiza <jlanda(a)fedoraproject.org&gt;
wrote:

>  20/4/1 08:42(e)an, Clement Verna igorleak idatzi zuen:
>  >
>  >
>  > On Tue, 31 Mar 2020 at 22:41, Robbie Harwood <rharwood(a)redhat.com
>  > <mailto:[e-mail]>> wrote:
>  >
>  >     Clement Verna <cverna(a)fedoraproject.org
>  >     <mailto:[e-mail]>> writes:
>  >
>  >     > Neal Gompa <ngompa13(a)gmail.com <mailto:[e-mail]>>
> wrote:
>  >     >> Clement Verna <cverna(a)fedoraproject.org
>  >     <mailto:[e-mail]>> wrote:
>  >     >>
>  >     >> As for Pagure itself, I think this is where we fundamentally
>  >     >> disagree.  I think it behooves us to own and provide an experience
>  >     >> tailored for our community from beginning to end. That's why we
>  have
>  >     >> Koji, Bodhi, Dist-Git, and many other tools in that part of the
>  >     >> lifecycle. The packager experience is literally the lifeblood of
>  the
>  >     >> project, and our contributors are the core of what makes Fedora
>  >     >> successful. Pagure gives us an opportunity to do right by them
>  that I
>  >     >> *really* don't think we can do with any alternatives.
>  >     >
>  >     > I am not convinced that having a custom git forge is mandatory to
>  >     > provide an great experience to the community. I wasn't really
>  around
>  >     > the community before Pagure, but I as far as I understand it the
>  >     > experience was better before Pagure and people were able to do more
>  >     > self servicing. I believe that there is an alternative to having
>  the
>  >     > packager workflow tightly coupled to the git forge, this is also
>  maybe
>  >     > a good opportunity to rethink some of that workflow and explore
>  >     > different solutions.
>  >
>  >     Well, this continues to conflate "git forge" and "solution for
>  >     dist-git".
>  >
>  >
>  > Yeah sorry I was not very clear, communication is hard and communication
>  > via email is awfully hard. Personally I do not think that git hosting is
>  > a problem. In today's world it is very easy to find solution to host a
>  > project on a git forge and there are plenty of solution available. Also
>  > I think it is important to note that the plan is to keep pagure.io
>  > <http://pagure.io> running as long as there are people willing to do the
>  > maintenance and based on that thread I don't think that will be a
>  problem.
>  >
>  >
>  >
>  >     Before pagure, we had a (no-webui) git serving dist-git with other
>  >     services (e.g., pkgdb) stapled on.  More self-servicing was possible
>  >     because it was a more mature project.  In my opinion, the move to
>  pagure
>  >     happened prematurely due to lack of feature parity - a problem we're
>  >     still dealing with today, which I think is what your "self
>  servicing" is
>  >     in reference to.
>  >
>  >
>  >     Before pagure, we also had fedorahosted, which was our solution for
>  >     hosting projects, combining trac and a few other things.  Migration
>  was
>  >     *painful*, and there have been many rocky parts along the way, but
>  the
>  >     experience now is definitely better than fedorahosted.  It's far less
>  >     pleasant than a github project, though.
>  >
>  >     My impression is that most folks on this thread are more worried
>  about
>  >     dist-git and its integrations than a general git forge, while it
>  feels
>  >     like all CPE wants to talk about is the git forge.  You can't just
>  use a
>  >     git forge as a dist-git: it takes a lot of integration work, which is
>  >     invisible because right now it's been done and just works™.  The
>  refusal
>  >     to consider that this work exists in the decision worries me .
>  >
>  >
>  > I think this feeling comes from the mixing of git forge and dist-git use
>  > case that you have pointed out. In CPE there is awareness of the amount
>  > of work needed for migrating dist-git and all the integration you are
>  > mentioning. My personal opinion is that this will not be a small or easy
>  > project but I still think that this is worth it on the long term. I also
>  > agree with what Kevin Fenzi said earlier in this thread that we should
>  > take the time to rethink that integration layer around dist-git and
>  > minimize the dependencies to the git hosting solution, so that git
>  > hosting would simply be git hosting and it would not really matter if
>  > this was done by Pagure, GitLab, or any other solution.
>
>  I agree with you that this is something to explore and rethink, but I
>  wonder if the result won't be better if all that rethinking and
>  redesigning process would be done together and with participation of
>  *all* the community and looking for the best solution. 

Yes I think this is the plan, I don't believe that this would be done in a
silo within CPE. I am pretty sure that if this the way forward we (as
Fedora) want to explore this will involve a lot of iteration and
solicitation for contribution and feedback.


>  Now we
>  autolimited the possibilities, part of the community already chose a
>  path to go forward for all the community, the rethinking and redesigning
>  proccess is tied to and limited by that decision.
>  
Indeed I think this is fair for the people that are involved in that work
to make the decision. I recognized that the communication and the
transparency of the decision has not been good, but I still think that
making a decision was a good thing.


>  >
>  >
>  >
>  >     So long as it's open and we host it, I don't personally care what we
>  >     choose - as long as we can actually use it.
>  >
>  >     Thanks,
>  >     --Robbie
>  >
>  >
>  > _______________________________________________
>  > devel mailing list -- devel(a)lists.fedoraproject.org
>  > To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  >
>
>  --
>  Julen Landa Alustiza <jlanda(a)fedoraproject.org&gt;
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>

[Michal Konecny]

On 31/03/2020 20:53, Kevin Fenzi wrote:
>  On Tue, Mar 31, 2020 at 12:40:55PM -0500, Bruno Wolff III wrote:
>  ...snip...
> > Because of switching costs, this is likely to prevent us from going back to
> > Pagure if it does develop a vibrant independent community. That would be
> > unfortunate.
>  So, currently we are using pagure on src.fedoraproject.org, but it's not
>  just pagure, it's a integration layer over the top of pagure too.
>
>  I'd like to see if we can, as part of this: a) adjust our packaging
>  workflow (as many threads on this list have talked about) and b) after
>  that, try and reduce that integration layer as much as we can and c)
>  hopefully make it so we could move the backend git repos / forge later
>  if we wanted to without recreating a big integration layer. 
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?

If yes, than I'm into this and it doesn't matter for me where the 
packages are hosted anymore.

Michal
>  As part of that we could also provide whats needed for the integration
>  and the pagure community could add anything they don't already have on
>  their roadmap.
>
>  kevin
>
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail] 
-- 
Role: Fedora CPE Team - Software Engineer
IRC: mkonecny
FAS: zlopez

[Vít Ondruch]

Dne 01. 04. 20 v 10:37 Michal Konecny napsal(a):
>  On 31/03/2020 20:53, Kevin Fenzi wrote:
> > On Tue, Mar 31, 2020 at 12:40:55PM -0500, Bruno Wolff III wrote:
> > ...snip...
> >> Because of switching costs, this is likely to prevent us from going back to
> >> Pagure if it does develop a vibrant independent community. That would be
> >> unfortunate.
> > So, currently we are using pagure on src.fedoraproject.org, but it's not
> > just pagure, it's a integration layer over the top of pagure too. 
> >
> > I'd like to see if we can, as part of this: a) adjust our packaging
> > workflow (as many threads on this list have talked about) and b) after
> > that, try and reduce that integration layer as much as we can and c)
> > hopefully make it so we could move the backend git repos / forge later
> > if we wanted to without recreating a big integration layer.
>  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/ ? :)


Vít


>  If yes, than I'm into this and it doesn't matter for me where the
>  packages are hosted anymore.
>
>  Michal
> > As part of that we could also provide whats needed for the integration
> > and the pagure community could add anything they don't already have on
> > their roadmap. 
> >
> > kevin 
> >
> > _______________________________________________
> > devel mailing list -- devel(a)lists.fedoraproject.org
> > To unsubscribe send an email to devel-leave(a)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/[e-mail]
>
>  -- 
>  Role: Fedora CPE Team - Software Engineer
>  IRC: mkonecny
>  FAS: zlopez
>
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]

[Clement Verna]

On Wed, 1 Apr 2020 at 09:47, Panu Matilainen <pmatilai(a)redhat.com&gt; wrote:

>  On 3/31/20 8:44 PM, Adam Williamson wrote:
>
>  > I understand there are practical resource considerations and so on
>  > here, but I still think this merits more high level and serious
>  > consideration. At the very least, if we have somehow reached a point
>  > where Red Hat is no longer willing to provide sufficient resources to
>  > run Fedora on the lines the Fedora community wants it to be run, we
>  > need to recognize that this is a significant problem that needs to be
>  > properly aired and discussed and resolved. In this context I'll note
>  > that the apparent significant headcount reduction of RH people working
>  > on Fedora infrastructure over the last few years is in itself a
>  > worrying trend, particularly if you consider it while reading Clement's
>  > email.
>
>  This.
>  
I don't think this is correct, at least not in CPE, the team has grown over
the past year and every person leaving the team has been replaced (even by
2 persons in some cases). The problem in my opinion is that a lot of the
people that have setup and written the original services and applications
are gone, taking with them most of the knowledge about How, What and Why
something was done this way. That leaves people in the team now with a big
amount of legacy applications to take care of and not much clue of what is
going on.
There is also an historical taste to write in house applications for things
that don't really seems critical to the Fedora Project, for example do we
really need a custom calendar application ? or election application ? It
seems that every time we have a problem the solution is let's write
something to solve that problem, instead of trying to find a compromise and
reuse existing solutions.

Now when the CPE team goes and ask for more people because we struggle with
current situation, I can only guess that these non critical applications
are mentioned. If I was putting my own money to sponsor a team to help
building a Linux distribution I would be asking why do we have to develop a
calendar application or why do we need a custom git forge. I personally
find really great that the different use cases and requirements for the use
of Pagure were gathered and I am convinced that people working on this did
their very best to find a use case to justify the investment needed in
Pagure but it seems that we don't have such a thing.

I also appreciate that as a community developing our own solutions is
something important and something that seems to matter a lot, but we have
to realize that the development and maintenance effort cannot be carried
out by the CPE team any more. Maybe this is a opportunity to create a SIG
or a working group for people that are interested to carry on this effort.

Finally, I would like to make clear that I am not blaming anyone, and that
decisions made in the past, I am sure were taken with the best intentions.
But I think it is also important to recognize that it is legitimate to
question these decisions today as something that made sense 10 years ago or
5 years ago might not make sense in today's context.

Disclaimer: I actually have very little insight on how the CPE team budget
and headcount is defined, I can only image that if this was my own money
this is the type of conversation I would have. Within the team, I think
there is a general agreement that we are running and developing to many
applications and the effort to slim down that footprint lead us naturally
to services that appeared less critical (fedocal, election, etc ..) or
easier to replace (Pagure).



>  As a user, I wont be shedding a single tear for GitLab over Pagure, BUT.
>
>  There's something very wrong with the picture here, and this forge
>  business seems more like an abscess that finally burst rather than the
>  disease itself. I really do not envy being in CPE's pants in this
>  situation.
>
>  If the problem is lack of funding for Fedora infastructure, shouldn't we
>  talking about that (finding additional sponsors or something) instead of
>  which limb to saw off to ensure enough blood for the remaining organs?
>
>          - Panu -
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>

[clime]

On Wed, 1 Apr 2020 at 10:54, Vít Ondruch <vondruch(a)redhat.com&gt; wrote:
>  Dne 01. 04. 20 v 10:37 Michal Konecny napsal(a):
>
>
>
>  On 31/03/2020 20:53, Kevin Fenzi wrote:
>
>  On Tue, Mar 31, 2020 at 12:40:55PM -0500, Bruno Wolff III wrote:
>  ...snip...
>
>  Because of switching costs, this is likely to prevent us from going back to
>  Pagure if it does develop a vibrant independent community. That would be
>  unfortunate.
>
>  So, currently we are using pagure on src.fedoraproject.org, but it's not
>  just pagure, it's a integration layer over the top of pagure too.
>
>  I'd like to see if we can, as part of this: a) adjust our packaging
>  workflow (as many threads on this list have talked about) and b) after
>  that, try and reduce that integration layer as much as we can and c)
>  hopefully make it so we could move the backend git repos / forge later
>  if we wanted to without recreating a big integration layer.
>
>  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/ ? :) 
This is just hilarious, so after going all pagure for dist-git and
making it all work, we will now go back to pkgdb, additionally with
proprietary git backend, lol.

I mean if there is some alien race (or a human competitor) watching
what is happening in one of the leading linux distributions, they must
laugh hard. Well, we soon won't be leading.

I mean modularity...then this craziness. Why we can't have a
consistent development line that leads to continual improvements in
our ecosystem?

There is no such line it seems. It's like a crazy zig-zag that doesn't
make any sense.

>
>
> Vít
>
>
>
> If yes, than I'm into this and it doesn't matter for me where the packages
are hosted anymore.
>
> Michal
>
> As part of that we could also provide whats needed for the integration
> and the pagure community could add anything they don't already have on
> their roadmap.
>
> kevin
>
>
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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/[e-mail]
>
>
> --
> Role: Fedora CPE Team - Software Engineer
> IRC: mkonecny
> FAS: zlopez
>
>
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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/[e-mail]
>
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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/[e-mail]

[Leigh Griffin]

On Tue, Mar 31, 2020 at 4:49 PM <jkonecny(a)redhat.com&gt; wrote:

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

We had awareness of other groups looking at Pagure and that was not a
factor in our decision as it is not a concrete commitment with respect to a
backlog of initiatives that would bridge a feature gap right now and in the
future. Nor would it have helped with the SLA requirements and operational
cost. It is heartwarming to see it get such attention though and it can
only be positive things for the growth of the Pagure Community.


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

-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford <https://www.redhat.com/>

Communications House

Cork Road, Waterford City

lgriffin(a)redhat.com
M: [phone]     IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>

[Leigh Griffin]

On Tue, Mar 31, 2020 at 6:32 PM Adam Williamson <adamwill(a)fedoraproject.org&gt;
wrote:

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

>  --
>  Adam Williamson
>  Fedora QA Community Monkey
>  IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
>  http://www.happyassassin.net
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  

-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford <https://www.redhat.com/>

Communications House

Cork Road, Waterford City

lgriffin(a)redhat.com
M: [phone]     IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>

[Panu Matilainen]

On 4/1/20 12:49 PM, Clement Verna wrote:
>  
>  
>  On Wed, 1 Apr 2020 at 09:47, Panu Matilainen <pmatilai(a)redhat.com 
>  <mailto:[e-mail]>> wrote:
>  
>      On 3/31/20 8:44 PM, Adam Williamson wrote:
>  
>       > I understand there are practical resource considerations and so on
>       > here, but I still think this merits more high level and serious
>       > consideration. At the very least, if we have somehow reached a point
>       > where Red Hat is no longer willing to provide sufficient resources to
>       > run Fedora on the lines the Fedora community wants it to be run, we
>       > need to recognize that this is a significant problem that needs to be
>       > properly aired and discussed and resolved. In this context I'll note
>       > that the apparent significant headcount reduction of RH people
>      working
>       > on Fedora infrastructure over the last few years is in itself a
>       > worrying trend, particularly if you consider it while reading
>      Clement's
>       > email.
>  
>      This.
>  
>  
>  I don't think this is correct, at least not in CPE, the team has grown 
>  over the past year and every person leaving the team has been replaced 
>  (even by 2 persons in some cases). The problem in my opinion is that a 
>  lot of the people that have setup and written the original services and 
>  applications are gone, taking with them most of the knowledge about How, 
>  What and Why something was done this way. That leaves people in the team 
>  now with a big amount of legacy applications to take care of and not 
>  much clue of what is going on.
>  There is also an historical taste to write in house applications for 
>  things that don't really seems critical to the Fedora Project, for 
>  example do we really need a custom calendar application ? or election 
>  application ? It seems that every time we have a problem the solution is 
>  let's write something to solve that problem, instead of trying to find a 
>  compromise and reuse existing solutions.
>  
>  Now when the CPE team goes and ask for more people because we struggle 
>  with current situation, I can only guess that these non critical 
>  applications are mentioned. If I was putting my own money to sponsor a 
>  team to help building a Linux distribution I would be asking why do we 
>  have to develop a calendar application or why do we need a custom git 
>  forge. I personally find really great that the different use cases and 
>  requirements for the use of Pagure were gathered and I am convinced that 
>  people working on this did their very best to find a use case to justify 
>  the investment needed in Pagure but it seems that we don't have such a 
>  thing. 
Heh, I didn't even know about these calendar and election applications.
Of course, if you're running thin (on resources, whether human or 
otherwise) you start with cutting the excess of course. That is obvious.

>  
>  I also appreciate that as a community developing our own solutions is 
>  something important and something that seems to matter a lot, but we 
>  have to realize that the development and maintenance effort cannot be 
>  carried out by the CPE team any more. Maybe this is a opportunity to 
>  create a SIG or a working group for people that are interested to carry 
>  on this effort. 
But this is precisely at the heart of the problem: people feel they were 
not given an opportunity to lend a hand, and that now its too late 
because the messaging is that we go with GitLab, no matter what.

>  
>  Finally, I would like to make clear that I am not blaming anyone, and 
>  that decisions made in the past, I am sure were taken with the best 
>  intentions. But I think it is also important to recognize that it is 
>  legitimate to question these decisions today as something that made 
>  sense 10 years ago or 5 years ago might not make sense in today's context. 
Yes, world changes and past decisions need to be reviewed every now and 
then. However I believe with any changes it's paramount to understand 
and keep in mind the reasons behind the original decisions when 
re-evaluating.

I don't claim to have read anywhere near everything that's written on 
this topic, but at least in the blog entry I fail to see any mention of 
the original reasons to go with Pagure. I frankly didn't understand it 
back then (but didn't care too much), it's just that I find the lack of 
reference a bit alarming.

	- Panu -

[Leigh Griffin]

On Tue, Mar 31, 2020 at 7:44 PM Chris Murphy <lists(a)colorremedies.com&gt;
wrote:

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

There is no doubt that they are at risk. We cannot sustain the level of
commitment to the volume of projects we have. The lights on work for just
the Fedora side is consuming over 50% of our team. That's pure
firefighting, responding to tickets and fixing problems with very little
time to pay down some of the debt that is causing the problems in the first
place. The team is spread too thin on just the Fedora commitments before we
consider the fact the team has another distribution in CentOS under our
remit as well. The reality is that most applications are constantly under
risk, if a person goes on PTO or leaves the team / company, we lose domain
knowledge. This has happened in the past year and will happen in the
future. Part of how we are structuring our work is to reduce our overhead,
cross train the team, get smarter on what we invest our time and effort
into in order to provide real value, not fighting fires constantly. That
might sound alarmist, but it's the reality that the team are living day to
day.


>  Why can't half or even all of them be rolled up into
>  proprietary equivalents and handed off for some other company to
>  manage? What's next?
>
>  This is awkward, but not even 12 days ago the Council approved a new
>  vision statement:
>
>  The Fedora Project envisions a world where everyone benefits from free
>  and open source software built by inclusive, welcoming, and
>  open-minded communities.
>
>  I can't say for sure there is a conflict in the process used to arrive
>  at the decision, but I'm questioning whether there is incongruity, and
>  the nature of it.
>
>  --
>  Chris Murphy
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  

-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford <https://www.redhat.com/>

Communications House

Cork Road, Waterford City

lgriffin(a)redhat.com
M: [phone]     IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>

[Leigh Griffin]

On Tue, Mar 31, 2020 at 8:02 PM Chris Murphy <lists(a)colorremedies.com&gt;
wrote:

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

To distill it down:

- Gitlab has more features that are needed right now for our stakeholder
group
- Gitlab has an entire company dedicated to roadmap features, we do not.
- Gitlab has better resiliency and uptime, we offer an SLE on an app that
is not meeting our mission statement but is consuming a lot of our time
- Gitlab scales better, Pagure has scale issues
- CPE do not own an application that will consume 100% of our available
team capacity from here on in to bridge the gap, to keep the system stood
up, to move towards an SLA model and to keep apace with new innovations


>  That's what's not clear. And it's not fair to call
>  this mere disagreement, because the decision can't even be properly
>  absorbed. It is prima facie not an open or transparent process, yet is
>  being claimed to have been. That contradiction is not trust enhancing.
>
>
>
>  >>
>  >> On Mon, Mar 30, 2020 at 4:27 AM Iñaki Ucar <iucar(a)fedoraproject.org&gt;
>  wrote:
>  >> >
>  >> > I was referring to, and I was expecting, an open conversation about
>  >> > the User Story list, an open analysis of the requirements list. In
>  >> > other words:
>  >> >
>  >> > 1. Open conversation to gather requirements. Done.
>  >> > 2. Publication of User Story list.
>  >> > 3. Open conversation to discuss (2).
>  >> > 4. Publication of the final decision.
>  >> >
>  >> > I was expecting (3), and it's missing.
>  >>
>  >>
>  >> I concur, and don't think the missing piece has been adequately
>  >> addressed. There's a reason why there's bewilderment at the decision,
>  >> it's not ignorable.
>  >
>  >
>  > How would you like us to address it more clearly? Fedora has had the
>  publication of its User Story list, a threads worth of discussion on it
>  occured and it was submitted. As have other stakeholder groups. I think the
>  crux here is that we didn't publish the entire stakeholder User Stories for
>  dissemination to each individual stakeholder group. With each group valuing
>  something different, as is obvious from the discussion around individual
>  requirements that has occured in several threads here, we didn't feel the
>  value would have been there. That's on me for not looping the comms back in
>  and I apologise for that.
>  >
>  >>
>  >> Were there deliberations by CPE Team in between (2) and (4)?
>  >
>  > Yes, several hundred person hours worth of analysis, meetings and
>  dissecting the requirements.
>
>  It would be addressed more clearly by seeing the summary,
>  distillation, metric, method, by which those hundreds of hours were
>  turned into the decision.
>  
I have promised  several times that the feature gaps will land as a backlog
addition for Pagure and I can happily share out a matrix from a User Story
/ Feature perspective and additional comments. Stay tuned for that.

>  These entire threads are a verbose way of saying "show your work."
>
>  >
>  >>
>  >> Is there
>  >> a record of those deliberations?
>  >
>  >
>  > No, they were mostly video calls / in person meetings and the result is
>  the User Story list and decision document for sharing.
>
>  I think a summary of the first hour of these several hundred hours,
>  and the last hour, would be useful. There's no way to reconstruct
>  this? 

I mean if you want the summary of the first hour it was a strategy plan for
grouping the requirements and interviewing stakeholders / communicating
with our team on technical details. The last hour was the summary mail that
was sent out to communicate the decision.


>  Deliberative bodies should be keeping notes, summary of major
>  decisions, pros, cons, liabilities, prioritization of conflicting
>  requirements, what things are in and out of scope, etc. There must be
>  something to show.
>  
We have multiple documents with requirements, notes, matrixes, meeting
minutes which I'm happy to distill down and share out as indicated above.

>  --
>  Chris Murphy
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  

-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford <https://www.redhat.com/>

Communications House

Cork Road, Waterford City

lgriffin(a)redhat.com
M: [phone]     IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>

[Fabio Valentini]

On Wed, Apr 1, 2020 at 12:24 PM Leigh Griffin <lgriffin(a)redhat.com&gt; wrote:
>  On Tue, Mar 31, 2020 at 7:44 PM Chris Murphy <lists(a)colorremedies.com&gt; wrote:
> >
> > On Tue, Mar 31, 2020 at 11:45 AM Adam Williamson
> > <adamwill(a)fedoraproject.org&gt; wrote:
> > >
> > > On Tue, 2020-03-31 at 13:08 -0400, Matthew Miller wrote:
> > > > On Tue, Mar 31, 2020 at 10:48:55AM -0500, Michael Catanzaro wrote:
> > > > > Some failure of process or communication must have occurred
> > > > > somewhere along the lines, because open source should have been the
> > > > > first and most important requirement. A proprietary software
> > > > > solution is incompatible with the ethos and purpose of the Fedora
> > > > > project. I ask CPE to revise its requirements list to include open
> > > > > source as the first and most important requirement from the Fedora
> > > > > community. If that's incompatible with CentOS's need for
> merge
> > > > > request approvals or whatever else, then we need to accept that
> > > > > sharing the same forge is simply not going to work.
> > > >
> > > > Obviously open source is one of our key foundations. And it is part of who
> > > > we are even before those foundations were drafted. Nonetheless, I want to
> > > > gently discuss this a little bit. We make an entirely open source and free
> > > > software operating system. We support and promote and advocate for open
> > > > source and free content. But we can't do everything, and at some point,
> this
> > > > becomes "this is why we can't have nice things". I see that
> you've made
> > > > contributions to other open source projects on GitHub and (hosted) GitLab
> > > > this month. Lots of Fedora contributors have and will continue to do so.
> > > > Many use that as their main hosting. It's not ideal, but it's not
> the end of
> > > > the world. I don't see Fedora making use of non-open hosted services as
> the
> > > > end of the world either, if that is what is best for us.
> > > >
> > > > We did communicate as the very top line of our gathered requirements that
> > > > open source is essential to our community and central to our feedback.
> I'm
> > > > not trying to be soft on that. Let's just not do purity-test level
> > > > assessments and instead focus on our goals.
> > >
> > > I'm sorry, but I have to agree with Kevin and Michael here to a
> > > significant extent. Running our own project on open source code has
> > > always been a very big bright line for Fedora.
> > >
> > > I'm not necessarily saying it's a hill we should die on, but at the
> > > very least, choosing a proprietary hosted solution for something as
> > > fundamental as our dist-git needs to be treated as a Very Big Deal and
> > > needs to be a decision that is handled a *lot* better than this one has
> > > been handled.
> > >
> > > You said in another email that the tooling choice ultimately has to be
> > > largely made by the team that is responsible for the work and it
> > > wouldn't really work for Council to order them to do something they
> > > can't practically do, and I see the truth in that, but at the same time
> > > I think there has to be a balance there. Does this "the team decides
> > > what works for them" principle extend as far as the team being able to
> > > choose unilaterally to go against principles Fedora has been working
> > > very hard to maintain for about as long as it has existed, and that are
> > > listed right up there front and centre as our Foundations? That, to me,
> > > seems like a decision that Council ought at the very least to be deeply
> > > involved in - much more than seems to have been the case here (which
> > > seems to have been that we wrote up some requirements and sent them off
> > > to "the team", which smooshed them into some kind of summary and then
> > > made a decision - a decision which seems to have had a rather confused
> > > context, as various people don't seem to be on the same page about
> > > whether a choice was supposed to be made about "dist-git", or
> > > "pagure.io", or "Pagure", or CentOS's or Red Hat's
> use of Pagure, or
> > > any or all of these things somehow smooshed together).
> > >
> > > I think if I turned up tomorrow and said that QA had decided we're
> > > going to use a proprietary hosted service for managing release
> > > validation testing there would be significant pushback against that,
> > > and I think that pushback would be valid, and I'm not sure it would be
> > > appropriate for us to say "tough, we made that decision so that's
> > > what's happening". I don't think it's necessarily appropriate
> for that
> > > to happen here either.
> > >
> > > I understand there are practical resource considerations and so on
> > > here, but I still think this merits more high level and serious
> > > consideration. At the very least, if we have somehow reached a point
> > > where Red Hat is no longer willing to provide sufficient resources to
> > > run Fedora on the lines the Fedora community wants it to be run, we
> > > need to recognize that this is a significant problem that needs to be
> > > properly aired and discussed and resolved. In this context I'll note
> > > that the apparent significant headcount reduction of RH people working
> > > on Fedora infrastructure over the last few years is in itself a
> > > worrying trend, particularly if you consider it while reading Clement's
> > > email.
> > >
> > > I think Iñaki's take on the "oh, you contribute to Github projects so
> > > no problem right?" angle is correct.
> >
> > I concur with this, in its entirety.
> >
> > Lack of resources might supercede an open source requirement. But if
> > that is really the choice, that itself exposes a far bigger problem:
> > all other projects being maintained by CPE and Fedora Infrastructure
> > team are at risk.
>
>
>  There is no doubt that they are at risk. We cannot sustain the level of commitment to the
> volume of projects we have. The lights on work for just the Fedora side is consuming over
> 50% of our team. That's pure firefighting, responding to tickets and fixing problems
> with very little time to pay down some of the debt that is causing the problems in the
> first place. The team is spread too thin on just the Fedora commitments before we consider
> the fact the team has another distribution in CentOS under our remit as well. The reality
> is that most applications are constantly under risk, if a person goes on PTO or leaves the
> team / company, we lose domain knowledge. This has happened in the past year and will
> happen in the future. Part of how we are structuring our work is to reduce our overhead,
> cross train the team, get smarter on what we invest our time and effort into in order to
> provide real value, not fighting fires constantly. That might sound alarmist, but it's
> the reality that the team are living day to day. 

Would it be possible to publish the list of applications that the CPE
maintains / runs?
I think having that information might lead to a better conversation
around what services can be replaced and/or shut down. Right now, I
don't have the foggiest idea what 75% of those applications you run
actually are, which makes this discussion a bit hard.

Fabio

>
>
>>
>> Why can't half or even all of them be rolled up into
>> proprietary equivalents and handed off for some other company to
>> manage? What's next?
>>
>> This is awkward, but not even 12 days ago the Council approved a new
>> vision statement:
>>
>> The Fedora Project envisions a world where everyone benefits from free
>> and open source software built by inclusive, welcoming, and
>> open-minded communities.
>>
>> I can't say for sure there is a conflict in the process used to arrive
>> at the decision, but I'm questioning whether there is incongruity, and
>> the nature of it.
>>
>> --
>> Chris Murphy
>> _______________________________________________
>> devel mailing list -- devel(a)lists.fedoraproject.org
>> To unsubscribe send an email to devel-leave(a)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/[e-mail]
>
>
>
> --
>
> Leigh Griffin
>
> Engineering Manager
>
> Red Hat Waterford
>
> Communications House
>
> Cork Road, Waterford City
>
> lgriffin(a)redhat.com
> M: [phone]     IM: lgriffin
>
> @redhatjobs   redhatjobs @redhatjobs
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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/[e-mail]

[Miro Hrončok]

On 01. 04. 20 10:53, Vít Ondruch wrote:
>  
>  Dne 01. 04. 20 v 10:37 Michal Konecny napsal(a):
> >
> >
> > On 31/03/2020 20:53, Kevin Fenzi wrote:
> >> On Tue, Mar 31, 2020 at 12:40:55PM -0500, Bruno Wolff III wrote:
> >> ...snip...
> >>> Because of switching costs, this is likely to prevent us from going back to
> >>> Pagure if it does develop a vibrant independent community. That would be
> >>> unfortunate.
> >> So, currently we are using pagure on src.fedoraproject.org, but it's not
> >> just pagure, it's a integration layer over the top of pagure too.
> >>
> >> I'd like to see if we can, as part of this: a) adjust our packaging
> >> workflow (as many threads on this list have talked about) and b) after
> >> that, try and reduce that integration layer as much as we can and c)
> >> hopefully make it so we could move the backend git repos / forge later
> >> if we wanted to without recreating a big integration layer.
> > 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.)


-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Florian Weimer]

* Bruno Wolff, III:

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

  <https://bugzilla.redhat.com/show_bug.cgi?id=478886>

Thanks,
Florian

[Leigh Griffin]

On Wed, Apr 1, 2020 at 11:33 AM Fabio Valentini <decathorpe(a)gmail.com&gt;
wrote:

>  On Wed, Apr 1, 2020 at 12:24 PM Leigh Griffin
> <lgriffin(a)redhat.com&gt; wrote:
>  >
>  >
>  >
>  > On Tue, Mar 31, 2020 at 7:44 PM Chris Murphy <lists(a)colorremedies.com&gt;
>  wrote:
>  >>
>  >> On Tue, Mar 31, 2020 at 11:45 AM Adam Williamson
>  >> <adamwill(a)fedoraproject.org&gt; wrote:
>  >> >
>  >> > On Tue, 2020-03-31 at 13:08 -0400, Matthew Miller wrote:
>  >> > > On Tue, Mar 31, 2020 at 10:48:55AM -0500, Michael Catanzaro wrote:
>  >> > > > Some failure of process or communication must have occurred
>  >> > > > somewhere along the lines, because open source should have been
>  the
>  >> > > > first and most important requirement. A proprietary software
>  >> > > > solution is incompatible with the ethos and purpose of the
> Fedora
>  >> > > > project. I ask CPE to revise its requirements list to include
> open
>  >> > > > source as the first and most important requirement from the
> Fedora
>  >> > > > community. If that's incompatible with CentOS's need for
> merge
>  >> > > > request approvals or whatever else, then we need to accept that
>  >> > > > sharing the same forge is simply not going to work.
>  >> > >
>  >> > > Obviously open source is one of our key foundations. And it is part
>  of who
>  >> > > we are even before those foundations were drafted. Nonetheless, I
>  want to
>  >> > > gently discuss this a little bit. We make an entirely open source
>  and free
>  >> > > software operating system. We support and promote and advocate for
>  open
>  >> > > source and free content. But we can't do everything, and at some
>  point, this
>  >> > > becomes "this is why we can't have nice things". I see
> that you've
>  made
>  >> > > contributions to other open source projects on GitHub and (hosted)
>  GitLab
>  >> > > this month. Lots of Fedora contributors have and will continue to
>  do so.
>  >> > > Many use that as their main hosting. It's not ideal, but it's
> not
>  the end of
>  >> > > the world. I don't see Fedora making use of non-open hosted
>  services as the
>  >> > > end of the world either, if that is what is best for us.
>  >> > >
>  >> > > We did communicate as the very top line of our gathered
>  requirements that
>  >> > > open source is essential to our community and central to our
>  feedback. I'm
>  >> > > not trying to be soft on that. Let's just not do purity-test
> level
>  >> > > assessments and instead focus on our goals.
>  >> >
>  >> > I'm sorry, but I have to agree with Kevin and Michael here to a
>  >> > significant extent. Running our own project on open source code has
>  >> > always been a very big bright line for Fedora.
>  >> >
>  >> > I'm not necessarily saying it's a hill we should die on, but at
> the
>  >> > very least, choosing a proprietary hosted solution for something as
>  >> > fundamental as our dist-git needs to be treated as a Very Big Deal and
>  >> > needs to be a decision that is handled a *lot* better than this one
>  has
>  >> > been handled.
>  >> >
>  >> > You said in another email that the tooling choice ultimately has to be
>  >> > largely made by the team that is responsible for the work and it
>  >> > wouldn't really work for Council to order them to do something they
>  >> > can't practically do, and I see the truth in that, but at the same
>  time
>  >> > I think there has to be a balance there. Does this "the team decides
>  >> > what works for them" principle extend as far as the team being able
> to
>  >> > choose unilaterally to go against principles Fedora has been working
>  >> > very hard to maintain for about as long as it has existed, and that
>  are
>  >> > listed right up there front and centre as our Foundations? That, to
>  me,
>  >> > seems like a decision that Council ought at the very least to be
>  deeply
>  >> > involved in - much more than seems to have been the case here (which
>  >> > seems to have been that we wrote up some requirements and sent them
>  off
>  >> > to "the team", which smooshed them into some kind of summary and
> then
>  >> > made a decision - a decision which seems to have had a rather confused
>  >> > context, as various people don't seem to be on the same page about
>  >> > whether a choice was supposed to be made about "dist-git", or
>  >> > "pagure.io", or "Pagure", or CentOS's or Red
> Hat's use of Pagure, or
>  >> > any or all of these things somehow smooshed together).
>  >> >
>  >> > I think if I turned up tomorrow and said that QA had decided we're
>  >> > going to use a proprietary hosted service for managing release
>  >> > validation testing there would be significant pushback against that,
>  >> > and I think that pushback would be valid, and I'm not sure it would be
>  >> > appropriate for us to say "tough, we made that decision so that's
>  >> > what's happening". I don't think it's necessarily
> appropriate for that
>  >> > to happen here either.
>  >> >
>  >> > I understand there are practical resource considerations and so on
>  >> > here, but I still think this merits more high level and serious
>  >> > consideration. At the very least, if we have somehow reached a point
>  >> > where Red Hat is no longer willing to provide sufficient resources to
>  >> > run Fedora on the lines the Fedora community wants it to be run, we
>  >> > need to recognize that this is a significant problem that needs to be
>  >> > properly aired and discussed and resolved. In this context I'll note
>  >> > that the apparent significant headcount reduction of RH people working
>  >> > on Fedora infrastructure over the last few years is in itself a
>  >> > worrying trend, particularly if you consider it while reading
>  Clement's
>  >> > email.
>  >> >
>  >> > I think Iñaki's take on the "oh, you contribute to Github projects
> so
>  >> > no problem right?" angle is correct.
>  >>
>  >> I concur with this, in its entirety.
>  >>
>  >> Lack of resources might supercede an open source requirement. But if
>  >> that is really the choice, that itself exposes a far bigger problem:
>  >> all other projects being maintained by CPE and Fedora Infrastructure
>  >> team are at risk.
>  >
>  >
>  > There is no doubt that they are at risk. We cannot sustain the level of
>  commitment to the volume of projects we have. The lights on work for just
>  the Fedora side is consuming over 50% of our team. That's pure
>  firefighting, responding to tickets and fixing problems with very little
>  time to pay down some of the debt that is causing the problems in the first
>  place. The team is spread too thin on just the Fedora commitments before we
>  consider the fact the team has another distribution in CentOS under our
>  remit as well. The reality is that most applications are constantly under
>  risk, if a person goes on PTO or leaves the team / company, we lose domain
>  knowledge. This has happened in the past year and will happen in the
>  future. Part of how we are structuring our work is to reduce our overhead,
>  cross train the team, get smarter on what we invest our time and effort
>  into in order to provide real value, not fighting fires constantly. That
>  might sound alarmist, but it's the reality that the team are living day to
>  day.
>
>
>  Would it be possible to publish the list of applications that the CPE
>  maintains / runs?
>  
We are working on an updated list of those applications and should have it
with the community over the coming 2 weeks.


>  I think having that information might lead to a better conversation
>  around what services can be replaced and/or shut down. Right now, I
>  don't have the foggiest idea what 75% of those applications you run
>  actually are, which makes this discussion a bit hard.
>
>  Fabio
>
>  >
>  >
>  >>
>  >> Why can't half or even all of them be rolled up into
>  >> proprietary equivalents and handed off for some other company to
>  >> manage? What's next?
>  >>
>  >> This is awkward, but not even 12 days ago the Council approved a new
>  >> vision statement:
>  >>
>  >> The Fedora Project envisions a world where everyone benefits from free
>  >> and open source software built by inclusive, welcoming, and
>  >> open-minded communities.
>  >>
>  >> I can't say for sure there is a conflict in the process used to arrive
>  >> at the decision, but I'm questioning whether there is incongruity, and
>  >> the nature of it.
>  >>
>  >> --
>  >> Chris Murphy
>  >> _______________________________________________
>  >> devel mailing list -- devel(a)lists.fedoraproject.org
>  >> To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  >
>  >
>  >
>  > --
>  >
>  > Leigh Griffin
>  >
>  > Engineering Manager
>  >
>  > Red Hat Waterford
>  >
>  > Communications House
>  >
>  > Cork Road, Waterford City
>  >
>  > lgriffin(a)redhat.com
>  > M: [phone]     IM: lgriffin
>  >
>  > @redhatjobs   redhatjobs @redhatjobs
>  > _______________________________________________
>  > devel mailing list -- devel(a)lists.fedoraproject.org
>  > To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  

-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford <https://www.redhat.com/>

Communications House

Cork Road, Waterford City

lgriffin(a)redhat.com
M: [phone]     IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>

[Nicolas Mailhot]

Le mercredi 01 avril 2020 à 11:30 +0100, Leigh Griffin a écrit :
>  
>  To distill it down:
>  
>  - Gitlab has more features that are needed right now for our
>  stakeholder group
>  - Gitlab has an entire company dedicated to roadmap features, we do
>  not. 
Unfortunately, Gitlab’s roadmap is also conflicting with Fedora
objectives. The bread and butter of Gitlab is intermediating between
devs and end users, culling free software intermediaries like
distributions, and positionning itself in their stead. That is unlikely
to result in any commitment to making distribution workflows work.

That would not be a problem if the disintermediation worked, but like
many actors Gitlab sees the $$$ and power in being the
desintermediator, and does not care if the result is deffective, as
long as $$$ and power flows its way.

At heart, Fedora is a tooling project. It’s a collective of people that
chose to use a specific integration toolchain. Anything involved in
creating Fedora packages cuts deep into the project core. (unlike, say,
calendaring).

It’s easy to forget this when making tooling decisions,
because it is so pervasive, most do not see it anymore. Tooling is
anything but accessory to the project.

Regards,

-- 
Nicolas Mailhot

[Neal Gompa]

On Wed, Apr 1, 2020 at 6:52 AM Nicolas Mailhot via devel
<devel(a)lists.fedoraproject.org&gt; wrote:
>  Le mercredi 01 avril 2020 à 11:30 +0100, Leigh Griffin a écrit :
>  >
>  > To distill it down:
>  >
>  > - Gitlab has more features that are needed right now for our
>  > stakeholder group
>  > - Gitlab has an entire company dedicated to roadmap features, we do
>  > not.
>
>  Unfortunately, Gitlab’s roadmap is also conflicting with Fedora
>  objectives. The bread and butter of Gitlab is intermediating between
>  devs and end users, culling free software intermediaries like
>  distributions, and positionning itself in their stead. That is unlikely
>  to result in any commitment to making distribution workflows work.
>
>  That would not be a problem if the disintermediation worked, but like
>  many actors Gitlab sees the $$$ and power in being the
>  desintermediator, and does not care if the result is deffective, as
>  long as $$$ and power flows its way.
>  
It's also important to note that at the core of GitLab's incentive
model is that they want to remove incentives to use FOSS solutions in
favor of their unified proprietary solution. They are constantly
integrating features and capabilities into the proprietary parts to
make it "juicier" for enterprises who don't really have a compunction
about whether they are using Free Software solutions or not, or even
may not be willing to support them if it was Free Software because of
outmoded thinking.

The consequence of this is that it starves interest and development in
FOSS solutions, and contributes to making the FOSS ecosystem weaker
over time.

It wouldn't surprise me if not many people at Red Hat sat down and
thought seriously about that particular consequence, because it's not
exactly an obvious one.

>  At heart, Fedora is a tooling project. It’s a collective of people
> that
>  chose to use a specific integration toolchain. Anything involved in
>  creating Fedora packages cuts deep into the project core. (unlike, say,
>  calendaring).
>
>  It’s easy to forget this when making tooling decisions,
>  because it is so pervasive, most do not see it anymore. Tooling is
>  anything but accessory to the project.
>  
Exactly. This is a huge part of why people are so upset over this,
because if you take away our tools, you take away the reason to be
passionate about Fedora. And thus, you remove why people use and
contribute to Fedora in the first place.



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Bruno Wolff III]

On Wed, Apr 01, 2020 at 12:39:21 +0200,
  Florian Weimer <fweimer(a)redhat.com&gt; wrote:
> * Bruno Wolff, III:
>
> > RHEL is a special case, as CENTOS provides a free drop in replacement
> > and switching from CENTOS to Fedora shouldn't be much work. Is there
> > other proprietary software at the OS level or above, that is used for
> > Fedora infrastructure?
>
> The Bugzilla fork running on bugzilla.redhat.com?
>
>   <https://bugzilla.redhat.com/show_bug.cgi?id=478886> 
That was an interesting read. It sounds like corners were cut under the 
assumption that there would be no desire to share the code. Specifically 
code and config were mixed together and the config can't be released.

[Jeff Fearn]

On 1/4/20 21:11, Bruno Wolff III wrote:
>  On Wed, Apr 01, 2020 at 12:39:21 +0200,
>   Florian Weimer <fweimer(a)redhat.com&gt; wrote:
> > * Bruno Wolff, III:
> >
> >> RHEL is a special case, as CENTOS provides a free drop in replacement
> >> and switching from CENTOS to Fedora shouldn't be much work. Is there
> >> other proprietary software at the OS level or above, that is used for
> >> Fedora infrastructure?
> >
> > The Bugzilla fork running on bugzilla.redhat.com?
> >
> >  <https://bugzilla.redhat.com/show_bug.cgi?id=478886>
>  
>  That was an interesting read. It sounds like corners were cut under the
>  assumption that there would be no desire to share the code. Specifically
>  code and config were mixed together and the config can't be released. 
A lot of time and effort was spent getting code audits done and fixing
the issues raised.

It's seriously depressing it still isn't public.

Jeff.

[Neal Gompa]

On Wed, Apr 1, 2020 at 7:47 AM Jeff Fearn <jfearn(a)redhat.com&gt; wrote:
>  On 1/4/20 21:11, Bruno Wolff III wrote:
>  > On Wed, Apr 01, 2020 at 12:39:21 +0200,
>  >  Florian Weimer <fweimer(a)redhat.com&gt; wrote:
>  >> * Bruno Wolff, III:
>  >>
>  >>> RHEL is a special case, as CENTOS provides a free drop in replacement
>  >>> and switching from CENTOS to Fedora shouldn't be much work. Is there
>  >>> other proprietary software at the OS level or above, that is used for
>  >>> Fedora infrastructure?
>  >>
>  >> The Bugzilla fork running on bugzilla.redhat.com?
>  >>
>  >>  <https://bugzilla.redhat.com/show_bug.cgi?id=478886>
>  >
>  > That was an interesting read. It sounds like corners were cut under the
>  > assumption that there would be no desire to share the code. Specifically
>  > code and config were mixed together and the config can't be released.
>
>  A lot of time and effort was spent getting code audits done and fixing
>  the issues raised.
>
>  It's seriously depressing it still isn't public.
>  
It'd be great if it was. There's some interest in SUSE and other
places of running an instance of the Red Hat Bugzilla code since it's
better suited for Linux distributions and has some really nice
features for supporting that.




--
真実はいつも一つ！/ Always, there's only one truth!

[Pierre-Yves Chibon]

On Wed, Apr 01, 2020 at 11:49:41AM +0200, Clement Verna wrote:
>     There is also an historical taste to write in house applications
> for
>     things that don't really seems critical to the Fedora Project, for example
>     do we really need a custom calendar application ? or election application
>     ? It seems that every time we have a problem the solution is let's write
>     something to solve that problem, instead of trying to find a compromise
>     and reuse existing solutions. 
Could please stop this?

The continuous theme of "we're building things because we like it" is unfair
to
all the people who have been involved in the infrastructure at some point in the
past.
It is assuming that there was no reasons, that they did not do their research,
that they didn't think it through.

The requirements for applications 3 years ago were vastly different from what
they are today.
If you don't know the historical reasons for an app, there are a number of
people around who can answer them, but please let's stop assuming things which
are at the end of the day insulting and demotivating for the people who were
involved then and are still now.

This goes for fedocal, for pagure, for anitya. I've seen this question come up
often enough (here and elsewhere): "Why aren't we using libraries.io instead of
anytia?"
Well, the simple reason is: because libraries.io *did* *not* *exist* when anitya
was created. So maybe we are not the bad ones that didn't do their research.


I am not saying that we can't re-evaluate these decision and see if they still
make sense, but please, please, can we stop assuming the worst?


>     Now when the CPE team goes and ask for more people because we
> struggle
>     with current situation, I can only guess that these non critical
>     applications are mentioned. If I was putting my own money to sponsor a
>     team to help building a Linux distribution I would be asking why do we
>     have to develop a calendar application or why do we need a custom git
>     forge.  
Here as well, what you believe CPE is meant to be is immensely different than
what the Fedora Infrastructure (Fedora Engineering) team was just a few years
ago.
So asking these questions and taking this angle may make sense with the new
vision but you would have a much different picture if you were looking at them
from the old vision, or the one before that, or the next one.

Let's be aware that Fedora Infra's job hasn't been "Building a linux
distro"
since it's inception, for a long time its goal was much closer to "building and
supporting the *community* that builds the linux distro".
If you use this mission statement, you can a much different look at badges,
elections or calendaring.



Piere

[Alex Scheel]

----- Original Message -----
>  From: "Panu Matilainen" <pmatilai(a)redhat.com&gt;
>  To: devel(a)lists.fedoraproject.org
>  Sent: Wednesday, April 1, 2020 6:22:39 AM
>  Subject: Re: CPE Git Forge Decision
>   
>  > I also appreciate that as a community developing our own
> solutions is
>  > something important and something that seems to matter a lot, but we
>  > have to realize that the development and maintenance effort cannot be
>  > carried out by the CPE team any more. Maybe this is a opportunity to
>  > create a SIG or a working group for people that are interested to carry
>  > on this effort.
>  
>  But this is precisely at the heart of the problem: people feel they were
>  not given an opportunity to lend a hand, and that now its too late
>  because the messaging is that we go with GitLab, no matter what. 
Pagure has huge developer experience bugs filed against it for many
years. Where have all these contributors been? Are those of us who really
dislike Pagure's workflows in the minority? Or are others more prone
to put up with it because it is free, open source software?


IMO, it seems like an ideological argument, not a sound technical
one.

- Alex

[Stephen John Smoogen]

On Wed, 1 Apr 2020 at 08:16, Pierre-Yves Chibon <pingou(a)pingoured.fr&gt; wrote:

>  On Wed, Apr 01, 2020 at 11:49:41AM +0200, Clement Verna wrote:
>  >    There is also an historical taste to write in house applications for
>  >    things that don't really seems critical to the Fedora Project, for
>  example
>  >    do we really need a custom calendar application ? or election
>  application
>  >    ? It seems that every time we have a problem the solution is let's
>  write
>  >    something to solve that problem, instead of trying to find a
>  compromise
>  >    and reuse existing solutions.
>
>  Could please stop this?
>
>  
This is me also asking this.



>  The continuous theme of "we're building things because we
> like it" is
>  unfair to
>  all the people who have been involved in the infrastructure at some point
>  in the
>  past.
>  It is assuming that there was no reasons, that they did not do their
>  research,
>  that they didn't think it through.
>
>  The requirements for applications 3 years ago were vastly different from
>  what
>  they are today.
>  If you don't know the historical reasons for an app, there are a number of
>  people around who can answer them, but please let's stop assuming things
>  which
>  are at the end of the day insulting and demotivating for the people who
>  were
>  involved then and are still now.
>
>  This goes for fedocal, for pagure, for anitya. I've seen this question
>  come up
>  often enough (here and elsewhere): "Why aren't we using libraries.io
>  instead of
>  anytia?"
>  Well, the simple reason is: because libraries.io *did* *not* *exist* when
>  anitya
>  was created. So maybe we are not the bad ones that didn't do their
>  research.
>
>  
I am also sick and tired of this. For many years, a central drive for
Fedora Infra was about building the Free and Open Source tools to allow a
community to work together without using closed source tools. This was a
constant requirement of the community to us at the time with wanting
something to 'compete' against Canonical's forge and Canonicals' other
tools. Things have changed but instead of saying "Good job, thanks for all
that work but we have decided to change.", our efforts are brought up
constantly as a bunch of NIH who wasted time and effort. And it doesn't
matter how many times people are reminded that we had reasons and research
for doing this from 2005 to 2015.. it gets thrown in our faces that we
reinvented the wheel when there were clearly better things to spend our
time on.



-- 
Stephen J Smoogen.

[Michal Konecny]

On 01/04/2020 10:53, Vít Ondruch wrote:
>  Dne 01. 04. 20 v 10:37 Michal Konecny napsal(a):
> >
> >
> > On 31/03/2020 20:53, Kevin Fenzi wrote:
> >> On Tue, Mar 31, 2020 at 12:40:55PM -0500, Bruno Wolff III wrote:
> >> ...snip...
> >>> Because of switching costs, this is likely to prevent us from going back to
> >>> Pagure if it does develop a vibrant independent community. That would be
> >>> unfortunate.
> >> So, currently we are using pagure on src.fedoraproject.org, but it's not
> >> just pagure, it's a integration layer over the top of pagure too.
> >>
> >> I'd like to see if we can, as part of this: a) adjust our packaging
> >> workflow (as many threads on this list have talked about) and b) after
> >> that, try and reduce that integration layer as much as we can and c)
> >> hopefully make it so we could move the backend git repos / forge later
> >> if we wanted to without recreating a big integration layer.
> > 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/ ? :)
>
>
>  Vít
>
>  
I meant something more user friendly, this is just an API, which is not 
easy to use for everyone.

Michal
> >
> > If yes, than I'm into this and it doesn't matter for me where the 
> > packages are hosted anymore.
> >
> > Michal
> >> As part of that we could also provide whats needed for the integration
> >> and the pagure community could add anything they don't already have on
> >> their roadmap.
> >>
> >> kevin
> >>
> >> _______________________________________________
> >> devel mailing list --devel(a)lists.fedoraproject.org
> >> To unsubscribe send an email todevel-leave(a)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/[e-mail]...
> >
> > -- 
> > Role: Fedora CPE Team - Software Engineer
> > IRC: mkonecny
> > FAS: zlopez
> >
> > _______________________________________________
> > devel mailing list --devel(a)lists.fedoraproject.org
> > To unsubscribe send an email todevel-leave(a)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/[e-mail]...
>
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail] 
-- 
Role: Fedora CPE Team - Software Engineer
IRC: mkonecny
FAS: zlopez

[Neal Gompa]

On Wed, Apr 1, 2020 at 8:34 AM Alex Scheel <ascheel(a)redhat.com&gt; wrote:
>  ----- Original Message -----
>  > From: "Panu Matilainen" <pmatilai(a)redhat.com&gt;
>  > To: devel(a)lists.fedoraproject.org
>  > Sent: Wednesday, April 1, 2020 6:22:39 AM
>  > Subject: Re: CPE Git Forge Decision
>  >
>
>  > > I also appreciate that as a community developing our own solutions is
>  > > something important and something that seems to matter a lot, but we
>  > > have to realize that the development and maintenance effort cannot be
>  > > carried out by the CPE team any more. Maybe this is a opportunity to
>  > > create a SIG or a working group for people that are interested to carry
>  > > on this effort.
>  >
>  > But this is precisely at the heart of the problem: people feel they were
>  > not given an opportunity to lend a hand, and that now its too late
>  > because the messaging is that we go with GitLab, no matter what.
>
>  Pagure has huge developer experience bugs filed against it for many
>  years. Where have all these contributors been? Are those of us who really
>  dislike Pagure's workflows in the minority? Or are others more prone
>  to put up with it because it is free, open source software?
>
>
>  IMO, it seems like an ideological argument, not a sound technical
>  one. 
Technical issues can always be resolved, ideological ones rarely so. I
would say it's a combination of disinterest in the issues you've
pointed out and general willingness to put up with bugs because it
aligns better with their philosophy.

Generally speaking, Pagure has served most of the workflows well for
package maintainers and has been a nice lightweight solution we can
easily extend for our needs. As a general forge, it has been somewhat
lacking because the principal interest (until *very* recently) has
been around using it as a dist-git system.

With the adoption of Pagure by parties who intend to use it more as a
general forge, I expect contributions to move towards improving this
aspect of the experience. It's not *bad* at being a general forge,
it's just not *as good* as proprietary alternatives yet. But ideology
+ technical capability + scratching itches is how most FOSS gets
better. If you don't have that, well... why bother?



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Clement Verna]

On Wed, 1 Apr 2020 at 14:16, Pierre-Yves Chibon <pingou(a)pingoured.fr&gt; wrote:

>  On Wed, Apr 01, 2020 at 11:49:41AM +0200, Clement Verna wrote:
>  >    There is also an historical taste to write in house applications for
>  >    things that don't really seems critical to the Fedora Project, for
>  example
>  >    do we really need a custom calendar application ? or election
>  application
>  >    ? It seems that every time we have a problem the solution is let's
>  write
>  >    something to solve that problem, instead of trying to find a
>  compromise
>  >    and reuse existing solutions.
>
>  Could please stop this?
>  
>  The continuous theme of "we're building things because we
> like it" is
>  unfair to
>  all the people who have been involved in the infrastructure at some point
>  in the
>  past.
>  It is assuming that there was no reasons, that they did not do their
>  research,
>  that they didn't think it through.
>
>  The requirements for applications 3 years ago were vastly different from
>  what
>  they are today.
>  If you don't know the historical reasons for an app, there are a number of
>  people around who can answer them, but please let's stop assuming things
>  which
>  are at the end of the day insulting and demotivating for the people who
>  were
>  involved then and are still now.
>
>  This goes for fedocal, for pagure, for anitya. I've seen this question
>  come up
>  often enough (here and elsewhere): "Why aren't we using libraries.io
>  instead of
>  anytia?"
>  Well, the simple reason is: because libraries.io *did* *not* *exist* when
>  anitya
>  was created. So maybe we are not the bad ones that didn't do their
>  research.
>
>
>  I am not saying that we can't re-evaluate these decision and see if they
>  still
>  make sense, but please, please, can we stop assuming the worst?
>
>  
I apologize if that came down that way but this is exactly what I was
trying to say at the end of my email (see below since it was cut here) . I
am 100% sure that decision taken in the past were the best decision at that
time and I am honestly not in position to judge or to say anything about
it.

"
Finally, I would like to make clear that I am not blaming anyone, and that
decisions made in the past, I am sure were taken with the best intentions.
But I think it is also important to recognize that it is legitimate to
question these decisions today as something that made sense 10 years ago or
5 years ago might not make sense in today's context.
"

>  >    Now when the CPE team goes and ask for more people because we struggle
>  >    with current situation, I can only guess that these non critical
>  >    applications are mentioned. If I was putting my own money to sponsor a
>  >    team to help building a Linux distribution I would be asking why do we
>  >    have to develop a calendar application or why do we need a custom git
>  >    forge.
>
>  Here as well, what you believe CPE is meant to be is immensely different
>  than
>  what the Fedora Infrastructure (Fedora Engineering) team was just a few
>  years
>  ago.
>  So asking these questions and taking this angle may make sense with the new
>  vision but you would have a much different picture if you were looking at
>  them
>  from the old vision, or the one before that, or the next one.
>
>  Let's be aware that Fedora Infra's job hasn't been "Building a linux
>  distro"
>  since it's inception, for a long time its goal was much closer to
>  "building and
>  supporting the *community* that builds the linux distro".
>  If you use this mission statement, you can a much different look at badges,
>  elections or calendaring.
>  
Yeah again agree with that, and I think this is what I was trying to say by
mentioning that we should look at these with today's context in mind. Again
sorry if I failed to express that point clearly.


>  Piere
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>

[Clement Verna]

On Wed, 1 Apr 2020 at 14:40, Stephen John Smoogen <smooge(a)gmail.com&gt; wrote:

>  On Wed, 1 Apr 2020 at 08:16, Pierre-Yves Chibon <pingou(a)pingoured.fr&gt;
>  wrote:
>
> > On Wed, Apr 01, 2020 at 11:49:41AM +0200, Clement Verna wrote:
> > >    There is also an historical taste to write in house applications for
> > >    things that don't really seems critical to the Fedora Project, for
> > example
> > >    do we really need a custom calendar application ? or election
> > application
> > >    ? It seems that every time we have a problem the solution is let's
> > write
> > >    something to solve that problem, instead of trying to find a
> > compromise
> > >    and reuse existing solutions.
> >
> > Could please stop this?
> >
> >
>  This is me also asking this.
>
>
>
> > The continuous theme of "we're building things because we like it" is
> > unfair to
> > all the people who have been involved in the infrastructure at some point
> > in the
> > past.
> > It is assuming that there was no reasons, that they did not do their
> > research,
> > that they didn't think it through.
> >
> > The requirements for applications 3 years ago were vastly different from
> > what
> > they are today.
> > If you don't know the historical reasons for an app, there are a number of
> > people around who can answer them, but please let's stop assuming things
> > which
> > are at the end of the day insulting and demotivating for the people who
> > were
> > involved then and are still now.
> >
> > This goes for fedocal, for pagure, for anitya. I've seen this question
> > come up
> > often enough (here and elsewhere): "Why aren't we using libraries.io
> > instead of
> > anytia?"
> > Well, the simple reason is: because libraries.io *did* *not* *exist*
> > when anitya
> > was created. So maybe we are not the bad ones that didn't do their
> > research.
> >
> >
>  I am also sick and tired of this. For many years, a central drive for
>  Fedora Infra was about building the Free and Open Source tools to allow a
>  community to work together without using closed source tools. This was a
>  constant requirement of the community to us at the time with wanting
>  something to 'compete' against Canonical's forge and Canonicals' other
>  tools. Things have changed but instead of saying "Good job, thanks for all
>  that work but we have decided to change.", our efforts are brought up
>  constantly as a bunch of NIH who wasted time and effort. And it doesn't
>  matter how many times people are reminded that we had reasons and research
>  for doing this from 2005 to 2015.. it gets thrown in our faces that we
>  reinvented the wheel when there were clearly better things to spend our
>  time on.
>
>  
Ok fair and thanks for pointing and raising that point. It is also good to
share that historical context to people like me that where not around
during that time. Again apologies, this was not at all my intention to
point fingers at people.

What does NIH stands for ?


>  --
>  Stephen J Smoogen.
>
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>

[Vít Ondruch]

Dne 01. 04. 20 v 14:41 Michal Konecny napsal(a):
>  On 01/04/2020 10:53, Vít Ondruch wrote:
> >
> >
> > Dne 01. 04. 20 v 10:37 Michal Konecny napsal(a):
> >>
> >>
> >> On 31/03/2020 20:53, Kevin Fenzi wrote:
> >>> On Tue, Mar 31, 2020 at 12:40:55PM -0500, Bruno Wolff III wrote:
> >>> ...snip...
> >>>> Because of switching costs, this is likely to prevent us from going back
> to
> >>>> Pagure if it does develop a vibrant independent community. That would be
> >>>> unfortunate.
> >>> So, currently we are using pagure on src.fedoraproject.org, but it's not
> >>> just pagure, it's a integration layer over the top of pagure too. 
> >>>
> >>> I'd like to see if we can, as part of this: a) adjust our packaging
> >>> workflow (as many threads on this list have talked about) and b) after
> >>> that, try and reduce that integration layer as much as we can and c)
> >>> hopefully make it so we could move the backend git repos / forge later
> >>> if we wanted to without recreating a big integration layer.
> >> 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/ ? :)
> >
> >
> > Vít
> >
> >
>  I meant something more user friendly, this is just an API 

Don't be mistaken, this is not just API but full fledged web app with UI.


>  , which is not easy to use for everyone. 

This is of course always questionable :)


Vít


>  Michal
> >
> >>
> >> If yes, than I'm into this and it doesn't matter for me where the
> >> packages are hosted anymore.
> >>
> >> Michal
> >>> As part of that we could also provide whats needed for the integration
> >>> and the pagure community could add anything they don't already have on
> >>> their roadmap. 
> >>>
> >>> kevin 
> >>>
> >>> _______________________________________________
> >>> devel mailing list -- devel(a)lists.fedoraproject.org
> >>> To unsubscribe send an email to devel-leave(a)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/[e-mail]
> >>
> >> -- 
> >> Role: Fedora CPE Team - Software Engineer
> >> IRC: mkonecny
> >> FAS: zlopez
> >>
> >> _______________________________________________
> >> devel mailing list -- devel(a)lists.fedoraproject.org
> >> To unsubscribe send an email to devel-leave(a)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/[e-mail]
> >
> > _______________________________________________
> > devel mailing list -- devel(a)lists.fedoraproject.org
> > To unsubscribe send an email to devel-leave(a)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/[e-mail]
>
>  -- 
>  Role: Fedora CPE Team - Software Engineer
>  IRC: mkonecny
>  FAS: zlopez
>
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]

[Solomon Peachy]

On Wed, Apr 01, 2020 at 03:04:57PM +0200, Clement Verna wrote:
>  What does NIH stands for ? 
https://en.wikipedia.org/wiki/Not_invented_here

 - Solomon
-- 
Solomon Peachy			       pizza at shaftnet dot org
High Springs, FL                          ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.

[Emmanuel Seyman]

* Clement Verna [01/04/2020 15:04] :
>  What does NIH stands for ? 
Not invented here (see https://en.wikipedia.org/wiki/Not_invented_here
for the gory details)

Emmanuel

[Vít Ondruch]

Dne 01. 04. 20 v 12:37 Miro Hrončok napsal(a):
>  On 01. 04. 20 10:53, Vít Ondruch wrote:
> >
> > Dne 01. 04. 20 v 10:37 Michal Konecny napsal(a):
> >>
> >>
> >> On 31/03/2020 20:53, Kevin Fenzi wrote:
> >>> On Tue, Mar 31, 2020 at 12:40:55PM -0500, Bruno Wolff III wrote:
> >>> ...snip...
> >>>> Because of switching costs, this is likely to prevent us from
> >>>> going back to
> >>>> Pagure if it does develop a vibrant independent community. That
> >>>> would be
> >>>> unfortunate.
> >>> So, currently we are using pagure on src.fedoraproject.org, but
> >>> it's not
> >>> just pagure, it's a integration layer over the top of pagure too.
> >>>
> >>> I'd like to see if we can, as part of this: a) adjust our packaging
> >>> workflow (as many threads on this list have talked about) and b) after
> >>> that, try and reduce that integration layer as much as we can and c)
> >>> hopefully make it so we could move the backend git repos / forge later
> >>> if we wanted to without recreating a big integration layer.
> >> 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. 

I know, I mentioned PkdDB just half jokingly, because this is like
walking in circles ...


Vít


>  (Not sure if still, but it was the case around a year ago.)
>
>

[Vít Ondruch]

Dne 01. 04. 20 v 14:33 Alex Scheel napsal(a):
>  ----- Original Message -----
> > From: "Panu Matilainen" <pmatilai(a)redhat.com&gt;
> > To: devel(a)lists.fedoraproject.org
> > Sent: Wednesday, April 1, 2020 6:22:39 AM
> > Subject: Re: CPE Git Forge Decision
> >
> >> I also appreciate that as a community developing our own solutions is
> >> something important and something that seems to matter a lot, but we
> >> have to realize that the development and maintenance effort cannot be
> >> carried out by the CPE team any more. Maybe this is a opportunity to
> >> create a SIG or a working group for people that are interested to carry
> >> on this effort.
> > But this is precisely at the heart of the problem: people feel they were
> > not given an opportunity to lend a hand, and that now its too late
> > because the messaging is that we go with GitLab, no matter what.
>  Pagure has huge developer experience bugs filed against it for many
>  years. Where have all these contributors been? Are those of us who really
>  dislike Pagure's workflows in the minority? 

Since you are asking, for dist-git and for ticket tracking in Fedora,
Pagure is much better than what we ever had and with one exception (I am
missing easy access to history of a file), there is not missing anything
substantial.

OTOH, GitLab UI is overwhelming, much harder to navigate. And moreover,
we don't have it and it won't be free neither easy to have it.

I read your list on some other place, I don't say it is wrong, but it
seems you don't appreciate the step forward from CGit and frankly they
are more or less just paper cuts.


Vít


>   Or are others more prone
>  to put up with it because it is free, open source software?
>
>
>  IMO, it seems like an ideological argument, not a sound technical
>  one.
>
>  - Alex
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]

[Neal Gompa]

On Wed, Apr 1, 2020 at 9:26 AM Vít Ondruch <vondruch(a)redhat.com&gt; wrote:
>  Dne 01. 04. 20 v 14:33 Alex Scheel napsal(a):
>  > ----- Original Message -----
>  >> From: "Panu Matilainen" <pmatilai(a)redhat.com&gt;
>  >> To: devel(a)lists.fedoraproject.org
>  >> Sent: Wednesday, April 1, 2020 6:22:39 AM
>  >> Subject: Re: CPE Git Forge Decision
>  >>
>  >>> I also appreciate that as a community developing our own solutions is
>  >>> something important and something that seems to matter a lot, but we
>  >>> have to realize that the development and maintenance effort cannot be
>  >>> carried out by the CPE team any more. Maybe this is a opportunity to
>  >>> create a SIG or a working group for people that are interested to carry
>  >>> on this effort.
>  >> But this is precisely at the heart of the problem: people feel they were
>  >> not given an opportunity to lend a hand, and that now its too late
>  >> because the messaging is that we go with GitLab, no matter what.
>  > Pagure has huge developer experience bugs filed against it for many
>  > years. Where have all these contributors been? Are those of us who really
>  > dislike Pagure's workflows in the minority?
>
>
>  Since you are asking, for dist-git and for ticket tracking in Fedora,
>  Pagure is much better than what we ever had and with one exception (I am
>  missing easy access to history of a file), there is not missing anything
>  substantial.
>  
We're getting this on the next Pagure upgrade:
https://stg.pagure.io/rpm-packages/pagure/history/pagure.spec



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Frank Ch. Eigler]

>  [...] 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?

- FChE

[Leigh Griffin]

On Wed, Apr 1, 2020 at 2:47 PM Frank Ch. Eigler <fche(a)redhat.com&gt; 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.

>  - FChE
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  

-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford <https://www.redhat.com/>

Communications House

Cork Road, Waterford City

lgriffin(a)redhat.com
M: [phone]     IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>

[Vít Ondruch]

Dne 01. 04. 20 v 15:34 Neal Gompa napsal(a):
>  On Wed, Apr 1, 2020 at 9:26 AM Vít Ondruch
> <vondruch(a)redhat.com&gt; wrote:
> >
> > Dne 01. 04. 20 v 14:33 Alex Scheel napsal(a):
> >> ----- Original Message -----
> >>> From: "Panu Matilainen" <pmatilai(a)redhat.com&gt;
> >>> To: devel(a)lists.fedoraproject.org
> >>> Sent: Wednesday, April 1, 2020 6:22:39 AM
> >>> Subject: Re: CPE Git Forge Decision
> >>>
> >>>> I also appreciate that as a community developing our own solutions is
> >>>> something important and something that seems to matter a lot, but we
> >>>> have to realize that the development and maintenance effort cannot be
> >>>> carried out by the CPE team any more. Maybe this is a opportunity to
> >>>> create a SIG or a working group for people that are interested to carry
> >>>> on this effort.
> >>> But this is precisely at the heart of the problem: people feel they were
> >>> not given an opportunity to lend a hand, and that now its too late
> >>> because the messaging is that we go with GitLab, no matter what.
> >> Pagure has huge developer experience bugs filed against it for many
> >> years. Where have all these contributors been? Are those of us who really
> >> dislike Pagure's workflows in the minority?
> >
> > Since you are asking, for dist-git and for ticket tracking in Fedora,
> > Pagure is much better than what we ever had and with one exception (I am
> > missing easy access to history of a file), there is not missing anything
> > substantial.
> >
>  We're getting this on the next Pagure upgrade:
>  https://stg.pagure.io/rpm-packages/pagure/history/pagure.spec
>  
Cool, so then I won't miss any substantial feature for dist-git ;) Thank
you!


Vít

[Felix Schwarz]

Am 01.04.20 um 08:42 schrieb Clement Verna:
>  I think this feeling comes from the mixing of git forge and dist-git
> use case
>  that you have pointed out. 
That seems to be the core of all the talk about "feature gaps" - obviously
pagure is not nearly as advanced as gitlab/github when you want "some space
for generic software development" (and probably will never be).

However using a generic git forge means we need a separate "self-service
application" for administration of Fedora packages. We had that in the past
(packagedb).

I don't want to presume too much but I just hope you researched why packagedb
was decommissioned and why people thought integrating the functionality into
pagure was a good idea?

Right now this really feels like a kind of ping-pong (from packagedb to pagure
to packagedb2?). I'm not against reversing decisions when the environment
changes or just because after careful consideration something seems like a
better choice. Still I'm worried that the CPE team might have missed some of
the lessons learned in the past...

Felix

[Matthew Miller]

On Wed, Apr 01, 2020 at 02:15:05PM +0200, Pierre-Yves Chibon wrote:
>  Let's be aware that Fedora Infra's job hasn't been
> "Building a linux distro"
>  since it's inception, for a long time its goal was much closer to "building and
>  supporting the *community* that builds the linux distro".
>  If you use this mission statement, you can a much different look at badges,
>  elections or calendaring. 
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.

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Adam Williamson]

On Wed, 2020-04-01 at 11:49 +0200, Clement Verna wrote:
>  On Wed, 1 Apr 2020 at 09:47, Panu Matilainen
> <pmatilai(a)redhat.com&gt; wrote:
>  
>  > On 3/31/20 8:44 PM, Adam Williamson wrote:
>  > 
>  > > I understand there are practical resource considerations and so on
>  > > here, but I still think this merits more high level and serious
>  > > consideration. At the very least, if we have somehow reached a point
>  > > where Red Hat is no longer willing to provide sufficient resources to
>  > > run Fedora on the lines the Fedora community wants it to be run, we
>  > > need to recognize that this is a significant problem that needs to be
>  > > properly aired and discussed and resolved. In this context I'll note
>  > > that the apparent significant headcount reduction of RH people working
>  > > on Fedora infrastructure over the last few years is in itself a
>  > > worrying trend, particularly if you consider it while reading Clement's
>  > > email.
>  > 
>  > This.
>  > 
>  
>  I don't think this is correct, at least not in CPE, the team has grown over
>  the past year and every person leaving the team has been replaced (even by
>  2 persons in some cases). 
Okay, I didn't mean to get into detail, but I don't see how this is
possible. Unless you're considering 'CPE' as a whole (which includes
the infra admin team, release engineering, and docs) versus 'people
doing development'.

Around two-three years ago, IIRC, we had all these people working on
Fedora app/infra development:

puiterwijk (who counts as about ten people, admittedly, replacing
Patrick with anything besides an entire team was always going to be a
challenge)
Randy (bowlofeggs)
pingou
jcline
Ralph
jflory
abompard

Right now, I see these people who appear to be on the CPE team and
clearly working on Fedora infra/app development:

abompard?
lrossetti/odra (although I had not heard of or seen him till I started
doing research for this post, he seems to be working on fasjson which I
don't really run into)
pingou
scoady
cverna

I put a question mark by abompard as he clearly works for RH and works
a lot on infra, but (looking at internal systems) does not seem to be
quite in the same management chain as the others, not sure why that is.
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.

If I'm missing anyone, please do correct me. Mattia Verga seems to do a
lot of work on Bodhi, but AFAICS he is not part of RH CPE. We could
count Ryan Lerch (UX) and/or Kevin Fenzi (who's officially admin, but
as we all know, does everything) in both list or neither.

Maybe the people I remember were not all there at exactly the same
time, I'm not 100% sure as I'm not on that team. But it does not feel
to me like we (RH) have the same level of personpower working on Fedora
app/infra development now as we did in 2018, put it that way.

The list at
https://fedoraproject.org/wiki/Community_Platform_Engineering seems to
be rather out of date; to my knowledge, Randy, Sayan, and Sinny are no
longer on the team, correct? Others in the list seem to work more or
less entirely on CentOS.

>   The problem in my opinion is that a lot of the
>  people that have setup and written the original services and applications
>  are gone, taking with them most of the knowledge about How, What and Why
>  something was done this way. That leaves people in the team now with a big
>  amount of legacy applications to take care of and not much clue of what is
>  going on. 
I can believe this, though I'd also note that few of the apps are
original to the "last gen" team either. Bodhi was written by Luke, back
in the day, for instance, but Ralph did a great job of taking it over
(and fixing it up). fedmsg was written by Ralph, then handed off
successfully (AFAICS, anyway) to jcline. So we seem to have done these
kinds of hand off before with success. What changed there?

>  There is also an historical taste to write in house applications for
> things
>  that don't really seems critical to the Fedora Project, for example do we
>  really need a custom calendar application ? or election application ? It
>  seems that every time we have a problem the solution is let's write
>  something to solve that problem, instead of trying to find a compromise and
>  reuse existing solutions. 
So on the whole I agree with this. I talked to Jim about this whole
situation at OSS 2018 and he was already thinking along the lines of
cutting some of the stuff we really don't need to be writing. I
entirely agree that it's a reasonable approach to ditch stuff like this
that is *relatively* external to the process of actually building a
distribution. I'd be kinda sad if it was replaced with proprietary SAAS
stuff, but I don't think it'd be as big of a problem as if we did that
with our dist-git.

I don't think we need to go into it in detail, but I *do* also
understand why we did it in the first place, and I think there's still
merit in that. For a start, it genuinely was the case back when a lot
of these apps were written that you couldn't so easily go out and "buy
one off the shelf", so to speak. But there's also the whole idea of
dogfooding, and the ecosystem. Again there's a historical angle to
this: it wasn't just for us but for the whole industry that it was more
common to build stuff in-house than outsource absolutely everything
besides your "core competency", as is the management fad these days. So
for us to build our own infrastructure was kind of a proof-of-concept
that Fedora *was* a suitable environment for *anyone* to do that: at
least at the time we felt that there was value in demonstrating that
Fedora provided an environment in which you *could* build and deploy
and maintain and use, you know, calendaring systems! and authentication
systems! and election apps! and so on and so forth.

I agree that this has fallen out of fashion to an extent, and the
"let's just outsource everything that isn't actively building bits into
OS images" mindset is in tune with Current Industry Thinking and there
is a sustainable logic behind it. Personally I still think it comes
with significant issues, though, because there were a lot of what
management is pleased to call "intangibles" that went along with doing
all that work. We had an awful lot of "in-house" knowledge about a
whole range of stuff because we *did* build and maintain and deploy and
support all of these bits. Why do you think Patrick and Kevin can fix
just about anything? In large part because of all that experience.

Still, we're getting a bit into the weeds at that point. I'm not
arguing that we *must* continue to develop elections apps and calendars
and all of that stuff. To be clear, I'm not even arguing that we should
continue developing Pagure as part of CPE, or even necessarily host
Gitlab ourselves.

>  Now when the CPE team goes and ask for more people because we
> struggle with
>  current situation, I can only guess that these non critical applications
>  are mentioned. If I was putting my own money to sponsor a team to help
>  building a Linux distribution I would be asking why do we have to develop a
>  calendar application or why do we need a custom git forge. I personally
>  find really great that the different use cases and requirements for the use
>  of Pagure were gathered and I am convinced that people working on this did
>  their very best to find a use case to justify the investment needed in
>  Pagure but it seems that we don't have such a thing. 
I think other people are following up on this, but from following the
discussion, it appears to me that there seems to have been a large slip
somewhere along the line from Ben submitting a list of ~50 Fedora
submissions, to Leigh suggesting that (after those were, mysteriously,
"summarized" somehow) Fedora does not have much in the way of specific
requirements. I also think the confusion between "git forge" and "dist-
git" is a major issue here. On the whole I suspect people using
Pagure.io for project hosting don't have a lot of very specific
requirements, because - let's be honest - Gitlab and Github can
certainly do nearly everything Pagure does as a generic project hosting
system. I could probably move my projects to a Gitlab instance in an
afternoon (depending on how much of a pain it is to set up F/OSS CI on
Gitlab, I have not looked into that yet, and yes, for anyone who hasn't
been looking lately, Pagure does actually have CI integration now).
However, I think we (Fedora) certainly *do* have a whole pile of
requirements for a dist-git system, and Leigh's responses so far (of
the "well we haven't figured all that out yet!" variety) do not give me
confidence that this was fully appreciated in the decision-making
process.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Matthew Miller]

On Wed, Apr 01, 2020 at 12:52:00PM +0200, Nicolas Mailhot via devel wrote:
>  At heart, Fedora is a tooling project. It’s a collective of people
> that
>  chose to use a specific integration toolchain. Anything involved in
>  creating Fedora packages cuts deep into the project core. (unlike, say,
>  calendaring).
>  
>  It’s easy to forget this when making tooling decisions,
>  because it is so pervasive, most do not see it anymore. Tooling is
>  anything but accessory to the project. 
I understand the sentiment but would like to tweak it a bit. Rather than a
tooling project, Fedora is an _integration_ project. We bring together all
of this software in the world and create polished solutions for users, and
we make it easy for community members with specific ideas, and our
downstreams, to do the same. That necessarily requires tooling, but tooling
isn't the heart of the project. It's okay for us to be the integrator of
tooling rather than the owner and creator of it all.


-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Adam Williamson]

On Wed, 2020-04-01 at 06:11 -0500, Bruno Wolff III wrote:
>  On Wed, Apr 01, 2020 at 12:39:21 +0200,
>    Florian Weimer <fweimer(a)redhat.com&gt; wrote:
>  > * Bruno Wolff, III:
>  > 
>  > > RHEL is a special case, as CENTOS provides a free drop in replacement
>  > > and switching from CENTOS to Fedora shouldn't be much work. Is there
>  > > other proprietary software at the OS level or above, that is used for
>  > > Fedora infrastructure?
>  > 
>  > The Bugzilla fork running on bugzilla.redhat.com?
>  > 
>  >  <https://bugzilla.redhat.com/show_bug.cgi?id=478886>
>  
>  That was an interesting read. It sounds like corners were cut under the 
>  assumption that there would be no desire to share the code. Specifically 
>  code and config were mixed together and the config can't be released. 
There's been an ongoing project in RH for the last few years to get
RHBZ closer to upstream. It's *much* closer now than it was a few years
ago. I haven't looked at the internal fork for a year or so, but last
time I did it wasn't a long way away from upstream.

So yeah, this is a valid entry in the list, but again it's a very
'grandfathered' one, and one it would be practically very difficult to
do much about (trying to unpick Fedora from RHBZ has been talked about
more than once but is logistically a very difficult job).
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Adam Williamson]

On Wed, 2020-04-01 at 08:33 -0400, Alex Scheel wrote:
>  ----- Original Message -----
>  > From: "Panu Matilainen" <pmatilai(a)redhat.com&gt;
>  > To: devel(a)lists.fedoraproject.org
>  > Sent: Wednesday, April 1, 2020 6:22:39 AM
>  > Subject: Re: CPE Git Forge Decision
>  > 
>  > > I also appreciate that as a community developing our own solutions is
>  > > something important and something that seems to matter a lot, but we
>  > > have to realize that the development and maintenance effort cannot be
>  > > carried out by the CPE team any more. Maybe this is a opportunity to
>  > > create a SIG or a working group for people that are interested to carry
>  > > on this effort.
>  > 
>  > But this is precisely at the heart of the problem: people feel they were
>  > not given an opportunity to lend a hand, and that now its too late
>  > because the messaging is that we go with GitLab, no matter what.
>  
>  Pagure has huge developer experience bugs filed against it for many
>  years. Where have all these contributors been? Are those of us who really
>  dislike Pagure's workflows in the minority? Or are others more prone
>  to put up with it because it is free, open source software? 
To speak for myself, I've been sending patches to Pagure for some time:

https://pagure.io/pagure/commits/master?author=[e-mail]
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Adam Williamson]

On Wed, 2020-04-01 at 15:08 +0100, Leigh Griffin wrote:
>  On Wed, Apr 1, 2020 at 2:47 PM Frank Ch. Eigler
> <fche(a)redhat.com&gt; 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?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Nicolas Mailhot]

Le mercredi 01 avril 2020 à 12:15 -0400, Matthew Miller a écrit :
>  
>  I understand the sentiment but would like to tweak it a bit. Rather
>  than a
>  tooling project, Fedora is an _integration_ project. We bring
>  together all
>  of this software in the world and create polished solutions for
>  users, and
>  we make it easy for community members with specific ideas, and our
>  downstreams, to do the same. That necessarily requires tooling, but
>  tooling
>  isn't the heart of the project. It's okay for us to be the integrator
>  of tooling rather than the owner and creator of it all. 
That’s a nice sentiment, but practically, the reason why Debian and
Fedora are not interchangeable, or why @gnome is dead set on creating
alternative toolchains, to “free” itself from distributions, is tooling
and only tooling.

You can not integrate at the level of a distribution without deep
tooling control and strategy. You can not replace the tools without
effectively embarking on a different distribution with a different
contributor set.

I am quite sceptical on how much of this can be SAASed away to a third
party without deleterious long term effects. (I don’t say it is
impossible, but it is a huge gamble).

What I am sure, is that the CPE statement “Gitlab is cool because they
will think about the roadmap in our stead” is a complete
misunderstanding of what makes Fedora tick.

Regards,

-- 
Nicolas Mailhot

[Adam Williamson]

On Tue, 2020-03-31 at 14:22 -0700, Adam Williamson wrote:
>  On Tue, 2020-03-31 at 17:06 -0400, Paul Frields wrote:
>  > > Sure. I tend to think of these as 'upstream projects' that we (Fedora)
>  > > consume as a downstream. Project hosting has always been a kinda
>  > > optional bolt-on, I think; going back to the days of fedorahosted.org I
>  > > don't think we've ever hosted everything "Fedora-adjacent" in
> our own
>  > > hosting service, it's always been a "use it if you want to"
> thing, and
>  > > the rule for using a project in Fedora has always been "is it open
>  > > source?", not "how is it hosted?".
>  > 
>  > Although the Council changed that hard line some time ago.
>  
>  Someone told me that a few minutes ago; either I wasn't aware at the
>  time or have forgotten, but my personal opinion is that this was a
>  mistake. 
For a bit more on this, it seems Council discussed it again today:

https://meetbot-raw.fedoraproject.org/teams/council/council.2020-04-01-14...

as noted there, the precise text agreed was:

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

To me that's fairly strongly qualified. "Not viable or not available".
Note, that does not say "not the absolute best-in-class", it says "not
viable". Has it been demonstrated that either Pagure or Gitlab CE are
"not viable" for the purposes Fedora needs?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Frank Ch. Eigler]

>      > [...] 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.  
Surely what we want to minimize is total cost, not just one
department's expenditure.  For that, you'd need to have the
gitlab costs to compare.


- FChE

[Kevin Fenzi]

On Wed, Apr 01, 2020 at 11:51:01AM +0200, clime wrote:
>  On Wed, 1 Apr 2020 at 10:54, Vít Ondruch <vondruch(a)redhat.com&gt;
> wrote:
>  > Do you mean https://github.com/fedora-infra/pkgdb2/ ? :) 
No.

>  This is just hilarious, so after going all pagure for dist-git and
>  making it all work, we will now go back to pkgdb, additionally with
>  proprietary git backend, lol. 
But pagure doesn't "just work". There's pagure-dist-git that does all
kinds of things to make src.fedoraproject.org have different things than
pagure.io. 

Do you consider pagure-dist-git to be pkgdb 1.5?

You missed where I said we should adjust our workflow and try and
minimize this layer. I wasn't suggesting we just make another app in
front of the git forge. I was suggesting we move all our "special" stuff
into git or otherwise adjust our workflow to make such a layer
nonexistant or as small as we can. 

How could we do that?

Well, there was the suggestion from Jermey that we use tags to store
this 'distro metadata'. Or perhaps we have files in each git repo, or a
branch or a seperate repo. This would not only mean we have less to
maintain, but it would mean we could move things much easier, people
could mirror them to another gitforge much easier, etc. 

>  I mean if there is some alien race (or a human competitor) watching
>  what is happening in one of the leading linux distributions, they must
>  laugh hard. Well, we soon won't be leading. 
I think you are misunderstanding me, but sure, laugh away. If you can't
laugh, you have to cry. ;) 

kevin

[Adam Williamson]

On Wed, 2020-04-01 at 12:09 -0400, Matthew Miller wrote:
>  On Wed, Apr 01, 2020 at 02:15:05PM +0200, Pierre-Yves Chibon wrote:
>  > Let's be aware that Fedora Infra's job hasn't been "Building a
> linux distro"
>  > since it's inception, for a long time its goal was much closer to "building
> and
>  > supporting the *community* that builds the linux distro".
>  > If you use this mission statement, you can a much different look at badges,
>  > elections or calendaring.
>  
>  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?

Right now the only story I remember hearing around these things is the
CPE team's "we are narrowing our focus and these things are no longer
within it, so they're going to be dropped or heavily back-burnered or 
given to The Community". There have been specific individual efforts to
pick up or at least drive-by work on various specific things, but I
haven't seen any organized effort (from Red Hat or "The Community") to
consider this in a broader way.

I was figuring this really was the intended state of affairs, but the
above makes it sound like there's some idea "Fedora" might still want
this stuff done, but I don't see any processes or groups or anything
that are being formed or proposed to make that happen?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Adam Williamson]

On Wed, 2020-04-01 at 09:11 -0700, Adam Williamson wrote:
>  Bodhi was written by Luke, back
>  
>  in the day, for instance, but Ralph did a great job of taking it over
>  
>  (and fixing it up). 
Sorry, that was obviously a mental slip: I meant Randy, not Ralph.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Chris Murphy]

On Wed, Apr 1, 2020 at 1:47 AM Panu Matilainen <pmatilai(a)redhat.com&gt; wrote:
>  On 3/31/20 8:44 PM, Adam Williamson wrote:
>
>  > I understand there are practical resource considerations and so on
>  > here, but I still think this merits more high level and serious
>  > consideration. At the very least, if we have somehow reached a point
>  > where Red Hat is no longer willing to provide sufficient resources to
>  > run Fedora on the lines the Fedora community wants it to be run, we
>  > need to recognize that this is a significant problem that needs to be
>  > properly aired and discussed and resolved. In this context I'll note
>  > that the apparent significant headcount reduction of RH people working
>  > on Fedora infrastructure over the last few years is in itself a
>  > worrying trend, particularly if you consider it while reading Clement's
>  > email.
>
>  This.
>
>  As a user, I wont be shedding a single tear for GitLab over Pagure, BUT.
>
>  There's something very wrong with the picture here, and this forge
>  business seems more like an abscess that finally burst rather than the
>  disease itself. I really do not envy being in CPE's pants in this situation.
>
>  If the problem is lack of funding for Fedora infastructure, shouldn't we
>  talking about that (finding additional sponsors or something) instead of
>  which limb to saw off to ensure enough blood for the remaining organs? 
I agree, and wonder about this too. But such a conversation
immediately runs into the delicate and awkward realm of corporate
politics: would Red Hat even allow other sponsors, and what are the
parameters by which this could even happen - it's not clear to me at
all.

Also, there are different kinds of resources: funding, people,
hardware (virtual/physical). While the project always has resource
shortages to varying degrees, I'm not certain of any metric to
establish a low watermark; know whether it's being approached before
there's a problem; or a formal mechanism of refreshing teams to avoid
burn out and hitting a resource low watermark.

Another example of this is:

#275 Websites team needs revitalizing
https://pagure.io/Fedora-Council/tickets/issue/275

from which I've just realized two things: (a) CPE is Fedora
Infrastructure team; (b) due to the lack of an active websites team,
this responsibility is, for now, on CPE.


--
Chris Murphy

[Paul Frields]

On Wed, Apr 1, 2020 at 7:03 AM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  On Wed, Apr 1, 2020 at 6:52 AM Nicolas Mailhot via devel
>  <devel(a)lists.fedoraproject.org&gt; wrote:
>  >
>  > Le mercredi 01 avril 2020 à 11:30 +0100, Leigh Griffin a écrit :
>  > >
>  > > To distill it down:
>  > >
>  > > - Gitlab has more features that are needed right now for our
>  > > stakeholder group
>  > > - Gitlab has an entire company dedicated to roadmap features, we do
>  > > not.
>  >
>  > Unfortunately, Gitlab’s roadmap is also conflicting with Fedora
>  > objectives. The bread and butter of Gitlab is intermediating between
>  > devs and end users, culling free software intermediaries like
>  > distributions, and positionning itself in their stead. That is unlikely
>  > to result in any commitment to making distribution workflows work.
>  >
>  > That would not be a problem if the disintermediation worked, but like
>  > many actors Gitlab sees the $$$ and power in being the
>  > desintermediator, and does not care if the result is deffective, as
>  > long as $$$ and power flows its way.
>  >
>
>  It's also important to note that at the core of GitLab's incentive
>  model is that they want to remove incentives to use FOSS solutions in
>  favor of their unified proprietary solution. They are constantly
>  integrating features and capabilities into the proprietary parts to
>  make it "juicier" for enterprises who don't really have a compunction
>  about whether they are using Free Software solutions or not, or even
>  may not be willing to support them if it was Free Software because of
>  outmoded thinking.
>
>  The consequence of this is that it starves interest and development in
>  FOSS solutions, and contributes to making the FOSS ecosystem weaker
>  over time. 
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.

>  It wouldn't surprise me if not many people at Red Hat sat down
> and
>  thought seriously about that particular consequence, because it's not
>  exactly an obvious one. 
I don't know how many people do, since it's a growing company. I
assure you some of us do. :-)

>  > At heart, Fedora is a tooling project. It’s a collective of
> people that
>  > chose to use a specific integration toolchain. Anything involved in
>  > creating Fedora packages cuts deep into the project core. (unlike, say,
>  > calendaring).
>  >
>  > It’s easy to forget this when making tooling decisions,
>  > because it is so pervasive, most do not see it anymore. Tooling is
>  > anything but accessory to the project.
>  >
>
>  Exactly. This is a huge part of why people are so upset over this,
>  because if you take away our tools, you take away the reason to be
>  passionate about Fedora. And thus, you remove why people use and
>  contribute to Fedora in the first place. 
My reason for being passionate about Fedora is mainly about helping
people use the software and content we provide in ways that serve
their needs and solve their problems. To do that, I use Inkscape[1],
Wordpress[2], and Ansible[3] a lot.

[1] https://gitlab.com/inkscape/inkscape
[2] https://github.com/WordPress/wordpress-develop
[3] https://github.com/ansible/ansible


--
Paul

[Chris Murphy]

On Wed, Apr 1, 2020 at 6:39 AM Stephen John Smoogen <smooge(a)gmail.com&gt; wrote:
>  On Wed, 1 Apr 2020 at 08:16, Pierre-Yves Chibon <pingou(a)pingoured.fr&gt; wrote:
> >
> > On Wed, Apr 01, 2020 at 11:49:41AM +0200, Clement Verna wrote:
> > >    There is also an historical taste to write in house applications for
> > >    things that don't really seems critical to the Fedora Project, for
> example
> > >    do we really need a custom calendar application ? or election application
> > >    ? It seems that every time we have a problem the solution is let's write
> > >    something to solve that problem, instead of trying to find a compromise
> > >    and reuse existing solutions.
> >
> > Could please stop this?
> >
>
>  This is me also asking this.
>
>
> >
> > The continuous theme of "we're building things because we like it" is
> unfair to
> > all the people who have been involved in the infrastructure at some point in the
> > past.
> > It is assuming that there was no reasons, that they did not do their research,
> > that they didn't think it through.
> >
> > The requirements for applications 3 years ago were vastly different from what
> > they are today.
> > If you don't know the historical reasons for an app, there are a number of
> > people around who can answer them, but please let's stop assuming things which
> > are at the end of the day insulting and demotivating for the people who were
> > involved then and are still now.
> >
> > This goes for fedocal, for pagure, for anitya. I've seen this question come up
> > often enough (here and elsewhere): "Why aren't we using libraries.io instead
> of
> > anytia?"
> > Well, the simple reason is: because libraries.io *did* *not* *exist* when anitya
> > was created. So maybe we are not the bad ones that didn't do their research.
> >
>
>  I am also sick and tired of this. For many years, a central drive for Fedora Infra was
> about building the Free and Open Source tools to allow a community to work together
> without using closed source tools. This was a constant requirement of the community to us
> at the time with wanting something to 'compete' against Canonical's forge and
> Canonicals' other tools. Things have changed but instead of saying "Good job,
> thanks for all that work but we have decided to change.", our efforts are brought up
> constantly as a bunch of NIH who wasted time and effort. And it doesn't matter how
> many times people are reminded that we had reasons and research for doing this from 2005
> to 2015.. it gets thrown in our faces that we reinvented the wheel when there were clearly
> better things to spend our time on.
>  
Is the FOSS position adequately represented on the Council?

-- 
Chris Murphy

[clime]

On Wed, 1 Apr 2020 at 21:12, Kevin Fenzi <kevin(a)scrye.com&gt; wrote:
>  On Wed, Apr 01, 2020 at 11:51:01AM +0200, clime wrote:
>  > On Wed, 1 Apr 2020 at 10:54, Vít Ondruch <vondruch(a)redhat.com&gt; wrote:
>  > > Do you mean https://github.com/fedora-infra/pkgdb2/ ? :)
>
>  No.
>
>  > This is just hilarious, so after going all pagure for dist-git and
>  > making it all work, we will now go back to pkgdb, additionally with
>  > proprietary git backend, lol.
>
>  But pagure doesn't "just work". There's pagure-dist-git that does all
>  kinds of things to make src.fedoraproject.org have different things than
>  pagure.io.
>
>  Do you consider pagure-dist-git to be pkgdb 1.5?
>
>  You missed where I said we should adjust our workflow and try and
>  minimize this layer. I wasn't suggesting we just make another app in
>  front of the git forge. I was suggesting we move all our "special" stuff
>  into git or otherwise adjust our workflow to make such a layer
>  nonexistant or as small as we can.
>
>  How could we do that?
>
>  Well, there was the suggestion from Jermey that we use tags to store
>  this 'distro metadata'. Or perhaps we have files in each git repo, or a
>  branch or a seperate repo. This would not only mean we have less to
>  maintain, but it would mean we could move things much easier, people
>  could mirror them to another gitforge much easier, etc.
>
>  > I mean if there is some alien race (or a human competitor) watching
>  > what is happening in one of the leading linux distributions, they must
>  > laugh hard. Well, we soon won't be leading.
>
>  I think you are misunderstanding me, but sure, laugh away. If you can't
>  laugh, you have to cry. ;) 
I am all for thinning the layer around our base by using git metadata
or files where possible but some things cannot be done by it like e.g.
links to builds for a given commit, list of actual releases from
bodhi, the bugzilla integration etc. But I think it could be suitable
e.g. for PDC data.

I mean keeping things defined in git is a great goal and it would
definitely help to make things minimal. And keeping the tooling
footprint minimal can help us to keep our open-source spirit.

Anyway, I admit I didn't really understand your email. What you
suggested is a good thing to do - a good technological direction but I
don't want to be doing this on a proprietary platform that belongs to
someone else. That seems to be a huge cut into our identity.

pagure is a very well written technology (with a few UI quirks
perhaps) and we should be proud of it and continue improving it. A
decision like this is likely to make it dead, I mean, guys in the blog
post tried to draw some rainbows but we all know what's going to
happen.

I also think it is sufficient for our needs, whatever the mentioned
"stakeholders" wanted I am sure can be done with quite a little effort
if the requirements are very well specified. Imho, we should do that
instead of immediately switching to some enterprise external hosting
that doesn't align with our culture (at least according my view of
Fedora, I started to use fedora since around .fc3 and it was a cool
and inspiring distribution to me ever since, such feeling can change
for new-comers if we don't keep our values).

clime

>
> kevin
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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/[e-mail]

[Michael Catanzaro]

On Wed, Apr 1, 2020 at 3:39 pm, Chris Murphy <lists(a)colorremedies.com&gt; 
wrote:
>  Is the FOSS position adequately represented on the Council? 
 From my reading of [1], the Council decision is that we use FOSS in 
our infrastructure except where it is "not viable and not available." 
In the case of dist-git, it seems undeniable that FOSS is both viable 
and available (whether it's Pagure or GitLab CE). Council hasn't 
actually approved a move to a proprietary version of GitLab yet afaik.

[1] 
https://meetbot-raw.fedoraproject.org/teams/council/council.2020-04-01-14...

[clime]

On Wed, 1 Apr 2020 at 23:22, Paul Frields <stickster(a)gmail.com&gt; wrote:
>  On Wed, Apr 1, 2020 at 7:03 AM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  >
>  > On Wed, Apr 1, 2020 at 6:52 AM Nicolas Mailhot via devel
>  > <devel(a)lists.fedoraproject.org&gt; wrote:
>  > >
>  > > Le mercredi 01 avril 2020 à 11:30 +0100, Leigh Griffin a écrit :
>  > > >
>  > > > To distill it down:
>  > > >
>  > > > - Gitlab has more features that are needed right now for our
>  > > > stakeholder group
>  > > > - Gitlab has an entire company dedicated to roadmap features, we do
>  > > > not.
>  > >
>  > > Unfortunately, Gitlab’s roadmap is also conflicting with Fedora
>  > > objectives. The bread and butter of Gitlab is intermediating between
>  > > devs and end users, culling free software intermediaries like
>  > > distributions, and positionning itself in their stead. That is unlikely
>  > > to result in any commitment to making distribution workflows work.
>  > >
>  > > That would not be a problem if the disintermediation worked, but like
>  > > many actors Gitlab sees the $$$ and power in being the
>  > > desintermediator, and does not care if the result is deffective, as
>  > > long as $$$ and power flows its way.
>  > >
>  >
>  > It's also important to note that at the core of GitLab's incentive
>  > model is that they want to remove incentives to use FOSS solutions in
>  > favor of their unified proprietary solution. They are constantly
>  > integrating features and capabilities into the proprietary parts to
>  > make it "juicier" for enterprises who don't really have a compunction
>  > about whether they are using Free Software solutions or not, or even
>  > may not be willing to support them if it was Free Software because of
>  > outmoded thinking.
>  >
>  > The consequence of this is that it starves interest and development in
>  > FOSS solutions, and contributes to making the FOSS ecosystem weaker
>  > over time.
>
>  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. 
This is imho a contradictory statement. Github, being closed source
and pervasive, is a proof that open-source has won?

No, the trend obviously is to give up some open-source community part
to get people hooked-in and then earn money on the proprietary version
of the product which has more features.

I am not saying it is wrong but it is clearly something else than
"open source has won the war of how development should work".

But what we are solving here is not about some
closed-source/open-source battle, it's about Fedora keeping its
autonomy and values. Of course, Fedora going for a proprietary
solution also _doesn't_ show that "open source has won the war of how
development should work".

>  > It wouldn't surprise me if not many people at Red Hat sat down and
>  > thought seriously about that particular consequence, because it's not
>  > exactly an obvious one.
>
>  I don't know how many people do, since it's a growing company. I
>  assure you some of us do. :-)
>
>  > > At heart, Fedora is a tooling project. It’s a collective of people that
>  > > chose to use a specific integration toolchain. Anything involved in
>  > > creating Fedora packages cuts deep into the project core. (unlike, say,
>  > > calendaring).
>  > >
>  > > It’s easy to forget this when making tooling decisions,
>  > > because it is so pervasive, most do not see it anymore. Tooling is
>  > > anything but accessory to the project.
>  > >
>  >
>  > Exactly. This is a huge part of why people are so upset over this,
>  > because if you take away our tools, you take away the reason to be
>  > passionate about Fedora. And thus, you remove why people use and
>  > contribute to Fedora in the first place.
>
>  My reason for being passionate about Fedora is mainly about helping
>  people use the software and content we provide in ways that serve
>  their needs and solve their problems. To do that, I use Inkscape[1],
>  Wordpress[2], and Ansible[3] a lot.
>
>  [1] https://gitlab.com/inkscape/inkscape
>  [2] https://github.com/WordPress/wordpress-develop
>  [3] https://github.com/ansible/ansible 
That's nice, some people, on the other hand, are passionate about the
way Fedora is able to deliver that software - it delivers it while at
the same time helping the open-source software by using it.

>
>
> --
> Paul
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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/[e-mail]

[Paul Frields]

On Wed, Apr 1, 2020, 7:53 PM Michael Catanzaro <mcatanzaro(a)gnome.org&gt; wrote:

>  On Wed, Apr 1, 2020 at 3:39 pm, Chris Murphy
> <lists(a)colorremedies.com&gt;
>  wrote:
>  > Is the FOSS position adequately represented on the Council?
>
>   From my reading of [1], the Council decision is that we use FOSS in
>  our infrastructure except where it is "not viable and not available."
>  In the case of dist-git, it seems undeniable that FOSS is both viable
>  and available (whether it's Pagure or GitLab CE). Council hasn't
>  actually approved a move to a proprietary version of GitLab yet afaik.
>
>  [1]
>
>  https://meetbot-raw.fedoraproject.org/teams/council/council.2020-04-01-14...

For a solution to be viable it needs to meet requirements.

-- 
Paul

[Solomon Peachy]

On Wed, Apr 01, 2020 at 08:16:29PM -0400, Paul Frields wrote:
>  >
> https://meetbot-raw.fedoraproject.org/teams/council/council.2020-04-01-14...
>  
>  For a solution to be viable it needs to meet requirements. 
By that standard, GitLab (in any guise) must be excluded as well.

 - Solomon
-- 
Solomon Peachy			       pizza at shaftnet dot org
High Springs, FL                          ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.

[Adam Williamson]

On Wed, 2020-04-01 at 20:16 -0400, Paul Frields wrote:
>  On Wed, Apr 1, 2020, 7:53 PM Michael Catanzaro
> <mcatanzaro(a)gnome.org&gt; wrote:
>  
>  > On Wed, Apr 1, 2020 at 3:39 pm, Chris Murphy <lists(a)colorremedies.com&gt;
>  > wrote:
>  > > Is the FOSS position adequately represented on the Council?
>  > 
>  >  From my reading of [1], the Council decision is that we use FOSS in
>  > our infrastructure except where it is "not viable and not available."
>  > In the case of dist-git, it seems undeniable that FOSS is both viable
>  > and available (whether it's Pagure or GitLab CE). Council hasn't
>  > actually approved a move to a proprietary version of GitLab yet afaik.
>  > 
>  > [1]
>  > 
>  >
> https://meetbot-raw.fedoraproject.org/teams/council/council.2020-04-01-14...
>  
>  For a solution to be viable it needs to meet requirements. 
Sure. That's just a re-statement of the question. Are there Fedora
requirements here which are met by proprietary Gitlab but not by Gitlab
CE or Pagure?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Randy Barlow]

On 4/1/20 11:25 AM, Felix Schwarz wrote:
>  I don't want to presume too much but I just hope you researched
> why packagedb
>  was decommissioned and why people thought integrating the functionality into
>  pagure was a good idea? 
pkgdb was decommissioned because modularity needed a lot of changes 
across the infrastructure, and pkgdb was in a state that made it 
expensive to alter (or even to maintain). That said, I do miss how 
things were back when we had pkgdb. I wish we had been able to rewrite 
or rebase it rather than eliminate it.

I personally think keeping package data separate from the git data makes 
sense (i.e., having a generic git server, and a separate app like pkgdb 
to do Fedora package specific things). Then the git server can just be 
an off-the-shelf program, and infrastructure can focus solely on 
maintaining the code that is unique to Fedora's needs.

[Randy Barlow]

On 4/1/20 1:16 PM, Adam Williamson wrote:
>  Has it been demonstrated that either Pagure or Gitlab CE are
>  "not viable" for the purposes Fedora needs? 
Hey Adam!

I agree with you that Pagure and Gitlab CE are both viable for Fedora's 
needs in terms of feature matrices and requirements. We have shipped a 
handful or so of Fedora releases over the last 3ish years since src.fpo 
came online as proof!

However, the CPE team does not have the resources to do a good job on 
maintaining that system, and Bodhi, and Koji, and the 187 other apps (I 
think we did count the apps we maintained at one point and ended up with 
a list that was about 190 long!). The responsibility to engineer ratio 
is not healthy or sustainable.

I agree with the sentiment that this decision process was not done in 
the open. There was a thread on a Fedora Council mailing list, but I 
personally was not aware of the existence of that list until someone 
linked that thread here, and I expect that most of the Fedora community 
probably does not closely monitor that list. Thus, I don't think that 
really counts as a venue for open discussion with the community.

I expected to see discussion about it here, on this list, because this 
is where all of the users for the proposed system can reasonably 
expected to be. I also expected that discussion to allow community 
members to be meaningfully involved in the process: requirement 
gathering, analysis, proposals, counter proposals, counter counter 
proposals, etc. That's what an open decision process would have looked 
like in my opinion.

[Adam Williamson]

On Wed, 2020-04-01 at 22:33 -0400, Randy Barlow wrote:
>  On 4/1/20 1:16 PM, Adam Williamson wrote:
>  > Has it been demonstrated that either Pagure or Gitlab CE are
>  > "not viable" for the purposes Fedora needs?
>  
>  Hey Adam!
>  
>  I agree with you that Pagure and Gitlab CE are both viable for Fedora's 
>  needs in terms of feature matrices and requirements. We have shipped a 
>  handful or so of Fedora releases over the last 3ish years since src.fpo 
>  came online as proof!
>  
>  However, the CPE team does not have the resources to do a good job on 
>  maintaining that system, and Bodhi, and Koji, and the 187 other apps (I 
>  think we did count the apps we maintained at one point and ended up with 
>  a list that was about 190 long!). The responsibility to engineer ratio 
>  is not healthy or sustainable. 
Okay, look, at a certain point I start to feel like we're trapped in
some sort of Kafka novel here.

At the outset of this whole mess, quite a lot of people said "well this
is obviously just all a pretext for dropping Pagure and going to hosted
Gitlab". Much offence seemed to be taken at this, and much was made of
this absolutely not being the case at all, and Pagure being definitely
a contender, and - as was pointed out upthread - how there would be
public meetings and feedback sessions and a whole three-ring circus
before a final decision was made. Which very definitely hadn't already
been made, or anything.

And now three days into this thread, you're saying "well, CPE doesn't
have the resources to maintain Pagure". So, what, people were right in
the first place, and this was really just the Dump Pagure Project all
along?

If so what was the point of all this half-baked kabuki nonsense? Why
not just say so up-front? If CPE never thought it had the resources to
maintain Pagure and Pagure was never really a contender, and Github was
as clearly a non-starter as Leigh says it was, why didn't we just say
"yeah no we're going to Gitlab" four months (or whatever it was) ago
and save all of this silliness? We agree that this process wasn't
actually very open at all, but *even if it had been*, if the result was
preordained, what would have been the point?

Also, why does CPE not *at least* have its ducks very definitely in a
row about exactly how much work is actually going to be involved in all
the options here? How has this decision taken several months and yet
when people ask "okay, so exactly what is the plan for re-doing all the
Pagure<->dist-git integration with Gitlab, and how much work and how
long is that going to take?", the answer is "uh, we don't know, we're
going to figure it out now"? Why does the blog post that announced this
decision - talk quite a lot about what the plan is with regard to
pagure.io (that's clearly what it usually means when it says "Pagure",
in context) but nothing at all about what the plan is wrt dist-git?

Not to mention that this subthread is about the circumstances in which
Fedora has decided it will accept non-free infra, and that "not viable
and not available" quote. If we count absolutely anything that involves
CPE actually doing any work beyond paying someone else to run it as
"not viable", well, yeah, that's going to render an awful lot of stuff
"not viable", isn't it? But I don't think that's how many people
would
necessarily have expected that text to be interpreted.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Pierre-Yves Chibon]

On Wed, Apr 01, 2020 at 09:24:44PM -0400, Randy Barlow wrote:
>  and pkgdb was in a state that made it expensive to alter
>  (or even to maintain). 
Source?


Pierre

[Florian Weimer]

* Adam Williamson:

>  On Wed, 2020-04-01 at 06:11 -0500, Bruno Wolff III wrote:
> > On Wed, Apr 01, 2020 at 12:39:21 +0200,
> >   Florian Weimer <fweimer(a)redhat.com&gt; wrote:
> > > * Bruno Wolff, III:
> > > 
> > > > RHEL is a special case, as CENTOS provides a free drop in replacement
> > > > and switching from CENTOS to Fedora shouldn't be much work. Is there
> > > > other proprietary software at the OS level or above, that is used for
> > > > Fedora infrastructure?
> > > 
> > > The Bugzilla fork running on bugzilla.redhat.com?
> > > 
> > >  <https://bugzilla.redhat.com/show_bug.cgi?id=478886>
> > 
> > That was an interesting read. It sounds like corners were cut under the 
> > assumption that there would be no desire to share the code. Specifically 
> > code and config were mixed together and the config can't be released.
>
>  There's been an ongoing project in RH for the last few years to get
>  RHBZ closer to upstream. It's *much* closer now than it was a few years
>  ago. I haven't looked at the internal fork for a year or so, but last
>  time I did it wasn't a long way away from upstream. 
Yes, it's really close, and I still hope it will happen eventually.
It will be a bit sad to see this counterexample go, though.

>  So yeah, this is a valid entry in the list, but again it's a
> very
>  'grandfathered' one, and one it would be practically very difficult to
>  do much about (trying to unpick Fedora from RHBZ has been talked about
>  more than once but is logistically a very difficult job). 
The close integration between Fedora and Red Hat Enterprise Linux bugs
has been quite helpful to us, too.  I also don't think CPE is eager to
run their own Bugzilla.

Thanks,
Florian

[Vít Ondruch]

Dne 01. 04. 20 v 19:28 Kevin Fenzi napsal(a):
>  On Wed, Apr 01, 2020 at 11:51:01AM +0200, clime wrote:
> > On Wed, 1 Apr 2020 at 10:54, Vít Ondruch <vondruch(a)redhat.com&gt; wrote:
> >> Do you mean https://github.com/fedora-infra/pkgdb2/ ? :)
>  No.
>
> > This is just hilarious, so after going all pagure for dist-git and
> > making it all work, we will now go back to pkgdb, additionally with
> > proprietary git backend, lol.
>  But pagure doesn't "just work". There's pagure-dist-git that does all
>  kinds of things to make src.fedoraproject.org have different things than
>  pagure.io. 
>
>  Do you consider pagure-dist-git to be pkgdb 1.5?
>
>  You missed where I said we should adjust our workflow and try and
>  minimize this layer. I wasn't suggesting we just make another app in
>  front of the git forge. I was suggesting we move all our "special" stuff
>  into git or otherwise adjust our workflow to make such a layer
>  nonexistant or as small as we can. 
>
>  How could we do that?
>
>  Well, there was the suggestion from Jermey that we use tags to store
>  this 'distro metadata'. Or perhaps we have files in each git repo, or a
>  branch or a seperate repo. This would not only mean we have less to
>  maintain, but it would mean we could move things much easier, people
>  could mirror them to another gitforge much easier, etc.  

But where are the UI bits?

Right, we did all the package management in tickets (which are git
repositories in backgroud) for a while, but that is really awful way of
doing things.

Also, a few years ago, when we moved to Pagure, I proposed that we
should have Readme in every dist-git repo with badges to replace the
PkdDB UI, but to my knowledge, there is available just Koschei badge,
which probably nobody uses.

As far as I care, the PkgDB was precisely what was doing this stuff.
Hopefully, it could be more lightweight on backend these days, but I am
still afraid we will need the UI if we move somewhere.


Vít


> > I mean if there is some alien race (or a human competitor) watching
> > what is happening in one of the leading linux distributions, they must
> > laugh hard. Well, we soon won't be leading.
>  I think you are misunderstanding me, but sure, laugh away. If you can't
>  laugh, you have to cry. ;) 
>
>  kevin
>
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]

[Panu Matilainen]

On 4/2/20 3:15 AM, clime wrote:
>  On Wed, 1 Apr 2020 at 23:22, Paul Frields <stickster(a)gmail.com&gt;
> wrote:
> >
> > On Wed, Apr 1, 2020 at 7:03 AM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
> >>
> >> On Wed, Apr 1, 2020 at 6:52 AM Nicolas Mailhot via devel
> >> <devel(a)lists.fedoraproject.org&gt; wrote:
> >>>
> >>> Le mercredi 01 avril 2020 à 11:30 +0100, Leigh Griffin a écrit :
> >>>>
> >>>> To distill it down:
> >>>>
> >>>> - Gitlab has more features that are needed right now for our
> >>>> stakeholder group
> >>>> - Gitlab has an entire company dedicated to roadmap features, we do
> >>>> not.
> >>>
> >>> Unfortunately, Gitlab’s roadmap is also conflicting with Fedora
> >>> objectives. The bread and butter of Gitlab is intermediating between
> >>> devs and end users, culling free software intermediaries like
> >>> distributions, and positionning itself in their stead. That is unlikely
> >>> to result in any commitment to making distribution workflows work.
> >>>
> >>> That would not be a problem if the disintermediation worked, but like
> >>> many actors Gitlab sees the $$$ and power in being the
> >>> desintermediator, and does not care if the result is deffective, as
> >>> long as $$$ and power flows its way.
> >>>
> >>
> >> It's also important to note that at the core of GitLab's incentive
> >> model is that they want to remove incentives to use FOSS solutions in
> >> favor of their unified proprietary solution. They are constantly
> >> integrating features and capabilities into the proprietary parts to
> >> make it "juicier" for enterprises who don't really have a
> compunction
> >> about whether they are using Free Software solutions or not, or even
> >> may not be willing to support them if it was Free Software because of
> >> outmoded thinking.
> >>
> >> The consequence of this is that it starves interest and development in
> >> FOSS solutions, and contributes to making the FOSS ecosystem weaker
> >> over time.
> >
> > 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.
>  
>  This is imho a contradictory statement. Github, being closed source
>  and pervasive, is a proof that open-source has won? 
Yes, this really is a bizarre statement.

It also assumes people are perfectly okay with this, whereas many of us 
are disgusted to the bone by this situation.

	- Panu -

[Neil Thompson]

Yeah, it's really starting to smell as though this whole process was a
"consultation" done in bad faith with a predetermined outcome.  Not what
one expects from Fedora/Red Hat.

On Thu, 2 Apr 2020 at 11:53, Panu Matilainen <pmatilai(a)redhat.com&gt; wrote:

>  On 4/2/20 3:15 AM, clime wrote:
>  > On Wed, 1 Apr 2020 at 23:22, Paul Frields <stickster(a)gmail.com&gt; wrote:
>  >>
>  >> On Wed, Apr 1, 2020 at 7:03 AM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  >>>
>  >>> On Wed, Apr 1, 2020 at 6:52 AM Nicolas Mailhot via devel
>  >>> <devel(a)lists.fedoraproject.org&gt; wrote:
>  >>>>
>  >>>> Le mercredi 01 avril 2020 à 11:30 +0100, Leigh Griffin a écrit :
>  >>>>>
>  >>>>> To distill it down:
>  >>>>>
>  >>>>> - Gitlab has more features that are needed right now for our
>  >>>>> stakeholder group
>  >>>>> - Gitlab has an entire company dedicated to roadmap features, we do
>  >>>>> not.
>  >>>>
>  >>>> Unfortunately, Gitlab’s roadmap is also conflicting with Fedora
>  >>>> objectives. The bread and butter of Gitlab is intermediating between
>  >>>> devs and end users, culling free software intermediaries like
>  >>>> distributions, and positionning itself in their stead. That is
>  unlikely
>  >>>> to result in any commitment to making distribution workflows work.
>  >>>>
>  >>>> That would not be a problem if the disintermediation worked, but like
>  >>>> many actors Gitlab sees the $$$ and power in being the
>  >>>> desintermediator, and does not care if the result is deffective, as
>  >>>> long as $$$ and power flows its way.
>  >>>>
>  >>>
>  >>> It's also important to note that at the core of GitLab's incentive
>  >>> model is that they want to remove incentives to use FOSS solutions in
>  >>> favor of their unified proprietary solution. They are constantly
>  >>> integrating features and capabilities into the proprietary parts to
>  >>> make it "juicier" for enterprises who don't really have a
> compunction
>  >>> about whether they are using Free Software solutions or not, or even
>  >>> may not be willing to support them if it was Free Software because of
>  >>> outmoded thinking.
>  >>>
>  >>> The consequence of this is that it starves interest and development in
>  >>> FOSS solutions, and contributes to making the FOSS ecosystem weaker
>  >>> over time.
>  >>
>  >> 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.
>  >
>  > This is imho a contradictory statement. Github, being closed source
>  > and pervasive, is a proof that open-source has won?
>
>  Yes, this really is a bizarre statement.
>
>  It also assumes people are perfectly okay with this, whereas many of us
>  are disgusted to the bone by this situation.
>
>          - Panu -
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>

[Bruno Wolff III]

On Wed, Apr 01, 2020 at 17:21:14 -0400,
  Paul Frields <stickster(a)gmail.com&gt; 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. 
I care more about free software than open source. Github, at least in the 
past, didn't really encourage free software and a lot of stuff hosted 
there didn't have a clear license.

Github is a problem, because it seems to be benefitting from network 
effects to pressure people to create accounts there. I was very happy 
when Pagure was announced, because it seemed that there would be a 
competitor that should at least do well amoung people who cared about 
free software. Hopefully that still happens, but this change will 
probably kill some of the momentum.

Github certainly does some good things and isn't currently a bad actor, 
but I don't think they are really in the free software camp.

[Iñaki Ucar]

On Thu, 2 Apr 2020 at 12:20, Neil Thompson <albiorix(a)gmail.com&gt; wrote:
>  Yeah, it's really starting to smell as though this whole process was a
> "consultation" done in bad faith with a predetermined outcome.  Not what one
> expects from Fedora/Red Hat. 
I am convinced that the consultation was done in good faith, and it
would be unfair to think otherwise. However, the smell of
predetermined outcome, in the sense that Pagure was never really an
option here, that was "considered" just out of deference but it was
never going to win, is what triggered this discussion and these
feelings.

-- 
Iñaki Úcar

[Leigh Griffin]

On Wed, Apr 1, 2020 at 7:28 PM Adam Williamson <adamwill(a)fedoraproject.org&gt;
wrote:

>  On Wed, 2020-04-01 at 11:49 +0200, Clement Verna wrote:
>  > On Wed, 1 Apr 2020 at 09:47, Panu Matilainen <pmatilai(a)redhat.com&gt;
>  wrote:
>  >
>  > > On 3/31/20 8:44 PM, Adam Williamson wrote:
>  > >
>  > > > I understand there are practical resource considerations and so on
>  > > > here, but I still think this merits more high level and serious
>  > > > consideration. At the very least, if we have somehow reached a point
>  > > > where Red Hat is no longer willing to provide sufficient resources to
>  > > > run Fedora on the lines the Fedora community wants it to be run, we
>  > > > need to recognize that this is a significant problem that needs to be
>  > > > properly aired and discussed and resolved. In this context I'll note
>  > > > that the apparent significant headcount reduction of RH people
>  working
>  > > > on Fedora infrastructure over the last few years is in itself a
>  > > > worrying trend, particularly if you consider it while reading
>  Clement's
>  > > > email.
>  > >
>  > > This.
>  > >
>  >
>  > I don't think this is correct, at least not in CPE, the team has grown
>  over
>  > the past year and every person leaving the team has been replaced (even
>  by
>  > 2 persons in some cases).
>
>  Okay, I didn't mean to get into detail, but I don't see how this is
>  possible. Unless you're considering 'CPE' as a whole (which includes
>  the infra admin team, release engineering, and docs) versus 'people
>  doing development'.
>
>  Around two-three years ago, IIRC, we had all these people working on
>  Fedora app/infra development:
>
>  puiterwijk (who counts as about ten people, admittedly, replacing
>  Patrick with anything besides an entire team was always going to be a
>  challenge)
>  Randy (bowlofeggs)
>  pingou
>  jcline
>  Ralph
>  jflory
>  abompard
>
>  Right now, I see these people who appear to be on the CPE team and
>  clearly working on Fedora infra/app development:
>
>  abompard?
>  lrossetti/odra (although I had not heard of or seen him till I started
>  doing research for this post, he seems to be working on fasjson which I
>  don't really run into)
>  pingou
>  scoady
>  cverna
>
>  I put a question mark by abompard as he clearly works for RH and works
>  a lot on infra, but (looking at internal systems) does not seem to be
>  quite in the same management chain as the others, not sure why that is.
>  
Jim and I are co-managers of the CPE team and the reporting is shared
between us for logistical reasons (i.e. number of direct reports)

>  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

>  If I'm missing anyone, please do correct me. 

Other developers in our pool right now are:
- Ryan Lerch
- 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.


>  Mattia Verga seems to do a
>  lot of work on Bodhi, but AFAICS he is not part of RH CPE. We could
>  count Ryan Lerch (UX) and/or Kevin Fenzi (who's officially admin, but
>  as we all know, does everything) in both list or neither.
>
>  Maybe the people I remember were not all there at exactly the same
>  time, I'm not 100% sure as I'm not on that team. But it does not feel
>  to me like we (RH) have the same level of personpower working on Fedora
>  app/infra development now as we did in 2018, put it that way.
>  
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.

>  The list at
>  https://fedoraproject.org/wiki/Community_Platform_Engineering seems to
>  be rather out of date; to my knowledge, Randy, Sayan, and Sinny are no
>  longer on the team, correct? Others in the list seem to work more or
>  less entirely on CentOS.
>  
Yup it's missing some folks, will get it updated.


>  >  The problem in my opinion is that a lot of the
>  > people that have setup and written the original services and applications
>  > are gone, taking with them most of the knowledge about How, What and Why
>  > something was done this way. That leaves people in the team now with a
>  big
>  > amount of legacy applications to take care of and not much clue of what
>  is
>  > going on.
>
>  I can believe this, though I'd also note that few of the apps are
>  original to the "last gen" team either. Bodhi was written by Luke, back
>  in the day, for instance, but Ralph did a great job of taking it over
>  (and fixing it up). fedmsg was written by Ralph, then handed off
>  successfully (AFAICS, anyway) to jcline. So we seem to have done these
>  kinds of hand off before with success. What changed there?
>  
An entire code base handed over to one person is not viable for a whole
host of reasons. For Rawhide Gating we had 6 Engineers on Bodhi for almost
7 months of last year and even that took one person to mind the lights on
work while the actual development progressed.


>  > There is also an historical taste to write in house applications
> for
>  things
>  > that don't really seems critical to the Fedora Project, for example do we
>  > really need a custom calendar application ? or election application ? It
>  > seems that every time we have a problem the solution is let's write
>  > something to solve that problem, instead of trying to find a compromise
>  and
>  > reuse existing solutions.
>
>  So on the whole I agree with this. I talked to Jim about this whole
>  situation at OSS 2018 and he was already thinking along the lines of
>  cutting some of the stuff we really don't need to be writing. I
>  entirely agree that it's a reasonable approach to ditch stuff like this
>  that is *relatively* external to the process of actually building a
>  distribution. I'd be kinda sad if it was replaced with proprietary SAAS
>  stuff, but I don't think it'd be as big of a problem as if we did that
>  with our dist-git.
>
>  I don't think we need to go into it in detail, but I *do* also
>  understand why we did it in the first place, and I think there's still
>  merit in that. For a start, it genuinely was the case back when a lot
>  of these apps were written that you couldn't so easily go out and "buy
>  one off the shelf", so to speak. But there's also the whole idea of
>  dogfooding, and the ecosystem. Again there's a historical angle to
>  this: it wasn't just for us but for the whole industry that it was more
>  common to build stuff in-house than outsource absolutely everything
>  besides your "core competency", as is the management fad these days. So
>  for us to build our own infrastructure was kind of a proof-of-concept
>  that Fedora *was* a suitable environment for *anyone* to do that: at
>  least at the time we felt that there was value in demonstrating that
>  Fedora provided an environment in which you *could* build and deploy
>  and maintain and use, you know, calendaring systems! and authentication
>  systems! and election apps! and so on and so forth.
>  
I genuinely tip my hat to the developers and sys admins that created such
solutions and made them open. Unfortunately as time went on and
contributors moved on to pastures new, the CPE team have inherited those
apps and must keep them alive, fix issues in them and in some cases enhance
them. That is what has bloomed our remit, not the creation of apps to solve
a problem that it was needed for, the long term maintenance and ownership
model of said projects. Many were created in the here and now and relied
heavily on that creator being engaged and responsive.

>  I agree that this has fallen out of fashion to an extent, and the
>  "let's just outsource everything that isn't actively building bits into
>  OS images" mindset is in tune with Current Industry Thinking and there
>  is a sustainable logic behind it. Personally I still think it comes
>  with significant issues, though, because there were a lot of what
>  management is pleased to call "intangibles" that went along with doing
>  all that work. We had an awful lot of "in-house" knowledge about a
>  whole range of stuff because we *did* build and maintain and deploy and
>  support all of these bits. Why do you think Patrick and Kevin can fix
>  just about anything? In large part because of all that experience.
>
>  Still, we're getting a bit into the weeds at that point. I'm not
>  arguing that we *must* continue to develop elections apps and calendars
>  and all of that stuff. To be clear, I'm not even arguing that we should
>  continue developing Pagure as part of CPE, or even necessarily host
>  Gitlab ourselves.
>
>  > Now when the CPE team goes and ask for more people because we struggle
>  with
>  > current situation, I can only guess that these non critical applications
>  > are mentioned. If I was putting my own money to sponsor a team to help
>  > building a Linux distribution I would be asking why do we have to
>  develop a
>  > calendar application or why do we need a custom git forge. I personally
>  > find really great that the different use cases and requirements for the
>  use
>  > of Pagure were gathered and I am convinced that people working on this
>  did
>  > their very best to find a use case to justify the investment needed in
>  > Pagure but it seems that we don't have such a thing.
>
>  I think other people are following up on this, but from following the
>  discussion, it appears to me that there seems to have been a large slip
>  somewhere along the line from Ben submitting a list of ~50 Fedora
>  submissions, to Leigh suggesting that (after those were, mysteriously,
>  "summarized" somehow) 

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.


>  Fedora does not have much in the way of specific
>  requirements. I also think the confusion between "git forge" and "dist-
>  git" is a major issue here. On the whole I suspect people using
>  Pagure.io for project hosting don't have a lot of very specific
>  requirements, because - let's be honest - Gitlab and Github can
>  certainly do nearly everything Pagure does as a generic project hosting
>  system. I could probably move my projects to a Gitlab instance in an
>  afternoon (depending on how much of a pain it is to set up F/OSS CI on
>  Gitlab, I have not looked into that yet, and yes, for anyone who hasn't
>  been looking lately, Pagure does actually have CI integration now).
>  However, I think we (Fedora) certainly *do* have a whole pile of
>  requirements for a dist-git system, and Leigh's responses so far (of
>  the "well we haven't figured all that out yet!" variety) do not give me
>  confidence that this was fully appreciated in the decision-making
>  process.
>  --
>  Adam Williamson
>  Fedora QA Community Monkey
>  IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
>  http://www.happyassassin.net
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  

-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford <https://www.redhat.com/>

Communications House

Cork Road, Waterford City

lgriffin(a)redhat.com
M: [phone]     IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>

[Leigh Griffin]

On Thu, Apr 2, 2020 at 8:05 AM Adam Williamson <adamwill(a)fedoraproject.org
>  
wrote:

>  On Wed, 2020-04-01 at 22:33 -0400, Randy Barlow wrote:
>  > On 4/1/20 1:16 PM, Adam Williamson wrote:
>  > > Has it been demonstrated that either Pagure or Gitlab CE are
>  > > "not viable" for the purposes Fedora needs?
> >  
>  > Hey Adam!
> >  
>  > I agree with you that Pagure and Gitlab CE are both
> viable for Fedora's
>  > needs in terms of feature matrices and requirements. We have shipped a
>  > handful or so of Fedora releases over the last 3ish years since src.fpo
>  > came online as proof!
> >  
>  > However, the CPE team does not have the resources to do a
> good job on
>  > maintaining that system, and Bodhi, and Koji, and the 187 other apps (I
>  > think we did count the apps we maintained at one point and ended up with
>  > a list that was about 190 long!). The responsibility to engineer ratio
>  > is not healthy or sustainable.
>
>  Okay, look, at a certain point I start to feel like we're trapped in
>  some sort of Kafka novel here.
>
>  At the outset of this whole mess, quite a lot of people said "well this
>  is obviously just all a pretext for dropping Pagure and going to hosted
>  Gitlab". Much offence seemed to be taken at this, and much was made of
>  this absolutely not being the case at all, and Pagure being definitely
>  a contender, and - as was pointed out upthread - how there would be
>  public meetings and feedback sessions and a whole three-ring circus
>  before a final decision was made. Which very definitely hadn't already
>  been made, or anything.
>  
We held the public consultation with each community. Fedora held public
dissemination of it's own requirements that were rolled up after a lengthy
discussion (almost 10 days beyond the deadline to roll up). Once that
closed we went into analysis mode and we didn't rightly or wrongly, share
the full user story list for every single stakeholder to debate and argue
about. I personally think it was the right call not to share it as already,
in several replies from people, the merit of some requirements making the
list was called out. That's not conducive to a debate when the requestor
might not be part of the community and when we as CPE genuinely take each
requirement at face value and it's not for us to debate or side on whether
it's a 'good or bad' requirement. Given the passionate responses here I
know that others feel that decision was wrong. I respect that viewpoint, I
don't have to agree with it, but I respect it.


>  And now three days into this thread, you're saying "well, CPE doesn't
>  have the resources to maintain Pagure". So, what, people were right in
>  the first place, and this was really just the Dump Pagure Project all
>  along?
>  
To be crystal clear, the exercise was to do check if we needed to invest in
Pagure (heavily or otherwise) and use those requirements to help set the
priority of our Git Forge solution, a solution we had ignored priority wise
as both a team and stakeholders (Fedora Council and CentOS Board) and which
was not harming us. Had Pagure been the choice, we would have invested in
it to bring it to the point we needed it and would have maintained it
longer term. We would have made it clear to stakeholders that the trade off
here was other features that we could not call on. That's why we ran this,
to arrive at that logical decision and not make an ill informed decision.


>  If so what was the point of all this half-baked kabuki nonsense? Why
>  not just say so up-front? 

Because it genuinely was not the case.

>  
If CPE never thought it had the resources to
>  maintain Pagure and Pagure was never really a contender, and Github
> was
>  as clearly a non-starter as Leigh says it was, why didn't we just say
>  "yeah no we're going to Gitlab" four months (or whatever it was) ago
>  and save all of this silliness? 

I'm going to be clear here. CPE does not have the resources to maintain
Pagure to the standard it needs to be. CPE does not have the resources to
maintain Bodhi to the standard it needs to be. CPE does not have the
resources to.......I can keep going but you get the picture. Randy is
correctly pointing out that from an Engineering capacity perspective, we
simply do not have the people power to maintain, build, drive, own and be
responsible for the lifecycle of a project that in truth needs a full time
team far beyond the current capacity of our team. Last year we invested all
our available developers to bring Bodhi to a point it could gate Rawhide.
We were prepared to make a similar investment in Pagure to bring it to a
point it met the requirements we had gathered. The difference here is that
finish line does not exist for Pagure as requirements we received have a
much larger long term onus on us as a team. That's why we ran it, to figure
out if we could do another long stint in a singular project to solve a real
problem we have. The requirements said this was not viable.


> We agree that this process wasn't
> actually very open at all, but *even if it had been*, if the result was
> preordained, what would have been the point?
>  
it was not preordained.

>  
> Also, why does CPE not *at least* have its ducks very
definitely in a
> row about exactly how much work is actually going to be involved in all
> the options here?


This analysis was ran side by side with a datacenter colo move across
country in the USA. The AAA project requirements and spin up for replacing
FAS. CentOS Stream requirements and phased deliverables. We took a decision
to not get as deep technically when the initial set of requirements was
trending towards Gitlab. This was a time investment trade off and now we
can schedule the deeper tech phase and are making moves in that direction
already.


>  How has this decision taken several months and yet
>  when people ask "okay, so exactly what is the plan for re-doing all the
>  Pagure<->dist-git integration with Gitlab, and how much work and how
>  long is that going to take?", the answer is "uh, we don't know, we're
>  going to figure it out now"? 

I hope the above explains it.


> Why does the blog post that announced this
> decision - talk quite a lot about what the plan is with regard to
> pagure.io (that's clearly what it usually means when it says "Pagure",
> in context) but nothing at all about what the plan is wrt dist-git?
>  
This was to ensure that the option for project hosting on pagure.io was
still there for community members who wish to store their source code in
Pagure. It was requested to be explicitly called out by Pingou to make it
crystal clear that this decision is not designed to kill Pagure. We are
happy to facilitate pagure.io as long as the community find it useful and
hopefully we will get interest in helping to maintain that.


>  
> Not to mention that this subthread is about the
circumstances in which
> Fedora has decided it will accept non-free infra, and that "not viable
> and not available" quote. If we count absolutely anything that involves
> CPE actually doing any work beyond paying someone else to run it as
> "not viable", well, yeah, that's going to render an awful lot of stuff
> "not viable", isn't it? But I don't think that's how many
people would
> necessarily have expected that text to be interpreted.
> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  

-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford <https://www.redhat.com/
>  
Communications House

Cork Road, Waterford City

lgriffin(a)redhat.com
M: [phone]     IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs
>
<https://red.ht/sig
>

[Florian Weimer]

* Paul Frields:

>  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. 
For those who think this statement is bizarre: Gmail is also strongly
associated with open-source development, but is not itself open source.
Many people also seem to believe they do open-source development once
their proprietary product targets GNU/Linux (as opposed to Windows or
Android).

Meanwhile, some of us struggle with being accepted as open source
because we offer corresponding source code along with binaries,
but neither is freely downloadable from the public Internet.

To me, that suggests that the term “open source” has become largely
meaningless.  The concept is still important to me, but the term itself
is about as ambiguous now as “free software” always was.

Thanks,
Florian

[clime]

On Thu, 2 Apr 2020 at 12:54, Leigh Griffin <lgriffin(a)redhat.com&gt; wrote:

>  On Wed, Apr 1, 2020 at 7:28 PM Adam Williamson <adamwill(a)fedoraproject.org&gt;
>  wrote:
>
> > On Wed, 2020-04-01 at 11:49 +0200, Clement Verna wrote:
> > > On Wed, 1 Apr 2020 at 09:47, Panu Matilainen <pmatilai(a)redhat.com&gt;
> > wrote:
> > >
> > > > On 3/31/20 8:44 PM, Adam Williamson wrote:
> > > >
> > > > > I understand there are practical resource considerations and so on
> > > > > here, but I still think this merits more high level and serious
> > > > > consideration. At the very least, if we have somehow reached a point
> > > > > where Red Hat is no longer willing to provide sufficient resources
> > to
> > > > > run Fedora on the lines the Fedora community wants it to be run, we
> > > > > need to recognize that this is a significant problem that needs to
> > be
> > > > > properly aired and discussed and resolved. In this context I'll
> note
> > > > > that the apparent significant headcount reduction of RH people
> > working
> > > > > on Fedora infrastructure over the last few years is in itself a
> > > > > worrying trend, particularly if you consider it while reading
> > Clement's
> > > > > email.
> > > >
> > > > This.
> > > >
> > >
> > > I don't think this is correct, at least not in CPE, the team has grown
> > over
> > > the past year and every person leaving the team has been replaced (even
> > by
> > > 2 persons in some cases).
> >
> > Okay, I didn't mean to get into detail, but I don't see how this is
> > possible. Unless you're considering 'CPE' as a whole (which includes
> > the infra admin team, release engineering, and docs) versus 'people
> > doing development'.
> >
> > Around two-three years ago, IIRC, we had all these people working on
> > Fedora app/infra development:
> >
> > puiterwijk (who counts as about ten people, admittedly, replacing
> > Patrick with anything besides an entire team was always going to be a
> > challenge)
> > Randy (bowlofeggs)
> > pingou
> > jcline
> > Ralph
> > jflory
> > abompard
> >
> > Right now, I see these people who appear to be on the CPE team and
> > clearly working on Fedora infra/app development:
> >
> > abompard?
> > lrossetti/odra (although I had not heard of or seen him till I started
> > doing research for this post, he seems to be working on fasjson which I
> > don't really run into)
> > pingou
> > scoady
> > cverna
> >
> > I put a question mark by abompard as he clearly works for RH and works
> > a lot on infra, but (looking at internal systems) does not seem to be
> > quite in the same management chain as the others, not sure why that is.
> >
>
>  Jim and I are co-managers of the CPE team and the reporting is shared
>  between us for logistical reasons (i.e. number of direct reports)
>
> > 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
>
> >
> > If I'm missing anyone, please do correct me.
>
>
>  Other developers in our pool right now are:
>  - Ryan Lerch
>  - 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.
>
>
> > Mattia Verga seems to do a
> > lot of work on Bodhi, but AFAICS he is not part of RH CPE. We could
> > count Ryan Lerch (UX) and/or Kevin Fenzi (who's officially admin, but
> > as we all know, does everything) in both list or neither.
> >
> > Maybe the people I remember were not all there at exactly the same
> > time, I'm not 100% sure as I'm not on that team. But it does not feel
> > to me like we (RH) have the same level of personpower working on Fedora
> > app/infra development now as we did in 2018, put it that way.
> >
>
>  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.
>
> >
> > The list at
> > https://fedoraproject.org/wiki/Community_Platform_Engineering seems to
> > be rather out of date; to my knowledge, Randy, Sayan, and Sinny are no
> > longer on the team, correct? Others in the list seem to work more or
> > less entirely on CentOS.
> >
>
>  Yup it's missing some folks, will get it updated.
>
>
> >
> > >  The problem in my opinion is that a lot of the
> > > people that have setup and written the original services and
> > applications
> > > are gone, taking with them most of the knowledge about How, What and Why
> > > something was done this way. That leaves people in the team now with a
> > big
> > > amount of legacy applications to take care of and not much clue of what
> > is
> > > going on.
> >
> > I can believe this, though I'd also note that few of the apps are
> > original to the "last gen" team either. Bodhi was written by Luke, back
> > in the day, for instance, but Ralph did a great job of taking it over
> > (and fixing it up). fedmsg was written by Ralph, then handed off
> > successfully (AFAICS, anyway) to jcline. So we seem to have done these
> > kinds of hand off before with success. What changed there?
> >
>
>  An entire code base handed over to one person is not viable for a whole
>  host of reasons. For Rawhide Gating we had 6 Engineers on Bodhi for almost
>  7 months of last year and even that took one person to mind the lights on
>  work while the actual development progressed.
>
>
> > > There is also an historical taste to write in house applications for
> > things
> > > that don't really seems critical to the Fedora Project, for example do
> > we
> > > really need a custom calendar application ? or election application ? It
> > > seems that every time we have a problem the solution is let's write
> > > something to solve that problem, instead of trying to find a compromise
> > and
> > > reuse existing solutions.
> >
> > So on the whole I agree with this. I talked to Jim about this whole
> > situation at OSS 2018 and he was already thinking along the lines of
> > cutting some of the stuff we really don't need to be writing. I
> > entirely agree that it's a reasonable approach to ditch stuff like this
> > that is *relatively* external to the process of actually building a
> > distribution. I'd be kinda sad if it was replaced with proprietary SAAS
> > stuff, but I don't think it'd be as big of a problem as if we did that
> > with our dist-git.
> >
> > I don't think we need to go into it in detail, but I *do* also
> > understand why we did it in the first place, and I think there's still
> > merit in that. For a start, it genuinely was the case back when a lot
> > of these apps were written that you couldn't so easily go out and "buy
> > one off the shelf", so to speak. But there's also the whole idea of
> > dogfooding, and the ecosystem. Again there's a historical angle to
> > this: it wasn't just for us but for the whole industry that it was more
> > common to build stuff in-house than outsource absolutely everything
> > besides your "core competency", as is the management fad these days. So
> > for us to build our own infrastructure was kind of a proof-of-concept
> > that Fedora *was* a suitable environment for *anyone* to do that: at
> > least at the time we felt that there was value in demonstrating that
> > Fedora provided an environment in which you *could* build and deploy
> > and maintain and use, you know, calendaring systems! and authentication
> > systems! and election apps! and so on and so forth.
> >
>
>  I genuinely tip my hat to the developers and sys admins that created such
>  solutions and made them open. Unfortunately as time went on and
>  contributors moved on to pastures new, the CPE team have inherited those
>  apps and must keep them alive, fix issues in them and in some cases enhance
>  them. That is what has bloomed our remit, not the creation of apps to solve
>  a problem that it was needed for, the long term maintenance and ownership
>  model of said projects. Many were created in the here and now and relied
>  heavily on that creator being engaged and responsive.
>
> >
> > I agree that this has fallen out of fashion to an extent, and the
> > "let's just outsource everything that isn't actively building bits into
> > OS images" mindset is in tune with Current Industry Thinking and there
> > is a sustainable logic behind it. Personally I still think it comes
> > with significant issues, though, because there were a lot of what
> > management is pleased to call "intangibles" that went along with doing
> > all that work. We had an awful lot of "in-house" knowledge about a
> > whole range of stuff because we *did* build and maintain and deploy and
> > support all of these bits. Why do you think Patrick and Kevin can fix
> > just about anything? In large part because of all that experience.
> >
> > Still, we're getting a bit into the weeds at that point. I'm not
> > arguing that we *must* continue to develop elections apps and calendars
> > and all of that stuff. To be clear, I'm not even arguing that we should
> > continue developing Pagure as part of CPE, or even necessarily host
> > Gitlab ourselves.
> >
> > > Now when the CPE team goes and ask for more people because we struggle
> > with
> > > current situation, I can only guess that these non critical applications
> > > are mentioned. If I was putting my own money to sponsor a team to help
> > > building a Linux distribution I would be asking why do we have to
> > develop a
> > > calendar application or why do we need a custom git forge. I personally
> > > find really great that the different use cases and requirements for the
> > use
> > > of Pagure were gathered and I am convinced that people working on this
> > did
> > > their very best to find a use case to justify the investment needed in
> > > Pagure but it seems that we don't have such a thing.
> >
> > I think other people are following up on this, but from following the
> > discussion, it appears to me that there seems to have been a large slip
> > somewhere along the line from Ben submitting a list of ~50 Fedora
> > submissions, to Leigh suggesting that (after those were, mysteriously,
> > "summarized" somehow)
>
>
>  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.
>  
Can you show the analysis of the points from:
https://hackmd.io/@My419-DISUGgo4gcmO1D6A/HJB74lcL8 ?

My question is why didn't you do the analysis, then show it to the
community for feedback while saying: "hey, we can't quite do with our
current resources and setup, some help needed?". Or did you do it? If yes,
I missed it.

I would still like to see the analysis. Maybe we will find ways to simplify
on your intended solutions with pagure for each given point so that it will
be clear that pagure is actually more than sufficient for us. It would be
also good to see the stakeholder from which the request originated and
priority it was assigned to it but I think you don't have this information,
so, please, show at least what you currently have.

Thank you
clime


> > Fedora does not have much in the way of specific
> > requirements. I also think the confusion between "git forge" and
> "dist-
> > git" is a major issue here. On the whole I suspect people using
> > Pagure.io for project hosting don't have a lot of very specific
> > requirements, because - let's be honest - Gitlab and Github can
> > certainly do nearly everything Pagure does as a generic project hosting
> > system. I could probably move my projects to a Gitlab instance in an
> > afternoon (depending on how much of a pain it is to set up F/OSS CI on
> > Gitlab, I have not looked into that yet, and yes, for anyone who hasn't
> > been looking lately, Pagure does actually have CI integration now).
> > However, I think we (Fedora) certainly *do* have a whole pile of
> > requirements for a dist-git system, and Leigh's responses so far (of
> > the "well we haven't figured all that out yet!" variety) do not give
> me
> > confidence that this was fully appreciated in the decision-making
> > process.
> > --
> > Adam Williamson
> > Fedora QA Community Monkey
> > IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> > http://www.happyassassin.net
> > _______________________________________________
> > devel mailing list -- devel(a)lists.fedoraproject.org
> > To unsubscribe send an email to devel-leave(a)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/[e-mail]
> >
>
>
>  --
>
>  Leigh Griffin
>
>  Engineering Manager
>
>  Red Hat Waterford <https://www.redhat.com/>
>
>  Communications House
>
>  Cork Road, Waterford City
>
>  lgriffin(a)redhat.com
>  M: [phone]     IM: lgriffin
>  @redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
>  <https://www.facebook.com/redhatjobs> @redhatjobs
>  <https://instagram.com/redhatjobs>
>  <https://red.ht/sig>
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>

[Adam Saleh]

To be honest, I didn't really have energy to read all of the thread, by
skimming it,
I would like to add my thoughts w.r.t. the path forward.

I really like the idea of having a RedHat/Fedora/CentOS provided an
supported GitLab.

But as we plan to ahe gitlab as the alternative to pagure as both gitforge
and distgit,
this sounds like two projects, with two distinct pilots and testing periods
and re-evaluation.

What I really want to be mindful are sunk-cost fallacies and
unknown-unknowns.
So we need to be able to say "we tried but we need more resources" or even
"we tried but it is not working out and we are pulling the plug".

We might get to a point where we'd see that GitLab is a great forge, but we
drastically underestimated resources
to actually support migration to use it as a new dist-git.

I have been through a plan to replace an established but
under-staffed/under-developed tool at RedHat.
As a QE at RedHat, I have been through a switch from our
TestCaseManagementSystem to Polarion.
These days we mostly use it as an excellent example how not to replace
tools in your company :D

There was almost no pilot, limited testing-period, and little support for
people attempting to migrate,
especially as we were starting to see how the tool didn't fit the volume of
test-cases we wanted to store there.

I have a fair degree of trust that we will introduce GitLab in a more
reasonable way :-)

Adam

[Leigh Griffin]

On Thu, Apr 2, 2020 at 1:22 PM clime <clime(a)fedoraproject.org&gt; wrote:

>  On Thu, 2 Apr 2020 at 12:54, Leigh Griffin <lgriffin(a)redhat.com&gt; wrote:
>
> >
> >
> > On Wed, Apr 1, 2020 at 7:28 PM Adam Williamson <
> > adamwill(a)fedoraproject.org&gt; wrote:
> >
> >> On Wed, 2020-04-01 at 11:49 +0200, Clement Verna wrote:
> >> > On Wed, 1 Apr 2020 at 09:47, Panu Matilainen <pmatilai(a)redhat.com&gt;
> >> wrote:
> >> >
> >> > > On 3/31/20 8:44 PM, Adam Williamson wrote:
> >> > >
> >> > > > I understand there are practical resource considerations and so
> on
> >> > > > here, but I still think this merits more high level and serious
> >> > > > consideration. At the very least, if we have somehow reached a
> >> point
> >> > > > where Red Hat is no longer willing to provide sufficient
> resources
> >> to
> >> > > > run Fedora on the lines the Fedora community wants it to be run,
> we
> >> > > > need to recognize that this is a significant problem that needs
> to
> >> be
> >> > > > properly aired and discussed and resolved. In this context
> I'll
> >> note
> >> > > > that the apparent significant headcount reduction of RH people
> >> working
> >> > > > on Fedora infrastructure over the last few years is in itself a
> >> > > > worrying trend, particularly if you consider it while reading
> >> Clement's
> >> > > > email.
> >> > >
> >> > > This.
> >> > >
> >> >
> >> > I don't think this is correct, at least not in CPE, the team has grown
> >> over
> >> > the past year and every person leaving the team has been replaced
> >> (even by
> >> > 2 persons in some cases).
> >>
> >> Okay, I didn't mean to get into detail, but I don't see how this is
> >> possible. Unless you're considering 'CPE' as a whole (which includes
> >> the infra admin team, release engineering, and docs) versus 'people
> >> doing development'.
> >>
> >> Around two-three years ago, IIRC, we had all these people working on
> >> Fedora app/infra development:
> >>
> >> puiterwijk (who counts as about ten people, admittedly, replacing
> >> Patrick with anything besides an entire team was always going to be a
> >> challenge)
> >> Randy (bowlofeggs)
> >> pingou
> >> jcline
> >> Ralph
> >> jflory
> >> abompard
> >>
> >> Right now, I see these people who appear to be on the CPE team and
> >> clearly working on Fedora infra/app development:
> >>
> >> abompard?
> >> lrossetti/odra (although I had not heard of or seen him till I started
> >> doing research for this post, he seems to be working on fasjson which I
> >> don't really run into)
> >> pingou
> >> scoady
> >> cverna
> >>
> >> I put a question mark by abompard as he clearly works for RH and works
> >> a lot on infra, but (looking at internal systems) does not seem to be
> >> quite in the same management chain as the others, not sure why that is.
> >>
> >
> > Jim and I are co-managers of the CPE team and the reporting is shared
> > between us for logistical reasons (i.e. number of direct reports)
> >
> >> 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
> >
> >>
> >> If I'm missing anyone, please do correct me.
> >
> >
> > Other developers in our pool right now are:
> > - Ryan Lerch
> > - 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.
> >
> >
> >> Mattia Verga seems to do a
> >> lot of work on Bodhi, but AFAICS he is not part of RH CPE. We could
> >> count Ryan Lerch (UX) and/or Kevin Fenzi (who's officially admin, but
> >> as we all know, does everything) in both list or neither.
> >>
> >> Maybe the people I remember were not all there at exactly the same
> >> time, I'm not 100% sure as I'm not on that team. But it does not feel
> >> to me like we (RH) have the same level of personpower working on Fedora
> >> app/infra development now as we did in 2018, put it that way.
> >>
> >
> > 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.
> >
> >>
> >> The list at
> >> https://fedoraproject.org/wiki/Community_Platform_Engineering seems to
> >> be rather out of date; to my knowledge, Randy, Sayan, and Sinny are no
> >> longer on the team, correct? Others in the list seem to work more or
> >> less entirely on CentOS.
> >>
> >
> > Yup it's missing some folks, will get it updated.
> >
> >
> >>
> >> >  The problem in my opinion is that a lot of the
> >> > people that have setup and written the original services and
> >> applications
> >> > are gone, taking with them most of the knowledge about How, What and
> >> Why
> >> > something was done this way. That leaves people in the team now with a
> >> big
> >> > amount of legacy applications to take care of and not much clue of
> >> what is
> >> > going on.
> >>
> >> I can believe this, though I'd also note that few of the apps are
> >> original to the "last gen" team either. Bodhi was written by Luke,
> back
> >> in the day, for instance, but Ralph did a great job of taking it over
> >> (and fixing it up). fedmsg was written by Ralph, then handed off
> >> successfully (AFAICS, anyway) to jcline. So we seem to have done these
> >> kinds of hand off before with success. What changed there?
> >>
> >
> > An entire code base handed over to one person is not viable for a whole
> > host of reasons. For Rawhide Gating we had 6 Engineers on Bodhi for almost
> > 7 months of last year and even that took one person to mind the lights on
> > work while the actual development progressed.
> >
> >
> >> > There is also an historical taste to write in house applications for
> >> things
> >> > that don't really seems critical to the Fedora Project, for example do
> >> we
> >> > really need a custom calendar application ? or election application ?
> >> It
> >> > seems that every time we have a problem the solution is let's write
> >> > something to solve that problem, instead of trying to find a
> >> compromise and
> >> > reuse existing solutions.
> >>
> >> So on the whole I agree with this. I talked to Jim about this whole
> >> situation at OSS 2018 and he was already thinking along the lines of
> >> cutting some of the stuff we really don't need to be writing. I
> >> entirely agree that it's a reasonable approach to ditch stuff like this
> >> that is *relatively* external to the process of actually building a
> >> distribution. I'd be kinda sad if it was replaced with proprietary SAAS
> >> stuff, but I don't think it'd be as big of a problem as if we did that
> >> with our dist-git.
> >>
> >> I don't think we need to go into it in detail, but I *do* also
> >> understand why we did it in the first place, and I think there's still
> >> merit in that. For a start, it genuinely was the case back when a lot
> >> of these apps were written that you couldn't so easily go out and "buy
> >> one off the shelf", so to speak. But there's also the whole idea of
> >> dogfooding, and the ecosystem. Again there's a historical angle to
> >> this: it wasn't just for us but for the whole industry that it was more
> >> common to build stuff in-house than outsource absolutely everything
> >> besides your "core competency", as is the management fad these days.
> So
> >> for us to build our own infrastructure was kind of a proof-of-concept
> >> that Fedora *was* a suitable environment for *anyone* to do that: at
> >> least at the time we felt that there was value in demonstrating that
> >> Fedora provided an environment in which you *could* build and deploy
> >> and maintain and use, you know, calendaring systems! and authentication
> >> systems! and election apps! and so on and so forth.
> >>
> >
> > I genuinely tip my hat to the developers and sys admins that created such
> > solutions and made them open. Unfortunately as time went on and
> > contributors moved on to pastures new, the CPE team have inherited those
> > apps and must keep them alive, fix issues in them and in some cases enhance
> > them. That is what has bloomed our remit, not the creation of apps to solve
> > a problem that it was needed for, the long term maintenance and ownership
> > model of said projects. Many were created in the here and now and relied
> > heavily on that creator being engaged and responsive.
> >
> >>
> >> I agree that this has fallen out of fashion to an extent, and the
> >> "let's just outsource everything that isn't actively building bits
> into
> >> OS images" mindset is in tune with Current Industry Thinking and there
> >> is a sustainable logic behind it. Personally I still think it comes
> >> with significant issues, though, because there were a lot of what
> >> management is pleased to call "intangibles" that went along with doing
> >> all that work. We had an awful lot of "in-house" knowledge about a
> >> whole range of stuff because we *did* build and maintain and deploy and
> >> support all of these bits. Why do you think Patrick and Kevin can fix
> >> just about anything? In large part because of all that experience.
> >>
> >> Still, we're getting a bit into the weeds at that point. I'm not
> >> arguing that we *must* continue to develop elections apps and calendars
> >> and all of that stuff. To be clear, I'm not even arguing that we should
> >> continue developing Pagure as part of CPE, or even necessarily host
> >> Gitlab ourselves.
> >>
> >> > Now when the CPE team goes and ask for more people because we struggle
> >> with
> >> > current situation, I can only guess that these non critical
> >> applications
> >> > are mentioned. If I was putting my own money to sponsor a team to help
> >> > building a Linux distribution I would be asking why do we have to
> >> develop a
> >> > calendar application or why do we need a custom git forge. I personally
> >> > find really great that the different use cases and requirements for
> >> the use
> >> > of Pagure were gathered and I am convinced that people working on this
> >> did
> >> > their very best to find a use case to justify the investment needed in
> >> > Pagure but it seems that we don't have such a thing.
> >>
> >> I think other people are following up on this, but from following the
> >> discussion, it appears to me that there seems to have been a large slip
> >> somewhere along the line from Ben submitting a list of ~50 Fedora
> >> submissions, to Leigh suggesting that (after those were, mysteriously,
> >> "summarized" somehow)
> >
> >
> > 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.
> >
>
>  Can you show the analysis of the points from:
>  https://hackmd.io/@My419-DISUGgo4gcmO1D6A/HJB74lcL8 ?
>  
I am distilling down the main points and analysis to share with the
communities.

>  My question is why didn't you do the analysis, then show it to the
>  community for feedback while saying: "hey, we can't quite do with our
>  current resources and setup, some help needed?". Or did you do it? If yes,
>  I missed it.
>  
As stated several times it is my belief that the sharing of the analysis
for feedback would not be productive as we don't have a singular means for
all stakeholders to communicate and debate requirements. It would be unfair
for RHEL and CentOS stakeholder requirements to be debated and attacked on
the Fedora mailing lists and vice versa. A community crusade to bridge the
feature gap is a non guarantee in a non specific timeframe, due to the very
nature of volunteer oriented development. Requesting that assistance would
not have changed the requirements based decision based on timeline for an
implementation, development gap to meet that timeline and future
commitments.


>  I would still like to see the analysis. Maybe we will find ways to
>  simplify on your intended solutions with pagure for each given point so
>  that it will be clear that pagure is actually more than sufficient for us.
>  It would be also good to see the stakeholder from which the request
>  originated and priority it was assigned to it but I think you don't have
>  this information, so, please, show at least what you currently have.
>  
The distilled version I will share out as promised but I'm unsure whether I
will get stakeholder buyin to share their verbatim requirements, as the
creation of those requirements intertwined with operational needs ( int he
case of RHEL) and there was never an agreed expectation to share them as
such.

All stakeholders had equal priority. All core functional requirements held
equal priority, all non functional or entirely optional requirements were
not weighed into the decision as they were deemed nice to have e.g. mobile
app capabilities was a nice to have and wasn't even a consideration in the
final decision.

>  Thank you
>  clime
>
>
> >
> >
> >> Fedora does not have much in the way of specific
> >> requirements. I also think the confusion between "git forge" and
> "dist-
> >> git" is a major issue here. On the whole I suspect people using
> >> Pagure.io for project hosting don't have a lot of very specific
> >> requirements, because - let's be honest - Gitlab and Github can
> >> certainly do nearly everything Pagure does as a generic project hosting
> >> system. I could probably move my projects to a Gitlab instance in an
> >> afternoon (depending on how much of a pain it is to set up F/OSS CI on
> >> Gitlab, I have not looked into that yet, and yes, for anyone who hasn't
> >> been looking lately, Pagure does actually have CI integration now).
> >> However, I think we (Fedora) certainly *do* have a whole pile of
> >> requirements for a dist-git system, and Leigh's responses so far (of
> >> the "well we haven't figured all that out yet!" variety) do not
> give me
> >> confidence that this was fully appreciated in the decision-making
> >> process.
> >> --
> >> Adam Williamson
> >> Fedora QA Community Monkey
> >> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> >> http://www.happyassassin.net
> >> _______________________________________________
> >> devel mailing list -- devel(a)lists.fedoraproject.org
> >> To unsubscribe send an email to devel-leave(a)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/[e-mail]
> >>
> >
> >
> > --
> >
> > Leigh Griffin
> >
> > Engineering Manager
> >
> > Red Hat Waterford <https://www.redhat.com/>
> >
> > Communications House
> >
> > Cork Road, Waterford City
> >
> > lgriffin(a)redhat.com
> > M: [phone]     IM: lgriffin
> > @redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
> > <https://www.facebook.com/redhatjobs> @redhatjobs
> > <https://instagram.com/redhatjobs>
> > <https://red.ht/sig>
> > _______________________________________________
> > devel mailing list -- devel(a)lists.fedoraproject.org
> > To unsubscribe send an email to devel-leave(a)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/[e-mail]
> >
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  

-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford <https://www.redhat.com/>

Communications House

Cork Road, Waterford City

lgriffin(a)redhat.com
M: [phone]     IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>

[Randy Barlow]

On 4/2/20 3:03 AM, Adam Williamson wrote:
>  At the outset of this whole mess, quite a lot of people said
> "well this
>  is obviously just all a pretext for dropping Pagure and going to hosted
>  Gitlab". Much offence seemed to be taken at this, and much was made of
>  this absolutely not being the case at all, and Pagure being definitely
>  a contender, and - as was pointed out upthread - how there would be
>  public meetings and feedback sessions and a whole three-ring circus
>  before a final decision was made. Which very definitely hadn't already
>  been made, or anything.
>  
>  And now three days into this thread, you're saying "well, CPE doesn't
>  have the resources to maintain Pagure". So, what, people were right in
>  the first place, and this was really just the Dump Pagure Project all
>  along?
>  
>  If so what was the point of all this half-baked kabuki nonsense? Why
>  not just say so up-front? If CPE never thought it had the resources to
>  maintain Pagure and Pagure was never really a contender, and Github was
>  as clearly a non-starter as Leigh says it was, why didn't we just say
>  "yeah no we're going to Gitlab" four months (or whatever it was) ago
>  and save all of this silliness? We agree that this process wasn't
>  actually very open at all, but*even if it had been*, if the result was
>  preordained, what would have been the point? 
I agree with you.

[Michael Catanzaro]

On Wed, Apr 1, 2020 at 8:16 pm, Paul Frields <stickster(a)gmail.com&gt; 
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. 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

[Neal Gompa]

On Thu, Apr 2, 2020 at 10:57 AM Michael Catanzaro <mcatanzaro(a)gnome.org&gt; wrote:
>  On Wed, Apr 1, 2020 at 8:16 pm, Paul Frields <stickster(a)gmail.com&gt;
>  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. 
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.

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.



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Stephen John Smoogen]

On Thu, 2 Apr 2020 at 10:57, Michael Catanzaro <mcatanzaro(a)gnome.org&gt; wrote:

>  On Wed, Apr 1, 2020 at 8:16 pm, Paul Frields
> <stickster(a)gmail.com&gt;
>  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
>  
I think one of the problems is that every person here says they know what
Fedora needs and quite frankly after you add up all the things it comes
into the grab bag we got for a Git replacement. You have your opinions, and
so do 800 other developers. Right now the people who want a complete FLOSS
solution are yelling but for the last 5+ years the people who have been
yelling that GitLab/GitHub was a better solution have been yelling. Those
complaints have been just as strong and vociferous with lots of
insinuations about wasting time, money, and resources when Git* was there.
I have seen multiple infra people burn out trying to keep up with all the
features that various Fedora groups said was ESSENTIAL and complained
enough that they would go elsewhere if it didn't happen.

In the end, we have to realize that the Fedora community is not a solid
mass and there is rarely a clear majority.  The infrastructure we have is a
highly complicated mess of interlocking tools to try and deal with the fact
there is no majority of what people want, and that they want new stuff
every 3-5 months added. That continually adding complexity has made getting
people involved in infrastructure harder and harder because for every group
which said 'oh drop this, it isn't needed' there were multiple groups
saying 'we use this heavily and would stop existing if you took it away'.
And whenever a primary team decides they can't handle it anymore.. oh that
is what Red Hat pays Infrastructure to do.. they can add it.

We tried to have a 'heroes' program to get people added in like we used to
but so much stuff is so intertwined and needing only limited access that it
is pretty impossible to allow anyone an ability to look at it. [I regularly
find I can't drop something to the community because it contains personal
information and the GDPR and other regs say it is now something which must
have limited access and must be treated properly. I fundamentally agree
that is the right thing for people's private information so I end up not
being able to allow anyone else to work on it.] Trying to say 'ok well
start over and take over responsibility for any data collected' has been a
flop because 'too much work and too much responsibility' as one person told
me.

-- 
Stephen J Smoogen.

[Neal Gompa]

On Thu, Apr 2, 2020 at 11:43 AM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  Red Hat CPE team, and as indicated earlier somewhere, CPE team is not
>  a community team. 
I want to correct myself here. I do not personally believe that CPE
team is not part of the community. All the members of the team are
valued members of the community, and I've personally worked with many
of them quite well.


-- 
真実はいつも一つ！/ Always, there's only one truth!

Full history of linux kernel (Re: CPE Git Forge Decision)

[Petr Viktorin]

On 2020-03-31 21:39, Przemek Klosowski via devel wrote:
[...]> Still, the
>  official Linux git log ( 
>  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?o... 
>  ) lacks the development history preceding 2005-04-16, and starts with 
>  one heck of a commit:
>   

FWIW, this is mainly because early Git was unable to cope with huge 
histories, converting old history to another format isn't 
straighforward, and the history is immutable.

Earlier history is out there and there are ways to `graft` it to a 
current repo to locally join the histories together. See e.g. 
https://stackoverflow.com/a/8130239/99057

[Robbie Harwood]

Paul Frields <stickster(a)gmail.com&gt; writes:

>  Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
> > Nicolas Mailhot wrote:
> >> Leigh Griffin a écrit :
> >>
> >>> To distill it down:
> >>>
> >>> - Gitlab has more features that are needed right now for our
> >>> stakeholder group
> >>> - Gitlab has an entire company dedicated to roadmap features, we do
> >>> not.
> >>
> >> Unfortunately, Gitlab’s roadmap is also conflicting with Fedora
> >> objectives. The bread and butter of Gitlab is intermediating between
> >> devs and end users, culling free software intermediaries like
> >> distributions, and positionning itself in their stead. That is
> >> unlikely to result in any commitment to making distribution
> >> workflows work.
> >>
> >> That would not be a problem if the disintermediation worked, but
> >> like many actors Gitlab sees the $$$ and power in being the
> >> desintermediator, and does not care if the result is deffective, as
> >> long as $$$ and power flows its way.
> >
> > It's also important to note that at the core of GitLab's incentive
> > model is that they want to remove incentives to use FOSS solutions in
> > favor of their unified proprietary solution. They are constantly
> > integrating features and capabilities into the proprietary parts to
> > make it "juicier" for enterprises who don't really have a compunction
> > about whether they are using Free Software solutions or not, or even
> > may not be willing to support them if it was Free Software because of
> > outmoded thinking.
> >
> > The consequence of this is that it starves interest and development in
> > FOSS solutions, and contributes to making the FOSS ecosystem weaker
> > over time.
>
>  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, 
I assume you didn't mean quite that.  Sure, it's not totally open
source, but it's built on and uses open source tools, just like many
other applications.  In a personal example, I've fixed something on
github by patching https://github.com/jch/html-pipeline/ .  Or more
bulk, there are 340 repos at https://github.com/github .

Thanks,
--Robbie

[Matthew Miller]

On Wed, Apr 01, 2020 at 02:49:13PM -0600, Chris Murphy wrote:
>  I agree, and wonder about this too. But such a conversation
>  immediately runs into the delicate and awkward realm of corporate
>  politics: would Red Hat even allow other sponsors, and what are the
>  parameters by which this could even happen - it's not clear to me at
>  all. 
I can answer some of this. I don't think Red Hat has any fundamental
objection to other large sponsors. (We do have many non-Red Hat smaller
sponsors, generally through non-monitary contributions. See
https://getfedora.org/sponsors/). But, who would these other sponsors be?
Red Hat's annual investment in Fedora is in the many millions of dollars.
Someone else with that kind of money to invest probably has other plans.


-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Matthew Miller]

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


-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Adam Williamson]

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

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

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

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. 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 to maintain all the projects we have already" is the 
recurring refrain here.

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.

James I didn't count as he's listed as an intern. But here's his Github 
log (I can't find him on Pagure):

https://github.com/james02135

so I don't mean this as a knock at all, but he's obviously not 
equivalent to one regular full-time dev, nor would we (I hope) expect 
him to be.

So if we include Ryan on both lists and add Michal, we get to this. 
Previous:

puiterwijk
Randy (bowlofeggs)
pingou
jcline
Ralph
jflory
abompard
rlerch

Current:

abompard
lrossetti/odra
pingou
scoady
cverna
mkonecny (Zlopez)

If we also count rpmautospec, we add Nils and Adam to the current list:

abompard
lrossetti/odra
pingou
scoady
cverna
mkonecny (Zlopez)
nphilipp
asaleh

and it looks like it's about even. But that's counting rpmautospec, 
which seems to be an odd counterpoint to the overall CPE narrative that 
"we have too many projects and we're trying to get rid of the 
maintenance burden" - you already don't have resources to maintain the 
things that Fedora very definitely needs and is using right now, but you 
*do* have resources to dedicate some or all of the time of three 
engineers to a brand new project which certainly looks cool but is 
definitely a new invented-here thing that isn't absolutely essential to 
Fedora's needs and isn't replacing an existing project?

To be really clear: I don't want the takeaway from this to be "Adam is 
very mad and doesn't want CPE to be allowed to work on cool new projects 
any more". I like cool new projects! Cool new projects are great! I 
write them myself sometimes! I'm just having trouble joining up the dots 
here in terms of high-level strategy.

>  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. 
What I'm looking at is the commit logs. That's all that ultimately 
matters. But see above revisions, of course.

[snip the stuff about whether we need elections apps and blahblah 
because I don't have anything to add there]

>  > > Now when the CPE team goes and ask for more people because
> we struggle
>  > with
>  > > current situation, I can only guess that these non critical applications
>  > > are mentioned. If I was putting my own money to sponsor a team to help
>  > > building a Linux distribution I would be asking why do we have to
>  > develop a
>  > > calendar application or why do we need a custom git forge. I personally
>  > > find really great that the different use cases and requirements for the
>  > use
>  > > of Pagure were gathered and I am convinced that people working on this
>  > did
>  > > their very best to find a use case to justify the investment needed in
>  > > Pagure but it seems that we don't have such a thing.
>  >
>  > I think other people are following up on this, but from following the
>  > discussion, it appears to me that there seems to have been a large slip
>  > somewhere along the line from Ben submitting a list of ~50 Fedora
>  > submissions, to Leigh suggesting that (after those were, mysteriously,
>  > "summarized" somehow)
>  
>  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/[e-mail]...

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 have not been "merged" with
"duplications" or 
"similar in theme requirements". The "spirit" of them has not been 
"captured" in a "User Story". They are just *not there*. They have not

been summarized. They were dropped. So the claim is false, and there was 
not just a summarization process here, there was some sort of filtering 
process. Things from the stakeholder lists were outright left out of the 
"summarization". I'll pick this up again later.

Of the other 44 points on the Fedora list, 23 mention dist-git 
specifically. The term "dist-git" is mentioned 40 times. Some of these 
aren't truly "dist-git" specific, and are really just generic git or 
forge requirements, but many of them *are* specific to dist-git and the 
packager workflow integration; I'd count at least points 9, 17, 18, 19, 
20, 22, 23, 24, 25, 26, 28, 29, and maybe 37 in this bucket. In the 
"summarized" list, the string "dist-git" does not appear once. I can
buy 
that a few of the requirements are *possibly* "summarized" into the 
points about access control, but generic access control requirements do 
not at all cover all the details of dist-git integration. Effectively, 
all the details relating to dist-git and packager workflow interaction - 
which constitute the large majority of significant requirements on the 
Fedora list that wouldn't be satisfied by all of the candidates - are 
lost in the summarized list.

You say that all the (original 300+) requirements were analyzed, but 
when you have been asked for specific details on any of the issues 
relating to dist-git / packager workflow integration, these are the 
kinds of answers you have given:

"The Fedora specific requirements (as I am on the Fedora lists here) had 
very few unique needs such that both Gitlab and Pagure would have 
satisfied their desire."

If you read the two lists above and my notes, I do not see how you can 
possibly claim that Fedora "had very few unique needs". This was the 
quote that first got me really worried that Fedora's needs had not been 
properly considered and understood. (We can also note, of course, that 
while both Gitlab CE and Pagure can potentially satisfy the "open 
source" and "self-hosted" requirements, Gitlab Ultimate - to which the 
decision appears to be weighted, a suggestion no-one has yet denied, 
beyond a very mealy-mouth and deniable "no option is off the table yet" 
- does not satisfy either). You later made more or less the same claim 
again:

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

which only makes me worry more.

[to a question about Bugzilla package workflow integration] "I don't 
have an answer to this as we haven't done that deep level of tooling 
analysis and integration analysis yet."

How can you have considered Fedora's requirements with regard to tooling 
and integration if you haven't "done a deep level of tooling analysis 
and integration analysis yet"?

[when Till attempted to make similar points about the dist-git 
requirements] "The User Stories are deliberately vague and that 
represents around 10 unique requirements that boil down to having group 
membership and management capabilities."

"Having group memembership and management capabilities" is nowhere close 
to covering the dist-git integration requirements. Pagure had these more 
or less from day one, but we still had to spend months on engineering 
the dist-git integration. You cannot count generic group membership and 
ACL capabilities as "covering" these requirements, and if you did, that 
was a fundamental misunderstanding of what Fedora was requesting.

[when asked if you know how many existing integrations with Pagure there 
are] "No. Our analysis will tell us that in due course"

Once again - if you don't even know that, how can you possibly have 
fully evaluated Fedora's detailed requirements regarding dist-git / 
packager workflow integration? You defended this by saying "I do know of 
many important integrations that I come into contact with during my day 
to day job in the team, that doesn't mean I know every single one of 
them. We analysed the critical path needs via the requirements and any 
reference to tooling integrations (e.g. fedora messaging was reference 
in multiple conversations) will be brought forward with us for deeper 
technical conversations", but the extent to which the detail in Fedora's 
list is lost in the "summarized" list gives me (and I suspect others) no 
confidence at all that this analysis was done correctly.

To put it slightly more generally: I think Fedora as a whole would have 
expected that CPE was *already* deeply familiar with the importance of 
dist-git / packager workflow integration. That CPE would *already* 
understand that this - along with F/OSS principles - would be the meat 
of Fedora's "unique" requirements in this process. And that the rolling 
of these into "user stories" would be a useful technique for 
facilitating the process, but not the Holy Grail of the process outside 
of which nothing would matter at all; I would have expected the 
knowledge that (for instance) pingou already has about this stuff to 
have just been included directly in the decision-making process.

However, as you've described it, that doesn't seem to have been what's 
happened. Instead, this deep base of existing knowledge within your team 
seems to have been sidelined in the decision process, and instead the 
decision has been made based mostly or entirely on this apparently 
somewhat wobbly process of bundling up and "summarizing" requirements 
(through three levels of the telephone game, from Fedora lists to the 
Council to this "summarized" list) as "User Stories". Or at least,
that 
is how you are presenting the process as having worked and the decision 
as having been made, and the focus on generic forge-type requirements 
and the repeated contention that Fedora had "very few" "unique" 
requirements reinforces that impression.

On a general note, I'm really having trouble understanding the overall 
logic behind this "requirements" process at all. You've mentioned there 
were over 300 requirements from the stakeholders and you summarized them 
into this list. But when people have pressed you on individual items in 
the summarized list, you've said stuff like this:

[on private PR comments] "It is a valid requirement from a stakeholder 
that we had to take at face value."

OK, but why did *this* requirement make the "summarized" list when 
others - as I've mentioned above - didn't? I am discounting the claim 
that the list somehow summarizes all the given requirements, because it 
very clearly and inarguably does not. You had to "take it at face 
value", but there were 300 other requirements that had to be taken "at 
face value" as well, and not all of them made the list. As that's true, 
you can't duck Neal's question: why did *this specific request*, which 
Neal gives various reasons for not considering a great priority, make 
the summarized list? You can say "we think you're wrong that it's not a 
very important request, we think it is an important request for reason 
X", but you can't just duck the question by saying there was no choice 
made that can be questioned. Clearly there *was*.

[on the mobile app requirement] "It's a requirement that came from the 
Fedora Community and one we could not satisfy as soon as Github was 
ruled out. I do agree the experience is not great on it."

Again, given the context that there clearly was some sort of filtering 
process here, this reads as very bizarre. A bells-and-whistles feature 
requirement that you acknowledge only Github barely fulfils, badly, 
makes the summarized list, but "we want it to be F/OSS" and multiple 
very specific fundamental dist-git integration requirements somehow 
don't make the summarized list or are garbled beyond recognition?

[on gists] "It's not up to me to gauge the merit of that as a use case 
but it's a valid requirement which we considered."

But the question is why *this* item from the list of 300+ made the 
"summarized" list rather than being smooshed into something very vaguely 
related, or dropped entirely. Did someone *else* gauge the merit of that 
as a use case? Or did you make the decision on some other grounds?

You have also implied there was some kind of "weighting" involved, when 
asked if a requirement that "Github" be at the top of the UI would have 
been accepted:

"Would it be weighed equally with a more core functional requirement? 
The answer is of course no but we would
have respected that request."

but you have not provided any further detail on exactly how this 
"weighting" worked and how Fedora's requirements (those which were not, 
apparently, entirely dropped) were "weighted". How was Fedora's "we
want 
it to be open source" "weighed" against requests that cannot currently 
be satisfied by an open source choice, if it was considered at all?

I will also make a side note: it was claimed earlier in this thread that 
the "mobile app" requirement "came from Fedora", but there is a rather

interesting discrepancy there. The Fedora requirement reads:

"As a Fedora contributor, I can perform issue and pull request actions 
on mobile devices via a native mobile app or a mobile-friendly webapp so 
that I can contribute while away from my desk."

The "summarized" version reads:

"As a General User
I want a mobile native app
To allow me contribute while away from my desk"

somehow the "or a mobile-friendly webapp" bit got lost. (And the 
specific actions).
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Adam Williamson]

On Thu, 2020-04-02 at 13:26 -0400, Matthew Miller wrote:
>  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). 
And has that process been synchronized with this "git forge decision"
process?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Adam Williamson]

On Thu, 2020-04-02 at 12:06 -0400, Stephen John Smoogen wrote:
>  On Thu, 2 Apr 2020 at 10:57, Michael Catanzaro
> <mcatanzaro(a)gnome.org&gt; wrote:
>  
>  > On Wed, Apr 1, 2020 at 8:16 pm, Paul Frields <stickster(a)gmail.com&gt;
>  > 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
>  > 
>  
>  I think one of the problems is that every person here says they know what
>  Fedora needs and quite frankly after you add up all the things it comes
>  into the grab bag we got for a Git replacement. You have your opinions, and
>  so do 800 other developers. Right now the people who want a complete FLOSS
>  solution are yelling but for the last 5+ years the people who have been
>  yelling that GitLab/GitHub was a better solution have been yelling. Those
>  complaints have been just as strong and vociferous with lots of
>  insinuations about wasting time, money, and resources when Git* was there. 
Let's not conflate things here. Gitlab CE *is* a complete FLOSS
solution.

>  In the end, we have to realize that the Fedora community is not a
> solid
>  mass and there is rarely a clear majority.  The infrastructure we have is a
>  highly complicated mess of interlocking tools to try and deal with the fact
>  there is no majority of what people want, and that they want new stuff
>  every 3-5 months added. That continually adding complexity has made getting
>  people involved in infrastructure harder and harder because for every group
>  which said 'oh drop this, it isn't needed' there were multiple groups
>  saying 'we use this heavily and would stop existing if you took it away'. 
You seem to have jumped away from "git forge requirements" somewhere in
the middle here and are now talking more generally about stuff we have
talked about lots and lots of times before. We know there is a serious
resource issue underlying all this. No-one is debating that. But that
doesn't actually seem to be a direct answer to Michael's post.

We *did* come up with a clear list of "Fedora" requirements for the git
forge decision. It was sent from the Council to the CPE team. And, as I
tried to detail extensively in the last email I sent, it does not seem
to have been properly included in the decision process. That can't be
blamed on the Fedora community not being a "solid mass" or having a
"clear majority". And I don't see how the stuff about "highly
complicated mess of interlocking tools" is relevant here, because I
don't see how any decision here changes that: whether our forge is
Pagure or Gitlab CE or Gitlab Ultimate or anything else, it is going to
require significant amounts of integration with our packaging workflow.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Adam Williamson]

On Thu, 2020-04-02 at 11:47 -0700, Adam Williamson wrote:
>  
>  So if we include Ryan on both lists and add Michal, we get to this. 
>  Previous:
>  
>  puiterwijk
>  Randy (bowlofeggs)
>  pingou
>  jcline
>  Ralph
>  jflory
>  abompard
>  rlerch
>  
>  Current:
>  
>  abompard
>  lrossetti/odra
>  pingou
>  scoady
>  cverna
>  mkonecny (Zlopez)
>  
>  If we also count rpmautospec, we add Nils and Adam to the current list:
>  
>  abompard
>  lrossetti/odra
>  pingou
>  scoady
>  cverna
>  mkonecny (Zlopez)
>  nphilipp
>  asaleh
>  and it looks like it's about even. 

Gahhh, and then I didn't actually include Ryan in the 'current' lists.
Sorry. Blame the Evo crashes :( For posterity, correct text should be:

Previous:

puiterwijk
Randy (bowlofeggs)
pingou
jcline
Ralph
jflory
abompard
rlerch

Current:

abompard
lrossetti/odra
pingou
scoady
cverna
mkonecny (Zlopez)
rlerch

If we also count rpmautospec, we add Nils and Adam to the current list:

abompard
lrossetti/odra
pingou
scoady
cverna
mkonecny (Zlopez)
rlerch
nphilipp
asaleh
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Stephen John Smoogen]

On Thu, 2 Apr 2020 at 14:57, Adam Williamson <adamwill(a)fedoraproject.org&gt;
wrote:

>  On Thu, 2020-04-02 at 12:06 -0400, Stephen John Smoogen wrote:
>  > On Thu, 2 Apr 2020 at 10:57, Michael Catanzaro <mcatanzaro(a)gnome.org&gt;
>  wrote:
>  >
>  > > On Wed, Apr 1, 2020 at 8:16 pm, Paul Frields <stickster(a)gmail.com&gt;
>  > > 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
>  > >
>  >
>  > I think one of the problems is that every person here says they know what
>  > Fedora needs and quite frankly after you add up all the things it comes
>  > into the grab bag we got for a Git replacement. You have your opinions,
>  and
>  > so do 800 other developers. Right now the people who want a complete
>  FLOSS
>  > solution are yelling but for the last 5+ years the people who have been
>  > yelling that GitLab/GitHub was a better solution have been yelling. Those
>  > complaints have been just as strong and vociferous with lots of
>  > insinuations about wasting time, money, and resources when Git* was
>  there.
>
>  Let's not conflate things here. Gitlab CE *is* a complete FLOSS
>  solution.
>
>  > In the end, we have to realize that the Fedora community is not a solid
>  > mass and there is rarely a clear majority.  The infrastructure we have
>  is a
>  > highly complicated mess of interlocking tools to try and deal with the
>  fact
>  > there is no majority of what people want, and that they want new stuff
>  > every 3-5 months added. That continually adding complexity has made
>  getting
>  > people involved in infrastructure harder and harder because for every
>  group
>  > which said 'oh drop this, it isn't needed' there were multiple groups
>  > saying 'we use this heavily and would stop existing if you took it away'.
>
>  You seem to have jumped away from "git forge requirements" somewhere in
>  the middle here and are now talking more generally about stuff we have
>  talked about lots and lots of times before. We know there is a serious
>  resource issue underlying all this. No-one is debating that. But that
>  doesn't actually seem to be a direct answer to Michael's post.
>
>  
The issue I tried and failed to communicate is that decisions are not made
in a vacuum.  Everything else I added was me going through various levels
of grief and confusing my denial and anger for acceptance.


>  -- 
Stephen J Smoogen.

[Clement Verna]

On Thu, 2 Apr 2020 at 20:49, Adam Williamson <adamwill(a)fedoraproject.org&gt;
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
>
>  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. 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.
>
>  > > 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, 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.


>  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. 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 to maintain all the projects we have already" is the
>  recurring refrain here.
>  
This is an effort to improve the packager workflow in order to automate the
generation of spec file changelogs and release field. Indeed it is a new
project but we considered that improving and automating the packager
workflow is something worth investing time in and creating new projects.


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.


>  James I didn't count as he's listed as an intern. But here's his Github
>  log (I can't find him on Pagure):
>
>  https://github.com/james02135
>
>  so I don't mean this as a knock at all, but he's obviously not
>  equivalent to one regular full-time dev, nor would we (I hope) expect
>  him to be.
>
>  So if we include Ryan on both lists and add Michal, we get to this.
>  Previous:
>
>  puiterwijk
>  Randy (bowlofeggs)
>  pingou
>  jcline
>  Ralph
>  jflory
>  abompard
>  rlerch
>
>  Current:
>
>  abompard
>  lrossetti/odra
>  pingou
>  scoady
>  cverna
>  mkonecny (Zlopez)
>
>  If we also count rpmautospec, we add Nils and Adam to the current list:
>
>  abompard
>  lrossetti/odra
>  pingou
>  scoady
>  cverna
>  mkonecny (Zlopez)
>  nphilipp
>  asaleh
>
>  and it looks like it's about even. But that's counting rpmautospec,
>  which seems to be an odd counterpoint to the overall CPE narrative that
>  "we have too many projects and we're trying to get rid of the
>  maintenance burden" - you already don't have resources to maintain the
>  things that Fedora very definitely needs and is using right now, but you
>  *do* have resources to dedicate some or all of the time of three
>  engineers to a brand new project which certainly looks cool but is
>  definitely a new invented-here thing that isn't absolutely essential to
>  Fedora's needs and isn't replacing an existing project?
>
>  
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. Also
application development requires more effort as the time passes, working on
legacy code base is really time consuming, for example after completing the
work on Bodhi for rawhide gating not much time went into Bodhi's
development for a few months, when I started to look back at the project to
prepare a new release I easily spent a week just fixing the integration
tests,.



>  To be really clear: I don't want the takeaway from this to be
> "Adam is
>  very mad and doesn't want CPE to be allowed to work on cool new projects
>  any more". I like cool new projects! Cool new projects are great! I
>  write them myself sometimes! I'm just having trouble joining up the dots
>  here in terms of high-level strategy.
>  
We are really starting with prioritization and trying to be better at how
we organize our work, so yeah maybe not every is great, but I did not know
that perfection was the minimum required. We also share a weekly status
update of every that is going on and welcome feedback and comments. Also if
you think that we are really on the wrong tracks please feel free to reach
out to the council or directly to Aoife which is working really hard to try
to make sense of all the requests and needs that arrives at our door.

I think it is important to note that a lot of people in the team are quite
new to being part of a community. Honestly I don't think we are giving them
a really good experience. But what strike me the most is the little trust
there is in our team. When a group of people is working as hard as the
folks in the CPE team, (some being around during the weekends or waking up
in the middle of the night to restart a service) is telling that they
cannot sustain the amount of work they have, there is so little trust in
that team that we have to go and check the commit logs of these people to
see on what they are working and if this time is well invested.

Honestly I have no words, and no motivation to go and fix any of the
tickets that are waiting to be fixed.


>  > 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.
>
>  What I'm looking at is the commit logs. That's all that ultimately
>  matters. But see above revisions, of course
>  
.
>  [snip the stuff about whether we need elections apps and blahblah
>  because I don't have anything to add there]
>
>  > > > Now when the CPE team goes and ask for more people because we
>  struggle
>  > > with
>  > > > current situation, I can only guess that these non critical
>  applications
>  > > > are mentioned. If I was putting my own money to sponsor a team to
>  help
>  > > > building a Linux distribution I would be asking why do we have to
>  > > develop a
>  > > > calendar application or why do we need a custom git forge. I
>  personally
>  > > > find really great that the different use cases and requirements for
>  the
>  > > use
>  > > > of Pagure were gathered and I am convinced that people working on
>  this
>  > > did
>  > > > their very best to find a use case to justify the investment needed
>  in
>  > > > Pagure but it seems that we don't have such a thing.
>  > >
>  > > I think other people are following up on this, but from following the
>  > > discussion, it appears to me that there seems to have been a large slip
>  > > somewhere along the line from Ben submitting a list of ~50 Fedora
>  > > submissions, to Leigh suggesting that (after those were, mysteriously,
>  > > "summarized" somehow)
>  >
>  > 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/[e-mail]...
>
>  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 have not been "merged" with
> "duplications" or
>  "similar in theme requirements". The "spirit" of them has not been
>  "captured" in a "User Story". They are just *not there*. They have
> not
>  been summarized. They were dropped. So the claim is false, and there was
>  not just a summarization process here, there was some sort of filtering
>  process. Things from the stakeholder lists were outright left out of the
>  "summarization". I'll pick this up again later.
>
>  Of the other 44 points on the Fedora list, 23 mention dist-git
>  specifically. The term "dist-git" is mentioned 40 times. Some of these
>  aren't truly "dist-git" specific, and are really just generic git or
>  forge requirements, but many of them *are* specific to dist-git and the
>  packager workflow integration; I'd count at least points 9, 17, 18, 19,
>  20, 22, 23, 24, 25, 26, 28, 29, and maybe 37 in this bucket. In the
>  "summarized" list, the string "dist-git" does not appear once. I can
> buy
>  that a few of the requirements are *possibly* "summarized" into the
>  points about access control, but generic access control requirements do
>  not at all cover all the details of dist-git integration. Effectively,
>  all the details relating to dist-git and packager workflow interaction -
>  which constitute the large majority of significant requirements on the
>  Fedora list that wouldn't be satisfied by all of the candidates - are
>  lost in the summarized list.
>
>  You say that all the (original 300+) requirements were analyzed, but
>  when you have been asked for specific details on any of the issues
>  relating to dist-git / packager workflow integration, these are the
>  kinds of answers you have given:
>
>  "The Fedora specific requirements (as I am on the Fedora lists here) had
>  very few unique needs such that both Gitlab and Pagure would have
>  satisfied their desire."
>
>  If you read the two lists above and my notes, I do not see how you can
>  possibly claim that Fedora "had very few unique needs". This was the
>  quote that first got me really worried that Fedora's needs had not been
>  properly considered and understood. (We can also note, of course, that
>  while both Gitlab CE and Pagure can potentially satisfy the "open
>  source" and "self-hosted" requirements, Gitlab Ultimate - to which the
>  decision appears to be weighted, a suggestion no-one has yet denied,
>  beyond a very mealy-mouth and deniable "no option is off the table yet"
>  - does not satisfy either). You later made more or less the same claim
>  again:
>
>  "The needs of Fedora, CentOS, RHEL and the CPE team were weighed equally
>  in our decision. Fedora had very few specific needs in their
>  requirements where as some stakeholder groups had."
>
>  which only makes me worry more.
>
>  [to a question about Bugzilla package workflow integration] "I don't
>  have an answer to this as we haven't done that deep level of tooling
>  analysis and integration analysis yet."
>
>  How can you have considered Fedora's requirements with regard to tooling
>  and integration if you haven't "done a deep level of tooling analysis
>  and integration analysis yet"?
>
>  [when Till attempted to make similar points about the dist-git
>  requirements] "The User Stories are deliberately vague and that
>  represents around 10 unique requirements that boil down to having group
>  membership and management capabilities."
>
>  "Having group memembership and management capabilities" is nowhere close
>  to covering the dist-git integration requirements. Pagure had these more
>  or less from day one, but we still had to spend months on engineering
>  the dist-git integration. You cannot count generic group membership and
>  ACL capabilities as "covering" these requirements, and if you did, that
>  was a fundamental misunderstanding of what Fedora was requesting.
>
>  [when asked if you know how many existing integrations with Pagure there
>  are] "No. Our analysis will tell us that in due course"
>
>  Once again - if you don't even know that, how can you possibly have
>  fully evaluated Fedora's detailed requirements regarding dist-git /
>  packager workflow integration? You defended this by saying "I do know of
>  many important integrations that I come into contact with during my day
>  to day job in the team, that doesn't mean I know every single one of
>  them. We analysed the critical path needs via the requirements and any
>  reference to tooling integrations (e.g. fedora messaging was reference
>  in multiple conversations) will be brought forward with us for deeper
>  technical conversations", but the extent to which the detail in Fedora's
>  list is lost in the "summarized" list gives me (and I suspect others) no
>  confidence at all that this analysis was done correctly.
>
>  To put it slightly more generally: I think Fedora as a whole would have
>  expected that CPE was *already* deeply familiar with the importance of
>  dist-git / packager workflow integration. That CPE would *already*
>  understand that this - along with F/OSS principles - would be the meat
>  of Fedora's "unique" requirements in this process. And that the rolling
>  of these into "user stories" would be a useful technique for
>  facilitating the process, but not the Holy Grail of the process outside
>  of which nothing would matter at all; I would have expected the
>  knowledge that (for instance) pingou already has about this stuff to
>  have just been included directly in the decision-making process.
>
>  However, as you've described it, that doesn't seem to have been what's
>  happened. Instead, this deep base of existing knowledge within your team
>  seems to have been sidelined in the decision process, and instead the
>  decision has been made based mostly or entirely on this apparently
>  somewhat wobbly process of bundling up and "summarizing" requirements
>  (through three levels of the telephone game, from Fedora lists to the
>  Council to this "summarized" list) as "User Stories". Or at least,
> that
>  is how you are presenting the process as having worked and the decision
>  as having been made, and the focus on generic forge-type requirements
>  and the repeated contention that Fedora had "very few" "unique"
>  requirements reinforces that impression.
>
>  On a general note, I'm really having trouble understanding the overall
>  logic behind this "requirements" process at all. You've mentioned there
>  were over 300 requirements from the stakeholders and you summarized them
>  into this list. But when people have pressed you on individual items in
>  the summarized list, you've said stuff like this:
>
>  [on private PR comments] "It is a valid requirement from a stakeholder
>  that we had to take at face value."
>
>  OK, but why did *this* requirement make the "summarized" list when
>  others - as I've mentioned above - didn't? I am discounting the claim
>  that the list somehow summarizes all the given requirements, because it
>  very clearly and inarguably does not. You had to "take it at face
>  value", but there were 300 other requirements that had to be taken "at
>  face value" as well, and not all of them made the list. As that's true,
>  you can't duck Neal's question: why did *this specific request*, which
>  Neal gives various reasons for not considering a great priority, make
>  the summarized list? You can say "we think you're wrong that it's not a
>  very important request, we think it is an important request for reason
>  X", but you can't just duck the question by saying there was no choice
>  made that can be questioned. Clearly there *was*.
>
>  [on the mobile app requirement] "It's a requirement that came from the
>  Fedora Community and one we could not satisfy as soon as Github was
>  ruled out. I do agree the experience is not great on it."
>
>  Again, given the context that there clearly was some sort of filtering
>  process here, this reads as very bizarre. A bells-and-whistles feature
>  requirement that you acknowledge only Github barely fulfils, badly,
>  makes the summarized list, but "we want it to be F/OSS" and multiple
>  very specific fundamental dist-git integration requirements somehow
>  don't make the summarized list or are garbled beyond recognition?
>
>  [on gists] "It's not up to me to gauge the merit of that as a use case
>  but it's a valid requirement which we considered."
>
>  But the question is why *this* item from the list of 300+ made the
>  "summarized" list rather than being smooshed into something very vaguely
>  related, or dropped entirely. Did someone *else* gauge the merit of that
>  as a use case? Or did you make the decision on some other grounds?
>
>  You have also implied there was some kind of "weighting" involved, when
>  asked if a requirement that "Github" be at the top of the UI would have
>  been accepted:
>
>  "Would it be weighed equally with a more core functional requirement?
>  The answer is of course no but we would
>  have respected that request."
>
>  but you have not provided any further detail on exactly how this
>  "weighting" worked and how Fedora's requirements (those which were not,
>  apparently, entirely dropped) were "weighted". How was Fedora's "we
> want
>  it to be open source" "weighed" against requests that cannot currently
>  be satisfied by an open source choice, if it was considered at all?
>
>  I will also make a side note: it was claimed earlier in this thread that
>  the "mobile app" requirement "came from Fedora", but there is a
> rather
>  interesting discrepancy there. The Fedora requirement reads:
>
>  "As a Fedora contributor, I can perform issue and pull request actions
>  on mobile devices via a native mobile app or a mobile-friendly webapp so
>  that I can contribute while away from my desk."
>
>  The "summarized" version reads:
>
>  "As a General User
>  I want a mobile native app
>  To allow me contribute while away from my desk"
>
>  somehow the "or a mobile-friendly webapp" bit got lost. (And the
>  specific actions).
>  --
>  Adam Williamson
>  Fedora QA Community Monkey
>  IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
>  http://www.happyassassin.net
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>

[Adam Williamson]

On Thu, 2020-04-02 at 11:47 -0700, Adam Williamson wrote:
>  
>  > 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/[e-mail]...
>  
>  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 have not been "merged" with
> "duplications" or 
>  "similar in theme requirements". The "spirit" of them has not been 
>  "captured" in a "User Story". They are just *not there*. They have
> not 
>  been summarized. They were dropped. So the claim is false, and there was 
>  not just a summarization process here, there was some sort of filtering 
>  process. Things from the stakeholder lists were outright left out of the 
>  "summarization". I'll pick this up again later.
>  
>  Of the other 44 points on the Fedora list, 23 mention dist-git 
>  specifically. The term "dist-git" is mentioned 40 times. Some of these 
>  aren't truly "dist-git" specific, and are really just generic git or 
>  forge requirements, but many of them *are* specific to dist-git and the 
>  packager workflow integration; I'd count at least points 9, 17, 18, 19, 
>  20, 22, 23, 24, 25, 26, 28, 29, and maybe 37 in this bucket. In the 
>  "summarized" list, the string "dist-git" does not appear once. I can
> buy 
>  that a few of the requirements are *possibly* "summarized" into the 
>  points about access control, but generic access control requirements do 
>  not at all cover all the details of dist-git integration. Effectively, 
>  all the details relating to dist-git and packager workflow interaction - 
>  which constitute the large majority of significant requirements on the 
>  Fedora list that wouldn't be satisfied by all of the candidates - are 
>  lost in the summarized list. 
Sorry, just to join up the thinking here a little more: this isn't just
theoretical after-the-fact point-scoring and Monday morning
quarterbacking, either. It's still very important as this decision
making process goes forward.

As we've been sort of dancing around, if we accept that the "Pagure vs.
Gitlab" decision has been made in favour of Gitlab, we still ostensibly
have two very important and interrelated choices to make:

1. Which Gitlab product?
2. Self-hosted or SaaS?

(it actually doesn't seem at all clear whether 2) is really outstanding
or not, but for the purpose of this email I'm going to assume it is).
If those decisions get made based on this summarized list of User
Stories, then all of the Fedora requirements which have been lost or
transmogrified beyond recognition (as detailed in the other post) will
not be taken into account in making that decision. As Neal has pointed
out, if the summarized list is taken at face value, it's very difficult
to imagine the decision coming out as anything other than 'Gitlab
Ultimate Saas'.

But those Fedora requirements that are not properly captured are *very*
germane to this decision. Most obviously, the strong Fedora preference
for F/OSS software - which I think should be obvious from the fact that
this is item #2 in Fedora's list! - will not be considered at all.
Neither will Fedora's desire for self-hosting, which is item #1 in
Fedora's list. Both of those requirements bear *directly* on these
decisions, yet are not captured in the summarized list *at all*.

Beyond that, the dist-git integration issues are *also* very germane to
these decisions. I would suggest that it is likely that this
integration work would go easier and faster on a self-hosted forge as
compared to an SaaS forge, for two main reasons:

1) We can patch a self-hosted forge at will
2) We control the deployment choices for a self-hosted forge

These are both things that make deploying deep and complex integrations
much easier. If the integration requires a change to be made in the
forge, and we're using a hosted solution, we are at the mercy of the
provider to merge and deploy it. I suppose it's *possible* that you
could negotiate a hosting contract which gives us the ability to demand
that our deployments be patched with certain changes, or to dictate
when a new version be deployed, but it doesn't seem *likely*. That
doesn't seem to be how hosting generally works. At best I can imagine
we could get the ability to *ask* for these things, but I doubt very
much the responsiveness would be anywhere near the control you have
over a self-hosted deployment.

I would like to have much more confidence than I currently do that
these issues are going to be considered in deciding these two
questions.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Adam Williamson]

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 there
was an "apparent significant headcount reduction" was off the mark, but
to me it seems that in saying "for roughly the same team, there is much
more thing to do", you're *supporting* my initial point here, if
anything, right?

>  > To be really clear: I don't want the takeaway from this to
> be "Adam 
is
>  > very mad and doesn't want CPE to be allowed to work on cool
> new 
projects
>  > any more". I like cool new projects! Cool new projects are
> great! I
>  > write them myself sometimes! I'm just having trouble joining up the 
dots
>  > here in terms of high-level strategy.
>  > 
>  
>  We are really starting with prioritization and trying to be better at 
how
>  we organize our work, so yeah maybe not every is great, but I did not
know
>  that perfection was the minimum required. 
Sheesh, I thought everyone knew that perfection is the baseline for
anything where LWN and Phoronix might be reading ;)

>   We also share a weekly status
>  update of every that is going on and welcome feedback and comments. 
Also if
>  you think that we are really on the wrong tracks please feel free to
reach
>  out to the council or directly to Aoife which is working really hard
to try
>  to make sense of all the requests and needs that arrives at our door.
I certainly don't mean to give that impression. I meant what I said:
I'm having trouble trying to reconcile the various different statements
about resource prioritization from Smooge and Randy and yourself and
Leigh with the whole forge decision process, and I'm struggling to make
sense of it. In my head it is adding up to something like "we
absolutely don't have anything like the resources to maintain all the
legacy stuff (including Pagure) let alone take on new stuff BUT
continuing to maintain and host Pagure was absolutely a valid option
and one we needed to go through a lengthy decision process to discount
BUT "24/7 availability in an SLA model and not hosted by the CPE team"
was a top level requirement BUT we do have the resources to work on
*this* new thing..."

I'm not saying it *definitely doesn't* add up. I'm not in a position to
make that assertion and I wouldn't presume to. I'm just saying I
haven't yet found it all laid out somewhere where I can see how it adds
up. That's why I phrased it as "I'm having trouble joining up the
dots".

>  I think it is important to note that a lot of people in the team are
quite
>  new to being part of a community. Honestly I don't think we are
giving them
>  a really good experience. But what strike me the most is the little
trust
>  there is in our team. When a group of people is working as hard as
the
>  folks in the CPE team, (some being around during the weekends or
waking up
>  in the middle of the night to restart a service) is telling that
> they
>  cannot sustain the amount of work they have, there is so little trust 
in
>  that team that we have to go and check the commit logs of these
people to
>  see on what they are working and if this time is well invested.
>  
>  Honestly I have no words, and no motivation to go and fix any of the
>  tickets that are waiting to be fixed. 
To be absolutely 100% clear on this: I am absolutely not trying to dunk
on the CPE team here. I deeply appreciate all the work you folks in the
trenches do. I am trying very hard not to denigrate any specific
*people* here, because it's against the CoC and I don't like doing it
anyway: as I've always tried to say in discussions like this, I
absolutely believe good people with good intentions sometimes don't do
things as well as they could have been done, and I absolutely include
myself in that group, and I hope I'm always open to the same kind of
feedback on my decisions (as opposed to me personally) from others. But
the thing I am asking questions about here is the *decision making
process* and the *strategic vision*, which if I have to pin it down is
clearly a responsibility of management.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Ankur Sinha]

On Thu, Apr 02, 2020 21:58:36 +0200, Clement Verna wrote:
>  Honestly I have no words, and no motivation to go and fix any of the
> tickets
>  that are waiting to be fixed. 
I think a lot of the community will empathise with you here. You are
certainly not alone. That is part of the reason why this thread is in
its current state. People care---let's take that away from here :)

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) |
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London

[Björn Persson]

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.

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

[Paul Frields]

On Thu, Apr 2, 2020 at 1:12 PM Robbie Harwood <rharwood(a)redhat.com&gt; wrote:
>  Paul Frields <stickster(a)gmail.com&gt; writes:
>  > Neal Gompa <ngompa13(a)gmail.com&gt; wrote: 
[...snip...]
>  >> It's also important to note that at the core of
> GitLab's incentive
>  >> model is that they want to remove incentives to use FOSS solutions in
>  >> favor of their unified proprietary solution. They are constantly
>  >> integrating features and capabilities into the proprietary parts to
>  >> make it "juicier" for enterprises who don't really have a
> compunction
>  >> about whether they are using Free Software solutions or not, or even
>  >> may not be willing to support them if it was Free Software because of
>  >> outmoded thinking.
>  >>
>  >> The consequence of this is that it starves interest and development in
>  >> FOSS solutions, and contributes to making the FOSS ecosystem weaker
>  >> over time.
>  >
>  > 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,
>
>  I assume you didn't mean quite that.  Sure, it's not totally open
>  source, but it's built on and uses open source tools, just like many
>  other applications.  In a personal example, I've fixed something on
>  github by patching https://github.com/jch/html-pipeline/ .  Or more
>  bulk, there are 340 repos at https://github.com/github . 
You're absolutely right, my apologies. I should have said it doesn't
have a FOSS offering or the like. However, thank you for helping make
my point, which is that there are many shades in which open source
contribution comes.

-- 
Paul

[Jeremy Cline]

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

[Erich Eickmeyer]

Hi all. I'm a relative newcomer here and came to take-up the Fedora Jam 
project. I've been following this discussion very closely, and I've got to 
say, that I'm quite disappointed at the way this has been handled.

I'm not a software engineer by trade. I'm an audio engineer with 26 years of 
experience and a degree in leadership. That leadership degree is the hat that 
I want to chime-in with here, and the lens through which I'm viewing this.

On Thursday, April 2, 2020 4:25:53 PM PDT 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's comment here struck me to the core. If anybody on any team that I had 
led had mentioned this, I'd be broken-hearted. This is the sign of a complete 
failure at the leadership level. No volunteer or employee should *ever* be 
made to feel this way. Full stop. I have the feeling that Neal is feeling the 
same way. All of that hard work these people have done is being thrown away in 
their faces, and they have nothing to say about it. That is a complete 
leadership failure.

It is apparent in this discussion that the CPE (and especially Leigh) has 
failed in a leadership role. It's very possible that the Fedora Council has 
failed too for allowing this situation to happen. I don't care about the 
technical merits, I simply care about how this is being handled and how people 
are being treated in having their voices taken away from them. I think this 
goes against the whole "Friends" foundation.

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.

Honestly, this is making me, someone who came to this project only two months 
ago, wonder if it was, indeed, the right choice. I hope I'm not made to feel 
the same way as Jeremy, and I certainly hope I never make anyone I lead feel 
that way.

----
Erich Eickmeyer
Fedora Jam

[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

[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

[Charalampos Stratakis]

----- Original Message -----
>  From: "Erich Eickmeyer" <erich(a)ericheickmeyer.com&gt;
>  To: devel(a)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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>   
-- 
Regards,

Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat

[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: [phone]
IRC: mhroncok

[Clement Verna]

On Thu, 2 Apr 2020 at 22:33, Adam Williamson <adamwill(a)fedoraproject.org&gt;
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 there
>  was an "apparent significant headcount reduction" was off the mark, but
>  to me it seems that in saying "for roughly the same team, there is much
>  more thing to do", you're *supporting* my initial point here, if
>  anything, right?
>  
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.
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.


>  > > To be really clear: I don't want the takeaway from this to be "Adam
>  is
>  > > very mad and doesn't want CPE to be allowed to work on cool new
>  projects
>  > > any more". I like cool new projects! Cool new projects are great! I
>  > > write them myself sometimes! I'm just having trouble joining up the
>  dots
>  > > here in terms of high-level strategy.
>  > >
>  >
>  > We are really starting with prioritization and trying to be better at
>  how
>  > we organize our work, so yeah maybe not every is great, but I did not
>  know
>  > that perfection was the minimum required.
>
>  Sheesh, I thought everyone knew that perfection is the baseline for
>  anything where LWN and Phoronix might be reading ;)
>
>  >  We also share a weekly status
>  > update of every that is going on and welcome feedback and comments.
>  Also if
>  > you think that we are really on the wrong tracks please feel free to
>  reach
>  > out to the council or directly to Aoife which is working really hard
>  to try
>  > to make sense of all the requests and needs that arrives at our door.
>
>  I certainly don't mean to give that impression. I meant what I said:
>  I'm having trouble trying to reconcile the various different statements
>  about resource prioritization from Smooge and Randy and yourself and
>  Leigh with the whole forge decision process, and I'm struggling to make
>  sense of it. In my head it is adding up to something like "we
>  absolutely don't have anything like the resources to maintain all the
>  legacy stuff (including Pagure) let alone take on new stuff BUT
>  continuing to maintain and host Pagure was absolutely a valid option
>  and one we needed to go through a lengthy decision process to discount
>  BUT "24/7 availability in an SLA model and not hosted by the CPE team"
>  was a top level requirement BUT we do have the resources to work on
>  *this* new thing..."
>
>  I'm not saying it *definitely doesn't* add up. I'm not in a position to
>  make that assertion and I wouldn't presume to. I'm just saying I
>  haven't yet found it all laid out somewhere where I can see how it adds
>  up. That's why I phrased it as "I'm having trouble joining up the
>  dots".
>
>  > I think it is important to note that a lot of people in the team are
>  quite
>  > new to being part of a community. Honestly I don't think we are
>  giving them
>  > a really good experience. But what strike me the most is the little
>  trust
>  > there is in our team. When a group of people is working as hard as
>  the
>  > folks in the CPE team, (some being around during the weekends or
>  waking up
>  > in the middle of the night to restart a service) is telling that they
>  > cannot sustain the amount of work they have, there is so little trust
>  in
>  > that team that we have to go and check the commit logs of these
>  people to
>  > see on what they are working and if this time is well invested.
>  >
>  > Honestly I have no words, and no motivation to go and fix any of the
>  > tickets that are waiting to be fixed.
>
>  To be absolutely 100% clear on this: I am absolutely not trying to dunk
>  on the CPE team here. I deeply appreciate all the work you folks in the
>  trenches do. I am trying very hard not to denigrate any specific
>  *people* here, because it's against the CoC and I don't like doing it
>  anyway: as I've always tried to say in discussions like this, I
>  absolutely believe good people with good intentions sometimes don't do
>  things as well as they could have been done, and I absolutely include
>  myself in that group, and I hope I'm always open to the same kind of
>  feedback on my decisions (as opposed to me personally) from others. But
>  the thing I am asking questions about here is the *decision making
>  process* and the *strategic vision*, which if I have to pin it down is
>  clearly a responsibility of management.
>  
Yeah I know you meant well and were trying to prove your point. I just felt
it was important to remind that these are great people, dedicated and doing
a lot of work for the good of Fedora and CentOS.


>  --
>  Adam Williamson
>  Fedora QA Community Monkey
>  IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
>  http://www.happyassassin.net
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>

[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

[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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail] 
-- 
Role: Fedora CPE Team - Software Engineer
IRC: mkonecny
FAS: zlopez

[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(a)lists.fedoraproject.org
> > To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  
>  -- 
>  Role: Fedora CPE Team - Software Engineer
>  IRC: mkonecny
>  FAS: zlopez
>  
>  
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>   
-- 
Julen Landa Alustiza <jlanda(a)fedoraproject.org&gt;

[Markus Larsson]

On 3 April 2020 10:23:58 CEST, Julen Landa Alustiza <jlanda(a)fedoraproject.org&gt;
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

[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

[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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail] 
-- 
Role: Fedora CPE Team - Software Engineer
IRC: mkonecny
FAS: zlopez

[Neal Gompa]

On Fri, Apr 3, 2020 at 5:29 AM Michal Konecny <mkonecny(a)redhat.com&gt; 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!

[Leigh Griffin]

On Thu, Apr 2, 2020 at 3:58 PM Michael Catanzaro <mcatanzaro(a)gnome.org&gt;
wrote:

>  On Wed, Apr 1, 2020 at 8:16 pm, Paul Frields
> <stickster(a)gmail.com&gt;
>  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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  

-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford <https://www.redhat.com/>

Communications House

Cork Road, Waterford City

lgriffin(a)redhat.com
M: [phone]     IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>

[Martin Kolman]

----- Original Message -----
>  From: "Michal Konecny" <mkonecny(a)redhat.com&gt;
>  To: devel(a)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(a)lists.fedoraproject.org To unsubscribe send an
>  email to devel-leave(a)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/[e-mail]
>  
>  --
>  Role: Fedora CPE Team - Software Engineer
>  IRC: mkonecny
>  FAS: zlopez
>  
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>

[Leigh Griffin]

On Thu, Apr 2, 2020 at 7:48 PM Adam Williamson <adamwill(a)fedoraproject.org&gt;
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 to maintain all the projects we have already" is the
>  recurring refrain here.
>  
It was a request in our priority queue which is driven by the CentOS Board
and the Fedora Council. We deliver value for them and sometimes it involves
creating new services, sometimes it involves modifying an existing service.
We need to weigh up that value proposition for what it will deliver Vs what
it will cost us longer term. The difference now is we have a minimum team
of 3 people per initiative to ensure quality, resiliency in the solution
and longer term maintenance that removes a single point of failure

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

>  James I didn't count as he's listed as an intern. But
> here's his Github
>  log (I can't find him on Pagure):
>
>  https://github.com/james02135
>
>  so I don't mean this as a knock at all, but he's obviously not
>  equivalent to one regular full-time dev, nor would we (I hope) expect
>  him to be.
>
>  So if we include Ryan on both lists and add Michal, we get to this.
>  Previous:
>
>  puiterwijk
>  Randy (bowlofeggs)
>  pingou
>  jcline
>  Ralph
>  jflory
>  abompard
>  rlerch
>
>  Current:
>
>  abompard
>  lrossetti/odra
>  pingou
>  scoady
>  cverna
>  mkonecny (Zlopez)
>
>  If we also count rpmautospec, we add Nils and Adam to the current list:
>  
It is part of the Fedora remit, so yes.

>  abompard
>  lrossetti/odra
>  pingou
>  scoady
>  cverna
>  mkonecny (Zlopez)
>  nphilipp
>  asaleh
>
>  and it looks like it's about even. But that's counting rpmautospec,
>  which seems to be an odd counterpoint to the overall CPE narrative that
>  "we have too many projects and we're trying to get rid of the
>  maintenance burden" - you already don't have resources to maintain the
>  things that Fedora very definitely needs and is using right now, but you
>  *do* have resources to dedicate some or all of the time of three
>  engineers to a brand new project which certainly looks cool but is
>  definitely a new invented-here thing that isn't absolutely essential to
>  Fedora's needs and isn't replacing an existing project?
>  
Like I said, it came as a request for us to solve a problem. We aren't in
the habit of inventing work to do for ourselves anymore, we can propose
changes, we can propose ease of life improvements, they ultimately go to
our stakeholders for consideration and we plan our quarter out.


>  To be really clear: I don't want the takeaway from this to be "Adam is
>  very mad and doesn't want CPE to be allowed to work on cool new projects
>  any more". I like cool new projects! Cool new projects are great! I
>  write them myself sometimes! I'm just having trouble joining up the dots
>  here in terms of high-level strategy.
>
>  > 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.
>
>  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.


>  [snip the stuff about whether we need elections apps and blahblah
>  because I don't have anything to add there]
>
>  > > > Now when the CPE team goes and ask for more people because we
>  struggle
>  > > with
>  > > > current situation, I can only guess that these non critical
>  applications
>  > > > are mentioned. If I was putting my own money to sponsor a team to
>  help
>  > > > building a Linux distribution I would be asking why do we have to
>  > > develop a
>  > > > calendar application or why do we need a custom git forge. I
>  personally
>  > > > find really great that the different use cases and requirements for
>  the
>  > > use
>  > > > of Pagure were gathered and I am convinced that people working on
>  this
>  > > did
>  > > > their very best to find a use case to justify the investment needed
>  in
>  > > > Pagure but it seems that we don't have such a thing.
>  > >
>  > > I think other people are following up on this, but from following the
>  > > discussion, it appears to me that there seems to have been a large slip
>  > > somewhere along the line from Ben submitting a list of ~50 Fedora
>  > > submissions, to Leigh suggesting that (after those were, mysteriously,
>  > > "summarized" somehow)
>  >
>  > 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/[e-mail]...

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.

>  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
<https://lists.fedoraproject.org/archives/list/[e-mail]...
on the thread you linked which descoped om prem and OSS as a standard,
which I am assuming Ben used as his basis to remove them from the formally
submitted list.


>  They have not been "merged" with "duplications"
> or
>  "similar in theme requirements". The "spirit" of them has not been
>  "captured" in a "User Story". They are just *not there*. They have
> not
>  been summarized. They were dropped. So the claim is false, and there was
>  not just a summarization process here, there was some sort of filtering
>  process. Things from the stakeholder lists were outright left out of the
>  "summarization". I'll pick this up again later.
>
>  Of the other 44 points on the Fedora list, 23 mention dist-git
>  specifically. The term "dist-git" is mentioned 40 times. Some of these
>  aren't truly "dist-git" specific, and are really just generic git or
>  forge requirements, but many of them *are* specific to dist-git and the
>  packager workflow integration; I'd count at least points 9, 17, 18, 19,
>  20, 22, 23, 24, 25, 26, 28, 29, and maybe 37 in this bucket. In the
>  "summarized" list, the string "dist-git" does not appear once. I can
> buy
>  that a few of the requirements are *possibly* "summarized" into the
>  points about access control, but generic access control requirements do
>  not at all cover all the details of dist-git integration. Effectively,
>  all the details relating to dist-git and packager workflow interaction -
>  which constitute the large majority of significant requirements on the
>  Fedora list that wouldn't be satisfied by all of the candidates - are
>  lost in the summarized list.
>  
If your entire focal point is on the summarised list that I presented as an
amalgamation of the requirements then your entire argument is off. I
honestly cannot say it in any other way shape or form, we evaluated every
single requirement in making our decision. If it helps, I can update the
original hackmd with the stories and add all the Fedora ones verbatim? It
won't change what the analysis showed but it might help with your analysis
here. Let me know if that works for you.


>  You say that all the (original 300+) requirements were analyzed, but
>  when you have been asked for specific details on any of the issues
>  relating to dist-git / packager workflow integration, these are the
>  kinds of answers you have given:
>
>  "The Fedora specific requirements (as I am on the Fedora lists here) had
>  very few unique needs such that both Gitlab and Pagure would have
>  satisfied their desire."
>
>  If you read the two lists above and my notes, I do not see how you can
>  possibly claim that Fedora "had very few unique needs". 

I stand by that claim.


>  This was the
>  quote that first got me really worried that Fedora's needs had not been
>  properly considered and understood. (We can also note, of course, that
>  while both Gitlab CE and Pagure can potentially satisfy the "open
>  source" and "self-hosted" requirements, Gitlab Ultimate - to which the
>  decision appears to be weighted, a suggestion no-one has yet denied,
>  beyond a very mealy-mouth and deniable "no option is off the table yet"
>  - does not satisfy either). You later made more or less the same claim
>  again:
>
>  "The needs of Fedora, CentOS, RHEL and the CPE team were weighed equally
>  in our decision. Fedora had very few specific needs in their
>  requirements where as some stakeholder groups had."
>
>  which only makes me worry more.
>  
Today, we are meeting Gitlab, first thing we are discussing is license
options. Anything else is speculation on your part.

>  [to a question about Bugzilla package workflow integration] "I don't
>  have an answer to this as we haven't done that deep level of tooling
>  analysis and integration analysis yet."
>
>  How can you have considered Fedora's requirements with regard to tooling
>  and integration if you haven't "done a deep level of tooling analysis
>  and integration analysis yet"?
>  
Key word is deep. If we done the depth of analysis that you are desiring
here, we might have the decision around Christmas time. The level of due
diligence was done.


>  [when Till attempted to make similar points about the dist-git
>  requirements] "The User Stories are deliberately vague and that
>  represents around 10 unique requirements that boil down to having group
>  membership and management capabilities."
>
>  "Having group memembership and management capabilities" is nowhere close
>  to covering the dist-git integration requirements. Pagure had these more
>  or less from day one, but we still had to spend months on engineering
>  the dist-git integration. You cannot count generic group membership and
>  ACL capabilities as "covering" these requirements, and if you did, that
>  was a fundamental misunderstanding of what Fedora was requesting.
>
>  [when asked if you know how many existing integrations with Pagure there
>  are] "No. Our analysis will tell us that in due course"
>
>  Once again - if you don't even know that, how can you possibly have
>  fully evaluated Fedora's detailed requirements regarding dist-git /
>  packager workflow integration? You defended this by saying "I do know of
>  many important integrations that I come into contact with during my day
>  to day job in the team, that doesn't mean I know every single one of
>  them. We analysed the critical path needs via the requirements and any
>  reference to tooling integrations (e.g. fedora messaging was reference
>  in multiple conversations) will be brought forward with us for deeper
>  technical conversations", but the extent to which the detail in Fedora's
>  list is lost in the "summarized" list gives me (and I suspect others) no
>  confidence at all that this analysis was done correctly.
>
>  To put it slightly more generally: I think Fedora as a whole would have
>  expected that CPE was *already* deeply familiar with the importance of
>  dist-git / packager workflow integration. 

We are.


>  That CPE would *already*
>  understand that this - along with F/OSS principles - would be the meat
>  of Fedora's "unique" requirements in this process. 

The latter was not a requirement as per council directives on git hosting
as mentioned in this thread already and the fact it did not end up as a
formal requirement.

>  And that the rolling
>  of these into "user stories" would be a useful technique for
>  facilitating the process, but not the Holy Grail of the process outside
>  of which nothing would matter at all; I would have expected the
>  knowledge that (for instance) pingou already has about this stuff to
>  have just been included directly in the decision-making process.
>  
Pingou was involved in the analysis of the requirements, as were other team
members.


>  However, as you've described it, that doesn't seem to have been what's
>  happened. Instead, this deep base of existing knowledge within your team
>  seems to have been sidelined in the decision process, and instead the
>  decision has been made based mostly or entirely on this apparently
>  somewhat wobbly process of bundling up and "summarizing" requirements
>  (through three levels of the telephone game, from Fedora lists to the
>  Council to this "summarized" list) as "User Stories". Or at least,
> that
>  is how you are presenting the process as having worked and the decision
>  as having been made, and the focus on generic forge-type requirements
>  and the repeated contention that Fedora had "very few" "unique"
>  requirements reinforces that impression.
>
>  On a general note, I'm really having trouble understanding the overall
>  logic behind this "requirements" process at all. You've mentioned there
>  were over 300 requirements from the stakeholders and you summarized them
>  into this list. But when people have pressed you on individual items in
>  the summarized list, you've said stuff like this:
>
>  [on private PR comments] "It is a valid requirement from a stakeholder
>  that we had to take at face value."
>
>  OK, but why did *this* requirement make the "summarized" list when
>  others - as I've mentioned above - didn't? 

Because that is a unique requirement, with a specific need, that came from
2 stakeholder groups and was therefore merged in. I'm unsure what ones did
not meet your summarised list, but like I said already, the entire list
received was parsed and analysed and the ask in the requirement rolled into
generic requirements to capture them at a bucket level. I cannot be any
more clearer on this.


>  I am discounting the claim
>  that the list somehow summarizes all the given requirements, because it
>  very clearly and inarguably does not. You had to "take it at face
>  value", but there were 300 other requirements that had to be taken "at
>  face value" as well, and not all of them made the list. As that's true,
>  you can't duck Neal's question: why did *this specific request*, which
>  Neal gives various reasons for not considering a great priority, make
>  the summarized list? You can say "we think you're wrong that it's not a
>  very important request, we think it is an important request for reason
>  X", but you can't just duck the question by saying there was no choice
>  made that can be questioned. Clearly there *was*.
>
>  [on the mobile app requirement] "It's a requirement that came from the
>  Fedora Community and one we could not satisfy as soon as Github was
>  ruled out. I do agree the experience is not great on it."
>
>  Again, given the context that there clearly was some sort of filtering
>  process here, this reads as very bizarre. A bells-and-whistles feature
>  requirement that you acknowledge only Github barely fulfils, badly,
>  makes the summarized list, but "we want it to be F/OSS" and multiple
>  very specific fundamental dist-git integration requirements somehow
>  don't make the summarized list or are garbled beyond recognition?
>  
The mobile one made it to the list as it was a unique standalone
requirement, as stated previously.

>  [on gists] "It's not up to me to gauge the merit of that as a use case
>  but it's a valid requirement which we considered."
>
>  But the question is why *this* item from the list of 300+ made the
>  "summarized" list rather than being smooshed into something very vaguely
>  related, or dropped entirely. Did someone *else* gauge the merit of that
>  as a use case? Or did you make the decision on some other grounds?
>  
>  You have also implied there was some kind of "weighting"
> involved, when
>  asked if a requirement that "Github" be at the top of the UI would have
>  been accepted:
>  
I asked and suggested that a MoSCoW style weighting be put in place by
stakeholders, this did not happen for Fedora requirements.

>  "Would it be weighed equally with a more core functional requirement?
>  The answer is of course no but we would
>  have respected that request."
>
>  but you have not provided any further detail on exactly how this
>  "weighting" worked and how Fedora's requirements (those which were not,
>  apparently, entirely dropped) were "weighted". How was Fedora's "we
> want
>  it to be open source" "weighed" against requests that cannot currently
>  be satisfied by an open source choice, if it was considered at all?
>  
That was not a requirement but we did not weigh anything that was not a
critical use case of a git forge, so mobile apps is not going to make or
break the usage of a git forge.

>  I will also make a side note: it was claimed earlier in this thread that
>  the "mobile app" requirement "came from Fedora", but there is a
> rather
>  interesting discrepancy there. The Fedora requirement reads:
>
>  "As a Fedora contributor, I can perform issue and pull request actions
>  on mobile devices via a native mobile app or a mobile-friendly webapp so
>  that I can contribute while away from my desk."
>
>  The "summarized" version reads:
>
>  "As a General User
>  I want a mobile native app
>  To allow me contribute while away from my desk"
>  
I don't really find that an interesting discrepancy that we choose the
generic wording for a mobile app requirement. If you like, I can update the
wording to be verbatim, it doesn't change the actual ask of the requirement
which is mobility use cases, which is what we evaluated on.

>  somehow the "or a mobile-friendly webapp" bit got lost. (And the
>  specific actions).
>  --
>  Adam Williamson
>  Fedora QA Community Monkey
>  IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
>  http://www.happyassassin.net
>
>  
-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford <https://www.redhat.com/>

Communications House

Cork Road, Waterford City

lgriffin(a)redhat.com
M: [phone]     IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>

[Michael Catanzaro]

On Thu, Apr 2, 2020 at 4:48 pm, Erich Eickmeyer 
<erich(a)ericheickmeyer.com&gt; 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.

[Neal Gompa]

On Fri, Apr 3, 2020 at 4:24 AM Julen Landa Alustiza
<jlanda(a)fedoraproject.org&gt; 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!

[Michael Catanzaro]

On Fri, Apr 3, 2020 at 11:11 am, Vít Ondruch <vondruch(a)redhat.com&gt; 
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.

[Michael Catanzaro]

On Fri, Apr 3, 2020 at 8:15 am, Michael Catanzaro 
<mcatanzaro(a)gnome.org&gt; 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....

[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
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[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/[e-mail]...
>  
>  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/[e-mail].o...

and you said "yes":

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

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/[e-mail]...

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
>
> <https://lists.fedoraproject.org/archives/list/[e-mail]...
>  on the thread you linked which descoped om prem and OSS as a standard,
>  which I am assuming Ben used as his basis to remove them from the formally
>  submitted list. 
You're right, I didn't, but this was because earlier in the thread you
said that the list mentioned above *was* the Fedora list. I can only go
on what I'm told, after all.

Can we *please* see the final actual definitely official Fedora list,
then? If this is supposed to be an open process?

As I wrote I find Matthew's comment ambiguous, but I would suggest that
reading it as "descoping...OSS" is arguably going too far. It does,
after all, start out by saying "In contrast, I strongly urge the CPE
decision-makers to take this into strong consideration". That seems
kind of the opposite to "descoping" it, to me. As a Fedora contributor
I would be surprised if the original list plus Matthew's comment with
no further discussion led to the utter removal of F/OSS as a
requirement on Fedora's part from the final submitted list. That would
seem like a mistake. Of course, it wouldn't be CPE's mistake.

>  > I will also make a side note: it was claimed earlier in this
> thread that
>  > the "mobile app" requirement "came from Fedora", but there is a
> rather
>  > interesting discrepancy there. The Fedora requirement reads:
>  > 
>  > "As a Fedora contributor, I can perform issue and pull request actions
>  > on mobile devices via a native mobile app or a mobile-friendly webapp so
>  > that I can contribute while away from my desk."
>  > 
>  > The "summarized" version reads:
>  > 
>  > "As a General User
>  > I want a mobile native app
>  > To allow me contribute while away from my desk"
>  > 
>  
>  I don't really find that an interesting discrepancy that we choose the
>  generic wording for a mobile app requirement. If you like, I can update the
>  wording to be verbatim, it doesn't change the actual ask of the requirement
>  which is mobility use cases, which is what we evaluated on. 
It's not very important, I just found it another interesting indication
of the "summarization" process losing some nuance. There is a
difference between saying you want (only) "a mobile native app" and
saying you want "a mobile native app or mobile-friendly webapp". After
all, only Github (kinda) has the first, but all three (arguably) have
the second.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[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
> <mcatanzaro(a)gnome.org&gt;
>  wrote:
>  
>  > On Wed, Apr 1, 2020 at 8:16 pm, Paul Frields <stickster(a)gmail.com&gt;
>  > 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

[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
> <mkonecny(a)redhat.com&gt;
>  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

[Leigh Griffin]

On Fri, Apr 3, 2020 at 4:04 PM Adam Williamson <adamwill(a)fedoraproject.org&gt;
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/[e-mail]...
>  >
>  > 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/[e-mail].o...
>
>  and you said "yes":
>
>
>
> https://lists.fedoraproject.org/archives/list/[e-mail].o...
>
>  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/[e-mail]...
>
>  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
>  > <
>
> https://lists.fedoraproject.org/archives/list/[e-mail]...
>  >
>  > on the thread you linked which descoped om prem and OSS as a standard,
>  > which I am assuming Ben used as his basis to remove them from the
>  formally
>  > submitted list.
>
>  You're right, I didn't, but this was because earlier in the thread you
>  said that the list mentioned above *was* the Fedora list. I can only go
>  on what I'm told, after all.
>  
It's possible I misspoke on it, that list was the wrap up requirements that
Ben took and shared for the 2nd phase of discussion. I'm after replying to
50+ mails on this topic so it's possible I misinterpreted the comment, I
hope my subsequent comments clears it up.


>  Can we *please* see the final actual definitely official Fedora
> list,
>  then? If this is supposed to be an open process?
>  
@Ben Cotton <bcotton(a)redhat.com&gt; can oblige here, it's not my place to
share it without a stakeholder approval.

>  As I wrote I find Matthew's comment ambiguous, but I would suggest that
>  reading it as "descoping...OSS" is arguably going too far. It does,
>  after all, start out by saying "In contrast, I strongly urge the CPE
>  decision-makers to take this into strong consideration". That seems
>  kind of the opposite to "descoping" it, to me. 

Descope in the sense it never made it into the requirement list. We didn't
base our analysis on comments in a mailing thread.


>  As a Fedora contributor
>  I would be surprised if the original list plus Matthew's comment with
>  no further discussion led to the utter removal of F/OSS as a
>  requirement on Fedora's part from the final submitted list. That would
>  seem like a mistake. Of course, it wouldn't be CPE's mistake.
>
>  > > I will also make a side note: it was claimed earlier in this thread
>  that
>  > > the "mobile app" requirement "came from Fedora", but there
> is a rather
>  > > interesting discrepancy there. The Fedora requirement reads:
>  > >
>  > > "As a Fedora contributor, I can perform issue and pull request actions
>  > > on mobile devices via a native mobile app or a mobile-friendly webapp
>  so
>  > > that I can contribute while away from my desk."
>  > >
>  > > The "summarized" version reads:
>  > >
>  > > "As a General User
>  > > I want a mobile native app
>  > > To allow me contribute while away from my desk"
>  > >
>  >
>  > I don't really find that an interesting discrepancy that we choose the
>  > generic wording for a mobile app requirement. If you like, I can update
>  the
>  > wording to be verbatim, it doesn't change the actual ask of the
>  requirement
>  > which is mobility use cases, which is what we evaluated on.
>
>  It's not very important, I just found it another interesting indication
>  of the "summarization" process losing some nuance. There is a
>  difference between saying you want (only) "a mobile native app" and
>  saying you want "a mobile native app or mobile-friendly webapp". After
>  all, only Github (kinda) has the first, but all three (arguably) have
>  the second.
>  --
>  Adam Williamson
>  Fedora QA Community Monkey
>  IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
>  http://www.happyassassin.net
>
>  
-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford <https://www.redhat.com/>

Communications House

Cork Road, Waterford City

lgriffin(a)redhat.com
M: [phone]     IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>

[Leigh Griffin]

On Fri, Apr 3, 2020 at 4:20 PM Jeremy Cline <jeremy(a)jcline.org&gt; wrote:

>  On Fri, 2020-04-03 at 05:38 -0400, Neal Gompa wrote:
>  > On Fri, Apr 3, 2020 at 5:29 AM Michal Konecny <mkonecny(a)redhat.com&gt;
>  > 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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  

-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford <https://www.redhat.com/>

Communications House

Cork Road, Waterford City

lgriffin(a)redhat.com
M: [phone]     IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>

[Ben Cotton]

On Fri, Apr 3, 2020 at 11:59 AM Leigh Griffin <lgriffin(a)redhat.com&gt; 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.

As anybody, I can easily get a list of all dist-git repos that a
specific Fedora account has admin/commit access to so that I can see
what packages the account is associated with.

As anybody, when looking at the dist-git repo it is clearly visible
which branches are still maintained so that I know what release
versions are supported.

As anybody, when I look for a specific branch, EOL branches do not
clutter my view so that I can more easily see the active branches.

As a package maintainer, I can easily request commit/admin access for
a specific branch or dist-git repo so that I can help contribute in a
low-friction manner.

As Fedora infra, I can easily audit that no git repo was accessed
without authorization so that I can maintain the security of the
Fedora infrastructure.

As Fedora infra/security response team, I have access to secure logs
to analyse the impact of unauthorized access to all dist-git repos so
that I can maintain the security of the Fedora infrastructure.

As anybody, the dist-git web page of a repo points me to Bugzilla to
report issues for a repository so that I can file bugs for released
packages.

As an independent software or distro developer, I can fork a dist-git
repo via mirroring, make changes, and submit them back to Fedora as
applicable so that I can contribute to Fedora.

As a Fedora contributor, I can use a public API so that I can develop
workflow tools for myself and my team.

As a repository admin, I can define custom labels for a repo so that
it can support my team’s particular workflow.

As a repository admin, I can define arbitrary custom fields for a repo
so that it can support my team’s particular workflow.

As a Fedora contributor, I can file bugs and feature requests in an
issue tracker so that I can provide feedback or track desired work.

As a Fedora team member, I can vote +1/abstain/-1 on issues so that I
can approve or deny proposals.

As a Fedora contributor, I want issues to support inline images in
order to simplify the workflow for visual tasks (e.g. design work)

As a Fedora contributor, I want a Kanban board so that I can visually
track the status of work and do project planning.

As a Fedora contributor, I can perform issue and pull request actions
on mobile devices via a native mobile app or a mobile-friendly webapp
so that I can contribute while away from my desk.

As a Fedora contributor, I can reassign issues/bugs to another
component so that I can cooperate with other contributors when an
issue is mis-assigned.



-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis

[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
> <lgriffin(a)redhat.com&gt; 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/[e-mail]...
. 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

[Ben Cotton]

On Fri, Apr 3, 2020 at 12:42 PM Adam Williamson
<adamwill(a)fedoraproject.org&gt; 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-hack...

-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis

[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
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[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

[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
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[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

[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

[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

[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

[Neal Gompa]

On Fri, Apr 3, 2020 at 1:28 PM Kevin Fenzi <kevin(a)scrye.com&gt; 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[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

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

At least with Pagure, some of the effort I'm doing is starting to bear
fruit, and I'm still working on other initiatives to drive growth
there. For Pagure Dist-Git, I've been focused on attracting other
Linux distributions. For example, Mageia, openSUSE, and Trisquel are
good candidates for this. There has been interest by others for it,
especially in Mageia. But the problem is that Mageia right now runs a
Dist-SVN, and converting to Git is the _first_ step. And in openSUSE,
the usage of Git in general isn't uniform. Trisquel is probably the
easiest of the bunch as they've got basically nothing right now, and
the work the bring up a Pagure server for Trisquel is beginning later
this month.

Fedora Messaging is a wrapper around AMQP, as opposed to FedMsg (which
implemented everything around ZeroMQ). Beyond the library (which is
likely to be picked up in usage as apps that use it are adopted), I
don't know what else you'd want? I know it'll wind up becoming
available in openSUSE because I've been working with them to adopt
Noggin+Ipsilon for openSUSE's new account system, and Noggin already
requires it. Integrating Fedora-Messaging with openSUSE's AMQP
infrastructure will certainly get interesting...

modernpaste (which we used as a pastebin) is in the process of being
revived as postmodern-paste, with folks from openSUSE helping to bring
it up to snuff.

There's already an existing effort for openSUSE to adopt
MirrorManager2 in part or whole. I've also been talking to some of the
other smaller distributions (like Adélie Linux) about adopting it and
contributing to it.

Mailman 3 + HyperKitty + Postorius are in the process of being adopted
by a number of projects and distributions now, so that's finally
taking off. :)

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.

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.



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Markus Larsson]

On 3 April 2020 19:18:57 CEST, Matthew Miller <mattdm(a)fedoraproject.org&gt; 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

[Leigh Griffin]

On Fri, Apr 3, 2020, 18:21 Adam Williamson <adamwill(a)fedoraproject.org&gt;
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-discuss(a)lists.fedoraproject.org
>  To unsubscribe send an email to
>  council-discuss-leave(a)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/[e-mail]...
>

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

[Leigh Griffin]

On Fri, Apr 3, 2020, 18:22 Adam Williamson <adamwill(a)fedoraproject.org&gt;
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-discuss(a)lists.fedoraproject.org
>  To unsubscribe send an email to
>  council-discuss-leave(a)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/[e-mail]...
>

[Leigh Griffin]

On Fri, Apr 3, 2020, 17:42 Adam Williamson <adamwill(a)fedoraproject.org&gt;
wrote:

>  On Fri, 2020-04-03 at 12:07 -0400, Ben Cotton wrote:
>  > On Fri, Apr 3, 2020 at 11:59 AM Leigh Griffin <lgriffin(a)redhat.com&gt;
>  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/[e-mail]...
>  . 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-discuss(a)lists.fedoraproject.org
>  To unsubscribe send an email to
>  council-discuss-leave(a)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/[e-mail]...
>

[Adam Williamson]

On Fri, 2020-04-03 at 20:12 +0200, Markus Larsson wrote:
>  
>  On 3 April 2020 19:18:57 CEST, Matthew Miller <mattdm(a)fedoraproject.org&gt; 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 compromising on our F/OSS principles.

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/

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.

Or to take the "Kanban" requirement - obviously there are existing
F/OSS Kanban implementations, some of which are available as SaaS, like
Taiga. Is it really so important to have this feature implemented
*within our git forge* that it outweighs our F/OSS principles?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Adam Williamson]

On Fri, 2020-04-03 at 19:30 +0100, Leigh Griffin wrote:
>  On Fri, Apr 3, 2020, 18:22 Adam Williamson
> <adamwill(a)fedoraproject.org&gt;
>  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

[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 <jeremy(a)jcline.org&gt;
>  wrote:
>  > On Fri, 2020-04-03 at 05:38 -0400, Neal Gompa wrote:
>  > > On Fri, Apr 3, 2020 at 5:29 AM Michal Konecny <
>  > mkonecny(a)redhat.com&gt;
>  > > 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

[Adam Williamson]

On Fri, 2020-04-03 at 19:28 +0100, Leigh Griffin wrote:
>  On Fri, Apr 3, 2020, 18:21 Adam Williamson
> <adamwill(a)fedoraproject.org&gt;
>  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

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

[Chris Adams]

Once upon a time, Kevin Fenzi <kevin(a)scrye.com&gt; 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 <linux(a)cmadams.net&gt;

[Adam Williamson]

On Fri, 2020-04-03 at 14:41 -0500, Chris Adams wrote:
>  Once upon a time, Kevin Fenzi <kevin(a)scrye.com&gt; 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

[Michael Catanzaro]

On Fri, Apr 3, 2020 at 12:10 pm, Adam Williamson 
<adamwill(a)fedoraproject.org&gt; 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

[Michael Catanzaro]

On Fri, Apr 3, 2020 at 2:46 pm, Michael Catanzaro 
<mcatanzaro(a)gnome.org&gt; 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....

[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 <kevin(a)scrye.com&gt;
> 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

[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 
>  <adamwill(a)fedoraproject.org&gt; 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

[Neal Gompa]

On Fri, Apr 3, 2020 at 3:57 PM Adam Williamson
<adamwill(a)fedoraproject.org&gt; wrote:
>  On Fri, 2020-04-03 at 14:46 -0500, Michael Catanzaro wrote:
>  > On Fri, Apr 3, 2020 at 12:10 pm, Adam Williamson
>  > <adamwill(a)fedoraproject.org&gt; 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!

[Leigh Griffin]

On Fri, Apr 3, 2020, 20:26 Randy Barlow <bowlofeggs(a)fedoraproject.org&gt;
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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>

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

[Neal Gompa]

On Fri, Apr 3, 2020 at 9:42 PM Randy Barlow
<bowlofeggs(a)fedoraproject.org&gt; 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!

[clime]

On Sat, 4 Apr 2020 at 14:04, Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  On Fri, Apr 3, 2020 at 9:42 PM Randy Barlow
>  <bowlofeggs(a)fedoraproject.org&gt; 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 damaging for both sides (RH and
Fedora). Slower but more careful progress is OK.

clime

>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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/[e-mail]

[Fabien Boucher]

On Fri, Apr 3, 2020 at 9:11 PM Adam Williamson
<adamwill(a)fedoraproject.org&gt; 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.

[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

[Leigh Griffin]

On Sat, Apr 4, 2020 at 2:43 AM Randy Barlow <bowlofeggs(a)fedoraproject.org&gt;
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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  

-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford <https://www.redhat.com/>

Communications House

Cork Road, Waterford City

lgriffin(a)redhat.com
M: [phone]     IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>

[Neal Gompa]

On Mon, Apr 6, 2020 at 6:14 AM Dominik 'Rathann' Mierzejewski
<dominik(a)greysector.net&gt; 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!

[Leigh Griffin]

<snip>
>  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(a)lists.fedoraproject.org
>  > To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  

-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford <https://www.redhat.com/>

Communications House

Cork Road, Waterford City

lgriffin(a)redhat.com
M: [phone]     IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>

[Leigh Griffin]

On Fri, Apr 3, 2020 at 8:15 PM Jeremy Cline <jeremy(a)jcline.org&gt; 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 <jeremy(a)jcline.org&gt;
>  > wrote:
>  > > On Fri, 2020-04-03 at 05:38 -0400, Neal Gompa wrote:
>  > > > On Fri, Apr 3, 2020 at 5:29 AM Michal Konecny <
>  > > mkonecny(a)redhat.com&gt;
>  > > > 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 <https://www.redhat.com/>

Communications House

Cork Road, Waterford City

lgriffin(a)redhat.com
M: [phone]     IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>

[clime]

On Monday, 6 April 2020, Leigh Griffin <lgriffin(a)redhat.com&gt; wrote:

>  <snip>
> >
> >
> > 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(a)lists.fedoraproject.org
> > > To unsubscribe send an email to devel-leave(a)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(a)lists.fedoraproject.org
> > _______________________________________________
> > devel mailing list -- devel(a)lists.fedoraproject.org
> > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> > Fedora Code of Conduct: https://docs.fedoraproject.
> > org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.
> > fedoraproject.org
> >
>
>
>  --
>
>  Leigh Griffin
>
>  Engineering Manager
>
>  Red Hat Waterford <https://www.redhat.com/>
>
>  Communications House
>
>  Cork Road, Waterford City
>
>  lgriffin(a)redhat.com
>  M: [phone]     IM: lgriffin
>  @redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
>  <https://www.facebook.com/redhatjobs> @redhatjobs
>  <https://instagram.com/redhatjobs>
>  <https://red.ht/sig>
>

[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: [phone]
IRC: mhroncok

[Julen Landa Alustiza]

<snip>

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...
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 <jlanda(a)fedoraproject.org&gt;

[Stasiek Michalski]

>  On Fri, Apr 3, 2020 at 12:10 pm, Adam Williamson 
>  <adamwill(a)fedoraproject.org&gt; wrote:
>  
>  $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

[Josh Boyer]

On Mon, Apr 6, 2020 at 8:26 AM Stasiek Michalski <stasiek(a)michalski.cc&gt; wrote:
>  > On Fri, Apr 3, 2020 at 12:10 pm, Adam Williamson
>  > <adamwill(a)fedoraproject.org&gt; wrote:
>  >
>  > $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

[Stasiek Michalski]

>  On Mon, Apr 6, 2020 at 8:26 AM Stasiek Michalski
> <stasiek(a)michalski.cc&gt; 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

[Josh Boyer]

On Mon, Apr 6, 2020 at 8:42 AM Stasiek Michalski <stasiek(a)michalski.cc&gt; wrote:
>  > On Mon, Apr 6, 2020 at 8:26 AM Stasiek Michalski <stasiek(a)michalski.cc&gt;
> 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. 
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

[Neal Gompa]

On Mon, Apr 6, 2020 at 8:42 AM Stasiek Michalski <stasiek(a)michalski.cc&gt; wrote:
>  > On Mon, Apr 6, 2020 at 8:26 AM Stasiek Michalski <stasiek(a)michalski.cc&gt;
> 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.
>  
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!

[Neal Gompa]

On Mon, Apr 6, 2020 at 8:48 AM Josh Boyer <jwboyer(a)fedoraproject.org&gt; wrote:
>  On Mon, Apr 6, 2020 at 8:42 AM Stasiek Michalski <stasiek(a)michalski.cc&gt; wrote:
>  >
>  > > On Mon, Apr 6, 2020 at 8:26 AM Stasiek Michalski
> <stasiek(a)michalski.cc&gt; 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.
>
>  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!

[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

[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

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

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

[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
> <stasiek(a)michalski.cc&gt; wrote:
> >> On Fri, Apr 3, 2020 at 12:10 pm, Adam Williamson
> >> <adamwill(a)fedoraproject.org&gt; wrote:
> >>
> >> $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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]

[Josh Boyer]

On Mon, Apr 6, 2020 at 10:15 AM Vít Ondruch <vondruch(a)redhat.com&gt; wrote:
>  Dne 06. 04. 20 v 14:34 Josh Boyer napsal(a):
>  > On Mon, Apr 6, 2020 at 8:26 AM Stasiek Michalski <stasiek(a)michalski.cc&gt;
> wrote:
>  >>> On Fri, Apr 3, 2020 at 12:10 pm, Adam Williamson
>  >>> <adamwill(a)fedoraproject.org&gt; wrote:
>  >>>
>  >>> $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

[Leigh Griffin]

On Mon, Apr 6, 2020 at 11:56 AM clime <clime(a)fedoraproject.org&gt; wrote:

>  On Monday, 6 April 2020, Leigh Griffin <lgriffin(a)redhat.com&gt; wrote:
>
> >
> >
> > <snip>
> >>
> >>
> >> 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(a)lists.fedoraproject.org
> >> > To unsubscribe send an email to devel-leave(a)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/[e-mail]
> >> _______________________________________________
> >> devel mailing list -- devel(a)lists.fedoraproject.org
> >> To unsubscribe send an email to devel-leave(a)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/[e-mail]
> >>
> >
> >
> > --
> >
> > Leigh Griffin
> >
> > Engineering Manager
> >
> > Red Hat Waterford <https://www.redhat.com/>
> >
> > Communications House
> >
> > Cork Road, Waterford City
> >
> > lgriffin(a)redhat.com
> > M: [phone]     IM: lgriffin
> > @redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
> > <https://www.facebook.com/redhatjobs> @redhatjobs
> > <https://instagram.com/redhatjobs>
> > <https://red.ht/sig>
> >
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  

-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford <https://www.redhat.com/>

Communications House

Cork Road, Waterford City

lgriffin(a)redhat.com
M: [phone]     IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>

[Leigh Griffin]

On Mon, Apr 6, 2020 at 11:59 AM Miro Hrončok <mhroncok(a)redhat.com&gt; 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: [phone]
>  IRC: mhroncok
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  

-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford <https://www.redhat.com/>

Communications House

Cork Road, Waterford City

lgriffin(a)redhat.com
M: [phone]     IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>

[Leigh Griffin]

On Mon, Apr 6, 2020 at 12:10 PM Julen Landa Alustiza <
jlanda(a)fedoraproject.org&gt; wrote:

>  <snip>
>
>  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
<https://pagure.io/fedora-infrastructure/issues?status=all&tags=pagure...
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...
>  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 <jlanda(a)fedoraproject.org&gt;
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  

-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford <https://www.redhat.com/>

Communications House

Cork Road, Waterford City

lgriffin(a)redhat.com
M: [phone]     IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>

[Leigh Griffin]

On Mon, Apr 6, 2020 at 2:14 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:

>  On Mon, Apr 6, 2020 at 8:48 AM Josh Boyer
> <jwboyer(a)fedoraproject.org&gt;
>  wrote:
>  >
>  > On Mon, Apr 6, 2020 at 8:42 AM Stasiek Michalski <stasiek(a)michalski.cc&gt;
>  wrote:
>  > >
>  > > > On Mon, Apr 6, 2020 at 8:26 AM Stasiek Michalski
>  <stasiek(a)michalski.cc&gt; 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.
>  >
>  > 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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  

-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford <https://www.redhat.com/>

Communications House

Cork Road, Waterford City

lgriffin(a)redhat.com
M: [phone]     IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>

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

[Leigh Griffin]

On Mon, Apr 6, 2020 at 2:36 PM Dominik 'Rathann' Mierzejewski <
dominik(a)greysector.net&gt; 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.
>          -- from "Collected Sayings of Muad'Dib" by the Princess Irulan
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  

-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford <https://www.redhat.com/>

Communications House

Cork Road, Waterford City

lgriffin(a)redhat.com
M: [phone]     IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>

[Leigh Griffin]

On Mon, Apr 6, 2020 at 3:49 PM Randy Barlow <bowlofeggs(a)fedoraproject.org&gt;
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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  

-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford <https://www.redhat.com/>

Communications House

Cork Road, Waterford City

lgriffin(a)redhat.com
M: [phone]     IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>

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

[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

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

[Leigh Griffin]

On Mon, Apr 6, 2020 at 4:25 PM Adam Williamson <adamwill(a)fedoraproject.org&gt;
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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  

-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford <https://www.redhat.com/>

Communications House

Cork Road, Waterford City

lgriffin(a)redhat.com
M: [phone]     IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>

[clime]

On Mon, 6 Apr 2020 at 17:05, Leigh Griffin <lgriffin(a)redhat.com&gt; wrote:

>  On Mon, Apr 6, 2020 at 2:36 PM Dominik 'Rathann' Mierzejewski <
>  dominik(a)greysector.net&gt; 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 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.
> >         -- from "Collected Sayings of Muad'Dib" by the Princess Irulan
> > _______________________________________________
> > devel mailing list -- devel(a)lists.fedoraproject.org
> > To unsubscribe send an email to devel-leave(a)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/[e-mail]
> >
>
>
>  --
>
>  Leigh Griffin
>
>  Engineering Manager
>
>  Red Hat Waterford <https://www.redhat.com/>
>
>  Communications House
>
>  Cork Road, Waterford City
>
>  lgriffin(a)redhat.com
>  M: [phone]     IM: lgriffin
>  @redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
>  <https://www.facebook.com/redhatjobs> @redhatjobs
>  <https://instagram.com/redhatjobs>
>  <https://red.ht/sig>
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>

[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

[Sheogorath]

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

[clime]

On Mon, 6 Apr 2020 at 17:52, Leigh Griffin <lgriffin(a)redhat.com&gt; wrote:
>  On Mon, Apr 6, 2020 at 4:25 PM Adam Williamson <adamwill(a)fedoraproject.org&gt; 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(a)lists.fedoraproject.org
>> To unsubscribe send an email to devel-leave(a)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/[e-mail]
>
>
>
> --
>
> Leigh Griffin
>
> Engineering Manager
>
> Red Hat Waterford
>
> Communications House
>
> Cork Road, Waterford City
>
> lgriffin(a)redhat.com
> M: [phone]     IM: lgriffin
>
> @redhatjobs   redhatjobs @redhatjobs
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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/[e-mail]

[Dan Čermák]

Leigh Griffin <lgriffin(a)redhat.com&gt; 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

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

[Bruno Wolff III]

On Mon, Apr 06, 2020 at 16:02:34 +0100,
  Leigh Griffin <lgriffin(a)redhat.com&gt; 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.

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 <fche(a)redhat.com&gt;
>  > 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

[Iñaki Ucar]

On Tue, 7 Apr 2020 at 03:08, Randy Barlow <bowlofeggs(a)fedoraproject.org&gt; 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

[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
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader
Not the Pope

[Aleksandra Fedorova]

On Mon, 6 Apr 2020, 21:26 clime, <clime(a)fedoraproject.org&gt; wrote:

>  On Mon, 6 Apr 2020 at 17:52, Leigh Griffin
> <lgriffin(a)redhat.com&gt; wrote:
>  >
>  >
>  >
>  > On Mon, Apr 6, 2020 at 4:25 PM Adam Williamson <
>  adamwill(a)fedoraproject.org&gt; 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(a)lists.fedoraproject.org
>  >> To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  >
>  >
>  >
>  > --
>  >
>  > Leigh Griffin
>  >
>  > Engineering Manager
>  >
>  > Red Hat Waterford
>  >
>  > Communications House
>  >
>  > Cork Road, Waterford City
>  >
>  > lgriffin(a)redhat.com
>  > M: [phone]     IM: lgriffin
>  >
>  > @redhatjobs   redhatjobs @redhatjobs
>  > _______________________________________________
>  > devel mailing list -- devel(a)lists.fedoraproject.org
>  > To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>