Git Forge Requirements: Please see the Community Blog

[Leigh Griffin]

Hey Everyone,

On behalf of the CPE team I want to draw the communities attention to a
recent blog post which you may be impacted by:
 https://communityblog.fedoraproject.org/git-forge-requirements/

We will be seeking input and requirements in an open and transparent manner
on the future of a git forge solution which will be run by the CPE team on
behalf of the Fedora Community. This mail is being sent to the devel,
mindshare and council-discuss lists for maximum visibility on a BCC to
allow each list have their own views. Please forward it to any other list
you may feel is relevant to maximise the exposure.

Thanks in advance,
Leigh

-- 

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 Tue, Jan 21, 2020 at 5:40 PM Leigh Griffin <lgriffin(a)redhat.com&gt; wrote:
>  Hey Everyone,
>
>  On behalf of the CPE team I want to draw the communities attention to a recent blog post
> which you may be impacted by:
>   https://communityblog.fedoraproject.org/git-forge-requirements/
>
>  We will be seeking input and requirements in an open and transparent manner on the future
> of a git forge solution which will be run by the CPE team on behalf of the Fedora
> Community. This mail is being sent to the devel, mindshare and council-discuss lists for
> maximum visibility on a BCC to allow each list have their own views. Please forward it to
> any other list you may feel is relevant to maximise the exposure.
>
>  Thanks in advance,
>  Leigh 
Alright, I have some questions that are not answered by the blog post.

- What is going to happen to the two pagure instances at pagure.io,
and src.fedoraproject.org?

I think pagure.io is a good home for fedora-related projects (it was
the successor to fedorahosted.org, after all, IIRC). I know that many
group efforts are hosting their source code, ticketing system, etc.
there (Go SIG, Stewardship SIG, FPC, FESCo, etc.). If it is decided to
shut down pagure.io, I assume those projects will have to be moved
somewhere?

Also, it's very nice to have a PR-based workflow for some
shared-maintenance packages on src.fedoraproject.org, and I don't
think losing that feature would be a good thing for fedora.

- How is GitHub considered to be an alternative here?

I don't think (public or hosted) GitHub can do what is currently done
on src.fedoraproject.org, can it?
I'd also not want to see fedora use a closed-source product for such a
core service ...

- Which features are missing from pagure, compared to the other forges?

For my purposes, I don't miss any feature on pagure.io compared to my
repositories on github.com, and OTTOMH, I can't come up with any
missing features, at all ...


TL;DR:
Can we please keep pagure? It already has the fedora-specific features
we need, and I don't mind a "slow" pace of development.
In my experience, it works really well, and I actually *like* to use
it (which is not true for GitLab ... which is slow and horrible)

Fabio

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

[Leigh Griffin]

On Tue, Jan 21, 2020, 17:17 Fabio Valentini <decathorpe(a)gmail.com&gt; wrote:

>  On Tue, Jan 21, 2020 at 5:40 PM Leigh Griffin
> <lgriffin(a)redhat.com&gt; wrote:
>  >
>  > Hey Everyone,
>  >
>  > On behalf of the CPE team I want to draw the communities attention to a
>  recent blog post which you may be impacted by:
>  >  https://communityblog.fedoraproject.org/git-forge-requirements/
>  >
>  > We will be seeking input and requirements in an open and transparent
>  manner on the future of a git forge solution which will be run by the CPE
>  team on behalf of the Fedora Community. This mail is being sent to the
>  devel, mindshare and council-discuss lists for maximum visibility on a BCC
>  to allow each list have their own views. Please forward it to any other
>  list you may feel is relevant to maximise the exposure.
>  >
>  > Thanks in advance,
>  > Leigh
>
>  Alright, I have some questions that are not answered by the blog post.
>
>  - What is going to happen to the two pagure instances at pagure.io,
>  and src.fedoraproject.org?
>
>  I think pagure.io is a good home for fedora-related projects (it was
>  the successor to fedorahosted.org, after all, IIRC). I know that many
>  group efforts are hosting their source code, ticketing system, etc.
>  there (Go SIG, Stewardship SIG, FPC, FESCo, etc.). If it is decided to
>  shut down pagure.io, I assume those projects will have to be moved
>  somewhere?
>  
That scenario assumes a certain result and decision from the requirements
analysis so I genuinely have no answer here. Whatever choice we make, an
impact analysis would be needed in some shape or form. That (and our next
steps) will be done collaboratively in the open.

>  Also, it's very nice to have a PR-based workflow for some
>  shared-maintenance packages on src.fedoraproject.org, and I don't
>  think losing that feature would be a good thing for fedora.
>
>  - How is GitHub considered to be an alternative here?
>
>  I don't think (public or hosted) GitHub can do what is currently done
>  on src.fedoraproject.org, can it?
>  I'd also not want to see fedora use a closed-source product for such a
>  core service ...
>
>  - Which features are missing from pagure, compared to the other forges?
>
>  For my purposes, I don't miss any feature on pagure.io compared to my
>  repositories on github.com, and OTTOMH, I can't come up with any
>  missing features, at all ...
>
>
>  TL;DR:
>  Can we please keep pagure? It already has the fedora-specific features
>  we need, and I don't mind a "slow" pace of development.
>  In my experience, it works really well, and I actually *like* to use
>  it (which is not true for GitLab ... which is slow and horrible)
>
>  Fabio
>
>  > --
>  >
>  > 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]
>

[Fabio Valentini]

On Tue, Jan 21, 2020 at 8:30 PM Leigh Griffin <lgriffin(a)redhat.com&gt; wrote:
>  On Tue, Jan 21, 2020, 17:17 Fabio Valentini <decathorpe(a)gmail.com&gt; wrote:
> >
> > On Tue, Jan 21, 2020 at 5:40 PM Leigh Griffin <lgriffin(a)redhat.com&gt; wrote:
> > >
> > > Hey Everyone,
> > >
> > > On behalf of the CPE team I want to draw the communities attention to a recent
> blog post which you may be impacted by:
> > >  https://communityblog.fedoraproject.org/git-forge-requirements/
> > >
> > > We will be seeking input and requirements in an open and transparent manner on
> the future of a git forge solution which will be run by the CPE team on behalf of the
> Fedora Community. This mail is being sent to the devel, mindshare and council-discuss
> lists for maximum visibility on a BCC to allow each list have their own views. Please
> forward it to any other list you may feel is relevant to maximise the exposure.
> > >
> > > Thanks in advance,
> > > Leigh
> >
> > Alright, I have some questions that are not answered by the blog post.
> >
> > - What is going to happen to the two pagure instances at pagure.io,
> > and src.fedoraproject.org?
> >
> > I think pagure.io is a good home for fedora-related projects (it was
> > the successor to fedorahosted.org, after all, IIRC). I know that many
> > group efforts are hosting their source code, ticketing system, etc.
> > there (Go SIG, Stewardship SIG, FPC, FESCo, etc.). If it is decided to
> > shut down pagure.io, I assume those projects will have to be moved
> > somewhere? 
(snip)

>  That scenario assumes a certain result and decision from the
> requirements analysis so I genuinely have no answer here. Whatever choice we make, an
> impact analysis would be needed in some shape or form. That (and our next steps) will be
> done collaboratively in the open. 
I'm sorry, but I'm genuinely confused now. Maybe I'm tired, or maybe
this is a language barrier issue ... but I'd hope that an impact
analysis of the different possibilities would be done *before* making
a decision, not after?

I mean, whatever the "Git Forge Requirements" will be, we'd need to
know how any change will affect the projects and groups that are
currently using pagure ...

Fabio

>>
>> Also, it's very nice to have a PR-based workflow for some
>> shared-maintenance packages on src.fedoraproject.org, and I don't
>> think losing that feature would be a good thing for fedora.
>>
>> - How is GitHub considered to be an alternative here?
>>
>> I don't think (public or hosted) GitHub can do what is currently done
>> on src.fedoraproject.org, can it?
>> I'd also not want to see fedora use a closed-source product for such a
>> core service ...
>>
>> - Which features are missing from pagure, compared to the other forges?
>>
>> For my purposes, I don't miss any feature on pagure.io compared to my
>> repositories on github.com, and OTTOMH, I can't come up with any
>> missing features, at all ...
>>
>>
>> TL;DR:
>> Can we please keep pagure? It already has the fedora-specific features
>> we need, and I don't mind a "slow" pace of development.
>> In my experience, it works really well, and I actually *like* to use
>> it (which is not true for GitLab ... which is slow and horrible)
>>
>> Fabio
>>
>> > --
>> >
>> > 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]
>
> _______________________________________________
> 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, Jan 21, 2020, 20:02 Fabio Valentini <decathorpe(a)gmail.com&gt; wrote:

>  On Tue, Jan 21, 2020 at 8:30 PM Leigh Griffin
> <lgriffin(a)redhat.com&gt; wrote:
>  >
>  >
>  >
>  > On Tue, Jan 21, 2020, 17:17 Fabio Valentini <decathorpe(a)gmail.com&gt;
>  wrote:
>  >>
>  >> On Tue, Jan 21, 2020 at 5:40 PM Leigh Griffin <lgriffin(a)redhat.com&gt;
>  wrote:
>  >> >
>  >> > Hey Everyone,
>  >> >
>  >> > On behalf of the CPE team I want to draw the communities attention to
>  a recent blog post which you may be impacted by:
>  >> >  https://communityblog.fedoraproject.org/git-forge-requirements/
>  >> >
>  >> > We will be seeking input and requirements in an open and transparent
>  manner on the future of a git forge solution which will be run by the CPE
>  team on behalf of the Fedora Community. This mail is being sent to the
>  devel, mindshare and council-discuss lists for maximum visibility on a BCC
>  to allow each list have their own views. Please forward it to any other
>  list you may feel is relevant to maximise the exposure.
>  >> >
>  >> > Thanks in advance,
>  >> > Leigh
>  >>
>  >> Alright, I have some questions that are not answered by the blog post.
>  >>
>  >> - What is going to happen to the two pagure instances at pagure.io,
>  >> and src.fedoraproject.org?
>  >>
>  >> I think pagure.io is a good home for fedora-related projects (it was
>  >> the successor to fedorahosted.org, after all, IIRC). I know that many
>  >> group efforts are hosting their source code, ticketing system, etc.
>  >> there (Go SIG, Stewardship SIG, FPC, FESCo, etc.). If it is decided to
>  >> shut down pagure.io, I assume those projects will have to be moved
>  >> somewhere?
>
>  (snip)
>
>  > That scenario assumes a certain result and decision from the
>  requirements analysis so I genuinely have no answer here. Whatever choice
>  we make, an impact analysis would be needed in some shape or form. That
>  (and our next steps) will be done collaboratively in the open.
>
>  I'm sorry, but I'm genuinely confused now. Maybe I'm tired, or maybe
>  this is a language barrier issue ... but I'd hope that an impact
>  analysis of the different possibilities would be done *before* making
>  a decision, not after?
>
>  I mean, whatever the "Git Forge Requirements" will be, we'd need to
>  know how any change will affect the projects and groups that are
>  currently using pagure ...
>  
Sorry I should have been more detailed on the steps, that's on me. So we
have a few steps in this process, first and foremost is this ODF document
to figure out what are the real requirements/ use cases / features of a git
forge. We gather and analyze that, combining the multiple stakeholder views
and have our requirements to base an analysis on. We then evaluate what
solution(s) meets the requirements and bring those solutions forward. We
then perform impact analysis on what each path might look like from
multiple perspectives which will include obvious costs from a time, money,
resources perspective of using a git forge. A decision can be made then in
an informed way as we know what we want to have, why we want it and what
the cost may be. We haven't fully defined the criteria for that analysis
yet as the requirements will no doubt throw up use cases and scenarios that
we have to factor in. So this is very much a call to arms to help inform us
of how you use a git forge and what your requirements are for one.

Hope that clears it up and sorry for the lack of clarity.

>  Fabio
>
>  >>
>  >> Also, it's very nice to have a PR-based workflow for some
>  >> shared-maintenance packages on src.fedoraproject.org, and I don't
>  >> think losing that feature would be a good thing for fedora.
>  >>
>  >> - How is GitHub considered to be an alternative here?
>  >>
>  >> I don't think (public or hosted) GitHub can do what is currently done
>  >> on src.fedoraproject.org, can it?
>  >> I'd also not want to see fedora use a closed-source product for such a
>  >> core service ...
>  >>
>  >> - Which features are missing from pagure, compared to the other forges?
>  >>
>  >> For my purposes, I don't miss any feature on pagure.io compared to my
>  >> repositories on github.com, and OTTOMH, I can't come up with any
>  >> missing features, at all ...
>  >>
>  >>
>  >> TL;DR:
>  >> Can we please keep pagure? It already has the fedora-specific features
>  >> we need, and I don't mind a "slow" pace of development.
>  >> In my experience, it works really well, and I actually *like* to use
>  >> it (which is not true for GitLab ... which is slow and horrible)
>  >>
>  >> Fabio
>  >>
>  >> > --
>  >> >
>  >> > 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]
>  >
>  > _______________________________________________
>  > 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]
>

[Fabio Valentini]

On Tue, Jan 21, 2020 at 10:02 PM Leigh Griffin <lgriffin(a)redhat.com&gt; wrote:
>  On Tue, Jan 21, 2020, 20:02 Fabio Valentini <decathorpe(a)gmail.com&gt; wrote:
> >
> > On Tue, Jan 21, 2020 at 8:30 PM Leigh Griffin <lgriffin(a)redhat.com&gt; wrote:
> > >
> > >
> > >
> > > On Tue, Jan 21, 2020, 17:17 Fabio Valentini <decathorpe(a)gmail.com&gt; wrote:
> > >>
> > >> On Tue, Jan 21, 2020 at 5:40 PM Leigh Griffin <lgriffin(a)redhat.com&gt;
> wrote:
> > >> >
> > >> > Hey Everyone,
> > >> >
> > >> > On behalf of the CPE team I want to draw the communities attention to a
> recent blog post which you may be impacted by:
> > >> >  https://communityblog.fedoraproject.org/git-forge-requirements/
> > >> >
> > >> > We will be seeking input and requirements in an open and transparent
> manner on the future of a git forge solution which will be run by the CPE team on behalf
> of the Fedora Community. This mail is being sent to the devel, mindshare and
> council-discuss lists for maximum visibility on a BCC to allow each list have their own
> views. Please forward it to any other list you may feel is relevant to maximise the
> exposure.
> > >> >
> > >> > Thanks in advance,
> > >> > Leigh
> > >>
> > >> Alright, I have some questions that are not answered by the blog post.
> > >>
> > >> - What is going to happen to the two pagure instances at pagure.io,
> > >> and src.fedoraproject.org?
> > >>
> > >> I think pagure.io is a good home for fedora-related projects (it was
> > >> the successor to fedorahosted.org, after all, IIRC). I know that many
> > >> group efforts are hosting their source code, ticketing system, etc.
> > >> there (Go SIG, Stewardship SIG, FPC, FESCo, etc.). If it is decided to
> > >> shut down pagure.io, I assume those projects will have to be moved
> > >> somewhere?
> >
> > (snip)
> >
> > > That scenario assumes a certain result and decision from the requirements
> analysis so I genuinely have no answer here. Whatever choice we make, an impact analysis
> would be needed in some shape or form. That (and our next steps) will be done
> collaboratively in the open.
> >
> > I'm sorry, but I'm genuinely confused now. Maybe I'm tired, or maybe
> > this is a language barrier issue ... but I'd hope that an impact
> > analysis of the different possibilities would be done *before* making
> > a decision, not after?
> >
> > I mean, whatever the "Git Forge Requirements" will be, we'd need to
> > know how any change will affect the projects and groups that are
> > currently using pagure ... 
(...)

>  Sorry I should have been more detailed on the steps, that's on
> me. So we have a few steps in this process, first and foremost is this ODF document to
> figure out what are the real requirements/ use cases / features of a git forge. We gather
> and analyze that, combining the multiple stakeholder views and have our requirements to
> base an analysis on. We then evaluate what solution(s) meets the requirements and bring
> those solutions forward. We then perform impact analysis on what each path might look like
> from multiple perspectives which will include obvious costs from a time, money, resources
> perspective of using a git forge. A decision can be made then in an informed way as we
> know what we want to have, why we want it and what the cost may be. We haven't fully
> defined the criteria for that analysis yet as the requirements will no doubt throw up use
> cases and scenarios that we have to factor in. So this is very much a call to arms to help
> inform us of how you use a git forge and what your requirements are for one.
>
>  Hope that clears it up and sorry for the lack of clarity. 
Yes! Absolutely, thank you.
Is there a place where we can suggest such formal "requirements"? I
don't think either mailing list posts nor comments on the community
blog post are a good medium for that.

Fabio

>>
>> Fabio
>>
>> >>
>> >> Also, it's very nice to have a PR-based workflow for some
>> >> shared-maintenance packages on src.fedoraproject.org, and I don't
>> >> think losing that feature would be a good thing for fedora.
>> >>
>> >> - How is GitHub considered to be an alternative here?
>> >>
>> >> I don't think (public or hosted) GitHub can do what is currently
done
>> >> on src.fedoraproject.org, can it?
>> >> I'd also not want to see fedora use a closed-source product for such
a
>> >> core service ...
>> >>
>> >> - Which features are missing from pagure, compared to the other forges?
>> >>
>> >> For my purposes, I don't miss any feature on pagure.io compared to
my
>> >> repositories on github.com, and OTTOMH, I can't come up with any
>> >> missing features, at all ...
>> >>
>> >>
>> >> TL;DR:
>> >> Can we please keep pagure? It already has the fedora-specific features
>> >> we need, and I don't mind a "slow" pace of development.
>> >> In my experience, it works really well, and I actually *like* to use
>> >> it (which is not true for GitLab ... which is slow and horrible)
>> >>
>> >> Fabio
>> >>
>> >> > --
>> >> >
>> >> > 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]
>> >
>> > _______________________________________________
>> > 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]
>
> _______________________________________________
> 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 Tue, Jan 21, 2020 at 3:01 PM Fabio Valentini <decathorpe(a)gmail.com&gt; wrote:
>  On Tue, Jan 21, 2020 at 8:30 PM Leigh Griffin <lgriffin(a)redhat.com&gt; wrote:
>  >
>  >
>  >
>  > On Tue, Jan 21, 2020, 17:17 Fabio Valentini <decathorpe(a)gmail.com&gt; wrote:
>  >>
>  >> On Tue, Jan 21, 2020 at 5:40 PM Leigh Griffin <lgriffin(a)redhat.com&gt;
> wrote:
>  >> >
>  >> > Hey Everyone,
>  >> >
>  >> > On behalf of the CPE team I want to draw the communities attention to a
> recent blog post which you may be impacted by:
>  >> >  https://communityblog.fedoraproject.org/git-forge-requirements/
>  >> >
>  >> > We will be seeking input and requirements in an open and transparent manner
> on the future of a git forge solution which will be run by the CPE team on behalf of the
> Fedora Community. This mail is being sent to the devel, mindshare and council-discuss
> lists for maximum visibility on a BCC to allow each list have their own views. Please
> forward it to any other list you may feel is relevant to maximise the exposure.
>  >> >
>  >> > Thanks in advance,
>  >> > Leigh
>  >>
>  >> Alright, I have some questions that are not answered by the blog post.
>  >>
>  >> - What is going to happen to the two pagure instances at pagure.io,
>  >> and src.fedoraproject.org?
>  >>
>  >> I think pagure.io is a good home for fedora-related projects (it was
>  >> the successor to fedorahosted.org, after all, IIRC). I know that many
>  >> group efforts are hosting their source code, ticketing system, etc.
>  >> there (Go SIG, Stewardship SIG, FPC, FESCo, etc.). If it is decided to
>  >> shut down pagure.io, I assume those projects will have to be moved
>  >> somewhere?
>
>  (snip)
>
>  > That scenario assumes a certain result and decision from the requirements analysis
> so I genuinely have no answer here. Whatever choice we make, an impact analysis would be
> needed in some shape or form. That (and our next steps) will be done collaboratively in
> the open.
>
>  I'm sorry, but I'm genuinely confused now. Maybe I'm tired, or maybe
>  this is a language barrier issue ... but I'd hope that an impact
>  analysis of the different possibilities would be done *before* making
>  a decision, not after?
>
>  I mean, whatever the "Git Forge Requirements" will be, we'd need to
>  know how any change will affect the projects and groups that are
>  currently using pagure ...
>  
I think this is the CPE team's way of telling us that they want to
yank pingou from Pagure as part of $PINGOU_DAYJOB work. Otherwise,
this is grotesquely premature, given that the Pagure community is
slowly growing, and we have an increasing contributor base (slowly
growing, but it is growing).

As someone who has run GitHub Enterprise and is currently running
GitLab Enterprise for $MY_DAYJOB work, Pagure is loads easier to
manage and deal with. The "burden", as it were, is considerably lower.
The much saner rate of code churn also means that upgrading and
maintaining the system is much more manageable, which is why I
switched my personal Git server from GitLab CE to Pagure.

I suspect the features that they're thinking of are the trivial CI
setup stuff. Pagure has no equivalent to GitLab CI nor do we have a
service like Travis CI in place to support projects hosted there. We
do have CentOS CI, but because Jenkins is crap and requires the
Jenkins admins to approve projects, it's basically garbage for
self-service CI.

There's no reasonable chance we'd be able to migrate all our
integrations from Pagure to either GitHub or GitLab (self hosted or
otherwise). Aside from GitLab being very anti-integration and GitHub
increasingly going down the same path, the fundamental architecture of
our integrations is quite difficult to do with those two solutions
(message based on a broker). We have hacked around it for GitHub.com
with github2fedmsg, but it's not quite as expressive as the native
functionality Pagure provides is.

And any discussion of GitHub isn't going to involve self-hosted, it's
going to involve GitHub.com, which means we're talking about losing
more of our independence as a project. This is one of those things
that I'm not sure is a wise move.

Honestly, I think the only reason fixes and releases don't come more
frequently for Pagure is because there just aren't many people allowed
to merge and do things. And the CentOS CI frequently breaks. :(

If there's something I'd *love* to see replaced, it's the Jenkins
thing the CentOS Project runs. It's awful and provides a horrible user
and developer experience.


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

[John M. Harris Jr]

On Tuesday, January 21, 2020 2:04:33 PM MST Neal Gompa wrote:
>  Aside from GitLab being very anti-integration 
This is no longer the case, by the way. GitLab has recently made it easier to 
add plugins, with the new method not requiring patching the source tree.

Even before that change, webhook integrations + API calls were fairly powerful 
in GitLab.

-- 
John M. Harris, Jr.
Splentity

[Neal Gompa]

On Tue, Jan 21, 2020 at 4:18 PM John M. Harris Jr <johnmh(a)splentity.com&gt; wrote:
>  On Tuesday, January 21, 2020 2:04:33 PM MST Neal Gompa wrote:
>  > Aside from GitLab being very anti-integration
>
>  This is no longer the case, by the way. GitLab has recently made it easier to
>  add plugins, with the new method not requiring patching the source tree.
>
>  Even before that change, webhook integrations + API calls were fairly powerful
>  in GitLab.
>  
I'm aware of those and the capabilities implied. Unfortunately, this
is very difficult to manage with GitLab Omnibus based deployments, and
there are other caveats and restrictions that make this not as usable
as it looks at first glace. And everyone I've talked to indicates that
the a from-source deployment is a recipe for insanity, so I'm not even
going to go there.


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

[John M. Harris Jr]

On Tuesday, January 21, 2020 2:33:11 PM MST Neal Gompa wrote:
>  Unfortunately, this is very difficult to manage with GitLab Omnibus
>  based deployments 
The new plugin interface makes it so that this is not the case. I make use of 
it on git.splentity.com, for example.

-- 
John M. Harris, Jr.
Splentity

[Michael Catanzaro]

On Tue, Jan 21, 2020 at 4:04 pm, Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  And any discussion of GitHub isn't going to involve self-hosted,
> it's
>  going to involve GitHub.com, which means we're talking about losing
>  more of our independence as a project. This is one of those things
>  that I'm not sure is a wise move. 
Well since we have a request for requirements: I propose requirements 
#1 and #2 are to be self-hosted and open source. I'm suspect the Fedora 
community would be outraged if we fail to meet either requirement.

So if we can agree on that much, then we can avoid wasting time by 
including GitHub in the list of options. That would bring us to a 
choice between GitLab CE and Pagure. (Are there any other serious 
options?)

Michael

[Michael Watters]

On 1/21/20 4:31 PM, Michael Catanzaro wrote:
>  On Tue, Jan 21, 2020 at 4:04 pm, Neal Gompa
> <ngompa13(a)gmail.com&gt; wrote:
> > And any discussion of GitHub isn't going to involve self-hosted, it's
> > going to involve GitHub.com, which means we're talking about losing
> > more of our independence as a project. This is one of those things
> > that I'm not sure is a wise move.
>
>  Well since we have a request for requirements: I propose requirements
>  #1 and #2 are to be self-hosted and open source. I'm suspect the
>  Fedora community would be outraged if we fail to meet either requirement. 
I second this.  FOSS is what's allowed RedHat to succeed and it would
really suck to see Fedora switch to a closed source platform that's
owned by Microsoft...

Also, as somebody who runs a self hosted pagure server I would really
hate to see pagure go away.  I understand Pingou may not have the time
to work on the project as in the past but the torch should definitely be
passed to somebody else or the community to continue work on the project.

[Peter Robinson]

>  >> And any discussion of GitHub isn't going to involve
> self-hosted, it's
>  >> going to involve GitHub.com, which means we're talking about losing
>  >> more of our independence as a project. This is one of those things
>  >> that I'm not sure is a wise move.
>  >
>  > Well since we have a request for requirements: I propose requirements
>  > #1 and #2 are to be self-hosted and open source. I'm suspect the
>  > Fedora community would be outraged if we fail to meet either requirement.
>
>  I second this.  FOSS is what's allowed RedHat to succeed and it would
>  really suck to see Fedora switch to a closed source platform that's
>  owned by Microsoft...
>
>  Also, as somebody who runs a self hosted pagure server I would really
>  hate to see pagure go away.  I understand Pingou may not have the time
>  to work on the project as in the past but the torch should definitely be
>  passed to somebody else or the community to continue work on the project. 
It's open source now so what's stopping people/companies using it now
from contributing rather than relying on Pingou? Similarly if it
ceases to be a core piece of infrastructure for Fedora there's nothing
stopping the pagure community to continue it's development.

[Alex Scheel]

----- Original Message -----
>  From: "Michael Catanzaro" <mcatanzaro(a)gnome.org&gt;
>  To: "Development discussions related to Fedora"
> <devel(a)lists.fedoraproject.org&gt;
>  Sent: Tuesday, January 21, 2020 4:31:47 PM
>  Subject: Re: Git Forge Requirements: Please see the Community Blog
>  
>  On Tue, Jan 21, 2020 at 4:04 pm, Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  > And any discussion of GitHub isn't going to involve self-hosted, it's
>  > going to involve GitHub.com, which means we're talking about losing
>  > more of our independence as a project. This is one of those things
>  > that I'm not sure is a wise move.
>  
>  Well since we have a request for requirements: I propose requirements
>  #1 and #2 are to be self-hosted and open source. I'm suspect the Fedora
>  community would be outraged if we fail to meet either requirement.
>  
>  So if we can agree on that much, then we can avoid wasting time by
>  including GitHub in the list of options. That would bring us to a
>  choice between GitLab CE and Pagure. (Are there any other serious
>  options?) 
I'd mention sr.ht (sourcehut) and gitea; the latter I run myself.

https://sourcehut.org/ (live: https://git.sr.ht/)
https://github.com/go-gitea/gitea demo: https://try.gitea.io/)

YMMV.

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

[Felix Schwarz]

Am 21.01.20 um 22:31 schrieb Michael Catanzaro:
>  Well since we have a request for requirements: I propose requirements
> #1 and
>  #2 are to be self-hosted and open source. 
+1

Felix

[Kevin Fenzi]

On Tue, Jan 21, 2020 at 11:01:59PM +0100, Felix Schwarz wrote:
>  
>  Am 21.01.20 um 22:31 schrieb Michael Catanzaro:
>  > Well since we have a request for requirements: I propose requirements #1 and
>  > #2 are to be self-hosted and open source.
>  
>  +1 
I am with you on open source, but I don't understand the 'self-hosted'
requirement. I guess I agree that self hosting should be possible, in
case someone wants to fork our distro and use our tools, but if we can
convince a open source project to maintain our dist git for us, why is
that bad?

kevin

[Felix Schwarz]

Am 31.01.20 um 03:01 schrieb Kevin Fenzi:
>  I am with you on open source, but I don't understand the
> 'self-hosted'
>  requirement. I guess I agree that self hosting should be possible, in
>  case someone wants to fork our distro and use our tools, but if we can
>  convince a open source project to maintain our dist git for us, why is
>  that bad? 
First there is a bit of paranoia: Often there is software which you could
self-host but if you actually try there are some proprietary bits or you need
some very special patched dependencies. So switching from "hosted externally"
to "self hosted" might be quite hard.

Also dist-git is the very core of Fedora (+ build/update infrastructure and
ticketing). If this is hosted externally we would also need to trust the
external operator. In the end having write access to a spec file means having
root access on all machines which install that package (though you could
detect the modification via git - but I don't want to rely only on git's hash
sums).

In the end I'm also ok with a hosted solution (as I'm not the one doing the
work) as long as there is a (realistic!) backup plan to self-host the code.

As far as I know Debian and Freedesktop maintain their own gitlab instances so
it should be possible to benefit from their experience and tooling.

Felix

[Petr Pisar]

On Thu, Jan 30, 2020 at 06:01:22PM -0800, Kevin Fenzi wrote:
>  I am with you on open source, but I don't understand the
> 'self-hosted'
>  requirement. I guess I agree that self hosting should be possible, in
>  case someone wants to fork our distro and use our tools, but if we can
>  convince a open source project to maintain our dist git for us, why is
>  that bad?
>   
Because of the legal issues? If Fedora starts using e.g. GitHub for dist-git,
then all packagers would have to agree with GitHub use of terms. And I can
imagine that there are people (like me) for whom they are unaccaptable. And
also these terms can change on a whim without consent of the Fedora Project.
I.e. by using a third-party service, you increases the burdends the users have
to overcome.

It's like all the modern payment methods for public transpartation systems
that require you to have a local phone number or an application from Google
application store. They are convenient for most of the users, but they also
discriminate. To take a ride you have to enter into a legal contract with
a third party.

-- Petr

[Kevin Fenzi]

On Fri, Jan 31, 2020 at 10:02:36AM +0100, Petr Pisar wrote:
>  On Thu, Jan 30, 2020 at 06:01:22PM -0800, Kevin Fenzi wrote:
>  > I am with you on open source, but I don't understand the 'self-hosted'
>  > requirement. I guess I agree that self hosting should be possible, in
>  > case someone wants to fork our distro and use our tools, but if we can
>  > convince a open source project to maintain our dist git for us, why is
>  > that bad?
>  > 
>  Because of the legal issues? If Fedora starts using e.g. GitHub for dist-git,
>  then all packagers would have to agree with GitHub use of terms. And I can
>  imagine that there are people (like me) for whom they are unaccaptable. And
>  also these terms can change on a whim without consent of the Fedora Project.
>  I.e. by using a third-party service, you increases the burdends the users have
>  to overcome. 
Thats definitely something to consider. I would think if we have another
company host things for us, we should be able to decide the terms. I
agree just using general github wouldn't work (not only because it's non
free)

>  It's like all the modern payment methods for public
> transpartation systems
>  that require you to have a local phone number or an application from Google
>  application store. They are convenient for most of the users, but they also
>  discriminate. To take a ride you have to enter into a legal contract with
>  a third party. 
Sure, but I am supposing the Fedora Project would enter into some sort
of hosting agreement with a 3rd party, I wasn't assuming we would just
use general github or gitlab.

kevin

[John M. Harris Jr]

On Tuesday, January 21, 2020 2:31:47 PM MST Michael Catanzaro wrote:
>  On Tue, Jan 21, 2020 at 4:04 pm, Neal Gompa
> <ngompa13(a)gmail.com&gt; wrote:
>  
>  > And any discussion of GitHub isn't going to involve self-hosted, it's
>  > going to involve GitHub.com, which means we're talking about losing
>  > more of our independence as a project. This is one of those things
>  > that I'm not sure is a wise move.
>  
>  
>  Well since we have a request for requirements: I propose requirements 
>  #1 and #2 are to be self-hosted and open source. I'm suspect the Fedora 
>  community would be outraged if we fail to meet either requirement.
>  
>  So if we can agree on that much, then we can avoid wasting time by 
>  including GitHub in the list of options. That would bring us to a 
>  choice between GitLab CE and Pagure. (Are there any other serious 
>  options?)
>  
>  Michael 
Both Gitea and Gogs are potential options, in my opinion, both are lightweight 
and easy to extend.

-- 
John M. Harris, Jr.
Splentity

[Neal Gompa]

