Re: Git Forge Requirements: Please see the Community Blog

[Kamil Paral]

On Tue, Jan 21, 2020 at 5:40 PM 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
>

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Stephen John Smoogen]

On Fri, 7 Feb 2020 at 03:32, Michal Konecny  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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Michal Konecny]

On 06/02/2020 22:13, Till Maas wrote:

On Tue, Jan 21, 2020 at 04:34:37PM +, 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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


--
Role: Fedora CPE Team - Software Engineer
IRC: mkonecny
FAS: zlopez
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Leigh Griffin]

On Thu, Feb 6, 2020, 21:14 Till Maas  wrote:

> On Tue, Jan 21, 2020 at 04:34:37PM +, 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@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Josh Boyer]

On Thu, Feb 6, 2020 at 4:14 PM Till Maas  wrote:
>
> On Tue, Jan 21, 2020 at 04:34:37PM +, 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@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Till Maas]

On Tue, Jan 21, 2020 at 04:34:37PM +, 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Kevin Fenzi]

On Sat, Feb 01, 2020 at 11:15:43AM +0100, Dan Čermák wrote:
> Dan Čermák  writes:
> 
> > Rahul Sundaram  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


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[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


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Leigh Griffin]

On Sat, Feb 1, 2020 at 10:16 AM Dan Čermák 
wrote:

> Dan Čermák  writes:
>
> > Rahul Sundaram  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@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford 

Communications House

Cork Road, Waterford City

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


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Dan Čermák]

Dan Čermák  writes:

> Rahul Sundaram  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…


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Dan Čermák]

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


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Robbie Harwood]

Neal Gompa  writes:

> Michal Konecny  wrote:
>> Vít Ondruch wrote:
>>> Neal Gompa napsal(a):
 Randy Barlow  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


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Leigh Griffin]

On Fri, Jan 31, 2020 at 3:53 PM Rahul Sundaram  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@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford 

Communications House

Cork Road, Waterford City

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


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Neal Gompa]

On Fri, Jan 31, 2020 at 10:23 AM Michal Konecny  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
> >>  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!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[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
 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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


--
Role: Fedora CPE Team - Software Engineer
IRC: mkonecny
FAS: zlopez
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[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


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[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


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Neal Gompa]

On Thu, Jan 30, 2020 at 6:51 PM Randy Barlow
 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!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

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


signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

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


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[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 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Neal Gompa]

On Thu, Jan 30, 2020 at 6:40 AM Iñaki Ucar  wrote:
>
> On Wed, 29 Jan 2020 at 23:23, Leigh Griffin  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!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Iñaki Ucar]

On Wed, 29 Jan 2020 at 23:23, Leigh Griffin  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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[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  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@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[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  > wrote:
>
> On Wed, Jan 29, 2020 at 03:56:08PM +0100, Clement Verna wrote:
> >    On Wed, Jan 29, 2020, 15:23 Julen Landa Alustiza
> >    mailto:jla...@fedoraproject.org>>
> 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


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@lists.fedoraproject.org
> 
> To unsubscribe send an email to
> devel-le...@lists.fedoraproject.org
> 
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Pierre-Yves Chibon]

On Wed, Jan 29, 2020 at 12:52:53PM -0500, Robbie Harwood wrote:
> Julen Landa Alustiza  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


pgp7ggPJoZWO2.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Leigh Griffin]

On Wed, Jan 29, 2020, 17:19 Iñaki Ucar  wrote:

> On Wed, 29 Jan 2020 at 16:23, Leigh Griffin  wrote:
> >
> > On Wed, Jan 29, 2020 at 10:35 AM Iñaki Ucar 
> wrote:
> >>
> >> On Wed, 29 Jan 2020 at 00:08, Leigh Griffin 
> wrote:
> >> >
> >> > On Tue, Jan 28, 2020, 22:06 Iñaki Ucar 
> wrote:
> >> >>
> >> >> On Tue, 28 Jan 2020 at 20:58, Leigh Griffin 
> 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@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Clement Verna]

On Wed, 29 Jan 2020 at 18:26, Stephen John Smoogen  wrote:

> On Wed, 29 Jan 2020 at 11:38, Clement Verna 
> wrote:
> >
> >
> >
> > On Wed, 29 Jan 2020 at 16:18, Pierre-Yves Chibon 
> 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@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List 

Re: Git Forge Requirements: Please see the Community Blog

[Robbie Harwood]

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


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Clement Verna]

On Wed, 29 Jan 2020 at 16:56, Adam Williamson 
wrote:

> On Wed, 2020-01-29 at 15:56 +0100, Clement Verna wrote:
> > On Wed, Jan 29, 2020, 15:23 Julen Landa Alustiza <
> jla...@fedoraproject.org>
> > 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@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Stephen John Smoogen]

On Wed, 29 Jan 2020 at 11:38, Clement Verna  wrote:
>
>
>
> On Wed, 29 Jan 2020 at 16:18, Pierre-Yves Chibon  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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Clement Verna]

