3:10 p.m.
---
title: CPE Weekly status email
tags: CPE Weekly, email
---
# CPE Weekly: 2020-03-06
Background:
The Community Platform Engineering group is the Red Hat team combining
IT and release engineering from Fedora and CentOS. Our goal is to keep
core servers and services running and maintained, build releases, and
other strategic tasks that need more dedicated time than volunteers
can give.
For better communication, we will be giving weekly reports to the
CentOS and Fedora communities about the general tasks and work being
done. Also for better communication between our groups we have
created #redhat-cpe on Freenode IRC! Please feel free to catch us
there, a mail has landed on both the CentOS and Fedora devel lists
with context here.
## Fedora Updates
* Freeze is over!
* New version of pagure (5.9.0) has been released and deployed in
staging and on pagure.io
* Document being worked on about how to onboard new CI systems in
Fedora - this is a work in progress!
https://hackmd.io/5gk_kHFhSR6sKa1huPA-4Q
### Request for Review
* Fedora magazine: Article proposals about Silverblue rebase to F32
https://pagure.io/fedora-magazine-proposals/issue/59
* Packit integration in the-new-hotness
https://github.com/packit-service/packit/issues/689
* KeepassXC flatpak issue https://pagure.io/flatpak-module-tools/issue/6
### Data Centre Move
* Communishift will be unavailable from 2020-04-13 until 2020-05-08
* Check out our detailed move shedule here
https://hackmd.io/R3EkjzVyTG2TYwQvkfzYrA?sync=&type=
* Covid-19 has seen restrictions added to the data centres we are
moving from and to, however we are unaffected as of yet for the move.
* If or when our timelines become affected, we will inform you
immediately of any outages, downtimes, etc a delay could cause.
* Thank you for your understanding at this particularly uncertain and
worrying times.
### AAA Replacement
* We are nearly complete in our phase one development!
* Below are some of the features the team have developed since
beginning the project in mid-Jan
* UI where people register and login
* Add groups function
* Change personal details
* Enroll OPT
* Reset password
* View group owner details
* Use a search engine
* Our next steps in this project is to demo to the team for feedback
and then continue to develop CentOS authentication, more user focused
features, request for more feedback and test, test test!
### CI/CD
* Monitor-gating is now running in production and has already caught a
couple of issues with bodhi (both in stg and in prod)!
* Rpmautospec
* This is in review as a Fedora package:
https://bugzilla.redhat.com/show_bug.cgi?id=1816124
* Work progressing on Koji tagging plugin (post-build), full use
case support for bumping releases
* The team hope to deploy this in staging soon!
### Sustaining Team
* Mbbox
* Some progress on CRD for koji-builder and koji-hub components
has been made this week
* Bodhi 5.2.2 released
* Some issues with celery tasks & rawhide monitoring has been
super useful with this.
* Compose Tracker enhancement
* Tagging issues have been resolved
* Ability to ping maintainers
* Fedora Minimal Compose
* Odcs-backend-releng01 has been provisioned to enable testing
## CentOS Updates
### CentOS
* ppc64le and aarch64, 8 and 8-stream nodes now available in cico for
tenants to checkout. -- Email sent to ci-user list
* New signing for SIGs (through https://cbs.centos.org) live this week!
### CentOS Stream
* Qt5.12 pushed in response to an internal request
* NetworkManager re-imported
### Other Updates
#### GitForge Decision
* After evaluating over 300 user stories from multiple stakeholders we
have aligned on a decision for the Gitforge that CPE will operate for
the coming years. We are opting for Gitlab for our dist git and
project hosting and will continue to run pagure.io with community
assistance.
* Check out our GitForge decision on the Fedora Community blog
https://communityblog.fedoraproject.org/
* And at the CentOS blog page
https://blog.centos.org/2020/03/git-forge-decision/
* Keep an eye out for mails in the coming months to the devel lists as
we plan transitions and next steps with GitLab
* We would like to express our sincere thank you to all who
contributed requirements to us!
As always, feedback is welcome, and we will continue to look at ways
to improve the delivery and readability of this weekly report.
Have a great weekend!
Aoife
Source: https://hackmd.io/8iV7PilARSG68Tqv8CzKOQ
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
10:47 p.m.
New subject: The Git forge decision (was CPE Weekly: 2020-03-28)
On Sat, Mar 28, 2020 at 4:12 PM Aoife Moloney <amoloney(a)redhat.com> wrote:
### Other Updates
#### GitForge Decision
* After evaluating over 300 user stories from multiple stakeholders we
have aligned on a decision for the Gitforge that CPE will operate for
the coming years. We are opting for Gitlab for our dist git and
project hosting and will continue to run pagure.io with community
assistance.
* Check out our GitForge decision on the Fedora Community blog
https://communityblog.fedoraproject.org/
* And at the CentOS blog page
https://blog.centos.org/2020/03/git-forge-decision/
* Keep an eye out for mails in the coming months to the devel lists as
we plan transitions and next steps with GitLab
* We would like to express our sincere thank you to all who
contributed requirements to us!
I'm going to start with the delivery of this decision sucked. If I
hadn't been alerted to look for this by other folks due to my advocacy
and community building work around Pagure, I would *not* have known
that the decision had been made. This is in contrast to the *big deal*
that was made about starting this "decision process". I don't know if
there were folks counting on nobody noticing this or not, but this is
not a good way to deliver effectively a major decision like this. I
also absolutely *refuse* to deal with the fact that this thread was
split into three mailing lists. All three are connected to this
thread, and I will take responses from all of them and follow them
accordingly.
Enough about that, let's talk about the actual decision.
So, you're going with GitLab. It's interesting to note that the
particulars about going to GitLab are not even figured out. It is
curious that "SAAS" is mentioned very prominently. That made me a bit
more curious, so I looked at the "final" feature requirements.
Needless to say, I was extremely disappointed.
To put it bluntly, there are *zero* free and open source solutions
that satisfy your needs. From this, I understood why you said GitLab
and SaaS. You want GitLab Ultimate, the proprietary solution that
includes several extra features on top to satisfy the following
requirements (quoted from your blog post):
* There is a need for CentOS Stream to integrate with a kernel
workflow that is an automated bot driven merging solution (merge trains). This allows for
richer CI capabilities and minimizes the need for human interaction
* Gitlab allows for project planning capability which could make multiple trackers such
as Taiga redundant, allowing for the planning and tracking to reside within the repo. It
would enrich the current ticket based solution that Pagure has evolved into for some
groups
These two requirements *alone* automatically force us to GitLab
Enterprise Ultimate Edition, as there is no other solution available
that satisfies those requirements in one product. Merge trains *is* a
feature of Pagure when combined with Zuul, but GitLab's project
planning features do not exist in *any* FOSS product, including GitLab
CE (or GitLab Core as they call it now).
There are mentions of other work that CPE team wants to do to better
improve Fedora. Okay, sure. I even agree with some of them. And the
time bomb that is FAS is definitely worth the attention (note that I
am somewhat involved in the development of the Fedora AAA solution and
am also working on trying to develop a community around it so it
doesn't implode like virtually every other project under the Fedora
umbrella, more on *that* a bit later).
However, nobody has given me or anyone else in the Pagure community
(which yes, is more than Pierre-Yves, thank you very much!) any
concrete details of deficiencies they'd see that is not satisfiable by
the community within a year before now. I've spent a little over a day
analyzing the user stories and thinking about the gaps between Pagure
and what the community wants, and I want to give some perspective here
for some of these. I'm happy to accept refutations and other details
to further enhance the color of these stories, of course.
5
As a RH Developer
I need the ability to privately comment on a PR
so that confidential information does not leak outside Red Hat
Ignoring the mountainous levels of terrible problems that such a
feature causes us *now* in the Red Hat Bugzilla, Pierre-Yves and I
were literally discussing this with a Mageian who was interested in
this feature for Pagure weeks ago. We had identified the feature as
not difficult to implement but also simultaneously nobody really
*wanted it now*. It surprises me that this is something that should be
considered an important feature to preserve. It's actually a very
*rare* feature, and does not exist in any forge today, presumably
because it's actually a horrifically bad idea and antithetical to open
development. GitLab itself lacks this feature, in all variants.
16
As a general user
I want to be able to create a bot/service account
That integrates with the gitforge in the same way as a human does
This is a nice ask, but it's not a reasonably easy one to implement
with our current system. This is a problem I've struggled with at
$DAYJOB with GitLab as well, and frankly, if you have account
integration with a single-sign-on system (which virtually all
large-scale Git forge instances do), you can't really easily have this
without causing major problems. Not the least of which is how you
resolve account namespace collisions. There are also problems with
maintaining and auditing, too. But it's certainly something I'd like
to see in any forge (note that none implement this today either).
29
As a General User
I want to access repos fully over https
For environments where SSH is blocked
I would be really curious if the Red Hat Infrastructure Security guys
have changed their opinion on this after four years of blocking the
development of this feature in Pagure. The two major reasons we don't
have this in Pagure are:
* There is a very strong push to not provide a way to bypass the SSO
(ignoring the fact that SSH keys are effectively a bypass, but most
security people are two-faced about this anyway)
* There is a very strong push to not provide LDAP integration so that
the required HTTP(S) Git proxy server would not be able to be
implemented.
Note that for GitLab, unless you configure it to have access to LDAP
or set up personal access tokens, you cannot use HTTP(S) push at all.
Once again, this totally bypasses SSO. If the same rules that applied
to Pagure apply to GitLab, nobody is getting this feature anytime soon
with GitLab. If the attitude toward this feature has finally changed,
I'd love to know.
Also, for those who don't know, Fedora's Dist-Git supports HTTPS push,
and has for almost a year:
https://fedoraproject.org/wiki/Infrastructure/HTTPS-commits
This is done by *forcing* an SSO flow for *fedpkg* itself and
leveraging it as a credential and auth point. Unfortunately, this is
not a general purpose feature because there's not an easy way to do
that, so it's unavailable on pagure.io at this time. This mechanism
for HTTP push is *not* possible with GitLab, and would be quite
difficult to implement due to the crazy architecture internally. But
if more *normal* HTTPS is acceptable (like through auth tokens or LDAP
auth), then this is something that could be relatively quickly added
to Pagure (there was some old code that never got merged two years
ago, I still have it archived somewhere...).
31
As a General User
I can request access rights to a repository
So that I can contribute in a low friction manner
I honestly don't know entirely what this means. Are we talking about
having partial commit access (commit access to only some branches)? If
so, there's a PR out for implementing this in Pagure under review:
https://pagure.io/pagure/pull-request/4786
34
As a General User
I want a mobile native app
To allow me contribute while away from my desk
I don't have words for this... You folks know that only GitHub.com has
an official mobile app, right? And the experience is not great...
🤦♂️
42
As a General User
want a GUI to interface with the system as well as a CLI
so new users have an easier way to interface with it
I'd like to point out that most popular GUIs for Git stuff are not
forge specific and do not even do much for forge integration. But
sure...?
44
As a General User
I want a temporary file (gist)
So that I can share code easily
There seems to be a misunderstanding here... Gists are not temporary.
They're lightweight *permanent* Git repos (in GitHub). GitLab stores
them (called Snippets) as permanent things in the database (not a Git
repo). Are you trying to conflate pastebin use-cases here? That's
probably a very bad idea...
46
As a General User
I want to be notified of CVEs in my code
so that I can stay on top of critical vulnerabilities
There are *zero* FOSS solutions for this in the forge space. This
feature does *not* exist below GitLab Ultimate (the former Gemnasium
service was integrated into it).
47
As a General User
I want integrated keyword support
to allow me automate a lot of my actions such as a rebuild / retest
This is not a forge feature, this is a CI service feature. And note,
GitLab CI does not support this.
49
As a General User
I want to gain analytics and insights from my code
so that I can have historic context to make decisions moving forward
GitLab Enterprise features...
51
As a General User
I would like to track my work in an Agile manner
allowing me centralise all my planning in my forge and gain insights into how I am
working.
GitLab Enterprise features, as mentioned earlier.
56
As a General User
I want registry integration
so that I can store dependencies
No, you don't. You *really* don't want this. Are you *sure* you know
what you're asking for? You're suggesting three things here:
* OSS solutions for this (including Fedora's own package/container
infrastructure and hosted quay.io) are not good enough
* You are ready to have even more arbitrary data stored in the Git
system that may not follow our legal compliance
* You are willing to pay the cost of having even more data stored
57
As a General User
I want the ability to have a private branch
So that I do not need to leave the code tree I am already in
Just so everyone is *crystal clear*: you literally cannot do this. Git
does not have a concept of private branches or private refs within a
repository. You can have private forks, of course. And Pagure supports
those just fine, just like GitLab and GitHub do.
(also note, we *intentionally* do not have private repos turned on...
if we want this, we could just flip a switch...)
62
As a General User
I want automerges when specific acceptance criteria are met
So that I do not need manual intervention
So... Mergify then? This is not *currently* a GitLab feature, and
Mergify does not support GitLab, last I checked. Only GitHub.com. It's
been on my bucket for a while to look at extending Mergify to support
Pagure for this, as it's a really nice feature...
I want to take a moment to reflect on something that has been on my
mind for a while now: Fedora has not done a good job being an umbrella
organization. As an organization, we have done a huge disservice to
all Fedora-affiliated projects by not allocating any community
development effort or marketing effort. I know that Matthew Miller
feels Fedora should evolve to being an operating systems factory[1]
and to some extent that isn't a bad thought. But the Fedora Project
was always intended to be more than just the Fedora Linux
distribution. It has always been intended to be a home for Free and
Open Source innovation. In a Hacker News thread last year[2], I had
reflected on how proud I have been to be part of Fedora because we, as
a community, weren't willing to just give up like so many others do.
When FOSS solutions were inadequate, we built better ones. We've
invented things that didn't exist before, and jump-started
conversations about concepts that people didn't think of before. But
there has been a bit of a dark side to this for Fedora. We've rarely
given our projects an opportunity to grow beyond us. Off the top of my
head, the *only* project that technically *started* in Fedora and
became successful was Ansible. And if I'm being totally brutally
honest, it was only successful because the engineers who were
passionate about it had to quit Red Hat and create AnsibleWorks to
push it to success. It was successful *despite* Fedora. Maybe soon
we'll be able to add HyperKitty and Postorius to that, as I've been
seeing deployments of that come online over the past few months. It's
taken a while, but HyperKitty is finally taking off. There was one
person I talked to who told me that HyperKitty made mailing lists
enjoyable and she didn't know the project came from Fedora originally.
Again, seeing success despite Fedora.
When I talk to folks in other communities and show them some of the
infrastructure projects we've developed as part of trying to build
communities around them, I've literally had people tell me that they
wish they had known we made them before, because it solved all their
problems they were struggling with. That's both amazingly uplifting
and terribly depressing at the same time. I'm not even putting in a
lot of effort and we get so much more out of it. It didn't take a lot
for me to get openSUSE interested in our new AAA solution and
contributing. That tells me that we're just not trying. And really,
that's obvious. Even a simple comparison of the Fedora and openSUSE
project landing pages show that Fedora gives zero attention to the
projects that exist under its umbrella. When you look at the openSUSE
landing page, the distribution and major software projects under the
umbrella are all broadcasted there. It makes it so much easier to
discover and generate interest. I'm not saying I love every aspect of
the openSUSE marketing. Far from it! But this is one thing they do
right that we do terribly wrong. And then we sit back and wonder why
our projects fail to generate interest beyond a few folks in Fedora
itself. It's a self-fulfilling prophecy. This is something we need to
fix for *all* our projects: present and future.
In the end, I think the biggest disappointment of this process is that
it feels like it demonstrates that Fedora leadership and management is
not as committed to its mission and vision[3] as I hoped it was. I
realize that I should not be surprised by this. Most of the leadership
and management are no longer the idealistic people they were when they
first became involved. And it's even harder to be idealistic when it's
so easy to give in when you work for "open source company" that
increasingly uses proprietary software to manage its workflow (to be
fair, I think at this point virtually all major companies do this,
which more or less demonstrates the amoral nature of these entities).
Maybe I'm just an old remnant of a bygone era, but I personally remain
somewhat idealistic, even as I have progressed over the years. I also
remain hopeful that other members of the community are of similar
mind. And perhaps this is a bit of a fool's hope, but I hope the CPE
team reconsiders their decision, or at least would be willing to
provide more context on the gaps they felt pushed them over so they
could be prioritized for Pagure development (and maybe we can develop
them fast enough so that we don't have to switch...).
I think this is also an important indicator that Open Source has *not*
won and it is *not* the default. People who keep saying otherwise need
to seriously look hard at the landscape and realize that we have a
long way to go before Open Source becomes the true default. It
behooves us to become cognizant of this and push for freedom whenever
and wherever we can.
As for me? Well, I will do my best to try to help develop the Pagure
community. I'm still committed to assisting the Free Software
Foundation and other communities with using and contributing to
Pagure. I hope others within the community will consider helping too.
Pagure provides unique features that do not exist in any other forge,
in large part because it is driven by an ideal that open data and
freedom should be core tenants of software project management. And
hey, I hear whispers of new Pagure instances being set up all the
time! We're doing something right here, and it'd be a shame to
squander it.
Heh, the irony is that I started using and contributing to Pagure
*because* I was burned by GitLab...
[1]:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
[2]: https://news.ycombinator.com/item?id=19356307
[3]: https://docs.fedoraproject.org/en-US/project/
--
真実はいつも一つ！/ Always, there's only one truth!
1:40 a.m.
New subject: The Git forge decision (was CPE Weekly: 2020-03-28)
On Sun, Mar 29, 2020, at 11:47 PM, Neal Gompa wrote:
On Sat, Mar 28, 2020 at 4:12 PM Aoife Moloney
<amoloney(a)redhat.com> wrote:
>
> ### Other Updates
>
> #### GitForge Decision
> * After evaluating over 300 user stories from multiple stakeholders we
> have aligned on a decision for the Gitforge that CPE will operate for
> the coming years. We are opting for Gitlab for our dist git and
> project hosting and will continue to run pagure.io with community
> assistance.
> * Check out our GitForge decision on the Fedora Community blog
> https://communityblog.fedoraproject.org/
> * And at the CentOS blog page
> https://blog.centos.org/2020/03/git-forge-decision/
> * Keep an eye out for mails in the coming months to the devel lists as
> we plan transitions and next steps with GitLab
> * We would like to express our sincere thank you to all who
> contributed requirements to us!
>
>
I'm going to start with the delivery of this decision sucked. If I
hadn't been alerted to look for this by other folks due to my advocacy
and community building work around Pagure, I would *not* have known
that the decision had been made. This is in contrast to the *big deal*
that was made about starting this "decision process". I don't know if
Indeed, it seems like the lead got buried. I, too, had missed the announcement. I guess
I'll make more effort to read these weekly status updates.
there were folks counting on nobody noticing this or not, but this
is
not a good way to deliver effectively a major decision like this. I
also absolutely *refuse* to deal with the fact that this thread was
split into three mailing lists. All three are connected to this
thread, and I will take responses from all of them and follow them
accordingly.
Enough about that, let's talk about the actual decision.
Thanks for your comprehensive response here and for all the work you've done to drive
Pagure forward.
V/r,
James Cassell
>
> So, you're going with GitLab. It's interesting to note that the
> particulars about going to GitLab are not even figured out. It is
> curious that "SAAS" is mentioned very prominently. That made me a bit
> more curious, so I looked at the "final" feature requirements.
> Needless to say, I was extremely disappointed.
>
> To put it bluntly, there are *zero* free and open source solutions
> that satisfy your needs. From this, I understood why you said GitLab
> and SaaS. You want GitLab Ultimate, the proprietary solution that
> includes several extra features on top to satisfy the following
> requirements (quoted from your blog post):
>
> > * There is a need for CentOS Stream to integrate with a kernel workflow that is
an automated bot driven merging solution (merge trains). This allows for richer CI
capabilities and minimizes the need for human interaction
> > * Gitlab allows for project planning capability which could make multiple
trackers such as Taiga redundant, allowing for the planning and tracking to reside within
the repo. It would enrich the current ticket based solution that Pagure has evolved into
for some groups
>
> These two requirements *alone* automatically force us to GitLab
> Enterprise Ultimate Edition, as there is no other solution available
> that satisfies those requirements in one product. Merge trains *is* a
> feature of Pagure when combined with Zuul, but GitLab's project
> planning features do not exist in *any* FOSS product, including GitLab
> CE (or GitLab Core as they call it now).
>
> There are mentions of other work that CPE team wants to do to better
> improve Fedora. Okay, sure. I even agree with some of them. And the
> time bomb that is FAS is definitely worth the attention (note that I
> am somewhat involved in the development of the Fedora AAA solution and
> am also working on trying to develop a community around it so it
> doesn't implode like virtually every other project under the Fedora
> umbrella, more on *that* a bit later).
>
> However, nobody has given me or anyone else in the Pagure community
> (which yes, is more than Pierre-Yves, thank you very much!) any
> concrete details of deficiencies they'd see that is not satisfiable by
> the community within a year before now. I've spent a little over a day
> analyzing the user stories and thinking about the gaps between Pagure
> and what the community wants, and I want to give some perspective here
> for some of these. I'm happy to accept refutations and other details
> to further enhance the color of these stories, of course.
>
> > 5
> > As a RH Developer
> > I need the ability to privately comment on a PR
> > so that confidential information does not leak outside Red Hat
>
> Ignoring the mountainous levels of terrible problems that such a
> feature causes us *now* in the Red Hat Bugzilla, Pierre-Yves and I
> were literally discussing this with a Mageian who was interested in
> this feature for Pagure weeks ago. We had identified the feature as
> not difficult to implement but also simultaneously nobody really
> *wanted it now*. It surprises me that this is something that should be
> considered an important feature to preserve. It's actually a very
> *rare* feature, and does not exist in any forge today, presumably
> because it's actually a horrifically bad idea and antithetical to open
> development. GitLab itself lacks this feature, in all variants.
>
> > 16
> > As a general user
> > I want to be able to create a bot/service account
> > That integrates with the gitforge in the same way as a human does
>
> This is a nice ask, but it's not a reasonably easy one to implement
> with our current system. This is a problem I've struggled with at
> $DAYJOB with GitLab as well, and frankly, if you have account
> integration with a single-sign-on system (which virtually all
> large-scale Git forge instances do), you can't really easily have this
> without causing major problems. Not the least of which is how you
> resolve account namespace collisions. There are also problems with
> maintaining and auditing, too. But it's certainly something I'd like
> to see in any forge (note that none implement this today either).
>
> > 29
> > As a General User
> > I want to access repos fully over https
> > For environments where SSH is blocked
>
> I would be really curious if the Red Hat Infrastructure Security guys
> have changed their opinion on this after four years of blocking the
> development of this feature in Pagure. The two major reasons we don't
> have this in Pagure are:
>
> * There is a very strong push to not provide a way to bypass the SSO
> (ignoring the fact that SSH keys are effectively a bypass, but most
> security people are two-faced about this anyway)
> * There is a very strong push to not provide LDAP integration so that
> the required HTTP(S) Git proxy server would not be able to be
> implemented.
>
> Note that for GitLab, unless you configure it to have access to LDAP
> or set up personal access tokens, you cannot use HTTP(S) push at all.
> Once again, this totally bypasses SSO. If the same rules that applied
> to Pagure apply to GitLab, nobody is getting this feature anytime soon
> with GitLab. If the attitude toward this feature has finally changed,
> I'd love to know.
>
> Also, for those who don't know, Fedora's Dist-Git supports HTTPS push,
> and has for almost a year:
> https://fedoraproject.org/wiki/Infrastructure/HTTPS-commits
>
> This is done by *forcing* an SSO flow for *fedpkg* itself and
> leveraging it as a credential and auth point. Unfortunately, this is
> not a general purpose feature because there's not an easy way to do
> that, so it's unavailable on pagure.io at this time. This mechanism
> for HTTP push is *not* possible with GitLab, and would be quite
> difficult to implement due to the crazy architecture internally. But
> if more *normal* HTTPS is acceptable (like through auth tokens or LDAP
> auth), then this is something that could be relatively quickly added
> to Pagure (there was some old code that never got merged two years
> ago, I still have it archived somewhere...).
>
> > 31
> > As a General User
> > I can request access rights to a repository
> > So that I can contribute in a low friction manner
>
> I honestly don't know entirely what this means. Are we talking about
> having partial commit access (commit access to only some branches)? If
> so, there's a PR out for implementing this in Pagure under review:
> https://pagure.io/pagure/pull-request/4786
>
>
> > 34
> > As a General User
> > I want a mobile native app
> > To allow me contribute while away from my desk
>
> I don't have words for this... You folks know that only GitHub.com has
> an official mobile app, right? And the experience is not great...
> 🤦♂️
>
> > 42
> > As a General User
> > want a GUI to interface with the system as well as a CLI
> > so new users have an easier way to interface with it
>
> I'd like to point out that most popular GUIs for Git stuff are not
> forge specific and do not even do much for forge integration. But
> sure...?
>
> > 44
> > As a General User
> > I want a temporary file (gist)
> > So that I can share code easily
>
> There seems to be a misunderstanding here... Gists are not temporary.
> They're lightweight *permanent* Git repos (in GitHub). GitLab stores
> them (called Snippets) as permanent things in the database (not a Git
> repo). Are you trying to conflate pastebin use-cases here? That's
> probably a very bad idea...
>
> > 46
> > As a General User
> > I want to be notified of CVEs in my code
> > so that I can stay on top of critical vulnerabilities
>
> There are *zero* FOSS solutions for this in the forge space. This
> feature does *not* exist below GitLab Ultimate (the former Gemnasium
> service was integrated into it).
>
> > 47
> > As a General User
> > I want integrated keyword support
> > to allow me automate a lot of my actions such as a rebuild / retest
>
> This is not a forge feature, this is a CI service feature. And note,
> GitLab CI does not support this.
>
> > 49
> > As a General User
> > I want to gain analytics and insights from my code
> > so that I can have historic context to make decisions moving forward
>
> GitLab Enterprise features...
>
> > 51
> > As a General User
> > I would like to track my work in an Agile manner
> > allowing me centralise all my planning in my forge and gain insights into how I
am working.
>
> GitLab Enterprise features, as mentioned earlier.
>
> > 56
> > As a General User
> > I want registry integration
> > so that I can store dependencies
>
> No, you don't. You *really* don't want this. Are you *sure* you know
> what you're asking for? You're suggesting three things here:
>
> * OSS solutions for this (including Fedora's own package/container
> infrastructure and hosted quay.io) are not good enough
> * You are ready to have even more arbitrary data stored in the Git
> system that may not follow our legal compliance
> * You are willing to pay the cost of having even more data stored
>
> > 57
> > As a General User
> > I want the ability to have a private branch
> > So that I do not need to leave the code tree I am already in
>
> Just so everyone is *crystal clear*: you literally cannot do this. Git
> does not have a concept of private branches or private refs within a
> repository. You can have private forks, of course. And Pagure supports
> those just fine, just like GitLab and GitHub do.
>
> (also note, we *intentionally* do not have private repos turned on...
> if we want this, we could just flip a switch...)
>
> > 62
> > As a General User
> > I want automerges when specific acceptance criteria are met
> > So that I do not need manual intervention
>
> So... Mergify then? This is not *currently* a GitLab feature, and
> Mergify does not support GitLab, last I checked. Only GitHub.com. It's
> been on my bucket for a while to look at extending Mergify to support
> Pagure for this, as it's a really nice feature...
>
> I want to take a moment to reflect on something that has been on my
> mind for a while now: Fedora has not done a good job being an umbrella
> organization. As an organization, we have done a huge disservice to
> all Fedora-affiliated projects by not allocating any community
> development effort or marketing effort. I know that Matthew Miller
> feels Fedora should evolve to being an operating systems factory[1]
> and to some extent that isn't a bad thought. But the Fedora Project
> was always intended to be more than just the Fedora Linux
> distribution. It has always been intended to be a home for Free and
> Open Source innovation. In a Hacker News thread last year[2], I had
> reflected on how proud I have been to be part of Fedora because we, as
> a community, weren't willing to just give up like so many others do.
> When FOSS solutions were inadequate, we built better ones. We've
> invented things that didn't exist before, and jump-started
> conversations about concepts that people didn't think of before. But
> there has been a bit of a dark side to this for Fedora. We've rarely
> given our projects an opportunity to grow beyond us. Off the top of my
> head, the *only* project that technically *started* in Fedora and
> became successful was Ansible. And if I'm being totally brutally
> honest, it was only successful because the engineers who were
> passionate about it had to quit Red Hat and create AnsibleWorks to
> push it to success. It was successful *despite* Fedora. Maybe soon
> we'll be able to add HyperKitty and Postorius to that, as I've been
> seeing deployments of that come online over the past few months. It's
> taken a while, but HyperKitty is finally taking off. There was one
> person I talked to who told me that HyperKitty made mailing lists
> enjoyable and she didn't know the project came from Fedora originally.
> Again, seeing success despite Fedora.
>
> When I talk to folks in other communities and show them some of the
> infrastructure projects we've developed as part of trying to build
> communities around them, I've literally had people tell me that they
> wish they had known we made them before, because it solved all their
> problems they were struggling with. That's both amazingly uplifting
> and terribly depressing at the same time. I'm not even putting in a
> lot of effort and we get so much more out of it. It didn't take a lot
> for me to get openSUSE interested in our new AAA solution and
> contributing. That tells me that we're just not trying. And really,
> that's obvious. Even a simple comparison of the Fedora and openSUSE
> project landing pages show that Fedora gives zero attention to the
> projects that exist under its umbrella. When you look at the openSUSE
> landing page, the distribution and major software projects under the
> umbrella are all broadcasted there. It makes it so much easier to
> discover and generate interest. I'm not saying I love every aspect of
> the openSUSE marketing. Far from it! But this is one thing they do
> right that we do terribly wrong. And then we sit back and wonder why
> our projects fail to generate interest beyond a few folks in Fedora
> itself. It's a self-fulfilling prophecy. This is something we need to
> fix for *all* our projects: present and future.
>
> In the end, I think the biggest disappointment of this process is that
> it feels like it demonstrates that Fedora leadership and management is
> not as committed to its mission and vision[3] as I hoped it was. I
> realize that I should not be surprised by this. Most of the leadership
> and management are no longer the idealistic people they were when they
> first became involved. And it's even harder to be idealistic when it's
> so easy to give in when you work for "open source company" that
> increasingly uses proprietary software to manage its workflow (to be
> fair, I think at this point virtually all major companies do this,
> which more or less demonstrates the amoral nature of these entities).
> Maybe I'm just an old remnant of a bygone era, but I personally remain
> somewhat idealistic, even as I have progressed over the years. I also
> remain hopeful that other members of the community are of similar
> mind. And perhaps this is a bit of a fool's hope, but I hope the CPE
> team reconsiders their decision, or at least would be willing to
> provide more context on the gaps they felt pushed them over so they
> could be prioritized for Pagure development (and maybe we can develop
> them fast enough so that we don't have to switch...).
>
> I think this is also an important indicator that Open Source has *not*
> won and it is *not* the default. People who keep saying otherwise need
> to seriously look hard at the landscape and realize that we have a
> long way to go before Open Source becomes the true default. It
> behooves us to become cognizant of this and push for freedom whenever
> and wherever we can.
>
> As for me? Well, I will do my best to try to help develop the Pagure
> community. I'm still committed to assisting the Free Software
> Foundation and other communities with using and contributing to
> Pagure. I hope others within the community will consider helping too.
> Pagure provides unique features that do not exist in any other forge,
> in large part because it is driven by an ideal that open data and
> freedom should be core tenants of software project management. And
> hey, I hear whispers of new Pagure instances being set up all the
> time! We're doing something right here, and it'd be a shame to
> squander it.
>
> Heh, the irony is that I started using and contributing to Pagure
> *because* I was burned by GitLab...
>
>
> [1]:
>
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
> [2]: https://news.ycombinator.com/item?id=19356307
> [3]: https://docs.fedoraproject.org/en-US/project/
>
2:07 a.m.
New subject: The Git forge decision (was CPE Weekly: 2020-03-28)
20/3/30 08:40(e)an, James Cassell igorleak idatzi zuen:
On Sun, Mar 29, 2020, at 11:47 PM, Neal Gompa wrote:
> On Sat, Mar 28, 2020 at 4:12 PM Aoife Moloney <amoloney(a)redhat.com> wrote:
>>
>> ### Other Updates
>>
>> #### GitForge Decision
>> * After evaluating over 300 user stories from multiple stakeholders we
>> have aligned on a decision for the Gitforge that CPE will operate for
>> the coming years. We are opting for Gitlab for our dist git and
>> project hosting and will continue to run pagure.io with community
>> assistance.
>> * Check out our GitForge decision on the Fedora Community blog
>> https://communityblog.fedoraproject.org/
>> * And at the CentOS blog page
>> https://blog.centos.org/2020/03/git-forge-decision/
>> * Keep an eye out for mails in the coming months to the devel lists as
>> we plan transitions and next steps with GitLab
>> * We would like to express our sincere thank you to all who
>> contributed requirements to us!
>>
>>
>
> I'm going to start with the delivery of this decision sucked. If I
> hadn't been alerted to look for this by other folks due to my advocacy
> and community building work around Pagure, I would *not* have known
> that the decision had been made. This is in contrast to the *big deal*
> that was made about starting this "decision process". I don't know if
Indeed, it seems like the lead got buried. I, too, had missed the announcement. I guess
I'll make more effort to read these weekly status updates.
From the original blow post:
https://communityblog.fedoraproject.org/git-forge-requirements/
How will information be gathered and disseminated?
It is recommended that both Fedora Council and CentOS Board gather
input and
present their concerns in a manner that is consistent with how
their communities work. The RHEL and CPE requirements will be gathered
through Red Hat communication mechanisms and presented publicly via a
HackMD file to ensure transparency in their source. This will be
published and distributed in due course. Additionally, a live video call
and associated IRC meetings will be held and advertised in advance to
discuss the requirements, talk about concerns and address any questions.
We want transparency to be at the heart of this decision.
Good promise, where are all those? No discussion, no advances, no proper
information dissemination, nothing :(
This announcement is not even on the first position on communityblog. I
was expecting at least the same announcement visibility level for the
final announcement that we had for the initial one: first position on
communityblog blog + exclusive threads on the mailing lists.
Well, actually I was waiting for those live discussions
> there were folks counting on nobody noticing this or not, but this is
> not a good way to deliver effectively a major decision like this. I
> also absolutely *refuse* to deal with the fact that this thread was
> split into three mailing lists. All three are connected to this
> thread, and I will take responses from all of them and follow them
> accordingly.
>
> Enough about that, let's talk about the actual decision.
Thanks for your comprehensive response here and for all the work you've done to drive
Pagure forward.
V/r,
James Cassell
>
> So, you're going with GitLab. It's interesting to note that the
> particulars about going to GitLab are not even figured out. It is
> curious that "SAAS" is mentioned very prominently. That made me a bit
> more curious, so I looked at the "final" feature requirements.
> Needless to say, I was extremely disappointed.
>
> To put it bluntly, there are *zero* free and open source solutions
> that satisfy your needs. From this, I understood why you said GitLab
> and SaaS. You want GitLab Ultimate, the proprietary solution that
> includes several extra features on top to satisfy the following
> requirements (quoted from your blog post):
>
>> * There is a need for CentOS Stream to integrate with a kernel workflow that is
an automated bot driven merging solution (merge trains). This allows for richer CI
capabilities and minimizes the need for human interaction
>> * Gitlab allows for project planning capability which could make multiple
trackers such as Taiga redundant, allowing for the planning and tracking to reside within
the repo. It would enrich the current ticket based solution that Pagure has evolved into
for some groups
>
> These two requirements *alone* automatically force us to GitLab
> Enterprise Ultimate Edition, as there is no other solution available
> that satisfies those requirements in one product. Merge trains *is* a
> feature of Pagure when combined with Zuul, but GitLab's project
> planning features do not exist in *any* FOSS product, including GitLab
> CE (or GitLab Core as they call it now).
>
> There are mentions of other work that CPE team wants to do to better
> improve Fedora. Okay, sure. I even agree with some of them. And the
> time bomb that is FAS is definitely worth the attention (note that I
> am somewhat involved in the development of the Fedora AAA solution and
> am also working on trying to develop a community around it so it
> doesn't implode like virtually every other project under the Fedora
> umbrella, more on *that* a bit later).
>
> However, nobody has given me or anyone else in the Pagure community
> (which yes, is more than Pierre-Yves, thank you very much!) any
> concrete details of deficiencies they'd see that is not satisfiable by
> the community within a year before now. I've spent a little over a day
> analyzing the user stories and thinking about the gaps between Pagure
> and what the community wants, and I want to give some perspective here
> for some of these. I'm happy to accept refutations and other details
> to further enhance the color of these stories, of course.
>
>> 5
>> As a RH Developer
>> I need the ability to privately comment on a PR
>> so that confidential information does not leak outside Red Hat
>
> Ignoring the mountainous levels of terrible problems that such a
> feature causes us *now* in the Red Hat Bugzilla, Pierre-Yves and I
> were literally discussing this with a Mageian who was interested in
> this feature for Pagure weeks ago. We had identified the feature as
> not difficult to implement but also simultaneously nobody really
> *wanted it now*. It surprises me that this is something that should be
> considered an important feature to preserve. It's actually a very
> *rare* feature, and does not exist in any forge today, presumably
> because it's actually a horrifically bad idea and antithetical to open
> development. GitLab itself lacks this feature, in all variants.
>
>> 16
>> As a general user
>> I want to be able to create a bot/service account
>> That integrates with the gitforge in the same way as a human does
>
> This is a nice ask, but it's not a reasonably easy one to implement
> with our current system. This is a problem I've struggled with at
> $DAYJOB with GitLab as well, and frankly, if you have account
> integration with a single-sign-on system (which virtually all
> large-scale Git forge instances do), you can't really easily have this
> without causing major problems. Not the least of which is how you
> resolve account namespace collisions. There are also problems with
> maintaining and auditing, too. But it's certainly something I'd like
> to see in any forge (note that none implement this today either).
>
>> 29
>> As a General User
>> I want to access repos fully over https
>> For environments where SSH is blocked
>
> I would be really curious if the Red Hat Infrastructure Security guys
> have changed their opinion on this after four years of blocking the
> development of this feature in Pagure. The two major reasons we don't
> have this in Pagure are:
>
> * There is a very strong push to not provide a way to bypass the SSO
> (ignoring the fact that SSH keys are effectively a bypass, but most
> security people are two-faced about this anyway)
> * There is a very strong push to not provide LDAP integration so that
> the required HTTP(S) Git proxy server would not be able to be
> implemented.
>
> Note that for GitLab, unless you configure it to have access to LDAP
> or set up personal access tokens, you cannot use HTTP(S) push at all.
> Once again, this totally bypasses SSO. If the same rules that applied
> to Pagure apply to GitLab, nobody is getting this feature anytime soon
> with GitLab. If the attitude toward this feature has finally changed,
> I'd love to know.
>
> Also, for those who don't know, Fedora's Dist-Git supports HTTPS push,
> and has for almost a year:
> https://fedoraproject.org/wiki/Infrastructure/HTTPS-commits
>
> This is done by *forcing* an SSO flow for *fedpkg* itself and
> leveraging it as a credential and auth point. Unfortunately, this is
> not a general purpose feature because there's not an easy way to do
> that, so it's unavailable on pagure.io at this time. This mechanism
> for HTTP push is *not* possible with GitLab, and would be quite
> difficult to implement due to the crazy architecture internally. But
> if more *normal* HTTPS is acceptable (like through auth tokens or LDAP
> auth), then this is something that could be relatively quickly added
> to Pagure (there was some old code that never got merged two years
> ago, I still have it archived somewhere...).
>
>> 31
>> As a General User
>> I can request access rights to a repository
>> So that I can contribute in a low friction manner
>
> I honestly don't know entirely what this means. Are we talking about
> having partial commit access (commit access to only some branches)? If
> so, there's a PR out for implementing this in Pagure under review:
> https://pagure.io/pagure/pull-request/4786
>
>
>> 34
>> As a General User
>> I want a mobile native app
>> To allow me contribute while away from my desk
>
> I don't have words for this... You folks know that only GitHub.com has
> an official mobile app, right? And the experience is not great...
> 🤦♂️
>
>> 42
>> As a General User
>> want a GUI to interface with the system as well as a CLI
>> so new users have an easier way to interface with it
>
> I'd like to point out that most popular GUIs for Git stuff are not
> forge specific and do not even do much for forge integration. But
> sure...?
>
>> 44
>> As a General User
>> I want a temporary file (gist)
>> So that I can share code easily
>
> There seems to be a misunderstanding here... Gists are not temporary.
> They're lightweight *permanent* Git repos (in GitHub). GitLab stores
> them (called Snippets) as permanent things in the database (not a Git
> repo). Are you trying to conflate pastebin use-cases here? That's
> probably a very bad idea...
>
>> 46
>> As a General User
>> I want to be notified of CVEs in my code
>> so that I can stay on top of critical vulnerabilities
>
> There are *zero* FOSS solutions for this in the forge space. This
> feature does *not* exist below GitLab Ultimate (the former Gemnasium
> service was integrated into it).
>
>> 47
>> As a General User
>> I want integrated keyword support
>> to allow me automate a lot of my actions such as a rebuild / retest
>
> This is not a forge feature, this is a CI service feature. And note,
> GitLab CI does not support this.
>
>> 49
>> As a General User
>> I want to gain analytics and insights from my code
>> so that I can have historic context to make decisions moving forward
>
> GitLab Enterprise features...
>
>> 51
>> As a General User
>> I would like to track my work in an Agile manner
>> allowing me centralise all my planning in my forge and gain insights into how I
am working.
>
> GitLab Enterprise features, as mentioned earlier.
>
>> 56
>> As a General User
>> I want registry integration
>> so that I can store dependencies
>
> No, you don't. You *really* don't want this. Are you *sure* you know
> what you're asking for? You're suggesting three things here:
>
> * OSS solutions for this (including Fedora's own package/container
> infrastructure and hosted quay.io) are not good enough
> * You are ready to have even more arbitrary data stored in the Git
> system that may not follow our legal compliance
> * You are willing to pay the cost of having even more data stored
>
>> 57
>> As a General User
>> I want the ability to have a private branch
>> So that I do not need to leave the code tree I am already in
>
> Just so everyone is *crystal clear*: you literally cannot do this. Git
> does not have a concept of private branches or private refs within a
> repository. You can have private forks, of course. And Pagure supports
> those just fine, just like GitLab and GitHub do.
>
> (also note, we *intentionally* do not have private repos turned on...
> if we want this, we could just flip a switch...)
>
>> 62
>> As a General User
>> I want automerges when specific acceptance criteria are met
>> So that I do not need manual intervention
>
> So... Mergify then? This is not *currently* a GitLab feature, and
> Mergify does not support GitLab, last I checked. Only GitHub.com. It's
> been on my bucket for a while to look at extending Mergify to support
> Pagure for this, as it's a really nice feature...
>
> I want to take a moment to reflect on something that has been on my
> mind for a while now: Fedora has not done a good job being an umbrella
> organization. As an organization, we have done a huge disservice to
> all Fedora-affiliated projects by not allocating any community
> development effort or marketing effort. I know that Matthew Miller
> feels Fedora should evolve to being an operating systems factory[1]
> and to some extent that isn't a bad thought. But the Fedora Project
> was always intended to be more than just the Fedora Linux
> distribution. It has always been intended to be a home for Free and
> Open Source innovation. In a Hacker News thread last year[2], I had
> reflected on how proud I have been to be part of Fedora because we, as
> a community, weren't willing to just give up like so many others do.
> When FOSS solutions were inadequate, we built better ones. We've
> invented things that didn't exist before, and jump-started
> conversations about concepts that people didn't think of before. But
> there has been a bit of a dark side to this for Fedora. We've rarely
> given our projects an opportunity to grow beyond us. Off the top of my
> head, the *only* project that technically *started* in Fedora and
> became successful was Ansible. And if I'm being totally brutally
> honest, it was only successful because the engineers who were
> passionate about it had to quit Red Hat and create AnsibleWorks to
> push it to success. It was successful *despite* Fedora. Maybe soon
> we'll be able to add HyperKitty and Postorius to that, as I've been
> seeing deployments of that come online over the past few months. It's
> taken a while, but HyperKitty is finally taking off. There was one
> person I talked to who told me that HyperKitty made mailing lists
> enjoyable and she didn't know the project came from Fedora originally.
> Again, seeing success despite Fedora.
>
> When I talk to folks in other communities and show them some of the
> infrastructure projects we've developed as part of trying to build
> communities around them, I've literally had people tell me that they
> wish they had known we made them before, because it solved all their
> problems they were struggling with. That's both amazingly uplifting
> and terribly depressing at the same time. I'm not even putting in a
> lot of effort and we get so much more out of it. It didn't take a lot
> for me to get openSUSE interested in our new AAA solution and
> contributing. That tells me that we're just not trying. And really,
> that's obvious. Even a simple comparison of the Fedora and openSUSE
> project landing pages show that Fedora gives zero attention to the
> projects that exist under its umbrella. When you look at the openSUSE
> landing page, the distribution and major software projects under the
> umbrella are all broadcasted there. It makes it so much easier to
> discover and generate interest. I'm not saying I love every aspect of
> the openSUSE marketing. Far from it! But this is one thing they do
> right that we do terribly wrong. And then we sit back and wonder why
> our projects fail to generate interest beyond a few folks in Fedora
> itself. It's a self-fulfilling prophecy. This is something we need to
> fix for *all* our projects: present and future.
>
> In the end, I think the biggest disappointment of this process is that
> it feels like it demonstrates that Fedora leadership and management is
> not as committed to its mission and vision[3] as I hoped it was. I
> realize that I should not be surprised by this. Most of the leadership
> and management are no longer the idealistic people they were when they
> first became involved. And it's even harder to be idealistic when it's
> so easy to give in when you work for "open source company" that
> increasingly uses proprietary software to manage its workflow (to be
> fair, I think at this point virtually all major companies do this,
> which more or less demonstrates the amoral nature of these entities).
> Maybe I'm just an old remnant of a bygone era, but I personally remain
> somewhat idealistic, even as I have progressed over the years. I also
> remain hopeful that other members of the community are of similar
> mind. And perhaps this is a bit of a fool's hope, but I hope the CPE
> team reconsiders their decision, or at least would be willing to
> provide more context on the gaps they felt pushed them over so they
> could be prioritized for Pagure development (and maybe we can develop
> them fast enough so that we don't have to switch...).
>
> I think this is also an important indicator that Open Source has *not*
> won and it is *not* the default. People who keep saying otherwise need
> to seriously look hard at the landscape and realize that we have a
> long way to go before Open Source becomes the true default. It
> behooves us to become cognizant of this and push for freedom whenever
> and wherever we can.
>
> As for me? Well, I will do my best to try to help develop the Pagure
> community. I'm still committed to assisting the Free Software
> Foundation and other communities with using and contributing to
> Pagure. I hope others within the community will consider helping too.
> Pagure provides unique features that do not exist in any other forge,
> in large part because it is driven by an ideal that open data and
> freedom should be core tenants of software project management. And
> hey, I hear whispers of new Pagure instances being set up all the
> time! We're doing something right here, and it'd be a shame to
> squander it.
>
> Heh, the irony is that I started using and contributing to Pagure
> *because* I was burned by GitLab...
>
>
> [1]:
>
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
> [2]: https://news.ycombinator.com/item?id=19356307
> [3]: https://docs.fedoraproject.org/en-US/project/
>
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Julen Landa Alustiza <jlanda(a)fedoraproject.org>
4:27 a.m.
New subject: The Git forge decision (was CPE Weekly: 2020-03-28)
On Mon, 30 Mar 2020 at 09:15, Julen Landa Alustiza
<jlanda(a)fedoraproject.org> wrote:
20/3/30 08:40(e)an, James Cassell igorleak idatzi zuen:
>
> On Sun, Mar 29, 2020, at 11:47 PM, Neal Gompa wrote:
>> On Sat, Mar 28, 2020 at 4:12 PM Aoife Moloney <amoloney(a)redhat.com>
wrote:
>>>
>>> ### Other Updates
>>>
>>> #### GitForge Decision
>>> * After evaluating over 300 user stories from multiple stakeholders we
>>> have aligned on a decision for the Gitforge that CPE will operate for
>>> the coming years. We are opting for Gitlab for our dist git and
>>> project hosting and will continue to run pagure.io with community
>>> assistance.
>>> * Check out our GitForge decision on the Fedora Community blog
>>> https://communityblog.fedoraproject.org/
>>> * And at the CentOS blog page
>>> https://blog.centos.org/2020/03/git-forge-decision/
>>> * Keep an eye out for mails in the coming months to the devel lists as
>>> we plan transitions and next steps with GitLab
>>> * We would like to express our sincere thank you to all who
>>> contributed requirements to us!
>>>
>>>
>>
>> I'm going to start with the delivery of this decision sucked. If I
>> hadn't been alerted to look for this by other folks due to my advocacy
>> and community building work around Pagure, I would *not* have known
>> that the decision had been made. This is in contrast to the *big deal*
>> that was made about starting this "decision process". I don't know
if
>
> Indeed, it seems like the lead got buried. I, too, had missed the announcement. I
guess I'll make more effort to read these weekly status updates.
I missed that too! This is not a way to communicate such a big
decision. Plus we went from requirements gathering to the final
decision? Where's the rest of the process?
From the original blow post:
https://communityblog.fedoraproject.org/git-forge-requirements/
> How will information be gathered and disseminated?
>
> It is recommended that both Fedora Council and CentOS Board gather
input and present their concerns in a manner that is consistent with how
their communities work. The RHEL and CPE requirements will be gathered
through Red Hat communication mechanisms and presented publicly via a
HackMD file to ensure transparency in their source. This will be
published and distributed in due course. Additionally, a live video call
and associated IRC meetings will be held and advertised in advance to
discuss the requirements, talk about concerns and address any questions.
> We want transparency to be at the heart of this decision.
Good promise, where are all those? No discussion, no advances, no proper
information dissemination, nothing :(
This announcement is not even on the first position on communityblog. I
was expecting at least the same announcement visibility level for the
final announcement that we had for the initial one: first position on
communityblog blog + exclusive threads on the mailing lists.
Well, actually I was waiting for those live discussions
Moreover, Leigh Griffin said in the previous devel thread:
And if the requirements are stated we can have an open conversation
about
what does suit it.
So I was also waiting for those open discussions about the
requirements gathered. I was really looking forward to reading what
Neal (as he's doing now) and others had to say about the requirements
*before* any decision was taken, and how each tool covers them or not,
and what kind of effort would require to cover it in the latter case.
This is *very* disappointing.
In the final announcement in the Community Blog, this is listed as a
requirement:
24/7 availability in an SLA model and not hosted by the CPE team
freeing
up resourcing and removing the need to staff a dedicated team for a git
forge SLA which would necessitate a follow-the-sun ops model and a
heavy investment in stability and observability of the Pagure solution.
Ok, so I suppose that's it, check mate. I recall that several people
in the initial thread argued that self-hosting was important to avoid
depending on third-parties. Obviously this requirement comes directly
from CPE and supersedes any of such arguments. Also it automatically
rules Pagure out, so GitLab is the only option even if it doesn't
cover many other requierements (as per Neal's analysis).
In the initial thread, I said:
When I first read the post, my thought was: wow, what a convoluted
and
abstruse way of saying "we want to abandon Pagure".
Now that feeling has only been reinforced.
Iñaki
4:57 a.m.
New subject: The Git forge decision (was CPE Weekly: 2020-03-28)
20/3/30 11:27(e)an, Iñaki Ucar igorleak idatzi zuen:
On Mon, 30 Mar 2020 at 09:15, Julen Landa Alustiza
<jlanda(a)fedoraproject.org> wrote:
>
> 20/3/30 08:40(e)an, James Cassell igorleak idatzi zuen:
>>
>> On Sun, Mar 29, 2020, at 11:47 PM, Neal Gompa wrote:
>>> On Sat, Mar 28, 2020 at 4:12 PM Aoife Moloney <amoloney(a)redhat.com>
wrote:
>>>>
>>>> ### Other Updates
>>>>
>>>> #### GitForge Decision
>>>> * After evaluating over 300 user stories from multiple stakeholders we
>>>> have aligned on a decision for the Gitforge that CPE will operate for
>>>> the coming years. We are opting for Gitlab for our dist git and
>>>> project hosting and will continue to run pagure.io with community
>>>> assistance.
>>>> * Check out our GitForge decision on the Fedora Community blog
>>>> https://communityblog.fedoraproject.org/
>>>> * And at the CentOS blog page
>>>> https://blog.centos.org/2020/03/git-forge-decision/
>>>> * Keep an eye out for mails in the coming months to the devel lists as
>>>> we plan transitions and next steps with GitLab
>>>> * We would like to express our sincere thank you to all who
>>>> contributed requirements to us!
>>>>
>>>>
>>>
>>> I'm going to start with the delivery of this decision sucked. If I
>>> hadn't been alerted to look for this by other folks due to my advocacy
>>> and community building work around Pagure, I would *not* have known
>>> that the decision had been made. This is in contrast to the *big deal*
>>> that was made about starting this "decision process". I don't
know if
>>
>> Indeed, it seems like the lead got buried. I, too, had missed the announcement. I
guess I'll make more effort to read these weekly status updates.
I missed that too! This is not a way to communicate such a big
decision. Plus we went from requirements gathering to the final
decision? Where's the rest of the process?
> From the original blow post:
> https://communityblog.fedoraproject.org/git-forge-requirements/
>
>> How will information be gathered and disseminated?
>>
>> It is recommended that both Fedora Council and CentOS Board gather
> input and present their concerns in a manner that is consistent with how
> their communities work. The RHEL and CPE requirements will be gathered
> through Red Hat communication mechanisms and presented publicly via a
> HackMD file to ensure transparency in their source. This will be
> published and distributed in due course. Additionally, a live video call
> and associated IRC meetings will be held and advertised in advance to
> discuss the requirements, talk about concerns and address any questions.
>> We want transparency to be at the heart of this decision.
>
> Good promise, where are all those? No discussion, no advances, no proper
> information dissemination, nothing :(
>
> This announcement is not even on the first position on communityblog. I
> was expecting at least the same announcement visibility level for the
> final announcement that we had for the initial one: first position on
> communityblog blog + exclusive threads on the mailing lists.
>
> Well, actually I was waiting for those live discussions
Moreover, Leigh Griffin said in the previous devel thread:
> And if the requirements are stated we can have an open conversation about
> what does suit it.
So I was also waiting for those open discussions about the
requirements gathered. I was really looking forward to reading what
Neal (as he's doing now) and others had to say about the requirements
*before* any decision was taken, and how each tool covers them or not,
and what kind of effort would require to cover it in the latter case.
This is *very* disappointing.
In the final announcement in the Community Blog, this is listed as a
requirement:
> 24/7 availability in an SLA model and not hosted by the CPE team freeing
> up resourcing and removing the need to staff a dedicated team for a git
> forge SLA which would necessitate a follow-the-sun ops model and a
> heavy investment in stability and observability of the Pagure solution.
Ok, so I suppose that's it, check mate. I recall that several people
in the initial thread argued that self-hosting was important to avoid
depending on third-parties. Obviously this requirement comes directly
from CPE and supersedes any of such arguments. Also it automatically
rules Pagure out, so GitLab is the only option even if it doesn't
cover many other requierements (as per Neal's analysis).
Moreover, the SLA requirement for the git forge is bigger than the SLE
of CPE even for the most critical internal services:
https://fedora-infra-docs.readthedocs.io/en/latest/sysadmin-guide/sles/Ge...
So, is the outsourced option the unique real option? Why all this then?
How can you ask for an 24/7 SLA on the gitforge while we have a lower
expectation for the AAA service that the forge will depend on to be
functional?
In the initial thread, I said:
> When I first read the post, my thought was: wow, what a convoluted and
> abstruse way of saying "we want to abandon Pagure".
Now that feeling has only been reinforced.
Iñaki
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Julen Landa Alustiza <jlanda(a)fedoraproject.org>
6 a.m.
New subject: The Git forge decision (was CPE Weekly: 2020-03-28)
On Mon, Mar 30, 2020 at 10:29 AM Iñaki Ucar <iucar(a)fedoraproject.org> wrote:
On Mon, 30 Mar 2020 at 09:15, Julen Landa Alustiza
<jlanda(a)fedoraproject.org> wrote:
>
> 20/3/30 08:40(e)an, James Cassell igorleak idatzi zuen:
> >
> > On Sun, Mar 29, 2020, at 11:47 PM, Neal Gompa wrote:
> >> On Sat, Mar 28, 2020 at 4:12 PM Aoife Moloney <amoloney(a)redhat.com>
wrote:
> >>>
> >>> ### Other Updates
> >>>
> >>> #### GitForge Decision
> >>> * After evaluating over 300 user stories from multiple stakeholders
we
> >>> have aligned on a decision for the Gitforge that CPE will operate for
> >>> the coming years. We are opting for Gitlab for our dist git and
> >>> project hosting and will continue to run pagure.io with community
> >>> assistance.
> >>> * Check out our GitForge decision on the Fedora Community blog
> >>> https://communityblog.fedoraproject.org/
> >>> * And at the CentOS blog page
> >>> https://blog.centos.org/2020/03/git-forge-decision/
> >>> * Keep an eye out for mails in the coming months to the devel lists
as
> >>> we plan transitions and next steps with GitLab
> >>> * We would like to express our sincere thank you to all who
> >>> contributed requirements to us!
> >>>
> >>>
> >>
> >> I'm going to start with the delivery of this decision sucked. If I
> >> hadn't been alerted to look for this by other folks due to my advocacy
> >> and community building work around Pagure, I would *not* have known
> >> that the decision had been made. This is in contrast to the *big deal*
> >> that was made about starting this "decision process". I don't
know if
> >
> > Indeed, it seems like the lead got buried. I, too, had missed the
announcement. I guess I'll make more effort to read these weekly status
updates.
I missed that too! This is not a way to communicate such a big
decision. Plus we went from requirements gathering to the final
decision? Where's the rest of the process?
Here were the original phases after the Ideation Phase ended:
CPE Management evaluate the requests and where necessary may instruct the
CPE team to begin a Planning and Research phase to take in the inputs from
the Ideation Phase
We had internal research on the requirements within the team as planned.
CPE design, develop and test proof of concept plans based on the decision
made by CPE Management and share this with the Community
We did not create any Proof of Concept as the weight of the decision
shifted towards Gitlab when we completed our analysis and this sharing of
the decision is to help us work out technical details and next steps
CPE closes the ODF with a decision made and a path forward for our git forge
The decision is made to go with Gitlab but as noted in the blog and in
other replies we haven't worked out the details or path forward yet. This
is that step in the process now.
> From the original blow post:
> https://communityblog.fedoraproject.org/git-forge-requirements/
>
> > How will information be gathered and disseminated?
> >
> > It is recommended that both Fedora Council and CentOS Board gather
> input and present their concerns in a manner that is consistent with how
> their communities work. The RHEL and CPE requirements will be gathered
> through Red Hat communication mechanisms and presented publicly via a
> HackMD file to ensure transparency in their source. This will be
> published and distributed in due course. Additionally, a live video call
> and associated IRC meetings will be held and advertised in advance to
> discuss the requirements, talk about concerns and address any questions.
> > We want transparency to be at the heart of this decision.
>
> Good promise, where are all those? No discussion, no advances, no proper
> information dissemination, nothing :(
>
> This announcement is not even on the first position on communityblog. I
> was expecting at least the same announcement visibility level for the
> final announcement that we had for the initial one: first position on
> communityblog blog + exclusive threads on the mailing lists.
>
> Well, actually I was waiting for those live discussions
Moreover, Leigh Griffin said in the previous devel thread:
> And if the requirements are stated we can have an open conversation about
> what does suit it.
So I was also waiting for those open discussions about the
requirements gathered.
We had several threads on them from the Fedora perspective on both devel
and council lists.
I was really looking forward to reading what
Neal (as he's doing now) and others had to say about the requirements
*before* any decision was taken, and how each tool covers them or not,
and what kind of effort would require to cover it in the latter case.
This is *very* disappointing.
I'm sorry this is disappointing but even reading the analysis by Neal it is
looking at the merit of the requirement and not looking at the fact that it
is valuable to somebody. Each stakeholder group had their own means to
discuss and debate the merits and had them rolled into CPE who in turn
analysed them and published the full story list.
In the final announcement in the Community Blog, this is listed as a
requirement:
> 24/7 availability in an SLA model and not hosted by the CPE team freeing
> up resourcing and removing the need to staff a dedicated team for a git
> forge SLA which would necessitate a follow-the-sun ops model and a
> heavy investment in stability and observability of the Pagure solution.
Ok, so I suppose that's it, check mate. I recall that several people
in the initial thread argued that self-hosting was important to avoid
depending on third-parties. Obviously this requirement comes
directly
from CPE and supersedes any of such arguments.
There were several stakeholders whom requested rapid response on fixes and
availability guarantees. This requirement did not come exclusively from CPE.
Also it automatically
rules Pagure out,
It did not rule Pagure out as one viable route for us was to invest our
team into Pagure. Ultimately that was not possible based on the asks of the
CPE team from our stakeholders which includes the Fedora Community asks.
so GitLab is the only option even if it doesn't
cover many other requierements (as per Neal's analysis).
Github had a much better fit with respect to the overall requirements but
was eliminated before deeper analysis was performed
In the initial thread, I said:
> When I first read the post, my thought was: wow, what a convoluted and
> abstruse way of saying "we want to abandon Pagure".
Now that feeling has only been reinforced.
Iñaki
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Leigh Griffin
Engineering Manager
Red Hat Waterford <https://www.redhat.com/>
Communications House
Cork Road, Waterford City
lgriffin(a)redhat.com
M: +353877545162 IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs> redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>
6:08 a.m.
New subject: The Git forge decision (was CPE Weekly: 2020-03-28)
On Mon, Mar 30, 2020 at 7:02 AM Leigh Griffin <lgriffin(a)redhat.com> wrote:
>
> I was really looking forward to reading what
> Neal (as he's doing now) and others had to say about the requirements
> *before* any decision was taken, and how each tool covers them or not,
> and what kind of effort would require to cover it in the latter case.
> This is *very* disappointing.
I'm sorry this is disappointing but even reading the analysis by Neal it is looking
at the merit of the requirement and not looking at the fact that it is valuable to
somebody. Each stakeholder group had their own means to discuss and debate the merits and
had them rolled into CPE who in turn analysed them and published the full story list.
I'm not bothering with the other aspects because there's no point. You
*already* decided. Why should I evaluate the merits of the
requirements when you've already decided they mattered enough to use
them for deciding for GitLab?
--
真実はいつも一つ！/ Always, there's only one truth!
6:26 a.m.
New subject: The Git forge decision (was CPE Weekly: 2020-03-28)
On Mon, 30 Mar 2020 at 13:20, Neal Gompa <ngompa13(a)gmail.com> wrote:
On Mon, Mar 30, 2020 at 7:02 AM Leigh Griffin <lgriffin(a)redhat.com> wrote:
>
>>
>> I was really looking forward to reading what
>> Neal (as he's doing now) and others had to say about the requirements
>> *before* any decision was taken, and how each tool covers them or not,
>> and what kind of effort would require to cover it in the latter case.
>> This is *very* disappointing.
>
> I'm sorry this is disappointing but even reading the analysis by Neal it is
looking at the merit of the requirement and not looking at the fact that it is valuable to
somebody. Each stakeholder group had their own means to discuss and debate the merits and
had them rolled into CPE who in turn analysed them and published the full story list.
I'm not bothering with the other aspects because there's no point. You
*already* decided. Why should I evaluate the merits of the
requirements when you've already decided they mattered enough to use
them for deciding for GitLab?
I think he's arguing the opposite: that you shouldn't be evaluating
the merits of the requirements published just because they are
valuable to *someone*, which is crazy.
Iñaki
6:29 a.m.
New subject: The Git forge decision (was CPE Weekly: 2020-03-28)
On Mon, Mar 30, 2020 at 7:27 AM Iñaki Ucar <iucar(a)fedoraproject.org> wrote:
On Mon, 30 Mar 2020 at 13:20, Neal Gompa <ngompa13(a)gmail.com> wrote:
>
> On Mon, Mar 30, 2020 at 7:02 AM Leigh Griffin <lgriffin(a)redhat.com> wrote:
> >
> >>
> >> I was really looking forward to reading what
> >> Neal (as he's doing now) and others had to say about the requirements
> >> *before* any decision was taken, and how each tool covers them or not,
> >> and what kind of effort would require to cover it in the latter case.
> >> This is *very* disappointing.
> >
> > I'm sorry this is disappointing but even reading the analysis by Neal it is
looking at the merit of the requirement and not looking at the fact that it is valuable to
somebody. Each stakeholder group had their own means to discuss and debate the merits and
had them rolled into CPE who in turn analysed them and published the full story list.
>
> I'm not bothering with the other aspects because there's no point. You
> *already* decided. Why should I evaluate the merits of the
> requirements when you've already decided they mattered enough to use
> them for deciding for GitLab?
I think he's arguing the opposite: that you shouldn't be evaluating
the merits of the requirements published just because they are
valuable to *someone*, which is crazy.
That is nuts, no agile process I've ever heard of does it that way.
Part of the job of a product owner and project manager is to filter
these down, determine the merits of them, and determine the importance
of them after that. If you don't do that, you'll be bogged down in
useless requirements effectively forcing decisions for you.
--
真実はいつも一つ！/ Always, there's only one truth!
6:45 a.m.
New subject: The Git forge decision (was CPE Weekly: 2020-03-28)
On Mon, Mar 30, 2020 at 12:31 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
On Mon, Mar 30, 2020 at 7:27 AM Iñaki Ucar
<iucar(a)fedoraproject.org>
wrote:
>
> On Mon, 30 Mar 2020 at 13:20, Neal Gompa <ngompa13(a)gmail.com> wrote:
> >
> > On Mon, Mar 30, 2020 at 7:02 AM Leigh Griffin <lgriffin(a)redhat.com>
wrote:
> > >
> > >>
> > >> I was really looking forward to reading what
> > >> Neal (as he's doing now) and others had to say about the
requirements
> > >> *before* any decision was taken, and how each tool covers them or
not,
> > >> and what kind of effort would require to cover it in the latter
case.
> > >> This is *very* disappointing.
> > >
> > > I'm sorry this is disappointing but even reading the analysis by
Neal it is looking at the merit of the requirement and not looking at the
fact that it is valuable to somebody. Each stakeholder group had their own
means to discuss and debate the merits and had them rolled into CPE who in
turn analysed them and published the full story list.
> >
> > I'm not bothering with the other aspects because there's no point. You
> > *already* decided. Why should I evaluate the merits of the
> > requirements when you've already decided they mattered enough to use
> > them for deciding for GitLab?
>
> I think he's arguing the opposite: that you shouldn't be evaluating
> the merits of the requirements published just because they are
> valuable to *someone*, which is crazy.
That is nuts, no agile process I've ever heard of does it that way.
Part of the job of a product owner and project manager is to filter
these down, determine the merits of them, and determine the importance
of them after that. If you don't do that, you'll be bogged down in
useless requirements effectively forcing decisions for you.
We done that as a Management team and with our Product Owner among other
stakeholders. We did evaluate the merit of the requirements from a
practicality perspective but we did not question or force our opinion on
the validity of their asks, as we respect that it serves some demographic
of their stakeholder group. I don't feel it's appropriate for one
stakeholder group to criticise or attack the merits of a requirement from
another group, that's the essence of my point.
--
真実はいつも一つ！/ Always, there's only one truth!
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Leigh Griffin
Engineering Manager
Red Hat Waterford <https://www.redhat.com/>
Communications House
Cork Road, Waterford City
lgriffin(a)redhat.com
M: +353877545162 IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs> redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>
7:01 a.m.
New subject: The Git forge decision (was CPE Weekly: 2020-03-28)
On Mon, Mar 30, 2020 at 12:45:59PM +0100, Leigh Griffin wrote:
We done that as a Management team and with our Product Owner among
other
stakeholders. We did evaluate the merit of the requirements from a
practicality perspective but we did not question or force our opinion on
the validity of their asks, as we respect that it serves some demographic
of their stakeholder group. I don't feel it's appropriate for one
stakeholder group to criticise or attack the merits of a requirement from
another group, that's the essence of my point.
He's not saying their opinions or asks are invalid or are without some
merit, just that one has to evaluate those asks *in some greater
context* to determine if they should influence the final decision.
That "evaluation" and (even the "greater context") seems to have gone
completely missing here, and no, whatever went on in a disused lavatory
behind a sign that says "beware of leopard" doesn't count.
- Solomon
--
Solomon Peachy pizza at shaftnet dot org
High Springs, FL ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.
6:38 a.m.
New subject: The Git forge decision (was CPE Weekly: 2020-03-28)
On Mon, Mar 30, 2020 at 12:10 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
On Mon, Mar 30, 2020 at 7:02 AM Leigh Griffin
<lgriffin(a)redhat.com> wrote:
>
>>
>> I was really looking forward to reading what
>> Neal (as he's doing now) and others had to say about the requirements
>> *before* any decision was taken, and how each tool covers them or not,
>> and what kind of effort would require to cover it in the latter case.
>> This is *very* disappointing.
>
> I'm sorry this is disappointing but even reading the analysis by Neal it
is looking at the merit of the requirement and not looking at the fact that
it is valuable to somebody. Each stakeholder group had their own means to
discuss and debate the merits and had them rolled into CPE who in turn
analysed them and published the full story list.
I'm not bothering with the other aspects because there's no point. You
*already* decided.
The decision is made and we are proceeding to engage with Gitlab and
unfortunately that won't be reversed as a decision.
Why should I evaluate the merits of the
requirements when you've already decided they mattered enough to use
them for deciding for GitLab?
My point was more towards the fact that the analysis you provided focused
a lot on the merit or worthiness of the requirement, rather than the fact
that somebody wanted it for their own use cases.
--
真実はいつも一つ！/ Always, there's only one truth!
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Leigh Griffin
Engineering Manager
Red Hat Waterford <https://www.redhat.com/>
Communications House
Cork Road, Waterford City
lgriffin(a)redhat.com
M: +353877545162 IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs> redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>
10:55 a.m.
New subject: The Git forge decision (was CPE Weekly: 2020-03-28)
Hi,
On Mon, Mar 30, 2020 at 12:38:16PM +0100, Leigh Griffin wrote:
The decision is made and we are proceeding to engage with Gitlab and
unfortunately that won't be reversed as a decision.
I haven't expected this situation, so I've read up a bit on the whole
thing.
From the outside it looks that the CPE team is trying since about a year
to get rid of as many services as possible, due to having not enough
resources to handle all. (I've only been looking at devel@ and blog
posts, there is not much else I could find about the CPE team)
The problem I think I see is, that there seems to be no option of giving
away responsibilities - the only advances I see are either "we'll
replace this with something we think is easier" or "lets turn it off".
I see one exception: Fedocal, where this list has been asked, if someone
wants to take over. Unfortunately that seems to be stuck due to
bureaucracy.
What I don't understand is, why a decision this big is not taken by
FESCo (or Council) and the CentOS Governing Board itself.
After all in the Blogpost about how the CPE team is planning to do
things[1], it is stated:
"Our intention is to run all of the apps through the Fedora Council
first, in case the Council prefers any specific alternatives to a
particular service or app."
(I'm also not sure why the article states the Council directly, and not
FESCo)
It sure feels like the CPE is not bound by either FESCo, CentOS
Governing Board or Fedora Council - this whole thing feels quite
arbitrary. Maybe it would be wiser to consider this as a formal error and
either re-do the decision process or hand the decision off to the Fedora
Council and the CentOS Governing Board (maybe as a joint decision?)
[1]
https://communityblog.fedoraproject.org/application-service-categories-an...
All the best,
David
11:20 a.m.
New subject: The Git forge decision (was CPE Weekly: 2020-03-28)
On Mon, Mar 30, 2020 at 5:06 PM David Kaufmann <astra(a)ionic.at> wrote:
Hi,
On Mon, Mar 30, 2020 at 12:38:16PM +0100, Leigh Griffin wrote:
> The decision is made and we are proceeding to engage with Gitlab and
> unfortunately that won't be reversed as a decision.
I haven't expected this situation, so I've read up a bit on the whole
thing.
From the outside it looks that the CPE team is trying since about a year
to get rid of as many services as possible, due to having not enough
resources to handle all. (I've only been looking at devel@ and blog
posts, there is not much else I could find about the CPE team)
We are trying to reduce the total ownership of the team to allow us to
provide value on initiatives that are requested of us by our stakeholders.
The problem I think I see is, that there seems to be no option of giving
away responsibilities - the only advances I see are either "we'll
replace this with something we think is easier" or "lets turn it off".
I see one exception: Fedocal, where this list has been asked, if someone
wants to take over. Unfortunately that seems to be stuck due to
bureaucracy.
Unfortunately GDPR means we cannot give away application data, the
applications themselves are free and open for the community to take and
standup and offer to the community at large.
What I don't understand is, why a decision this big is not taken
by
FESCo (or Council) and the CentOS Governing Board itself.
Neither run the git forge, CPE run it and we asked both Communities for
input as to what our next steps should be.
After all in the Blogpost about how the CPE team is planning to do
things[1], it is stated:
"Our intention is to run all of the apps through the Fedora Council
first, in case the Council prefers any specific alternatives to a
particular service or app."
And we done that and shared intentions around Pagure (and several other
apps) and in the case of Pagure it led to a requirements gathering exercise
to decide on the appropriate direction to take.
(I'm also not sure why the article states the Council directly, and not
FESCo)
We engage with Council who in turn may decide to engage with other groups
including FESCo
It sure feels like the CPE is not bound by either FESCo, CentOS
Governing Board or Fedora Council - this whole thing feels quite
arbitrary.
We take their input and guidance very seriously and they guide and shape
our backlog of initiatives to work on.
Maybe it would be wiser to consider this as a formal error and
either re-do the decision process or hand the decision off to the Fedora
Council and the CentOS Governing Board (maybe as a joint decision?)
Ultimately CPE have to run the application, so if your scenario is to come
to pass, both Fedora Council and CentOS Board will need to invest time and
resourcing into the running and maintenance of a Git forge solution. They
are also not the only stakeholders here.
[1]
https://communityblog.fedoraproject.org/application-service-categories-an...
All the best,
David
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Leigh Griffin
Engineering Manager
Red Hat Waterford <https://www.redhat.com/>
Communications House
Cork Road, Waterford City
lgriffin(a)redhat.com
M: +353877545162 IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs> redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>
1:08 p.m.
New subject: The Git forge decision (was CPE Weekly: 2020-03-28)
On Mon, Mar 30, 2020 at 17:20:04 +0100,
Leigh Griffin <lgriffin(a)redhat.com> wrote:
On Mon, Mar 30, 2020 at 5:06 PM David Kaufmann <astra(a)ionic.at>
wrote:
We are trying to reduce the total ownership of the team to allow us to
provide value on initiatives that are requested of us by our stakeholders.
Pagure has value beyond Fedora and RedHat. In some ways it has more value
than Fedora the OS, because there are less free options in the git forge
space. (Gitlab isn't usably free as is. It would need a real fork to
get out from under the sponsor's conflicts of interest.)
I would have expected the council to consider this an important project
worth pursuing on its own, not just for running part of Fedora's
infrastructure.
1:42 p.m.
New subject: The Git forge decision (was CPE Weekly: 2020-03-28)
----- Original Message -----
From: "Bruno Wolff III" <bruno(a)wolff.to>
To: "Leigh Griffin" <lgriffin(a)redhat.com>
Cc: "Development discussions related to Fedora"
<devel(a)lists.fedoraproject.org>
Sent: Monday, March 30, 2020 2:08:21 PM
Subject: Re: The Git forge decision (was CPE Weekly: 2020-03-28)
On Mon, Mar 30, 2020 at 17:20:04 +0100,
Leigh Griffin <lgriffin(a)redhat.com> wrote:
>On Mon, Mar 30, 2020 at 5:06 PM David Kaufmann <astra(a)ionic.at> wrote:
>
>We are trying to reduce the total ownership of the team to allow us to
>provide value on initiatives that are requested of us by our stakeholders.
Pagure has value beyond Fedora and RedHat. In some ways it has more value
than Fedora the OS, because there are less free options in the git forge
space. (Gitlab isn't usably free as is. It would need a real fork to
get out from under the sponsor's conflicts of interest.)
Have you tried to use Pagure as a development based git forge? And not
just as a dist-git hosting location? It needs a lot of help! More than the
current resources provide.
The reasons why are well documented in Pagure's issue tracker.
If that's something you value, feel free to contribute to Pagure upstream.
But Pagure can't compete with Gitlab as a development forge in its current
state.
There are other public git forges that behave better than Pagure:
- SourceHut
- Gitea
- ...
So I don't think this actually has as much value as you think.
And to be clear: there's a difference between a Fedora-sponsored
Development forge and a new git forge for dist-git. A lot of this
discussion has conflated these two cases. I mostly care about it
releasing the former role (pagure.io) and don't care much about
the latter role (s.fp.o).
My 2c.
- Alex
I would have expected the council to consider this an important project
worth pursuing on its own, not just for running part of Fedora's
infrastructure.
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
2:04 p.m.
New subject: The Git forge decision (was CPE Weekly: 2020-03-28)
On Mon, Mar 30, 2020 at 14:42:33 -0400,
Alex Scheel <ascheel(a)redhat.com> wrote:
Have you tried to use Pagure as a development based git forge? And not
just as a dist-git hosting location? It needs a lot of help! More than the
current resources provide.
I've used the PR features a bit in a dist-git context. I tried to see if
we could use it for my group at work, but somebody had already set up
gitlab for another group and we ended up re-using their work instead.
The reasons why are well documented in Pagure's issue tracker.
I have contributed to the the issue list, but not for a while.
If that's something you value, feel free to contribute to Pagure
upstream.
It's hard for me to keep up with packing now, so it is hard to do much more
than report issues and test fixes.
But Pagure can't compete with Gitlab as a development forge in its
current
state.
There are other public git forges that behave better than Pagure:
- SourceHut
- Gitea
- ...
So I don't think this actually has as much value as you think.
Perhaps. SourceHut does look like it is really free. I'd be a little
worried about something happening to the founder if I was reliant on
them for improvements. Gitea also seems to be really free and seems
to be community based. I don't know how well either works or how
sustainable their development is. But they do seem to be alternatives
that are really free, unlike gitlab.
And to be clear: there's a difference between a Fedora-sponsored
Development forge and a new git forge for dist-git. A lot of this
discussion has conflated these two cases. I mostly care about it
releasing the former role (pagure.io) and don't care much about
the latter role (s.fp.o).
I think it is a project that is valuable for Red Hat to sponsor, but
apparently the decision makers there don't think so.
I'm still disapointed in this decision. One of the reasons I got involved
with Fedora instead of other distributions way back, was that they were
working on getting rid of plague and replacing it with free software.
(It was gone by the time I was a packager, so I never used it.)
2:30 p.m.
New subject: The Git forge decision (was CPE Weekly: 2020-03-28)
On Mon, Mar 30, 2020 at 3:26 PM Bruno Wolff III <bruno(a)wolff.to> wrote:
On Mon, Mar 30, 2020 at 14:42:33 -0400,
Alex Scheel <ascheel(a)redhat.com> wrote:
>
>Have you tried to use Pagure as a development based git forge? And not
>just as a dist-git hosting location? It needs a lot of help! More than the
>current resources provide.
I've used the PR features a bit in a dist-git context. I tried to see if
we could use it for my group at work, but somebody had already set up
gitlab for another group and we ended up re-using their work instead.
>The reasons why are well documented in Pagure's issue tracker.
I have contributed to the the issue list, but not for a while.
>If that's something you value, feel free to contribute to Pagure upstream.
It's hard for me to keep up with packing now, so it is hard to do much more
than report issues and test fixes.
>But Pagure can't compete with Gitlab as a development forge in its current
>state.
>
>There are other public git forges that behave better than Pagure:
>
> - SourceHut
> - Gitea
> - ...
>
>So I don't think this actually has as much value as you think.
Perhaps. SourceHut does look like it is really free. I'd be a little
worried about something happening to the founder if I was reliant on
them for improvements. Gitea also seems to be really free and seems
to be community based. I don't know how well either works or how
sustainable their development is. But they do seem to be alternatives
that are really free, unlike gitlab.
SourceHut eschews common norms for forge-based development in favor of
email based workflows. I don't think anyone here is keen on that. :)
As for Gitea, we're basically at parity with Gitea now. The major
difference between Pagure and Gitea is that Pagure is highly
extensible and Gitea is designed to be a very self-contained
application. Plugging Pagure into workflows and infrastructure is
substantially easier than doing the same with Gitea.
>And to be clear: there's a difference between a
Fedora-sponsored
>Development forge and a new git forge for dist-git. A lot of this
>discussion has conflated these two cases. I mostly care about it
>releasing the former role (pagure.io) and don't care much about
>the latter role (s.fp.o).
I think it is a project that is valuable for Red Hat to sponsor, but
apparently the decision makers there don't think so.
I'm still disapointed in this decision. One of the reasons I got involved
with Fedora instead of other distributions way back, was that they were
working on getting rid of plague and replacing it with free software.
(It was gone by the time I was a packager, so I never used it.)
I barely remember plague (it was going away when I started as a
packager). Plague was free software, but the build system for Fedora
Core was not. That and Plague were both replaced with Koji in 2007. It
was a great day, indeed.
--
真実はいつも一つ！/ Always, there's only one truth!
2:16 p.m.
New subject: The Git forge decision (was CPE Weekly: 2020-03-28)
On Mon, Mar 30, 2020 at 15:30:20 -0400,
Neal Gompa <ngompa13(a)gmail.com> wrote:
I barely remember plague (it was going away when I started as a
packager). Plague was free software, but the build system for Fedora
Core was not. That and Plague were both replaced with Koji in 2007. It
was a great day, indeed.
Thanks for the correction, as it was a long time ago and apparently either
misremembered or confused plague with the proprietary part long ago.
2:50 p.m.
New subject: The Git forge decision (was CPE Weekly: 2020-03-28)
----- Original Message -----
From: "Neal Gompa" <ngompa13(a)gmail.com>
To: "Development discussions related to Fedora"
<devel(a)lists.fedoraproject.org>
Cc: "Alex Scheel" <ascheel(a)redhat.com>, "Leigh Griffin"
<lgriffin(a)redhat.com>
Sent: Monday, March 30, 2020 3:30:20 PM
Subject: Re: The Git forge decision (was CPE Weekly: 2020-03-28)
As for Gitea, we're basically at parity with Gitea now. The
major
difference between Pagure and Gitea is that Pagure is highly
extensible and Gitea is designed to be a very self-contained
application. Plugging Pagure into workflows and infrastructure is
substantially easier than doing the same with Gitea.
The following "just work" with Gitea and have usable defaults:
- Full Text Search by default
https://pagure.io/pagure/issue/2505
- A real search bar
https://pagure.io/pagure/issue/4543
- Proper diff line numbers
https://pagure.io/pagure/issue/2193
https://pagure.io/pagure/issue/724
- Proper inline comments
https://pagure.io/pagure/issue/3488
https://pagure.io/pagure/issue/4488
https://pagure.io/pagure/issue/3646
- ... I could go on
Pagure isn't at parity with Gitea. Please run an instance of Gitea and
compare. The UX with Gitea is _much_ better.
If these issues are old, please close them.
- Alex
2:05 p.m.
New subject: The Git forge decision (was CPE Weekly: 2020-03-28)
----- Original Message -----
From: "Alex Scheel" <ascheel(a)redhat.com>
To: "Development discussions related to Fedora"
<devel(a)lists.fedoraproject.org>
Cc: "Leigh Griffin" <lgriffin(a)redhat.com>
Sent: Monday, March 30, 2020 8:42:33 PM
Subject: Re: The Git forge decision (was CPE Weekly: 2020-03-28)
----- Original Message -----
> From: "Bruno Wolff III" <bruno(a)wolff.to>
> To: "Leigh Griffin" <lgriffin(a)redhat.com>
> Cc: "Development discussions related to Fedora"
> <devel(a)lists.fedoraproject.org>
> Sent: Monday, March 30, 2020 2:08:21 PM
> Subject: Re: The Git forge decision (was CPE Weekly: 2020-03-28)
>
> On Mon, Mar 30, 2020 at 17:20:04 +0100,
> Leigh Griffin <lgriffin(a)redhat.com> wrote:
> >On Mon, Mar 30, 2020 at 5:06 PM David Kaufmann <astra(a)ionic.at> wrote:
> >
> >We are trying to reduce the total ownership of the team to allow us to
> >provide value on initiatives that are requested of us by our stakeholders.
>
> Pagure has value beyond Fedora and RedHat. In some ways it has more value
> than Fedora the OS, because there are less free options in the git forge
> space. (Gitlab isn't usably free as is. It would need a real fork to
> get out from under the sponsor's conflicts of interest.)
Have you tried to use Pagure as a development based git forge? And not
just as a dist-git hosting location? It needs a lot of help! More than the
current resources provide.
The reasons why are well documented in Pagure's issue tracker.
If that's something you value, feel free to contribute to Pagure upstream.
But Pagure can't compete with Gitlab as a development forge in its current
state.
There are other public git forges that behave better than Pagure:
- SourceHut
- Gitea
- ...
So I don't think this actually has as much value as you think.
And to be clear: there's a difference between a Fedora-sponsored
Development forge and a new git forge for dist-git. A lot of this
discussion has conflated these two cases. I mostly care about it
releasing the former role (pagure.io) and don't care much about
the latter role (s.fp.o).
I personally see this pretty much the other way - there
are many good
or usable forges for hosting ones project. There is at the moment pretty much
only one git forge with good (and any at all any) integration with Fedora processes
- Pagure.
That's why I see Pagure as important mostly in the Fedora family context and less
important in the general git forge are. It would certainly be nice to see Pagure
take over that as well, but I see having a fully open git forge with full
Fedora integration sitting on top of distgit as more important.
My 2c.
- Alex
>
> I would have expected the council to consider this an important project
> worth pursuing on its own, not just for running part of Fedora's
> infrastructure.
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
2:23 p.m.
New subject: The Git forge decision (was CPE Weekly: 2020-03-28)
----- Original Message -----
From: "Martin Kolman" <mkolman(a)redhat.com>
To: "Development discussions related to Fedora"
<devel(a)lists.fedoraproject.org>
Cc: "Leigh Griffin" <lgriffin(a)redhat.com>
Sent: Monday, March 30, 2020 3:05:54 PM
Subject: Re: The Git forge decision (was CPE Weekly: 2020-03-28)
> And to be clear: there's a difference between a
Fedora-sponsored
> Development forge and a new git forge for dist-git. A lot of this
> discussion has conflated these two cases. I mostly care about it
> releasing the former role (pagure.io) and don't care much about
> the latter role (s.fp.o).
I personally see this pretty much the other way - there are many good
or usable forges for hosting ones project. There is at the moment pretty much
only one git forge with good (and any at all any) integration with Fedora
processes
- Pagure.
That's why I see Pagure as important mostly in the Fedora family context and
less
important in the general git forge are. It would certainly be nice to see
Pagure
take over that as well, but I see having a fully open git forge with full
Fedora integration sitting on top of distgit as more important.
I don't really use dist-git's forge for much. Maybe for hitting "fork"
when
I need to open a PR against another repo, and filing the PR. Everything else
happens via fedpkg/git/bodhi/koji... on the command line.
I don't really care about showing the latest versions of packages on dist-git
(that's what bodhi/koji is for). That's the most recent user-visible feature,
yes? Why that? ~shrugs~
Having a little better admin/group integration would be nice.
But as long as it doesn't take ages to fork a repo (and Pagure does sometimes!),
I don't really care. I'm also not a proven packager or the owner of a huge
package dependency tree (python, java, perl, ...). I really just care about a
few packages, plus whatever is in the Stewardship SIG.
I guess a little nicer orphan/unorphan package procedure would be nice, but
you'd still need a ticket for unretiring dead packages, which is where I've hit
the most problems/delays.
But as long as I can continue to work from the command line, I don't really
care what the WebUI is as long as it works and isn't too slow.
My 2c. but I'm really agnostic about dist-git forges. :-)
- Alex
1:16 p.m.
New subject: The Git forge decision (was CPE Weekly: 2020-03-28)
I thought CPE ("Community Platform Engineering") is a part of the
community. But no, because you want to hand over pagure.io to "the
Community", so what community is that...People that don't have
hardware?
It seems that the whole proposal is trying to make src.fp.o and
git.centos.org part of a corporate solution and therefore eat a huge
part of Fedora & CentOS ecosystems and of their independence.
Do you realize how valuable the Fedora upstream is for RHEL?
The thing that I am saying is suggested by points like:
5
As a RH Developer
I need the ability to privately comment on a PR
so that confidential information does not leak outside Red Hat
8
As a RHEL engineer
I want a modern git workflow
So that I can use upstream practices in RHEL development for quicker delivery of features
& fixes
Taking points like this into account for Fedora dist-git only makes
sense if RHEL development would take place directly on src.fp.o. But
that's not the case. We have community upstream and then there is RHEL
that further uses and processes the upstream work. While there is some
overlap in people, these are still two separate software development
domains.
Your suggestion is: "Let's break everything." Do you know how many
existing integrations with pagure there are? Do you know how much time
and also emotions was put into building it? Do you say all that work
was useless? It's not only about technology but it's also about how
many people connected on it with a vision to build something good. And
by trying to overcome the feature gap, this can continue.
Fedora is a community Linux distribution with people that want to work
together on something, it's not just some dumb package factory.
Do you want a community help on pagure? Ask for it but not by handing
it a project that RH does not want to maintain anymore but instead try
first to describe the feature gap we are missing and see if it can be
overcome by a collective effort. It's better than rushing into a
decision which is breaking an extreme amount of stuff and which might
put into grave a good reusable technology that we have and that we
could also offer to other people and other communities for free so
that open-source can thrive.
Fedora dist-git is using pagure, CentOS dist-git is using pagure so
both these parties are, in my opinion, okay with it already. Let's
build on something we already have instead of destroying it over and
over again. Only this is a way for Fedora community to be a leading
party in the open-source and free software, which it should be.
clime
3:51 a.m.
New subject: The Git forge decision (was CPE Weekly: 2020-03-28)
On Mon, Mar 30, 2020 at 7:17 PM clime <clime(a)fedoraproject.org> wrote:
I thought CPE ("Community Platform Engineering") is a part
of the
community.
We are part of the CentOS and Fedora Communities, correct.
But no, because you want to hand over pagure.io to "the
Community", so what community is that...People that don't have
hardware?
As a team we owned over 130 services at last count, we cannot sustain that
load, so wish to have the community come on board and take some of that
ownership, be it code maintenance, feature development or hosting off of
us. With that workload on us we cannot give due diligence to each app,
Pagure fell into that category and led to this process. So yes, we would
like to have the community more involved with running pagure.io, that may
just be at an operational / development level, we haven't gotten that far
in our planning yet.
It seems that the whole proposal is trying to make src.fp.o and
git.centos.org part of a corporate solution and therefore eat a huge
part of Fedora & CentOS ecosystems and of their independence.
Do you realize how valuable the Fedora upstream is for RHEL?
It's hugely valuable.
The thing that I am saying is suggested by points like:
> 5
> As a RH Developer
> I need the ability to privately comment on a PR
> so that confidential information does not leak outside Red Hat
> 8
> As a RHEL engineer
> I want a modern git workflow
> So that I can use upstream practices in RHEL development for quicker
delivery of features & fixes
Taking points like this into account for Fedora dist-git only makes
sense if RHEL development would take place directly on src.fp.o.
But
that's not the case. We have community upstream and then there is
RHEL
that further uses and processes the upstream work. While there is some
overlap in people, these are still two separate software development
domains.
The requirements given were taken for what they were, the two requirements
you quoted were taken at face value.
Your suggestion is: "Let's break everything."
I never suggested that.
Do you know how many
existing integrations with pagure there are?
No. Our analysis will tell us that in due course
Do you know how much time
and also emotions was put into building it?
I have tracked the project development and am very familiar with the
evolution of it. I can't quantify emotions but I do understand how much
this means to the community and to the folks who worked on it and Pagure
will live on beyond CPE operationally using it as a Git Forge. Just to note
that emotions were not a factor in the requirements gathering process from
the Fedora Community side, we got very simple requirements to process and
base our decision upon.
Do you say all that work
was useless?
I never said that
It's not only about technology but it's also about how
many people connected on it with a vision to build something good.
And
by trying to overcome the feature gap, this can continue.
And I genuinely would love to see that feature gap overcome and for Pagure
to flourish, I will be tracking the project and assisting where I can.
Fedora is a community Linux distribution with people that want to work
together on something, it's not just some dumb package factory.
Do you want a community help on pagure?
Yes, I'd love a proper community to form around it.
Ask for it but not by handing
it a project that RH does not want to maintain anymore but instead try
first to describe the feature gap we are missing and see if it can be
overcome by a collective effort. It's better than rushing into a
decision which is breaking an extreme amount of stuff and which might
put into grave a good reusable technology that we have and that we
could also offer to other people and other communities for free so
that open-source can thrive.
We had several call to arms to bring more contributors in to apps that CPE
had attained ownership of. Had we wanted to drop Pagure as a project we
would have done so. We engaged on a requirements gathering exercise and
while you might not agree with the outcome, Gitlab meets the vast majority,
if not all, the needs of the Fedora community. The effort we will undertake
to fix tooling and make this work will still be a fraction of the effort
for us both short and long term and allows us to concentrate on the actual
value adds that the Fedora Community, via the Council, are requesting of
our team. That's the trade off that I think is being missed here.
Fedora dist-git is using pagure, CentOS dist-git is using pagure so
both these parties are, in my opinion, okay with it already. Let's
build on something we already have instead of destroying it over and
over again. Only this is a way for Fedora community to be a leading
party in the open-source and free software, which it should be.
clime
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Leigh Griffin
Engineering Manager
Red Hat Waterford <https://www.redhat.com/>
Communications House
Cork Road, Waterford City
lgriffin(a)redhat.com
M: +353877545162 IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs> redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>
7:21 a.m.
New subject: The Git forge decision (was CPE Weekly: 2020-03-28)
Leigh,
Do you know how many
> existing integrations with pagure there are?
No. Our analysis will tell us that in due course
I am concerned by this approach to the decision-making. In many of your
replies, you mention wanting to get feature-parity with the current tooling
and systems, but here you suggest no analysis was done to see what it would
take from a technical perspective for each of the options to meet the
existing needs (e.g. what integrations would actually need to be moved from
the current Pagure dist-git to a GitLab dist-git, how the workflows would
have to be changed for each dist-git candidate, etc.). Most of these
integrations will probably be Fedora-specific, so it would still end up on
CPE to implement/update them (such as a fedora-messaging translator,
Bugzilla default assignee overrides, the dashboard metrics displayed on the
current dist-git repo, etc.).
I understand wanting to free up CPE time from fire fighting issues to doing
actual development of the community infrastructure, but it seems the
original goal of this project to reduce the CPE team workload hasn't
actually been shown to be satisfied by this choice of dist-git yet.
Specifically, there seems to have been no analysis of the time/effort
required to switch to a GitLab-based dist-git instead of implementing any
missing features into the Pagure-based dist-git.
Additionally, you mention that new features required for this transition
will be submitted to GitLab so that they can prioritize them and add them
to their "backlog." The problem here is their current issue database seems
to have >26,000 open issues in it, and >13,000 are in the "backlog"
category. Is there any guarantee that GitLab will implement the features
CPE submits to their "backlog" that are required to get feature-parity in
the 12-18 month timeframe this switchover was going to happen in (if I
recall those timings correctly)? Will CPE dedicate any staff time to doing
that feature development for GitLab if GitLab is unwilling to prioritize
those issues?
Thanks,
-Ian
8:29 a.m.
New subject: The Git forge decision (was CPE Weekly: 2020-03-28)
On Tue, Mar 31, 2020 at 1:23 PM Ian McInerney <Ian.S.McInerney(a)ieee.org>
wrote:
Leigh,
> Do you know how many
>> existing integrations with pagure there are?
>
>
> No. Our analysis will tell us that in due course
>
I am concerned by this approach to the decision-making. In many of your
replies, you mention wanting to get feature-parity with the current tooling
and systems, but here you suggest no analysis was done to see what it would
take from a technical perspective for each of the options to meet the
existing needs (e.g. what integrations would actually need to be moved from
the current Pagure dist-git to a GitLab dist-git, how the workflows would
have to be changed for each dist-git candidate, etc.).
I never said there was no analysis done, I answered a question asking me
did I know how many integrations there are for Pagure and the answer off
hand is I don't. I do know of many important integrations that I come into
contact with during my day to day job in the team, that doesn't mean I know
everysingle one of them. We analysed the critical path needs via the
requirements and any reference to tooling integrations (e.g. fedora
messaging was reference in multiple conversations) will be brought forward
with us for deeper technical conversations.
Most of these integrations will probably be Fedora-specific, so it
would
still end up on CPE to implement/update them (such as a fedora-messaging
translator, Bugzilla default assignee overrides, the dashboard metrics
displayed on the current dist-git repo, etc.).
I understand wanting to free up CPE time from fire fighting issues to
doing actual development of the community infrastructure, but it seems the
original goal of this project to reduce the CPE team workload hasn't
actually been shown to be satisfied by this choice of dist-git yet.
Specifically, there seems to have been no analysis of the time/effort
required to switch to a GitLab-based dist-git instead of implementing any
missing features into the Pagure-based dist-git.
The focus here is on the retooling cost Vs the feature gap cost and the
continued maintenance of that stack. While this will be a short term cost
trade off for us in CPE, it ultimately frees up a lot more of our time and
resources.
Additionally, you mention that new features required for this transition
will be submitted to GitLab so that they can prioritize them and add them
to their "backlog."
Feature gaps will be lodged
The problem here is their current issue database seems to have >26,000 open
issues in it, and >13,000 are in the "backlog" category.
Is there any
guarantee that GitLab will implement the features CPE submits to their
"backlog" that are required to get feature-parity in the 12-18 month
timeframe this switchover was going to happen in (if I recall those timings
correctly)?
There are no guarantees and while we can make representations
ultimately they control their own development resources, we control ours.
Will CPE dedicate any staff time to doing that feature development
for
GitLab if GitLab is unwilling to prioritize those issues?
That's a possibility for sure.
Thanks,
-Ian
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Leigh Griffin
Engineering Manager
Red Hat Waterford <https://www.redhat.com/>
Communications House
Cork Road, Waterford City
lgriffin(a)redhat.com
M: +353877545162 IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs> redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>
12:58 p.m.
New subject: The Git forge decision (was CPE Weekly: 2020-03-28)
On 30. 03. 20 17:55, David Kaufmann wrote:
What I don't understand is, why a decision this big is not taken
by
FESCo (or Council) and the CentOS Governing Board itself.
FESCo cannot actually make anyone do anything. So even if FESCo says: "The
dist-git will run on Pagure", CPE can say: "Whatever, but we are not maintaining
it."
Not sure what would be the result of such situation, but I am pretty sure it
would not be very nice.
That said, completely ignoring FESCo during this entire process strikes me as
odd as well.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
6:23 a.m.
New subject: The Git forge decision (was CPE Weekly: 2020-03-28)
On Mon, 30 Mar 2020 at 13:10, Leigh Griffin <lgriffin(a)redhat.com> wrote:
On Mon, Mar 30, 2020 at 10:29 AM Iñaki Ucar <iucar(a)fedoraproject.org> wrote:
>
> So I was also waiting for those open discussions about the
> requirements gathered.
We had several threads on them from the Fedora perspective on both devel and council
lists.
Yet again: threads on requirements gathering, not on the merits of the
final User Story list. That's what several of us were expecting. I
don't think it's too hard too understand. You can say "no, that wasn't
part of the process", but then, sorry, you didn't communicate that
effectively.
I'm sorry this is disappointing but even reading the analysis by
Neal it is looking at the merit of the requirement and not looking at the fact that it is
valuable to somebody. Each stakeholder group had their own means to discuss and debate the
merits and had them rolled into CPE who in turn analysed them and published the full story
list.
Two things are obvious here: 1) not all the requirements can be met
(you already stated this), and 2) not all requirements have the same
importance. So yes, of course Neal is looking at the merit of every
single requirement, and that's your job too. What if I say that is
valuable to me that the GitHub logo is on top of the interface? Is
that something that should be taken into account just because it's
valuable to somebody?
Iñaki
6:43 a.m.
New subject: The Git forge decision (was CPE Weekly: 2020-03-28)
On Mon, Mar 30, 2020 at 12:24 PM Iñaki Ucar <iucar(a)fedoraproject.org> wrote:
On Mon, 30 Mar 2020 at 13:10, Leigh Griffin
<lgriffin(a)redhat.com> wrote:
>
> On Mon, Mar 30, 2020 at 10:29 AM Iñaki Ucar <iucar(a)fedoraproject.org>
wrote:
>>
>> So I was also waiting for those open discussions about the
>> requirements gathered.
>
> We had several threads on them from the Fedora perspective on both devel
and council lists.
Yet again: threads on requirements gathering, not on the merits of the
final User Story list.
A merits based discussion whereby multiple stakeholders have a totally
different view and use case for a Forge is impossible to facilitate. What
is valuable to you and your use case might not be valuable to other users
and vice versa. I'm happy to have a conversation about any individual
requirements but the reality is any that made the list are valid
requirements from a stakeholder perspective and it's not up to me or anyone
to challenge that assertion.
That's what several of us were expecting. I
don't think it's too hard too understand. You can say "no, that wasn't
part of the process", but then, sorry, you didn't communicate that
effectively.
> I'm sorry this is disappointing but even reading the analysis by Neal it
is looking at the merit of the requirement and not looking at the fact that
it is valuable to somebody. Each stakeholder group had their own means to
discuss and debate the merits and had them rolled into CPE who in turn
analysed them and published the full story list.
Two things are obvious here: 1) not all the requirements can be met
(you already stated this), and 2) not all requirements have the same
importance. So yes, of course Neal is looking at the merit of every
single requirement, and that's your job too. What if I say that is
valuable to me that the GitHub logo is on top of the interface? Is
that something that should be taken into account just because it's
valuable to somebody?
If that came up as a UI requirement then yes we would have taken it on
board, would have documented it and would have presented it in the final
list of unique user stories we gathered. Would it be weighed equally with a
more core functional requirement? The answer is of course no but we would
have respected that request.
The Fedora specific requirements (as I am on the Fedora lists here) had
very few unique needs such that both Gitlab and Pagure would have satisfied
their desire. Either Forge would have been satisfied the requirements we
received and we ultimately opted for Gitlab based on a more holistic view
of the stakeholder needs.
Iñaki
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Leigh Griffin
Engineering Manager
Red Hat Waterford <https://www.redhat.com/>
Communications House
Cork Road, Waterford City
lgriffin(a)redhat.com
M: +353877545162 IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs> redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>
7:03 a.m.
New subject: The Git forge decision (was CPE Weekly: 2020-03-28)
20/3/30 13:43(e)an, Leigh Griffin igorleak idatzi zuen:
On Mon, Mar 30, 2020 at 12:24 PM Iñaki Ucar <iucar(a)fedoraproject.org
<mailto:iucar@fedoraproject.org>> wrote:
On Mon, 30 Mar 2020 at 13:10, Leigh Griffin <lgriffin(a)redhat.com
<mailto:lgriffin@redhat.com>> wrote:
>
> On Mon, Mar 30, 2020 at 10:29 AM Iñaki Ucar
<iucar(a)fedoraproject.org <mailto:iucar@fedoraproject.org>> wrote:
>>
>> So I was also waiting for those open discussions about the
>> requirements gathered.
>
> We had several threads on them from the Fedora perspective on both
devel and council lists.
Yet again: threads on requirements gathering, not on the merits of the
final User Story list.
A merits based discussion whereby multiple stakeholders have a totally
different view and use case for a Forge is impossible to facilitate.
What is valuable to you and your use case might not be valuable to other
users and vice versa. I'm happy to have a conversation about any
individual requirements but the reality is any that made the list are
valid requirements from a stakeholder perspective and it's not up to me
or anyone to challenge that assertion.
As I asked before on this thread, I would
like to know how are you
planning to fullfill the SLA requirement while the SLE from CPE for the
services like AAA that the forge will require to function is lower than
the required SLA for the forge itself.
That's what several of us were expecting. I
don't think it's too hard too understand. You can say "no, that
wasn't
part of the process", but then, sorry, you didn't communicate that
effectively.
> I'm sorry this is disappointing but even reading the analysis by
Neal it is looking at the merit of the requirement and not looking
at the fact that it is valuable to somebody. Each stakeholder group
had their own means to discuss and debate the merits and had them
rolled into CPE who in turn analysed them and published the full
story list.
Two things are obvious here: 1) not all the requirements can be met
(you already stated this), and 2) not all requirements have the same
importance. So yes, of course Neal is looking at the merit of every
single requirement, and that's your job too. What if I say that is
valuable to me that the GitHub logo is on top of the interface? Is
that something that should be taken into account just because it's
valuable to somebody?
If that came up as a UI requirement then yes we would have taken it on
board, would have documented it and would have presented it in the final
list of unique user stories we gathered. Would it be weighed equally
with a more core functional requirement? The answer is of course no but
we would have respected that request.
The Fedora specific requirements (as I am on the Fedora lists here) had
very few unique needs such that both Gitlab and Pagure would have
satisfied their desire. Either Forge would have been satisfied the
requirements we received and we ultimately opted for Gitlab based on a
more holistic view of the stakeholder needs.
Iñaki
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
<mailto:devel@lists.fedoraproject.org>
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
<mailto:devel-leave@lists.fedoraproject.org>
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Leigh Griffin
Engineering Manager
Red Hat Waterford <https://www.redhat.com/>
Communications House
Cork Road, Waterford City
lgriffin(a)redhat.com <mailto:lgriffin@redhat.com>
M: +353877545162 <tel:+353877545162> IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs> redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Julen Landa Alustiza <jlanda(a)fedoraproject.org>
9:46 a.m.
New subject: The Git forge decision (was CPE Weekly: 2020-03-28)
On Mon, Mar 30, 2020 at 1:13 PM Julen Landa Alustiza <
jlanda(a)fedoraproject.org> wrote:
20/3/30 13:43(e)an, Leigh Griffin igorleak idatzi zuen:
>
>
> On Mon, Mar 30, 2020 at 12:24 PM Iñaki Ucar <iucar(a)fedoraproject.org
> <mailto:iucar@fedoraproject.org>> wrote:
>
> On Mon, 30 Mar 2020 at 13:10, Leigh Griffin <lgriffin(a)redhat.com
> <mailto:lgriffin@redhat.com>> wrote:
> >
> > On Mon, Mar 30, 2020 at 10:29 AM Iñaki Ucar
> <iucar(a)fedoraproject.org <mailto:iucar@fedoraproject.org>> wrote:
> >>
> >> So I was also waiting for those open discussions about the
> >> requirements gathered.
> >
> > We had several threads on them from the Fedora perspective on both
> devel and council lists.
>
> Yet again: threads on requirements gathering, not on the merits of
the
> final User Story list.
>
>
> A merits based discussion whereby multiple stakeholders have a totally
> different view and use case for a Forge is impossible to facilitate.
> What is valuable to you and your use case might not be valuable to other
> users and vice versa. I'm happy to have a conversation about any
> individual requirements but the reality is any that made the list are
> valid requirements from a stakeholder perspective and it's not up to me
> or anyone to challenge that assertion.
As I asked before on this thread, I would like to know how are you
planning to fullfill the SLA requirement while the SLE from CPE for the
services like AAA that the forge will require to function is lower than
the required SLA for the forge itself.
The availability of the forge isn't bound by the availability of the AAA
system, that will only impact a percentage of users. I'm not sure if that
is addressing your question or not?
>
>
> That's what several of us were expecting. I
> don't think it's too hard too understand. You can say "no, that
wasn't
> part of the process", but then, sorry, you didn't communicate that
> effectively.
>
> > I'm sorry this is disappointing but even reading the analysis by
> Neal it is looking at the merit of the requirement and not looking
> at the fact that it is valuable to somebody. Each stakeholder group
> had their own means to discuss and debate the merits and had them
> rolled into CPE who in turn analysed them and published the full
> story list.
>
> Two things are obvious here: 1) not all the requirements can be met
> (you already stated this), and 2) not all requirements have the same
> importance. So yes, of course Neal is looking at the merit of every
> single requirement, and that's your job too. What if I say that is
> valuable to me that the GitHub logo is on top of the interface? Is
> that something that should be taken into account just because it's
> valuable to somebody?
>
>
> If that came up as a UI requirement then yes we would have taken it on
> board, would have documented it and would have presented it in the final
> list of unique user stories we gathered. Would it be weighed equally
> with a more core functional requirement? The answer is of course no but
> we would have respected that request.
>
> The Fedora specific requirements (as I am on the Fedora lists here) had
> very few unique needs such that both Gitlab and Pagure would have
> satisfied their desire. Either Forge would have been satisfied the
> requirements we received and we ultimately opted for Gitlab based on a
> more holistic view of the stakeholder needs.
>
>
> Iñaki
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> <mailto:devel@lists.fedoraproject.org>
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> <mailto:devel-leave@lists.fedoraproject.org>
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
>
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
>
>
> --
>
> Leigh Griffin
>
> Engineering Manager
>
> Red Hat Waterford <https://www.redhat.com/>
>
> Communications House
>
> Cork Road, Waterford City
>
> lgriffin(a)redhat.com <mailto:lgriffin@redhat.com>
> M: +353877545162 <tel:+353877545162> IM: lgriffin
>
> @redhatjobs <https://twitter.com/redhatjobs> redhatjobs
> <https://www.facebook.com/redhatjobs> @redhatjobs
> <https://instagram.com/redhatjobs>
> <https://red.ht/sig>
>
>
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
--
Julen Landa Alustiza <jlanda(a)fedoraproject.org>
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Leigh Griffin
Engineering Manager
Red Hat Waterford <https://www.redhat.com/>
Communications House
Cork Road, Waterford City
lgriffin(a)redhat.com
M: +353877545162 IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs> redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>
5:34 a.m.
New subject: The Git forge decision (was CPE Weekly: 2020-03-28)
On Mon, Mar 30, 2020 at 8:08 AM Julen Landa Alustiza <
jlanda(a)fedoraproject.org> wrote:
20/3/30 08:40(e)an, James Cassell igorleak idatzi zuen:
>
> On Sun, Mar 29, 2020, at 11:47 PM, Neal Gompa wrote:
>> On Sat, Mar 28, 2020 at 4:12 PM Aoife Moloney <amoloney(a)redhat.com>
wrote:
>>>
>>> ### Other Updates
>>>
>>> #### GitForge Decision
>>> * After evaluating over 300 user stories from multiple stakeholders we
>>> have aligned on a decision for the Gitforge that CPE will operate for
>>> the coming years. We are opting for Gitlab for our dist git and
>>> project hosting and will continue to run pagure.io with community
>>> assistance.
>>> * Check out our GitForge decision on the Fedora Community blog
>>> https://communityblog.fedoraproject.org/
>>> * And at the CentOS blog page
>>> https://blog.centos.org/2020/03/git-forge-decision/
>>> * Keep an eye out for mails in the coming months to the devel lists as
>>> we plan transitions and next steps with GitLab
>>> * We would like to express our sincere thank you to all who
>>> contributed requirements to us!
>>>
>>>
>>
>> I'm going to start with the delivery of this decision sucked. If I
>> hadn't been alerted to look for this by other folks due to my advocacy
>> and community building work around Pagure, I would *not* have known
>> that the decision had been made. This is in contrast to the *big deal*
>> that was made about starting this "decision process". I don't know
if
>
> Indeed, it seems like the lead got buried. I, too, had missed the
announcement. I guess I'll make more effort to read these weekly status
updates.
From the original blow post:
https://communityblog.fedoraproject.org/git-forge-requirements/
> How will information be gathered and disseminated?
>
> It is recommended that both Fedora Council and CentOS Board gather
input and present their concerns in a manner that is consistent with how
their communities work. The RHEL and CPE requirements will be gathered
through Red Hat communication mechanisms and presented publicly via a
HackMD file to ensure transparency in their source.
We published the full requirements gathered from all stakeholders alongside
the blog
This will be
published and distributed in due course. Additionally, a live video call
and associated IRC meetings will be held and advertised in advance to
discuss the requirements, talk about concerns and address any questions.
We felt that the discussions came to a natural conclusion for each
stakeholder group. I should have returned to that thread and updated folks
that we had taken all the requirements in, that's on me, you have my
apologies.
> We want transparency to be at the heart of this decision.
Good promise, where are all those? No discussion, no advances, no proper
information dissemination, nothing :(
This announcement is not even on the first position on communityblog. I
was expecting at least the same announcement visibility level for the
final announcement that we had for the initial one: first position on
communityblog blog + exclusive threads on the mailing lists.
I can't speak to how the community blog structures it's priority queue but
I opened the mailing thread this morning due to the weekend.
Well, actually I was waiting for those live discussions
>
>> there were folks counting on nobody noticing this or not, but this is
>> not a good way to deliver effectively a major decision like this. I
>> also absolutely *refuse* to deal with the fact that this thread was
>> split into three mailing lists. All three are connected to this
>> thread, and I will take responses from all of them and follow them
>> accordingly.
>>
>> Enough about that, let's talk about the actual decision.
>
> Thanks for your comprehensive response here and for all the work you've
done to drive Pagure forward.
>
> V/r,
> James Cassell
>
>
>>
>> So, you're going with GitLab. It's interesting to note that the
>> particulars about going to GitLab are not even figured out. It is
>> curious that "SAAS" is mentioned very prominently. That made me a bit
>> more curious, so I looked at the "final" feature requirements.
>> Needless to say, I was extremely disappointed.
>>
>> To put it bluntly, there are *zero* free and open source solutions
>> that satisfy your needs. From this, I understood why you said GitLab
>> and SaaS. You want GitLab Ultimate, the proprietary solution that
>> includes several extra features on top to satisfy the following
>> requirements (quoted from your blog post):
>>
>>> * There is a need for CentOS Stream to integrate with a kernel
workflow that is an automated bot driven merging solution (merge trains).
This allows for richer CI capabilities and minimizes the need for human
interaction
>>> * Gitlab allows for project planning capability which could make
multiple trackers such as Taiga redundant, allowing for the planning and
tracking to reside within the repo. It would enrich the current ticket
based solution that Pagure has evolved into for some groups
>>
>> These two requirements *alone* automatically force us to GitLab
>> Enterprise Ultimate Edition, as there is no other solution available
>> that satisfies those requirements in one product. Merge trains *is* a
>> feature of Pagure when combined with Zuul, but GitLab's project
>> planning features do not exist in *any* FOSS product, including GitLab
>> CE (or GitLab Core as they call it now).
>>
>> There are mentions of other work that CPE team wants to do to better
>> improve Fedora. Okay, sure. I even agree with some of them. And the
>> time bomb that is FAS is definitely worth the attention (note that I
>> am somewhat involved in the development of the Fedora AAA solution and
>> am also working on trying to develop a community around it so it
>> doesn't implode like virtually every other project under the Fedora
>> umbrella, more on *that* a bit later).
>>
>> However, nobody has given me or anyone else in the Pagure community
>> (which yes, is more than Pierre-Yves, thank you very much!) any
>> concrete details of deficiencies they'd see that is not satisfiable by
>> the community within a year before now. I've spent a little over a day
>> analyzing the user stories and thinking about the gaps between Pagure
>> and what the community wants, and I want to give some perspective here
>> for some of these. I'm happy to accept refutations and other details
>> to further enhance the color of these stories, of course.
>>
>>> 5
>>> As a RH Developer
>>> I need the ability to privately comment on a PR
>>> so that confidential information does not leak outside Red Hat
>>
>> Ignoring the mountainous levels of terrible problems that such a
>> feature causes us *now* in the Red Hat Bugzilla, Pierre-Yves and I
>> were literally discussing this with a Mageian who was interested in
>> this feature for Pagure weeks ago. We had identified the feature as
>> not difficult to implement but also simultaneously nobody really
>> *wanted it now*. It surprises me that this is something that should be
>> considered an important feature to preserve. It's actually a very
>> *rare* feature, and does not exist in any forge today, presumably
>> because it's actually a horrifically bad idea and antithetical to open
>> development. GitLab itself lacks this feature, in all variants.
>>
>>> 16
>>> As a general user
>>> I want to be able to create a bot/service account
>>> That integrates with the gitforge in the same way as a human does
>>
>> This is a nice ask, but it's not a reasonably easy one to implement
>> with our current system. This is a problem I've struggled with at
>> $DAYJOB with GitLab as well, and frankly, if you have account
>> integration with a single-sign-on system (which virtually all
>> large-scale Git forge instances do), you can't really easily have this
>> without causing major problems. Not the least of which is how you
>> resolve account namespace collisions. There are also problems with
>> maintaining and auditing, too. But it's certainly something I'd like
>> to see in any forge (note that none implement this today either).
>>
>>> 29
>>> As a General User
>>> I want to access repos fully over https
>>> For environments where SSH is blocked
>>
>> I would be really curious if the Red Hat Infrastructure Security guys
>> have changed their opinion on this after four years of blocking the
>> development of this feature in Pagure. The two major reasons we don't
>> have this in Pagure are:
>>
>> * There is a very strong push to not provide a way to bypass the SSO
>> (ignoring the fact that SSH keys are effectively a bypass, but most
>> security people are two-faced about this anyway)
>> * There is a very strong push to not provide LDAP integration so that
>> the required HTTP(S) Git proxy server would not be able to be
>> implemented.
>>
>> Note that for GitLab, unless you configure it to have access to LDAP
>> or set up personal access tokens, you cannot use HTTP(S) push at all.
>> Once again, this totally bypasses SSO. If the same rules that applied
>> to Pagure apply to GitLab, nobody is getting this feature anytime soon
>> with GitLab. If the attitude toward this feature has finally changed,
>> I'd love to know.
>>
>> Also, for those who don't know, Fedora's Dist-Git supports HTTPS push,
>> and has for almost a year:
>> https://fedoraproject.org/wiki/Infrastructure/HTTPS-commits
>>
>> This is done by *forcing* an SSO flow for *fedpkg* itself and
>> leveraging it as a credential and auth point. Unfortunately, this is
>> not a general purpose feature because there's not an easy way to do
>> that, so it's unavailable on pagure.io at this time. This mechanism
>> for HTTP push is *not* possible with GitLab, and would be quite
>> difficult to implement due to the crazy architecture internally. But
>> if more *normal* HTTPS is acceptable (like through auth tokens or LDAP
>> auth), then this is something that could be relatively quickly added
>> to Pagure (there was some old code that never got merged two years
>> ago, I still have it archived somewhere...).
>>
>>> 31
>>> As a General User
>>> I can request access rights to a repository
>>> So that I can contribute in a low friction manner
>>
>> I honestly don't know entirely what this means. Are we talking about
>> having partial commit access (commit access to only some branches)? If
>> so, there's a PR out for implementing this in Pagure under review:
>> https://pagure.io/pagure/pull-request/4786
>>
>>
>>> 34
>>> As a General User
>>> I want a mobile native app
>>> To allow me contribute while away from my desk
>>
>> I don't have words for this... You folks know that only GitHub.com has
>> an official mobile app, right? And the experience is not great...
>> 🤦♂️
>>
>>> 42
>>> As a General User
>>> want a GUI to interface with the system as well as a CLI
>>> so new users have an easier way to interface with it
>>
>> I'd like to point out that most popular GUIs for Git stuff are not
>> forge specific and do not even do much for forge integration. But
>> sure...?
>>
>>> 44
>>> As a General User
>>> I want a temporary file (gist)
>>> So that I can share code easily
>>
>> There seems to be a misunderstanding here... Gists are not temporary.
>> They're lightweight *permanent* Git repos (in GitHub). GitLab stores
>> them (called Snippets) as permanent things in the database (not a Git
>> repo). Are you trying to conflate pastebin use-cases here? That's
>> probably a very bad idea...
>>
>>> 46
>>> As a General User
>>> I want to be notified of CVEs in my code
>>> so that I can stay on top of critical vulnerabilities
>>
>> There are *zero* FOSS solutions for this in the forge space. This
>> feature does *not* exist below GitLab Ultimate (the former Gemnasium
>> service was integrated into it).
>>
>>> 47
>>> As a General User
>>> I want integrated keyword support
>>> to allow me automate a lot of my actions such as a rebuild / retest
>>
>> This is not a forge feature, this is a CI service feature. And note,
>> GitLab CI does not support this.
>>
>>> 49
>>> As a General User
>>> I want to gain analytics and insights from my code
>>> so that I can have historic context to make decisions moving forward
>>
>> GitLab Enterprise features...
>>
>>> 51
>>> As a General User
>>> I would like to track my work in an Agile manner
>>> allowing me centralise all my planning in my forge and gain insights
into how I am working.
>>
>> GitLab Enterprise features, as mentioned earlier.
>>
>>> 56
>>> As a General User
>>> I want registry integration
>>> so that I can store dependencies
>>
>> No, you don't. You *really* don't want this. Are you *sure* you know
>> what you're asking for? You're suggesting three things here:
>>
>> * OSS solutions for this (including Fedora's own package/container
>> infrastructure and hosted quay.io) are not good enough
>> * You are ready to have even more arbitrary data stored in the Git
>> system that may not follow our legal compliance
>> * You are willing to pay the cost of having even more data stored
>>
>>> 57
>>> As a General User
>>> I want the ability to have a private branch
>>> So that I do not need to leave the code tree I am already in
>>
>> Just so everyone is *crystal clear*: you literally cannot do this. Git
>> does not have a concept of private branches or private refs within a
>> repository. You can have private forks, of course. And Pagure supports
>> those just fine, just like GitLab and GitHub do.
>>
>> (also note, we *intentionally* do not have private repos turned on...
>> if we want this, we could just flip a switch...)
>>
>>> 62
>>> As a General User
>>> I want automerges when specific acceptance criteria are met
>>> So that I do not need manual intervention
>>
>> So... Mergify then? This is not *currently* a GitLab feature, and
>> Mergify does not support GitLab, last I checked. Only GitHub.com. It's
>> been on my bucket for a while to look at extending Mergify to support
>> Pagure for this, as it's a really nice feature...
>>
>> I want to take a moment to reflect on something that has been on my
>> mind for a while now: Fedora has not done a good job being an umbrella
>> organization. As an organization, we have done a huge disservice to
>> all Fedora-affiliated projects by not allocating any community
>> development effort or marketing effort. I know that Matthew Miller
>> feels Fedora should evolve to being an operating systems factory[1]
>> and to some extent that isn't a bad thought. But the Fedora Project
>> was always intended to be more than just the Fedora Linux
>> distribution. It has always been intended to be a home for Free and
>> Open Source innovation. In a Hacker News thread last year[2], I had
>> reflected on how proud I have been to be part of Fedora because we, as
>> a community, weren't willing to just give up like so many others do.
>> When FOSS solutions were inadequate, we built better ones. We've
>> invented things that didn't exist before, and jump-started
>> conversations about concepts that people didn't think of before. But
>> there has been a bit of a dark side to this for Fedora. We've rarely
>> given our projects an opportunity to grow beyond us. Off the top of my
>> head, the *only* project that technically *started* in Fedora and
>> became successful was Ansible. And if I'm being totally brutally
>> honest, it was only successful because the engineers who were
>> passionate about it had to quit Red Hat and create AnsibleWorks to
>> push it to success. It was successful *despite* Fedora. Maybe soon
>> we'll be able to add HyperKitty and Postorius to that, as I've been
>> seeing deployments of that come online over the past few months. It's
>> taken a while, but HyperKitty is finally taking off. There was one
>> person I talked to who told me that HyperKitty made mailing lists
>> enjoyable and she didn't know the project came from Fedora originally.
>> Again, seeing success despite Fedora.
>>
>> When I talk to folks in other communities and show them some of the
>> infrastructure projects we've developed as part of trying to build
>> communities around them, I've literally had people tell me that they
>> wish they had known we made them before, because it solved all their
>> problems they were struggling with. That's both amazingly uplifting
>> and terribly depressing at the same time. I'm not even putting in a
>> lot of effort and we get so much more out of it. It didn't take a lot
>> for me to get openSUSE interested in our new AAA solution and
>> contributing. That tells me that we're just not trying. And really,
>> that's obvious. Even a simple comparison of the Fedora and openSUSE
>> project landing pages show that Fedora gives zero attention to the
>> projects that exist under its umbrella. When you look at the openSUSE
>> landing page, the distribution and major software projects under the
>> umbrella are all broadcasted there. It makes it so much easier to
>> discover and generate interest. I'm not saying I love every aspect of
>> the openSUSE marketing. Far from it! But this is one thing they do
>> right that we do terribly wrong. And then we sit back and wonder why
>> our projects fail to generate interest beyond a few folks in Fedora
>> itself. It's a self-fulfilling prophecy. This is something we need to
>> fix for *all* our projects: present and future.
>>
>> In the end, I think the biggest disappointment of this process is that
>> it feels like it demonstrates that Fedora leadership and management is
>> not as committed to its mission and vision[3] as I hoped it was. I
>> realize that I should not be surprised by this. Most of the leadership
>> and management are no longer the idealistic people they were when they
>> first became involved. And it's even harder to be idealistic when it's
>> so easy to give in when you work for "open source company" that
>> increasingly uses proprietary software to manage its workflow (to be
>> fair, I think at this point virtually all major companies do this,
>> which more or less demonstrates the amoral nature of these entities).
>> Maybe I'm just an old remnant of a bygone era, but I personally remain
>> somewhat idealistic, even as I have progressed over the years. I also
>> remain hopeful that other members of the community are of similar
>> mind. And perhaps this is a bit of a fool's hope, but I hope the CPE
>> team reconsiders their decision, or at least would be willing to
>> provide more context on the gaps they felt pushed them over so they
>> could be prioritized for Pagure development (and maybe we can develop
>> them fast enough so that we don't have to switch...).
>>
>> I think this is also an important indicator that Open Source has *not*
>> won and it is *not* the default. People who keep saying otherwise need
>> to seriously look hard at the landscape and realize that we have a
>> long way to go before Open Source becomes the true default. It
>> behooves us to become cognizant of this and push for freedom whenever
>> and wherever we can.
>>
>> As for me? Well, I will do my best to try to help develop the Pagure
>> community. I'm still committed to assisting the Free Software
>> Foundation and other communities with using and contributing to
>> Pagure. I hope others within the community will consider helping too.
>> Pagure provides unique features that do not exist in any other forge,
>> in large part because it is driven by an ideal that open data and
>> freedom should be core tenants of software project management. And
>> hey, I hear whispers of new Pagure instances being set up all the
>> time! We're doing something right here, and it'd be a shame to
>> squander it.
>>
>> Heh, the irony is that I started using and contributing to Pagure
>> *because* I was burned by GitLab...
>>
>>
>> [1]:
>>
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
>> [2]: https://news.ycombinator.com/item?id=19356307
>> [3]: https://docs.fedoraproject.org/en-US/project/
>>
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
--
Julen Landa Alustiza <jlanda(a)fedoraproject.org>
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Leigh Griffin
Engineering Manager
Red Hat Waterford <https://www.redhat.com/>
Communications House
Cork Road, Waterford City
lgriffin(a)redhat.com
M: +353877545162 IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs> redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>
3:20 a.m.
New subject: The Git forge decision (was CPE Weekly: 2020-03-28)
On 30. 03. 20 5:47, Neal Gompa wrote:
On Sat, Mar 28, 2020 at 4:12 PM Aoife
Moloney<amoloney(a)redhat.com> wrote:
> ### Other Updates
>
> #### GitForge Decision
> * After evaluating over 300 user stories from multiple stakeholders we
> have aligned on a decision for the Gitforge that CPE will operate for
> the coming years. We are opting for Gitlab for our dist git and
> project hosting and will continue to run pagure.io with community
> assistance.
> * Check out our GitForge decision on the Fedora Community blog
> https://communityblog.fedoraproject.org/
> * And at the CentOS blog page
> https://blog.centos.org/2020/03/git-forge-decision/
> * Keep an eye out for mails in the coming months to the devel lists as
> we plan transitions and next steps with GitLab
> * We would like to express our sincere thank you to all who
> contributed requirements to us!
>
>
I'm going to start with the delivery of this decision sucked. If I
hadn't been alerted to look for this by other folks due to my advocacy
and community building work around Pagure, I would*not* have known
that the decision had been made. This is in contrast to the*big deal*
that was made about starting this "decision process". I don't know if
there were folks counting on nobody noticing this or not, but this is
not a good way to deliver effectively a major decision like this.
Thank you Neal
for pointing this out. I agree fully. This is not nice.
The original proposal promised Fedora Council involvement. I wonder where that
happened, I could not found any Pagure ticket nor a Council mailing list thread
about this.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
9:33 a.m.
New subject: The Git forge decision (was CPE Weekly: 2020-03-28)
On Mon, Mar 30, 2020 at 10:20:00AM +0200, Miro Hrončok wrote:
The original proposal promised Fedora Council involvement. I wonder
where that happened, I could not found any Pagure ticket nor a
Council mailing list thread about this.
We were asked to help collect the user stories and requirements. We
also gave the strong feedback that the community wasn't interested in
GitHub for a variety of reasons, which isn't a user-story per se but
obviously important.
I understand the attachment we have as a project to Pagure -- someone
in our community made it, after all, and lots of others have made
direct and indirect contributions. I feel that too! But, we all know
that it needs significant development work for scaling, stability, and
features.
Miro says somewhere else in this thread
FESCo cannot actually make anyone do anything. So even if FESCo
says: "The dist-git will run on Pagure", CPE can say: "Whatever, but
we are not maintaining it."
This is true of the Council as well, of course. Ultimately, the CPE
team is going to put huge amounts of time, effort, and money into
running this. So, I feel very comfortable in saying that this really is
that team's decision to make.
At the same time, having a dist-git and a git-forge at all is totally
meaningless if the Fedora contributor community's needs aren't served.
I see the Council's role here in making sure they are.
And, while obviously communication could have been better and maybe a
longer process would have helped, ultimately, I have a lot of trust for
the people who work on CPE. Let's help them figure out how to best help
all of us.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
9:30 a.m.
New subject: The Git forge decision (was CPE Weekly: 2020-03-28)
On Tue, Mar 31, 2020 at 10:33:46 -0400,
Matthew Miller <mattdm(a)fedoraproject.org> wrote:
I understand the attachment we have as a project to Pagure -- someone
in our community made it, after all, and lots of others have made
direct and indirect contributions. I feel that too! But, we all know
that it needs significant development work for scaling, stability, and
features.
It's more than that. While the community edition of gitlab (assuming we
don't get stuck with the proprietary version) is technically open source,
the main fork is run by Gitlab who have a conflict of interest in adding
features that compete with their enterprise edition. If it comes down to
needing a change they don't want to add, then we need to be willing to
maintain a fork or switch to something else. While this is true for a
lesser amount for using any free software, there normally isn't the
same incentive for most projects to reject enhancements submitted back
upstream.
10:28 a.m.
New subject: The Git forge decision (was CPE Weekly: 2020-03-28)
On Tue, Mar 31, 2020 at 09:30:57AM -0500, Bruno Wolff III wrote:
It's more than that. While the community edition of gitlab
(assuming
we don't get stuck with the proprietary version) is technically open
source, the main fork is run by Gitlab who have a conflict of
interest in adding features that compete with their enterprise
edition. If it comes down to needing a change they don't want to
add, then we need to be willing to maintain a fork or switch to
something else. While this is true for a lesser amount for using any
free software, there normally isn't the same incentive for most
projects to reject enhancements submitted back upstream.
Sure, this is a reasonable concern. Open core isn't my favorite
business model. But, doing open source as a business is hard. Not
everyone can be Red Hat. :) We have good relationships with people over
there -- I've talked with them before about other things -- and I think
we'll be able to navigate anything that comes up.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
5:28 a.m.
New subject: The Git forge decision (was CPE Weekly: 2020-03-28)
On Mon, Mar 30, 2020 at 4:48 AM Neal Gompa <ngompa13(a)gmail.com> wrote:
Merge trains *is* a
> feature of Pagure when combined with Zuul, but GitLab's project
> planning features do not exist in *any* FOSS product, including GitLab
> CE (or GitLab Core as they call it now).
> There are mentions of other work that CPE team wants to do
to better
> improve Fedora. Okay, sure. I even agree with some of them. And the
> time bomb that is FAS is definitely worth the attention (note that I
> am somewhat involved in the development of the Fedora AAA solution and
> am also working on trying to develop a community around it so it
> doesn't implode like virtually every other project under the Fedora
> umbrella, more on *that* a bit later).
> However, nobody has given me or anyone else in the Pagure
community
> (which yes, is more than Pierre-Yves, thank you very much!) any
> concrete details of deficiencies they'd see that is not satisfiable by
> the community within a year before now. I've spent a little over a day
> analyzing the user stories and thinking about the gaps between Pagure
> and what the community wants, and I want to give some perspective here
> for some of these. I'm happy to accept refutations and other details
> to further enhance the color of these stories, of course.
Feature gap was one aspect to satisfy immediate needs. Running and staffing
Pagure to not just meet that gap now but to ensure that gap stays small or
non existent is another factor. Another factor again is the maintenance,
upkeep and general development needed on a Forge solution Vs the desired
feature backlog of our stakeholders, which includes the Fedora Community.
> > 5
> > As a RH Developer
> > I need the ability to privately comment on a PR
> > so that confidential information does not leak outside Red Hat
> Ignoring the mountainous levels of terrible problems that
such a
> feature causes us *now* in the Red Hat Bugzilla,
It is a valid requirement from a stakeholder that we had to take at face
value. I can say the same for every single other requirement that we
analysed. Different stakeholders wanted different things from a Forge.
> Pierre-Yves and I
> were literally discussing this with a Mageian who was interested in
> this feature for Pagure weeks ago. We had identified the feature as
> not difficult to implement but also simultaneously nobody really
> *wanted it now*. It surprises me that this is something that should be
> considered an important feature to preserve. It's actually a very
> *rare* feature, and does not exist in any forge today, presumably
> because it's actually a horrifically bad idea and antithetical to open
> development. GitLab itself lacks this feature, in all variants.
No singular Forge satisfied every single User Story. Any feature gaps will
land on the Backlog of Gitlab for voting and prioritisation as their
Engineering teams see fit.
> > 16
> > As a general user
> > I want to be able to create a bot/service account
> > That integrates with the gitforge in the same way as a human does
> This is a nice ask, but it's not a reasonably easy one
to implement
> with our current system. This is a problem I've struggled with at
> $DAYJOB with GitLab as well, and frankly, if you have account
> integration with a single-sign-on system (which virtually all
> large-scale Git forge instances do), you can't really easily have this
> without causing major problems. Not the least of which is how you
> resolve account namespace collisions. There are also problems with
> maintaining and auditing, too. But it's certainly something I'd like
> to see in any forge (note that none implement this today either).
> > 29
> > As a General User
> > I want to access repos fully over https
> > For environments where SSH is blocked
> I would be really curious if the Red Hat Infrastructure
Security guys
> have changed their opinion on this after four years of blocking the
> development of this feature in Pagure.
The two major reasons we don't
> have this in Pagure are:
> * There is a very strong push to not provide a way to
bypass the SSO
> (ignoring the fact that SSH keys are effectively a bypass, but most
> security people are two-faced about this anyway)
> * There is a very strong push to not provide LDAP integration so that
> the required HTTP(S) Git proxy server would not be able to be
> implemented.
> Note that for GitLab, unless you configure it to have
access to LDAP
> or set up personal access tokens, you cannot use HTTP(S) push at all.
> Once again, this totally bypasses SSO. If the same rules that applied
> to Pagure apply to GitLab, nobody is getting this feature anytime soon
> with GitLab. If the attitude toward this feature has finally changed,
> I'd love to know.
I can't speak for that as I am unaware of the history but that requirement
came from several stakeholder groups and as mentioned above, we have not
engaged with Gitlab on specific cases like this. Our CPE team are compiling
a list of technical questions and asks from our side for that meeting I can
certainly add this to it.
> Also, for those who don't know, Fedora's Dist-Git
supports HTTPS push,
> and has for almost a year:
> https://fedoraproject.org/wiki/Infrastructure/HTTPS-commits
> This is done by *forcing* an SSO flow for *fedpkg* itself
and
> leveraging it as a credential and auth point. Unfortunately, this is
> not a general purpose feature because there's not an easy way to do
> that, so it's unavailable on pagure.io at this time. This mechanism
> for HTTP push is *not* possible with GitLab, and would be quite
> difficult to implement due to the crazy architecture internally. But
> if more *normal* HTTPS is acceptable (like through auth tokens or LDAP
> auth), then this is something that could be relatively quickly added
> to Pagure (there was some old code that never got merged two years
> ago, I still have it archived somewhere...).
> > 31
> > As a General User
> > I can request access rights to a repository
> > So that I can contribute in a low friction manner
> I honestly don't know entirely what this means.
This pertains to drive by contributors getting access without major
headaches, that's the low friction part.
> Are we talking about
> having partial commit access (commit access to only some branches)? If
> so, there's a PR out for implementing this in Pagure under review:
> https://pagure.io/pagure/pull-request/4786
> > 34
> > As a General User
> > I want a mobile native app
> > To allow me contribute while away from my desk
> I don't have words for this... You folks know that
only GitHub.com has
> an official mobile app, right? And the experience is not great...
It's a requirement that came from the Fedora Community and one we could not
satisfy as soon as Github was ruled out. I do agree the experience is not
great on it.
> 🤦♂️
> > 42
> > As a General User
> > want a GUI to interface with the system as well as a CLI
> > so new users have an easier way to interface with it
> I'd like to point out that most popular GUIs for Git
stuff are not
> forge specific and do not even do much for forge integration. But
> sure...?
Again it's valid and this one actually was at the request of the Fedora
Community to make it easier for non developers to contribute and use a
Forge.
> > 44
> > As a General User
> > I want a temporary file (gist)
> > So that I can share code easily
> There seems to be a misunderstanding here... Gists are not
temporary.
> They're lightweight *permanent* Git repos (in GitHub). GitLab stores
> them (called Snippets) as permanent things in the database (not a Git
> repo). Are you trying to conflate pastebin use-cases here? That's
> probably a very bad idea...
This was taking verbatim, I take your point that they are permanent and the
stakeholder here was obviously influenced by Github, the spirit of the
request was to have somewhere to store files for sharing around in a
lightweight manner. It is akin to a pastebin for sure. It's not up to me to
gauge the merit of that as a use case but it's a valid requirement which we
considered.
> > 46
> > As a General User
> > I want to be notified of CVEs in my code
> > so that I can stay on top of critical vulnerabilities
> There are *zero* FOSS solutions for this in the forge
space. This
> feature does *not* exist below GitLab Ultimate (the former Gemnasium
> service was integrated into it).
Just a general note that any feature gaps that we have seen will land as
backlog items / ideas in Pagure that will hopefully one day be built out by
the Community.
> > 47
> > As a General User
> > I want integrated keyword support
> > to allow me automate a lot of my actions such as a rebuild / retest
> This is not a forge feature, this is a CI service feature.
And note,
> GitLab CI does not support this.
This was framed around PR interactions and was hence considered as a forge
feature from an integration perspective.
> > 49
> > As a General User
> > I want to gain analytics and insights from my code
> > so that I can have historic context to make decisions moving forward
> GitLab Enterprise features...
> > 51
> > As a General User
> > I would like to track my work in an Agile manner
> > allowing me centralise all my planning in my forge and gain insights
> into how I am working.
> GitLab Enterprise features, as mentioned earlier.
> > 56
> > As a General User
> > I want registry integration
> > so that I can store dependencies
> No, you don't. You *really* don't want this. Are
you *sure* you know
> what you're asking for? You're suggesting three things here:
> * OSS solutions for this (including Fedora's own
package/container
> infrastructure and hosted quay.io) are not good enough
> * You are ready to have even more arbitrary data stored in the Git
> system that may not follow our legal compliance
> * You are willing to pay the cost of having even more data stored
It was not our place to question valid use cases or requirements from our
stakeholders. I personally don't agree with some of them but we set that
aside and took this at face value.
> > 57
> > As a General User
> > I want the ability to have a private branch
> > So that I do not need to leave the code tree I am already in
> Just so everyone is *crystal clear*: you literally cannot
do this. Git
> does not have a concept of private branches or private refs within a
> repository. You can have private forks, of course. And Pagure supports
> those just fine, just like GitLab and GitHub do.
> (also note, we *intentionally* do not have private repos
turned on...
> if we want this, we could just flip a switch...)
> > 62
> > As a General User
> > I want automerges when specific acceptance criteria are met
> > So that I do not need manual intervention
> So... Mergify then? This is not *currently* a GitLab
feature, and
> Mergify does not support GitLab, last I checked. Only GitHub.com. It's
> been on my bucket for a while to look at extending Mergify to support
> Pagure for this, as it's a really nice feature...
> I want to take a moment to reflect on something that has
been on my
> mind for a while now: Fedora has not done a good job being an umbrella
> organization. As an organization, we have done a huge disservice to
> all Fedora-affiliated projects by not allocating any community
> development effort or marketing effort. I know that Matthew Miller
> feels Fedora should evolve to being an operating systems factory[1]
> and to some extent that isn't a bad thought. But the Fedora Project
> was always intended to be more than just the Fedora Linux
> distribution. It has always been intended to be a home for Free and
> Open Source innovation. In a Hacker News thread last year[2], I had
> reflected on how proud I have been to be part of Fedora because we, as
> a community, weren't willing to just give up like so many others do.
> When FOSS solutions were inadequate, we built better ones. We've
> invented things that didn't exist before, and jump-started
> conversations about concepts that people didn't think of before. But
> there has been a bit of a dark side to this for Fedora. We've rarely
> given our projects an opportunity to grow beyond us. Off the top of my
> head, the *only* project that technically *started* in Fedora and
> became successful was Ansible. And if I'm being totally brutally
> honest, it was only successful because the engineers who were
> passionate about it had to quit Red Hat and create AnsibleWorks to
> push it to success. It was successful *despite* Fedora. Maybe soon
> we'll be able to add HyperKitty and Postorius to that, as I've been
> seeing deployments of that come online over the past few months. It's
> taken a while, but HyperKitty is finally taking off. There was one
> person I talked to who told me that HyperKitty made mailing lists
> enjoyable and she didn't know the project came from Fedora originally.
> Again, seeing success despite Fedora.
> When I talk to folks in other communities and show them
some of the
> infrastructure projects we've developed as part of trying to build
> communities around them, I've literally had people tell me that they
> wish they had known we made them before, because it solved all their
> problems they were struggling with. That's both amazingly uplifting
> and terribly depressing at the same time. I'm not even putting in a
> lot of effort and we get so much more out of it. It didn't take a lot
> for me to get openSUSE interested in our new AAA solution and
> contributing. That tells me that we're just not trying. And really,
> that's obvious. Even a simple comparison of the Fedora and openSUSE
> project landing pages show that Fedora gives zero attention to the
> projects that exist under its umbrella. When you look at the openSUSE
> landing page, the distribution and major software projects under the
> umbrella are all broadcasted there. It makes it so much easier to
> discover and generate interest. I'm not saying I love every aspect of
> the openSUSE marketing. Far from it! But this is one thing they do
> right that we do terribly wrong. And then we sit back and wonder why
> our projects fail to generate interest beyond a few folks in Fedora
> itself. It's a self-fulfilling prophecy. This is something we need to
> fix for *all* our projects: present and future.
> In the end, I think the biggest disappointment of this
process is that
> it feels like it demonstrates that Fedora leadership and management is
> not as committed to its mission and vision[3] as I hoped it was. I
> realize that I should not be surprised by this. Most of the leadership
> and management are no longer the idealistic people they were when they
> first became involved. And it's even harder to be idealistic when it's
> so easy to give in when you work for "open source company" that
> increasingly uses proprietary software to manage its workflow (to be
> fair, I think at this point virtually all major companies do this,
> which more or less demonstrates the amoral nature of these entities).
> Maybe I'm just an old remnant of a bygone era, but I personally remain
> somewhat idealistic, even as I have progressed over the years. I also
> remain hopeful that other members of the community are of similar
> mind. And perhaps this is a bit of a fool's hope, but I hope the CPE
> team reconsiders their decision, or at least would be willing to
> provide more context on the gaps they felt pushed them over so they
> could be prioritized for Pagure development (and maybe we can develop
> them fast enough so that we don't have to switch...).
We are committed to publishing those gaps as a feature backlog for Pagure.
> I think this is also an important indicator that Open
Source has *not*
> won and it is *not* the default. People who keep saying otherwise need
> to seriously look hard at the landscape and realize that we have a
> long way to go before Open Source becomes the true default. It
> behooves us to become cognizant of this and push for freedom whenever
> and wherever we can.
> As for me? Well, I will do my best to try to help develop
the Pagure
> community.
I'm glad to hear that and I hope that Pagure grows to become a success.
It's just not something we can commit to as a CPE team and something we
have not committed to in nearly 18 months now. That's harming the project
and I hope it gets the growth and energy that it deserves.
> I'm still committed to assisting the Free Software
> Foundation and other communities with using and contributing to
> Pagure. I hope others within the community will consider helping too.
> Pagure provides unique features that do not exist in any other forge,
> in large part because it is driven by an ideal that open data and
> freedom should be core tenants of software project management. And
> hey, I hear whispers of new Pagure instances being set up all the
> time! We're doing something right here, and it'd be a shame to
> squander it.
> Heh, the irony is that I started using and contributing to
Pagure
> *because* I was burned by GitLab...
> [1]:
>
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
> [2]: https://news.ycombinator.com/item?id=19356307
> [3]: https://docs.fedoraproject.org/en-US/project/
> --
> 真実はいつも一つ！/ Always, there's only one truth!
--
Leigh Griffin
Engineering Manager
Red Hat Waterford <https://www.redhat.com/
Communications House
Cork Road, Waterford City
lgriffin(a)redhat.com
M: +353877545162 IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs> redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs
<https://red.ht/sig
On Sat, Mar 28, 2020 at 4:12 PM Aoife Moloney
<amoloney(a)redhat.com> wrote:
> ### Other Updates
> #### GitForge Decision
> * After evaluating over 300 user stories from multiple stakeholders we
> have aligned on a decision for the Gitforge that CPE will operate for
> the coming years. We are opting for Gitlab for our dist git and
> project hosting and will continue to run pagure.io with community
> assistance.
> * Check out our GitForge decision on the Fedora Community blog
> https://communityblog.fedoraproject.org/
> * And at the CentOS blog page
> https://blog.centos.org/2020/03/git-forge-decision/
> * Keep an eye out for mails in the coming months to the devel lists as
> we plan transitions and next steps with GitLab
> * We would like to express our sincere thank you to all who
> contributed requirements to us!
I'm going to start with the delivery of this decision sucked.
The blog post was scheduled to go out early Friday but due to
unavailability and illness on the volunteers part the blog was not posted
until late Friday night. We compiled our rolling weekly update which went
out as scheduled and I have opened a devel-thread first thing this morning
on it as I did not touch my laptop over the weekend which is family time.
If I
hadn't been alerted to look for this by other folks due to my advocacy
and community building work around Pagure, I would *not* have known
that the decision had been made. This is in contrast to the *big deal*
that was made about starting this "decision process". I don't know if
there were folks counting on nobody noticing this or not, but this is
not a good way to deliver effectively a major decision like this. I
also absolutely *refuse* to deal with the fact that this thread was
split into three mailing lists. All three are connected to this
thread, and I will take responses from all of them and follow them
accordingly.
Enough about that, let's talk about the actual decision.
So, you're going with GitLab. It's interesting to note that the
particulars about going to GitLab are not even figured out. It is
curious that "SAAS" is mentioned very prominently. That made me a bit
more curious, so I looked at the "final" feature requirements.
Needless to say, I was extremely disappointed.
To put it bluntly, there are *zero* free and open source solutions
that satisfy your needs. From this, I understood why you said GitLab
and SaaS. You want GitLab Ultimate, the proprietary solution that
includes several extra features on top to satisfy the following
requirements (quoted from your blog post):
We have not engaged formally with Gitlab yet to decide on a license or
feature set. A thread has been opened up an a meeting set for later this
week which will result in a public ticket for tracking
> * There is a need for CentOS Stream to integrate with a kernel
workflow
that is an automated bot driven merging solution (merge trains). This
allows for richer CI capabilities and minimizes the need for human
interaction
> * Gitlab allows for project planning capability which could make
multiple trackers such as Taiga redundant, allowing for the planning and
tracking to reside within the repo. It would enrich the current ticket
based solution that Pagure has evolved into for some groups
These two requirements *alone* automatically force us to GitLab
Enterprise Ultimate Edition, as there is no other solution available
that satisfies those requirements in one product.
No singular requirement forced us into a decision, the decision was taken
holistically.
4:12 p.m.
New subject: The Git forge decision (was CPE Weekly: 2020-03-28)
Hi,
On Mon, Mar 30, 2020 at 11:28:59AM +0100, Leigh Griffin wrote:
No singular Forge satisfied every single User Story. Any feature gaps
will
land on the Backlog of Gitlab for voting and prioritisation as their
Engineering teams see fit.
this sounds very disturbing. Please clarify this. Fedora needs a
dist-git repo with certain features/workflows that might not make sense
for a generic git forge or in other words: A git forge might just be a
part of the solution that Fedora needs for dist-git. Does this mean that
the CPE team will implement the missing features that are not part of a
gitforge and therefore no priority for Gitlab? Or will Fedora just get a
gitforge and need to figure out how to be able to implement their
workflows with it?
Kind regards
Till
3:56 a.m.
New subject: The Git forge decision (was CPE Weekly: 2020-03-28)
On Mon, Mar 30, 2020 at 10:13 PM Till Maas <opensource(a)till.name> wrote:
Hi,
On Mon, Mar 30, 2020 at 11:28:59AM +0100, Leigh Griffin wrote:
> No singular Forge satisfied every single User Story. Any feature gaps
will
> land on the Backlog of Gitlab for voting and prioritisation as their
> Engineering teams see fit.
this sounds very disturbing. Please clarify this.
What part is unclear and I can help rephrase it? Leave me try in advance,
no single solution would satisfy the entirety of the stakeholder needs
across the board so our choice, Gitlab, satisfies the majority. They have a
strong team who work on community requested features where we will log any
feature gaps for their backlog and future consideration, further moving us
to a point where all requirements are met.
Fedora needs a
dist-git repo with certain features/workflows that might not make sense
for a generic git forge or in other words: A git forge might just be a
part of the solution that Fedora needs for dist-git. Does this mean that
the CPE team will implement the missing features that are not part of a
gitforge and therefore no priority for Gitlab?
Our goal is to ensure what we have today works in the future and we will
undertake that work where it makes sense for us to do so.
Or will Fedora just get a
gitforge and need to figure out how to be able to implement their
workflows with it?
Kind regards
Till
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Leigh Griffin
Engineering Manager
Red Hat Waterford <https://www.redhat.com/>
Communications House
Cork Road, Waterford City
lgriffin(a)redhat.com
M: +353877545162 IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs> redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>
5:26 a.m.
New subject: The Git forge decision (was CPE Weekly: 2020-03-28)
Hi Leigh,
On Tue, Mar 31, 2020 at 09:56:10AM +0100, Leigh Griffin wrote:
On Mon, Mar 30, 2020 at 10:13 PM Till Maas
<opensource(a)till.name> wrote:
> Hi,
>
> On Mon, Mar 30, 2020 at 11:28:59AM +0100, Leigh Griffin wrote:
>
> > No singular Forge satisfied every single User Story. Any feature gaps
> will
> > land on the Backlog of Gitlab for voting and prioritisation as their
> > Engineering teams see fit.
>
> this sounds very disturbing. Please clarify this.
What part is unclear and I can help rephrase it? Leave me try in advance,
no single solution would satisfy the entirety of the stakeholder needs
across the board so our choice, Gitlab, satisfies the majority. They have a
strong team who work on community requested features where we will log any
feature gaps for their backlog and future consideration, further moving us
to a point where all requirements are met.
What is unclear to me, is will CPE provide Fedora a solution for their
dist-git needs as described in the user stories provided by the Council?
Currently it sounds to me that CPE will only provide a generic git forge
and Fedora will rely on Gitlab to consider their special requirements
worthy to be implemented in a generic git forge solution.
Thank you
Till
5:33 a.m.
New subject: The Git forge decision (was CPE Weekly: 2020-03-28)
On Tue, Mar 31, 2020 at 11:28 AM Till Maas <opensource(a)till.name> wrote:
Hi Leigh,
On Tue, Mar 31, 2020 at 09:56:10AM +0100, Leigh Griffin wrote:
> On Mon, Mar 30, 2020 at 10:13 PM Till Maas <opensource(a)till.name> wrote:
>
> > Hi,
> >
> > On Mon, Mar 30, 2020 at 11:28:59AM +0100, Leigh Griffin wrote:
> >
> > > No singular Forge satisfied every single User Story. Any feature gaps
> > will
> > > land on the Backlog of Gitlab for voting and prioritisation as their
> > > Engineering teams see fit.
> >
> > this sounds very disturbing. Please clarify this.
>
>
> What part is unclear and I can help rephrase it? Leave me try in advance,
> no single solution would satisfy the entirety of the stakeholder needs
> across the board so our choice, Gitlab, satisfies the majority. They
have a
> strong team who work on community requested features where we will log
any
> feature gaps for their backlog and future consideration, further moving
us
> to a point where all requirements are met.
What is unclear to me, is will CPE provide Fedora a solution for their
dist-git needs as described in the user stories provided by the Council?
Currently it sounds to me that CPE will only provide a generic git forge
and Fedora will rely on Gitlab to consider their special requirements
worthy to be implemented in a generic git forge solution.
If it works today, we will strive to make sure it works with the Gitlab
solution going forward. We do not want a regression of functionality and we
will either work directly with Gitlab to try and bridge that gap or build
the tooling ourselves. I can't say exact specifics because I don't know
them yet. Hope that helps clarify our intent.
Thank you
Till
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Leigh Griffin
Engineering Manager
Red Hat Waterford <https://www.redhat.com/>
Communications House
Cork Road, Waterford City
lgriffin(a)redhat.com
M: +353877545162 IM: lgriffin
@redhatjobs <https://twitter.com/redhatjobs> redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://red.ht/sig>
7:10 a.m.
New subject: The Git forge decision (was CPE Weekly: 2020-03-28)
Le dimanche 29 mars 2020 à 23:47 -0400, Neal Gompa a écrit :
> As a General User
> I want to access repos fully over https
> For environments where SSH is blocked
I would be really curious if the Red Hat Infrastructure Security guys
have changed their opinion on this after four years of blocking the
development of this feature in Pagure. The two major reasons we don't
have this in Pagure are:
Neal,
Security is the usual excuse not to implement stuff. That does not work
when competing with others that did their homework. As you noted
yourself ssh accesss is not blameless either.
Gitlab and Github work in https mode. Pagure does not. End of story.
Expecting others to hole their security with corkscrew because of the
ssh holy cow was never going to impress any third party.
Regards,
--
Nicolas Mailhot
7:17 a.m.
New subject: The Git forge decision (was CPE Weekly: 2020-03-28)
On Mon, Mar 30, 2020 at 8:13 AM Nicolas Mailhot via devel
<devel(a)lists.fedoraproject.org> wrote:
Le dimanche 29 mars 2020 à 23:47 -0400, Neal Gompa a écrit :
>
> > As a General User
> > I want to access repos fully over https
> > For environments where SSH is blocked
>
> I would be really curious if the Red Hat Infrastructure Security guys
> have changed their opinion on this after four years of blocking the
> development of this feature in Pagure. The two major reasons we don't
> have this in Pagure are:
Neal,
Security is the usual excuse not to implement stuff. That does not work
when competing with others that did their homework. As you noted
yourself ssh accesss is not blameless either.
Gitlab and Github work in https mode. Pagure does not. End of story.
Expecting others to hole their security with corkscrew because of the
ssh holy cow was never going to impress any third party.
You don't have to tell me, I already know. It was intentionally not
implemented. And even with all that, we *do* have HTTPS through SSO on
src.fp.o. We just don't have it on pagure.io. Don't expect it to be
available with the move to GitLab. GitLab admins have a toggle they
can use to disable HTTPS pushing for policy reasons, and I will
strongly bet on it being flipped so that HTTPS pushing will not be
available in our GitLab.
--
真実はいつも一つ！/ Always, there's only one truth!
1487
days inactive
1490
days old
43 comments
17 participants
participants (17)
-
Alex Scheel -
Aoife Moloney -
Bruno Wolff III -
clime -
David Kaufmann -
Ian McInerney -
Iñaki Ucar -
James Cassell -
Julen Landa Alustiza -
Leigh Griffin -
Martin Kolman -
Matthew Miller -
Miro Hrončok -
Neal Gompa -
Nicolas Mailhot -
Solomon Peachy -
Till Maas