On Tue, Jan 21, 2020 at 5:14 PM John M. Harris Jr <johnmh(a)splentity.com&gt; wrote:
>  On Tuesday, January 21, 2020 2:31:47 PM MST Michael Catanzaro wrote:
>  > On Tue, Jan 21, 2020 at 4:04 pm, Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  >
>  > > And any discussion of GitHub isn't going to involve self-hosted, it's
>  > > going to involve GitHub.com, which means we're talking about losing
>  > > more of our independence as a project. This is one of those things
>  > > that I'm not sure is a wise move.
>  >
>  >
>  > Well since we have a request for requirements: I propose requirements
>  > #1 and #2 are to be self-hosted and open source. I'm suspect the Fedora
>  > community would be outraged if we fail to meet either requirement.
>  >
>  > So if we can agree on that much, then we can avoid wasting time by
>  > including GitHub in the list of options. That would bring us to a
>  > choice between GitLab CE and Pagure. (Are there any other serious
>  > options?)
>  >
>  > Michael
>
>  Both Gitea and Gogs are potential options, in my opinion, both are lightweight
>  and easy to extend.
>  
Neither of those two are designed to be extended. There have been
other examples of attempts to do this, which has led to effectively
forking it. NotABug.org runs a fork of gogs for that reason. There are
some instances of Gitea that I'm aware of that had to be forked to be
extended. Forking to extend is not anything close to desirable.



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

[Michael Catanzaro]

On Tue, Jan 21, 2020 at 3:13 pm, John M. Harris Jr 
<johnmh(a)splentity.com&gt; wrote:
>  Both Gitea and Gogs are potential options, in my opinion, both are 
>  lightweight
>  and easy to extend. 
I have some experience with Gogs. I don't recommend it.

[Michal Konecny]

On 21/01/2020 23:13, John M. Harris Jr wrote:
>  On Tuesday, January 21, 2020 2:31:47 PM MST Michael Catanzaro wrote:
> > On Tue, Jan 21, 2020 at 4:04 pm, Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
> >
> >> And any discussion of GitHub isn't going to involve self-hosted, it's
> >> going to involve GitHub.com, which means we're talking about losing
> >> more of our independence as a project. This is one of those things
> >> that I'm not sure is a wise move.
> >
> > Well since we have a request for requirements: I propose requirements
> > #1 and #2 are to be self-hosted and open source. I'm suspect the Fedora
> > community would be outraged if we fail to meet either requirement.
> >
> > So if we can agree on that much, then we can avoid wasting time by
> > including GitHub in the list of options. That would bring us to a
> > choice between GitLab CE and Pagure. (Are there any other serious
> > options?)
> >
> > Michael
>  Both Gitea and Gogs are potential options, in my opinion, both are lightweight
>  and easy to extend.
>  
If we go this way, in a few years we will end up in the same situation 
as with Pagure today. We will have many custom patches (which we need to 
take care of) and we will not have manpower to compete with the features 
of other major git forges.

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

[Michael Watters]

On 1/22/20 1:56 AM, Michal Konecny wrote:
>  If we go this way, in a few years we will end up in the same
> situation
>  as with Pagure today. We will have many custom patches (which we need
>  to take care of) and we will not have manpower to compete with the
>  features of other major git forges. 

Which just begs the question, do you *need* to compete with other git
forges.  Seems like pagure fills a niche that the others don't.

[Neal Gompa]

On Wed, Jan 22, 2020 at 10:22 AM Michael Watters <wattersm(a)watters.ws&gt; wrote:
>  On 1/22/20 1:56 AM, Michal Konecny wrote:
>  > If we go this way, in a few years we will end up in the same situation
>  > as with Pagure today. We will have many custom patches (which we need
>  > to take care of) and we will not have manpower to compete with the
>  > features of other major git forges.
>
>
>  Which just begs the question, do you *need* to compete with other git
>  forges.  Seems like pagure fills a niche that the others don't. 
We don't need to. There are improvements that people would like, and
that does take development effort. That's the piece that requires
manpower to go faster.



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

[Bruno Wolff III]

On Wed, Jan 22, 2020 at 10:28:52 -0500,
  Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
> We don't need to. There are improvements that people would like, and
> that does take development effort. That's the piece that requires
> manpower to go faster. 
In my opinion, I think this is where Red Hat should be helping. Pagure has 
a chance to change what free projects use for software development. Github 
isn't free (though they do some nice things for free software). Gitlab is 
open core, which means they have a conflict of interest when accepting 
improvements from outsiders. They could also stop supporting the open 
core at any time, leaving users who want infrastructure running on free 
software in a poor place.

[John Florian]

On 2020-01-23 11:26, Bruno Wolff III wrote:
>  On Wed, Jan 22, 2020 at 10:28:52 -0500,
>   Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
> >
> > We don't need to. There are improvements that people would like, and
> > that does take development effort. That's the piece that requires
> > manpower to go faster.
>
>  In my opinion, I think this is where Red Hat should be helping. Pagure 
>  has a chance to change what free projects use for software 
>  development. Github isn't free (though they do some nice things for 
>  free software). Gitlab is open core, which means they have a conflict 
>  of interest when accepting improvements from outsiders. They could 
>  also stop supporting the open core at any time, leaving users who want 
>  infrastructure running on free software in a poor place. 

I completely agree with this.  I find it rather bizarre that I came to 
know FOSS almost exclusively because of Red Hat, yet it seems the 
majority of the projects I contribute to are now being hosted on Github, 
a Microsoft-owned company.  I'd be rather incredulous if someone told me 
it was going to be like this back in the 90s.  I've little experience 
with Gitlab, but plenty with Pagure from an internal instance and a few 
projects on pagure.io like Koji.  I love Pagure and all this talk of 
possibly pushing it aside for Fedora makes me sad.  I thought it was the 
way forward and was just getting to an excellent footing.  Pagure might 
not be a money-making product but it sure can help build a community in 
an environment that is void of any potential corporate hostility.

[Peter Oliver]

On Tue, 21 Jan 2020, 21:32 Michael Catanzaro, <mcatanzaro(a)gnome.org&gt; wrote:

So if we can agree on that much, then we can avoid wasting time by
>  including GitHub in the list of options. That would bring us to a
>  choice between GitLab CE and Pagure. (Are there any other serious
>  options?) 

In the blog post they state that there aren't.  Certainly GitHub and GitLab
have the most momentum.

I happen to like Phabricator, and appreciate the developer's opinionated
design approach, but perhaps it's right to pick the most mainstream thing
we can with the goal of not wanting to move again for, say, another decade
or so.

-- 
Peter Oliver

[Pierre-Yves Chibon]

On Wed, Jan 22, 2020 at 08:40:54AM +0000, Peter Oliver wrote:
>     On Tue, 21 Jan 2020, 21:32 Michael Catanzaro,
> <[1]mcatanzaro(a)gnome.org&gt;
>     wrote:
>  
>       So if we can agree on that much, then we can avoid wasting time by
>       including GitHub in the list of options. That would bring us to a
>       choice between GitLab CE and Pagure. (Are there any other serious
>       options?)
>  
>     In the blog post they state that there aren't.  Certainly GitHub and
>     GitLab have the most momentum.
>     I happen to like Phabricator, and appreciate the developer's opinionated
>     design approach, but perhaps it's right to pick the most mainstream thing
>     we can with the goal of not wanting to move again for, say, another decade
>     or so. 
IIRC phabricator does not issue tracking which mean it would not fit the
use-case of FESCo, FPC and other groups that are mostly using pagure as a
ticketing system.


Pierre

[Adam Williamson]

On Wed, 2020-01-22 at 10:01 +0100, Pierre-Yves Chibon wrote:
>  
>  IIRC phabricator does not issue tracking which mean it would not fit the
>  use-case of FESCo, FPC and other groups that are mostly using pagure as a
>  ticketing system. 
Sure it does, we used to use it for this. It calls them 'tasks', but
it's the same paradigm.

https://phacility.com/phabricator/maniphest/
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

[Adam Williamson]

On Wed, 2020-01-22 at 08:40 +0000, Peter Oliver wrote:
>  On Tue, 21 Jan 2020, 21:32 Michael Catanzaro,
> <mcatanzaro(a)gnome.org&gt; wrote:
>  
>  So if we can agree on that much, then we can avoid wasting time by
>  > including GitHub in the list of options. That would bring us to a
>  > choice between GitLab CE and Pagure. (Are there any other serious
>  > options?)
>  
>  In the blog post they state that there aren't.  Certainly GitHub and GitLab
>  have the most momentum.
>  
>  I happen to like Phabricator, and appreciate the developer's opinionated
>  design approach, but perhaps it's right to pick the most mainstream thing
>  we can with the goal of not wanting to move again for, say, another decade
>  or so. 
We used Phabricator for Fedora QA work for a while, before migrating to
Pagure. It had some really nice features, but it was quite a lot of
work to maintain, and the fact that its workflow is not like Github's
and requires some specific tooling would likely be a barrier to
contribution since the Github workflow is such a de facto standard
these days.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

[Clement Verna]

On Tue, 21 Jan 2020 at 22:32, Michael Catanzaro <mcatanzaro(a)gnome.org&gt;
wrote:

>  On Tue, Jan 21, 2020 at 4:04 pm, Neal Gompa
> <ngompa13(a)gmail.com&gt; wrote:
>  > And any discussion of GitHub isn't going to involve self-hosted, it's
>  > going to involve GitHub.com, which means we're talking about losing
>  > more of our independence as a project. This is one of those things
>  > that I'm not sure is a wise move.
>
>  Well since we have a request for requirements: I propose requirements
>  #1 and #2 are to be self-hosted and open source. I'm suspect the Fedora
>  community would be outraged if we fail to meet either requirement.
>
>  So if we can agree on that much, then we can avoid wasting time by
>  including GitHub in the list of options. That would bring us to a
>  choice between GitLab CE and Pagure. (Are there any other serious
>  options?)
>  
Thanks for actually proposing some requirements :-).

In my opinion there are 2 different use cases :

- pagure.io :
For me the requirements here is to provide a place for community members to
host there projects. And project here can mean anything it can be actual
source code, documentation, or just a README with some info about a team or
like many team have just a ticket tracker. Once of the strong requirement
is that whatever the solution is it needs to integrate with Fedora Account
System and user should be able to use Single Sign On. Regarding the use
case where a team wants to have a issue tracker and maybe a README to give
details about how to contribute to that team I think teams.fedoraproject.org
should be the prefered solution, for the second where people want to host a
git project (code, documentation, book, etc ...) I don't think this needs
to be solved by the Fedora community, there are many options (free and non
free, as in freedom) which have dedicated infrastructure and dedicated
teams running this type of service.


- dist-git (src.fedoraproject.org):
This is a different use case, since here the solution needs to integrate
with the rest of the infrastructure. the list of requirements here will be
more specific for example it needs to be able to integrate with Fedora FAS
but also to have the FAS group synced, branch ACLs, a way to integrate with
release-monitoring, a way to integrate with bugzilla, a way to integrate
with fedora-messaging (RabbitMQ), ....
In general I think most of the integration with our infrastructure can be
done with any solution either using the solution APIs or plugins system.
After we need to compare the cost of developing and maintaining these
pieces of glue to integrate everything against the current situation.



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

[Aleksandra Fedorova]

On Wed, Jan 22, 2020 at 9:48 AM Clement Verna <cverna(a)fedoraproject.org&gt; wrote:
>  On Tue, 21 Jan 2020 at 22:32, Michael Catanzaro <mcatanzaro(a)gnome.org&gt; wrote:
> >
> > On Tue, Jan 21, 2020 at 4:04 pm, Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
> > > And any discussion of GitHub isn't going to involve self-hosted, it's
> > > going to involve GitHub.com, which means we're talking about losing
> > > more of our independence as a project. This is one of those things
> > > that I'm not sure is a wise move.
> >
> > Well since we have a request for requirements: I propose requirements
> > #1 and #2 are to be self-hosted and open source. I'm suspect the Fedora
> > community would be outraged if we fail to meet either requirement.
> >
> > So if we can agree on that much, then we can avoid wasting time by
> > including GitHub in the list of options. That would bring us to a
> > choice between GitLab CE and Pagure. (Are there any other serious
> > options?)
>
>
>  Thanks for actually proposing some requirements :-).
>
>  In my opinion there are 2 different use cases :
>
>  - pagure.io :
>  For me the requirements here is to provide a place for community members to host there
> projects. And project here can mean anything it can be actual source code, documentation,
> or just a README with some info about a team or like many team have just a ticket tracker.
> Once of the strong requirement is that whatever the solution is it needs to integrate with
> Fedora Account System and user should be able to use Single Sign On. Regarding the use
> case where a team wants to have a issue tracker and maybe a README to give details about
> how to contribute to that team I think teams.fedoraproject.org should be the prefered
> solution, for the second where people want to host a git project (code, documentation,
> book, etc ...) I don't think this needs to be solved by the Fedora community, there
> are many options (free and non free, as in freedom) which have dedicated infrastructure
> and dedicated teams running this type of service.
>
>
>  - dist-git (src.fedoraproject.org):
>  This is a different use case, since here the solution needs to integrate with the rest of
> the infrastructure. the list of requirements here will be more specific for example it
> needs to be able to integrate with Fedora FAS but also to have the FAS group synced,
> branch ACLs, a way to integrate with release-monitoring, a way to integrate with bugzilla,
> a way to integrate with fedora-messaging (RabbitMQ), ....
>  In general I think most of the integration with our infrastructure can be done with any
> solution either using the solution APIs or plugins system. After we need to compare the
> cost of developing and maintaining these pieces of glue to integrate everything against
> the current situation.
>  
If we go for splitting up use cases, than I'd like to highlight one thing:

    src.fedoraproject.org is not a GitForge, it is a centrally managed
code-review platform

Git Forges play a lot with the idea of users being able to create
their own forks of the repository, their own projects, with their own
rules. src.fp.org is the integrated platform where Fedora rules are in
action. This is different from the use case KDE and Gnome have, as
they manage development of projects, while we manage the integration.

And while GitHub and GitLab are well know leaders in the Git Forge
business, they are actually not that good when it comes to the topics
of 1) managing the large multi-component project in a unified way
under central authority; 2) managing actual code review process.

Code Review platforms, like Gerrit are way better at that.

To see an example, take a look at the management of projects and
groups in Gerrit. Or take a look on integration of CI systems. GitHub
still struggles to make it natural part of the interface.

We _can_ implement centralized code review platform on top of any Git
Forge service. But let's maybe consider using the right tool for the
right job?


The obvious counter-argument here is: most of the users are
uncomfortable with any interface other than GitHub. No matter if the
interface is superior, or lighter, or nicer, there is still going to
be that thing that it is _unusual_.

We, as a Linux distribution, know this argument pretty well. We, as
Fedora Linux distribution, know it even better: you can not bring
something new if you are scared of unusual things. Should it stop us?

We do need a better discoverability and visibility in the generic
development community. But it is a solvable task: we can create a
read-only mirror of our code on every common platform out there. We
can use it as an opportunity to show what we do, but also to teach how
we do it. For example OpenStack has a bot which replies on every
GitHub issue and pull-request to the read-only mirrored repository
with a manual on how one can send the same change through the
OpenStack development process. We would need to do it the same way
anyway, if we land on anything other than GitHub.

-- 
Aleksandra Fedorova
bookwar

[Neal Gompa]

On Wed, Jan 22, 2020 at 6:06 AM Aleksandra Fedorova <alpha(a)bookwar.info&gt; wrote:
>  On Wed, Jan 22, 2020 at 9:48 AM Clement Verna <cverna(a)fedoraproject.org&gt; wrote:
>  >
>  >
>  >
>  > On Tue, 21 Jan 2020 at 22:32, Michael Catanzaro <mcatanzaro(a)gnome.org&gt; wrote:
>  >>
>  >> On Tue, Jan 21, 2020 at 4:04 pm, Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  >> > And any discussion of GitHub isn't going to involve self-hosted,
> it's
>  >> > going to involve GitHub.com, which means we're talking about losing
>  >> > more of our independence as a project. This is one of those things
>  >> > that I'm not sure is a wise move.
>  >>
>  >> Well since we have a request for requirements: I propose requirements
>  >> #1 and #2 are to be self-hosted and open source. I'm suspect the Fedora
>  >> community would be outraged if we fail to meet either requirement.
>  >>
>  >> So if we can agree on that much, then we can avoid wasting time by
>  >> including GitHub in the list of options. That would bring us to a
>  >> choice between GitLab CE and Pagure. (Are there any other serious
>  >> options?)
>  >
>  >
>  > Thanks for actually proposing some requirements :-).
>  >
>  > In my opinion there are 2 different use cases :
>  >
>  > - pagure.io :
>  > For me the requirements here is to provide a place for community members to host
> there projects. And project here can mean anything it can be actual source code,
> documentation, or just a README with some info about a team or like many team have just a
> ticket tracker. Once of the strong requirement is that whatever the solution is it needs
> to integrate with Fedora Account System and user should be able to use Single Sign On.
> Regarding the use case where a team wants to have a issue tracker and maybe a README to
> give details about how to contribute to that team I think teams.fedoraproject.org should
> be the prefered solution, for the second where people want to host a git project (code,
> documentation, book, etc ...) I don't think this needs to be solved by the Fedora
> community, there are many options (free and non free, as in freedom) which have dedicated
> infrastructure and dedicated teams running this type of service.
>  >
>  >
>  > - dist-git (src.fedoraproject.org):
>  > This is a different use case, since here the solution needs to integrate with the
> rest of the infrastructure. the list of requirements here will be more specific for
> example it needs to be able to integrate with Fedora FAS but also to have the FAS group
> synced, branch ACLs, a way to integrate with release-monitoring, a way to integrate with
> bugzilla, a way to integrate with fedora-messaging (RabbitMQ), ....
>  > In general I think most of the integration with our infrastructure can be done with
> any solution either using the solution APIs or plugins system. After we need to compare
> the cost of developing and maintaining these pieces of glue to integrate everything
> against the current situation.
>  >
>
>  If we go for splitting up use cases, than I'd like to highlight one thing:
>
>      src.fedoraproject.org is not a GitForge, it is a centrally managed
>  code-review platform
>
>  Git Forges play a lot with the idea of users being able to create
>  their own forks of the repository, their own projects, with their own
>  rules. src.fp.org is the integrated platform where Fedora rules are in
>  action. This is different from the use case KDE and Gnome have, as
>  they manage development of projects, while we manage the integration.
>
>  And while GitHub and GitLab are well know leaders in the Git Forge
>  business, they are actually not that good when it comes to the topics
>  of 1) managing the large multi-component project in a unified way
>  under central authority; 2) managing actual code review process.
>
>  Code Review platforms, like Gerrit are way better at that.
>
>  To see an example, take a look at the management of projects and
>  groups in Gerrit. Or take a look on integration of CI systems. GitHub
>  still struggles to make it natural part of the interface.
>
>  We _can_ implement centralized code review platform on top of any Git
>  Forge service. But let's maybe consider using the right tool for the
>  right job?
>
>
>  The obvious counter-argument here is: most of the users are
>  uncomfortable with any interface other than GitHub. No matter if the
>  interface is superior, or lighter, or nicer, there is still going to
>  be that thing that it is _unusual_.
>
>  We, as a Linux distribution, know this argument pretty well. We, as
>  Fedora Linux distribution, know it even better: you can not bring
>  something new if you are scared of unusual things. Should it stop us?
>
>  We do need a better discoverability and visibility in the generic
>  development community. But it is a solvable task: we can create a
>  read-only mirror of our code on every common platform out there. We
>  can use it as an opportunity to show what we do, but also to teach how
>  we do it. For example OpenStack has a bot which replies on every
>  GitHub issue and pull-request to the read-only mirrored repository
>  with a manual on how one can send the same change through the
>  OpenStack development process. We would need to do it the same way
>  anyway, if we land on anything other than GitHub. 
I'm sorry, no. I absolutely despise the Gerrit workflow that OpenStack
uses. To me, the only thing worse than Gerrit is the email/bz patch
submission workflow we used prior to Pagure. Gerrit would be a step up
from that legacy workflow, but it pushes too much crap onto the
contributor that it's a great way to demotivate people.

Having contributed to projects using Gerrit, and previously dealt with
Gerrit based workflows, I can honestly say that Gerrit is absolutely a
miserable experience and the OpenStack project should feel bad about
the fact that they think Gerrit provides a good user experience.
What's worse is that the stupid bot that they use on GitHub mirrors is
completely unfriendly to drive-by contributors. The OpenStack Project
is an example of how to make it fundamentally driven by corporate
developers who force asinine workflows because they can't be bothered
to make a proper community full of a mixture of hobbyists and
corporate contributors. And don't get me started on the fact that
there are no distributions of OpenStack on community Linux
distributions anymore, which I further indicate as evidence that the
OpenStack community is too insular for its own good. RDO does not
count since it doesn't work on *real* community distributions like
Fedora.

(Sorry, but OpenStack makes me angry for a variety of reasons, and in
my view, it's a failure as a community)

At least with Pagure, we have a bloody chance of being able to do
something interesting like synchronize PR states across different
mirrors of Fedora packages.

An idea I've had for the Pagure project itself would be to monitor
when PRs are made on the GitHub.com and GitLab.com mirrors and
automatically open up remote PRs pointing to the canonical Pagure repo
and synchronize review information from Pagure to GitHub/GitLab and
back. This is possible because Pagure is so flexible with how pull
requests work, and because I don't particularly care if a PR shows up
as "merged" on the GitHub.com/GitLab.com side. :)

The main reason I haven't pursued it is because CentOS CI is so
unreliable and awful. It's demoralizing getting failures and then
looking at Jenkins and seeing there are no logs of the failure. Or the
increasing number of "error" states where it just breaks...


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

[Miro Hrončok]

On 22. 01. 20 12:19, Neal Gompa wrote:>> We do need a better discoverability and 
visibility in the generic
> > development community. But it is a solvable task: we can create
> a
> > read-only mirror of our code on every common platform out there. We
> > can use it as an opportunity to show what we do, but also to teach how
> > we do it. For example OpenStack has a bot which replies on every
> > GitHub issue and pull-request to the read-only mirrored repository
> > with a manual on how one can send the same change through the
> > OpenStack development process. We would need to do it the same way
> > anyway, if we land on anything other than GitHub.
>  
>  I'm sorry, no. I absolutely despise the Gerrit workflow that OpenStack
>  uses. To me, the only thing worse than Gerrit is the email/bz patch
>  submission workflow we used prior to Pagure. Gerrit would be a step up
>  from that legacy workflow, but it pushes too much crap onto the
>  contributor that it's a great way to demotivate people.
>  
>  Having contributed to projects using Gerrit, and previously dealt with
>  Gerrit based workflows, I can honestly say that Gerrit is absolutely a
>  miserable experience and the OpenStack project should feel bad about
>  the fact that they think Gerrit provides a good user experience.
>  What's worse is that the stupid bot that they use on GitHub mirrors is
>  completely unfriendly to drive-by contributors. The OpenStack Project
>  is an example of how to make it fundamentally driven by corporate
>  developers who force asinine workflows because they can't be bothered
>  to make a proper community full of a mixture of hobbyists and
>  corporate contributors. And don't get me started on the fact that
>  there are no distributions of OpenStack on community Linux
>  distributions anymore, which I further indicate as evidence that the
>  OpenStack community is too insular for its own good. RDO does not
>  count since it doesn't work on *real* community distributions like
>  Fedora. 
While I don't necessarily agree with the tone, I must agree the the Gerrit 
experience for drive by contributors is one of the most horrible ones I had.

I even think sending patches over e-mail is probably better.


>  The main reason I haven't pursued it is because CentOS CI is so
>  unreliable and awful. It's demoralizing getting failures and then
>  looking at Jenkins and seeing there are no logs of the failure. Or the
>  increasing number of "error" states where it just breaks... 
This has been reported a year ago, without a fix so far:

During running tests, it's very hard to see what's happening
https://pagure.io/fedora-ci/general/issue/2

CI errors are undecipherable
https://pagure.io/fedora-ci/general/issue/43

CI errors happen far to often
https://pagure.io/fedora-ci/general/issue/44


I've been trying to make those issues a priority when we adapted gating, but I 
was outvoted at FESCo.

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

[Clement Verna]

On Wed, 22 Jan 2020 at 12:38, Miro Hrončok <mhroncok(a)redhat.com&gt; wrote:

>  On 22. 01. 20 12:19, Neal Gompa wrote:>> We do need a better
>  discoverability and
>  visibility in the generic
>  >> development community. But it is a solvable task: we can create a
>  >> read-only mirror of our code on every common platform out there. We
>  >> can use it as an opportunity to show what we do, but also to teach how
>  >> we do it. For example OpenStack has a bot which replies on every
>  >> GitHub issue and pull-request to the read-only mirrored repository
>  >> with a manual on how one can send the same change through the
>  >> OpenStack development process. We would need to do it the same way
>  >> anyway, if we land on anything other than GitHub.
>  >
>  > I'm sorry, no. I absolutely despise the Gerrit workflow that OpenStack
>  > uses. To me, the only thing worse than Gerrit is the email/bz patch
>  > submission workflow we used prior to Pagure. Gerrit would be a step up
>  > from that legacy workflow, but it pushes too much crap onto the
>  > contributor that it's a great way to demotivate people.
>  >
>  > Having contributed to projects using Gerrit, and previously dealt with
>  > Gerrit based workflows, I can honestly say that Gerrit is absolutely a
>  > miserable experience and the OpenStack project should feel bad about
>  > the fact that they think Gerrit provides a good user experience.
>  > What's worse is that the stupid bot that they use on GitHub mirrors is
>  > completely unfriendly to drive-by contributors. The OpenStack Project
>  > is an example of how to make it fundamentally driven by corporate
>  > developers who force asinine workflows because they can't be bothered
>  > to make a proper community full of a mixture of hobbyists and
>  > corporate contributors. And don't get me started on the fact that
>  > there are no distributions of OpenStack on community Linux
>  > distributions anymore, which I further indicate as evidence that the
>  > OpenStack community is too insular for its own good. RDO does not
>  > count since it doesn't work on *real* community distributions like
>  > Fedora.
>
>  While I don't necessarily agree with the tone, 

+1 I appreciate that people are passionate about this topic, but let's stay
respectful of other people work and opinion.


>  I must agree the the Gerrit
>  experience for drive by contributors is one of the most horrible ones I
>  had.
>
>  I even think sending patches over e-mail is probably better.
>
>
>  > The main reason I haven't pursued it is because CentOS CI is so
>  > unreliable and awful. It's demoralizing getting failures and then
>  > looking at Jenkins and seeing there are no logs of the failure. Or the
>  > increasing number of "error" states where it just breaks...
>
>  This has been reported a year ago, without a fix so far:
>
>  During running tests, it's very hard to see what's happening
>  https://pagure.io/fedora-ci/general/issue/2
>
>  CI errors are undecipherable
>  https://pagure.io/fedora-ci/general/issue/43
>
>  CI errors happen far to often
>  https://pagure.io/fedora-ci/general/issue/44
>
>
>  I've been trying to make those issues a priority when we adapted gating,
>  but I
>  was outvoted at FESCo.
>
>  --
>  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]
>

[Aleksandra Fedorova]

On Wed, Jan 22, 2020 at 12:38 PM Miro Hrončok <mhroncok(a)redhat.com&gt; wrote:
>  On 22. 01. 20 12:19, Neal Gompa wrote:>> We do need a better discoverability and
>  visibility in the generic
>  >> development community. But it is a solvable task: we can create a
>  >> read-only mirror of our code on every common platform out there. We
>  >> can use it as an opportunity to show what we do, but also to teach how
>  >> we do it. For example OpenStack has a bot which replies on every
>  >> GitHub issue and pull-request to the read-only mirrored repository
>  >> with a manual on how one can send the same change through the
>  >> OpenStack development process. We would need to do it the same way
>  >> anyway, if we land on anything other than GitHub.
>  >
>  > I'm sorry, no. I absolutely despise the Gerrit workflow that OpenStack
>  > uses. To me, the only thing worse than Gerrit is the email/bz patch
>  > submission workflow we used prior to Pagure. Gerrit would be a step up
>  > from that legacy workflow, but it pushes too much crap onto the
>  > contributor that it's a great way to demotivate people.
>  >
>  > Having contributed to projects using Gerrit, and previously dealt with
>  > Gerrit based workflows, I can honestly say that Gerrit is absolutely a
>  > miserable experience and the OpenStack project should feel bad about
>  > the fact that they think Gerrit provides a good user experience.
>  > What's worse is that the stupid bot that they use on GitHub mirrors is
>  > completely unfriendly to drive-by contributors. The OpenStack Project
>  > is an example of how to make it fundamentally driven by corporate
>  > developers who force asinine workflows because they can't be bothered
>  > to make a proper community full of a mixture of hobbyists and
>  > corporate contributors. And don't get me started on the fact that
>  > there are no distributions of OpenStack on community Linux
>  > distributions anymore, which I further indicate as evidence that the
>  > OpenStack community is too insular for its own good. RDO does not
>  > count since it doesn't work on *real* community distributions like
>  > Fedora.
>
>  While I don't necessarily agree with the tone, I must agree the the Gerrit
>  experience for drive by contributors is one of the most horrible ones I had. 
Ok, I knew I would trigger a lot of wrong conversation if I mention it
out in the open.

So let me just reiterate the main points:

1) src.fedoraproject.org is not a Git Forge

Implementation of src.fp.org via GitForge is the option which we used
through Pagure, but there are other possibilities.

@jlanda just posted an awesome summary on the features, some of them
support my point.

Proven packages for example is not a Git Forge concept.

Or the question of the ownership of the Pull request: in Git Forge
pull-request are defined by the branch in someone's personal forked
repository. And no one else has access to manage it.
In Code Review system (yes, like Gerrit) change requests belong to the
project repository. Anyone is able to work on anyone else's pull
request, for example rebase it, or take over the work if the original
owner doesn't want to continue by some reason.

2) Being afraid of everything which is not GitHub is not a good reason
to choose GitHub.

It is a reason to look into how to make some integrations and ways out
from GitHub possible for the end user.
Things like mirroring, like allowing GitHub accounts in the Single
Sign On system for sending patches and so on can help with that.

3) No matter what we choose, it would anger someone, and makes
someone's life harder.

I would prefer if we choose tools by alignment of the purpose, the
problem which those tools are trying to solve, rather then by the
"niceness". Because if we have a same purpose - we have a way to
improve the "niceness", sometimes by just waiting, sometimes by
contributing...

But if we have different purposes in mind, then we are not going to
get any improvements, because "we are not the target audience" and our
features are always going to be out of priority and out of scope.

>  I even think sending patches over e-mail is probably better. 
I think that it would be more productive if you try to rationalize this opinion.
I don't want to argue about the feeling you have, but I would be
interested in comparing notes on what exactly "Gerrit workflow" means
to you, and whether or not it is the same thing to me.

>  > The main reason I haven't pursued it is because CentOS CI is
> so
>  > unreliable and awful. It's demoralizing getting failures and then
>  > looking at Jenkins and seeing there are no logs of the failure. Or the
>  > increasing number of "error" states where it just breaks...
>
>  This has been reported a year ago, without a fix so far:
>
>  During running tests, it's very hard to see what's happening
>  https://pagure.io/fedora-ci/general/issue/2
>
>  CI errors are undecipherable
>  https://pagure.io/fedora-ci/general/issue/43
>
>  CI errors happen far to often
>  https://pagure.io/fedora-ci/general/issue/44
>
>
>  I've been trying to make those issues a priority when we adapted gating, but I
>  was outvoted at FESCo.
>
>  --
>  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] 
-- 
Aleksandra Fedorova
bookwar

[Miro Hrončok]

On 22. 01. 20 13:12, Aleksandra Fedorova wrote:
>  I think that it would be more productive if you try to rationalize
> this opinion.
>  I don't want to argue about the feeling you have, but I would be
>  interested in comparing notes on what exactly "Gerrit workflow" means
>  to you, and whether or not it is the same thing to me. 
Note that I don't describe an experience with a workflow. I am describing a 
drive by contributor experience:

1. you send a Pull Request over a familiar channel
2. a bot tells you that you cannot do this and you need to follow this tutorial 
instead
3. you push your code to some place that is far to overocmplicated to navigate
4. magic happens, there is no way to see what's going on unless you have 
experienced this before
5. you get dozens of bot e-mail you don't understand
6. eventually hopefully the bot merges the thing

I realize that (4) might be true about "anything new". What I am trying to say 
is that e-mail is a familiar channel. GitHub / GitLab / Pagure etc. almost looks 
like a bulletin board or a more code-oriented Facebook comments. However gerrit 
is like a nuclear power plant control center -> you are afraid to touch 
anything. You need a tutorial to handle it. It's not beginners friendly and it 
enhances a cargo cult behavior.

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

[Florian Weimer]

* Miro Hrončok:

>  On 22. 01. 20 13:12, Aleksandra Fedorova wrote:
> > I think that it would be more productive if you try to rationalize this opinion.
> > I don't want to argue about the feeling you have, but I would be
> > interested in comparing notes on what exactly "Gerrit workflow" means
> > to you, and whether or not it is the same thing to me.
>
>  Note that I don't describe an experience with a workflow. I am
>  describing a drive by contributor experience:
>
>  1. you send a Pull Request over a familiar channel
>  2. a bot tells you that you cannot do this and you need to follow this
>  tutorial instead
>  3. you push your code to some place that is far to overocmplicated to navigate
>  4. magic happens, there is no way to see what's going on unless you
>  have experienced this before
>  5. you get dozens of bot e-mail you don't understand
>  6. eventually hopefully the bot merges the thing 
Does that really matter for src.fedoraproject.org and the current
dist-git model?

Even if you want to make a really simple change (such as fixing a typo
in the --help message), src.fedoraproject.org will not show you the file
you need to edit, or provide you with tools to produce a patch/commit to
submit.