On Wed, 29 Jan 2020 at 16:18, Julen Landa Alustiza 
wrote:

>
>
> 2020(e)ko urtarrilaren 29(a) 15:56:08 (CET)-(e)an, Clement Verna <
> cve...@fedoraproject.org>-(e)k hau idatzi zuen:
> >On Wed, Jan 29, 2020, 15:23 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.
> >>
> >
> >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 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Iñaki Ucar]

On Wed, 29 Jan 2020 at 16:23, Leigh Griffin  wrote:
>
> On Wed, Jan 29, 2020 at 10:35 AM Iñaki Ucar  wrote:
>>
>> On Wed, 29 Jan 2020 at 00:08, Leigh Griffin  wrote:
>> >
>> > On Tue, Jan 28, 2020, 22:06 Iñaki Ucar  wrote:
>> >>
>> >> On Tue, 28 Jan 2020 at 20:58, Leigh Griffin  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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Clement Verna]

On Wed, 29 Jan 2020 at 16:18, Pierre-Yves Chibon 
wrote:

> On Wed, Jan 29, 2020 at 03:56:08PM +0100, Clement Verna wrote:
> >On Wed, Jan 29, 2020, 15:23 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.
> >
> >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@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[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 
> -(e)k hau idatzi zuen:
> > On Wed, Jan 29, 2020, 15:23 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.
> > > 
> > 
> > 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-with-zuul

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/5b518d107d62e0fa9462c4ef518d05b34758f65c/f/.zuul.yaml
https://pagure.io/fedora-qa/os-autoinst-distri-fedora/blob/05cfd0aff616e0216afa35a63ac875cd4cbbe88b/f/ci/tox.yaml

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Adam Williamson]

On Wed, 2020-01-29 at 15:56 +0100, Clement Verna wrote:
> On Wed, Jan 29, 2020, 15:23 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.
> > 
> 
> 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Florian Weimer]

* Neal Gompa:

> On Wed, Jan 29, 2020 at 10:07 AM 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.
>>
>
> 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Leigh Griffin]

On Wed, Jan 29, 2020 at 3:30 PM Pierre-Yves Chibon 
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@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford 

Communications House

Cork Road, Waterford City

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


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Neal Gompa]

On Wed, Jan 29, 2020 at 10:07 AM 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.
>

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!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[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
> 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Julen Landa Alustiza]

2020(e)ko urtarrilaren 29(a) 15:56:08 (CET)-(e)an, Clement Verna 
-(e)k hau idatzi zuen:
>On Wed, Jan 29, 2020, 15:23 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.
>>
>
>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 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Leigh Griffin]

On Wed, Jan 29, 2020 at 10:35 AM Iñaki Ucar  wrote:

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

Correct and it's why we said this line, which you might have missed:
"While we can make exceptions to the mission statement, we first need to
know why we should consider a specific exception."


> 2. CPE is not gonna commit a development team to Pagure.
>

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


> 3. The feature gap is big and growing, and basically Pagure is gonna
> die because of this (and the document goes on saying that you're not
> trying to solve the feature gap).
>

Pagure is a standalone community project. Our choice is not killing Pagure
and irrespective of the decision we make I personally hope it stays strong
and grows. Stating the feature gap is big and growing is factual, with no
committed team we are behind on it.

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


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


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


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


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


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


> Only that, as it happens, Pagure has grown to cover
> their necessities with more or less success, which doesn't necessarily
> mean that a forge is the best solution for all of them (as, again,
> others have pointed out already). But the ODF only lists forges as
> solutions.
>

And if the requirements are stated we can have an open conversation about
what does suit it. I get that things have organically grown around a forge
that may / may not be the best fit for it now, lets examine that as a
conversation when we know how people are using it. This topic is focused on
what git forge the CPE team will choose based on requirements gathered but
if there is a means to address a requirement gap by another tool that is
not a forge, then that's a really good outcome of the conversation.

>
> So solutions for what? What are we talking about here? Requirements
> for src.fp.org? Requirements for things that are in pagure.io? All?
> Other?
>
> Iñaki
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford 

Communications House

Cork Road, Waterford City

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

Re: Git Forge Requirements: Please see the Community Blog

[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 
-(e)k hau idatzi zuen:
>On Wed, Jan 29, 2020 at 9:29 AM Pierre-Yves Chibon
> 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@lists.fedoraproject.org
>To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>Fedora Code of Conduct:
>https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>List Archives:
>https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

--
Julen Landa Alustiza ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Clement Verna]

On Wed, Jan 29, 2020, 15:23 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.
>

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@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[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  
> 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Neal Gompa]

On Wed, Jan 29, 2020 at 9:29 AM Pierre-Yves Chibon  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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[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,
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Clement Verna]

On Wed, 29 Jan 2020 at 11:36, Iñaki Ucar  wrote:

> On Wed, 29 Jan 2020 at 00:08, Leigh Griffin  wrote:
> >
> > On Tue, Jan 28, 2020, 22:06 Iñaki Ucar  wrote:
> >>
> >> On Tue, 28 Jan 2020 at 20:58, Leigh Griffin 
> 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@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Iñaki Ucar]

On Wed, 29 Jan 2020 at 00:08, Leigh Griffin  wrote:
>
> On Tue, Jan 28, 2020, 22:06 Iñaki Ucar  wrote:
>>
>> On Tue, 28 Jan 2020 at 20:58, Leigh Griffin  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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Nicolas Mailhot via devel]

Le mardi 21 janvier 2020 à 16:34 +, 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Leigh Griffin]

On Tue, Jan 28, 2020, 22:06 Iñaki Ucar  wrote:

> On Tue, 28 Jan 2020 at 20:58, Leigh Griffin  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@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Iñaki Ucar]

On Tue, 28 Jan 2020 at 20:58, Leigh Griffin  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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Leigh Griffin]

On Tue, Jan 28, 2020, 15:58 Adam Saleh  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  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/master/ODF-community.md
>
>
>
> On Fri, Jan 24, 2020 at 4:56 PM Michael Catanzaro 
> wrote:
>
>> On Wed, Jan 22, 2020 at 11:37 am, Michael Catanzaro
>>  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@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Stephen John Smoogen]

On Tue, 28 Jan 2020 at 12:17, Martin Kolman  wrote:
>
> On Wed, 2020-01-22 at 13:28 -0500, Neal Gompa wrote:
> > On Wed, Jan 22, 2020 at 12:58 PM Milan Crha  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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[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  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@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[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  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/master/ODF-community.md



On Fri, Jan 24, 2020 at 4:56 PM Michael Catanzaro 
wrote:

> On Wed, Jan 22, 2020 at 11:37 am, Michael Catanzaro
>  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@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Michael Catanzaro]

On Wed, Jan 22, 2020 at 11:37 am, Michael Catanzaro 
 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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[John Florian]

On 2020-01-23 11:26, Bruno Wolff III wrote:

On Wed, Jan 22, 2020 at 10:28:52 -0500,
 Neal Gompa  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.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Bruno Wolff III]

On Wed, Jan 22, 2020 at 10:28:52 -0500,
 Neal Gompa  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.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Neal Gompa]

On Wed, Jan 22, 2020 at 5:21 PM Felix Schwarz
 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!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Neal Gompa]

On Wed, Jan 22, 2020 at 12:58 PM Milan Crha  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!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Robbie Harwood]

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


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Michael Catanzaro]

On Wed, Jan 22, 2020 at 9:12 am, Neal Gompa  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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Neal Gompa]

On Wed, Jan 22, 2020 at 10:46 AM Michael Catanzaro  wrote:
>
> On Wed, Jan 22, 2020 at 5:00 am, Neal Gompa  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!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Michael Catanzaro]

On Wed, Jan 22, 2020 at 5:00 am, Neal Gompa  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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[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@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Neal Gompa]

On Wed, Jan 22, 2020 at 10:22 AM Michael Watters  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!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Felipe Borges]

On Wed, Jan 22, 2020 at 3:43 PM Clement Verna  wrote:
>
>
>
> On Wed, 22 Jan 2020 at 15:37, Ernestas Kulik  wrote:
>>
>> On Wed, 2020-01-22 at 09:12 -0500, Neal Gompa wrote:
>> > On Wed, Jan 22, 2020 at 9:08 AM Ernestas Kulik 
>> > 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@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: 
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Clement Verna]

On Wed, 22 Jan 2020 at 15:37, Ernestas Kulik  wrote:

> On Wed, 2020-01-22 at 09:12 -0500, Neal Gompa wrote:
> > On Wed, Jan 22, 2020 at 9:08 AM Ernestas Kulik 
> > 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@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[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 
> 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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Neal Gompa]

On Wed, Jan 22, 2020 at 9:08 AM Ernestas Kulik  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!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Aleksandra Fedorova]

On Wed, Jan 22, 2020 at 2:21 PM Miro Hrončok  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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Florian Weimer]

* Miro Hrončok:

>> The red X isn't a relevant indicator.  This commit was merged and has it,
>> too:
>>
>>
>
> 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[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: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

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

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:

   


And is not merged.


But this is not shown clearly in the commit:

   

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

   


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: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

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

  

But this is not shown clearly in the commit:

  

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

  

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Aleksandra Fedorova]

On Wed, Jan 22, 2020 at 1:25 PM Miro Hrončok  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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

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

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: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[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


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[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: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Aleksandra Fedorova]

On Wed, Jan 22, 2020 at 12:38 PM Miro Hrončok  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
>
>
> 

Re: Git Forge Requirements: Please see the Community Blog

[Clement Verna]

On Wed, 22 Jan 2020 at 12:38, Miro Hrončok  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: +420777974800
> IRC: mhroncok
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org