The Github model is different: you would just click on the 🖉 button,
make your change, add a description, and click “Propose file change”.
But even if we switched src.fedoraproject.org to Github, this would only
work for RPM spec file changes.  You would still not be able to edit the
--help message directly.  That's why I think that there is little risk
of random drive-by contributions: people just won't find a place to make
the changes they want.  (The potential FPCA issue I raised separately
still exists, though.)

Thanks,
Florian

[Martin Kolman]

On Wed, 2020-01-22 at 13:51 +0100, Florian Weimer wrote:
>  * Miro Hrončok:
>  
>  > On 22. 01. 20 13:12, Aleksandra Fedorova wrote:
>  > > I think that it would be more productive if you try to rationalize this
> opinion.
>  > > I don't want to argue about the feeling you have, but I would be
>  > > interested in comparing notes on what exactly "Gerrit workflow"
> means
>  > > to you, and whether or not it is the same thing to me.
>  > 
>  > Note that I don't describe an experience with a workflow. I am
>  > describing a drive by contributor experience:
>  > 
>  > 1. you send a Pull Request over a familiar channel
>  > 2. a bot tells you that you cannot do this and you need to follow this
>  > tutorial instead
>  > 3. you push your code to some place that is far to overocmplicated to navigate
>  > 4. magic happens, there is no way to see what's going on unless you
>  > have experienced this before
>  > 5. you get dozens of bot e-mail you don't understand
>  > 6. eventually hopefully the bot merges the thing
>  
>  Does that really matter for src.fedoraproject.org and the current
>  dist-git model?
>  
>  Even if you want to make a really simple change (such as fixing a typo
>  in the --help message), src.fedoraproject.org will not show you the file
>  you need to edit, or provide you with tools to produce a patch/commit to
>  submit.
>  
>  The Github model is different: you would just click on the 🖉 button,
>  make your change, add a description, and click “Propose file change”.
>  But even if we switched src.fedoraproject.org to Github, this would only
>  work for RPM spec file changes.  You would still not be able to edit the
>  --help message directly. 
Weren't there some suggestions to use upackaged source
code/git subtree instead of the tarball
we have now ? 

Then the upstream source code would be there and you could fix the --help message
directly
in Fedora distgit. The result would be a fixed Fedora package & ideally also the same
change automatically
submitted to upstream for review.

>    That's why I think that there is little risk
>  of random drive-by contributions: people just won't find a place to make
>  the changes they want.  (The potential FPCA issue I raised separately
>  still exists, though.)
>  
>  Thanks,
>  Florian
>  _______________________________________________
>  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]

[Aleksandra Fedorova]

On Wed, Jan 22, 2020 at 1:25 PM Miro Hrončok <mhroncok(a)redhat.com&gt; wrote:
>  On 22. 01. 20 13:12, Aleksandra Fedorova wrote:
>  > I think that it would be more productive if you try to rationalize this opinion.
>  > I don't want to argue about the feeling you have, but I would be
>  > interested in comparing notes on what exactly "Gerrit workflow" means
>  > to you, and whether or not it is the same thing to me.
>
>  Note that I don't describe an experience with a workflow. I am describing a
>  drive by contributor experience:
>
>  1. you send a Pull Request over a familiar channel
>  2. a bot tells you that you cannot do this and you need to follow this tutorial
>  instead
>  3. you push your code to some place that is far to overocmplicated to navigate
>  4. magic happens, there is no way to see what's going on unless you have
>  experienced this before
>  5. you get dozens of bot e-mail you don't understand
>  6. eventually hopefully the bot merges the thing
>
>  I realize that (4) might be true about "anything new". What I am trying to say
>  is that e-mail is a familiar channel. GitHub / GitLab / Pagure etc. almost looks
>  like a bulletin board or a more code-oriented Facebook comments. However gerrit
>  is like a nuclear power plant control center -> you are afraid to touch
>  anything. You need a tutorial to handle it. It's not beginners friendly and it
>  enhances a cargo cult behavior. 
OK, I can understand that.


Though when people talk about simplicity of the GitHub interface, I
usually tend to point at this page:
   https://github.com/kubernetes/kubernetes/pulls and the k8s-bot actions there
If this page doesn't look overwhelming for you, I don't know what does :)


I admit, being a gerrit user for couple of years I actually miss the
"nuclear plant" interface, where you can get a full state of a change
request in one glance, rather then by browsing through several
"Facebook-like" tabs and pages to see the full picture: comments, ci
results, files changed, people who need to review the task, their
comments,..

And we haven't even started about the CLI interface (git review) it
has, which none of GitLab/GitHub things can compete with.

So you argument for me sounds like Gerrit is too powerful and too
good. Which is a valid argument, actually. We don't want newcomer to
go the full speed with it from a day one.

The question here is:

can we have the power, scalability and feature-richness of a platform
like Gerrit, but (optionally) hidden under the hood so that there is a
"simple mode" for people who just need a one-time contribution?

I've just checked, there is a GitHub plugin [1] for Gerrit which
manages the integration. Could it be the option?

[1] https://gerrit.googlesource.com/plugins/github/

--
Aleksandra Fedorova
bookwar

[Miro Hrončok]

On 22. 01. 20 14:03, Aleksandra Fedorova wrote:
>  can we have the power, scalability and feature-richness of a
> platform
>  like Gerrit, but (optionally) hidden under the hood so that there is a
>  "simple mode" for people who just need a one-time contribution? 
I won't go there, becasue I don't think we need the power, scalability and 
feature-richness of a platform like gerrit in the first place.

1. Not for dist git
2. Not for ticketing projects on pagure.io
3. Code projects on pagure.io can choose a platform that fits their needs

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

[Aleksandra Fedorova]

On Wed, Jan 22, 2020 at 2:21 PM Miro Hrončok <mhroncok(a)redhat.com&gt; wrote:
>  On 22. 01. 20 14:03, Aleksandra Fedorova wrote:
>  > can we have the power, scalability and feature-richness of a platform
>  > like Gerrit, but (optionally) hidden under the hood so that there is a
>  > "simple mode" for people who just need a one-time contribution?
>
>  I won't go there, becasue I don't think we need the power, scalability and
>  feature-richness of a platform like gerrit in the first place.
>
>  1. Not for dist git 
This is where we disagree heavily I guess.

We do need scalability, especially if we consider moving from source
tarballs to unpacked sources at some point. And I hope we do (which is
a yet another discussion we need to have).

In my previous life we hosted Gerrit server for the entire custom
Linux distribution (syncing all OpenStack commits in "real-time") on a
VM with 2Gb of RAM, which never had an issue.

We do need feature richness in terms of central management of the
repositories in src.fp.org: default policies, groups, users,
permissions, CI labels, branching,..
We do need integration, which Gerrit provides through the stream of
events. And we already have CI system (Zuul engine) which can
integrate nicely with it.
We do need features like topics, where pull-requests to different
projects are linked together as an implementation of one larger
cross-project feature. This is something Git Forges don't have as an
object at all, as they treat individual projects as isolated custom
playgrounds, each with a separate workflow.

If we don't get these features from a platform, we are going to
implement it on our own, through bots and external services. Which
will not make the contributor life easier. See the k8s link above:
when integrations are done by bots rather than by internal platform
features, they are not going to look nice or easy.

>  2. Not for ticketing projects on pagure.io
>  3. Code projects on pagure.io can choose a platform that fits their needs 
Pagure.io story is different.

-- 
Aleksandra Fedorova
bookwar

[Ankur Sinha]

Hello,

Thanks for the thread. Lots of good stuff there. Would it be also OK to
add a non technical requirement into the mix:

- whatever we do choose, we stick to it for N years.

I add this because an important reason for moving away from Pagure seems
to be that we don't have the man-power to keep developing/maintaining
it, and yet, moving core pieces of community infra to new platforms
makes it even harder to:

- keep existing contributors (who have to migrate their work and learn
  the new workflow around the new platform, even if it is similar to the
  previous one),

- gain new ones (because it takes time to move our processes and update
  community knowledge which new contributors need).

So, such changes, while positive and necessary for us to improve, must
also not be frequent enough to disrupt us.

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

[Florian Weimer]

* Aleksandra Fedorova:

> > I even think sending patches over e-mail is probably better.
>
>  I think that it would be more productive if you try to rationalize
>  this opinion. 
Gerrit makes it really hard to figure out your open tasks.  You can see
a list of the reviews you have “started” (unfortunate terminology
IMHO—starting a review means submitting it for others to review, not
starting to review it).  But at the individual review level, it is
really hard to figure out what your next steps are and if you have
addressed all reviewer comments (especially after rebasing).

With email, you can view the entire review thread in your client and tag
messages with action items as needed, and then get back to them for the
next version of the patch.

When we looked at Gerrit for glibc, our conclusion was that it would
need lots of customization.  That's okay if you derive benefit from
actually running the tool (as in, you like to provide this kind of
service personally or you can grow your team as a result), but it's much
more difficult to justify if you are just looking at it as a tool to
support what you are really interested in.

Thanks,
Florian

[Aleksandra Fedorova]

On Wed, Jan 22, 2020 at 12:20 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  On Wed, Jan 22, 2020 at 6:06 AM Aleksandra Fedorova <alpha(a)bookwar.info&gt; wrote:
>  >
>  > On Wed, Jan 22, 2020 at 9:48 AM Clement Verna <cverna(a)fedoraproject.org&gt;
> wrote:
>  > >
>  > >
>  > >
>  > > On Tue, 21 Jan 2020 at 22:32, Michael Catanzaro <mcatanzaro(a)gnome.org&gt;
> wrote:
>  > >>
>  > >> On Tue, Jan 21, 2020 at 4:04 pm, Neal Gompa <ngompa13(a)gmail.com&gt;
> wrote:
>  > >> > And any discussion of GitHub isn't going to involve self-hosted,
> it's
>  > >> > going to involve GitHub.com, which means we're talking about
> losing
>  > >> > more of our independence as a project. This is one of those things
>  > >> > that I'm not sure is a wise move.
>  > >>
>  > >> Well since we have a request for requirements: I propose requirements
>  > >> #1 and #2 are to be self-hosted and open source. I'm suspect the
> Fedora
>  > >> community would be outraged if we fail to meet either requirement.
>  > >>
>  > >> So if we can agree on that much, then we can avoid wasting time by
>  > >> including GitHub in the list of options. That would bring us to a
>  > >> choice between GitLab CE and Pagure. (Are there any other serious
>  > >> options?)
>  > >
>  > >
>  > > Thanks for actually proposing some requirements :-).
>  > >
>  > > In my opinion there are 2 different use cases :
>  > >
>  > > - pagure.io :
>  > > For me the requirements here is to provide a place for community members to
> host there projects. And project here can mean anything it can be actual source code,
> documentation, or just a README with some info about a team or like many team have just a
> ticket tracker. Once of the strong requirement is that whatever the solution is it needs
> to integrate with Fedora Account System and user should be able to use Single Sign On.
> Regarding the use case where a team wants to have a issue tracker and maybe a README to
> give details about how to contribute to that team I think teams.fedoraproject.org should
> be the prefered solution, for the second where people want to host a git project (code,
> documentation, book, etc ...) I don't think this needs to be solved by the Fedora
> community, there are many options (free and non free, as in freedom) which have dedicated
> infrastructure and dedicated teams running this type of service.
>  > >
>  > >
>  > > - dist-git (src.fedoraproject.org):
>  > > This is a different use case, since here the solution needs to integrate with
> the rest of the infrastructure. the list of requirements here will be more specific for
> example it needs to be able to integrate with Fedora FAS but also to have the FAS group
> synced, branch ACLs, a way to integrate with release-monitoring, a way to integrate with
> bugzilla, a way to integrate with fedora-messaging (RabbitMQ), ....
>  > > In general I think most of the integration with our infrastructure can be done
> with any solution either using the solution APIs or plugins system. After we need to
> compare the cost of developing and maintaining these pieces of glue to integrate
> everything against the current situation.
>  > >
>  >
>  > If we go for splitting up use cases, than I'd like to highlight one thing:
>  >
>  >     src.fedoraproject.org is not a GitForge, it is a centrally managed
>  > code-review platform
>  >
>  > Git Forges play a lot with the idea of users being able to create
>  > their own forks of the repository, their own projects, with their own
>  > rules. src.fp.org is the integrated platform where Fedora rules are in
>  > action. This is different from the use case KDE and Gnome have, as
>  > they manage development of projects, while we manage the integration.
>  >
>  > And while GitHub and GitLab are well know leaders in the Git Forge
>  > business, they are actually not that good when it comes to the topics
>  > of 1) managing the large multi-component project in a unified way
>  > under central authority; 2) managing actual code review process.
>  >
>  > Code Review platforms, like Gerrit are way better at that.
>  >
>  > To see an example, take a look at the management of projects and
>  > groups in Gerrit. Or take a look on integration of CI systems. GitHub
>  > still struggles to make it natural part of the interface.
>  >
>  > We _can_ implement centralized code review platform on top of any Git
>  > Forge service. But let's maybe consider using the right tool for the
>  > right job?
>  >
>  >
>  > The obvious counter-argument here is: most of the users are
>  > uncomfortable with any interface other than GitHub. No matter if the
>  > interface is superior, or lighter, or nicer, there is still going to
>  > be that thing that it is _unusual_.
>  >
>  > We, as a Linux distribution, know this argument pretty well. We, as
>  > Fedora Linux distribution, know it even better: you can not bring
>  > something new if you are scared of unusual things. Should it stop us?
>  >
>  > We do need a better discoverability and visibility in the generic
>  > development community. But it is a solvable task: we can create a
>  > read-only mirror of our code on every common platform out there. We
>  > can use it as an opportunity to show what we do, but also to teach how
>  > we do it. For example OpenStack has a bot which replies on every
>  > GitHub issue and pull-request to the read-only mirrored repository
>  > with a manual on how one can send the same change through the
>  > OpenStack development process. We would need to do it the same way
>  > anyway, if we land on anything other than GitHub.
>
>  I'm sorry, no. I absolutely despise the Gerrit workflow that OpenStack
>  uses. To me, the only thing worse than Gerrit is the email/bz patch
>  submission workflow we used prior to Pagure. Gerrit would be a step up
>  from that legacy workflow, but it pushes too much crap onto the
>  contributor that it's a great way to demotivate people.
>
>  Having contributed to projects using Gerrit, and previously dealt with
>  Gerrit based workflows, I can honestly say that Gerrit is absolutely a
>  miserable experience and the OpenStack project should feel bad about
>  the fact that they think Gerrit provides a good user experience.
>  What's worse is that the stupid bot that they use on GitHub mirrors is
>  completely unfriendly to drive-by contributors. The OpenStack Project
>  is an example of how to make it fundamentally driven by corporate
>  developers who force asinine workflows because they can't be bothered
>  to make a proper community full of a mixture of hobbyists and
>  corporate contributors. And don't get me started on the fact that
>  there are no distributions of OpenStack on community Linux
>  distributions anymore, which I further indicate as evidence that the
>  OpenStack community is too insular for its own good. RDO does not
>  count since it doesn't work on *real* community distributions like
>  Fedora.
>
>  (Sorry, but OpenStack makes me angry for a variety of reasons, and in
>  my view, it's a failure as a community) 
Sorry but I don't see any actual argument in this text other than that
you personally don't like OpenStack. And this doesn't really
contribute to the discussion.

>  At least with Pagure, we have a bloody chance of being able to do
>  something interesting like synchronize PR states across different
>  mirrors of Fedora packages.
>
>  An idea I've had for the Pagure project itself would be to monitor
>  when PRs are made on the GitHub.com and GitLab.com mirrors and
>  automatically open up remote PRs pointing to the canonical Pagure repo
>  and synchronize review information from Pagure to GitHub/GitLab and
>  back. This is possible because Pagure is so flexible with how pull
>  requests work, and because I don't particularly care if a PR shows up
>  as "merged" on the GitHub.com/GitLab.com side. :) 
I don't see how Pagure is special in this regard. Synchronizing
between two different APIs via external service is always possible.
Though complexity of this solution makes benefits questionable.

>  The main reason I haven't pursued it is because CentOS CI is so
>  unreliable and awful. It's demoralizing getting failures and then
>  looking at Jenkins and seeing there are no logs of the failure. Or the
>  increasing number of "error" states where it just breaks... 
Jenkins is not really a right tool for implementing such a service.
There should be a microservice-like stateless thing, which you can
deploy to Commushift for example.

--
Aleksandra Fedorova
bookwar

[Florian Weimer]

* Aleksandra Fedorova:

>  If we go for splitting up use cases, than I'd like to highlight
> one thing:
>
>      src.fedoraproject.org is not a GitForge, it is a centrally managed
>  code-review platform
>
>  Git Forges play a lot with the idea of users being able to create
>  their own forks of the repository, their own projects, with their own
>  rules. src.fp.org is the integrated platform where Fedora rules are in
>  action. This is different from the use case KDE and Gnome have, as
>  they manage development of projects, while we manage the integration. 
Like the other services, src.fedoraproject.org has no built-in knowledge
of the git-on-git model we currently use for most packages, so I think
as far as Fedora usage is concerned, those differences are pretty
minor.

Thanks,
Florian

[Guido Aulisi]

>  Il giorno 21 gen 2020, alle ore 18:15, Fabio Valentini
> <decathorpe(a)gmail.com&gt; ha scritto:
>  
>  On Tue, Jan 21, 2020 at 5:40 PM Leigh Griffin <lgriffin(a)redhat.com
> <mailto:[e-mail]>> wrote:
> > 
> > Hey Everyone,
> > 
> > On behalf of the CPE team I want to draw the communities attention to a recent blog
> post which you may be impacted by:
> > https://communityblog.fedoraproject.org/git-forge-requirements/
> <https://communityblog.fedoraproject.org/git-forge-requirements/>
> > 
> > We will be seeking input and requirements in an open and transparent manner on the
> future of a git forge solution which will be run by the CPE team on behalf of the Fedora
> Community. This mail is being sent to the devel, mindshare and council-discuss lists for
> maximum visibility on a BCC to allow each list have their own views. Please forward it to
> any other list you may feel is relevant to maximise the exposure.
> > 
> > Thanks in advance,
> > Leigh
>  
>  Alright, I have some questions that are not answered by the blog post.
>  
>  - What is going to happen to the two pagure instances at pagure.io
> <http://pagure.io/>;,
>  and src.fedoraproject.org <http://src.fedoraproject.org/>?
>  
>  I think pagure.io <http://pagure.io/> is a good home for fedora-related projects
> (it was
>  the successor to fedorahosted.org <http://fedorahosted.org/>;, after all, IIRC). I
> know that many
>  group efforts are hosting their source code, ticketing system, etc.
>  there (Go SIG, Stewardship SIG, FPC, FESCo, etc.). If it is decided to
>  shut down pagure.io <http://pagure.io/>;, I assume those projects will have to be
> moved
>  somewhere? 
+1

>  Also, it's very nice to have a PR-based workflow for some
>  shared-maintenance packages on src.fedoraproject.org
> <http://src.fedoraproject.org/>;, and I don't
>  think losing that feature would be a good thing for fedora. 
+1

>  - How is GitHub considered to be an alternative here? 
+1 …and
to my knowledge GitHub is closed source.

>  I don't think (public or hosted) GitHub can do what is currently
> done
>  on src.fedoraproject.org <http://src.fedoraproject.org/>;, can it?
>  I'd also not want to see fedora use a closed-source product for such a
>  core service ...
>  
>  - Which features are missing from pagure, compared to the other forges? 
+1 It’s not
clear reading the original POST

>  For my purposes, I don't miss any feature on pagure.io
> <http://pagure.io/> compared to my
>  repositories on github.com <http://github.com/>;, and OTTOMH, I can't come up
> with any
>  missing features, at all … 
+1

>  
>  TL;DR:
>  Can we please keep pagure? It already has the fedora-specific features
>  we need, and I don't mind a "slow" pace of development.
>  In my experience, it works really well, and I actually *like* to use
>  it (which is not true for GitLab ... which is slow and horrible) 
+1

>  Fabio 
I totally agree with Fabio, I can’t think of a single reason we should dismiss pagure.

Ciao
Guido
FAS: tartina

[Alex Scheel]

I had replied to Fabio on IRC but... :-)

----- Original Message -----
>  From: "Guido Aulisi" <guido.aulisi(a)gmail.com&gt;
>  To: "Development discussions related to Fedora"
> <devel(a)lists.fedoraproject.org&gt;
>  Sent: Tuesday, January 21, 2020 3:48:31 PM
>  Subject: Re: Git Forge Requirements: Please see the Community Blog
>  
>  
>  
>  > Il giorno 21 gen 2020, alle ore 18:15, Fabio Valentini
>  > <decathorpe(a)gmail.com&gt; ha scritto:
>  > 
>  > On Tue, Jan 21, 2020 at 5:40 PM Leigh Griffin <lgriffin(a)redhat.com
>  > <mailto:[e-mail]>> wrote:
>  >> 
>  >> Hey Everyone,
>  >> 
>  >> On behalf of the CPE team I want to draw the communities attention to a
>  >> recent blog post which you may be impacted by:
>  >> https://communityblog.fedoraproject.org/git-forge-requirements/
>  >> <https://communityblog.fedoraproject.org/git-forge-requirements/>
>  >> 
>  >> We will be seeking input and requirements in an open and transparent
>  >> manner on the future of a git forge solution which will be run by the CPE
>  >> team on behalf of the Fedora Community. This mail is being sent to the
>  >> devel, mindshare and council-discuss lists for maximum visibility on a
>  >> BCC to allow each list have their own views. Please forward it to any
>  >> other list you may feel is relevant to maximise the exposure.
>  >> 
>  >> Thanks in advance,
>  >> Leigh
>  > 
>  > Alright, I have some questions that are not answered by the blog post.
>  > 
>  > - What is going to happen to the two pagure instances at pagure.io
>  > <http://pagure.io/>;,
>  > and src.fedoraproject.org <http://src.fedoraproject.org/>?
>  > 
>  > I think pagure.io <http://pagure.io/> is a good home for fedora-related
>  > projects (it was
>  > the successor to fedorahosted.org <http://fedorahosted.org/>;, after all,
>  > IIRC). I know that many
>  > group efforts are hosting their source code, ticketing system, etc.
>  > there (Go SIG, Stewardship SIG, FPC, FESCo, etc.). If it is decided to
>  > shut down pagure.io <http://pagure.io/>;, I assume those projects will have
>  > to be moved
>  > somewhere?
>  +1
>  
>  > Also, it's very nice to have a PR-based workflow for some
>  > shared-maintenance packages on src.fedoraproject.org
>  > <http://src.fedoraproject.org/>;, and I don't
>  > think losing that feature would be a good thing for fedora.
>  +1
>  
>  > - How is GitHub considered to be an alternative here?
>  +1 …and to my knowledge GitHub is closed source.
>  
>  > I don't think (public or hosted) GitHub can do what is currently done
>  > on src.fedoraproject.org <http://src.fedoraproject.org/>;, can it?
>  > I'd also not want to see fedora use a closed-source product for such a
>  > core service ...
>  > 
>  > - Which features are missing from pagure, compared to the other forges?
>  +1 It’s not clear reading the original POST
>  
>  > For my purposes, I don't miss any feature on pagure.io
> <http://pagure.io/>
>  > compared to my
>  > repositories on github.com <http://github.com/>;, and OTTOMH, I can't come
>  > up with any
>  > missing features, at all …
>  +1 
From a _development_ POV, there's a number of things missing for it being
the primary git forge for pagure.io (not arguing about src.fedoraproject.org
or packaging use cases -- but some of those will benefit by these as well):

 - Real full-text search across issues and PRs. No need to RTFM.
    (
     For those not having RTFM'd, you use "content:<keyword>" to do a
     full-text search in current Pagure. I've argued that it should
     behave like other forge's searches:
     https://pagure.io/pagure/issue/2505#comment-582516
    )
 - A UI with a UX that makes sense.
   https://pagure.io/pagure/issue/4543
   https://pagure.io/pagure/issue/2193
   https://pagure.io/pagure/issue/42    (duped: 343)
   https://pagure.io/pagure/issue/2167
   (and you could keep cherry-picking issues. There's a section of
    opened ones with UI tags).
 - The above is a huge category and I think its worth restating
   some items:
    - Search, search, search.
    - Split diff
    - Real line numbers in the diff
    - Expanding context around the diff
      (Diff, diff, diff?)
    - Workflow on reviewing PRs is sub-optimal compared to most
      other forges.
 - Pagure is often slower than GitLab for me. YMMV.
 - ...

For a period of time, IDM tried using Pagure for FreeIPA development.
They filed a huge number of issues. Now we host issues on Pagure, and
have moved development to GitHub. [*] I think we've mostly quit filing
bugs; the Pagure team has done a good job with the resources they've
been given, but they definitely need more resources to pull this off
to a high level.

I still try and file issues from time to time...

...but Pagure really doesn't compare in quality to Gogs/Gitea, much
less GitLab or GitHub from strictly a development point of view.


My 2c.

- Alex


[*]: My team (Dogtag) is also considering moving our issues off of 
Pagure onto GitHub, to host them along side our code. I don't claim
to speak for all of IDM here though, just noting what they've done.

>  > 
>  > TL;DR:
>  > Can we please keep pagure? It already has the fedora-specific features
>  > we need, and I don't mind a "slow" pace of development.
>  > In my experience, it works really well, and I actually *like* to use
>  > it (which is not true for GitLab ... which is slow and horrible)
>  +1
>  
>  > Fabio
>  
>  I totally agree with Fabio, I can’t think of a single reason we should
>  dismiss pagure.
>  
>  Ciao
>  Guido
>  FAS: tartina
>  _______________________________________________
>  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]
>

[Alexander Bokovoy]

On ti, 21 tammi 2020, Alex Scheel wrote:
> For a period of time, IDM tried using Pagure for FreeIPA development.
> They filed a huge number of issues. Now we host issues on Pagure, and
> have moved development to GitHub. [*] I think we've mostly quit filing
> bugs; the Pagure team has done a good job with the resources they've
> been given, but they definitely need more resources to pull this off
> to a high level. 
FreeIPA does not use Github for its primary code hosting. We do use
Pagure for that and would like to stay with open source forge. We do use
Github to mirror source code from Pagure and utilize pull requests flow,
though, purely because there are two things available there:
  - an easier new contributors' flow
  - ability to integrate with a larger number of CI systems

The first one sometimes is a deal breaker but not really too much. For
example, for Samba a move of existing Github mirror to Gitlab didn't
really reduced inflow of external contributors. Samba project does host
its git tree on own servers and maintains gitlab mirror for actually
doing reviews and accepting external and in-team contributions.

> I still try and file issues from time to time...
>
> ...but Pagure really doesn't compare in quality to Gogs/Gitea, much
> less GitLab or GitHub from strictly a development point of view.
>
>
> My 2c.
>
> - Alex
>
>
> [*]: My team (Dogtag) is also considering moving our issues off of
> Pagure onto GitHub, to host them along side our code. I don't claim
> to speak for all of IDM here though, just noting what they've done.
>
> > >
> > > TL;DR:
> > > Can we please keep pagure? It already has the fedora-specific features
> > > we need, and I don't mind a "slow" pace of development.
> > > In my experience, it works really well, and I actually *like* to use
> > > it (which is not true for GitLab ... which is slow and horrible)
> > +1
> >
> > > Fabio
> >
> > I totally agree with Fabio, I can’t think of a single reason we should
> > dismiss pagure.
> >
> > Ciao
> > Guido
> > FAS: tartina
> > _______________________________________________
> > 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]
-- 
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland

[Robbie Harwood]

Alexander Bokovoy <abokovoy(a)redhat.com&gt; writes:

>  On ti, 21 tammi 2020, Alex Scheel wrote:
>
> > For a period of time, IDM tried using Pagure for FreeIPA development.
> > They filed a huge number of issues. Now we host issues on Pagure, and
> > have moved development to GitHub. [*] I think we've mostly quit
> > filing bugs; the Pagure team has done a good job with the resources
> > they've been given, but they definitely need more resources to pull
> > this off to a high level. 
I was one of the people filing under IdM (mostly due to another IdM
component, gssproxy, which is wholly on pagure).  While there was some
activity on them, it has definitely felt like there's no capacity for
new features.

>  FreeIPA does not use Github for its primary code hosting. We do use
>  Pagure for that and would like to stay with open source forge. We do use
>  Github to mirror source code from Pagure and utilize pull requests flow,
>  though, purely because there are two things available there:
>    - an easier new contributors' flow 
Hmm.  As an occasional drive-by contributor, I don't find this easier.
The problem for me is that the issue tracker and PR interface are on
separate platforms, and there's some pressure to create issues before
filing PRs.  While I prefer the Github workflow (and I agree it's easier
for new contributors), I honestly think it's better to have it in just
one place.

>    - ability to integrate with a larger number of CI systems
>
>  The first one sometimes is a deal breaker but not really too much. For
>  example, for Samba a move of existing Github mirror to Gitlab didn't
>  really reduced inflow of external contributors. Samba project does host
>  its git tree on own servers and maintains gitlab mirror for actually
>  doing reviews and accepting external and in-team contributions. 
As long as the distinction between "canonical source of truth" and "the
one everyone interacts with all the time" doesn't affect non-maintainers
(and they can just use the second), it doesn't really matter - admins
just can't use any of the nice tools for integrating PRs.  I don't
personally think it's a useful distinction in a DVCS world, so I don't
make it in my projects.

Thanks,
--Robbie

[Felix Schwarz]

Am 21.01.20 um 21:48 schrieb Guido Aulisi:
>  I totally agree with Fabio, I can’t think of a single reason we
> should dismiss
>  pagure. 
Gitlab is used by many free software communities like Freedesktop, Gnome,
Debian. Using the same tools could help to facilitate
inter-process/inter-distro collaboration.

Personally I guess github would attract most contributions for Fedora from new
contributors but it is closed source so I'd prefer gitlab for Fedora. (Though
I somehow got used to pagure and getting the gitlab integration to the same
level as pagure currently will be a lot of work for sure.)

Felix

[Michael Watters]

On 1/21/20 4:59 PM, Felix Schwarz wrote:
>  (Though
>  I somehow got used to pagure and getting the gitlab integration to the same
>  level as pagure currently will be a lot of work for sure.) 

Maybe I'm just a grumpy old system admin but it sounds like a lot of
work for little, if any, gain.

[Adam Williamson]

On Tue, 2020-01-21 at 17:04 -0500, Michael Watters wrote:
>  On 1/21/20 4:59 PM, Felix Schwarz wrote:
>  > (Though
>  > I somehow got used to pagure and getting the gitlab integration to the same
>  > level as pagure currently will be a lot of work for sure.)
>  
>  Maybe I'm just a grumpy old system admin but it sounds like a lot of
>  work for little, if any, gain. 
The gain would be not having to maintain Pagure any more. It's
essentially one-time work for long-term gain, assuming the alternative
solution continues to exist and to be maintained and to meet our needs.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

[Dan Čermák]

Felix Schwarz <fschwarz(a)fedoraproject.org&gt; writes:

>  Am 21.01.20 um 21:48 schrieb Guido Aulisi:
> > I totally agree with Fabio, I can’t think of a single reason we should dismiss
> > pagure.
>
>  Gitlab is used by many free software communities like Freedesktop, Gnome,
>  Debian. Using the same tools could help to facilitate
>  inter-process/inter-distro collaboration.
>
>  Personally I guess github would attract most contributions for Fedora from new
>  contributors but it is closed source so I'd prefer gitlab for Fedora. (Though
>  I somehow got used to pagure and getting the gitlab integration to the same
>  level as pagure currently will be a lot of work for sure.) 
On top of that Gitlab is a huge Ruby on Rails application and (at least
I have the feeling that) the Fedora community doesn't have so many Ruby
developers in comparison to Python developers, so implementing something
comparable could be challenging let alone from the manpower point of
view.
And then there's the issue that we are not upstream and might have to
maintain the integration as a downstream patch forever as upstream might
not want it.


Cheers,

Dan

[John M. Harris Jr]

On Tuesday, January 21, 2020 9:57:59 PM MST Dan Čermák wrote:
>  Felix Schwarz <fschwarz(a)fedoraproject.org&gt; writes:
>  > Am 21.01.20 um 21:48 schrieb Guido Aulisi:
>  >> I totally agree with Fabio, I can’t think of a single reason we should
>  >> dismiss pagure.
>  > 
>  > Gitlab is used by many free software communities like Freedesktop, Gnome,
>  > Debian. Using the same tools could help to facilitate
>  > inter-process/inter-distro collaboration.
>  > 
>  > Personally I guess github would attract most contributions for Fedora from
>  > new contributors but it is closed source so I'd prefer gitlab for Fedora.
>  > (Though I somehow got used to pagure and getting the gitlab integration
>  > to the same level as pagure currently will be a lot of work for sure.)
>  
>  On top of that Gitlab is a huge Ruby on Rails application and (at least
>  I have the feeling that) the Fedora community doesn't have so many Ruby
>  developers in comparison to Python developers, so implementing something
>  comparable could be challenging let alone from the manpower point of
>  view.
>  And then there's the issue that we are not upstream and might have to
>  maintain the integration as a downstream patch forever as upstream might
>  not want it.
>  
>  
>  Cheers,
>  
>  Dan 
If these Python people really can't figure out Ruby, a language binding can be 
generated.. However, Ruby is much more clean than Python, and there's no 
requirement for downstream patches anyway. GitLab has a plugin interface these 
days.

-- 
John M. Harris, Jr.
Splentity

[Peter Robinson]

On Wed, Jan 22, 2020 at 4:59 AM Dan Čermák
<dan.cermak(a)cgc-instruments.com&gt; wrote:
>  Felix Schwarz <fschwarz(a)fedoraproject.org&gt; writes:
>
>  > Am 21.01.20 um 21:48 schrieb Guido Aulisi:
>  >> I totally agree with Fabio, I can’t think of a single reason we should dismiss
>  >> pagure.
>  >
>  > Gitlab is used by many free software communities like Freedesktop, Gnome,
>  > Debian. Using the same tools could help to facilitate
>  > inter-process/inter-distro collaboration.
>  >
>  > Personally I guess github would attract most contributions for Fedora from new
>  > contributors but it is closed source so I'd prefer gitlab for Fedora. (Though
>  > I somehow got used to pagure and getting the gitlab integration to the same
>  > level as pagure currently will be a lot of work for sure.)
>
>  On top of that Gitlab is a huge Ruby on Rails application and (at least
>  I have the feeling that) the Fedora community doesn't have so many Ruby
>  developers in comparison to Python developers, so implementing something
>  comparable could be challenging let alone from the manpower point of
>  view. 
That's the whole point of APIs, and I'm sure they provide bindings for
those APIs to assist in the process.

>  And then there's the issue that we are not upstream and might
> have to
>  maintain the integration as a downstream patch forever as upstream might
>  not want it. 
They've provided pretty good support to various other open source
communities such as GNOME and Freedesktop/Xorg.

I think we should be looking at this from a different PoV.... like the
given the resources that we currently have attempting to develop a git
forge what could they do if someone else was doing that what other
awesome things could they achieve if they were able to deal with
integration as opposed to just playing catch up.

[Neal Gompa]

On Wed, Jan 22, 2020 at 1:05 AM Peter Robinson <pbrobinson(a)gmail.com&gt; wrote:
>  On Wed, Jan 22, 2020 at 4:59 AM Dan Čermák
>  <dan.cermak(a)cgc-instruments.com&gt; wrote:
>  >
>  > Felix Schwarz <fschwarz(a)fedoraproject.org&gt; writes:
>  >
>  > > Am 21.01.20 um 21:48 schrieb Guido Aulisi:
>  > >> I totally agree with Fabio, I can’t think of a single reason we should
> dismiss
>  > >> pagure.
>  > >
>  > > Gitlab is used by many free software communities like Freedesktop, Gnome,
>  > > Debian. Using the same tools could help to facilitate
>  > > inter-process/inter-distro collaboration.
>  > >
>  > > Personally I guess github would attract most contributions for Fedora from new
>  > > contributors but it is closed source so I'd prefer gitlab for Fedora.
> (Though
>  > > I somehow got used to pagure and getting the gitlab integration to the same
>  > > level as pagure currently will be a lot of work for sure.)
>  >
>  > On top of that Gitlab is a huge Ruby on Rails application and (at least
>  > I have the feeling that) the Fedora community doesn't have so many Ruby
>  > developers in comparison to Python developers, so implementing something
>  > comparable could be challenging let alone from the manpower point of
>  > view.
>
>  That's the whole point of APIs, and I'm sure they provide bindings for
>  those APIs to assist in the process.
>  
Sorry, no they don't. There are some community projects that provide
some overlays to some of the APIs, but they are in various states of
disrepair. Some are doing somewhat okay, but it's difficult since
their churn rate also includes API breakages.

>  > And then there's the issue that we are not upstream and
> might have to
>  > maintain the integration as a downstream patch forever as upstream might
>  > not want it.
>
>  They've provided pretty good support to various other open source
>  communities such as GNOME and Freedesktop/Xorg.
>  
Yes, but neither of those communities actually have terribly special
requirements. In fact, those communities either had *nothing* in terms
of infrastructure (FreeDesktop/Xorg) or were willing to throw
everything away for GitLab (GNOME). We would not fit in either bucket,
which makes GitLab a very awkward fit for us.

And GitLab CI is a poor fit for Fedora because it doesn't offer a good
model for distribution-scale integration and delivery. At $DAYJOB, I
have been maintaining a heavily used GitLab system for three years,
and I have some fairly good experience understanding where it fits
well since $DAYJOB folks try to exploit as many features that are
reasonably useful as possible. And frankly, it works well for GNOME
and FDO because multi-project integration is not a fundamental
requirement for the projects hosted there. For Fedora, this *is* a
fundamental requirement, and the Fedora CI people are working
gloriously towards the goal of having that be fully in place.

>  I think we should be looking at this from a different PoV.... like
> the
>  given the resources that we currently have attempting to develop a git
>  forge what could they do if someone else was doing that what other
>  awesome things could they achieve if they were able to deal with
>  integration as opposed to just playing catch up. 
That's not the motivation here. And honestly, I've *never* seen that happen.

That's also a somewhat negative view of this, because it implies we're
not doing something awesome now. Pagure fills a niche that currently
isn't filled by anything else today and works rather well in doing so.
Pagure is actually a pretty awesome forge that provides some unique
capabilities:

* Remote pull requests, allowing people working on their own servers
to contribute to projects on Pagure
* Support for fully offline workflows (this is actually possible due
to Pagure's fundamental design)
* Full state project mirroring in a reasonably portable manner
* Full themeability without pain (that's fairly recent, but it's nice!)
* First-class support for integrating with other solutions (best of
breed combinations rather than difficult monoliths)

Downstream distributions can actually fully mirror src.fp.o without
too much pain, including PRs, and do further work based on it. That's
not really a thing in other forges. I know that I've been using that
property for some of $DAYJOB work and personal work too, and it really
makes life quite nice.

Since Pagure 5.0, I've been a very happy user of the Pagure forge, as
the usability of the system has gone way up and it is very close to my
vision of what a Free Software forge should be like. Pagure makes our
island have bridges to other islands, as opposed to all these GitLab
servers that are closed islands.

And there's this worry that GitLab will go the same path Transifex
did. They have a ton of incentives to do so, and they already are
starting to with the consideration of injecting nonfree JavaScript in
all variants. And if you think community forks are going to survive on
the GitLab codebase, oh boy, nope. That codebase is *huge* and
complex. It's a combination of Ruby and Go that has one of the most
baffling architectures I've observed. The RhodeCode fork Kallithea is
many times smaller and is equally struggling.

Pagure is also slowly growing as a community in its own right and
there are various groups aligned with Pagure's vision that are
interested in adopting it as their solution and contributing to the
project. Part of this has been somewhat due to my campaigning for it
in aligned communities, of course, but it's also because Pagure is
genuinely good and unique among Git forge solutions.

Pagure is also proof that Fedora can be innovative in a very positive
way. It was a rough start, but we've got a groove going, let's not
kill it!

The Pagure.io forge really is only missing some kind of self-service
CI to make it generically useful. CentOS CI is a trash heap and needs
to be replaced by a better solution that allows self-service
enablement. I'm sorry, but whoever thought that CentOS CI would scale
or work reasonably well needs to rethink their priorities. It's the
only part of the Pagure.io forge system that isn't self-service, and
it shows with the poor levels of CI adoption.

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

[Adam Williamson]

On Wed, 2020-01-22 at 05:00 -0500, Neal Gompa wrote:
>  
>  > > On top of that Gitlab is a huge Ruby on Rails application and (at least
>  > > I have the feeling that) the Fedora community doesn't have so many Ruby
>  > > developers in comparison to Python developers, so implementing something
>  > > comparable could be challenging let alone from the manpower point of
>  > > view.
>  > 
>  > That's the whole point of APIs, and I'm sure they provide bindings for
>  > those APIs to assist in the process.
>  > 
>  
>  Sorry, no they don't. There are some community projects that provide
>  some overlays to some of the APIs, but they are in various states of
>  disrepair. Some are doing somewhat okay, but it's difficult since
>  their churn rate also includes API breakages. 
https://github.com/python-gitlab/python-gitlab looks like a pretty
actively maintained thing which claims to be compatible with current
Gitlab API.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

[Neal Gompa]

On Wed, Jan 22, 2020 at 6:04 AM Adam Williamson
<adamwill(a)fedoraproject.org&gt; wrote:
>  On Wed, 2020-01-22 at 05:00 -0500, Neal Gompa wrote:
>  >
>  > > > On top of that Gitlab is a huge Ruby on Rails application and (at least
>  > > > I have the feeling that) the Fedora community doesn't have so many
> Ruby
>  > > > developers in comparison to Python developers, so implementing something
>  > > > comparable could be challenging let alone from the manpower point of
>  > > > view.
>  > >
>  > > That's the whole point of APIs, and I'm sure they provide bindings for
>  > > those APIs to assist in the process.
>  > >
>  >
>  > Sorry, no they don't. There are some community projects that provide
>  > some overlays to some of the APIs, but they are in various states of
>  > disrepair. Some are doing somewhat okay, but it's difficult since
>  > their churn rate also includes API breakages.
>
>  https://github.com/python-gitlab/python-gitlab looks like a pretty
>  actively maintained thing which claims to be compatible with current
>  Gitlab API. 
I'm using that one at work for some stuff, and most of the basic APIs
are in place, but the coverage of the GitLab API isn't very high. It's
mostly because GitLab keeps adding more stuff to the API and people
can't keep up, though. When I started using it around GitLab 10.5, it
was considered a lot more complete than it is now.

That said, basic interactions work pretty well, and as far as I know,
it's the most complete of the community API modules.



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

[Jeremy Cline]

On Wed, Jan 22, 2020 at 12:04:15PM +0100, Adam Williamson wrote:
>  On Wed, 2020-01-22 at 05:00 -0500, Neal Gompa wrote:
>  > 
>  > > > On top of that Gitlab is a huge Ruby on Rails application and (at least
>  > > > I have the feeling that) the Fedora community doesn't have so many
> Ruby
>  > > > developers in comparison to Python developers, so implementing something
>  > > > comparable could be challenging let alone from the manpower point of
>  > > > view.
>  > > 
>  > > That's the whole point of APIs, and I'm sure they provide bindings for
>  > > those APIs to assist in the process.
>  > > 
>  > 
>  > Sorry, no they don't. There are some community projects that provide
>  > some overlays to some of the APIs, but they are in various states of
>  > disrepair. Some are doing somewhat okay, but it's difficult since
>  > their churn rate also includes API breakages.
>  
>  https://github.com/python-gitlab/python-gitlab looks like a pretty
>  actively maintained thing which claims to be compatible with current
>  Gitlab API. 
I've used this library in a moderately complicated project
(automatically bridging email list development to GitLab and vice versa)
and it's worked fine. As far as I can tell it covers the whole API.
Nothing has broken for me, documentation is reasonable, etc. The GitLab
API itself is much better than Pagure.

As far as I can tell GitLab actually versions its API and Pagure has
broken its API without a version bump repeatedly (e.g. some unpaginated
APIs suddenly became paginated).

- Jeremy

[Clement Verna]

On Wed, 22 Jan 2020 at 11:02, Neal Gompa <ngompa13(a)gmail.com&gt; wrote:

>  On Wed, Jan 22, 2020 at 1:05 AM Peter Robinson
> <pbrobinson(a)gmail.com&gt;
>  wrote:
>  >
>  > On Wed, Jan 22, 2020 at 4:59 AM Dan Čermák
>  > <dan.cermak(a)cgc-instruments.com&gt; wrote:
>  > >
>  > > Felix Schwarz <fschwarz(a)fedoraproject.org&gt; writes:
>  > >
>  > > > Am 21.01.20 um 21:48 schrieb Guido Aulisi:
>  > > >> I totally agree with Fabio, I can’t think of a single reason we
>  should dismiss
>  > > >> pagure.
>  > > >
>  > > > Gitlab is used by many free software communities like Freedesktop,
>  Gnome,
>  > > > Debian. Using the same tools could help to facilitate
>  > > > inter-process/inter-distro collaboration.
>  > > >
>  > > > Personally I guess github would attract most contributions for
>  Fedora from new
>  > > > contributors but it is closed source so I'd prefer gitlab for
>  Fedora. (Though
>  > > > I somehow got used to pagure and getting the gitlab integration to
>  the same
>  > > > level as pagure currently will be a lot of work for sure.)
>  > >
>  > > On top of that Gitlab is a huge Ruby on Rails application and (at least
>  > > I have the feeling that) the Fedora community doesn't have so many Ruby
>  > > developers in comparison to Python developers, so implementing
>  something
>  > > comparable could be challenging let alone from the manpower point of
>  > > view.
>  >
>  > That's the whole point of APIs, and I'm sure they provide bindings for
>  > those APIs to assist in the process.
>  >
>
>  Sorry, no they don't. There are some community projects that provide
>  some overlays to some of the APIs, but they are in various states of
>  disrepair. Some are doing somewhat okay, but it's difficult since
>  their churn rate also includes API breakages.
>
>  > > And then there's the issue that we are not upstream and might have to
>  > > maintain the integration as a downstream patch forever as upstream
>  might
>  > > not want it.
>  >
>  > They've provided pretty good support to various other open source
>  > communities such as GNOME and Freedesktop/Xorg.
>  >
>
>  Yes, but neither of those communities actually have terribly special
>  requirements. In fact, those communities either had *nothing* in terms
>  of infrastructure (FreeDesktop/Xorg) or were willing to throw
>  everything away for GitLab (GNOME). We would not fit in either bucket,
>  which makes GitLab a very awkward fit for us.
>
>  And GitLab CI is a poor fit for Fedora because it doesn't offer a good
>  model for distribution-scale integration and delivery. At $DAYJOB, I
>  have been maintaining a heavily used GitLab system for three years,
>  and I have some fairly good experience understanding where it fits
>  well since $DAYJOB folks try to exploit as many features that are
>  reasonably useful as possible. And frankly, it works well for GNOME
>  and FDO because multi-project integration is not a fundamental
>  requirement for the projects hosted there. For Fedora, this *is* a
>  fundamental requirement, and the Fedora CI people are working
>  gloriously towards the goal of having that be fully in place.
>
>  > I think we should be looking at this from a different PoV.... like the
>  > given the resources that we currently have attempting to develop a git
>  > forge what could they do if someone else was doing that what other
>  > awesome things could they achieve if they were able to deal with
>  > integration as opposed to just playing catch up.
>
>  That's not the motivation here. And honestly, I've *never* seen that
>  happen.
>  
It just happened last year, a lot of the development effort of the CPE team
was focused on rawhide gating. It meant that projects that were not related
to that effort suffered from this, for example pagure, anitya
(release-minotoring), speeding up the compose,  moving away from PDC,
moving from the current FAS, etc ...


>  That's also a somewhat negative view of this, because it implies we're
>  not doing something awesome now. Pagure fills a niche that currently
>  isn't filled by anything else today and works rather well in doing so.
>  Pagure is actually a pretty awesome forge that provides some unique
>  capabilities:
>
>  * Remote pull requests, allowing people working on their own servers
>  to contribute to projects on Pagure
>  * Support for fully offline workflows (this is actually possible due
>  to Pagure's fundamental design)
>  * Full state project mirroring in a reasonably portable manner
>  * Full themeability without pain (that's fairly recent, but it's nice!)
>  * First-class support for integrating with other solutions (best of
>  breed combinations rather than difficult monoliths)
>
>  Downstream distributions can actually fully mirror src.fp.o without
>  too much pain, including PRs, and do further work based on it. That's
>  not really a thing in other forges. I know that I've been using that
>  property for some of $DAYJOB work and personal work too, and it really
>  makes life quite nice.
>
>  Since Pagure 5.0, I've been a very happy user of the Pagure forge, as
>  the usability of the system has gone way up and it is very close to my
>  vision of what a Free Software forge should be like. Pagure makes our
>  island have bridges to other islands, as opposed to all these GitLab
>  servers that are closed islands.
>
>  And there's this worry that GitLab will go the same path Transifex
>  did. They have a ton of incentives to do so, and they already are
>  starting to with the consideration of injecting nonfree JavaScript in
>  all variants. And if you think community forks are going to survive on
>  the GitLab codebase, oh boy, nope. That codebase is *huge* and
>  complex. It's a combination of Ruby and Go that has one of the most
>  baffling architectures I've observed. The RhodeCode fork Kallithea is
>  many times smaller and is equally struggling.
>
>  Pagure is also slowly growing as a community in its own right and
>  there are various groups aligned with Pagure's vision that are
>  interested in adopting it as their solution and contributing to the
>  project. Part of this has been somewhat due to my campaigning for it
>  in aligned communities, of course, but it's also because Pagure is
>  genuinely good and unique among Git forge solutions.
>
>  Pagure is also proof that Fedora can be innovative in a very positive
>  way. It was a rough start, but we've got a groove going, let's not
>  kill it!
>  
I agree with you that Pagure is a cool project and is particularly unique
in the world of git forges. I have also made my first FOSS contribution to
Pagure and if I am part of the Fedora Community today it is because of
Pagure and Pingou. But I also have to pragmatic and realistic and I think
that to be successful Pagure needs more development effort and I don't
think that in the current state of the Fedora Infrastructure we can afford
that development. My opinion from working day to day in this infrastructure
is that we are now reaching a point where we have to pay for the technical
debt we have accumulated. Like any sort of debt, you have to pay its
interests and for many year we did not, now with have the debt collector
knocking at the door, looking at the televisor in the living room. The more
we wait to pay back this technical debt the worst it becomes, you also have
to add to that, that a lot of the technical and domain knowledge about the
tools and the infra in general was lost when most of the creator of these
applications moved to new adventures.

The Fedora community is also not growing much, more and more community
member ends up having more and more things to do, because of that they are
even more dependent on the infrastructure being reliable and stable. For
example many people might have planned to contribute during the end of the
year holidays but could not because of the problem we have experience with
Koji, Bodhi and RabbitMQ. It means that users of the infra are getting
frustrated because Koji is slow again, a Bodhi update was not pushed again,
there is a problem pushing a commit to fork again, or there is no progress
on my 2 year old ticket that ask to rename my group in FAS. It also means
that people working on the infra are getting more and more frustrated
because there are just too many fires to fight at once and whatever they do
it will suck or someone will complain.

All this technical debt, also make it harder to attract new contributor who
would be interested to contribute development time to these applications.
Being innovative and creative is fun, creating new cool application for the
Fedora Community is really great and rewarding, the other side of the medal
is a little bit less shiny, maintaining a large code base, making sure that
it runs well in production is not that interesting and rewarding.

In my opinion, as a community we have to make a choice either we continue
as we are now, knowing very well that the things will only get worst, or do
we try to refocus on the essential and make some sacrifice and compromise ?
Alternative to Pagure will not be perfect and will not cover 100% of the
use cases, but can we live with it ? are we ready to make some trade off ?
Another solution is to find 20 developers that are willing to invest a few
hours a week fixing bugs on all the applications we have.




>  The Pagure.io forge really is only missing some kind of self-service
>  CI to make it generically useful. CentOS CI is a trash heap and needs
>  to be replaced by a better solution that allows self-service
>  enablement. I'm sorry, but whoever thought that CentOS CI would scale
>  or work reasonably well needs to rethink their priorities. It's the
>  only part of the Pagure.io forge system that isn't self-service, and
>  it shows with the poor levels of CI adoption.
>
>  --
>  真実はいつも一つ！/ 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]
>

[Ernestas Kulik]

On Wed, 2020-01-22 at 05:00 -0500, Neal Gompa wrote:
>  > > And then there's the issue that we are not upstream and
> might
>  > > have to
>  > > maintain the integration as a downstream patch forever as
>  > > upstream might
>  > > not want it.
>  > 
>  > They've provided pretty good support to various other open source
>  > communities such as GNOME and Freedesktop/Xorg.
>  > 
>  
>  Yes, but neither of those communities actually have terribly special
>  requirements. In fact, those communities either had *nothing* in
>  terms
>  of infrastructure (FreeDesktop/Xorg) or were willing to throw
>  everything away for GitLab (GNOME). We would not fit in either
>  bucket,
>  which makes GitLab a very awkward fit for us. 
“Throw everything away”? Just how much of the transition did you
follow?

GitLab was more than accommodating in pulling features out of the
enterprise edition into the community one that were crucial for our
workflows. It was not done on a whim and I really resent your
statements here.

-- 
Ernestas Kulik
Associate Software Engineer - Base Operating Systems (Core
Services/ABRT)
Red Hat Czech, s.r.o.

[Neal Gompa]

On Wed, Jan 22, 2020 at 9:08 AM Ernestas Kulik <ekulik(a)redhat.com&gt; wrote:
>  On Wed, 2020-01-22 at 05:00 -0500, Neal Gompa wrote:
>  > > > And then there's the issue that we are not upstream and might
>  > > > have to
>  > > > maintain the integration as a downstream patch forever as
>  > > > upstream might
>  > > > not want it.
>  > >
>  > > They've provided pretty good support to various other open source
>  > > communities such as GNOME and Freedesktop/Xorg.
>  > >
>  >
>  > Yes, but neither of those communities actually have terribly special
>  > requirements. In fact, those communities either had *nothing* in
>  > terms
>  > of infrastructure (FreeDesktop/Xorg) or were willing to throw
>  > everything away for GitLab (GNOME). We would not fit in either
>  > bucket,
>  > which makes GitLab a very awkward fit for us.
>
>  “Throw everything away”? Just how much of the transition did you
>  follow?
>
>  GitLab was more than accommodating in pulling features out of the
>  enterprise edition into the community one that were crucial for our
>  workflows. It was not done on a whim and I really resent your
>  statements here.
>  
I followed it pretty closely. In the GNOME case, you were willing to
throw away Bugzilla, CGit, and older CI infrastructure to replace it
with GitLab. You guys also renamed some of your repositories to
accommodate the restrictions on project naming by GitLab. A lot of
retooling was required as part of the transition to GitLab for GNOME.

That, by my definition, is throwing away everything. It had knock on
effects for everyone downstream as well, as all the tools for tracking
GNOME also broke and needed to change. Again, that's fine if the
community is generally accepting of this pain, but it is still pain,
even if you refuse to acknowledge it.



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

[Ernestas Kulik]

On Wed, 2020-01-22 at 09:12 -0500, Neal Gompa wrote:
>  On Wed, Jan 22, 2020 at 9:08 AM Ernestas Kulik
> <ekulik(a)redhat.com&gt;
>  wrote:
>  > On Wed, 2020-01-22 at 05:00 -0500, Neal Gompa wrote:
>  > > > > And then there's the issue that we are not upstream and might
>  > > > > have to
>  > > > > maintain the integration as a downstream patch forever as
>  > > > > upstream might
>  > > > > not want it.
>  > > > 
>  > > > They've provided pretty good support to various other open
>  > > > source
>  > > > communities such as GNOME and Freedesktop/Xorg.
>  > > > 
>  > > 
>  > > Yes, but neither of those communities actually have terribly
>  > > special
>  > > requirements. In fact, those communities either had *nothing* in
>  > > terms
>  > > of infrastructure (FreeDesktop/Xorg) or were willing to throw
>  > > everything away for GitLab (GNOME). We would not fit in either
>  > > bucket,
>  > > which makes GitLab a very awkward fit for us.
>  > 
>  > “Throw everything away”? Just how much of the transition did you
>  > follow?
>  > 
>  > GitLab was more than accommodating in pulling features out of the
>  > enterprise edition into the community one that were crucial for our
>  > workflows. It was not done on a whim and I really resent your
>  > statements here.
>  > 
>  
>  I followed it pretty closely. In the GNOME case, you were willing to
>  throw away Bugzilla, CGit, and older CI infrastructure to replace it
>  with GitLab. You guys also renamed some of your repositories to
>  accommodate the restrictions on project naming by GitLab. A lot of
>  retooling was required as part of the transition to GitLab for GNOME. 
What? Do you suggest adding more infrastructure to maintain on (at the
time) a singular sysadmin? Bugzilla and cgit were to be made redundant,
that’s the whole point here.

The “older CI infrastructure” is still there and has been semi-broken
forever, so that’s as immaterial as it gets. The development for the
replacement was only nudged by the GitLab transition.

I don’t even know how to approach the accusation that we bent over
backwards to appease the overlords, dictating repository naming. Yes,
GTK, most prominently, was renamed as a result. It really was more a
pretext, because no one cares about the plus and it was historical
baggage.

>  That, by my definition, is throwing away everything. It had knock on
>  effects for everyone downstream as well, as all the tools for
>  tracking
>  GNOME also broke and needed to change. Again, that's fine if the
>  community is generally accepting of this pain, but it is still pain,
>  even if you refuse to acknowledge it. 
Please don’t say I’m in denial just because I don’t agree with what
you’re trying to convey here.

My observation is that the pipelines that were built only managed to
improve developers’ workflows by automating as much as possible with a
tool that tries to provide that. Those, who preferred the old ways,
adjusted as best they could, too, even only taking patches in GitLab
issues instead of working with merge requests. You can only imagine how
many external contributions those projects see.

-- 
Ernestas Kulik
Associate Software Engineer - Base Operating Systems (Core
Services/ABRT)
Red Hat Czech, s.r.o.

[Clement Verna]

On Wed, 22 Jan 2020 at 15:37, Ernestas Kulik <ekulik(a)redhat.com&gt; wrote:

>  On Wed, 2020-01-22 at 09:12 -0500, Neal Gompa wrote:
>  > On Wed, Jan 22, 2020 at 9:08 AM Ernestas Kulik <ekulik(a)redhat.com&gt;
>  > wrote:
>  > > On Wed, 2020-01-22 at 05:00 -0500, Neal Gompa wrote:
>  > > > > > And then there's the issue that we are not upstream and
> might
>  > > > > > have to
>  > > > > > maintain the integration as a downstream patch forever as
>  > > > > > upstream might
>  > > > > > not want it.
>  > > > >
>  > > > > They've provided pretty good support to various other open
>  > > > > source
>  > > > > communities such as GNOME and Freedesktop/Xorg.
>  > > > >
>  > > >
>  > > > Yes, but neither of those communities actually have terribly
>  > > > special
>  > > > requirements. In fact, those communities either had *nothing* in
>  > > > terms
>  > > > of infrastructure (FreeDesktop/Xorg) or were willing to throw
>  > > > everything away for GitLab (GNOME). We would not fit in either
>  > > > bucket,
>  > > > which makes GitLab a very awkward fit for us.
>  > >
>  > > “Throw everything away”? Just how much of the transition did you
>  > > follow?
>  > >
>  > > GitLab was more than accommodating in pulling features out of the
>  > > enterprise edition into the community one that were crucial for our
>  > > workflows. It was not done on a whim and I really resent your
>  > > statements here.
>  > >
>  >
>  > I followed it pretty closely. In the GNOME case, you were willing to
>  > throw away Bugzilla, CGit, and older CI infrastructure to replace it
>  > with GitLab. You guys also renamed some of your repositories to
>  > accommodate the restrictions on project naming by GitLab. A lot of
>  > retooling was required as part of the transition to GitLab for GNOME.
>
>  What? Do you suggest adding more infrastructure to maintain on (at the
>  time) a singular sysadmin? Bugzilla and cgit were to be made redundant,
>  that’s the whole point here.
>
>  The “older CI infrastructure” is still there and has been semi-broken
>  forever, so that’s as immaterial as it gets. The development for the
>  replacement was only nudged by the GitLab transition.
>
>  I don’t even know how to approach the accusation that we bent over
>  backwards to appease the overlords, dictating repository naming. Yes,
>  GTK, most prominently, was renamed as a result. It really was more a
>  pretext, because no one cares about the plus and it was historical
>  baggage.
>
>  > That, by my definition, is throwing away everything. It had knock on
>  > effects for everyone downstream as well, as all the tools for
>  > tracking
>  > GNOME also broke and needed to change. Again, that's fine if the
>  > community is generally accepting of this pain, but it is still pain,
>  > even if you refuse to acknowledge it.
>
>  Please don’t say I’m in denial just because I don’t agree with what
>  you’re trying to convey here.
>
>  My observation is that the pipelines that were built only managed to
>  improve developers’ workflows by automating as much as possible with a
>  tool that tries to provide that. Those, who preferred the old ways,
>  adjusted as best they could, too, even only taking patches in GitLab
>  issues instead of working with merge requests. You can only imagine how
>  many external contributions those projects see.
>  
For the curious like me, is the GNOME GitLab instance self hosted ? or
hosted by GitLab ?


>  --
>  Ernestas Kulik
>  Associate Software Engineer - Base Operating Systems (Core
>  Services/ABRT)
>  Red Hat Czech, s.r.o.
>  _______________________________________________
>  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]
>

[Felipe Borges]

On Wed, Jan 22, 2020 at 3:43 PM Clement Verna <cverna(a)fedoraproject.org&gt; wrote:
>  On Wed, 22 Jan 2020 at 15:37, Ernestas Kulik <ekulik(a)redhat.com&gt; wrote:
> >
> > On Wed, 2020-01-22 at 09:12 -0500, Neal Gompa wrote:
> > > On Wed, Jan 22, 2020 at 9:08 AM Ernestas Kulik <ekulik(a)redhat.com&gt;
> > > wrote:
> > > > On Wed, 2020-01-22 at 05:00 -0500, Neal Gompa wrote:
> > > > > > > And then there's the issue that we are not upstream and
> might
> > > > > > > have to
> > > > > > > maintain the integration as a downstream patch forever as
> > > > > > > upstream might
> > > > > > > not want it.
> > > > > >
> > > > > > They've provided pretty good support to various other open
> > > > > > source
> > > > > > communities such as GNOME and Freedesktop/Xorg.
> > > > > >
> > > > >
> > > > > Yes, but neither of those communities actually have terribly
> > > > > special
> > > > > requirements. In fact, those communities either had *nothing* in
> > > > > terms
> > > > > of infrastructure (FreeDesktop/Xorg) or were willing to throw
> > > > > everything away for GitLab (GNOME). We would not fit in either
> > > > > bucket,
> > > > > which makes GitLab a very awkward fit for us.
> > > >
> > > > “Throw everything away”? Just how much of the transition did you
> > > > follow?
> > > >
> > > > GitLab was more than accommodating in pulling features out of the
> > > > enterprise edition into the community one that were crucial for our
> > > > workflows. It was not done on a whim and I really resent your
> > > > statements here.
> > > >
> > >
> > > I followed it pretty closely. In the GNOME case, you were willing to
> > > throw away Bugzilla, CGit, and older CI infrastructure to replace it
> > > with GitLab. You guys also renamed some of your repositories to
> > > accommodate the restrictions on project naming by GitLab. A lot of
> > > retooling was required as part of the transition to GitLab for GNOME.
> >
> > What? Do you suggest adding more infrastructure to maintain on (at the
> > time) a singular sysadmin? Bugzilla and cgit were to be made redundant,
> > that’s the whole point here.
> >
> > The “older CI infrastructure” is still there and has been semi-broken
> > forever, so that’s as immaterial as it gets. The development for the
> > replacement was only nudged by the GitLab transition.
> >
> > I don’t even know how to approach the accusation that we bent over
> > backwards to appease the overlords, dictating repository naming. Yes,
> > GTK, most prominently, was renamed as a result. It really was more a
> > pretext, because no one cares about the plus and it was historical
> > baggage.
> >
> > > That, by my definition, is throwing away everything. It had knock on
> > > effects for everyone downstream as well, as all the tools for
> > > tracking
> > > GNOME also broke and needed to change. Again, that's fine if the
> > > community is generally accepting of this pain, but it is still pain,
> > > even if you refuse to acknowledge it.
> >
> > Please don’t say I’m in denial just because I don’t agree with what
> > you’re trying to convey here.
> >
> > My observation is that the pipelines that were built only managed to
> > improve developers’ workflows by automating as much as possible with a
> > tool that tries to provide that. Those, who preferred the old ways,
> > adjusted as best they could, too, even only taking patches in GitLab
> > issues instead of working with merge requests. You can only imagine how
> > many external contributions those projects see.
>
>
>  For the curious like me, is the GNOME GitLab instance self hosted ? or hosted by GitLab ?
It is self-hosted.

> >
> >
> > --
> > Ernestas Kulik
> > Associate Software Engineer - Base Operating Systems (Core
> > Services/ABRT)
> > Red Hat Czech, s.r.o.
> > _______________________________________________
> > 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]

[Michael Catanzaro]

On Wed, Jan 22, 2020 at 9:12 am, Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  I followed it pretty closely. In the GNOME case, you were willing to
>  throw away Bugzilla, CGit, and older CI infrastructure to replace it
>  with GitLab. 
To be clear, getting rid of Bugzilla was the goal, not a compromise. 
cgit is a nice interface but it's mostly obsoleted by GitLab as well. 
We didn't *have* to get rid of cgit, but there just wasn't a compelling 
reason to keep it. And we never had any CI prior to GitLab. CI is 
surely the most important part. GitLab CE has tremendously improved our 
development workflow.

When I say GitLab, I mean GitLab CE (Community Edition), the 
open-source self-hosted version of GitLab, not gitlab.com (which is 
GitLab Enterprise Edition). It doesn't have as many features as 
github.com, but it's been adopted by many related projects: GNOME, 
freedesktop.org, KDE, and Debian. Each of these projects had their own 
long and difficult search to determine which git forge would be best 
for them, and they all picked GitLab CE.

Michael

[Milan Crha]

On Wed, 2020-01-22 at 11:37 -0600, Michael Catanzaro wrote:
>  they all picked GitLab CE. 
	Hi,
I do not want to pollute this thread with unrelated information,
but for what it worth, I only recently realized that GitLab CE, the one
hosted on GNOME, does not have searching working properly. I filled a
bug upstream [1]. Being able to reliably search in issues is rather
essential function, from my point of view. I'm wondering how they can
search for anything when they've filled 10k+ issues.

Anyway, if you think this doesn't belong to this thread then I
apologize.
	Bye,
	Milan

[1] https://gitlab.com/gitlab-org/gitlab/issues/35611

[Neal Gompa]

On Wed, Jan 22, 2020 at 12:58 PM Milan Crha <mcrha(a)redhat.com&gt; wrote:
>  On Wed, 2020-01-22 at 11:37 -0600, Michael Catanzaro wrote:
>  > they all picked GitLab CE.
>
>          Hi,
>  I do not want to pollute this thread with unrelated information,
>  but for what it worth, I only recently realized that GitLab CE, the one
>  hosted on GNOME, does not have searching working properly. I filled a
>  bug upstream [1]. Being able to reliably search in issues is rather
>  essential function, from my point of view. I'm wondering how they can
>  search for anything when they've filled 10k+ issues.
>
>  Anyway, if you think this doesn't belong to this thread then I
>  apologize. 
Fulltext search in GitLab is an Enterprise Edition feature and
requires a separate deployment of ElasticSearch.



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

[Martin Kolman]

On Wed, 2020-01-22 at 13:28 -0500, Neal Gompa wrote:
>  On Wed, Jan 22, 2020 at 12:58 PM Milan Crha <mcrha(a)redhat.com&gt;
> wrote:
>  > On Wed, 2020-01-22 at 11:37 -0600, Michael Catanzaro wrote:
>  > > they all picked GitLab CE.
>  > 
>  >         Hi,
>  > I do not want to pollute this thread with unrelated information,
>  > but for what it worth, I only recently realized that GitLab CE, the one
>  > hosted on GNOME, does not have searching working properly. I filled a
>  > bug upstream [1]. Being able to reliably search in issues is rather
>  > essential function, from my point of view. I'm wondering how they can
>  > search for anything when they've filled 10k+ issues.
>  > 
>  > Anyway, if you think this doesn't belong to this thread then I
>  > apologize.
>  
>  Fulltext search in GitLab is an Enterprise Edition feature and
>  requires a separate deployment of ElasticSearch. 
Ouch - really ? :-(

Well, I guess that demonstrates quite nicely the dangers of open core projects right here
and there...
>  
>  
>  
>  -- 
>  真実はいつも一つ！/ 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]

[Stephen John Smoogen]

On Tue, 28 Jan 2020 at 12:17, Martin Kolman <mkolman(a)redhat.com&gt; wrote:
>  On Wed, 2020-01-22 at 13:28 -0500, Neal Gompa wrote:
>  > On Wed, Jan 22, 2020 at 12:58 PM Milan Crha <mcrha(a)redhat.com&gt; wrote:
>  > > On Wed, 2020-01-22 at 11:37 -0600, Michael Catanzaro wrote:
>  > > > they all picked GitLab CE.
>  > >
>  > >         Hi,
>  > > I do not want to pollute this thread with unrelated information,
>  > > but for what it worth, I only recently realized that GitLab CE, the one
>  > > hosted on GNOME, does not have searching working properly. I filled a
>  > > bug upstream [1]. Being able to reliably search in issues is rather
>  > > essential function, from my point of view. I'm wondering how they can
>  > > search for anything when they've filled 10k+ issues.
>  > >
>  > > Anyway, if you think this doesn't belong to this thread then I
>  > > apologize.
>  >
>  > Fulltext search in GitLab is an Enterprise Edition feature and
>  > requires a separate deployment of ElasticSearch.
>  Ouch - really ? :-(
>
>  Well, I guess that demonstrates quite nicely the dangers of open core projects right here
> and there... 
Well even if it wasn't opencore .. the search tools would still
require a lot of infrastructure to work. An allure of pagure has been
that it runs on 1 system front and back. To get the feature set that
people seem to want from gitlab would require about 6 to 18 systems
(the 'this is how it should be done if you want the minimum of dealing
with corner cases') with each sub-service adding on more systems for
its own cluster. You also find that you need to upgrade your hardware
to have 10 gigabit switches, fast storage, and other clustering tools
which were not budgeted for. Yes you can do it with less but you will
keep running into corner cases as you have more and more use-cases
from different developer groups. So you end up standing up a large set
of hardware and find yourself still focusing on running something
other than building software.

And that is the real allure of going to an outsourced software stack.
They deal with running things and fixing all the corner cases your
developers will find. [Whether those fixes actually ever occur is for
some future crisis.] You can then focus on the main job that you
started off on, regularly making an OS.



-- 
Stephen J Smoogen.

[Michael Catanzaro]

On Wed, Jan 22, 2020 at 11:37 am, Michael Catanzaro 
<mcatanzaro(a)gnome.org&gt; wrote:
>  It doesn't have as many features as github.com, 
Sorry, this was a typo. I meant: it doesn't have as many features as 
gitlab.com.

[Adam Saleh]

Way we were discussing this, I think there were several points I didn't
really see here.

a) we are gathering requirements for Git Forge, but we need a good Dist Git
as well.

There might be difference in requirements and tooling for Dist Git compared
to generic fully featured Git Forge.
It might still be useful to abandon Pagure as a full-featured git-forge and
instead focus on making it really useful as a dist-git solution.

b) Whatever we decide, there will be significant investment required.
Either by re-investing in our existing solution, or in the migration effort.

I think we really want to avoid the `Polarion` situation, where we wouldn't
be clear about all of the costs involved in migration, and end up with a
solution that only saved effort/money on paper,
and in reality it could cost many a man-day of
migration/maintenance/workaround efforts.

I am not yet sure how to make this less vague, and more "Gathering
requirements",
@Leigh Griffin <lgriffin(a)redhat.com&gt; will there be some sort of a poll in
the end, or how do we actually get a list of requirements?

I assume we are in the "Research" phase of ODF [1], but this is first time
I am interacting with the framework :-)

Adam

[1]
https://github.com/red-hat-people-team/open-decision-framework/blob/maste...



On Fri, Jan 24, 2020 at 4:56 PM Michael Catanzaro <mcatanzaro(a)gnome.org&gt;
wrote:

>  On Wed, Jan 22, 2020 at 11:37 am, Michael Catanzaro
>  <mcatanzaro(a)gnome.org&gt; wrote:
>  > It doesn't have as many features as github.com,
>
>  Sorry, this was a typo. I meant: it doesn't have as many features as
>  gitlab.com.
>
>  _______________________________________________
>  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, Jan 28, 2020, 15:58 Adam Saleh <asaleh(a)redhat.com&gt; wrote:

>  Way we were discussing this, I think there were several points I
> didn't
>  really see here.
>
>  a) we are gathering requirements for Git Forge, but we need a good Dist
>  Git as well.
>
>  There might be difference in requirements and tooling for Dist Git
>  compared to generic fully featured Git Forge.
>  It might still be useful to abandon Pagure as a full-featured git-forge
>  and instead focus on making it really useful as a dist-git solution.
>
>  b) Whatever we decide, there will be significant investment required.
>  Either by re-investing in our existing solution, or in the migration
>  effort.
>
>  I think we really want to avoid the `Polarion` situation, where we wouldn't
>  be clear about all of the costs involved in migration, and end up with a
>  solution that only saved effort/money on paper,
>  and in reality it could cost many a man-day of
>  migration/maintenance/workaround efforts.
>
>  I am not yet sure how to make this less vague, and more "Gathering
>  requirements",
>  @Leigh Griffin <lgriffin(a)redhat.com&gt; will there be some sort of a poll in
>  the end, or how do we actually get a list of requirements?
>  
This thread is serving as a source of requirements (although it has
meandered dramatically away from that) but I will default to the Fedora
Council for how a combined set from the input in this thread and others is
collated and presented. When all requirements are gathered from all
stakeholders I will share the distilled version out.

>  I assume we are in the "Research" phase of ODF [1], but this is first time
>  I am interacting with the framework :-)
>  
We are in that phase of getting requirements and analyzing them. Sorry on
my phone here so I can't be 100% sure of the formal phases off hand.

>  Adam
>
>  [1]
>
> https://github.com/red-hat-people-team/open-decision-framework/blob/maste...
>
>
>
>  On Fri, Jan 24, 2020 at 4:56 PM Michael Catanzaro <mcatanzaro(a)gnome.org&gt;
>  wrote:
>
> > On Wed, Jan 22, 2020 at 11:37 am, Michael Catanzaro
> > <mcatanzaro(a)gnome.org&gt; wrote:
> > > It doesn't have as many features as github.com,
> >
> > Sorry, this was a typo. I meant: it doesn't have as many features as
> > gitlab.com.
> >
> > _______________________________________________
> > 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]
>

[Iñaki Ucar]

On Tue, 28 Jan 2020 at 20:58, Leigh Griffin <lgriffin(a)redhat.com&gt; wrote:
>  This thread is serving as a source of requirements (although it has meandered
> dramatically away from that) 
When I first read the post, my thought was: wow, what a convoluted and
abstruse way of saying "we want to abandon Pagure". Probably this
wasn't your intent, but that's what I got. And given the reactions,
other people too.

Iñaki

[Leigh Griffin]

On Tue, Jan 28, 2020, 22:06 Iñaki Ucar <iucar(a)fedoraproject.org&gt; wrote:

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

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

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

[Iñaki Ucar]

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

1. Pagure does not align with CPE.
2. CPE is not gonna commit a development team to Pagure.
3. The feature gap is big and growing, and basically Pagure is gonna
die because of this (and the document goes on saying that you're not
trying to solve the feature gap).

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

>  If you (and others) elaborate on how you use Pagure (and other
> forges) and what you value from your day to day usage, we will take that on board and use
> it to drive our decision making. 
Asking for requirements for a *forge* is pointless. A forge doesn't
have requirements. What you do with a forge has requirements. As
others have already pointed out, Pagure is being used at the very
least for 3 distinct use cases: to maintain rpm packages, to maintain
upstream projects, and as an issue tracker. And they all have distinct
requirements. Only that, as it happens, Pagure has grown to cover
their necessities with more or less success, which doesn't necessarily
mean that a forge is the best solution for all of them (as, again,
others have pointed out already). But the ODF only lists forges as
solutions.

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

Iñaki

[Clement Verna]

On Wed, 29 Jan 2020 at 11:36, Iñaki Ucar <iucar(a)fedoraproject.org&gt; wrote:

>  On Wed, 29 Jan 2020 at 00:08, Leigh Griffin
> <lgriffin(a)redhat.com&gt; wrote:
>  >
>  > On Tue, Jan 28, 2020, 22:06 Iñaki Ucar <iucar(a)fedoraproject.org&gt; wrote:
>  >>
>  >> On Tue, 28 Jan 2020 at 20:58, Leigh Griffin <lgriffin(a)redhat.com&gt;
>  wrote:
>  >> >
>  >> > This thread is serving as a source of requirements (although it has
>  meandered dramatically away from that)
>  >>
>  >> When I first read the post, my thought was: wow, what a convoluted and
>  >> abstruse way of saying "we want to abandon Pagure". Probably this
>  >> wasn't your intent, but that's what I got. And given the reactions,
>  >> other people too.
>  >
>  > The linked blog to the ODF is very explicit that Pagure is one of the 3
>  forge options we are considering. I can't stress enough that it's a viable
>  choice and ultimately what we opt for will come down to an analysis driven
>  by the requirements gathered. I'm unsure how the blog has been interpreted
>  any other way but hopefully this clears it up.
>
>  The ODF is very explicit in the problem statement, and it specifically
>  and clearly says that:
>
>  1. Pagure does not align with CPE.
>  2. CPE is not gonna commit a development team to Pagure.
>  3. The feature gap is big and growing, and basically Pagure is gonna
>  die because of this (and the document goes on saying that you're not
>  trying to solve the feature gap).
>
>  Then the ODF lists Pagure as a solution. How am I supposed to
>  interpret the above?
>  
That the current situation is not ideal and before making any decisions it
is better to know exactly what are the use cases. It makes sense to keep
Pagure as a solution since we already know that it is matching most of
Fedora's needs, but Pagure has a few down side too and the main one is that
we have to develop and maintain it.  So while the current situation works,
it is not great. We might just find out that the other options are actually
worst, or not. To me that's the all point of this process, let's put down
what we *really* *really* need and  then look at the different options.

Also there are many possibilities, for example a group of people could step
up and take over the maintenance of Pagure so that CPE would just run the
instances, just like it is done with Koji. Or another distro, project could
be willing to use and contribute to Pagure so that we would share the
development and maintenance effort.  It is not forbidden to imagine such
possibilities :-)


>  > If you (and others) elaborate on how you use Pagure (and other forges)
>  and what you value from your day to day usage, we will take that on board
>  and use it to drive our decision making.
>
>  Asking for requirements for a *forge* is pointless. A forge doesn't
>  have requirements. What you do with a forge has requirements. 
As
>  others have already pointed out, Pagure is being used at the very
>  least for 3 distinct use cases: to maintain rpm packages, to maintain
>  upstream projects, and as an issue tracker. And they all have distinct
>  requirements. Only that, as it happens, Pagure has grown to cover
>  their necessities with more or less success, which doesn't necessarily
>  mean that a forge is the best solution for all of them (as, again,
>  others have pointed out already). But the ODF only lists forges as
>  solutions.
>
>  So solutions for what? What are we talking about here? Requirements
>  for src.fp.org? Requirements for things that are in pagure.io? All?
>  Other?
>  
My understanding is that we are looking at all use cases.


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

[Julen Landa Alustiza]

(snip)

20/1/29 14:49(e)an, Clement Verna igorleak idatzi zuen:
>  To me that's the all point of this 
>  process, let's put down what we *really* *really* need and  then look at 
>  the different options.
>   
Do we *really* *really* need to compete with other full featured git 
forges on features? The ODF says that this is one of the problem. Well, 
imo we don't *really* *really* need to compete with them.

Actually we already have the features that we *really* *really* need. 
Otherwise we could not release fedora using pagure as we are using, 
could we? :)

Regards,

[Pierre-Yves Chibon]

On Wed, Jan 29, 2020 at 03:22:25PM +0100, Julen Landa Alustiza wrote:
>  (snip)
>  
>  20/1/29 14:49(e)an, Clement Verna igorleak idatzi zuen:
>  >To me that's the all point of this process, let's put down what we
>  >*really* *really* need and  then look at the different options.
>  >
>  
>  Do we *really* *really* need to compete with other full featured git
>  forges on features? The ODF says that this is one of the problem.
>  Well, imo we don't *really* *really* need to compete with them.
>  
>  Actually we already have the features that we *really* *really*
>  need. Otherwise we could not release fedora using pagure as we are
>  using, could we? :) 
So let's revert the question, pagure does the what it needs to do and enough of
it, otherwise we would not be using it.

What does pagure miss that other solutions have and that could be considered a
requirement?

It could be that we don't **need** pagure to do anything more than what it does
today, which moves the discussion off a technical ground.


Pierre

[Neal Gompa]

On Wed, Jan 29, 2020 at 9:29 AM Pierre-Yves Chibon <pingou(a)pingoured.fr&gt; wrote:
>  On Wed, Jan 29, 2020 at 03:22:25PM +0100, Julen Landa Alustiza wrote:
>  > (snip)
>  >
>  > 20/1/29 14:49(e)an, Clement Verna igorleak idatzi zuen:
>  > >To me that's the all point of this process, let's put down what we
>  > >*really* *really* need and  then look at the different options.
>  > >
>  >
>  > Do we *really* *really* need to compete with other full featured git
>  > forges on features? The ODF says that this is one of the problem.
>  > Well, imo we don't *really* *really* need to compete with them.
>  >
>  > Actually we already have the features that we *really* *really*
>  > need. Otherwise we could not release fedora using pagure as we are
>  > using, could we? :)
>
>  So let's revert the question, pagure does the what it needs to do and enough of
>  it, otherwise we would not be using it.
>
>  What does pagure miss that other solutions have and that could be considered a
>  requirement?
>
>  It could be that we don't **need** pagure to do anything more than what it does
>  today, which moves the discussion off a technical ground.
>  
From a Dist-Git perspective, there is are two things I need:
* per-branch ACLs
* the ability to set bugzilla owners without granting commit access.

The first thing is because I get nervous granting people access to the
Git project who want to build EPEL8 packages but clearly aren't good
at managing Git workflows. I don't want them breaking my workflows
with Fedora packages.

The second thing is because there are a number of packages that I
maintain where upstream would like to be notified on bugzilla bugs but
not otherwise be involved in packaging. Pagure itself has the ticket
ACL for this, but I don't think this does anything in the Dist-Git
setup.

From the Git forge perspective, the two big things I need are:
* working self-service CI
* workflow for self-service integration management per-user and per-repo

The first item is because the current Pagure CI with CentOS CI Jenkins
is inexcusably bad. Jenkins is often unresponsive and broken, and
configuring it requires manual intervention from the CentOS CI folks.
Part of the reason we have Pagure was to move to more of a
self-service model, and our default offering for CI services fails at
that.

The second item is because there are an array of third party Free
Software services out there that people should be able to use without
having to talk to the Pagure admin to activate or enable. We do have
webhooks for basic integrations, but doing authentication and
authorization flows for generating app tokens and such is something we
don't have today. Having this would allow far more sophisticated
integrations than what we have now without always having to involve an
admin over it.


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

[Pierre-Yves Chibon]

On Wed, Jan 29, 2020 at 09:37:36AM -0500, Neal Gompa wrote:
>  On Wed, Jan 29, 2020 at 9:29 AM Pierre-Yves Chibon
> <pingou(a)pingoured.fr&gt; wrote:
>  >
>  > On Wed, Jan 29, 2020 at 03:22:25PM +0100, Julen Landa Alustiza wrote:
>  > > (snip)
>  > >
>  > > 20/1/29 14:49(e)an, Clement Verna igorleak idatzi zuen:
>  > > >To me that's the all point of this process, let's put down what we
>  > > >*really* *really* need and  then look at the different options.
>  > > >
>  > >
>  > > Do we *really* *really* need to compete with other full featured git
>  > > forges on features? The ODF says that this is one of the problem.
>  > > Well, imo we don't *really* *really* need to compete with them.
>  > >
>  > > Actually we already have the features that we *really* *really*
>  > > need. Otherwise we could not release fedora using pagure as we are
>  > > using, could we? :)
>  >
>  > So let's revert the question, pagure does the what it needs to do and enough of
>  > it, otherwise we would not be using it.
>  >
>  > What does pagure miss that other solutions have and that could be considered a
>  > requirement?
>  >
>  > It could be that we don't **need** pagure to do anything more than what it does
>  > today, which moves the discussion off a technical ground.
>  >
>  
>  From a Dist-Git perspective, there is are two things I need:
>  * per-branch ACLs
>  * the ability to set bugzilla owners without granting commit access.
>  
>  The first thing is because I get nervous granting people access to the
>  Git project who want to build EPEL8 packages but clearly aren't good
>  at managing Git workflows. I don't want them breaking my workflows
>  with Fedora packages.
>  
>  The second thing is because there are a number of packages that I
>  maintain where upstream would like to be notified on bugzilla bugs but
>  not otherwise be involved in packaging. Pagure itself has the ticket
>  ACL for this, but I don't think this does anything in the Dist-Git
>  setup. 
If they have a FAS account, they can go to dist-git: Watch issues on the package
and they will be added to the CC list on bugzilla.


We are working on moving off the bugzilla overrides from the scm-requests git
repo into pagure, like we did for the anitya integration.


Pierre

[Julen Landa Alustiza]

Per git ref acls is not a common thing on git forges. If this is a final requirement, we
should start analyzing the viability of implementing and maintain it on the different
forges (and it should be feasible with all of the rest of our strange ACLs on dist-git)

On pagure side, now that our downstream instances are not using gitolite, implementing
them needs much less work that migrating all our toolings to other solutions.

2020(e)ko urtarrilaren 29(a) 15:37:36 (CET)-(e)an, Neal Gompa
<ngompa13(a)gmail.com&gt;-(e)k hau idatzi zuen:
> On Wed, Jan 29, 2020 at 9:29 AM Pierre-Yves Chibon
> <pingou(a)pingoured.fr&gt; wrote:
> >
> > On Wed, Jan 29, 2020 at 03:22:25PM +0100, Julen Landa Alustiza wrote:
> > > (snip)
> > >
> > > 20/1/29 14:49(e)an, Clement Verna igorleak idatzi zuen:
> > > >To me that's the all point of this process, let's put down what we
> > > >*really* *really* need and  then look at the different options.
> > > >
> > >
> > > Do we *really* *really* need to compete with other full featured
> git
> > > forges on features? The ODF says that this is one of the problem.
> > > Well, imo we don't *really* *really* need to compete with them.
> > >
> > > Actually we already have the features that we *really* *really*
> > > need. Otherwise we could not release fedora using pagure as we are
> > > using, could we? :)
> >
> > So let's revert the question, pagure does the what it needs to do and
> enough of
> > it, otherwise we would not be using it.
> >
> > What does pagure miss that other solutions have and that could be
> considered a
> > requirement?
> >
> > It could be that we don't **need** pagure to do anything more than
> what it does
> > today, which moves the discussion off a technical ground.
> >
>
> From a Dist-Git perspective, there is are two things I need:
> * per-branch ACLs
> * the ability to set bugzilla owners without granting commit access.
>
> The first thing is because I get nervous granting people access to the
> Git project who want to build EPEL8 packages but clearly aren't good
> at managing Git workflows. I don't want them breaking my workflows
> with Fedora packages.
>
> The second thing is because there are a number of packages that I
> maintain where upstream would like to be notified on bugzilla bugs but
> not otherwise be involved in packaging. Pagure itself has the ticket
> ACL for this, but I don't think this does anything in the Dist-Git
> setup.
>
> From the Git forge perspective, the two big things I need are:
> * working self-service CI
> * workflow for self-service integration management per-user and
> per-repo
>
> The first item is because the current Pagure CI with CentOS CI Jenkins
> is inexcusably bad. Jenkins is often unresponsive and broken, and
> configuring it requires manual intervention from the CentOS CI folks.
> Part of the reason we have Pagure was to move to more of a
> self-service model, and our default offering for CI services fails at
> that.
>
> The second item is because there are an array of third party Free
> Software services out there that people should be able to use without
> having to talk to the Pagure admin to activate or enable. We do have
> webhooks for basic integrations, but doing authentication and
> authorization flows for generating app tokens and such is something we
> don't have today. Having this would allow far more sophisticated
> integrations than what we have now without always having to involve an
> admin over it.
>
>
> -- 
> 真実はいつも一つ！/ 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] 
--
Julen Landa Alustiza <jlanda(a)fedoraproject.org&gt;

[Pierre-Yves Chibon]

On Wed, Jan 29, 2020 at 04:06:22PM +0100, Julen Landa Alustiza wrote:
>     Per git ref acls is not a common thing on git forges. If this is a
> final
>     requirement, we should start analyzing the viability of implementing and
>     maintain it on the different forges (and it should be feasible with all of
>     the rest of our strange ACLs on dist-git)
>  
>     On pagure side, now that our downstream instances are not using gitolite,
>     implementing them needs much less work that migrating all our toolings to
>     other solutions. 
I believe, and Leigh correct me if I'm wrong, that this will be the next step in
the analysis.

1/ gather all the requirement
2/ figure out which option have which requirement
3/ figure out if it is "cheaper" to fix feature A in option 2, or add feature B
in option 3 or leave without feature C in option 1

Pierre

[Leigh Griffin]

On Wed, Jan 29, 2020 at 3:30 PM Pierre-Yves Chibon <pingou(a)pingoured.fr&gt;
wrote:

>  On Wed, Jan 29, 2020 at 04:06:22PM +0100, Julen Landa Alustiza
> wrote:
>  >    Per git ref acls is not a common thing on git forges. If this is a
>  final
>  >    requirement, we should start analyzing the viability of implementing
>  and
>  >    maintain it on the different forges (and it should be feasible with
>  all of
>  >    the rest of our strange ACLs on dist-git)
>  >
>  >    On pagure side, now that our downstream instances are not using
>  gitolite,
>  >    implementing them needs much less work that migrating all our
>  toolings to
>  >    other solutions.
>
>  I believe, and Leigh correct me if I'm wrong, that this will be the next
>  step in
>  the analysis.
>
>  1/ gather all the requirement
>  2/ figure out which option have which requirement
>  3/ figure out if it is "cheaper" to fix feature A in option 2, or add
>  feature B
>  in option 3 or leave without feature C in option 1
>  
Correct we will perform an analysis on the requirements Vs the offerings.
It then becomes a cost benefit analysis to build out (or acquire) feature A
at the cost of refactoring process B and so on. We will publish the wider
requirements and the analysis to help support a transparent decision.


>  Pierre
>  _______________________________________________
>  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 Wed, Jan 29, 2020 at 10:07 AM Julen Landa Alustiza
<jlanda(a)fedoraproject.org&gt; wrote:
>  Per git ref acls is not a common thing on git forges. If this is a final requirement, we
> should start analyzing the viability of implementing and maintain it on the different
> forges (and it should be feasible with all of the rest of our strange ACLs on dist-git)
>
>  On pagure side, now that our downstream instances are not using gitolite, implementing
> them needs much less work that migrating all our toolings to other solutions.
>  
It's usually called "branch protection" in GitHub and GitLab. The
functionality varies a bit, but the feature exists.

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

[Florian Weimer]

* Neal Gompa:

>  On Wed, Jan 29, 2020 at 10:07 AM Julen Landa Alustiza
>  <jlanda(a)fedoraproject.org&gt; wrote:
> >
> > Per git ref acls is not a common thing on git forges. If this is a final requirement,
> we should start analyzing the viability of implementing and maintain it on the different
> forges (and it should be feasible with all of the rest of our strange ACLs on dist-git)
> >
> > On pagure side, now that our downstream instances are not using gitolite,
> implementing them needs much less work that migrating all our toolings to other
> solutions.
> >
>
>  It's usually called "branch protection" in GitHub and GitLab. The
>  functionality varies a bit, but the feature exists. 
It's also sometimes enforced externally by bots which only perform
merges if they are requested by authorized developers (and nobody
updates refs directly under this model).

Thanks,
Florian

[Clement Verna]

On Wed, Jan 29, 2020, 15:23 Julen Landa Alustiza <jlanda(a)fedoraproject.org&gt;
wrote:

>  (snip)
>
>  20/1/29 14:49(e)an, Clement Verna igorleak idatzi zuen:
>  > To me that's the all point of this
>  > process, let's put down what we *really* *really* need and  then look at
>  > the different options.
>  >
>
>  Do we *really* *really* need to compete with other full featured git
>  forges on features? The ODF says that this is one of the problem. Well,
>  imo we don't *really* *really* need to compete with them.
>  
It depends on the use case, doing development work projects hosted on
pagure.io is not great in my opinion. In particular working with pull
requests.

In terms of issue trackers, it is missing the ability to visualize issues
in a board for example.
Again this my opinion and maybe these are maybe not *really* *really*
needed.


>  Actually we already have the features that we *really* *really*
> need.
>  Otherwise we could not release fedora using pagure as we are using,
>  could we? :)
>  
I personally don't think we can release Fedora without people across the
project doing heroics and a crazy amount of hours which seems to have
become a norm rather than an exception.



>  Regards,
>  _______________________________________________
>  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]
>

[Pierre-Yves Chibon]

On Wed, Jan 29, 2020 at 03:56:08PM +0100, Clement Verna wrote:
>     On Wed, Jan 29, 2020, 15:23 Julen Landa Alustiza
>     <jlanda(a)fedoraproject.org&gt; wrote:
>  
>       (snip)
>  
>       20/1/29 14:49(e)an, Clement Verna igorleak idatzi zuen:
>       > To me that's the all point of this
>       > process, let's put down what we *really* *really* need and  then look
>       at
>       > the different options.
>       >
>  
>       Do we *really* *really* need to compete with other full featured git
>       forges on features? The ODF says that this is one of the problem. Well,
>       imo we don't *really* *really* need to compete with them.
>  
>     It depends on the use case, doing development work projects hosted on
>     pagure.io is not great in my opinion. In particular working with pull
>     requests.
>     In terms of issue trackers, it is missing the ability to visualize issues
>     in a board for example. 
>     Again this my opinion and maybe these are maybe not *really* *really*
>     needed.
>  
>       Actually we already have the features that we *really* *really* need.
>       Otherwise we could not release fedora using pagure as we are using,
>       could we? :)
>  
>     I personally don't think we can release Fedora without people across the
>     project doing heroics and a crazy amount of hours which seems to have
>     become a norm rather than an exception.  
I don't think anyone can disagree with this, but this begs the question: are
these heroics related to pagure?
If not, I'm not sure what is the point you were trying to make for this thread.


Pierre

[Clement Verna]

On Wed, 29 Jan 2020 at 16:18, Pierre-Yves Chibon <pingou(a)pingoured.fr
>  
wrote:

>  On Wed, Jan 29, 2020 at 03:56:08PM +0100, Clement Verna wrote:
>  >    On Wed, Jan 29, 2020, 15:23 Julen Landa Alustiza
>  >    <jlanda(a)fedoraproject.org&gt; wrote:
> >  
>  >      (snip)
> >  
>  >      20/1/29 14:49(e)an, Clement Verna igorleak idatzi
> zuen:
>  >      > To me that's the all point of this
>  >      > process, let's put down what we *really* *really* need and  then
>  look
>  >      at
>  >      > the different options.
>  >
> >  
> >  
>  >    
>  Do we *really* *really* need to compete with other full featured git
>  >      forges on features? The ODF says that this is one of the problem.
>  Well,
>  >      imo we don't *really* *really* need to compete with them.
> >  
>  >    It depends on the use case, doing development work
> projects hosted on
>  >    pagure.io is not great in my opinion. In particular working with
>  pull
>  >    requests.
>  >    In terms of issue trackers, it is missing the ability to visualize
>  issues
>  >    in a board for example.Â
>  >    Again this my opinion and maybe these are maybe not *really* *really*
>  >    needed.
> >  
>  >      Actually we already have the features that we
> *really* *really*
>  need.
>  >      Otherwise we could not release fedora using pagure as we are using,
>  >      could we? :)
> >  
>  >    I personally don't think we can release Fedora
> without people across
>  the
>  >    project doing heroics and a crazy amount of hours which seems to have
>  >    become a norm rather than an exception.Â
>
>  I don't think anyone can disagree with this, but this begs the question:
>  are 
these heroics related to pagure?
>  
If not, I'm not sure what is the point you were trying to
make for this
> thread.
>  
My point is that we have to dedicate a team to work on Pagure, I would
rather have these people working on improving the infrastructure so that we
don't need these heroics to happen. If we don't put people to work on
Pagure it will end up being another fedora-packages, badges or FAS and in
couple years it will be too difficult to do anything with it. It is not
only about Pagure, for example I would love to be able to replace Bodhi
with something that we don't have to maintain but it is much more difficult
to find an alternative to Bodhi than Pagure.

My general feeling is that an infrastructure team should avoid as much as
possible to maintain large applications, the focus should be to develop the
glue needed to for the different services to work together in the most
efficient manner, to monitor the applications, the respond to outages.

Does that clarify my thoughts ?


>  
> Pierre
> _______________________________________________
> 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]
>

[Stephen John Smoogen]

On Wed, 29 Jan 2020 at 11:38, Clement Verna <cverna(a)fedoraproject.org&gt; wrote:
>  On Wed, 29 Jan 2020 at 16:18, Pierre-Yves Chibon <pingou(a)pingoured.fr&gt; wrote:
> > 
> > these heroics related to pagure?
> >
> > If not, I'm not sure what is the point you were trying to make for this thread.
>
>
>  My point is that we have to dedicate a team to work on Pagure, I would rather have these
> people working on improving the infrastructure so that we don't need these heroics to
> happen. If we don't put people to work on Pagure it will end up being another
> fedora-packages, badges or FAS and in couple years it will be too difficult to do anything
> with it. It is not only about Pagure, for example I would love to be able to replace Bodhi
> with something that we don't have to maintain but it is much more difficult to find an
> alternative to Bodhi than Pagure.
>  
We would instead need a dedicated team to work on integrating all our
tools with some other dist-git. Either using the people who are
already working on pagure, or some new set of people who have to be
hired in with a background in how-ever Git*** works. There will still
always be some group having to deal with how and what we do with our
source code. All we are doing is changing it from something we have
more control to direct to something we constantly adapt to its
changes. In other words, the heroics just change because we have
worked on a symptom for the cause of the heroics.. not the root cause
of the heroics.


>  My general feeling is that an infrastructure team should avoid as
> much as possible to maintain large applications, the focus should be to develop the glue
> needed to for the different services to work together in the most efficient manner, to
> monitor the applications, the respond to outages. 
The issue is that we are not going to see less work here and so there
is not going to be less heroics. Some group is going to have to make
tooling changes to make fedpkg, bodhi, koji, pdc, authentication etc
etc work with Git*** and keep up with every API change that occurs
over the years there. Some group is going to have to engineer new
caching layers to deal with source code in XYZ area and builders in
ABC area. Some group is going to have to add in all the documentation
and rules for dealing with any outage/burp/authentication Git***.

This doesn't mean that work should not be done.. but do not try to
sell it that it will drop the need for heroics and long hours. That
needs different changes and have nothing to do whether we have our
source code in Pagure or Gitlab. It has nothing to do with whether we
use OBS or Koji. It has to do with things much more fundamental about
what we are supposed to be doing, what we are supposed to not be
doing, and how much we are supposed to do towards either set. Trying
to lop off things one by one while we are adding in things 2x2 doesn't
help.



-- 
Stephen J Smoogen.

[Clement Verna]

On Wed, 29 Jan 2020 at 18:26, Stephen John Smoogen <smooge(a)gmail.com&gt; wrote:

>  On Wed, 29 Jan 2020 at 11:38, Clement Verna
> <cverna(a)fedoraproject.org&gt;
>  wrote:
>  >
>  >
>  >
>  > On Wed, 29 Jan 2020 at 16:18, Pierre-Yves Chibon <pingou(a)pingoured.fr&gt;
>  wrote:
>  >>
>
>  >> these heroics related to pagure?
>  >>
>  >> If not, I'm not sure what is the point you were trying to make for this
>  thread.
>  >
>  >
>  > My point is that we have to dedicate a team to work on Pagure, I would
>  rather have these people working on improving the infrastructure so that we
>  don't need these heroics to happen. If we don't put people to work on
>  Pagure it will end up being another fedora-packages, badges or FAS and in
>  couple years it will be too difficult to do anything with it. It is not
>  only about Pagure, for example I would love to be able to replace Bodhi
>  with something that we don't have to maintain but it is much more difficult
>  to find an alternative to Bodhi than Pagure.
>  >
>
>  We would instead need a dedicated team to work on integrating all our
>  tools with some other dist-git. Either using the people who are
>  already working on pagure, or some new set of people who have to be
>  hired in with a background in how-ever Git*** works. There will still
>  always be some group having to deal with how and what we do with our
>  source code. All we are doing is changing it from something we have
>  more control to direct to something we constantly adapt to its
>  changes. In other words, the heroics just change because we have
>  worked on a symptom for the cause of the heroics.. not the root cause
>  of the heroics.
>  
I completely agree that changing solution would be a massive effort and I
honestly don't know if it is worth it or not. In my opinion the root cause
of the heroics is that we keep adding and building new things on top of
foundation that is not stable. One of the reason for this foundation not
been stable is that we have too much to do, so we cut corners (the famous
quick fixes which becomes a permanent hack that everyone is scared to
touch). We cannot win this battle without reducing the number of things we
have to care for. Maybe I am too naive but for me the only way to reduce
these heroics is first to reduce the number of applications we have, second
take the time it takes to reduce the technical debt we have.

You have way more history and knowledge than me, so I am genuinely
interested to know what are the root cause for you ? And what would it take
to improve the situation ?


>  > My general feeling is that an infrastructure team should avoid as much
>  as possible to maintain large applications, the focus should be to develop
>  the glue needed to for the different services to work together in the most
>  efficient manner, to monitor the applications, the respond to outages.
>
>  The issue is that we are not going to see less work here and so there
>  is not going to be less heroics. Some group is going to have to make
>  tooling changes to make fedpkg, bodhi, koji, pdc, authentication etc
>  etc work with Git*** and keep up with every API change that occurs
>  over the years there. 

This assumes that Pagure will never break its API compatibility and that we
will never have to update all the different tools in that case. For me the
effort is the same here maybe even less for Git*** since we would most
likely use an library wrapping the API which could deal with the backward
compatibility.


>  Some group is going to have to engineer new
>  caching layers to deal with source code in XYZ area and builders in
>  ABC area. Some group is going to have to add in all the documentation
>  and rules for dealing with any outage/burp/authentication Git***.
>
>  This doesn't mean that work should not be done.. but do not try to
>  sell it that it will drop the need for heroics and long hours. That
>  needs different changes and have nothing to do whether we have our
>  source code in Pagure or Gitlab. It has nothing to do with whether we
>  use OBS or Koji. It has to do with things much more fundamental about
>  what we are supposed to be doing, what we are supposed to not be
>  doing, and how much we are supposed to do towards either set. Trying
>  to lop off things one by one while we are adding in things 2x2 doesn't
>  help.
>  
I agree that this will probably not make a huge difference, but I am an
optimistic and I prefer to take one tiny step in one direction without
knowing if it will make a difference rather than stay still waiting for
selling to fall on my head. "When eating an elephant, take one bite at a
time.” - Creighton Abrams

What are the different changes needed to avoid heroics ? What stops us from
making these ?


>  --
>  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 29. 01. 20 v 17:37 Clement Verna napsal(a):
>  On Wed, 29 Jan 2020 at 16:18, Pierre-Yves Chibon <pingou(a)pingoured.fr
>  <mailto:[e-mail]>> wrote:
>
>      On Wed, Jan 29, 2020 at 03:56:08PM +0100, Clement Verna wrote:
>      >    On Wed, Jan 29, 2020, 15:23 Julen Landa Alustiza
>      >    <jlanda(a)fedoraproject.org <mailto:[e-mail]>>
>      wrote:
>      >
>      >      (snip)
>      >
>      >      20/1/29 14:49(e)an, Clement Verna igorleak idatzi zuen:
>      >      > To me that's the all point of this
>      >      > process, let's put down what we *really* *really* need
>      and  then look
>      >      at
>      >      > the different options.
>      >      >
>      >
>      >      Do we *really* *really* need to compete with other full
>      featured git
>      >      forges on features? The ODF says that this is one of the
>      problem. Well,
>      >      imo we don't *really* *really* need to compete with them.
>      >
>      >    It depends on the use case, doing development work projects
>      hosted on
>      >    pagure.io <http://pagure.io> is not great in my opinion. In
>      particular working with pull
>      >    requests.
>      >    In terms of issue trackers, it is missing the ability to
>      visualize issues
>      >    in a board for example. 
>      >    Again this my opinion and maybe these are maybe not *really*
>      *really*
>      >    needed.
>      >
>      >      Actually we already have the features that we *really*
>      *really* need.
>      >      Otherwise we could not release fedora using pagure as we
>      are using,
>      >      could we? :)
>      >
>      >    I personally don't think we can release Fedora without people
>      across the
>      >    project doing heroics and a crazy amount of hours which seems
>      to have
>      >    become a norm rather than an exception. 
>
>      I don't think anyone can disagree with this, but this begs the
>      question: are 
>
>      these heroics related to pagure?
>
>      If not, I'm not sure what is the point you were trying to make for
>      this thread.
>
>
>  My point is that we have to dedicate a team to work on Pagure, I would
>  rather have these people working on improving the infrastructure so
>  that we don't need these heroics to happen. If we don't put people to
>  work on Pagure it will end up being another fedora-packages, badges or
>  FAS and in couple years it will be too difficult to do anything with
>  it. It is not only about Pagure, for example I would love to be able
>  to replace Bodhi with something that we don't have to maintain but it
>  is much more difficult to find an alternative to Bodhi 

cough cough errata cough cough

Honestly, sometimes the disconnect between what is going on in Fedora
and internally in Red Hat is intriguing.


Vít


>  than Pagure.
>
>  My general feeling is that an infrastructure team should avoid as much
>  as possible to maintain large applications, the focus should be to
>  develop the glue needed to for the different services to work together
>  in the most efficient manner, to monitor the applications, the respond
>  to outages.
>
>  Does that clarify my thoughts ?
>
>
>
>      Pierre
>      _______________________________________________
>      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]

[Adam Williamson]

On Thu, 2020-01-30 at 10:30 +0100, Vít Ondruch wrote:
>  
>  > My point is that we have to dedicate a team to work on Pagure, I would
>  > rather have these people working on improving the infrastructure so
>  > that we don't need these heroics to happen. If we don't put people to
>  > work on Pagure it will end up being another fedora-packages, badges or
>  > FAS and in couple years it will be too difficult to do anything with
>  > it. It is not only about Pagure, for example I would love to be able
>  > to replace Bodhi with something that we don't have to maintain but it
>  > is much more difficult to find an alternative to Bodhi
>  
>  cough cough errata cough cough
>  
>  Honestly, sometimes the disconnect between what is going on in Fedora
>  and internally in Red Hat is intriguing. 
Do you really think the entire CPE team is blissfully unaware of Errata
Tool's existence? I mean, is that really the scenario that makes the
most sense in your head, as opposed to 'they have already considered it
but don't find it a suitable replacement'?

You might ask 'why not errata
tool?', but it seems pretty silly to just assume that they don't even
know it exists, or something.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Vít Ondruch]

Dne 30. 01. 20 v 18:45 Adam Williamson napsal(a):
>  On Thu, 2020-01-30 at 10:30 +0100, Vít Ondruch wrote:
> >> My point is that we have to dedicate a team to work on Pagure, I would
> >> rather have these people working on improving the infrastructure so
> >> that we don't need these heroics to happen. If we don't put people to
> >> work on Pagure it will end up being another fedora-packages, badges or
> >> FAS and in couple years it will be too difficult to do anything with
> >> it. It is not only about Pagure, for example I would love to be able
> >> to replace Bodhi with something that we don't have to maintain but it
> >> is much more difficult to find an alternative to Bodhi
> > cough cough errata cough cough
> >
> > Honestly, sometimes the disconnect between what is going on in Fedora
> > and internally in Red Hat is intriguing.
>  Do you really think the entire CPE team is blissfully unaware of Errata
>  Tool's existence? 

I have never say that. I merely pointed out that there is disconnect
between what Fedora does and what Red Hat does internally. I see a lot
of duplication and I see a lot of lost opportunities. Bodhi vs Errata is
just one example.

The other example is that Red Hat adopted Pagure internally, so if CPE
decides to let Pagure go, that decision will impact Red Hat as well and
it somehow seems to be completely fine by everybody. If there was one
person fulltime coordinating Pagure upstream, we would save a lot of
time which was already wasted here by this discussion and we would save
all the costs of possible future migration where there will be suddenly
helping whole teams just to let later the whole migration project in
unfinished state and slowly dying.

And the another thread about Java packaging is of similar nature (not
going to details here).


Vít


>   I mean, is that really the scenario that makes the
>  most sense in your head, as opposed to 'they have already considered it
>  but don't find it a suitable replacement'?
>
>  You might ask 'why not errata
>  tool?', but it seems pretty silly to just assume that they don't even
>  know it exists, or something.

[Randy Barlow]

On Thu, 2020-01-30 at 10:30 +0100, Vít Ondruch wrote:
>  cough cough errata cough cough
>  
>  Honestly, sometimes the disconnect between what is going on in Fedora
>  and internally in Red Hat is intriguing. 
I did think about Errata tool* a bit back when I worked on Bodhi. I
like the idea of sharing code on one hand, but on the other hand it is
pretty oriented towards workflows that are designed for a product
release cycle. Bodhi is designed around community feedback (and now CI
feedback).

It could be interesting to hold a chat with the Errata tool developers
to see if there is interest in sharing tooling, but it may be a lot of
effort to make Errata tool flexible enough to support two pretty
different workflows. I'd be willing to have that conversation; I could
be wrong.


* Red Hat uses a project called Errata tool to publish updates.

[Neal Gompa]

On Thu, Jan 30, 2020 at 6:51 PM Randy Barlow
<bowlofeggs(a)fedoraproject.org&gt; wrote:
>  On Thu, 2020-01-30 at 10:30 +0100, Vít Ondruch wrote:
>  > cough cough errata cough cough
>  >
>  > Honestly, sometimes the disconnect between what is going on in Fedora
>  > and internally in Red Hat is intriguing.
>
>  I did think about Errata tool* a bit back when I worked on Bodhi. I
>  like the idea of sharing code on one hand, but on the other hand it is
>  pretty oriented towards workflows that are designed for a product
>  release cycle. Bodhi is designed around community feedback (and now CI
>  feedback).
>
>  It could be interesting to hold a chat with the Errata tool developers
>  to see if there is interest in sharing tooling, but it may be a lot of
>  effort to make Errata tool flexible enough to support two pretty
>  different workflows. I'd be willing to have that conversation; I could
>  be wrong.
>  
Why not go the other way? Bodhi could be extended to support the
internal product workflows.



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

[Vít Ondruch]

Dne 31. 01. 20 v 1:43 Neal Gompa napsal(a):
>  On Thu, Jan 30, 2020 at 6:51 PM Randy Barlow
>  <bowlofeggs(a)fedoraproject.org&gt; wrote:
> > On Thu, 2020-01-30 at 10:30 +0100, Vít Ondruch wrote:
> >> cough cough errata cough cough
> >>
> >> Honestly, sometimes the disconnect between what is going on in Fedora
> >> and internally in Red Hat is intriguing.
> > I did think about Errata tool* a bit back when I worked on Bodhi. 

Thank you for that.


> >  I
> > like the idea of sharing code on one hand, but on the other hand it is
> > pretty oriented towards workflows that are designed for a product
> > release cycle. Bodhi is designed around community feedback (and now CI
> > feedback).
> >
> > It could be interesting to hold a chat with the Errata tool developers
> > to see if there is interest in sharing tooling, but it may be a lot of
> > effort to make Errata tool flexible enough to support two pretty
> > different workflows. I'd be willing to have that conversation; I could
> > be wrong.
> > 
Of course, there is a lot of business logic specific to Red Hat projects
backed into Errata, but ultimately, it does not help to anybody if
Fedora release process is using different tools then Red Hat internally.
What Red Hat does internally should be just extension to what Fedora
does. The processes used internally should be proven in Fedora first.


>  Why not go the other way? Bodhi could be extended to support the
>  internal product workflows.
>
>
>  
In ideal world, Bodhi would be upstream project to Errata or possibly
Bodhi could be the open core of Errata. It does not really matter.


Vít

[Michal Konecny]

On 31/01/2020 12:11, Vít Ondruch wrote:
>  Dne 31. 01. 20 v 1:43 Neal Gompa napsal(a):
> > On Thu, Jan 30, 2020 at 6:51 PM Randy Barlow
> > <bowlofeggs(a)fedoraproject.org&gt; wrote:
> >> On Thu, 2020-01-30 at 10:30 +0100, Vít Ondruch wrote:
> >>> cough cough errata cough cough
> >>>
> >>> Honestly, sometimes the disconnect between what is going on in Fedora
> >>> and internally in Red Hat is intriguing.
> >> I did think about Errata tool* a bit back when I worked on Bodhi.
>
>  Thank you for that.
>
>
> >>   I
> >> like the idea of sharing code on one hand, but on the other hand it is
> >> pretty oriented towards workflows that are designed for a product
> >> release cycle. Bodhi is designed around community feedback (and now CI
> >> feedback).
> >>
> >> It could be interesting to hold a chat with the Errata tool developers
> >> to see if there is interest in sharing tooling, but it may be a lot of
> >> effort to make Errata tool flexible enough to support two pretty
> >> different workflows. I'd be willing to have that conversation; I could
> >> be wrong.
> >>
>  Of course, there is a lot of business logic specific to Red Hat projects
>  backed into Errata, but ultimately, it does not help to anybody if
>  Fedora release process is using different tools then Red Hat internally.
>  What Red Hat does internally should be just extension to what Fedora
>  does. The processes used internally should be proven in Fedora first. 
This is a
very nice vision that will potentially make life of Red Hat 
and Fedora much easier. I'm not that long in the Fedora project to know, 
why Fedora and Red Hat internal tools are that different, but this idea 
doesn't sound that bad. Few questions first:
Are those internal tools open source?
Could we as Fedora community use them?
Is there any legal issue?
Is this tool in good shape?

And talking about the git forge, what is Red Hat using internally as git 
forge? And then the above questions applies.

Michal
> > Why not go the other way? Bodhi could be extended to support the
> > internal product workflows.
> >
> >
> >
>  In ideal world, Bodhi would be upstream project to Errata or possibly
>  Bodhi could be the open core of Errata. It does not really matter.
>
>
>  Vít
>
>  _______________________________________________
>  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, Jan 31, 2020 at 10:23 AM Michal Konecny <mkonecny(a)redhat.com&gt; wrote:
>  On 31/01/2020 12:11, Vít Ondruch wrote:
>  > Dne 31. 01. 20 v 1:43 Neal Gompa napsal(a):
>  >> On Thu, Jan 30, 2020 at 6:51 PM Randy Barlow
>  >> <bowlofeggs(a)fedoraproject.org&gt; wrote:
>  >>> On Thu, 2020-01-30 at 10:30 +0100, Vít Ondruch wrote:
>  >>>> cough cough errata cough cough
>  >>>>
>  >>>> Honestly, sometimes the disconnect between what is going on in Fedora
>  >>>> and internally in Red Hat is intriguing.
>  >>> I did think about Errata tool* a bit back when I worked on Bodhi.
>  >
>  > Thank you for that.
>  >
>  >
>  >>>   I
>  >>> like the idea of sharing code on one hand, but on the other hand it is
>  >>> pretty oriented towards workflows that are designed for a product
>  >>> release cycle. Bodhi is designed around community feedback (and now CI
>  >>> feedback).
>  >>>
>  >>> It could be interesting to hold a chat with the Errata tool developers
>  >>> to see if there is interest in sharing tooling, but it may be a lot of
>  >>> effort to make Errata tool flexible enough to support two pretty
>  >>> different workflows. I'd be willing to have that conversation; I could
>  >>> be wrong.
>  >>>
>  > Of course, there is a lot of business logic specific to Red Hat projects
>  > backed into Errata, but ultimately, it does not help to anybody if
>  > Fedora release process is using different tools then Red Hat internally.
>  > What Red Hat does internally should be just extension to what Fedora
>  > does. The processes used internally should be proven in Fedora first.
>  This is a very nice vision that will potentially make life of Red Hat
>  and Fedora much easier. I'm not that long in the Fedora project to know,
>  why Fedora and Red Hat internal tools are that different, but this idea
>  doesn't sound that bad. Few questions first:
>  Are those internal tools open source?
>  Could we as Fedora community use them?
>  Is there any legal issue?
>  Is this tool in good shape?
>
>  And talking about the git forge, what is Red Hat using internally as git
>  forge? And then the above questions applies.
>  
It was mentioned in a different part of this thread that Red Hat is
using pagure internally.


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

[Robbie Harwood]

Neal Gompa <ngompa13(a)gmail.com&gt; writes:

>  Michal Konecny <mkonecny(a)redhat.com&gt; wrote:
> > Vít Ondruch wrote:
> >> Neal Gompa napsal(a):
> >>> Randy Barlow <bowlofeggs(a)fedoraproject.org&gt; wrote:
> >>>> Vít Ondruch wrote:
> >>>>
> >>>>> cough cough errata cough cough
> >>>>>
> >>>>> Honestly, sometimes the disconnect between what is going on in
> >>>>> Fedora and internally in Red Hat is intriguing.
> >>>>
> >>>> I like the idea of sharing code on one hand, but on the other hand
> >>>> it is pretty oriented towards workflows that are designed for a
> >>>> product release cycle. Bodhi is designed around community feedback
> >>>> (and now CI feedback).
> >>>>
> >>>> It could be interesting to hold a chat with the Errata tool
> >>>> developers to see if there is interest in sharing tooling, but it
> >>>> may be a lot of effort to make Errata tool flexible enough to
> >>>> support two pretty different workflows. I'd be willing to have
> >>>> that conversation; I could be wrong.
> >>
> >> Of course, there is a lot of business logic specific to Red Hat
> >> projects backed into Errata, but ultimately, it does not help to
> >> anybody if Fedora release process is using different tools then Red
> >> Hat internally.  What Red Hat does internally should be just
> >> extension to what Fedora does. The processes used internally should
> >> be proven in Fedora first.
> >
> > This is a very nice vision that will potentially make life of Red Hat
> > and Fedora much easier. I'm not that long in the Fedora project to
> > know, why Fedora and Red Hat internal tools are that different, but
> > this idea doesn't sound that bad. Few questions first: Are those
> > internal tools open source?  Could we as Fedora community use them?
> > Is there any legal issue?  Is this tool in good shape?
> >
> > And talking about the git forge, what is Red Hat using internally as
> > git forge? And then the above questions applies.
>
>  It was mentioned in a different part of this thread that Red Hat is
>  using pagure internally. 
Using, not standardized on.  It depends on the team.

Thanks,
--Robbie

[Adam Williamson]

On Fri, 2020-01-31 at 10:35 -0500, Neal Gompa wrote:
>  
>  > And talking about the git forge, what is Red Hat using internally as git
>  > forge? And then the above questions applies.
>  > 
>  
>  It was mentioned in a different part of this thread that Red Hat is
>  using pagure internally. 
Well, it's not that simple.

RH uses Pagure *for the internal equivalent of dist-git*. But it is, of
course, not the only git forge RH uses. (If there's one thing you can
bank on with RH, it's that there will be at least three tools being
used for any given job in different bits of the company). I'm aware of
RH teams using Github, Gitlab (various instances) and Gerrit. There are
probably more.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Pierre-Yves Chibon]

On Fri, Jan 31, 2020 at 12:11:08PM +0100, Vít Ondruch wrote:
>  
>  Of course, there is a lot of business logic specific to Red Hat projects
>  backed into Errata, but ultimately, it does not help to anybody if
>  Fedora release process is using different tools then Red Hat internally.
>  What Red Hat does internally should be just extension to what Fedora
>  does. The processes used internally should be proven in Fedora first. 
Welcome to our lives!
If it was mathematically possible to go above 100% that's how much agreement you
would have from us.


Pierre

[Rahul Sundaram]

Hi

On Fri, Jan 31, 2020 at 10:46 AM Pierre-Yves Chibon wrote:

>  Welcome to our lives!
>  If it was mathematically possible to go above 100% that's how much
>  agreement you
>  would have from us.
>  
If Red Hat is using Pagure internally, it is really odd to discuss
replacing Pagure with something else.  The only viable replacement is
Gitlab which is a open code project written in a language that isn't a
strong fit for Fedora. Red Hat should be assigning more resources
(development & infrastructure) to add the features needed to extend Pagure
going forward and reduce the burden on the CPE team.  Has CPE leadership
considered talking internally about that?

Rahul

[Leigh Griffin]

On Fri, Jan 31, 2020 at 3:53 PM Rahul Sundaram <metherid(a)gmail.com&gt; wrote:

>  Hi
>
>  On Fri, Jan 31, 2020 at 10:46 AM Pierre-Yves Chibon wrote:
>
> >
> > Welcome to our lives!
> > If it was mathematically possible to go above 100% that's how much
> > agreement you
> > would have from us.
> >
>
>  If Red Hat is using Pagure internally, it is really odd to discuss
>  replacing Pagure with something else.  The only viable replacement is
>  Gitlab which is a open code project written in a language that isn't a
>  strong fit for Fedora. Red Hat should be assigning more resources
>  (development & infrastructure) to add the features needed to extend Pagure
>  going forward and reduce the burden on the CPE team.  Has CPE leadership
>  considered talking internally about that?
>  
This ODF is being shared internally to get requirements as well.

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

[Dan Čermák]

Rahul Sundaram <metherid(a)gmail.com&gt; writes:

>  Hi
>
>  On Fri, Jan 31, 2020 at 10:46 AM Pierre-Yves Chibon wrote:
>
> >
> > Welcome to our lives!
> > If it was mathematically possible to go above 100% that's how much
> > agreement you
> > would have from us.
> >
>
>  If Red Hat is using Pagure internally, it is really odd to discuss
>  replacing Pagure with something else.  The only viable replacement is
>  Gitlab which is a open code project written in a language that isn't a
>  strong fit for Fedora. Red Hat should be assigning more resources
>  (development & infrastructure) to add the features needed to extend Pagure
>  going forward and reduce the burden on the CPE team.  Has CPE leadership
>  considered talking internally about that? 
I have to second this: why are we even *having* this discussion, when
Pagure is used internally at RedHat and thus RedHat will require some
form of maintenance anyway? Why is then the RedHat CPE team pushing to
move away from Pagure, especially to Gitlab? Which albeit being a great
platform, is written in Ruby and there's a lot less Ruby devs in the
Fedora community than Python devs.

Imho it would be a good idea that Pagure is not retired and is developed
further, as it is currently one of its kind in many aspects and can be
fully tweaked and customized to our needs without being huge in the way
gitlab is.


Cheers,

Dan

[Dan Čermák]

Dan Čermák <dan.cermak(a)cgc-instruments.com&gt; writes:

>  Rahul Sundaram <metherid(a)gmail.com&gt; writes:
>
> > Hi
> >
> > On Fri, Jan 31, 2020 at 10:46 AM Pierre-Yves Chibon wrote:
> >
> >>
> >> Welcome to our lives!
> >> If it was mathematically possible to go above 100% that's how much
> >> agreement you
> >> would have from us.
> >>
> >
> > If Red Hat is using Pagure internally, it is really odd to discuss
> > replacing Pagure with something else.  The only viable replacement is
> > Gitlab which is a open code project written in a language that isn't a
> > strong fit for Fedora. Red Hat should be assigning more resources
> > (development & infrastructure) to add the features needed to extend Pagure
> > going forward and reduce the burden on the CPE team.  Has CPE leadership
> > considered talking internally about that?
>
>  I have to second this: why are we even *having* this discussion, when
>  Pagure is used internally at RedHat and thus RedHat will require some
>  form of maintenance anyway? Why is then the RedHat CPE team pushing to
>  move away from Pagure, especially to Gitlab? Which albeit being a great
>  platform, is written in Ruby and there's a lot less Ruby devs in the
>  Fedora community than Python devs. 
I have to apologize, this was far too harsh. What I wanted to say is the
following: wouldn't it be mutually beneficial for RedHat, Fedora and
specifically the CPE Team too, that someone¹ takes over maintenance of
Pagure since it's used by us all and there appear to be enough people
that want to continue using it?


Cheers,

Dan

¹: Yeah, I know that this is actually the tricky part to find this
someone…

[Leigh Griffin]

On Sat, Feb 1, 2020 at 10:16 AM Dan Čermák <dan.cermak(a)cgc-instruments.com&gt;
wrote:

>  Dan Čermák <dan.cermak(a)cgc-instruments.com&gt; writes:
>
>  > Rahul Sundaram <metherid(a)gmail.com&gt; writes:
>  >
>  >> Hi
>  >>
>  >> On Fri, Jan 31, 2020 at 10:46 AM Pierre-Yves Chibon wrote:
>  >>
>  >>>
>  >>> Welcome to our lives!
>  >>> If it was mathematically possible to go above 100% that's how much
>  >>> agreement you
>  >>> would have from us.
>  >>>
>  >>
>  >> If Red Hat is using Pagure internally, it is really odd to discuss
>  >> replacing Pagure with something else. 

The usage is not uniform and not being 100% supported / hosted by the CPE
team. The rationale behind a requirements gathering process is clearly
outlined in the blog post and we have never said we are replacing Pagure,
we may opt to drive resourcing and time into it as one of the viable paths
forward.


>  The only viable replacement is
>  >> Gitlab which is a open code project written in a language that isn't a
>  >> strong fit for Fedora. 

There are 3 viable forges under consideration.


>  Red Hat should be assigning more resources
>  >> (development & infrastructure) to add the features needed to extend
>  Pagure
>  >> going forward and reduce the burden on the CPE team.  Has CPE
>  leadership 
> > considered talking internally about that?
>  
This is a key factor in the requirements exercise to know if Pagure is the
optimal choice and to know how much to build and at what cost Vs other
initiatives we could be focusing on.

>  > I have to second this: why are we even *having* this discussion, when
>  > Pagure is used internally at RedHat and thus RedHat will require some
>  > form of maintenance anyway? Why is then the RedHat CPE team pushing to
>  > move away from Pagure, especially to Gitlab? 

We never stated we are moving to Gitlab. We stated why the CPE team are
considering this exercise, if you have questions I'm happy to try clarify
them but I urge you to re-read the problem statement and approach in the
blog post.


>  Which albeit being a great
>  > platform, is written in Ruby and there's a lot less Ruby devs in the
>  > Fedora community than Python devs.
>
>  I have to apologize, this was far too harsh. 

It seems to be an emotive topic but thank you for apologising! I still
wanted to address the above though in case there was a concern.


>  What I wanted to say is the
>  following: wouldn't it be mutually beneficial for RedHat, Fedora and
>  specifically the CPE Team too, that someone¹ takes over maintenance of
>  Pagure since it's used by us all and there appear to be enough people
>  that want to continue using it?
>  
It possibly might be, when the analysis is complete we can check that out.
It would be premature and based on no real data to form that decision right
now, hence the requirements exercise. Whatever solution is chosen will
hopefully satisfy the requirements put forward by Fedora, CentOS, Red Hat
and the CPE team. We might not hit all of them perfectly, there might be
some trade offs in functionality but we hope to transparently show what
those trade offs would be and why we take a certain path.


>  Cheers,
>
>  Dan
>
>  ¹: Yeah, I know that this is actually the tricky part to find this
>  someone…
>  _______________________________________________
>  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 Fenzi]

On Sat, Feb 01, 2020 at 11:15:43AM +0100, Dan Čermák wrote:
>  Dan Čermák <dan.cermak(a)cgc-instruments.com&gt; writes:
>  
>  > Rahul Sundaram <metherid(a)gmail.com&gt; writes:
>  >
>  >> Hi
>  >>
>  >> On Fri, Jan 31, 2020 at 10:46 AM Pierre-Yves Chibon wrote:
>  >>
>  >>>
>  >>> Welcome to our lives!
>  >>> If it was mathematically possible to go above 100% that's how much
>  >>> agreement you
>  >>> would have from us.
>  >>>
>  >>
>  >> If Red Hat is using Pagure internally, it is really odd to discuss
>  >> replacing Pagure with something else.  The only viable replacement is
>  >> Gitlab which is a open code project written in a language that isn't a
>  >> strong fit for Fedora. Red Hat should be assigning more resources
>  >> (development & infrastructure) to add the features needed to extend Pagure
>  >> going forward and reduce the burden on the CPE team.  Has CPE leadership
>  >> considered talking internally about that?
>  >
>  > I have to second this: why are we even *having* this discussion, when
>  > Pagure is used internally at RedHat and thus RedHat will require some
>  > form of maintenance anyway? Why is then the RedHat CPE team pushing to
>  > move away from Pagure, especially to Gitlab? Which albeit being a great
>  > platform, is written in Ruby and there's a lot less Ruby devs in the
>  > Fedora community than Python devs.
>  
>  I have to apologize, this was far too harsh. What I wanted to say is the
>  following: wouldn't it be mutually beneficial for RedHat, Fedora and
>  specifically the CPE Team too, that someone¹ takes over maintenance of
>  Pagure since it's used by us all and there appear to be enough people
>  that want to continue using it? 
Thats one option sure, but also, if Fedora changes to something, Red Hat
could also choose to change, keeping alignment with Fedora too.

I think we want to be aware of the sunk cost falicy here. 

kevin

[Julen Landa Alustiza]

2020(e)ko urtarrilaren 29(a) 15:56:08 (CET)-(e)an, Clement Verna
<cverna(a)fedoraproject.org&gt;-(e)k hau idatzi zuen:
> On Wed, Jan 29, 2020, 15:23 Julen Landa Alustiza
> <jlanda(a)fedoraproject.org&gt;
> wrote:
>
> > (snip)
> >
> > 20/1/29 14:49(e)an, Clement Verna igorleak idatzi zuen:
> > > To me that's the all point of this
> > > process, let's put down what we *really* *really* need and  then
> look at
> > > the different options.
> > >
> >
> > Do we *really* *really* need to compete with other full featured git
> > forges on features? The ODF says that this is one of the problem.
> Well,
> > imo we don't *really* *really* need to compete with them.
> >
>
> It depends on the use case, doing development work projects hosted on
> pagure.io is not great in my opinion. In particular working with pull
> requests.
>  
I don't have excesive problems with pagure on PR workflows. Right now for me
centos-ci is a much bigger problem for PR workflows on pagure.io than pagure itself for
example.

> In terms of issue trackers, it is missing the ability to visualize
> issues
> in a board for example.
> Again this my opinion and maybe these are maybe not *really* *really*
> needed. 
Is a great forge the beste solution for this? Or are there other solutions for issue
tracking/kanban/boards etc that could better suit this use cases?
> > Actually we already have the features that we *really* *really* need.
> > Otherwise we could not release fedora using pagure as we are using,
> > could we? :)
> >
>
> I personally don't think we can release Fedora without people across
> the
> project doing heroics and a crazy amount of hours which seems to have
> become a norm rather than an exception.
>  
+1. But is this a git forge problem?

We are again on the same place: we have different use cases hosted on pagure. Some of them
could need a big effort on pagure side to compete with other options (on technical
features), some others could benefit of migrating to other solutions, and some others
could not have a better solution than our own custom one

--
Julen Landa Alustiza <jlanda(a)fedoraproject.org&gt;

[Adam Williamson]

On Wed, 2020-01-29 at 16:17 +0100, Julen Landa Alustiza wrote:
>  
>  2020(e)ko urtarrilaren 29(a) 15:56:08 (CET)-(e)an, Clement Verna
> <cverna(a)fedoraproject.org&gt;-(e)k hau idatzi zuen:
>  > On Wed, Jan 29, 2020, 15:23 Julen Landa Alustiza
>  > <jlanda(a)fedoraproject.org&gt;
>  > wrote:
>  > 
>  > > (snip)
>  > > 
>  > > 20/1/29 14:49(e)an, Clement Verna igorleak idatzi zuen:
>  > > > To me that's the all point of this
>  > > > process, let's put down what we *really* *really* need and  then
>  > look at
>  > > > the different options.
>  > > > 
>  > > 
>  > > Do we *really* *really* need to compete with other full featured git
>  > > forges on features? The ODF says that this is one of the problem.
>  > Well,
>  > > imo we don't *really* *really* need to compete with them.
>  > > 
>  > 
>  > It depends on the use case, doing development work projects hosted on
>  > pagure.io is not great in my opinion. In particular working with pull
>  > requests.
>  > 
>  I don't have excesive problems with pagure on PR workflows. Right now
>  for me centos-ci is a much bigger problem for PR workflows on
>  pagure.io than pagure itself for example. 
So, there was an interesting talk at Devconf this year:

https://devconfcz2020a.sched.com/event/YOtV/cicd-for-fedora-packaging-wit...

summary: you can use Zuul as CI on Pagure. Both src.fp.o and pagure.io.
I set it up for a project with some help from Tristan Cacqueray over
the last couple of days, to try it out. It works, and it wasn't too
hard:

https://pagure.io/fedora-qa/os-autoinst-distri-fedora/pull-request/140

that PR does a lot more than just set up the Zuul CI, but the point is
that it works, see the last couple of 'success'es. The failures were
teething troubles getting the CI setup right, but it was nothing too
major (mostly boiled down to the default environment being CentOS 7,
and that distro having a very old tox that doesn't have 'py37' and
'py38' as standard environments - we just had to tweak the config to
run the tests in a Fedora 31 environment instead).

The actual work to set up the CI was not too hard: send a pull request
to a special repo to 'enable' things:

https://pagure.io/fedora-qa/os-autoinst-distri-fedora/pull-request/140

and then add just a couple of little files to the repo:

https://pagure.io/fedora-qa/os-autoinst-distri-fedora/blob/5b518d107d62e0...
https://pagure.io/fedora-qa/os-autoinst-distri-fedora/blob/05cfd0aff616e0...

Obviously don't know if it's more reliable than CentOS CI yet as I
only just turned it on, but...I wouldn't bet against it :P
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Clement Verna]

On Wed, 29 Jan 2020 at 16:18, Julen Landa Alustiza <jlanda(a)fedoraproject.org&gt;
wrote:

>  2020(e)ko urtarrilaren 29(a) 15:56:08 (CET)-(e)an, Clement Verna <
>  cverna(a)fedoraproject.org&gt;-(e)k hau idatzi zuen:
>  >On Wed, Jan 29, 2020, 15:23 Julen Landa Alustiza
>  &gt;&lt;jlanda(a)fedoraproject.org&gt;
>  >wrote:
>  >
>  >> (snip)
>  >>
>  >> 20/1/29 14:49(e)an, Clement Verna igorleak idatzi zuen:
>  >> > To me that's the all point of this
>  >> > process, let's put down what we *really* *really* need and  then
>  >look at
>  >> > the different options.
>  >> >
>  >>
>  >> Do we *really* *really* need to compete with other full featured git
>  >> forges on features? The ODF says that this is one of the problem.
>  >Well,
>  >> imo we don't *really* *really* need to compete with them.
>  >>
>  >
>  >It depends on the use case, doing development work projects hosted on
>  >pagure.io is not great in my opinion. In particular working with pull
>  >requests.
>  >
>  I don't have excesive problems with pagure on PR workflows. Right now for
>  me centos-ci is a much bigger problem for PR workflows on pagure.io than
>  pagure itself for example.
>  
Things that I would in my opinion improve Pagure PRs :

* In the PR diff should start from the correct line number, not always 1. (
https://pagure.io/pagure/issue/724)
* Every time a branch is forced pushed you loose the comments from the diff
view. (somewhat related to https://pagure.io/pagure/issue/751)
* It should be possible to display a few lines of code before or after the
diff to help having more context when making the review

Things that would be really nice to have
* Have a way to suggest changes directly while reviewing PRs

Some unrelated to PRs improvement:

* Being able to rename, move projects
* Being able to move a ticket between projects (
https://pagure.io/pagure/issue/737)
* Full Text search projects, users, groups
* Code search (https://pagure.io/pagure/issue/539)
* Support GPG signing commit (https://pagure.io/pagure/issue/751)
* Be able to select which event you want to send on the webhook, ie
everything or nothing

A lot of these a not necessary things we *really* *really* need to have,
but they would make using Pagure much better in my opinion.

>  >In terms of issue trackers, it is missing the ability to visualize
>  >issues
>  >in a board for example.
>  >Again this my opinion and maybe these are maybe not *really* *really*
>  >needed.
>
>  Is a great forge the beste solution for this? Or are there other solutions
>  for issue tracking/kanban/boards etc that could better suit this use cases?
>  
Possibly but having the feature available at least gives you one more
option.


>  >
>  >
>  >> Actually we already have the features that we *really* *really* need.
>  >> Otherwise we could not release fedora using pagure as we are using,
>  >> could we? :)
>  >>
>  >
>  >I personally don't think we can release Fedora without people across
>  >the
>  >project doing heroics and a crazy amount of hours which seems to have
>  >become a norm rather than an exception.
>  >
>  +1. But is this a git forge problem?
>
>  We are again on the same place: we have different use cases hosted on
>  pagure. Some of them could need a big effort on pagure side to compete with
>  other options (on technical features), some others could benefit of
>  migrating to other solutions, and some others could not have a better
>  solution than our own custom one
>
>  --
>  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]
>

[Julen Landa Alustiza]

20/1/29 18:19(e)an, Clement Verna igorleak idatzi zuen:

>  
>  Things that I would in my opinion improve Pagure PRs :
>  
>  * In the PR diff should start from the correct line number, not always
>  1. (https://pagure.io/pagure/issue/724)
>  * Every time a branch is forced pushed you loose the comments from the
>  diff view. (somewhat related to https://pagure.io/pagure/issue/751)
>  * It should be possible to display a few lines of code before or after
>  the diff to help having more context when making the review
>  
>  Things that would be really nice to have
>  * Have a way to suggest changes directly while reviewing PRs
>  
>  Some unrelated to PRs improvement:
>  
>  * Being able to rename, move projects
>  * Being able to move a ticket between projects
>  (https://pagure.io/pagure/issue/737)
>  * Full Text search projects, users, groups
>  * Code search (https://pagure.io/pagure/issue/539)
>  * Support GPG signing commit (https://pagure.io/pagure/issue/751)
>  * Be able to select which event you want to send on the webhook, ie
>  everything or nothing
>  
>  A lot of these a not necessary things we *really* *really* need to have,
>  but they would make using Pagure much better in my opinion.
>  
>   
Yeah, I agree, pagure needs a better code reviewing UI

-- 
Julen Landa Alustiza <jlanda(a)fedoraproject.org&gt;

[Adam Williamson]

On Wed, 2020-01-29 at 15:56 +0100, Clement Verna wrote:
>  On Wed, Jan 29, 2020, 15:23 Julen Landa Alustiza
> <jlanda(a)fedoraproject.org&gt;
>  wrote:
>  
>  > (snip)
>  > 
>  > 20/1/29 14:49(e)an, Clement Verna igorleak idatzi zuen:
>  > > To me that's the all point of this
>  > > process, let's put down what we *really* *really* need and  then look at
>  > > the different options.
>  > > 
>  > 
>  > Do we *really* *really* need to compete with other full featured git
>  > forges on features? The ODF says that this is one of the problem. Well,
>  > imo we don't *really* *really* need to compete with them.
>  > 
>  
>  It depends on the use case, doing development work projects hosted on
>  pagure.io is not great in my opinion. In particular working with pull
>  requests. 
>  In terms of issue trackers, it is missing the ability to visualize
> issues
>  in a board for example.
>  Again this my opinion and maybe these are maybe not *really* *really*
>  needed. 
I think it depends on the size and scope of your project a bit. I do
find Pagure.io a pretty good host of the projects I have there, as
they're fairly small. But then, an open source (non-enterprise edition)
Gitlab instance would work fine for them too.

>  
>  > Actually we already have the features that we *really* *really* need.
>  > Otherwise we could not release fedora using pagure as we are using,
>  > could we? :)
>  > 
>  
>  I personally don't think we can release Fedora without people across the
>  project doing heroics and a crazy amount of hours which seems to have
>  become a norm rather than an exception. 
When that happens it doesn't normally involve Pagure much, though. And
I don't think even an amazing git forge would actually go a long way to
solving the main issues there.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Clement Verna]

On Wed, 29 Jan 2020 at 16:56, Adam Williamson <adamwill(a)fedoraproject.org&gt;
wrote:

>  On Wed, 2020-01-29 at 15:56 +0100, Clement Verna wrote:
>  > On Wed, Jan 29, 2020, 15:23 Julen Landa Alustiza <
>  jlanda(a)fedoraproject.org&gt;
>  > wrote:
>  >
>  > > (snip)
>  > >
>  > > 20/1/29 14:49(e)an, Clement Verna igorleak idatzi zuen:
>  > > > To me that's the all point of this
>  > > > process, let's put down what we *really* *really* need and  then
>  look at
>  > > > the different options.
>  > > >
>  > >
>  > > Do we *really* *really* need to compete with other full featured git
>  > > forges on features? The ODF says that this is one of the problem. Well,
>  > > imo we don't *really* *really* need to compete with them.
>  > >
>  >
>  > It depends on the use case, doing development work projects hosted on
>  > pagure.io is not great in my opinion. In particular working with pull
>  > requests.
>
>  > In terms of issue trackers, it is missing the ability to visualize issues
>  > in a board for example.
>  > Again this my opinion and maybe these are maybe not *really* *really*
>  > needed.
>
>  I think it depends on the size and scope of your project a bit. I do
>  find Pagure.io a pretty good host of the projects I have there, as
>  they're fairly small. But then, an open source (non-enterprise edition)
>  Gitlab instance would work fine for them too.
>  
Yes I agree with you, Pagure does a good job with small size project. It is
also easy deploy and self host. And as I mentioned earlier in this thread
my main real complain with Pagure is that we have to invest time to develop
it and maintain it. I would be very happy to use it, if it was developed
and maintained by someone else :-)


>  >
>  > > Actually we already have the features that we *really* *really* need.
>  > > Otherwise we could not release fedora using pagure as we are using,
>  > > could we? :)
>  > >
>  >
>  > I personally don't think we can release Fedora without people across the
>  > project doing heroics and a crazy amount of hours which seems to have
>  > become a norm rather than an exception.
>
>  When that happens it doesn't normally involve Pagure much, though. And
>  I don't think even an amazing git forge would actually go a long way to
>  solving the main issues there.
>  
It is not about the git forge itself it is about how and on what we spend
the little resources we have. If as a community we are all happy to invest
this time on developing and maintaining a git forge that's all fine with
me. But as said earlier we have not invested much in Pagure for more than a
year, that allowed us to put a lot of effort and focus on Bodhi to add
support for rawhide including people being able to use side-tag in rawhide
now. Should we continue like that and feature freeze Pagure ? or do we
invest in Pagure instead of other work that need to be done ? Do we switch
to another forge, knowing that it will require a LOT of initial effort to
migrate ? I honestly don't know what is the correct answer :-)



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

[Robbie Harwood]

Julen Landa Alustiza <jlanda(a)fedoraproject.org&gt; writes:

>  (snip)
>
>  20/1/29 14:49(e)an, Clement Verna igorleak idatzi zuen:
> > To me that's the all point of this 
> > process, let's put down what we *really* *really* need and  then look at 
> > the different options.
> > 
>
>  Do we *really* *really* need to compete with other full featured git 
>  forges on features? The ODF says that this is one of the problem. Well, 
>  imo we don't *really* *really* need to compete with them.
>
>  Actually we already have the features that we *really* *really* need. 
>  Otherwise we could not release fedora using pagure as we are using, 
>  could we? :) 
We don't have per-branch default assignees, which is actually a pretty
big problem in Fedora (especially with EPEL packages).

Thanks,
--Robbie

[Pierre-Yves Chibon]

On Wed, Jan 29, 2020 at 12:52:53PM -0500, Robbie Harwood wrote:
>  Julen Landa Alustiza <jlanda(a)fedoraproject.org&gt; writes:
>  
>  > (snip)
>  >
>  > 20/1/29 14:49(e)an, Clement Verna igorleak idatzi zuen:
>  >> To me that's the all point of this 
>  >> process, let's put down what we *really* *really* need and  then look at 
>  >> the different options.
>  >> 
>  >
>  > Do we *really* *really* need to compete with other full featured git 
>  > forges on features? The ODF says that this is one of the problem. Well, 
>  > imo we don't *really* *really* need to compete with them.
>  >
>  > Actually we already have the features that we *really* *really* need. 
>  > Otherwise we could not release fedora using pagure as we are using, 
>  > could we? :)
>  
>  We don't have per-branch default assignees, which is actually a pretty
>  big problem in Fedora (especially with EPEL packages). 
I'd counter-argue that we don't need one considering bugzilla doesn't support
a
per-version assignee. So we need an assignee for Fedora and one for Fedora
EPEL, going the level lower (F31, F30, F29, epel8, epel7...) does not bring
anything since we wouldn't be able to sync this to bugzilla.

And the Fedora vs Fedora EPEL overrides/assignee is being worked on so we can
move it off fedscm-requests where it is today to src.fp.o.


Pierre

[Vít Ondruch]

Dne 29. 01. 20 v 23:22 Pierre-Yves Chibon napsal(a):
>  On Wed, Jan 29, 2020 at 12:52:53PM -0500, Robbie Harwood wrote:
> > Julen Landa Alustiza <jlanda(a)fedoraproject.org&gt; writes:
> >
> >> (snip)
> >>
> >> 20/1/29 14:49(e)an, Clement Verna igorleak idatzi zuen:
> >>> To me that's the all point of this 
> >>> process, let's put down what we *really* *really* need and  then look at
>
> >>> the different options.
> >>>
> >> Do we *really* *really* need to compete with other full featured git 
> >> forges on features? The ODF says that this is one of the problem. Well, 
> >> imo we don't *really* *really* need to compete with them.
> >>
> >> Actually we already have the features that we *really* *really* need. 
> >> Otherwise we could not release fedora using pagure as we are using, 
> >> could we? :)
> > We don't have per-branch default assignees, which is actually a pretty
> > big problem in Fedora (especially with EPEL packages).
>  I'd counter-argue that we don't need one considering bugzilla doesn't support
> a
>  per-version assignee. So we need an assignee for Fedora and one for Fedora
>  EPEL, going the level lower (F31, F30, F29, epel8, epel7...) does not bring
>  anything since we wouldn't be able to sync this to bugzilla. 

I mostly agree. However, retired packages, such as [1], should then be
owned just by orphan after the years since their retirement. This used
to work during PkgDB days, it does not work anymore.


Vít


[1] https://src.fedoraproject.org/rpms/rubygem-sqlite3-ruby


>  And the Fedora vs Fedora EPEL overrides/assignee is being worked on so we can
>  move it off fedscm-requests where it is today to src.fp.o.
>
>
>  Pierre
>
>  _______________________________________________
>  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]

[Pierre-Yves Chibon]

On Thu, Jan 30, 2020 at 10:40:05AM +0100, Vít Ondruch wrote:
>     Dne 29. 01. 20 v 23:22 Pierre-Yves Chibon napsal(a):
>  
>   On Wed, Jan 29, 2020 at 12:52:53PM -0500, Robbie Harwood wrote:
>  
>   Julen Landa Alustiza [1]<jlanda(a)fedoraproject.org> writes:
>  
>  
>   (snip)
>  
>   20/1/29 14:49(e)an, Clement Verna igorleak idatzi zuen:
>  
>   To me that's the all point of this
>   process, let's put down what we *really* *really* need and  then look at
>   the different options.
>  
>  
>   Do we *really* *really* need to compete with other full featured git
>   forges on features? The ODF says that this is one of the problem. Well,
>   imo we don't *really* *really* need to compete with them.
>  
>   Actually we already have the features that we *really* *really* need.
>   Otherwise we could not release fedora using pagure as we are using,
>   could we? :)
>  
>   We don't have per-branch default assignees, which is actually a pretty
>   big problem in Fedora (especially with EPEL packages).
>  
>   I'd counter-argue that we don't need one considering bugzilla doesn't
> support a
>   per-version assignee. So we need an assignee for Fedora and one for Fedora
>   EPEL, going the level lower (F31, F30, F29, epel8, epel7...) does not bring
>   anything since we wouldn't be able to sync this to bugzilla.
>  
>     I mostly agree. However, retired packages, such as [1], should then be
>     owned just by orphan after the years since their retirement. This used to
>     work during PkgDB days, it does not work anymore. 
I'm traveling right now so I can't track it down, but the issue for this is that
basically the script that syncs status from src.fp.o to bugzilla has been broken
for a while.
We fixed this just last december and started running the new script early this
year, so this should be fixed now. If the issue persist, it's likely something
that is going on with someone's FAS email not mapping to a bugzilla account.
Having access to the logs of the cron job (runs twice a day), I can easily check
this when I get back to a more stable working station.

Could you open an infra ticket to track this, so we don't forget about it?

Thanks,
Pierre

[Leigh Griffin]

On Wed, Jan 29, 2020 at 10:35 AM Iñaki Ucar <iucar(a)fedoraproject.org&gt; wrote:

>  On Wed, 29 Jan 2020 at 00:08, Leigh Griffin
> <lgriffin(a)redhat.com&gt; wrote:
>  >
>  > On Tue, Jan 28, 2020, 22:06 Iñaki Ucar <iucar(a)fedoraproject.org&gt; wrote:
>  >>
>  >> On Tue, 28 Jan 2020 at 20:58, Leigh Griffin <lgriffin(a)redhat.com&gt;
>  wrote:
>  >> >
>  >> > This thread is serving as a source of requirements (although it has
>  meandered dramatically away from that)
>  >>
>  >> When I first read the post, my thought was: wow, what a convoluted and
>  >> abstruse way of saying "we want to abandon Pagure". Probably this
>  >> wasn't your intent, but that's what I got. And given the reactions,
>  >> other people too.
>  >
>  > The linked blog to the ODF is very explicit that Pagure is one of the 3
>  forge options we are considering. I can't stress enough that it's a viable
>  choice and ultimately what we opt for will come down to an analysis driven
>  by the requirements gathered. I'm unsure how the blog has been interpreted
>  any other way but hopefully this clears it up.
>
>  The ODF is very explicit in the problem statement, and it specifically
>  and clearly says that:
>
>  1. Pagure does not align with CPE.
>  
Correct and it's why we said this line, which you might have missed:
"While we can make exceptions to the mission statement, we first need to
know why we should consider a specific exception."


>  2. CPE is not gonna commit a development team to Pagure.
>  
CPE has not committed a team to it in over a year, we do state that as a
driving factor to why we want to engage in this conversation but your
assumption here is based on a particular outcome that sees Pagure not
chosen. If Pagure is chosen, we will commit a team. We are very clear on
that.


>  3. The feature gap is big and growing, and basically Pagure is gonna
>  die because of this (and the document goes on saying that you're not
>  trying to solve the feature gap).
>  
Pagure is a standalone community project. Our choice is not killing Pagure
and irrespective of the decision we make I personally hope it stays strong
and grows. Stating the feature gap is big and growing is factual, with no
committed team we are behind on it.

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

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


>  > If you (and others) elaborate on how you use Pagure (and other forges)
>  and what you value from your day to day usage, we will take that on board
>  and use it to drive our decision making.
>
>  Asking for requirements for a *forge* is pointless. A forge doesn't
>  have requirements. What you do with a forge has requirements. 

Tell me what you do and how you interact with a forge? That's the point of
this exercise.


>  As
>  others have already pointed out, Pagure is being used at the very
>  least for 3 distinct use cases: to maintain rpm packages, to maintain
>  upstream projects, and as an issue tracker. And they all have distinct
>  requirements. 

And we wish to hear all 3 as ultimately CPE become the owner of the
solution that satisfies those requirements.


>  Only that, as it happens, Pagure has grown to cover
>  their necessities with more or less success, which doesn't necessarily
>  mean that a forge is the best solution for all of them (as, again,
>  others have pointed out already). But the ODF only lists forges as
>  solutions.
>  
And if the requirements are stated we can have an open conversation about
what does suit it. I get that things have organically grown around a forge
that may / may not be the best fit for it now, lets examine that as a
conversation when we know how people are using it. This topic is focused on
what git forge the CPE team will choose based on requirements gathered but
if there is a means to address a requirement gap by another tool that is
not a forge, then that's a really good outcome of the conversation.

>  So solutions for what? What are we talking about here? Requirements
>  for src.fp.org? Requirements for things that are in pagure.io? All?
>  Other?
>
>  Iñaki
>  _______________________________________________
>  devel mailing list -- devel(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>

[Iñaki Ucar]

On Wed, 29 Jan 2020 at 16:23, Leigh Griffin <lgriffin(a)redhat.com&gt; wrote:
>  On Wed, Jan 29, 2020 at 10:35 AM Iñaki Ucar <iucar(a)fedoraproject.org&gt; wrote:
> >
> > On Wed, 29 Jan 2020 at 00:08, Leigh Griffin <lgriffin(a)redhat.com&gt; wrote:
> > >
> > > On Tue, Jan 28, 2020, 22:06 Iñaki Ucar <iucar(a)fedoraproject.org&gt; wrote:
> > >>
> > >> On Tue, 28 Jan 2020 at 20:58, Leigh Griffin <lgriffin(a)redhat.com&gt;
> wrote:
> > >> >
> > >> > This thread is serving as a source of requirements (although it has
> meandered dramatically away from that)
> > >>
> > >> When I first read the post, my thought was: wow, what a convoluted and
> > >> abstruse way of saying "we want to abandon Pagure". Probably this
> > >> wasn't your intent, but that's what I got. And given the reactions,
> > >> other people too.
> > >
> > > The linked blog to the ODF is very explicit that Pagure is one of the 3 forge
> options we are considering. I can't stress enough that it's a viable choice and
> ultimately what we opt for will come down to an analysis driven by the requirements
> gathered. I'm unsure how the blog has been interpreted any other way but hopefully
> this clears it up.
> >
> > The ODF is very explicit in the problem statement, and it specifically
> > and clearly says that:
> >
> > 1. Pagure does not align with CPE.
>
>  Correct and it's why we said this line, which you might have missed:
>  "While we can make exceptions to the mission statement, we first need to know why we
> should consider a specific exception." 
I didn't miss it, I was obviously cherry-picking, but the point was to
argue why this thread "meandered dramatically away from" the initial
purpose: if that was my initial feeling at first reading, probably
that was the case for others.

>  CPE has not committed a team to it in over a year, we do state that
> as a driving factor to why we want to engage in this conversation but your assumption here
> is based on a particular outcome that sees Pagure not chosen. If Pagure is chosen, we will
> commit a team. We are very clear on that. 
It wasn't so clear to me, but good to know.

>  Tell me what you do and how you interact with a forge? That's the
> point of this exercise. 
Those with the most complex workflows would provide most value here. I
only maintain a few simple packages at src.fp, and most of my work is
in Copr.

However, I would say that integration with FAS should be a
requirement. Owning the development of the specific tool (whether a
forge or not) is not a must, in principle, but it's a good thing IMO.
Please correct me if I'm wrong, but that was one of the drivers e.g.
to develop Copr instead of going for OBS.

Iñaki

[Leigh Griffin]

On Wed, Jan 29, 2020, 17:19 Iñaki Ucar <iucar(a)fedoraproject.org&gt; wrote:

>  On Wed, 29 Jan 2020 at 16:23, Leigh Griffin
> <lgriffin(a)redhat.com&gt; wrote:
>  >
>  > On Wed, Jan 29, 2020 at 10:35 AM Iñaki Ucar <iucar(a)fedoraproject.org&gt;
>  wrote:
>  >>
>  >> On Wed, 29 Jan 2020 at 00:08, Leigh Griffin <lgriffin(a)redhat.com&gt;
>  wrote:
>  >> >
>  >> > On Tue, Jan 28, 2020, 22:06 Iñaki Ucar <iucar(a)fedoraproject.org&gt;
>  wrote:
>  >> >>
>  >> >> On Tue, 28 Jan 2020 at 20:58, Leigh Griffin
> <lgriffin(a)redhat.com&gt;
>  wrote:
>  >> >> >
>  >> >> > This thread is serving as a source of requirements (although it
>  has meandered dramatically away from that)
>  >> >>
>  >> >> When I first read the post, my thought was: wow, what a convoluted
>  and
>  >> >> abstruse way of saying "we want to abandon Pagure". Probably
> this
>  >> >> wasn't your intent, but that's what I got. And given the
> reactions,
>  >> >> other people too.
>  >> >
>  >> > The linked blog to the ODF is very explicit that Pagure is one of the
>  3 forge options we are considering. I can't stress enough that it's a
>  viable choice and ultimately what we opt for will come down to an analysis
>  driven by the requirements gathered. I'm unsure how the blog has been
>  interpreted any other way but hopefully this clears it up.
>  >>
>  >> The ODF is very explicit in the problem statement, and it specifically
>  >> and clearly says that:
>  >>
>  >> 1. Pagure does not align with CPE.
>  >
>  > Correct and it's why we said this line, which you might have missed:
>  > "While we can make exceptions to the mission statement, we first need to
>  know why we should consider a specific exception."
>
>  I didn't miss it, I was obviously cherry-picking 

It gives a very different view when considered in balance Vs a selective
quote. That's why I replied on the off chance someone is driving by the
thread and skips the key points in the post.

, but the point was to
>  argue why this thread "meandered dramatically away from"
> the initial
>  purpose: if that was my initial feeling at first reading, probably
>  that was the case for others. 

>  > CPE has not committed a team to it in over a year, we do state
> that as a
>  driving factor to why we want to engage in this conversation but your
>  assumption here is based on a particular outcome that sees Pagure not
>  chosen. If Pagure is chosen, we will commit a team. We are very clear on
>  that.
>
>  It wasn't so clear to me, but good to know.
>  
Glad I could clarify it, I'm happy to update the original ODF document if
it makes it clearer for others.

>  > Tell me what you do and how you interact with a forge? That's the point
>  of this exercise.
>
>  Those with the most complex workflows would provide most value here. I
>  only maintain a few simple packages at src.fp, and most of my work is
>  in Copr.
>  
I suspect that a bulk of our users are similar to you. Given that you are
engaged on the thread (thank you!) what is your day to day needs? What
features are part of your usage and interaction? What's missing or what
would you like to see added? Your voice here can help represent that group
and is most welcome.


>  However, I would say that integration with FAS should be a
>  requirement. Owning the development of the specific tool (whether a
>  forge or not) is not a must, in principle, but it's a good thing IMO.
>  Please correct me if I'm wrong, but that was one of the drivers e.g.
>  to develop Copr instead of going for OBS.
>
>  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]
>

[Iñaki Ucar]

On Wed, 29 Jan 2020 at 23:23, Leigh Griffin <lgriffin(a)redhat.com&gt; wrote:
>  I suspect that a bulk of our users are similar to you. Given that you are engaged on the
> thread (thank you!) what is your day to day needs? What features are part of your usage
> and interaction? What's missing or what would you like to see added? Your voice here
> can help represent that group and is most welcome. 
I'd say that if you manage to accommodate the more complicated
workflows, the basic one is covered. Beyond that, I really like the
table that is displayed in src.fp.o for every package, because in a
single glance you can tell which one is the stable version and the
version in testing for every release. I really like the links to Koji,
Bodhi... integrated just above the table. And I really really like the
Fedora Packages app, but it seems to be dead.

In summary, package maintainance has many pieces (dist-git, builders,
update system, bugzilla, QA, CI...), and a "control panel" like Fedora
Packages is very useful, I think.

Iñaki

[Neal Gompa]

On Thu, Jan 30, 2020 at 6:40 AM Iñaki Ucar <iucar(a)fedoraproject.org&gt; wrote:
>  On Wed, 29 Jan 2020 at 23:23, Leigh Griffin <lgriffin(a)redhat.com&gt; wrote:
>  >
>  > I suspect that a bulk of our users are similar to you. Given that you are engaged on
> the thread (thank you!) what is your day to day needs? What features are part of your
> usage and interaction? What's missing or what would you like to see added? Your voice
> here can help represent that group and is most welcome.
>
>  I'd say that if you manage to accommodate the more complicated
>  workflows, the basic one is covered. Beyond that, I really like the
>  table that is displayed in src.fp.o for every package, because in a
>  single glance you can tell which one is the stable version and the
>  version in testing for every release. I really like the links to Koji,
>  Bodhi... integrated just above the table. And I really really like the
>  Fedora Packages app, but it seems to be dead.
>
>  In summary, package maintainance has many pieces (dist-git, builders,
>  update system, bugzilla, QA, CI...), and a "control panel" like Fedora
>  Packages is very useful, I think.
>  
The Packages app was being rewritten by Miroslav Suchy:
https://github.com/xsuchy/fedora-packages-ng

I don't know if it's ready yet to replace the existing one, though.



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

Packages webapp status

[Elliott Sales de Andrade]

On Thu, 30 Jan 2020 at 08:03, Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  On Thu, Jan 30, 2020 at 6:40 AM Iñaki Ucar <iucar(a)fedoraproject.org&gt; wrote:
>  >
>  > On Wed, 29 Jan 2020 at 23:23, Leigh Griffin <lgriffin(a)redhat.com&gt; wrote:
>  > >
>  > > I suspect that a bulk of our users are similar to you. Given that you are
> engaged on the thread (thank you!) what is your day to day needs? What features are part
> of your usage and interaction? What's missing or what would you like to see added?
> Your voice here can help represent that group and is most welcome.
>  >
>  > I'd say that if you manage to accommodate the more complicated
>  > workflows, the basic one is covered. Beyond that, I really like the
>  > table that is displayed in src.fp.o for every package, because in a
>  > single glance you can tell which one is the stable version and the
>  > version in testing for every release. I really like the links to Koji,
>  > Bodhi... integrated just above the table. And I really really like the
>  > Fedora Packages app, but it seems to be dead.
>  >
>  > In summary, package maintainance has many pieces (dist-git, builders,
>  > update system, bugzilla, QA, CI...), and a "control panel" like Fedora
>  > Packages is very useful, I think.
>  >
>
>  The Packages app was being rewritten by Miroslav Suchy:
>  https://github.com/xsuchy/fedora-packages-ng
>
>  I don't know if it's ready yet to replace the existing one, though.
>  
I don't know what the status of the replacement is, but when I go to
Packages, 50% of what I look for is missing and 50% is just wrong.
This is less than useless. Any prospective Fedora user won't even
bother installing it if they can't find out whether their favourite
application is available. We might as well just turn Packages off.

So if the rewrite can do basically anything, it's probably an
improvement. I'm sorry to be so harsh to the existing app, but it's
basically of negative benefit to Fedora right now.

-- 
Elliott

Packages webapp status

[Kevin Fenzi]

On Fri, Jan 31, 2020 at 01:37:36AM -0500, Elliott Sales de Andrade wrote:
>  On Thu, 30 Jan 2020 at 08:03, Neal Gompa <ngompa13(a)gmail.com&gt;
> wrote:
>  >
>  > On Thu, Jan 30, 2020 at 6:40 AM Iñaki Ucar <iucar(a)fedoraproject.org&gt; wrote:
>  > >
>  > > On Wed, 29 Jan 2020 at 23:23, Leigh Griffin <lgriffin(a)redhat.com&gt; wrote:
>  > > >
>  > > > I suspect that a bulk of our users are similar to you. Given that you are
> engaged on the thread (thank you!) what is your day to day needs? What features are part
> of your usage and interaction? What's missing or what would you like to see added?
> Your voice here can help represent that group and is most welcome.
>  > >
>  > > I'd say that if you manage to accommodate the more complicated
>  > > workflows, the basic one is covered. Beyond that, I really like the
>  > > table that is displayed in src.fp.o for every package, because in a
>  > > single glance you can tell which one is the stable version and the
>  > > version in testing for every release. I really like the links to Koji,
>  > > Bodhi... integrated just above the table. And I really really like the
>  > > Fedora Packages app, but it seems to be dead.
>  > >
>  > > In summary, package maintainance has many pieces (dist-git, builders,
>  > > update system, bugzilla, QA, CI...), and a "control panel" like
> Fedora
>  > > Packages is very useful, I think.
>  > >
>  >
>  > The Packages app was being rewritten by Miroslav Suchy:
>  > https://github.com/xsuchy/fedora-packages-ng
>  >
>  > I don't know if it's ready yet to replace the existing one, though.
>  >
>  
>  I don't know what the status of the replacement is, but when I go to 
Hopefully Miroslav can fill us in on that.

>  Packages, 50% of what I look for is missing and 50% is just wrong.
>  This is less than useless. Any prospective Fedora user won't even
>  bother installing it if they can't find out whether their favourite
>  application is available. We might as well just turn Packages off. 
Thats... much more harsh than I would agree with. I still use it and
find some of its information helpfull. 

kevin

Packages webapp status

[Richard Fearn]

On Mon, 3 Feb 2020 at 17:03, Kevin Fenzi <kevin(a)scrye.com&gt; wrote:
>  Thats... much more harsh than I would agree with. I still use it and
>  find some of its information helpfull. 
Sadly it does seem to have got a lot worse recently... I noticed last
weekend that a few of the packages I maintain (e.g. clide, colordiff,
perl-App-ccdiff, whowatch) can no longer found.

I remember some tickets being created about this - I'll see if I can
find them and comment there...

Rich

-- 
Richard Fearn
richardfearn(a)gmail.com

Packages webapp status

[Clement Verna]

On Fri, 7 Feb 2020 at 21:50, Richard Fearn <richardfearn(a)gmail.com&gt; wrote:

>  On Mon, 3 Feb 2020 at 17:03, Kevin Fenzi <kevin(a)scrye.com&gt;
> wrote:
>  >
>  > Thats... much more harsh than I would agree with. I still use it and
>  > find some of its information helpfull.
>
>  Sadly it does seem to have got a lot worse recently... I noticed last
>  weekend that a few of the packages I maintain (e.g. clide, colordiff,
>  perl-App-ccdiff, whowatch) can no longer found.
>
>  I remember some tickets being created about this - I'll see if I can
>  find them and comment there...
>  
Hi all,

The indexing of the packages app full text search database relies almost
only on mdapi [0] to populate the informations. The indexing sends a lot of
requests to mdapi (at least 80 000, 1 for each package and subpackages)
that causes a lot of load on mdapi which in returns makes some of the
requests timeout and fail. I have improved mdapi performance last year [1]
but unfortunately since we have moved it to OpenShift, mdapi is using an
NFS volume mount which is rather slow making the performance improvement
not as significant.

So the current situation is that every time the indexing process run, it is
a little bit of a lottery. Depending on how many requests to mdapi are
failing it will get different results, so a package might suddenly
disappear. There is also a bug that I did not investigate but sometimes a
package has another package description.

All that to say that I think, the indexing process needs to be rewritten or
fix to be less aggressive towards mdapi or to be able to handle failure. I
think it would be nice to have full text search of packages as a different
service providing a simple API so anyone interested can build something
cool using this. I personally don't have the time to look at this, but if
anyone is interested I am happy to answer questions or provide pointers
about the current process.

Hope this was an useful explanation :-)

[0] - https://mdapi.fedoraproject.org/
[1] - https://communityblog.fedoraproject.org/speeding-up-mdapi/

>  Rich
>
>  --
>  Richard Fearn
>  richardfearn(a)gmail.com
>  _______________________________________________
>  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, Jan 22, 2020 at 5:00 am, Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  And there's this worry that GitLab will go the same path
> Transifex
>  did. They have a ton of incentives to do so, and they already are
>  starting to with the consideration of injecting nonfree JavaScript in
>  all variants. 
Terrifying. Do you have a reference for this?

I guess GitLab does not understand it would be throwing away all the 
efforts of GNOME, freedesktop.org, KDE, and Debian to migrate to it? I 
doubt any of these communities would be willing to continue using 
GitLab if this were to happen (even though another transition would be 
very painful for each community). We might even wind up in a bizarro 
world where Pagure becomes the new default forge for open source 
communities.

Michael

[Neal Gompa]

On Wed, Jan 22, 2020 at 10:46 AM Michael Catanzaro <mcatanzaro(a)gnome.org&gt; wrote:
>  On Wed, Jan 22, 2020 at 5:00 am, Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  > And there's this worry that GitLab will go the same path Transifex
>  > did. They have a ton of incentives to do so, and they already are
>  > starting to with the consideration of injecting nonfree JavaScript in
>  > all variants.
>
>  Terrifying. Do you have a reference for this?
>  
Back in October, GitLab considered doing this[1]. The outcry from
their corporate customers got them to reconsider... for now. They're
still trying to figure out what to do here to implement that feature
without as much pushback.

[1]: https://about.gitlab.com/blog/2019/10/10/update-free-software-and-telemetry/

>  I guess GitLab does not understand it would be throwing away all the
>  efforts of GNOME, freedesktop.org, KDE, and Debian to migrate to it? I
>  doubt any of these communities would be willing to continue using
>  GitLab if this were to happen (even though another transition would be
>  very painful for each community). We might even wind up in a bizarro
>  world where Pagure becomes the new default forge for open source
>  communities.
>  
I don't know how many times we're going to have to learn the hard
lesson that relying on open core software bites us in the end.



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

[Felix Schwarz]

Am 22.01.20 um 11:00 schrieb Neal Gompa:
>  Yes, but neither of those communities actually have terribly special
>  requirements. In fact, those communities either had *nothing* in terms
>  of infrastructure (FreeDesktop/Xorg) or were willing to throw
>  everything away for GitLab (GNOME). We would not fit in either bucket,
>  which makes GitLab a very awkward fit for us. 
I'm sure you are aware of it but Debian uses gitlab as well...

Felix

[Neal Gompa]

On Wed, Jan 22, 2020 at 5:21 PM Felix Schwarz
<fschwarz(a)fedoraproject.org&gt; wrote:
>  Am 22.01.20 um 11:00 schrieb Neal Gompa:
>  > Yes, but neither of those communities actually have terribly special
>  > requirements. In fact, those communities either had *nothing* in terms
>  > of infrastructure (FreeDesktop/Xorg) or were willing to throw
>  > everything away for GitLab (GNOME). We would not fit in either bucket,
>  > which makes GitLab a very awkward fit for us.
>
>  I'm sure you are aware of it but Debian uses gitlab as well...
>  
I am aware of Salsa. Salsa functions largely as a fancy code host,
rather than something where they leverage more of its functionality.
They do have GitLab CI, but it's only used on some code projects. The
bulk of the projects that are packaging ones have no CI to speak of.
All of the packaging test stuff works off uploads by DMs/DDs into the
queue for ftpmasters, which is disconnected from the VCS entirely.
Moreover, Debian does not mandate that packaging has a VCS or that if
it does have a VCS that it has to be on Salsa. So overall, it's a very
odd situation compared to others where usage of the system isn't even
required (there are people hosting Debian projects and packaging on
pagure.io!).



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

[Florian Weimer]

* Felix Schwarz:

>  Personally I guess github would attract most contributions for
> Fedora
>  from new contributors but it is closed source so I'd prefer gitlab for
>  Fedora. 
I don't think Github allows disabling pull requests for projects.  This
means that a ptoential Fedora Github service would host content
submitted by people who have to agreed to the FPCA
<https://fedoraproject.org/wiki/Legal:Fedora_Project_Contributor_Agreement>;.

Maybe that alone is sufficient to rule out Github?

Thanks,
Florian

[Miro Hrončok]

On 22. 01. 20 11:21, Florian Weimer wrote:
>  * Felix Schwarz:
>  
> > Personally I guess github would attract most contributions for Fedora
> > from new contributors but it is closed source so I'd prefer gitlab for
> > Fedora.
>  
>  I don't think Github allows disabling pull requests for projects.  This
>  means that a ptoential Fedora Github service would host content
>  submitted by people who have to agreed to the FPCA
>  <https://fedoraproject.org/wiki/Legal:Fedora_Project_Contributor_Agreement>;.
>  
>  Maybe that alone is sufficient to rule out Github? 
We are not the first project to deal with this. Usually, i is sovled by pots. 
See for example:

https://github.com/python/cpython/pull/16012#issuecomment-530664428

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

[Florian Weimer]

* Miro Hrončok:

>  On 22. 01. 20 11:21, Florian Weimer wrote:
> > * Felix Schwarz:
> >
> >> Personally I guess github would attract most contributions for Fedora
> >> from new contributors but it is closed source so I'd prefer gitlab for
> >> Fedora.
> >
> > I don't think Github allows disabling pull requests for projects.  This
> > means that a ptoential Fedora Github service would host content
> > submitted by people who have to agreed to the FPCA
> > <https://fedoraproject.org/wiki/Legal:Fedora_Project_Contributor_Agreement>;.
> >
> > Maybe that alone is sufficient to rule out Github?
>
>  We are not the first project to deal with this. Usually, i is sovled
>  by pots. See for example:
>
>  https://github.com/python/cpython/pull/16012#issuecomment-530664428 
Does this really work?

This pull request still has the “CLA not signed” label:

  <https://github.com/python/cpython/pull/18111>

But this is not shown clearly in the commit:

  <https://github.com/python/cpython/commit/d6fd38e2a47af1e75>

The red X isn't a relevant indicator.  This commit was merged and has it,
too:

  <https://github.com/python/cpython/commit/0d5eac8c327251f8e>

I don't know if the branch list (the “master” below the commit subject)
is a reliable indicator.

This is why I think the bot-based approach needs some review.  I also
think it's quite rude.  The whole FPCA thing feels strange these days.
Hopefully there is a better way to make sure that contributions are
intended as such.

Thanks,
Florian

[Miro Hrončok]

On 22. 01. 20 14:12, Florian Weimer wrote:
>  * Miro Hrončok:
>  
> > On 22. 01. 20 11:21, Florian Weimer wrote:
> >> * Felix Schwarz:
> >>
> >>> Personally I guess github would attract most contributions for Fedora
> >>> from new contributors but it is closed source so I'd prefer gitlab for
> >>> Fedora.
> >>
> >> I don't think Github allows disabling pull requests for projects.  This
> >> means that a ptoential Fedora Github service would host content
> >> submitted by people who have to agreed to the FPCA
> >>
> <https://fedoraproject.org/wiki/Legal:Fedora_Project_Contributor_Agreement>;.
> >>
> >> Maybe that alone is sufficient to rule out Github?
> >
> > We are not the first project to deal with this. Usually, i is sovled
> > by pots. See for example:
> >
> > https://github.com/python/cpython/pull/16012#issuecomment-530664428
>  
>  Does this really work?
>  
>  This pull request still has the “CLA not signed” label:
>  
>     <https://github.com/python/cpython/pull/18111> 
And is not merged.

>  But this is not shown clearly in the commit:
>  
>     <https://github.com/python/cpython/commit/d6fd38e2a47af1e75>
>  
>  The red X isn't a relevant indicator.  This commit was merged and has it,
>  too:
>  
>     <https://github.com/python/cpython/commit/0d5eac8c327251f8e> 
The red X doesn't mean “CLA not signed”, it means any CI has failed. CPython 
allows merges with some CI failed, they have a very complicated setup with lots 
of lots of CIs, buildbots and a "night watch" about his. Not relevant for this 
discussion.

>  I don't know if the branch list (the “master” below the commit
> subject)
>  is a reliable indicator. 
Of what? CPython frequently cherry-picks, so in this case, no, it probably isn't.

>  This is why I think the bot-based approach needs some review.  I
> also
>  think it's quite rude.  The whole FPCA thing feels strange these days.
>  Hopefully there is a better way to make sure that contributions are
>  intended as such. 
It is quite rude, yes. So is the PAgure settings to enforce Signed off by 
commits (especially for repos that don't describe what are you signing off).

This thing is not easy indeed.

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

[Florian Weimer]

* Miro Hrončok:

> > The red X isn't a relevant indicator.  This commit was merged
> and has it,
> > too:
> >
> >    <https://github.com/python/cpython/commit/0d5eac8c327251f8e>
>
>  The red X doesn't mean “CLA not signed”, it means any CI has
>  failed. CPython allows merges with some CI failed, they have a very
>  complicated setup with lots of lots of CIs, buildbots and a "night
>  watch" about his. Not relevant for this discussion.
>
> > I don't know if the branch list (the “master” below the commit subject)
> > is a reliable indicator.
>
>  Of what? CPython frequently cherry-picks, so in this case, no, it
>  probably isn't. 
The second commit (cited above) is on the master branch, though.  Which
is my point: this shared space *is* confusing if you think you need to
control tightly who can publish under it.

Thanks,
Florian

[Robert-André Mauchin]

On Tuesday, 21 January 2020 17:34:37 CET Leigh Griffin wrote:
>  Hey Everyone,
>  
>  On behalf of the CPE team I want to draw the communities attention to a
>  recent blog post which you may be impacted by:
>   https://communityblog.fedoraproject.org/git-forge-requirements/
>  
>  We will be seeking input and requirements in an open and transparent manner
>  on the future of a git forge solution which will be run by the CPE team on
>  behalf of the Fedora Community. This mail is being sent to the devel,
>  mindshare and council-discuss lists for maximum visibility on a BCC to
>  allow each list have their own views. Please forward it to any other list
>  you may feel is relevant to maximise the exposure.
>  
>  Thanks in advance,
>  Leigh 
Quote:
> At the same time, integrations that already exist in Pagure may need
> to be  
created for another git forge, which is a cost as well. This also needs to be

fully considered by the team as part of the requirement gathering.

We just got Release-monitoring integration in Pagure, how would that be 
implemented in a new forge? What man-hours are you ready to commit to this new 
forge that can't equally be equally be committed to Pagure? At least with 
Pagure, we have people who know the codebase, would it be that easy to do 
custom integration with Git{hub,lab}?

GitHub is also, as far as I know, not free; wouldn't that be in contradiction 
with Fedora mission-statement to use it over a free alternative?

Best regards,

Robert-André

[Julen Landa Alustiza]

Heya,

Currently we have two different pagure instances that hosts different 
use cases on them, and different use cases means different requirements, 
so first of all, about what use cases we are talking about?

we have src.fp.o for distgit, some pagure.io projects that hosts actual 
code development repos and some other repos that are used as trackers 
and documentation containers.

For all of them, I agree with mcatanzaro's requirements:
#1 self hosted
#2 open source

IMO, #1 could be a soft requirement, I would be fine with a service 
provided by an upstream first and open source friendly service provider 
if it allows us to dump out all our data on a easy way. Now git and 
github is the mainstream workflow, but previously was sourceforge and 
svn . We should be able to transfer our data from our current service to 
a N+1 or N+2 service without losing too much so we should be able to 
dump all our data on a supported way.

I have some more general requirements:

#3 privacy friendly. Nowadays js|cookie tracking is huge on the world 
wide web, I would prefer not being tracked on that way while using a 
fedora service. bodhi, koji or distgit does not inject any weird 
tracking javascript or cookies, I love that and since privacy concerns 
me I would like to continue on this way.

#4 Good integration with Fedora infra's core services. This include fas 
(and it's replacement) and fedora-messaging

#5 Easy to onboard and open to any community member, newcomers included. 
We should avoid the integration problems that we're having with 
teams.fp.o on this matter for example (see below)

This requirements are not just for our git forge, all the fedora 
services should satisfy with them.

Then, we should capture and analyze the different use cases 
individually. Different use cases, different requirements. They might 
fit all of them on the same solution or we could move some of them to a 
different one if the other solution fits better for that case.

So let start with distgit. Here we have a bunch of more requirements:

#packager.1: technical implementation of our packaking policies and the 
ability to evolve them as the policies evolve. This means at least 
support for system-wide commit users (provenpackagers), system-wide 
restricted branches, systemn-wide protected (non force pushable) refs, 
system-wide actors that can bypass all this limitations (releng).

This should cover orphaning and retaking process too.
We lack but we should have ACL branches and admins to support different 
EPEL|Fedora maintainers on the same repo.

#packager.2: Integration with other options|services that we have on our 
packaking workflows. This could be done on the git repo or we could have 
a different packager control panel service (I love miro's mockups for 
example). This includes BZ, bodhi, koji, anitya, BZ overrides...

That's for now on distgit.

On pagure.io I identify two big groups of repositories: code repos for 
development of different projects and tracking repos that are mostly 
used for the ticket system and some documentation.

The later ones could fit on teams.fp.o if we can solve the big issues on 
it: the fas integration is not perfect, and is not open for 
contributions. Fixing [1] and [2] is a requirement for teams to fulfill 
the initial general requirements, so it would be a requirement for an 
hypothetical transfer of this kind of projects from pagure.io to teams.fp.o

As general requirements, I have two at least:

#tickets.1: ticket|issue system support for usual workflows: tickets, 
assignees, tags, states, priorities...

#tickets.2: some kind of documentation integration. We have some repos 
on this use case that are just docs + tickets. We could support them on 
a non git repo solution if we can integrate both docs and tickets on a 
unique UI.

And then we have the code repos.

I like the idea of having a unique place to host all the fedora related 
code projects and I would add a couple of requirements around the 
homepage about this in case we go with a solution that groups all those 
code repos on a single place:

#dev.1: An attractive homepage that shows where is the activity right 
now, where we need help, and where newcomers can start to contribute.

#dev.2: Good searching capabilities.



For the repo itself... this is where we probably diverge more since 
every single developer has her own workflows so she'll have their own 
personal requirements. Some of us could just work with a system that 
allows you to make basic git operations and some others will require 
complex interactive conflict resolving UIs.

On my case, I don't need too much:

#dev.3: git support. I'm fine with just ssh support, but https one could 
benefit newcomers onboarding process.

#dev.4: PR workflow support.

#dev.5: ticketing system

#dev.6: web ui to the code, branches etc.

And then I have a soft requirement on a actual pagure feature that I did 
not use it previously but it means a lot nowadays for me:

#dev.SOFT.1: allow project maintainer to rebase pull requests. This 
helps a lot both the PR author and the project maintainer, I love it, I 
use it a lot and I would like to continue using it on my fedora related 
contributions.

[1]: https://pagure.io/fedora-infrastructure/issue/7826
[2]: https://pagure.io/fedora-infrastructure/issue/7827

And that is for now.

Regards,

[Nicolas Mailhot]

Le mardi 21 janvier 2020 à 16:34 +0000, Leigh Griffin a écrit :

Hi,

>  On behalf of the CPE team I want to draw the communities attention
> to
>  a recent blog post which you may be impacted by:
>   https://communityblog.fedoraproject.org/git-forge-requirements/ 
Requirements:

1. the url to the archive (tar.xz, tar.bz2, etc) corresponding to
various code states (commit/tag/release/fork…) should be regular and
stable (ideally, identical to the current ones to avoid redoing all the
automation that plugs in pagure today, redoing source declaration in
specs, etc)

2. the git repos should be fully accessible over https (read and write)
to allow the contributionsfrom environments where ssh is filtered for
security reasons. It’s hard enough to nurture the contributor pool
whithout infra that can not work with nowaday’s most common access
protocol (contributors should do xxx means no contributors given the
current project attractivity deficit)

Regards

-- 
Nicolas Mailhot

[Jean-Baptiste Holcroft]

First requirement:
As a Fedora community member, I'm able to self-organize my personal and team work by
creating projects and group 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.

As teams.fedoraproject.org was mentioned before, the fact teams.fp.o requires you to add
each user in the project for them to be able to interact with a ticket made me given up
with this tool for the translation platform migration to Weblate.

In the other hand, we created 38 repositories to contain documentation's
translations.
We created groups and did the whole setting easily.
The Pagure mindset fits with the idea of autonomy and ability to personalize.

By the way, we are stuck with automation which relies on openshift.
It took me days only to get access as reader to fedora docs openshift.
I connected and got lost instantly, it's complex and since, we had no progress in
months.

Moving to either GitLab or Github worries me as it may lower our ability to self organize
and the empowerment from casual contributors to key member of the community.


Second requirement:
As a Fedora community member, I am using tools respecting the values of my community so
that my speech and my acts are consistent.

We already have difficulties in promoting open source, not using it ourselves lower our
credibility.


Third requirement:
The platform should provide ways to talk with fedora-messages, so that non-packaging
activities are included in Fedora community statistics and rewards (badges).

Jean-Baptiste

[Till Maas]

On Tue, Jan 21, 2020 at 04:34:37PM +0000, Leigh Griffin wrote:

>  On behalf of the CPE team I want to draw the communities attention to
> a
>  recent blog post which you may be impacted by:
>   https://communityblog.fedoraproject.org/git-forge-requirements/
>  
>  We will be seeking input and requirements in an open and transparent manner
>  on the future of a git forge solution which will be run by the CPE team on 
Aleksandra's comment made me aware that for dist-git, we do not really
need a git forge, it is just that the pagure git forge was used to
implement a lot of workflows that pkgdb provided in the past.

I tried to write the requirements as user stories to make them easier to
understand. What do you think?

- As a package maintainer, I can only commit to a dist-git repo, if I am
  in the Fedora packager group.
- As a package maintainer, I can only commit to a dist-git repo, if I am
  a maintainer of the branch.
- As a proven packager, I can commit to all dist-git repos that do not
  have special restrictions set by FESCo or are retired.
- As a FESCO member, I can configure exceptions to disallow proven
  packager access to a dist-git repo.
- 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
- As a dist-git repo admin, I cannot remove access to the repo from
  Fedora infra, Releng or proven packagers without FESCo approval.
- As a package maintainer, I can easily orphan a dist-git repo or branch
  to show that it is not maintained anymore.
- As a package maintainer, I can adopt any orphaned dist-git repo or
  branch.
- As a package maintainer, I can easily unretire a retired dist-git repo
  or branch.
- As a release engineer, I can easily approve unretire requests for a
  dist-git repo or branch.
- As anybody, I can easily see the FAS usernames of maintainers for all
  branches of a dist-git repo.
- As a non-releng member, I cannot remove any commits from any dist-git
  repo that were used to build a Fedora package.
- As an external user, I can easily get a list of all orphaned or
  retired dist-git repos and branches.
- As anybody, I can watch for issues (bugzillas) or PRs that are created
  for a dist-git repository.
- As anybody, I can easily get a list of all dist-git repos that I am
  watching.
- As anybody, I can easily get a list of all dist-git repos that a
  specific Fedora account has admin/commit access to.
- As anybody, when looking at the dist-git repo it is clearly visible
  which branches are still maintained.
- As anybody, when I look for a specific branch, EOL branches do not
  clutter my view.
- As a package maintainer, I can easily request commit/admin access for
  a specific branch or dist-git repo.

Also since dist-git is a critical part of our infrastructure, there
should probably also be some security-related requirements such as:

- As Fedora infra, I can easily audit that no git repo was accessed
  without authorization.
- As Fedora infra/security response team, I have access to secure logs
  to analyse the impact of unauthorized access to all dist-git repos.
- As anybody, the dist-git web page of a repo points me to Bugzilla to
  report issues for a repository.

I did not manage to read all other replies, so there might be some
duplicates but it also seems to me that many of these items were not
mentioned.

Kind regards
Till

[Josh Boyer]

On Thu, Feb 6, 2020 at 4:14 PM Till Maas <opensource(a)till.name&gt; wrote:
>  On Tue, Jan 21, 2020 at 04:34:37PM +0000, Leigh Griffin wrote:
>
>  > On behalf of the CPE team I want to draw the communities attention to a
>  > recent blog post which you may be impacted by:
>  >  https://communityblog.fedoraproject.org/git-forge-requirements/
>  >
>  > We will be seeking input and requirements in an open and transparent manner
>  > on the future of a git forge solution which will be run by the CPE team on
>
>  Aleksandra's comment made me aware that for dist-git, we do not really
>  need a git forge, it is just that the pagure git forge was used to
>  implement a lot of workflows that pkgdb provided in the past.
>
>  I tried to write the requirements as user stories to make them easier to
>  understand. What do you think? 
I think this is the most productive message on this thread so far.  Thanks!

josh

> - As a package maintainer, I can only commit to a dist-git repo, if I am
>   in the Fedora packager group.
> - As a package maintainer, I can only commit to a dist-git repo, if I am
>   a maintainer of the branch.
> - As a proven packager, I can commit to all dist-git repos that do not
>   have special restrictions set by FESCo or are retired.
> - As a FESCO member, I can configure exceptions to disallow proven
>   packager access to a dist-git repo.
> - 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
> - As a dist-git repo admin, I cannot remove access to the repo from
>   Fedora infra, Releng or proven packagers without FESCo approval.
> - As a package maintainer, I can easily orphan a dist-git repo or branch
>   to show that it is not maintained anymore.
> - As a package maintainer, I can adopt any orphaned dist-git repo or
>   branch.
> - As a package maintainer, I can easily unretire a retired dist-git repo
>   or branch.
> - As a release engineer, I can easily approve unretire requests for a
>   dist-git repo or branch.
> - As anybody, I can easily see the FAS usernames of maintainers for all
>   branches of a dist-git repo.
> - As a non-releng member, I cannot remove any commits from any dist-git
>   repo that were used to build a Fedora package.
> - As an external user, I can easily get a list of all orphaned or
>   retired dist-git repos and branches.
> - As anybody, I can watch for issues (bugzillas) or PRs that are created
>   for a dist-git repository.
> - As anybody, I can easily get a list of all dist-git repos that I am
>   watching.
> - As anybody, I can easily get a list of all dist-git repos that a
>   specific Fedora account has admin/commit access to.
> - As anybody, when looking at the dist-git repo it is clearly visible
>   which branches are still maintained.
> - As anybody, when I look for a specific branch, EOL branches do not
>   clutter my view.
> - As a package maintainer, I can easily request commit/admin access for
>   a specific branch or dist-git repo.
>
> Also since dist-git is a critical part of our infrastructure, there
> should probably also be some security-related requirements such as:
>
> - As Fedora infra, I can easily audit that no git repo was accessed
>   without authorization.
> - As Fedora infra/security response team, I have access to secure logs
>   to analyse the impact of unauthorized access to all dist-git repos.
> - As anybody, the dist-git web page of a repo points me to Bugzilla to
>   report issues for a repository.
>
> I did not manage to read all other replies, so there might be some
> duplicates but it also seems to me that many of these items were not
> mentioned.
>
> 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]

On Thu, Feb 6, 2020, 21:14 Till Maas <opensource(a)till.name&gt; wrote:

>  On Tue, Jan 21, 2020 at 04:34:37PM +0000, Leigh Griffin wrote:
>
>  > On behalf of the CPE team I want to draw the communities attention to a
>  > recent blog post which you may be impacted by:
>  >  https://communityblog.fedoraproject.org/git-forge-requirements/
>  >
>  > We will be seeking input and requirements in an open and transparent
>  manner
>  > on the future of a git forge solution which will be run by the CPE team
>  on
>
>  Aleksandra's comment made me aware that for dist-git, we do not really
>  need a git forge, it is just that the pagure git forge was used to
>  implement a lot of workflows that pkgdb provided in the past.
>
>  I tried to write the requirements as user stories to make them easier to
>  understand. What do you think?
>  
This is a really welcome contribution thank you!

>  - As a package maintainer, I can only commit to a dist-git repo, if I am
>    in the Fedora packager group.
>  - As a package maintainer, I can only commit to a dist-git repo, if I am
>    a maintainer of the branch.
>  - As a proven packager, I can commit to all dist-git repos that do not
>    have special restrictions set by FESCo or are retired.
>  - As a FESCO member, I can configure exceptions to disallow proven
>    packager access to a dist-git repo.
>  - 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
>  - As a dist-git repo admin, I cannot remove access to the repo from
>    Fedora infra, Releng or proven packagers without FESCo approval.
>  - As a package maintainer, I can easily orphan a dist-git repo or branch
>    to show that it is not maintained anymore.
>  - As a package maintainer, I can adopt any orphaned dist-git repo or
>    branch.
>  - As a package maintainer, I can easily unretire a retired dist-git repo
>    or branch.
>  - As a release engineer, I can easily approve unretire requests for a
>    dist-git repo or branch.
>  - As anybody, I can easily see the FAS usernames of maintainers for all
>    branches of a dist-git repo.
>  - As a non-releng member, I cannot remove any commits from any dist-git
>    repo that were used to build a Fedora package.
>  - As an external user, I can easily get a list of all orphaned or
>    retired dist-git repos and branches.
>  - As anybody, I can watch for issues (bugzillas) or PRs that are created
>    for a dist-git repository.
>  - As anybody, I can easily get a list of all dist-git repos that I am
>    watching.
>  - As anybody, I can easily get a list of all dist-git repos that a
>    specific Fedora account has admin/commit access to.
>  - As anybody, when looking at the dist-git repo it is clearly visible
>    which branches are still maintained.
>  - As anybody, when I look for a specific branch, EOL branches do not
>    clutter my view.
>  - As a package maintainer, I can easily request commit/admin access for
>    a specific branch or dist-git repo.
>
>  Also since dist-git is a critical part of our infrastructure, there
>  should probably also be some security-related requirements such as:
>
>  - As Fedora infra, I can easily audit that no git repo was accessed
>    without authorization.
>  - As Fedora infra/security response team, I have access to secure logs
>    to analyse the impact of unauthorized access to all dist-git repos.
>  - As anybody, the dist-git web page of a repo points me to Bugzilla to
>    report issues for a repository.
>
>  I did not manage to read all other replies, so there might be some
>  duplicates but it also seems to me that many of these items were not
>  mentioned.
>
>  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]
>

[Michal Konecny]

On 06/02/2020 22:13, Till Maas wrote:
>  On Tue, Jan 21, 2020 at 04:34:37PM +0000, Leigh Griffin wrote:
>
> > On behalf of the CPE team I want to draw the communities attention to a
> > recent blog post which you may be impacted by:
> >   https://communityblog.fedoraproject.org/git-forge-requirements/
> >
> > We will be seeking input and requirements in an open and transparent manner
> > on the future of a git forge solution which will be run by the CPE team on
>  Aleksandra's comment made me aware that for dist-git, we do not really
>  need a git forge, it is just that the pagure git forge was used to
>  implement a lot of workflows that pkgdb provided in the past.
>
>  I tried to write the requirements as user stories to make them easier to
>  understand. What do you think?
>
>  - As a package maintainer, I can only commit to a dist-git repo, if I am
>     in the Fedora packager group.
>  - As a package maintainer, I can only commit to a dist-git repo, if I am
>     a maintainer of the branch.
>  - As a proven packager, I can commit to all dist-git repos that do not
>     have special restrictions set by FESCo or are retired.
>  - As a FESCO member, I can configure exceptions to disallow proven
>     packager access to a dist-git repo.
>  - 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
>  - As a dist-git repo admin, I cannot remove access to the repo from
>     Fedora infra, Releng or proven packagers without FESCo approval.
>  - As a package maintainer, I can easily orphan a dist-git repo or branch
>     to show that it is not maintained anymore.
>  - As a package maintainer, I can adopt any orphaned dist-git repo or
>     branch.
>  - As a package maintainer, I can easily unretire a retired dist-git repo
>     or branch.
>  - As a release engineer, I can easily approve unretire requests for a
>     dist-git repo or branch.
>  - As anybody, I can easily see the FAS usernames of maintainers for all
>     branches of a dist-git repo.
>  - As a non-releng member, I cannot remove any commits from any dist-git
>     repo that were used to build a Fedora package.
>  - As an external user, I can easily get a list of all orphaned or
>     retired dist-git repos and branches.
>  - As anybody, I can watch for issues (bugzillas) or PRs that are created
>     for a dist-git repository.
>  - As anybody, I can easily get a list of all dist-git repos that I am
>     watching.
>  - As anybody, I can easily get a list of all dist-git repos that a
>     specific Fedora account has admin/commit access to.
>  - As anybody, when looking at the dist-git repo it is clearly visible
>     which branches are still maintained.
>  - As anybody, when I look for a specific branch, EOL branches do not
>     clutter my view.
>  - As a package maintainer, I can easily request commit/admin access for
>     a specific branch or dist-git repo. 
I add one more requirement based on my own
workflow:
- As fedora user, I want to easily create pull requests to any dist-git 
repo.

Michal
>  Also since dist-git is a critical part of our infrastructure, there
>  should probably also be some security-related requirements such as:
>
>  - As Fedora infra, I can easily audit that no git repo was accessed
>     without authorization.
>  - As Fedora infra/security response team, I have access to secure logs
>     to analyse the impact of unauthorized access to all dist-git repos.
>  - As anybody, the dist-git web page of a repo points me to Bugzilla to
>     report issues for a repository.
>
>  I did not manage to read all other replies, so there might be some
>  duplicates but it also seems to me that many of these items were not
>  mentioned.
>
>  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] 
-- 
Role: Fedora CPE Team - Software Engineer
IRC: mkonecny
FAS: zlopez

[Stephen John Smoogen]

On Fri, 7 Feb 2020 at 03:32, Michal Konecny <mkonecny(a)redhat.com&gt; wrote:

>  On 06/02/2020 22:13, Till Maas wrote:
>   As a package maintainer, I can easily request commit/admin access for
>  >    a specific branch or dist-git repo.
>  I add one more requirement based on my own workflow:
>  - As fedora user, I want to easily create pull requests to any dist-git
>  repo.
>
>  
I think that is the one that was why we went with a 'git forge' in the
first place. It was a requirement for the previous move that anyone with a
fedora account could create a pull request which could be looked at dealt
with by either a package maintainer or a proven packager.

A second one was that having an ability to merge and test pulls in an
automated fashion

-- 
Stephen J Smoogen.

[Kamil Paral]

On Tue, Jan 21, 2020 at 5:40 PM Leigh Griffin <lgriffin(a)redhat.com&gt; wrote:

>  Hey Everyone,
>
>  On behalf of the CPE team I want to draw the communities attention to a
>  recent blog post which you may be impacted by:
>   https://communityblog.fedoraproject.org/git-forge-requirements/
>
>  We will be seeking input and requirements in an open and
>  transparent manner on the future of a git forge solution which will be run
>  by the CPE team on behalf of the Fedora Community. This mail is being sent
>  to the devel, mindshare and council-discuss lists for maximum visibility on
>  a BCC to allow each list have their own views. Please forward it to any
>  other list you may feel is relevant to maximise the exposure.
>
>  Thanks in advance,
>  Leigh
>  
As QA, we don't have many git forge requirements. But this would be really
great to have:
* Be able to create several polls in a single ticket. This would allow us
to vote on blocker/freeze-exception status of proposed bugs.

If we can't have that, we can work around it using a ticket bot, which
would require at least the following:
* API to read tickets in a structured format
* API to add comments and edit the ticket description (ideally also adjust
ticket tags, milestones or some other properties)
* a webhook support to get notified of ticket changes or access to a
message bus

And to add some more to the wishlist:
* good integration to Fedora core services (the account system, messaging)
* open source
* be able to ping or CC someone using @name or similar
* be able to cross-reference projects using projectB#123 or similar
* be able to move tickets across projects