Gitlab Expiration Notice
Hey folks, You may have seen a notification on a banner within Gitlab that talks about an upcoming expiration date and a potential loss of features. This is unfortunately an automated message, our renewal as part of their OSS Program is in motion and no service interrupts are expected. Leigh -- Leigh Griffin Senior Manager, Emerging OS Platforms Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: CPE to staff EPEL
On Thu, Sep 2, 2021 at 10:41 PM Nico Kadel-Garcia wrote: > > > On Thu, Sep 2, 2021 at 11:23 AM Leigh Griffin wrote: > >> Hey everyone, >> >> Just a quick mail to let folks know that from October 1st, the CPE team >> will be working towards supporting the EPEL community. We just posted a >> quick comm blog on it [1] and wanted to raise wider awareness on the devel >> list. More good things to follow in the coming weeks and I will try and >> cross post here, but please consider following the EPEL mailing list [2] >> where we will be posting more regular updates. >> > > Cool. EPEL has long been a necessary part of RHEL environments, and for > many of us RHEL would not be welcome in our production environments without > it. I especially include components like ansible, which may be available > from additional RHEL yum channels but are awkward, at best, to provide in > CentOS and non-specifically-subscribed default RHEL systems. It's going to > especially require attention with the 4.x release of ansible, which > requires python 3.6 or later, and which originally required python 3.8 > which was not available for RHEL 7 or CentOS 7. I thought I might have to > set up pyenv, which I did *not* want to do! > Thanks Nico for the input and observations here, this is exactly what we want to hear as we look to make improvements :) > > Nico Kadel-Garcia > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > -- Leigh Griffin Senior Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Incorrect bodhi message "This update's test gating status has been changed to 'failed'."
On Thu, Sep 2, 2021 at 9:13 PM Neal Gompa wrote: > On Thu, Sep 2, 2021 at 4:08 PM Leigh Griffin wrote: > >> >> >> On Thu, Sep 2, 2021 at 8:40 PM Adam Williamson < >> adamw...@fedoraproject.org> wrote: >> >>> On Thu, 2021-09-02 at 13:54 -0500, Michael Catanzaro wrote: >>> > On Thu, Sep 2 2021 at 07:49:29 PM +0100, Leigh Griffin >>> > wrote: >>> > > Gating is optional so it shouldn't be causing an issue directly for >>> > > those who haven't opted in >>> > >>> > I believe this is incorrect, it's now required for critical path >>> > packages. Otherwise it wouldn't be running at all, because I don't >>> > believe we've opted-in to anything. (If we had opted in, where would >>> we >>> > have configured that?) >>> >>> Yes, that is right. There is now project-wide gating on openQA tests >>> for critpath updates. >>> >> >> Ah today I learned something new! Apologies for misinformation. >> >>> > >>> > > > I should not receive any emails telling me that tests >>> > > > have failed unless some test has actually failed. >>> > > >>> > > Agreed, go ahead and file it as a bug on the Bodhi tracker and we >>> can >>> > > take a look at it >>> > >>> > I think we have a bug report already, actually, but I just don't know >>> > where it is. :/ I can report a new issue if nobody remembers where to >>> > find the existing one. >>> >>> I fixed the bug, months ago, when you first reported it: >>> https://github.com/fedora-infra/bodhi/pull/4221 >>> but the PR has not been merged, because Bodhi's CI is broken, and no- >>> one who has the power to merge the PR despite the CI failure has done >>> so. See: >>> https://github.com/fedora-infra/bodhi/pull/4221#issuecomment-860011362 >> >> >> I have tagged the blocking bug for my team to take a look at tomorrow, >> hopefully we can get these merged in. >> > > This has been an issue for me as well. I started work on trying to improve > the intelligence on triggering offline updates from PackageKit, but the PR > I submitted to propagate more data from Bodhi into updateinfo metadata > hasn't been merged despite being approved for months for similar reasons: > https://github.com/fedora-infra/bodhi/pull/4214 > Thanks Neal, I added it to my list and have opened a dialog to get more insights into the current state of Bodhi. I'd like to understand why there is a bottleneck here from a merge permissions perspective. I will keep folks posted. > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > _______ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > -- Leigh Griffin Senior Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Incorrect bodhi message "This update's test gating status has been changed to 'failed'."
On Thu, Sep 2, 2021 at 8:40 PM Adam Williamson wrote: > On Thu, 2021-09-02 at 13:54 -0500, Michael Catanzaro wrote: > > On Thu, Sep 2 2021 at 07:49:29 PM +0100, Leigh Griffin > > wrote: > > > Gating is optional so it shouldn't be causing an issue directly for > > > those who haven't opted in > > > > I believe this is incorrect, it's now required for critical path > > packages. Otherwise it wouldn't be running at all, because I don't > > believe we've opted-in to anything. (If we had opted in, where would we > > have configured that?) > > Yes, that is right. There is now project-wide gating on openQA tests > for critpath updates. > Ah today I learned something new! Apologies for misinformation. > > > > > > I should not receive any emails telling me that tests > > > > have failed unless some test has actually failed. > > > > > > Agreed, go ahead and file it as a bug on the Bodhi tracker and we can > > > take a look at it > > > > I think we have a bug report already, actually, but I just don't know > > where it is. :/ I can report a new issue if nobody remembers where to > > find the existing one. > > I fixed the bug, months ago, when you first reported it: > https://github.com/fedora-infra/bodhi/pull/4221 > but the PR has not been merged, because Bodhi's CI is broken, and no- > one who has the power to merge the PR despite the CI failure has done > so. See: > https://github.com/fedora-infra/bodhi/pull/4221#issuecomment-860011362 I have tagged the blocking bug for my team to take a look at tomorrow, hopefully we can get these merged in. > > -- > Adam Williamson > Fedora QA > IRC: adamw | Twitter: adamw_ha > https://www.happyassassin.net > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > -- Leigh Griffin Senior Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Incorrect bodhi message "This update's test gating status has been changed to 'failed'."
On Thu 2 Sep 2021, 18:27 Michael Catanzaro, wrote: > Hi, > > In https://bodhi.fedoraproject.org/updates/FEDORA-2021-7558b7e7fc I > received a message from bodhi: > > """ > This update's test gating status has been changed to 'failed'. > """ > > However, no tests actually failed yet, and the gating status is > adjusted to "waiting" immediately after. > > This is a regression from the recent change to enable test gating in > bodhi. I remember complaining on this list at the time the change was > implemented, but apparently nothing happened. Please revert all this > gating stuff until it can be done without leaving inaccurate comments > on the updates! Gating is optional so it shouldn't be causing an issue directly for those who haven't opted in I should not receive any emails telling me that tests > have failed unless some test has actually failed. Agreed, go ahead and file it as a bug on the Bodhi tracker and we can take a look at it > Thanks. > > Michael > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
CPE to staff EPEL
Hey everyone, Just a quick mail to let folks know that from October 1st, the CPE team will be working towards supporting the EPEL community. We just posted a quick comm blog on it [1] and wanted to raise wider awareness on the devel list. More good things to follow in the coming weeks and I will try and cross post here, but please consider following the EPEL mailing list [2] where we will be posting more regular updates. Leigh [1] https://communityblog.fedoraproject.org/cpe-to-staff-epel-work/ [2] https://lists.fedoraproject.org/archives/list/epel-de...@lists.fedoraproject.org/ -- Leigh Griffin Senior Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Source-git SIG report #1 (June 2021)
This is a super update report, thanks for sharing CPE have activated an open source license for Gitlab to trial out some of the workflows and features. This is their top level SaaS offering which they grant to all open source projects so it has all the features we would need for testing. Stephen (on CC) and I have admin access. I'd love to grant folks in the SIG access, if someone can ping me a list of emails that are associated with a gitlab.com account (you need to register!) I can make that happen. Leigh On Thu 24 Jun 2021, 10:17 Tomas Tomecek, wrote: > Greetings from the Fedora source-git SIG! We are planning to start > publishing reports of what we are working on so everyone can easily > pay attention and get involved if interested. If you have any ideas, > comments or requests, don’t be shy and let us know :) > > Here’s a short list of things which we are working on. > > ## Choosing git forge to host source-git repositories > We need to find a home for all the source-git repositories. This is > actually a really hard task because we have many options (github.com, > gitlab.com, pagure.io, src.fedoraproject.org, something custom or > on-premise) and different expectations: some projects already have > repos set up on different platforms while Pagure is the primary forge > now. Since the CPE team is investigating GitLab as a forge, it's even > harder for us to figure out the primary forge. We may end up > supporting both actually: pagure.io and gitlab.com. What are your > thoughts on this topic? Would you prefer pagure.io or gitlab.com > More info: > * https://pagure.io/fedora-source-git/sig/issue/1 > * https://pagure.io/fedora-source-git/sig/issue/7 > > ## High-level workflow proposal up for review > Hunor proposed a high-level workflow linked below and I strongly > recommend reading it. We have also started discussing many details in > the process, such as getting archives: should we generate one from the > source-git repo or use the official release archive from upstream? > > Another big topic in terms of workflows are rebases (= updates to the > latest upstream release, which are very common in Rawhide). Rebases > are straightforward in dist-git, but when your source-git repo has > complete upstream git history, they are no longer trivial, especially > if one wants to get a review of a rebase. > > More info: > * https://pagure.io/fedora-source-git/sig/issue/2 > * Workflow proposal: > https://pagure.io/fedora-source-git/docs/pull-request/2 > * > https://pagure.io/fedora-source-git/docs/blob/main/f/resources/CommitRules.pdf > * https://pagure.io/fedora-source-git/sig/issue/8 > > ## Tooling > Packit is the tooling which will be used to work with source-git > repos. No surprise there I assume :D > * https://packit.dev/ > > We've done a lot of work here lately, mainly to polish the process of > creating source-git repos and doing updates of dist-git repositories > based on the source-git content. > * https://packit.dev/docs/source-git/work-with-source-git/ > * https://github.com/packit/packit/releases > > ## Interested? > We meet biweekly on Wednesdays via gmeet, 2:30 - 3:30 UTC, next one is > scheduled for July 7th. > * https://calendar.fedoraproject.org/SIGs/2021/7/5/#m9982 > > Everyone is welcome to join the SIG or provide any feedback on the > issues and PRs above. > > You can always find the latest information over here: > * https://fedoraproject.org/wiki/SIGs/Source-git > * https://pagure.io/fedora-source-git/sig/issues > > I'd like to thank all the SIG members for being so active, so happy to > work with all of you! > > Cheers, > Tomas > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Gitlab namespace: request to gain ownership for the Fedora project
Hey all, I'm tracking a ticket here <https://pagure.io/fedora-infrastructure/issue/10028> to help progress some R work around the Gitlab usage which the CPE team is taking on. The current namespace is reserved and inactive. I'm just checking if someone here owns that namespace and can work with me to get access to it. If not, in one weeks time, I will request the name space under the cybersquatting policies that Gitlab has. Thanks, Leigh -- Leigh Griffin Senior Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Is there interest in Quantum computing in Fedora?
Count me in for sure. Answer to Matthew inline! On Fri, Jan 15, 2021, 16:11 Matthew Miller wrote: > On Fri, Jan 15, 2021 at 12:58:28PM +, Stephen Coady wrote: > > I've recently been experimenting with Quantum computing and learning > > about its uses and benefits. There are currently libraries available > > in python to experiment with this technology so I thought it would be > > interesting to see if others in the community were working in this > > area. > > I'd love to see us in this area. Is this meant to be used with IBM's > cloud-based quantum computing offerings, or are there other hardware > options? > Qiskit is aimed at multiple Quantum hardware architectures and the Open QASM format aims to be vendor neutral. For general community awareness, the IBM Quantum Experience is heavily customized and linked into Qiskit (which came from IBM so no surprise) to effectively provide IBMQ as a default hardware to run almost out of the box on. I also know that OpenShift has an operator which came from some R work in this area which is pretty cool to shift workloads into Quantum. https://github.com/husky-parul/openshift-quantum-operators > > -- > Matthew Miller > > Fedora Project Leader > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: AArch64 support for container and flatpak builds
Great to see this land, well done :) On Thu, Dec 10, 2020 at 10:44 AM Mark O'Brien wrote: > All, > We are very happy to announce that we now have AArch64 support for flatpak > and container fedpkg builds in production! > > By default all flatpak and container builds will be built on both > architectures from now on. > > Thanks, > Fedora OSBS initiative > -- Leigh Griffin Senior Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: About the Future of Communishift
luster returns (if it even does, I > am unsure that it will, since running multiple OpenShift clusters > doesn't make sense anymore), it will require a vetting process of some > kind (that has yet to be created) to ensure that CPE is comfortable > with partial responsibility of the application, since they need to > care about the data it stores. > Legally we have to have agreements with the service owners and still be on the hook as the overall owner of it, it's messy and complicated but you are correct, there is a path forward through vetting and good processes. > > So, I guess... wait and see? > Finger crossing helps :) > > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
CPE Year in Review: Nest Q
Hey everyone, At Nest with Fedora the CPE team will be presenting a Year in Review. As part of that we want to hold a Community Q and this is a general call for any questions that you might like to have answered by the CPE Leadership team in that call? We can curate the top questions (with thanks to Ben Cotton who is volunteering his help here) and will follow up on any questions we can't fit in timewise in the call with a Community Blog. Looking forward to seeing you all virtually at Nest! Leigh -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Data Centre Move Update - Moving Week!
On Wed, Jun 17, 2020 at 2:49 PM Aoife Moloney wrote: > # DataCentre Move Update: 2020-06-17 > > Hi everyone, > > I hope you are all having a good week! I would like to give you some > updates on the Data Centre Move project that some members of the CPE > team have been involved in over the last few months. > > As you are probably aware at this point, the Fedora hardware has been > moving from the current data centre in Phoenix, Arizona to IAD2 in > Washington and to facilitate this move, we have been reducing services > available in Fedora to what is essential for operations over a 6-8 > week period. We are now officially operating in the reduced Fedora service and the > final hardware shipment has been packed up and is in transit to its > new home! > > We are expecting to begin re-racking the hardware in the new > datacentre from next week, beginning June 22nd. > > ### Service Bringup Schedule > The team intend to prioritize the bringup of the following, but not > limited to, services between the period of 22nd June to August 14th: > * Builder systems - est by July 3rd > * Additional high availability capacity > * Staging environment - est by July 28th > * CommuniShift (in RDU-CC which was paused in May to allow for the > bringup of the reduced Fedora service) - est by July 28th > * Remainder of applications for Fedora, such as Nuancier, Fedocal, etc > - est by August 12th > > For a full list of services that are impacted by this move, please see > previous hackmnd note https://hackmd.io/hpYYJQRjQy-oHxUS7IonIA?view > > ### Additional Communications for Context > For additional context, Kevin Fenzi has sent mails last week on a > daily basis alerting the community on services as and when they are > being brought down. > Please see copy of emails sent here: > Day 1 > https://lists.fedoraproject.org/archives/list/infrastruct...@lists.fedoraproject.org/thread/WYMAEIYUQSX6NMZ4LHJBBZBGJZCCEUWF/ > Day 2 > https://lists.fedoraproject.org/archives/list/infrastruct...@lists.fedoraproject.org/thread/56CHCFO6IKWC2JEOL657KHEGIOOIUAIU/ > Day 3 & 4 > https://lists.fedoraproject.org/archives/list/infrastruct...@lists.fedoraproject.org/thread/CC2PHZMZC2EDVVGXRXOK34S5EM5K7DFH/ > > We also have a 'What this move means for you' email that went to > devel-annou...@fedoraproject.org > > https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org/message/27U6YT73556KYW2RIFJO6J2HYMYVP22U/ > > > ### What can you do to help? > We would ask you to please be patient and be aware that at times PR, > build requests, and other build items may not work due to resource > limitations. Please open tickets when this happens as we may not be > able to get to it immediately or know the problem is occurring. > > We also have a list of services that we are asking for help validating > once bringup is complete in IAD2, so if you are able to assist us, > please check this hackmd and reach out to Kevin Fenzi (nirik) and/or > Stephen Smoogen (smooge) for instruction as the validation process may > be different in the new datacentre > https://hackmd.io/op6N_nIaR7aMzw9Ib-sDAQ > > > > Thank you for your patience and understanding during this crucial time > as we complete the final 9 weeks of this project! > Great work by everyone involved in the Community for helping out here and offering moral support to the team, it was very much appreciated by everyone within the CPE team who were involved here. > > > > Kind regards, > Batman, Robin and Alfred :) > > > > -- > Aoife Moloney > Product Owner > Community Platform Engineering Team > Red Hat EMEA > Communications House > Cork Road > Waterford > ___ > devel-announce mailing list -- devel-annou...@lists.fedoraproject.org > To unsubscribe send an email to > devel-announce-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House C
Re: Day one of the datacenter service migration
On Tue, Jun 9, 2020 at 10:31 AM Kevin Kofler wrote: > Kevin Fenzi wrote: > > The openshift apps move caused a outage for the elections app (both a > > short one while it was entirely down, and another short time when > > authentication wasn't yet working) > > Doing a migration of the elections app in the middle of a voting period > sounds like very bad timing to me. > The project plan was well advertised and we have done our best to keep apps available and stable during a very difficult migration. Unfortunately the colo move had immovable deadlines and our primary concern is the Fedora release cycle and ensuring we don't cause disruption there. > > Will the voting period be extended to compensate for the outage? > > Kevin Kofler > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Self Introduction: Sam Feifer
Welcome Sam, hope to see you around! On Fri, May 29, 2020, 20:30 Samuel Jacob Feifer wrote: > Hi everyone. I am currently a second year computer science student at > Vanderbilt and would love to garner some experience this summer working > with fedora. As my career is quite young, I hope to not only become a more > confident programmer, but also familiarize myself with how professional > programers communicate and interact while working on projects. So far, I've > learned java and python and while my main goal is to contribute to > programs, I would still appreciate just tagging along to a project and > seeing the steps made to finish it. If you'd like to add me to an irc chat > my username and nick are sfeifer. > > Thanks > --Sam > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CPE Weekly: 2020-05-11
On Wed, May 13, 2020 at 2:15 AM clime wrote: > On Tue, 12 May 2020 at 16:28, Clement Verna > wrote: > > > > On Mon, 11 May 2020 at 12:55, Clement Verna > wrote: > >> > >> > >> > >> On Mon, 11 May 2020 at 11:03, Fabio Valentini > wrote: > >>> > >>> On Mon, May 11, 2020 at 10:42 AM Aoife Moloney > wrote: > >>> > ## GitForge Updates > >>> > * We are tracking our progress here (nothing new added yet, fyi) > >>> > https://fedoraproject.org/wiki/Git_forge_update > >>> > * And the council are tracking the community issues in this ticket > >>> > https://pagure.io/Fedora-Council/tickets/issue/292 > >>> > * I have an Office hours IRC meeting slot on #fedora-meeting-1 @ > >>> > 1400-1500 UTC every Thursday. Feel free to stop by and say hi! We can > >>> > talk about Gitforge, or not :) > >>> > >>> I'm wondering, is actually anything happening here? > >> > >> > >> Yes, I am still gathering the "pain points". I am going to open a > ticket in the GitLab tracker (http://gitlab.com/gitlab-org/gitlab) this > week, so that all the discussions about what we are asking will be public. > > > > > > Hey so we now have a public issue[0] with GitLab that we are going to > use to drive the conversation. So if you are interested I highly encourage > you to follow that issue. Also this is currently focusing on the very basic > features of dist-git in purpose once we have a better idea on how these > features looks like in GitLab, we will be able to take a look at the rest > of our needs. > > > > Hope that helps > > > > PS: If there is anything that you feel should be mentioned in the > ticket, please feel free to tell me about it so that I can look at editing > the ticket. > > > > [0] - https://gitlab.com/gitlab-org/gitlab/-/issues/217350 > > Clement, thank you for your open approach. It's a welcomed change (I > mean considering what we have seen from CPE leaders so far). > Thank you for the kind words, it's great to know the efforts we are making to be as transparent as possible are being appreciated. > > > > >> > >> > >>> > >>> The "progress" being tracked in the wiki has been "nothing yet" since > >>> the wiki page was announced a few weekly reports ago, and the linked > >>> council ticket has not been updated in 2-3 weeks either :/ > >>> > >>> > >>> Fabio > >>> ___ > >>> devel mailing list -- devel@lists.fedoraproject.org > >>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org > >>> Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > >>> List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > >>> List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CPE Weekly: 2020-04-26
On Tue, May 5, 2020, 18:52 Fabio Valentini wrote: > On Tue, May 5, 2020 at 4:08 PM Leigh Griffin wrote: > > > > > > > > On Tue, May 5, 2020 at 10:55 AM Guido Aulisi > wrote: > >> > >> Il giorno dom, 26/04/2020 alle 18.13 +0100, Aoife Moloney ha scritto: > >> > # CPE Weekly: 2020-04-26 > >> > --- > >> > title: CPE Weekly status email > >> > tags: CPE Weekly, email > >> > --- > >> > >> Hello, > >> > >> ... snip > >> > > >> > ## GitForge Updates > >> > * We will be tracking our progress here > >> > https://fedoraproject.org/wiki/Git_forge_update > >> > * Please be aware this does not contain any new information, as we > >> > don't have any to share yet. > >> > * However once we have more information for you, we will be posting > >> > it > >> > to the above link, and with the URL in the weekly emails for quick > >> > access. > >> > * We are currently doing a technical deep-dive with our own team on > >> > what we need from GitLab > >> > * We are also still engaging with Fedora Council who are tracking the > >> > Fedora Communities needs here > >> > https://pagure.io/Fedora-Council/tickets/issue/292 > >> > * And we are looking at ways to engage closer with the CentOS > >> > community too to share information as and when we have it > >> > * Public Q sessions are still being discussed to allow for open > >> > conversations in public forums too as we move through this journey, > >> > so > >> > thank you for your patience with us. > >> > >> So you are doing a technical deep-dive now after choosing Gitlab, not > >> before deciding? It's a very strange way to take decisions... > > > > > > We have performed technical analysis at all stages, this is a deeper > dive from two perspectives. The first is in respect to the Council and > FESCo conversations for the proposed changes to ensure distgit > functionality moves through appropriate approval chains and we arrive at a > collaborative solution. The second is more technical questions to help > arrive at what work CPE needs to undertake and what Gitlab may be able to > provide be it tooling / plugin / support and so on. > > <...> > > > We could not perform the latter until we had arrived at a decision > > You keep saying that, but I still fail to understand: Why? > To do so would have been to presuppose that Gitlab was the choice. > > Fabio > > > so we are now actively engaged there and a public facing ticket will be > available soon for the community to track. > >> > >> > >> I'd expect that the entire git forge discussion would start from the > >> beginning, because of the many mistakes that were made in this process. > >> > >> Sorry for my bad english... > >> > >> Guido Aulisi > >> > >> FAS: tartina > >> > >> ___ > >> devel mailing list -- devel@lists.fedoraproject.org > >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org > >> Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > >> List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > > > > > > > -- > > > > Leigh Griffin > > > > Engineering Manager > > > > Red Hat Waterford > > > > Communications House > > > > Cork Road, Waterford City > > > > lgrif...@redhat.com > > M: +353877545162 IM: lgriffin > > > > @redhatjobs redhatjobs @redhatjobs > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CPE Weekly: 2020-04-26
On Tue, May 5, 2020 at 10:55 AM Guido Aulisi wrote: > Il giorno dom, 26/04/2020 alle 18.13 +0100, Aoife Moloney ha scritto: > > # CPE Weekly: 2020-04-26 > > --- > > title: CPE Weekly status email > > tags: CPE Weekly, email > > --- > > Hello, > > ... snip > > > > ## GitForge Updates > > * We will be tracking our progress here > > https://fedoraproject.org/wiki/Git_forge_update > > * Please be aware this does not contain any new information, as we > > don't have any to share yet. > > * However once we have more information for you, we will be posting > > it > > to the above link, and with the URL in the weekly emails for quick > > access. > > * We are currently doing a technical deep-dive with our own team on > > what we need from GitLab > > * We are also still engaging with Fedora Council who are tracking the > > Fedora Communities needs here > > https://pagure.io/Fedora-Council/tickets/issue/292 > > * And we are looking at ways to engage closer with the CentOS > > community too to share information as and when we have it > > * Public Q sessions are still being discussed to allow for open > > conversations in public forums too as we move through this journey, > > so > > thank you for your patience with us. > > So you are doing a technical deep-dive now after choosing Gitlab, not > before deciding? It's a very strange way to take decisions... > We have performed technical analysis at all stages, this is a deeper dive from two perspectives. The first is in respect to the Council and FESCo conversations for the proposed changes to ensure distgit functionality moves through appropriate approval chains and we arrive at a collaborative solution. The second is more technical questions to help arrive at what work CPE needs to undertake and what Gitlab may be able to provide be it tooling / plugin / support and so on. We could not perform the latter until we had arrived at a decision so we are now actively engaged there and a public facing ticket will be available soon for the community to track. > > I'd expect that the entire git forge discussion would start from the > beginning, because of the many mistakes that were made in this process. > > Sorry for my bad english... > > Guido Aulisi > > FAS: tartina > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Previous awesome background images
On Wed, Apr 22, 2020 at 3:41 PM Mohan Boddu wrote: > My personal favorite is Fedora 26 > > https://fedoraproject.org/wiki/Wallpapers#Fedora_26 > > I am not an artist, but the silhouette of the calming woods with the > reflection it on the lake is just *serene*. > Great share on this, adding that to my wallpaper list and some of the other nice ones shared, great trips down memory lane! > > On Fri, Apr 17, 2020 at 5:44 PM Miro Hrončok wrote: > > > > On 17. 04. 20 16:07, Kamil Paral wrote: > > > I'm disappointed with default wallpapers in the latest releases. I > wonder if we > > > could go back to more artistic images from previous releases? Here are > some of > > > my favorite ones: > > > https://fedoraproject.org/wiki/Wallpapers#Fedora_29 > > > https://fedoraproject.org/wiki/Wallpapers#Fedora_27 > > > https://fedoraproject.org/wiki/Wallpapers#Fedora_21 > > > https://fedoraproject.org/wiki/Wallpapers#Fedora_16 > > > https://fedoraproject.org/wiki/Wallpapers#Fedora_15 > > > https://fedoraproject.org/wiki/Wallpapers#Fedora_11 > > > https://fedoraproject.org/wiki/Wallpapers#Fedora_7 > > > > > > Especially the one in Fedora 15 (GNOME edition) and 16 was > outstanding. Can we > > > do more of those, please? > > > > I love both the design and concept of the F25-F28 wallpapers. > > > > "As of the past 3 releases, we choose a sequential letter of the > alphabet and > > come up with a list of scientists / mathematicians / technologists to > serve as > > an inspiration for the desktop background’s visual concept" > > > > > https://blog.linuxgrrl.com/2018/03/06/fedora-28s-desktop-background-design/ > > > > I am sad we haven't followed the pattern. (However I don't know the > reasoning > > for stopping that.) > > > > (I've changed the subject line, because I don't want to participate in > what was > > in there.) > > > > -- > > Miro Hrončok > > -- > > Phone: +420777974800 > > IRC: mhroncok > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CPE Git Forge Decision
On Mon, Apr 6, 2020 at 4:25 PM Adam Williamson wrote: > On Mon, 2020-04-06 at 15:35 +0100, Leigh Griffin wrote: > > > > > Does it mean you didn't consider dist-git<->zuul integration vs. Gitlab > > > CI? I.e. technical differences and advantages of each? If you did, can > you, > > > please, publish it? It would be valuable info for the community and > > > something we can comment on. > > > > > > > Gitlab CI was not part of our evaluation, we are aware it's a service > that > > is offered but did not evaluate it as it wasn't within the scope of our > > exercise. > > So, how does that track with this quote from the decision blog post? > > "Some top level requirements which helped us arrive at this decision > [to choose Gitlab]: > > There is a need for CentOS Stream to integrate with a kernel workflow > that is an automated bot driven merging solution (merge trains). This > allows for richer CI capabilities and minimises the need for human > interaction" > > If you did not evaluate Gitlab CI (and presumably CI capabilities of > the three systems more widely), how did the need for a CI feature - > that is what "merge trains" are - act as a "top level requirement" > which "helped us arrive at this decision"? > I'm talking specifically about CI as a capability, in that specific integrations at a CI level for hooks and other nice stuff which has several known issues in Pagure at an API level, we evaluated that high level requirement. Some stakeholders do not want to use the built in Gitlab CI as we have CentOS CI used extensively and some have homebrewed systems that they use. Hence why we did not go deep on CI at a very functional level outside of known limitations and desires that came up as direct requirements. Merge trains and that capability is plugin / CI based and was explicit in it's scope (it was called out as a need to have merge train functionality) Vs CI in general as it was named as a need. We had discussed that Zuul was a possibility around Pagure as part of that. > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net > http://www.happyassassin.net > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CPE Weekly: 2020-04-04
On Mon, Apr 6, 2020 at 4:34 PM Miro Hrončok wrote: > On 06. 04. 20 17:20, Leigh Griffin wrote: > > > > I'm reaffirming that I hear the concerns and that my team are taking > them on > > board. I am also reaffirming that our engagement point is with the > Fedora > > Council, not at the individual level as the Council is responsible for > listening > > and collating those concerns and speaking on behalf of the entire > community. > > This only makes it more clear that you are not interested in engaging with > the > community directly, but you are deferring that to the Council. This is not > "the > process", this is just a way to justify not engaging. What you say here is > not > very friendly. > I am engaging with the community directly but we have agreed and predetermined engagements with the Fedora Council to enact actual changes. We cannot take the view of a singular person and make changes based on that, we defer to them for prioritisation and their input. That's how the relationship works between CPE and the Fedora Community and it's how formal requests and feedback are routed. > > > It > > is not for me to change how that process works so please reach out to > your > > Council reps and engage through that channel. > > Fedora has an established process for infra changes like this and you have > chosen to bypass it entirely by talking directly to the Council. As explained above we have our formal engagement process. I can bring this up with Council in our next scheduled sync if the feeling is that we should be engaging through other means. I'm happy to accomodate. > And now you say > "this is how this process works" -- well, in fact it isn't. > > https://docs.fedoraproject.org/en-US/program_management/changes_policy/ > > https://pagure.io/Fedora-Council/tickets/issue/292#comment-640101 +1 on that ticket I would like to see clarity on this point so that we can engage in the right way in the future. Our engagement was not designed to side step known processes, it was taken at face value to engage with Council as previously agreed on. > > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CPE Weekly: 2020-04-04
On Mon, Apr 6, 2020 at 12:11 PM Dominik 'Rathann' Mierzejewski < domi...@greysector.net> wrote: > On Monday, 06 April 2020 at 12:41, Leigh Griffin wrote: > > On Sat, Apr 4, 2020 at 9:36 PM Randy Barlow < > bowlofe...@fedoraproject.org> > > wrote: > > > > > On 4/4/20 3:02 PM, Aoife Moloney wrote: > > > > However we do > > > > recognize that it was still nonetheless a decision that was not made > > > > in public, and for that we can only now offer our apologies for this > > > > mistake and learn a hard lesson from it. > > > > > > It's simply not true that this is the only thing that can be done. You > > > can hold off on making a decision, and follow an open process instead. > > > > We are engaged with the Fedora Council on the next steps here for the > > adoption of Gitlab / the retirement of Pagure from the CPE remit. That > much > > of the decision has been made, the actual specifics are what we are > > engaging on to make sure that the Fedora needs are satisfied as we move > > forward. > > The majority here is telling you to hold off execution of that > "decision" and revisit it, but you're ignoring those voices entirely and > offering useless "apologies" instead. You cannot pretend to be part of a > community if you just ignore its other members and do your own thing. > I'm reaffirming that I hear the concerns and that my team are taking them on board. I am also reaffirming that our engagement point is with the Fedora Council, not at the individual level as the Council is responsible for listening and collating those concerns and speaking on behalf of the entire community. It is not for me to change how that process works so please reach out to your Council reps and engage through that channel. > > > > > We do want to let you know that we deeply appreciate the requirements > > > > you have given us and would like to ask you to continue engaging with > > > > us while we are moving through our next steps with GitLab. > > > > > > What would be the goal if the community were to continue to engage with > > > CPE management when it has demonstrated that it does not meaningfully > > > engage with the community? > > > > Your engagement influences how this will look in the future, we have > enough > > gathered to ensure that is the case but given the breadth and depth of > > Fedora, we do wish for people to engage. > > You cannot wish for meaningful engagement in the future if you don't fix > your past mistakes and reverse bad decisions. > I'm happy to fix mistakes, I think it's a wonderful learning opportunity when One encounters a mistake and overcomes it down the line again. Bad decision here is subjective, you have your view on it and I have mine, both are entitled to it. > > Regards, > Dominik > -- > Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org > There should be a science of discontent. People need hard times and > oppression to develop psychic muscles. > -- from "Collected Sayings of Muad'Dib" by the Princess Irulan > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CPE Git Forge Decision
On Mon, Apr 6, 2020 at 3:49 PM Randy Barlow wrote: > On 4/6/20 10:36 AM, Leigh Griffin wrote: > > Answering 100+ replies individually is engaging with the community. > > Happy to stop that if people aren't seeing the benefit of it though. > > Writing 100 e-mails isn't automatically "engagement". > It's a form of engagement among others that we are partaking in day in day out, week in week out. > I could reply to what you wrote above with "If I had a world of my own, > everything would be nonsense. Nothing would be what it is, because > everything would be what it isn't. And contrary wise, what is, it > wouldn't be. And what it wouldn't be, it would. You see?" > > But if I did that, it would be disingenuous to claim that I engaged with > you. > > Your posts are not engaging with the community, but are instead an > avoidance strategy. I have answered every question directly, if I missed one in the multiple threads and someone wants it answered, feel free to forward it onto me directly and I can answer it. > You aren't meaningfully answering what people are > saying. I'm answering to the best of my ability in a truthful and honest way, I can't help how the responses are being received or interpreted. People are forming their own opinions and I'm still happy to engage and try and answer their concerns or thoughts. > You are putting your fingers in your ears and stating things > that are clearly untrue, like it being unique to be in a position where > stakeholders are not aligned. > Everything is untrue when paraphrased to suit a narrative. For sure stakeholder misalignment is part and parcel of Engineering life, CPEs stakeholder needs, our particular remit and how all of these things interact are industry unique in my experience and the kind of alignment needed might never be there that One would expect and hope for in a more traditional Engineering setting. I'm happy to debate that in a separate thread but I feel going into how the team is structured and how that relationship works is a distraction that this thread does not need. Feel free to reach out directly though Randy if you have specific concerns I am happy to help where I can. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CPE Git Forge Decision
On Mon, Apr 6, 2020 at 2:36 PM Dominik 'Rathann' Mierzejewski < domi...@greysector.net> wrote: > On Monday, 06 April 2020 at 12:29, Leigh Griffin wrote: > [...] > > > Yes, this whole "decision" is in dictatorship relation to the > > > community. > > > > > > Not following the standard procedures caused that I and probably > > > many people in the community didn't pay much attention to it. > > > > We followed the procedures that were outlined to us. > > So you think "just following procedures" makes it all right and gives > you mandate to continuing to pursue a decision that the community is > telling you was wrong despite your following procedures? > Our stakeholder and engagement point as a team is Fedora Council. If you have issues with how this was handled from a relationship perspective then please take that up with the Council. We have engaged with fesco in the past at the request of Council and will engage with them in the future in a similar manner. > > > > I thought you are simply going to collect requirements and then we > > > will talk. Collecting the requirements was actually very useful. > > > Providing the analysis for the requirements would be useful. > > > Providing a recommendation would be ok. Providing a "decision" like > > > that crosses the line. > > > > > > It sends quite a bad message that no matter what you start doing for > > > the community and how useful it becomes, RH management can come at > > > any time and make your work vanish, which is what is happening here > > > with pagure on dist-git effort and probably also zuul efforts might > > > get replaced by Gitlab CI. > > > > We have nothing to do with zuul and Gitlab CI may be made available as > > a service if folks want to use it. > > It's not just about CI. You only commented about the least significant > point of the above paragraph and ignored the rest. That seems to be the > pattern with your communication. Please change that. > What point would you like me to comment on? Red Hat is not making work vanish, we are not deleting Pagure from the internet. > > [...] > > > But still, please, listen to what the community is telling you. > > > > We are. > > That's not the impression you are giving here. > > > > While you may have means to force your decision as RH management > > > representative, doing so can be damaging for both sides (RH and > > > Fedora). > > > > We are not forcing a decision. We are still engaged with the Fedora > > Council on next steps and factoring in the requirements of the > > community. Right now, our wider needs are saying we cannot support > > Pagure and we intend on replacing that with Gitlab from a CPE > > perspective. > > You are forcing a decision because you're refusing to revisit the > decision you have made *for* the community without the engagement that > the community feels was required. This decision is made for 2x communities, 1x internal stakeholder and the CPE team. This decision is impacting 4 groups. If you feel so strongly that the decision should be revisited in some way shape or form, make your protests known to the Fedora Council. We engage at that level. > If you had stopped at the first > objections and revisited the decision making process with the rest of > the community involved in an open manner, you would have been forgiven, > because everyone here is trying to assume good faith. Alas, you haven't > done that. Apologizing for your mistakes is a necessary step, but it's > not sufficient. > Ok let's scenario this out so as several people want us to restart and go again, largely because they disagree with the decision and Pagure is the choice that they would have made. If we re-engage now, I firmly believe we will get a whole new set of requirements to complement the existing requirements but scoped deliberately (as has been suggested by numerous replies) to a situation where Pagure is the only choice for Fedora. How do we accommodate that when our other stakeholders' needs are now not being met as a whole and when the original requirements needs are being satisfied by the choice of Gitlab (which will most likely be CE for Fedora). What happens then, how do you suggest we proceed at that point? The other stakeholder groups are already progressing with Gitlab and we can do that for them and pause the Fedora move in this direction if that was the scenario. What happens after months of debate if we cannot bridge that divide? What happens when Pagure is sunset as the CPE team cannot run it / maintain it? I'm genuinely curious here as if this is a path the community want to go down then engage
Re: CPE Git Forge Decision
On Mon, Apr 6, 2020 at 2:14 PM Neal Gompa wrote: > On Mon, Apr 6, 2020 at 8:48 AM Josh Boyer > wrote: > > > > On Mon, Apr 6, 2020 at 8:42 AM Stasiek Michalski > wrote: > > > > > > > On Mon, Apr 6, 2020 at 8:26 AM Stasiek Michalski > > > > > > > > Why is it disappointing? The Pagure project isn't suddenly being > > > > removed from the internet. Is there a reason you can't contribute to > > > > it to add the features you need? > > > > > > I can add features, sure, and I do, but I am also not able or willing > to > > > maintain everything else that goes with Pagure. My disappointment is > > > much more of a manifestation of a fear that if CPE ends up going with > > > Gitlab, there will be nobody else interested enough to maintain it, > > > since Fedora will no longer have any interest in it. > > > > That's a reasonable fear. However, the only way to guarantee that > > fear becomes reality is to walk away from the project out of fear. > > > > Open source works because people contribute. If you want the project > > to live, keep contributing. You can always reassess who is > > contributing and what the health of the Pagure community is as you go. > > Others have said they want to see it succeed, so hopefully they'll > > also contribute. If they don't, and Pagure stagnates, then maybe the > > interest wasn't in building something, it was in having somebody else > > build it for them. > > > > Yes, but if part of the draw of using Pagure is to federate with other > servers, the drop in the "network" weakens things. > > Folks have said it before on here and other places: they use > GitHub.com for the network effect. They don't like GitHub, but they > use it because they value the "network" more than their principles. > But building a network is not a simple process, and takes time, too. > > It's interesting: if you look at the adoption curve for GitLab > relative to when it was created, Pagure isn't doing that badly. GitLab > was created in 2011 and most of its adoption/growth started at the end > of 2015, rising much more dramatically after the end of 2016. Pagure > was created in 2014 as progit, and then renamed a couple years later. > Fedora itself only deployed Pagure in 2017, and the CentOS instance > was rolled out in 2019. Around the same time last year, Pagure was > introduced to the openSUSE community formally and packaged there. > Mageia started looking at it in earnest only a month or so ago. The > Free Software Foundation started working on their Pagure deployment > last summer, and the intent is to launch it by this summer. Trisquel > will be setting up their instance in a matter of weeks. And I'm > ignoring the instances run by companies internally (who aren't even > Red Hat and *do* send contributions upstream!) and the instances run > by people for personal use. ForgeFed is securing funding to hire a > developer to work on Pagure, even! > > When you look at the timeline, we're doing pretty damn well compared > to GitLab on the adoption curve. That in itself says that Pagure is > worth something to people. From my view, there are three things that > make Pagure much more attractive: > > 1. Freedom/federated/decentralized philosophy > 2. Fully FOSS as opposed to Open Core > 3. Backed by a trusted organization (Fedora) that uses FOSS to support > itself and stands for its principles while not being polarizing to the > greater OSS community > > This whole CPE team debacle is attempting to destroy point number 3. > I disagree that we are destroying point 3. CPE cannot own everything and the maintenance of a git forge was outside of our scope of responsibility and Pagure can and should live on irrespective of the CPE teams involvement -- an involvement that really ceased in late 2018 but was being carried on by the passions of individuals in their spare time. The choice here was to invest and become the Pagure team and build out a git forge and staff it accordingly or to add features to Fedora and CentOS that users want / need. > Whether that kills the slowly building momentum for the Pagure project > or not, I don't know. But I'm hoping it doesn't. > > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.or
Re: CPE Git Forge Decision
On Mon, Apr 6, 2020 at 12:10 PM Julen Landa Alustiza < jla...@fedoraproject.org> wrote: > > > > 20/4/6 12:29(e)an, Leigh Griffin igorleak idatzi zuen: > > > Around 10 tickets a month is the average I believe for infra to deal > > with / handle from direct pings. > > > Where? > Infra queue <https://pagure.io/fedora-infrastructure/issues?status=all=pagure=src.fp.o=0_status=> has 6 and releng one in the last month, adding direct pings it's an average of 10 which I got from the Sustaining team. https://pagure.io/fedora-infrastructure/issues?status=all=src.fp.o=pagure=0_status= > lists 50 tickets for the last year and some of them are not actually > pagure issues and some others have attached fixes from the community. > > > -- > Julen Landa Alustiza > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CPE Git Forge Decision
On Mon, Apr 6, 2020 at 11:59 AM Miro Hrončok wrote: > On 06. 04. 20 12:13, Leigh Griffin wrote: > > > > You certainly didn't engage with the community. > > > > > > We did. > > Not enough. You did initially but than you've stopped. You repeating "we > have > made a decision" in various threads over and over is not "engaging with > the > community", it is the exact opposite. Please stop that. > Answering 100+ replies individually is engaging with the community. Happy to stop that if people aren't seeing the benefit of it though. > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CPE Git Forge Decision
On Mon, Apr 6, 2020 at 11:56 AM clime wrote: > > > On Monday, 6 April 2020, Leigh Griffin wrote: > >> >> >> >>> >>> >>> Yes, this whole "decision" is in dictatorship relation to the community. >>> >>> Not following the standard procedures caused that I and probably many >>> people in the community didn't pay much attention to it. >>> >> >> We followed the procedures that were outlined to us. >> >>> >>> I thought you are simply going to collect requirements and then we >>> will talk. Collecting the requirements was actually very useful. >>> Providing the analysis for the requirements would be useful. Providing >>> a recommendation would be ok. Providing a "decision" like that crosses >>> the line. >>> >>> It sends quite a bad message that no matter what you start doing for >>> the community and how useful it becomes, RH management can come at any >>> time and make your work vanish, which is what is happening here with >>> pagure on dist-git effort and probably also zuul efforts might get >>> replaced by Gitlab CI. >>> >> >> We have nothing to do with zuul and Gitlab CI may be made available as a >> service if folks want to use it. >> > > Does it mean you didn't consider dist-git<->zuul integration vs. Gitlab > CI? I.e. technical differences and advantages of each? If you did, can you, > please, publish it? It would be valuable info for the community and > something we can comment on. > Gitlab CI was not part of our evaluation, we are aware it's a service that is offered but did not evaluate it as it wasn't within the scope of our exercise. > > Please, also read what Fabien wrote. > I did. > > >> >>> Additionally, I think that disruption you will cause will take so much >>> time that it would several-times cover the time needed for >>> implementation of all of the features people want to see in pagure. >>> >>> I also don't see people on IRC complaining that pagure.io or src.fp.o >>> doesn't work so maintenance-wise it doesn't seem to be causing >>> problems (there might be some but I didn't notice). >>> >> >> Around 10 tickets a month is the average I believe for infra to deal with >> / handle from direct pings. >> >>> >>> In other words, the change you are suggesting won't be imho good for >>> Fedora. What would be good is to continue doing incremental >>> well-thought changes and not give up on our products. That might >>> result in them coming on top at one point. >>> >>> I consider this whole situation my mistake. For quite some time I >>> wanted to bring improvements to the packaging area to show that we can >>> have top-notch stuff ourselves but it got seriously delayed by me not >>> being always on top of my game. I still want to finish this >>> (https://github.com/rpm-software-management/mock/pull/526) but I >>> regret I didn't go for it earlier. >>> >>> But still, please, listen to what the community is telling you. >> >> >> We are. >> >>> While >>> you may have means to force your decision as RH management >>> representative, doing so can be damaging for both sides (RH and >>> Fedora). >> >> >> We are not forcing a decision. We are still engaged with the Fedora >> Council on next steps and factoring in the requirements of the community. >> Right now, our wider needs are saying we cannot support Pagure and we >> intend on replacing that with Gitlab from a CPE perspective. >> >> >>> Slower but more careful progress is OK. >>> >>> clime >>> >>> > >>> > -- >>> > 真実はいつも一つ！/ Always, there's only one truth! >>> > ___ >>> > devel mailing list -- devel@lists.fedoraproject.org >>> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org >>> > Fedora Code of Conduct: >>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >>> > List Guidelines: >>> https://fedoraproject.org/wiki/Mailing_list_guidelines >>> > List Archives: >>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org >>> ___ >>> devel mailing list -- devel@lists.fedoraproject.org >>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >>> Fedora Code
Re: CPE Weekly: 2020-04-04
On Sat, Apr 4, 2020 at 10:56 PM Chris Murphy wrote: > On Sat, Apr 4, 2020 at 2:36 PM Randy Barlow > wrote: > > > > On 4/4/20 3:02 PM, Aoife Moloney wrote: > > > However we do > > > recognize that it was still nonetheless a decision that was not made > > > in public, and for that we can only now offer our apologies for this > > > mistake and learn a hard lesson from it. > > > > It's simply not true that this is the only thing that can be done. You > > can hold off on making a decision, and follow an open process instead. > > > > > We do want to let you know that we deeply appreciate the requirements > > > you have given us and would like to ask you to continue engaging with > > > us while we are moving through our next steps with GitLab. > > > > What would be the goal if the community were to continue to engage with > > CPE management when it has demonstrated that it does not meaningfully > > engage with the community? > > I agree. Treating this as a fait accompli is not a good idea. > Over a year ago it was decided that Pagure did not meet our mission statement. The exercise we undertook for all our stakeholders (Fedora is one) reaffirmed that CPE will not be in a position to support Pagure going forward outside of pagure.io. This is the next step in that process and the actual specifics of how that looks on Gitlab is not decided yet and we are engaging to figure that out with the Council in tandem. > > There's been a trust reducing event. Repairing the damage should > happen before further actions requiring trust are taken. > I'm happy to have us repair the damage and work towards building an open and trustful relationship and this mail by Aoife is a good first step in that in my opinion. > > Flaws have been discovered in the process used to arrive at the > decision, and therefore it's not clear whether the decision is valid. > Our choice of Forge that CPE will support is valid from the requirements we received The mistake has been admitted, and treating it as moot suggests in > fact nothing has been learned from the mistake. > > > -- > Chris Murphy > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CPE Weekly: 2020-04-04
On Sat, Apr 4, 2020 at 9:36 PM Randy Barlow wrote: > On 4/4/20 3:02 PM, Aoife Moloney wrote: > > However we do > > recognize that it was still nonetheless a decision that was not made > > in public, and for that we can only now offer our apologies for this > > mistake and learn a hard lesson from it. > > It's simply not true that this is the only thing that can be done. You > can hold off on making a decision, and follow an open process instead. > We are engaged with the Fedora Council on the next steps here for the adoption of Gitlab / the retirement of Pagure from the CPE remit. That much of the decision has been made, the actual specifics are what we are engaging on to make sure that the Fedora needs are satisfied as we move forward. > > > We do want to let you know that we deeply appreciate the requirements > > you have given us and would like to ask you to continue engaging with > > us while we are moving through our next steps with GitLab. > > What would be the goal if the community were to continue to engage with > CPE management when it has demonstrated that it does not meaningfully > engage with the community? > Your engagement influences how this will look in the future, we have enough gathered to ensure that is the case but given the breadth and depth of Fedora, we do wish for people to engage. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CPE Git Forge Decision
On Fri, Apr 3, 2020 at 8:15 PM Jeremy Cline wrote: > Hi Leigh, > > On Fri, 2020-04-03 at 17:00 +0100, Leigh Griffin wrote: > > > > > > On Fri, Apr 3, 2020 at 4:20 PM Jeremy Cline > > wrote: > > > On Fri, 2020-04-03 at 05:38 -0400, Neal Gompa wrote: > > > > On Fri, Apr 3, 2020 at 5:29 AM Michal Konecny < > > > mkone...@redhat.com> > > > > wrote: > > > > > On 03/04/2020 01:25, Jeremy Cline wrote: > > > > > > On Thu, 2020-04-02 at 11:52 +0100, Leigh Griffin wrote: > > > > > > > The number of active developers on Fedora initiatives has > > > gone > > > > > > > up > > > > > > > drastically since I joined the team in 2019. You are > > > possibly > > > > > > > not > > > > > > > seeing that as the team have moved from a model of siloed > > > work > > > > > > > on > > > > > > > multiple apps, swimming against the tid working 16 hour > > > days, > > > > > > > to > > > > > > > working on team oriented initiatives to add real value to > > > the > > > > > > > ecosystem. So the noise of working on multiple small things > > > at > > > > > > > once > > > > > > > is not as loud as it was in 2018 which is giving that > > > illusion. > > > > > > I'd always suspected my work added no real value, but never > > > had > > > > > > the > > > > > > proof. I appreciate the validation . > > > > Sorry I missed this among the thread splits and dozens of other > > replies. Ping me offlist if you have specific concerns as I do not > > believe my comment infers a lack of value in your work or any other > > contributor for that matter and the wealth of positive comments since > > is validating that your contributions were indeed most welcome and > > appreciative. If I did somehow infer that your work had no value, I > > do apologise, lets connect though if you have concerns. > > > > I'm not sure how to be more specific, but here goes: > > When you said "the team have moved from a model of siloed work on > multiple apps, swimming against the tid[e] working 16 hour days, to > working on team oriented initiatives to add *real value* to the > ecosystem" (emphasis is mine in order to be more specific), it made me > feel that what you are saying is prior work didn't add "real value". > Other comments you have made in this thread (e.g. "We aren't in the > habit of inventing work to do for ourselves anymore") re-enforce this > feeling. > > While you may believe your comments never implied a lack of value, > I'm not sure how else to interpret your comments throughout this > thread. > Thanks for the clarity Jeremy, I'm sorry if you took my mail up as implying a lack of value from how the team historically worked. As a team we are being tasked more and more with adding what I call real value which is at a new app / service level that has scale, quality and requirements that historically a single developer could not call on. We had some superhuman developers in the past in the team that were able to do every single thing an application needed and produced some wonderful applications that in truth would have taken 10 or more developers to replicate. That team has moved on now and the old style of working was not going to meet the needs and wants of our stakeholders (in this case Fedora Council) and a repurposing of the team to make visible impacts was undertaken. So while we cannot have multiple commits across a plethora of services, we are not focusing our efforts on singular services at a time to generate a value proposition for the community. Sorry once again if you took my comment up as being a sleight, it was most definitely not intended and you have my sincere apologies. > > - Jeremy > > -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CPE Git Forge Decision
> > > Yes, this whole "decision" is in dictatorship relation to the community. > > Not following the standard procedures caused that I and probably many > people in the community didn't pay much attention to it. > We followed the procedures that were outlined to us. > > I thought you are simply going to collect requirements and then we > will talk. Collecting the requirements was actually very useful. > Providing the analysis for the requirements would be useful. Providing > a recommendation would be ok. Providing a "decision" like that crosses > the line. > > It sends quite a bad message that no matter what you start doing for > the community and how useful it becomes, RH management can come at any > time and make your work vanish, which is what is happening here with > pagure on dist-git effort and probably also zuul efforts might get > replaced by Gitlab CI. > We have nothing to do with zuul and Gitlab CI may be made available as a service if folks want to use it. > > Additionally, I think that disruption you will cause will take so much > time that it would several-times cover the time needed for > implementation of all of the features people want to see in pagure. > > I also don't see people on IRC complaining that pagure.io or src.fp.o > doesn't work so maintenance-wise it doesn't seem to be causing > problems (there might be some but I didn't notice). > Around 10 tickets a month is the average I believe for infra to deal with / handle from direct pings. > > In other words, the change you are suggesting won't be imho good for > Fedora. What would be good is to continue doing incremental > well-thought changes and not give up on our products. That might > result in them coming on top at one point. > > I consider this whole situation my mistake. For quite some time I > wanted to bring improvements to the packaging area to show that we can > have top-notch stuff ourselves but it got seriously delayed by me not > being always on top of my game. I still want to finish this > (https://github.com/rpm-software-management/mock/pull/526) but I > regret I didn't go for it earlier. > > But still, please, listen to what the community is telling you. We are. > While > you may have means to force your decision as RH management > representative, doing so can be damaging for both sides (RH and > Fedora). We are not forcing a decision. We are still engaged with the Fedora Council on next steps and factoring in the requirements of the community. Right now, our wider needs are saying we cannot support Pagure and we intend on replacing that with Gitlab from a CPE perspective. > Slower but more careful progress is OK. > > clime > > > > > -- > > 真実はいつも一つ！/ Always, there's only one truth! > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CPE Git Forge Decision
On Sat, Apr 4, 2020 at 2:43 AM Randy Barlow wrote: > On 4/3/20 4:41 PM, Leigh Griffin wrote: > > This is how a specific flavour of software development works centered on > > a singular product, with a shared vision. The CPE relationship with > > stakeholders is unique, it's clear the visions are not aligned across > > all bodies (and we do not expect it to be) and we don't have a product. > > We have taken a more formal project requirements elicitation approach > > for this phase. > > It is not unique, it is entirely common. It is typical for software > products to have a variety of stakeholders with different competing > visions. I've not worked on any software product in my career that had a > single aligned vision among stakeholders, at Red Hat or anywhere else, > companies large and small. Nothing about this project is out of the > ordinary in this regard. > CPE is entirely unique in this industry and is not perfectly aligned to the idealistic software engineering process, we are getting there. > > You do have a product: it's called dist-git. > That's not a product. > > That is what we are doing right now by engaging on the specific needs > > for our Gitlab instance(s). We are doing this and over the next 2 weeks > > will be engaging with each group on specifics now that a path has been > > set. At that point the real disagreements can be decided upon by our > > product owner in conjunction with stakeholders, this will not be a > > decision in a vacuum. > > Specific needs are evaluated before making a decision, not after. That's > engineering basics. > We evaluated the needs necessary to make a decision. > > > We didn't quash communication for reasons already mentioned. We didn't > > facilitate it is a more accurate assessment, for which we have > > acknowledged and apologized. > > You certainly didn't engage with the community. We did. > Fedora has a change > process, and every other significant change goes through it. We were instructed to go through Council, which we did. Sure, not > everyone is happy with the results of every decision, but there is at > least open discussion. That open discussion often influences the > decision. You didn't do that here, and the only communication of the > decision was buried in an e-mail that many people don't read. The blog post went out later than intended due to real life issues the volunteers who publish it had, that was outside of our control and less than ideal. I opened the thread first thing on Monday That > communication was also a decision, not an invitation for discussion. > There is no process now for discussion to influence the decision, a > cornerstone of open development. > > This is not open. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CPE Git Forge Decision
On Fri, Apr 3, 2020, 20:26 Randy Barlow wrote: > On 4/3/20 3:08 PM, Leigh Griffin wrote: > > It may have caught that for sure but it would have opened a lot more > > problems as stakeholders try to counter each others requirements with > > new more specific requirements to influence the decision. > > This is how software development is *supposed* to work. This is how a specific flavour of software development works centered on a singular product, with a shared vision. The CPE relationship with stakeholders is unique, it's clear the visions are not aligned across all bodies (and we do not expect it to be) and we don't have a product. We have taken a more formal project requirements elicitation approach for this phase. It is the job of > the product owner to resolve disagreements between stakeholders That is what we are doing right now by engaging on the specific needs for our Gitlab instance(s). We are doing this and over the next 2 weeks will be engaging with each group on specifics now that a path has been set. At that point the real disagreements can be decided upon by our product owner in conjunction with stakeholders, this will not be a decision in a vacuum. not to > quash communication between them. > We didn't quash communication for reasons already mentioned. We didn't facilitate it is a more accurate assessment, for which we have acknowledged and apologized. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CPE Git Forge Decision
On Fri, Apr 3, 2020, 17:42 Adam Williamson wrote: > On Fri, 2020-04-03 at 12:07 -0400, Ben Cotton wrote: > > On Fri, Apr 3, 2020 at 11:59 AM Leigh Griffin > wrote: > > > > Can we *please* see the final actual definitely official Fedora list, > > > > then? If this is supposed to be an open process? > > > @Ben Cotton can oblige here, it's not my place to share it without a > stakeholder approval. > > > > The list sent to CPE is below. While there was no intent to hide it > > (it can be reconstructed from the council-discuss thread), it was a > > mistake on my part to not explicitly post this at the end of the > > discussion. > > > > As a Fedora contributor, I want the git forge to integrate with FAS so > > that it can use FAS to provide authentication and authorization. > > > > As a Fedora contributor, I want the git forge to integrate with > > fedora-messaging so that it can be a part of automatic workflows. > > > > As a Fedora contributor, I want it to be easy to add new contributors > > to a project (and optionally to enable self-adding) so that joining > > new teams is low-friction. > > [snip] > > Uh...wow. > > So, Leigh was correct, Disclaimer that this is not aimed at you Adam, it's a broad statement. It's a shame that the perception is that I'm not correct or truthful on points like this. I can see why that might be the case given problems with the communication flow but know this, what I stated in all of my replies is truthful and up front about how we evaluated and discussed this. Whether we got it perfect or could have done things differently is another discussion. and the F/OSS and self-hosting requirements are > entirely removed from this list. Not adjusted or de-emphasized or given > nuance, but simply removed entirely. > > I highly dispute the idea that the removal of the F/OSS requirement > could be "reconstructed" from that initial list plus the discussion at > > https://lists.fedoraproject.org/archives/list/council-disc...@lists.fedoraproject.org/thread/OEPDGVKYAJIQ6YYZU5J3XT3LHXFROFI5/ > . I do not believe that is the case at all. Matthew's comment is > confusing and ambiguous, and there was no follow-up to it (at least, > not the F/OSS part of it), and it seems extremely questionable to me > that we would remove such a fundamental requirement based solely on one > confused comment from Matthew. He is the FPL, he is not the Pope. > > The end result of this is that we (Fedora) have somehow indicated to > CPE that we have no preference whatsoever for F/OSS tooling. I do not > believe that should have been the case. > > The self-hosting requirement at least Matthew was more clear in opining > should be removed, but it is still surprising to me that the process > here went "gather a list of requirements from the community, then if > Matt says he disagrees with one, take it out immediately but don't tell > anyone you did that"! (also I'll note that his substitute requirement > that out-migration be easy does not appear to be captured in the final > list, although it seems this probably *is* the case with Gitlab so we > don't have a problem there.) > > One thing I'll note here: this is *exactly* the kind of thing that > would have come to light very quickly if the open process which was > committed to at the start had actually been followed through on. > It may have caught that for sure but it would have opened a lot more problems as stakeholders try to counter each others requirements with new more specific requirements to influence the decision. The approach taken, for better or worse evaluated it at a functional level without that noise factor. The trade off is losing an opportunity like this, however it could have been picked up several other ways and Ben has already apologised for not sharing back the final list. > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net > http://www.happyassassin.net > ___ > council-discuss mailing list -- council-disc...@lists.fedoraproject.org > To unsubscribe send an email to > council-discuss-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/council-disc...@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CPE Git Forge Decision
On Fri, Apr 3, 2020, 18:22 Adam Williamson wrote: > On Fri, 2020-04-03 at 13:18 -0400, Matthew Miller wrote: > > On Fri, Apr 03, 2020 at 01:04:33PM -0400, Ben Cotton wrote: > > > For what it's worth, when I sent the list I included a reminder that > > > FOSS is always our strong preference where viable. It was a mistake to > > > not leave that in as a user story. I own that. I did that because of > > > > Eh, I remember it somewhat differently. I don't think that _it is our > strong > > preference and very important to our community that this be open source_ > is > > a _functional_ requirement, and doesn't really fit as a user story. So we > > pulled that out and emphasized it separately rather than leaving it as > one > > among many in the list. > > Can Leigh comment on whether this was then considered in the decision > process based on the summarized user stories, or was it lost? > We read it and like the wording implied it was a strong preference. It was not a requirement and it did not bind our decision not did emotive discussions or other comments, we dealt with the requirements at hand. It will certainly influence our decision to opt for Gitlab CE for the Fedora preference to stay open source. > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net > http://www.happyassassin.net > ___ > council-discuss mailing list -- council-disc...@lists.fedoraproject.org > To unsubscribe send an email to > council-discuss-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/council-disc...@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CPE Git Forge Decision
On Fri, Apr 3, 2020, 18:21 Adam Williamson wrote: > On Fri, 2020-04-03 at 13:04 -0400, Ben Cotton wrote: > > > One thing I'll note here: this is *exactly* the kind of thing that > > > would have come to light very quickly if the open process which was > > > committed to at the start had actually been followed through on. > > > > You are absolutely right. I screwed up. > > Just to be clear, by that comment I was referring to the whole stuff > about open meetings and calls and things that were supposed to happen > before the decision was made, but which CPE called off because the > decision was "obvious". > That was not the case and I have explained this several times. There was an open discussion on the Fedora requirements before they were finalized. There was not an open discussion on the entire list end to end for reasons I have already stated as cross stakeholder analysis with no recourse for all stakeholders involved was not something that would have added value. I stand over that and again I apologise for not looping the entire stakeholder group in. -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net > http://www.happyassassin.net > ___ > council-discuss mailing list -- council-disc...@lists.fedoraproject.org > To unsubscribe send an email to > council-discuss-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/council-disc...@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CPE Git Forge Decision
On Fri, Apr 3, 2020 at 4:20 PM Jeremy Cline wrote: > On Fri, 2020-04-03 at 05:38 -0400, Neal Gompa wrote: > > On Fri, Apr 3, 2020 at 5:29 AM Michal Konecny > > wrote: > > > On 03/04/2020 01:25, Jeremy Cline wrote: > > > > On Thu, 2020-04-02 at 11:52 +0100, Leigh Griffin wrote: > > > > > The number of active developers on Fedora initiatives has gone > > > > > up > > > > > drastically since I joined the team in 2019. You are possibly > > > > > not > > > > > seeing that as the team have moved from a model of siloed work > > > > > on > > > > > multiple apps, swimming against the tid working 16 hour days, > > > > > to > > > > > working on team oriented initiatives to add real value to the > > > > > ecosystem. So the noise of working on multiple small things at > > > > > once > > > > > is not as loud as it was in 2018 which is giving that illusion. > > > > I'd always suspected my work added no real value, but never had > > > > the > > > > proof. I appreciate the validation . > Sorry I missed this among the thread splits and dozens of other replies. Ping me offlist if you have specific concerns as I do not believe my comment infers a lack of value in your work or any other contributor for that matter and the wealth of positive comments since is validating that your contributions were indeed most welcome and appreciative. If I did somehow infer that your work had no value, I do apologise, lets connect though if you have concerns. > > > > > > > > - Jeremy > > > I bow before you mighty Jeremy and the work you did. The fedora > > > messaging is really nice replacement of the fedmsg, although is not > > > used > > > by every application yet. > > > > > > I also want to thank you for handing me off the Anitya and > > > the-new-hotness. It helped me grow my wizard realm in Fedora > > > Universe. :-) > > > > I would also like to echo my appreciation of Jeremy and his work. In > > particular, anitya is one of the tools I literally rely on to keep > > track of my packages and keep them fresh. Without anitya, I would be > > unable to do so. And we've slowly started to see other distributions > > starting to rely on it too (Arch, Alpine, PLD, Mageia, openSUSE). > > > > So, thank you for building such an awesome tool, and thank you Michal > > for taking up the reigns after that. > > > > I can hardly take credit for anitya. pingou started it as far as I know > and the project has over 50 contributors to the code, not to mention > all the issues and work to map projects on release-monitoring.org > itself. > > I appreciate all the kind words from folks and I do know that my work > has, on occasion, provided more value than the trouble it caused. > > - Jeremy > _______ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CPE Git Forge Decision
On Fri, Apr 3, 2020 at 4:04 PM Adam Williamson wrote: > On Fri, 2020-04-03 at 13:18 +0100, Leigh Griffin wrote: > > > > > What I'm looking at is the commit logs. That's all that ultimately > > > matters. But see above revisions, of course. > > > > > > > I think that's a very narrow view of the world to base your assertions on > > commit logs only, I don't see the value in it. If your end argument here > is > > that CPE do not spend enough time working on Fedora things then you are > > very mistaken. Almost 80% of our team capacity is on Fedora and our > > upcoming Q2 initiatives this is the same. > > Just to make sure this is really clear, no, that's not my intent at > all. I was only following up on the question of whether the amount of > resources available for what was previously referred to as "Fedora > infra" (as opposed, for instance, to "Fedora release engineering") had > increased, decreased or stayed the same (with "stayed the same" seeming > to be the ultimate conclusion). By including or excluding anyone from > the lists I absolutely did not mean to imply anything about the value > of their contributions, or whether those contributions were to "Fedora" > in a larger sense - I was only trying to keep it a like-for-like > comparison. It's obvious from your and Clement's emails that this idea > got lost somewhere as we got into the weeds of commit logs and the > like, so I apologize for that, particularly as it turns out my initial > impression that the resources available had declined was incorrect. I > probably work closer with the releng folks than anyone and I certainly > value their work highly! > I accept that apology and I'm glad I could straight out the state of CPE for others to see, so it was a positive contribution to the discussion. > > The initial suggestion I made that triggered this subthread was not > "perhaps CPE isn't spending enough time on Fedora" (I certainly don't > believe that or intend to suggest it) but "perhaps Red Hat is not > providing enough resources to CPE and other teams in order for Fedora > to be run the way the Fedora community believes it should be run". As I > said to Clement, I think the suggestion still bears consideration, > given that Clement says the workload has increased appreciably. > +1 I'd make that representation to Fedora Council who in turn can take it to the right folks in Red Hat. > > > > > Can you help me understand what the mystery is about? We took in 300+ > > > > requirements that we distilled down into the generic list that we > came > > > > up > > > > with, many of which are buckets / Epics. Every single requirement was > > > > analysed. I have said this multiple times but please, if this is > still > > > > a > > > > mystery to you, let me know how I can help clarify it. > > > > > > The specific gap I am talking about is the gap between this list > > > submitted by Ben Cotton on behalf of Fedora: > > > > > > > > > > https://lists.fedoraproject.org/archives/list/council-disc...@lists.fedoraproject.org/thread/OEPDGVKYAJIQ6YYZU5J3XT3LHXFROFI5/ > > > > The thread you reference is not the list that was submitted. The first > post > > on that is not the final list, the final list was a result of the debates > > and discussions that occurred on that thread and was submitted directly > to > > CPE. To be clear, we did not pull our Fedora requirements from that list > > you are referencing. > > Well, that's interesting. I got that link from earlier in this thread, > where Julen asked if that was the list you meant: > > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/O4GHD2AH2E55JE45H6NUJ46JEDZAKBWY/ > > and you said "yes": > > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/F4HMYWOCACQAJY57G3ZNXMC7PSBRQPZ3/ > > so, I'm only going on what you told us. If it is *not* in fact the > final list, where *is* that final list? > It's in a Google Doc I received, I don't know where the public version is but I think it's only the requirements that were debated that changed. > > There is a substantial comment from Matt in which he downplays the > self-hosting requirement: > > > https://lists.fedoraproject.org/archives/list/council-disc...@lists.fedoraproject.org/message/E5R55AS3Z7QLGRXAT6RGQKJNVXLTAJHJ/ > > and kind of prevaricates a lot on the F/OSS requirement, first > saying that he wants to emphasize it and then kind of saying the > opposite for three paragraphs. So I can see where that might
Re: CPE Git Forge Decision
On Thu, Apr 2, 2020 at 7:48 PM Adam Williamson wrote: > On Thu, 2020-04-02 at 11:52 +0100, Leigh Griffin wrote: > > [up front: apologies for any weird formatting in this email, Evolution > is crashing on me like crazy while I try to edit it, so I'm sending it > from Roundcube which I don't normally do] > > > I'm also not entirely sure about Adam Saleh, but he does not have any > > > infra activity I can find since the end of January and lists himself as > > > working for Exponea on Github and his personal blog. > > > > > > > Adam is working in CPE. CPE isn't entirely about Infra, he is working > > on CI > > improvements at the moment alongside some others > > Okay, well, next time I see him I'll mention he might want to update the > Exponea references :P > > I just pinged him on it :) > But "CPE isn't entirely about Infra" is sort of the point here: my > initial assertion was that there are fewer people working on > *Fedora-relevant app development* than there were before. Rightly or wrongly our span of control is: - Infrastructure service and hardware keep alive - Service maintenance / bug fixes etc The above two are lights on work - Service creation Across 2 distros. The rough breakdowns are >50% of our resourcing just on lights on work. > I'm happy to > accept that there may be more people in the CPE team than there were at > some point in its past, but that's not what I'm actually interested in > here. CI is great (whichever CI you mean, I lose track sometimes :>) but > someone working on CI is not someone working on the Fedora app > infrastructure, or on sourcing/deploying/integrating/maintaining > outsourced replacements for it, which is the actual problem space here. > Anything we do benefits the infrastructure or the services that make it up, the CI work here is improvements that take a lot of the manual work out for us / the community and a lot of our initiatives are geared towards easing that pressure on us while offering a value add. > > > > If I'm missing anyone, please do correct me. > > > > Other developers in our pool right now are: > > - Ryan Lerch > > I mentioned already that Ryan could go in either list or neither - he > was around at both times but I wasn't sure whether to count him as a > developer or not. But he can't count to one list but not the other, as > he's been here all along. :) > > > - Michal Konecny > > - Mohan Boddu > > - Tomas Hrcka > > - Nils Philippsen > > - Vipul Siddharth > > - James Richardson > > > > We additionally have 2 new Ops folks joining us over the next 2 weeks. > > > > Across them, the majority are working on the Fedora aspects (Infra, > > Dev, > > Releng) of the CPE remit. > > So yeah, let's discount the releng folks first, because releng has > existed all along We can't really discount them when their workload extends beyond Tomas and Mohan, that workload hits Smooge, Kevin, Clement and others. Their work is now within the lights on category to help with the workload, look at improving how they operate and ultimately trying to not leave them drown. If they drown, we miss releases. This is a much bigger workload on the team than folks realise. > and - as I said - my original statement was not about > "people who are organizationally in the same team as the people who work > on Fedora app stuff" but "people who work on Fedora app stuff". So that > lets out Mohan and Tomas. > Granted, but I wanted to clarify the above. > > As for the others: so, I didn't count Michal at first as I could not > find any infra-related activity for him, but since you included him I > looked closer, and found he's just hiding himself really well - his > github account name, for some inaccountable reason, is "Zlopez", and his > profile doesn't have his real name in it. I really want to know the story behind that name, I must ask him! > So I finally got his logs: > > https://github.com/Zlopez > https://pagure.io/user/zlopez > > ...and yeah, there's some infra activity there, so add him to the list. > > Initially I was just looking at Github logs, as all the infra stuff I > could find was hosted there, and Nils' list is: > > https://github.com/nphilipp > > which was busy up to the end of December but looked extremely empty all > of this year, so I figured he'd switched track or role or something and > didn't count him. But now I look closer, it seems what happened is he's > been working almost exclusively on a thing called rpmautospec, which is > hosted on Pagure: > > https://pagure.io/Fedora-Infra/rpmautospec > > so, he's clearly working hard on something, although I'm not
Re: CPE Git Forge Decision
On Thu, Apr 2, 2020 at 3:58 PM Michael Catanzaro wrote: > On Wed, Apr 1, 2020 at 8:16 pm, Paul Frields > wrote: > > For a solution to be viable it needs to meet requirements. > > Of course, but the problem is that the requirements identified by CPE > are wildly inconsistent with the actual requirements of the Fedora > community. The Pagure we have right now seems to be working fine for > Fedora. All we really need is occasional light maintenance and ensuring > the infrastructure keeps running. I don't think we'd be having this > conversation now at all if "dist-git must be open source" was a listed > requirement, as it should have been from the beginning. > > We don't need merge trains or MR approvals or mobile apps (seriously?) > or private comments or gists or analytics or basically any of the other > requirements that Neal has lampooned. I understand CentOS and RHEL > really want merge trains, so maybe that one is a good faith > requirement, but I honestly don't think most of the rest of them are. > The list seems to have been concocted by looking at GitLab features > exclusive to Enterprise and Ultimate editions and then listing as many > as possible, not by actually listing features that are really actually > needed to make things work. I know the requirements came from > stakeholders and not from CPE, but the requirements are so far removed > from Fedora's actual needs that it has jeopardized the legitimacy of > the rest of the process. Fedora simply doesn't need any of it. To the > extent that CentOS or RHEL actually needs a non-OSS feature -- and I > don't think they *really* do, because those look like nice-to-haves -- > then that just means that their needs are incompatible with Fedora's. > > So let's fix the requirements first. Attempting to share requirements > with CentOS and RHEL has clearly failed. The CPE team are at the intersection point of CentOS, Fedora and RHEL. We cannot escape that so any requirements gathered needs to respect that. We cannot sustain a service of feature for multiple individual stakeholders of this breadth. This was a driving factor in the exercise and decision. > A corrected requirements list > would start with OSS so that we don't consider non-OSS solutions as > viable for Fedora; they are not. If CPE is dead set on hosted GitLab, > then we should ask GitLab to set up a GitLab CE instance for us, and > let them know that's the only product we're willing to pay for. > > Michael > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CPE Git Forge Decision
On Thu, Apr 2, 2020 at 1:22 PM clime wrote: > > On Thu, 2 Apr 2020 at 12:54, Leigh Griffin wrote: > >> >> >> On Wed, Apr 1, 2020 at 7:28 PM Adam Williamson < >> adamw...@fedoraproject.org> wrote: >> >>> On Wed, 2020-04-01 at 11:49 +0200, Clement Verna wrote: >>> > On Wed, 1 Apr 2020 at 09:47, Panu Matilainen >>> wrote: >>> > >>> > > On 3/31/20 8:44 PM, Adam Williamson wrote: >>> > > >>> > > > I understand there are practical resource considerations and so on >>> > > > here, but I still think this merits more high level and serious >>> > > > consideration. At the very least, if we have somehow reached a >>> point >>> > > > where Red Hat is no longer willing to provide sufficient resources >>> to >>> > > > run Fedora on the lines the Fedora community wants it to be run, we >>> > > > need to recognize that this is a significant problem that needs to >>> be >>> > > > properly aired and discussed and resolved. In this context I'll >>> note >>> > > > that the apparent significant headcount reduction of RH people >>> working >>> > > > on Fedora infrastructure over the last few years is in itself a >>> > > > worrying trend, particularly if you consider it while reading >>> Clement's >>> > > > email. >>> > > >>> > > This. >>> > > >>> > >>> > I don't think this is correct, at least not in CPE, the team has grown >>> over >>> > the past year and every person leaving the team has been replaced >>> (even by >>> > 2 persons in some cases). >>> >>> Okay, I didn't mean to get into detail, but I don't see how this is >>> possible. Unless you're considering 'CPE' as a whole (which includes >>> the infra admin team, release engineering, and docs) versus 'people >>> doing development'. >>> >>> Around two-three years ago, IIRC, we had all these people working on >>> Fedora app/infra development: >>> >>> puiterwijk (who counts as about ten people, admittedly, replacing >>> Patrick with anything besides an entire team was always going to be a >>> challenge) >>> Randy (bowlofeggs) >>> pingou >>> jcline >>> Ralph >>> jflory >>> abompard >>> >>> Right now, I see these people who appear to be on the CPE team and >>> clearly working on Fedora infra/app development: >>> >>> abompard? >>> lrossetti/odra (although I had not heard of or seen him till I started >>> doing research for this post, he seems to be working on fasjson which I >>> don't really run into) >>> pingou >>> scoady >>> cverna >>> >>> I put a question mark by abompard as he clearly works for RH and works >>> a lot on infra, but (looking at internal systems) does not seem to be >>> quite in the same management chain as the others, not sure why that is. >>> >> >> Jim and I are co-managers of the CPE team and the reporting is shared >> between us for logistical reasons (i.e. number of direct reports) >> >>> I'm also not entirely sure about Adam Saleh, but he does not have any >>> infra activity I can find since the end of January and lists himself as >>> working for Exponea on Github and his personal blog. >>> >> >> Adam is working in CPE. CPE isn't entirely about Infra, he is working on >> CI improvements at the moment alongside some others >> >>> >>> If I'm missing anyone, please do correct me. >> >> >> Other developers in our pool right now are: >> - Ryan Lerch >> - Michal Konecny >> - Mohan Boddu >> - Tomas Hrcka >> - Nils Philippsen >> - Vipul Siddharth >> - James Richardson >> >> We additionally have 2 new Ops folks joining us over the next 2 weeks. >> >> Across them, the majority are working on the Fedora aspects (Infra, Dev, >> Releng) of the CPE remit. >> >> >>> Mattia Verga seems to do a >>> lot of work on Bodhi, but AFAICS he is not part of RH CPE. We could >>> count Ryan Lerch (UX) and/or Kevin Fenzi (who's officially admin, but >>> as we all know, does everything) in both list or neither. >>> >>> Maybe the people I remember were not all there at exactly the same >>> time, I'm not 100% sure as I'm not on that team. But it
Re: CPE Git Forge Decision
if we could do another long stint in a singular project to solve a real problem we have. The requirements said this was not viable. > We agree that this process wasn't > actually very open at all, but *even if it had been*, if the result was > preordained, what would have been the point? > it was not preordained. > > Also, why does CPE not *at least* have its ducks very definitely in a > row about exactly how much work is actually going to be involved in all > the options here? This analysis was ran side by side with a datacenter colo move across country in the USA. The AAA project requirements and spin up for replacing FAS. CentOS Stream requirements and phased deliverables. We took a decision to not get as deep technically when the initial set of requirements was trending towards Gitlab. This was a time investment trade off and now we can schedule the deeper tech phase and are making moves in that direction already. > How has this decision taken several months and yet > when people ask "okay, so exactly what is the plan for re-doing all the > Pagure<->dist-git integration with Gitlab, and how much work and how > long is that going to take?", the answer is "uh, we don't know, we're > going to figure it out now"? I hope the above explains it. > Why does the blog post that announced this > decision - talk quite a lot about what the plan is with regard to > pagure.io (that's clearly what it usually means when it says "Pagure", > in context) but nothing at all about what the plan is wrt dist-git? > This was to ensure that the option for project hosting on pagure.io was still there for community members who wish to store their source code in Pagure. It was requested to be explicitly called out by Pingou to make it crystal clear that this decision is not designed to kill Pagure. We are happy to facilitate pagure.io as long as the community find it useful and hopefully we will get interest in helping to maintain that. > > Not to mention that this subthread is about the circumstances in which > Fedora has decided it will accept non-free infra, and that "not viable > and not available" quote. If we count absolutely anything that involves > CPE actually doing any work beyond paying someone else to run it as > "not viable", well, yeah, that's going to render an awful lot of stuff > "not viable", isn't it? But I don't think that's how many people would > necessarily have expected that text to be interpreted. > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net > http://www.happyassassin.net > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CPE Git Forge Decision
y guess that these non critical applications > > are mentioned. If I was putting my own money to sponsor a team to help > > building a Linux distribution I would be asking why do we have to > develop a > > calendar application or why do we need a custom git forge. I personally > > find really great that the different use cases and requirements for the > use > > of Pagure were gathered and I am convinced that people working on this > did > > their very best to find a use case to justify the investment needed in > > Pagure but it seems that we don't have such a thing. > > I think other people are following up on this, but from following the > discussion, it appears to me that there seems to have been a large slip > somewhere along the line from Ben submitting a list of ~50 Fedora > submissions, to Leigh suggesting that (after those were, mysteriously, > "summarized" somehow) Can you help me understand what the mystery is about? We took in 300+ requirements that we distilled down into the generic list that we came up with, many of which are buckets / Epics. Every single requirement was analysed. I have said this multiple times but please, if this is still a mystery to you, let me know how I can help clarify it. > Fedora does not have much in the way of specific > requirements. I also think the confusion between "git forge" and "dist- > git" is a major issue here. On the whole I suspect people using > Pagure.io for project hosting don't have a lot of very specific > requirements, because - let's be honest - Gitlab and Github can > certainly do nearly everything Pagure does as a generic project hosting > system. I could probably move my projects to a Gitlab instance in an > afternoon (depending on how much of a pain it is to set up F/OSS CI on > Gitlab, I have not looked into that yet, and yes, for anyone who hasn't > been looking lately, Pagure does actually have CI integration now). > However, I think we (Fedora) certainly *do* have a whole pile of > requirements for a dist-git system, and Leigh's responses so far (of > the "well we haven't figured all that out yet!" variety) do not give me > confidence that this was fully appreciated in the decision-making > process. > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net > http://www.happyassassin.net > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CPE Git Forge Decision
On Wed, Apr 1, 2020 at 2:47 PM Frank Ch. Eigler wrote: > > > [...] Nor would it have helped with the SLA requirements and > > operational cost. [...] > > What reason is there to believe that a gitlab commercial SaaS might a > smaller operational cost? > I meant that in the sense of the time we invest in it to develop features, fix bugs, keep it on the air etc. > > - FChE > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CPE Git Forge Decision
On Wed, Apr 1, 2020 at 11:33 AM Fabio Valentini wrote: > On Wed, Apr 1, 2020 at 12:24 PM Leigh Griffin wrote: > > > > > > > > On Tue, Mar 31, 2020 at 7:44 PM Chris Murphy > wrote: > >> > >> On Tue, Mar 31, 2020 at 11:45 AM Adam Williamson > >> wrote: > >> > > >> > On Tue, 2020-03-31 at 13:08 -0400, Matthew Miller wrote: > >> > > On Tue, Mar 31, 2020 at 10:48:55AM -0500, Michael Catanzaro wrote: > >> > > > Some failure of process or communication must have occurred > >> > > > somewhere along the lines, because open source should have been > the > >> > > > first and most important requirement. A proprietary software > >> > > > solution is incompatible with the ethos and purpose of the Fedora > >> > > > project. I ask CPE to revise its requirements list to include open > >> > > > source as the first and most important requirement from the Fedora > >> > > > community. If that's incompatible with CentOS's need for merge > >> > > > request approvals or whatever else, then we need to accept that > >> > > > sharing the same forge is simply not going to work. > >> > > > >> > > Obviously open source is one of our key foundations. And it is part > of who > >> > > we are even before those foundations were drafted. Nonetheless, I > want to > >> > > gently discuss this a little bit. We make an entirely open source > and free > >> > > software operating system. We support and promote and advocate for > open > >> > > source and free content. But we can't do everything, and at some > point, this > >> > > becomes "this is why we can't have nice things". I see that you've > made > >> > > contributions to other open source projects on GitHub and (hosted) > GitLab > >> > > this month. Lots of Fedora contributors have and will continue to > do so. > >> > > Many use that as their main hosting. It's not ideal, but it's not > the end of > >> > > the world. I don't see Fedora making use of non-open hosted > services as the > >> > > end of the world either, if that is what is best for us. > >> > > > >> > > We did communicate as the very top line of our gathered > requirements that > >> > > open source is essential to our community and central to our > feedback. I'm > >> > > not trying to be soft on that. Let's just not do purity-test level > >> > > assessments and instead focus on our goals. > >> > > >> > I'm sorry, but I have to agree with Kevin and Michael here to a > >> > significant extent. Running our own project on open source code has > >> > always been a very big bright line for Fedora. > >> > > >> > I'm not necessarily saying it's a hill we should die on, but at the > >> > very least, choosing a proprietary hosted solution for something as > >> > fundamental as our dist-git needs to be treated as a Very Big Deal and > >> > needs to be a decision that is handled a *lot* better than this one > has > >> > been handled. > >> > > >> > You said in another email that the tooling choice ultimately has to be > >> > largely made by the team that is responsible for the work and it > >> > wouldn't really work for Council to order them to do something they > >> > can't practically do, and I see the truth in that, but at the same > time > >> > I think there has to be a balance there. Does this "the team decides > >> > what works for them" principle extend as far as the team being able to > >> > choose unilaterally to go against principles Fedora has been working > >> > very hard to maintain for about as long as it has existed, and that > are > >> > listed right up there front and centre as our Foundations? That, to > me, > >> > seems like a decision that Council ought at the very least to be > deeply > >> > involved in - much more than seems to have been the case here (which > >> > seems to have been that we wrote up some requirements and sent them > off > >> > to "the team", which smooshed them into some kind of summary and then > >> > made a decision - a decision which seems to have had a rather confused > >> > context, as various people don't seem to be on the same page about > >> > whether a choice was supposed t
Re: CPE Git Forge Decision
On Tue, Mar 31, 2020 at 8:02 PM Chris Murphy wrote: > On Tue, Mar 31, 2020 at 2:37 AM Leigh Griffin wrote: > > > > > > > > On Mon, Mar 30, 2020 at 10:38 PM Chris Murphy > wrote: > >> > >> On Mon, Mar 30, 2020 at 5:56 AM Leigh Griffin > wrote: > >> > > >> > We haven't ironed out the full details but what was incredibly clear > to us was that Gitlab was the decision to make. The next step in getting > there is what we are engaging in now to get thoughts and suggestions and > expect several threads in that capacity from a technical perspective in the > coming weeks and months. > >> > >> > >> It is not incredibly clear to the respondents on devel@. I don't care > >> to imagine what stronger disagreement on this particular point looks > >> like. > > > > > > I respect that there is disagreement but Gitlab is the choice we are > making. > > > Why this choice? To distill it down: - Gitlab has more features that are needed right now for our stakeholder group - Gitlab has an entire company dedicated to roadmap features, we do not. - Gitlab has better resiliency and uptime, we offer an SLE on an app that is not meeting our mission statement but is consuming a lot of our time - Gitlab scales better, Pagure has scale issues - CPE do not own an application that will consume 100% of our available team capacity from here on in to bridge the gap, to keep the system stood up, to move towards an SLA model and to keep apace with new innovations > That's what's not clear. And it's not fair to call > this mere disagreement, because the decision can't even be properly > absorbed. It is prima facie not an open or transparent process, yet is > being claimed to have been. That contradiction is not trust enhancing. > > > > >> > >> On Mon, Mar 30, 2020 at 4:27 AM Iñaki Ucar > wrote: > >> > > >> > I was referring to, and I was expecting, an open conversation about > >> > the User Story list, an open analysis of the requirements list. In > >> > other words: > >> > > >> > 1. Open conversation to gather requirements. Done. > >> > 2. Publication of User Story list. > >> > 3. Open conversation to discuss (2). > >> > 4. Publication of the final decision. > >> > > >> > I was expecting (3), and it's missing. > >> > >> > >> I concur, and don't think the missing piece has been adequately > >> addressed. There's a reason why there's bewilderment at the decision, > >> it's not ignorable. > > > > > > How would you like us to address it more clearly? Fedora has had the > publication of its User Story list, a threads worth of discussion on it > occured and it was submitted. As have other stakeholder groups. I think the > crux here is that we didn't publish the entire stakeholder User Stories for > dissemination to each individual stakeholder group. With each group valuing > something different, as is obvious from the discussion around individual > requirements that has occured in several threads here, we didn't feel the > value would have been there. That's on me for not looping the comms back in > and I apologise for that. > > > >> > >> Were there deliberations by CPE Team in between (2) and (4)? > > > > Yes, several hundred person hours worth of analysis, meetings and > dissecting the requirements. > > It would be addressed more clearly by seeing the summary, > distillation, metric, method, by which those hundreds of hours were > turned into the decision. > I have promised several times that the feature gaps will land as a backlog addition for Pagure and I can happily share out a matrix from a User Story / Feature perspective and additional comments. Stay tuned for that. > > These entire threads are a verbose way of saying "show your work." > > > > >> > >> Is there > >> a record of those deliberations? > > > > > > No, they were mostly video calls / in person meetings and the result is > the User Story list and decision document for sharing. > > I think a summary of the first hour of these several hundred hours, > and the last hour, would be useful. There's no way to reconstruct > this? I mean if you want the summary of the first hour it was a strategy plan for grouping the requirements and interviewing stakeholders / communicating with our team on technical details. The last hour was the summary mail that was sent out to communicate the decision. > Deliberative bodies should be keeping notes, summary of major > decisions, pros, cons, liabilities, prioritization o
Re: CPE Git Forge Decision
I understand there are practical resource considerations and so on > > here, but I still think this merits more high level and serious > > consideration. At the very least, if we have somehow reached a point > > where Red Hat is no longer willing to provide sufficient resources to > > run Fedora on the lines the Fedora community wants it to be run, we > > need to recognize that this is a significant problem that needs to be > > properly aired and discussed and resolved. In this context I'll note > > that the apparent significant headcount reduction of RH people working > > on Fedora infrastructure over the last few years is in itself a > > worrying trend, particularly if you consider it while reading Clement's > > email. > > > > I think Iñaki's take on the "oh, you contribute to Github projects so > > no problem right?" angle is correct. > > I concur with this, in its entirety. > > Lack of resources might supercede an open source requirement. But if > that is really the choice, that itself exposes a far bigger problem: > all other projects being maintained by CPE and Fedora Infrastructure > team are at risk. There is no doubt that they are at risk. We cannot sustain the level of commitment to the volume of projects we have. The lights on work for just the Fedora side is consuming over 50% of our team. That's pure firefighting, responding to tickets and fixing problems with very little time to pay down some of the debt that is causing the problems in the first place. The team is spread too thin on just the Fedora commitments before we consider the fact the team has another distribution in CentOS under our remit as well. The reality is that most applications are constantly under risk, if a person goes on PTO or leaves the team / company, we lose domain knowledge. This has happened in the past year and will happen in the future. Part of how we are structuring our work is to reduce our overhead, cross train the team, get smarter on what we invest our time and effort into in order to provide real value, not fighting fires constantly. That might sound alarmist, but it's the reality that the team are living day to day. > Why can't half or even all of them be rolled up into > proprietary equivalents and handed off for some other company to > manage? What's next? > > This is awkward, but not even 12 days ago the Council approved a new > vision statement: > > The Fedora Project envisions a world where everyone benefits from free > and open source software built by inclusive, welcoming, and > open-minded communities. > > I can't say for sure there is a conflict in the process used to arrive > at the decision, but I'm questioning whether there is incongruity, and > the nature of it. > > -- > Chris Murphy > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CPE Git Forge Decision
On Tue, Mar 31, 2020 at 6:32 PM Adam Williamson wrote: > On Tue, 2020-03-31 at 17:47 +0200, jkone...@redhat.com wrote: > > -- snip -- > > > As for Pagure itself, I think this is where we fundamentally > > > disagree. > > > I think it behooves us to own and provide an experience tailored for > > > our community from beginning to end. That's why we have Koji, Bodhi, > > > Dist-Git, and many other tools in that part of the lifecycle. The > > > packager experience is literally the lifeblood of the project, and > > > our > > > contributors are the core of what makes Fedora successful. Pagure > > > gives us an opportunity to do right by them that I *really* don't > > > think we can do with any alternatives. > > > > > > That does *not* mean that CPE team should be the sole owner of the > > > Pagure *codebase*. On that point, I agree. And that's why I've spent > > > a > > > lot of time and energy since late 2018 working on building up that > > > community. It's finally starting to bear fruit too: there's at least > > > one entity interested in building a product around it and > > > contributing > > > to help support that product, there's the FSF preparing to launch a > > > new forge using Pagure, there's the Trisquel GNU+Linux distribution > > > working on a Pagure deployment to host their code and packaging, and > > > there's a few other things I've got up my sleeve to help broaden the > > > community with not just users, but also contributors. > > > > It's great to hear this. Thanks a lot Neal for trying to find > > consumers. I'm not sure if this information was available to Fedora > > infrastructure during the decision. It means that we may have another > > contributors. > > I specifically mentioned at least the FSF angle on this mailing list, > over a month ago: > > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/EJAKU3MO4T5ZEWEBUWIRSGBWTFQU44QK/ > > so at least that part certainly *should* have been, if we assume it's > reasonable to expect those making this decision to be paying attention > to this list. > We were aware and we do follow this list. > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net > http://www.happyassassin.net > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CPE Git Forge Decision
On Tue, Mar 31, 2020 at 4:49 PM wrote: > -- snip -- > > > > As for Pagure itself, I think this is where we fundamentally > > disagree. > > I think it behooves us to own and provide an experience tailored for > > our community from beginning to end. That's why we have Koji, Bodhi, > > Dist-Git, and many other tools in that part of the lifecycle. The > > packager experience is literally the lifeblood of the project, and > > our > > contributors are the core of what makes Fedora successful. Pagure > > gives us an opportunity to do right by them that I *really* don't > > think we can do with any alternatives. > > > > That does *not* mean that CPE team should be the sole owner of the > > Pagure *codebase*. On that point, I agree. And that's why I've spent > > a > > lot of time and energy since late 2018 working on building up that > > community. It's finally starting to bear fruit too: there's at least > > one entity interested in building a product around it and > > contributing > > to help support that product, there's the FSF preparing to launch a > > new forge using Pagure, there's the Trisquel GNU+Linux distribution > > working on a Pagure deployment to host their code and packaging, and > > there's a few other things I've got up my sleeve to help broaden the > > community with not just users, but also contributors. > > It's great to hear this. Thanks a lot Neal for trying to find > consumers. I'm not sure if this information was available to Fedora > infrastructure during the decision. It means that we may have another > contributors. > > I think Fedora Infra should talk to these potential contributors to > find out how much they are willing to contribute to Pagure and re-think > the decision based on that. We had awareness of other groups looking at Pagure and that was not a factor in our decision as it is not a concrete commitment with respect to a backlog of initiatives that would bridge a feature gap right now and in the future. Nor would it have helped with the SLA requirements and operational cost. It is heartwarming to see it get such attention though and it can only be positive things for the growth of the Pagure Community. > It's big difference if this is just a > Fedora tool or if it is used and developed by others too. > > Jirka > > > > > Are there deficiencies in Pagure? Of course there are. I'm not > > claiming that Pagure is perfect. But I think that keeping on with > > Pagure and giving that community an opportunity to close the gap on > > needed features for Fedora/CentOS/Red Hat is the right way to go. > > Right now, I don't *know* what the important gaps are. I can make > > some > > guesses, but it'd be a lot better if we had a list of missing > > features > > and their relative important and why. That would help focus > > development to meet those needs. > > > > The Fedora community itself has indicated that they want to keep on > > with Pagure, and many Fedorans are Pythonistas, which means that > > everyone can easily contribute to help make it better for everyone. > > > > Anyway, I hope this helps clarify my position on the matter! > > > > [1]: > > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/Y5XXXHJCSDMOHA7FEZ3DNZYPGCTZBVH6/ > > > > > > > > > > -- > > 真実はいつも一つ！/ Always, there's only one truth! > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: > > https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > _______ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The Git forge decision (was CPE Weekly: 2020-03-28)
On Tue, Mar 31, 2020 at 1:23 PM Ian McInerney 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@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CPE Git Forge Decision
On Tue, Mar 31, 2020 at 11:48 AM Felix Schwarz wrote: > > Am 31.03.20 um 12:42 schrieb Kevin Kofler: > > I think that using anything other than Free Software as the hosting > platform > > for Fedora should be an absolute no go. In other words, self-hosted > GitLab > > CE or Pagure, no other options. > > +1 with one minor(?) exception: > I'm ok with using a hosted version provided that the software (and its > dependencies) is part of the Fedora repos and there are provisions to > extract > the data (e.g. database) from the hosted version without any data loss and > load it in a self-hosted version using Fedora RPMs. > We can certainly bring that forward as a requirement, thank you for this. > > Felix > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CPE Git Forge Decision
On Tue, Mar 31, 2020 at 11:43 AM Kevin Kofler wrote: > Leigh Griffin wrote: > > Thank you for your patience while the CPE Team worked through an > > incredible number of requirements from multiple stakeholder sources. On > > Friday evening we announced on the Community Blog > > <https://communityblog.fedoraproject.org/making-a-git-forge-decision/> > our > > decision to adopt Gitlab as our Git Forge and to retain pagure.io to > > ultimately hand over to the Community to maintain. It wasn't an easy > > decision by any stretch of the imagination and we hope that the > compromise > > that we are striking will help to allow Pagure flourish and to give a > > choice of Forges for your usage. I'm happy to field any questions or > > comments about this decision. > > What really worries to me is that: > * using GitLab as SaaS is being considered, and > * for self-hosting, using the proprietary "enterprise" editions is not > excluded. > > I think that using anything other than Free Software as the hosting > platform > for Fedora should be an absolute no go. In other words, self-hosted GitLab > CE or Pagure, no other options. > No option is off the table right now as we haven't sat down with Gitlab to evaluate options yet, that is scheduled for this week. SaaS and all variants of licensing are an option right now until we evaluate the tooling needs and process the valuable feedback in this thread (and others) will be brought to Gitlab and in our public facing ticket we would most welcome engagement to have your voice and say heard by the Gitlab folks directly. > Kevin Kofler > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CPE Git Forge Decision
On Tue, Mar 31, 2020 at 10:41 AM Miro Hrončok wrote: > On 31. 03. 20 10:36, Leigh Griffin wrote: > > I respect that there is disagreement but Gitlab is the choice we are > making. > > I always try to assume good intentions, but this is very hard now. I > understand > this statement as follows: > > "After collecting the requirements, we have not discussed the decision > with the > Fedora community, it was discussed in private. The requirements were analysed in private which we indicated they would be evaluated by the CPE Management. We have decided for Gitlab and > only once we have already decided, we have announced our decision to > Fedora. We have announced our decision to all stakeholders. Now > when the people who will be actually using the thing are trying to > participate > in the discussion, their arguments no longer matter to us, because the > decision > was already made, whatever you say won't change it, this discussion is > pointless." > The thoughts and arguments matter and will influence how the technical implementation will go for us. I already have pulled some good information from the responses for our consideration. It's not altering the decision as the overall balance of requirements is still pointing to Gitlab as the choice. > > Am I wrong? > Yes. > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The Git forge decision (was CPE Weekly: 2020-03-28)
On Tue, Mar 31, 2020 at 11:28 AM Till Maas 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 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@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The Git forge decision (was CPE Weekly: 2020-03-28)
On Mon, Mar 30, 2020 at 10:13 PM Till Maas 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@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The Git forge decision (was CPE Weekly: 2020-03-28)
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@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CPE Git Forge Decision
On Tue, Mar 31, 2020 at 8:10 AM Petr Kubat wrote: > From the community blog this decision seems more like a "what can we use > to make CentOS Stream work" rather than an open community-made choice of > what is best for Fedora. > The needs of Fedora, CentOS, RHEL and the CPE team were weighed equally in our decision. Fedora had very few specific needs in their requirements where as some stakeholder groups had. The balance of the decision was for Gitlab. > On 3/30/20 11:17 AM, Leigh Griffin wrote: > > Hi everyone, > > Thank you for your patience while the CPE Team worked through an > incredible number of requirements from multiple stakeholder sources. On > Friday evening we announced on the Community Blog > <https://communityblog.fedoraproject.org/making-a-git-forge-decision/> our > decision to adopt Gitlab as our Git Forge and to retain pagure.io to > ultimately hand over to the Community to maintain. It wasn't an easy > decision by any stretch of the imagination and we hope that the compromise > that we are striking will help to allow Pagure flourish and to give a > choice of Forges for your usage. I'm happy to field any questions or > comments about this decision. > > Kind regards, > Leigh, on behalf of the CPE Team > > -- > > Leigh Griffin > > Engineering Manager > > Red Hat Waterford <https://www.redhat.com/> > > Communications House > > Cork Road, Waterford City > > lgrif...@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> > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CPE Git Forge Decision
On Mon, Mar 30, 2020 at 10:38 PM Chris Murphy wrote: > On Mon, Mar 30, 2020 at 5:56 AM Leigh Griffin wrote: > > > > We haven't ironed out the full details but what was incredibly clear to > us was that Gitlab was the decision to make. The next step in getting there > is what we are engaging in now to get thoughts and suggestions and expect > several threads in that capacity from a technical perspective in the coming > weeks and months. > > > It is not incredibly clear to the respondents on devel@. I don't care > to imagine what stronger disagreement on this particular point looks > like. > I respect that there is disagreement but Gitlab is the choice we are making. > > > On Mon, Mar 30, 2020 at 4:27 AM Iñaki Ucar > wrote: > > > > I was referring to, and I was expecting, an open conversation about > > the User Story list, an open analysis of the requirements list. In > > other words: > > > > 1. Open conversation to gather requirements. Done. > > 2. Publication of User Story list. > > 3. Open conversation to discuss (2). > > 4. Publication of the final decision. > > > > I was expecting (3), and it's missing. > > > I concur, and don't think the missing piece has been adequately > addressed. There's a reason why there's bewilderment at the decision, > it's not ignorable. > How would you like us to address it more clearly? Fedora has had the publication of its User Story list, a threads worth of discussion on it occured and it was submitted. As have other stakeholder groups. I think the crux here is that we didn't publish the entire stakeholder User Stories for dissemination to each individual stakeholder group. With each group valuing something different, as is obvious from the discussion around individual requirements that has occured in several threads here, we didn't feel the value would have been there. That's on me for not looping the comms back in and I apologise for that. > Were there deliberations by CPE Team in between (2) and (4)? Yes, several hundred person hours worth of analysis, meetings and dissecting the requirements. > Is there > a record of those deliberations? > No, they were mostly video calls / in person meetings and the result is the User Story list and decision document for sharing. > > > > -- > Chris Murphy > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CPE Git Forge Decision
On Mon, Mar 30, 2020 at 9:55 PM Till Maas wrote: > Hi, > > On Mon, Mar 30, 2020 at 02:40:13PM +0000, Leigh Griffin wrote: > > On Mon, Mar 30, 2020 at 3:26 PM Till Maas wrote: > > > > > Hi, > > > > > > On Mon, Mar 30, 2020 at 01:59:07PM +, Leigh Griffin wrote: > > > > On Mon, Mar 30, 2020 at 2:18 PM Till Maas > wrote: > > > > > > > > > Hi, > > > > > > > > > > On Mon, Mar 30, 2020 at 11:04:03AM +0100, Leigh Griffin wrote: > > > > > > > > > > > For transparency, we have published the full User Story list > which is > > > > > > linked within the blog and for ease of searching is here: > > > > > > https://hackmd.io/@My419-DISUGgo4gcmO1D6A/HJB74lcL8 > > > > > > > > > > the user stories list does not seem to include the original user > > > stories > > > > > that I submitted regarding package life-cycle and permission > > > management. > > > > > These are requirements for dist-git but not necessarily for a > > > git-forge. > > > > > In the past they were fulfilled by package db, now pagure is > solving > > > > > this more. > > > > > > > > > > > > We received a summarised User Story list from the Fedora Council, I > would > > > > suggest reaching out with your concerns. > > > > > > What is the list that you got. The list on the council discuss list > > > contained these items, for example for FESCo members, proven packagers > > > and dist-git repo admins: > > > > > > > https://lists.fedoraproject.org/archives/list/council-disc...@lists.fedoraproject.org/thread/OEPDGVKYAJIQ6YYZU5J3XT3LHXFROFI5/ > > > > > > We received a Google Doc with the summation of the 44 requirements from > > Fedora Council. > > Please be more specific. Are these the requirements from the discussion > different ones? The discussion had 47 requirements, 1 and 2 were > challenged and 47 mentioned as nice-to-have. Who submitted them? I guess > it was Ben. > 44 requirements were received from Ben Cotton on behalf of the Fedora Council. It's not for me to comment on whether the thread was copied verbatim or how it was rolled up, I dealt with the formal requirements that landed. > > > > In the hackmd story list, there are is only infosec, RH Legal Rep, RH > > > Infocsec Rep, RH Developer, RHEL engineer and general users, project > > > contributor, CPE team member. Nothing really maps to the user groups I > > > mentioned. > > > > > > As mentioned, we rolled in stories together and General Users / > > contributors map to the majority of the Fedora projects requirements > > (similar for CentOS) and a lot of individual stakeholder requirements > ended > > up in the general bucket. > > > > > > > There is only > > > > > > | 41 > > > | As a General User > > > | I want groups and group membership and management > > > | to allow me create access control on a suite of repositories > > > > > > but this is very vague. > > > > > > > The User Stories are deliberately vague and that represents around 10 > > unique requirements that boil down to having group membership and > > management capabilities. > > IMHO the problem with this vague requirement is that it probably fits > every gitforge. But for Fedora, the package management aspects are more > important than generic gitforge capabilities that any gitforge can > provide. > Bear in mind the user stories we published were the amalgamated User Story list, we considered every single story as it was written and intended. > > > > Also there seems to be nothing about orphaning/adopting/retiring > > > packages, not even in a vague way. > > > > > > > We have stories relating to specific workflow requirements (from multiple > > stakeholders including RHEL, CentOS and Fedora) for dist-git. We have > > represented a requirement (number 18 on the list) about viewing orphaned > > packages. The requirements received around this process were very much > > aligned with permissions and visibility to allow actions. They are > covered > > through other User Stories and what I feel needs to be made clear, we are > > presenting the amalgamated list and as a team we read every single User > > Story that came in and processed them accordingly in making this > decision. > > From the experience with the migration from Packagedb to pagure, the > specific requiremen
Re: The Git forge decision (was CPE Weekly: 2020-03-28)
On Mon, Mar 30, 2020 at 5:06 PM David Kaufmann 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-and-community-handoff/ > > All the best, > David > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The Git forge decision (was CPE Weekly: 2020-03-28)
On Mon, Mar 30, 2020 at 1:13 PM Julen Landa Alustiza < jla...@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 > <mailto:iu...@fedoraproject.org>> wrote: > > > > On Mon, 30 Mar 2020 at 13:10, Leigh Griffin > <mailto:lgrif...@redhat.com>> wrote: > > > > > > On Mon, Mar 30, 2020 at 10:29 AM Iñaki Ucar > > mailto:iu...@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@lists.fedoraproject.org > > <mailto:devel@lists.fedoraproject.org> > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > <mailto:devel-le...@lists.fedoraproject.org> > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > > > > > > > -- > > > > Leigh Griffin > > > > Engineering Manager > > > > Red Hat Waterford <https://www.redhat.com/> > > > > Communications House > > > > Cork R
Re: CPE Git Forge Decision
On Mon, Mar 30, 2020 at 3:36 PM Matthias Runge wrote: > On 30/03/2020 16:23, Till Maas wrote: > > >>>> For transparency, we have published the full User Story list which is > >>>> linked within the blog and for ease of searching is here: > >>>> https://hackmd.io/@My419-DISUGgo4gcmO1D6A/HJB74lcL8 > > > > https://lists.fedoraproject.org/archives/list/council-disc...@lists.fedoraproject.org/thread/OEPDGVKYAJIQ6YYZU5J3XT3LHXFROFI5/ > > > > In the hackmd story list, there are is only infosec, RH Legal Rep, RH > > Infocsec Rep, RH Developer, RHEL engineer and general users, project > > contributor, CPE team member. Nothing really maps to the user groups I > > mentioned. There is only > > > > | 41 > > | As a General User > > | I want groups and group membership and management > > | to allow me create access control on a suite of repositories > > > > but this is very vague. > > > Comparing the two lists Ben posted and the one on hackmd.io differ quite > a bit. Was the list of requirements changed during the process? > As a team we evaluated every single requirement (over 300 of them) and the presentation in the combined User Story list is an amalgamation of like for like User Stories to capture at a high level the spirit of the requests. > > > Matthias > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CPE Git Forge Decision
On Mon, Mar 30, 2020 at 3:26 PM Till Maas wrote: > Hi, > > On Mon, Mar 30, 2020 at 01:59:07PM +0000, Leigh Griffin wrote: > > On Mon, Mar 30, 2020 at 2:18 PM Till Maas wrote: > > > > > Hi, > > > > > > On Mon, Mar 30, 2020 at 11:04:03AM +0100, Leigh Griffin wrote: > > > > > > > For transparency, we have published the full User Story list which is > > > > linked within the blog and for ease of searching is here: > > > > https://hackmd.io/@My419-DISUGgo4gcmO1D6A/HJB74lcL8 > > > > > > the user stories list does not seem to include the original user > stories > > > that I submitted regarding package life-cycle and permission > management. > > > These are requirements for dist-git but not necessarily for a > git-forge. > > > In the past they were fulfilled by package db, now pagure is solving > > > this more. > > > > > > We received a summarised User Story list from the Fedora Council, I would > > suggest reaching out with your concerns. > > What is the list that you got. The list on the council discuss list > contained these items, for example for FESCo members, proven packagers > and dist-git repo admins: > > https://lists.fedoraproject.org/archives/list/council-disc...@lists.fedoraproject.org/thread/OEPDGVKYAJIQ6YYZU5J3XT3LHXFROFI5/ We received a Google Doc with the summation of the 44 requirements from Fedora Council. > > > In the hackmd story list, there are is only infosec, RH Legal Rep, RH > Infocsec Rep, RH Developer, RHEL engineer and general users, project > contributor, CPE team member. Nothing really maps to the user groups I > mentioned. As mentioned, we rolled in stories together and General Users / contributors map to the majority of the Fedora projects requirements (similar for CentOS) and a lot of individual stakeholder requirements ended up in the general bucket. > There is only > > | 41 > | As a General User > | I want groups and group membership and management > | to allow me create access control on a suite of repositories > > but this is very vague. > The User Stories are deliberately vague and that represents around 10 unique requirements that boil down to having group membership and management capabilities. > > Also there seems to be nothing about orphaning/adopting/retiring > packages, not even in a vague way. > We have stories relating to specific workflow requirements (from multiple stakeholders including RHEL, CentOS and Fedora) for dist-git. We have represented a requirement (number 18 on the list) about viewing orphaned packages. The requirements received around this process were very much aligned with permissions and visibility to allow actions. They are covered through other User Stories and what I feel needs to be made clear, we are presenting the amalgamated list and as a team we read every single User Story that came in and processed them accordingly in making this decision. > > Thank you, > Till > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CPE Git Forge Decision
On Mon, Mar 30, 2020 at 3:07 PM Fabio Valentini wrote: > On Mon, Mar 30, 2020 at 4:00 PM Leigh Griffin wrote: > > > > > > > > On Mon, Mar 30, 2020 at 2:01 PM Miro Hrončok > wrote: > >> > >> On 30. 03. 20 14:13, Neal Gompa wrote: > >> > And unlike Alioth, we have*serious* > >> > integration across the board with Pagure, and a good chunk of it is > >> > not possible to implement in GitLab. Features we have in here were > >> > designed to meet the needs of Fedorans that we will be forced to give > >> > up. > >> > >> I want to stress out that recently we even got more of it. Several > years after > >> the PackageDB sunset, we are finally getting to a matching packager > experience. > >> > >> (For example with the Bugzilla default assignee or the > unorphan/unretire buttons.) > >> > >> Is this going to be possible with GitLab? > > > (snip) > > > > > > > I don't have an answer to this as we haven't done that deep level of > tooling analysis and integration analysis yet. > > So you're basically saying that you've decided for GitLab (despite the > fedora community obviously preferring pagure - whether you received > that message or not), It was not a formal requirement. and you have not even looked at what that will > mean? We have looked into the capabilities of it to inform our decision but not at a granular tooling level. > And if it turns out that GitLab can't deliver some features you > want, and not satisfy some "stakeholder user stories"? > Not all requirements can be satisfied in totality, we knew this before we began and Gitlab satisfies the majority of the requirements needed. > > Am I crazy, or shouldn't have those problems have been taken into > account *before* such a big decision is made? > Your responses sound like "we made our decisions, and now we'll stick > to them no matter what happens". > Like any technology decision that we as a team choose, we can revert our decision if the service is not working as intended and not satisfying our needs. Right now, we are proceeding with Gitlab as our choice. And honestly, I shouldn't have expected anything else from this "kill > pagure project". > Pagure was a viable choice and several hundred person hours went into informing us of this decision because of how critical it was to get right. > > The way the fedora community - and the pagure project - are and were > treated here is shameful, and you're going to lose fedora contributors > because of it. > > Fabio > > > > >> > >> Will CPE implement this before we > >> switch, or will GitLab be dumped on us and we will do toothless FESCo > approved > >> statements, such as "Missing Pagure features should be re-implemented in > >> GitLab"? > > > > > > CPE will take on a lot of the tooling work to ease the migration. > > > >> > >> What measures will be taken to prevent yet another "open a releng > >> ticket and a human will do this while we automate stuff" era? > >> > >> -- > >> Miro Hrončok > >> -- > >> Phone: +420777974800 > >> IRC: mhroncok > >> ___ > >> devel mailing list -- devel@lists.fedoraproject.org > >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org > >> Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > >> List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > > > > > > > -- > > > > Leigh Griffin > > > > Engineering Manager > > > > Red Hat Waterford > > > > Communications House > > > > Cork Road, Waterford City > > > > lgrif...@redhat.com > > M: +353877545162 IM: lgriffin > > > > @redhatjobs redhatjobs @redhatjobs > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ > devel mailing list -- d
Re: CPE Git Forge Decision
On Mon, Mar 30, 2020 at 2:18 PM Till Maas wrote: > Hi, > > On Mon, Mar 30, 2020 at 11:04:03AM +0100, Leigh Griffin wrote: > > > For transparency, we have published the full User Story list which is > > linked within the blog and for ease of searching is here: > > https://hackmd.io/@My419-DISUGgo4gcmO1D6A/HJB74lcL8 > > the user stories list does not seem to include the original user stories > that I submitted regarding package life-cycle and permission management. > These are requirements for dist-git but not necessarily for a git-forge. > In the past they were fulfilled by package db, now pagure is solving > this more. We received a summarised User Story list from the Fedora Council, I would suggest reaching out with your concerns. > What is the plan for this in the future? Will there be a > different solution instead of a git forge for this? > Thank you > Till > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CPE Git Forge Decision
On Mon, Mar 30, 2020 at 2:01 PM Miro Hrončok wrote: > On 30. 03. 20 14:13, Neal Gompa wrote: > > And unlike Alioth, we have*serious* > > integration across the board with Pagure, and a good chunk of it is > > not possible to implement in GitLab. Features we have in here were > > designed to meet the needs of Fedorans that we will be forced to give > > up. > > I want to stress out that recently we even got more of it. Several years > after > the PackageDB sunset, we are finally getting to a matching packager > experience. > > (For example with the Bugzilla default assignee or the unorphan/unretire > buttons.) > > Is this going to be possible with GitLab? I don't have an answer to this as we haven't done that deep level of tooling analysis and integration analysis yet. > Will CPE implement this before we > switch, or will GitLab be dumped on us and we will do toothless FESCo > approved > statements, such as "Missing Pagure features should be re-implemented in > GitLab"? CPE will take on a lot of the tooling work to ease the migration. > What measures will be taken to prevent yet another "open a releng > ticket and a human will do this while we automate stuff" era? > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CPE Git Forge Decision
On Mon, Mar 30, 2020 at 1:15 PM Neal Gompa wrote: > On Mon, Mar 30, 2020 at 7:56 AM Leigh Griffin wrote: > > > > On Mon, Mar 30, 2020 at 11:31 AM Julen Landa Alustiza < > jla...@fedoraproject.org> wrote: > >> > >> Sincelery, after reading the initial announcement, I was expecting a > >> more visible and open to the community discussion scenario. > >> > > >> > For transparency, we have published the full User Story list which is > >> > linked within the blog and for ease of searching is > >> > here: https://hackmd.io/@My419-DISUGgo4gcmO1D6A/HJB74lcL8 > >> > > >> > This thread is also part of the open conversation on the decision. > >> > >> No, this is a post decision conversation, not the promised open and live > >> discussions *during* the process. > > > > > > We haven't ironed out the full details but what was incredibly clear to > us was that Gitlab was the decision to make. The next step in getting there > is what we are engaging in now to get thoughts and suggestions and expect > several threads in that capacity from a technical perspective in the coming > weeks and months. > > But that's the problem. It *wasn't* clear to all of us in Fedora and > CentOS communities. This is why I'm upset about this more than > anything else. This is a post-decision conversation that didn't follow > the "open decision-making process" that you had described earlier. > We followed the process as laid out, we had open discussions of the problem and concluded the ideation phase with a set of requirements delivered by Ben Cotton on behalf of the Fedora Community. We are now engaging openly on what the challenges and next steps are. > > You've made the decision that we're going to move to GitLab in a way > that feels like we were only given lip service to. You also gave no > chance for the Pagure community to respond to meet those needs in a > way that we wouldn't be required to move to GitLab. I'm unsure where you got the impression that there was an opportunity for either Forge to respond to meet future needs? The exercise looked at our short term needs and our long term investment. Had Pagure been the right choice on both fronts, we would have engaged with the Pagure community to bridge the feature gap. > I would have been > happier if you had said: "at this current time, GitLab makes sense for > us. We will engage with GitLab to figure out some more details, but > here are the things we considered critical gaps. Since we're not > making this move this year anyway, if these gaps can be closed by the > end of the year, we will consider staying on Pagure instead of going > forward with a plan of a GitLab migration." > That sounds reasonable when taken in a vacuum. We have needs to service as a team and delaying a decision by a year or more to possibly solve some of the technical problem isn't going to change the operational overhead that some of the requirements is mandating. They were requirements we didn't quiet fully grasp until we carried out the exercise. It is our intention to have something stood up on Gitlab in the coming weeks and made available for consumption by our Communities and team ASAP. > It feels like "welp GitLab because GitLab", ignoring that many folks > in Fedora did not want GitLab. The requirements presented to us by the Fedora Community made no reference to Gitlab or Pagure so this was not a case of Gitlab because. If anything, and as I stated in another reply, Github ticked more boxes. > It's like the Debian Alioth replacement > process all over again. And unlike Alioth, we have *serious* > integration across the board with Pagure, and a good chunk of it is > not possible to implement in GitLab. Features we have in here were > designed to meet the needs of Fedorans that we will be forced to give > up. > > We aim to keep feature parity and any gaps in requirements or tooling will be put forward to Gitlab for their roadmap integreations. > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@redhat.com M: +353877545162 IM: lgriffin @redhatjobs <http
Re: CPE Git Forge Decision
On Mon, Mar 30, 2020 at 11:31 AM Julen Landa Alustiza < jla...@fedoraproject.org> wrote: > > > 20/3/30 12:04(e)an, Leigh Griffin igorleak idatzi zuen: > > > > > > On Mon, Mar 30, 2020 at 10:55 AM Iñaki Ucar > <mailto:iu...@fedoraproject.org>> wrote: > > > > Hi Leigh, > > > > On Mon, 30 Mar 2020 at 11:30, Leigh Griffin > <mailto:lgrif...@redhat.com>> wrote: > > > > > > Hi everyone, > > > > > > Thank you for your patience while the CPE Team worked through an > > incredible number of requirements from multiple stakeholder sources. > > On Friday evening we announced on the Community Blog our decision to > > adopt Gitlab as our Git Forge and to retain pagure.io > > <http://pagure.io> to ultimately hand over to the Community to > > maintain. It wasn't an easy decision by any stretch of the > > imagination and we hope that the compromise that we are striking > > will help to allow Pagure flourish and to give a choice of Forges > > for your usage. I'm happy to field any questions or comments about > > this decision. > > > > My question is, where's the open conversation about the requirements > > gathered that you promised in the initial thread? > > > > > > Hey Iñaki, we have had several rounds of open conversation facilitated > > via the Council threads on it to arrive on what the requirements were > > for the Fedora Project. This ultimately concluded with the formal > > requirements received from the Fedora Council which were shaped by the > > Community. > > Do you mean > > https://lists.fedoraproject.org/archives/list/council-disc...@lists.fedoraproject.org/thread/OEPDGVKYAJIQ6YYZU5J3XT3LHXFROFI5/ > ? I can't find anything else. > Yes. > > Sincelery, after reading the initial announcement, I was expecting a > more visible and open to the community discussion scenario. > > > > For transparency, we have published the full User Story list which is > > linked within the blog and for ease of searching is > > here: https://hackmd.io/@My419-DISUGgo4gcmO1D6A/HJB74lcL8 > > > > This thread is also part of the open conversation on the decision. > > No, this is a post decision conversation, not the promised open and live > discussions *during* the process. > We haven't ironed out the full details but what was incredibly clear to us was that Gitlab was the decision to make. The next step in getting there is what we are engaging in now to get thoughts and suggestions and expect several threads in that capacity from a technical perspective in the coming weeks and months. > > > > > > > Thanks, > > Iñaki > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > <mailto:devel@lists.fedoraproject.org> > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > <mailto:devel-le...@lists.fedoraproject.org> > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > > > > > > > -- > > > > Leigh Griffin > > > > Engineering Manager > > > > Red Hat Waterford <https://www.redhat.com/> > > > > Communications House > > > > Cork Road, Waterford City > > > > lgrif...@redhat.com <mailto:lgrif...@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> > > > > > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > > > -- > Julen Landa Alustiza > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Co
Re: CPE Git Forge Decision
On Mon, Mar 30, 2020 at 11:19 AM Daniel P. Berrangé wrote: > On Mon, Mar 30, 2020 at 10:17:21AM +0100, Leigh Griffin wrote: > > Hi everyone, > > > > Thank you for your patience while the CPE Team worked through an > incredible > > number of requirements from multiple stakeholder sources. On Friday > evening > > we announced on the Community Blog > > <https://communityblog.fedoraproject.org/making-a-git-forge-decision/> > our > > decision to adopt Gitlab as our Git Forge and to retain pagure.io to > > ultimately hand over to the Community to maintain. It wasn't an easy > > decision by any stretch of the imagination and we hope that the > compromise > > that we are striking will help to allow Pagure flourish and to give a > > choice of Forges for your usage. I'm happy to field any questions or > > comments about this decision. > > Overall I understand the decision to focus on GitLab & think it makes a lot > of sense given the precedent of other large open source projects adopting > it. I was always sceptical that there were enough resources invested to > turn Pagure into a strong competitor, especially when other large projects > that could have been potential users & contributors of Pagure (GNOME, > FreeDesktop, KDE, etc) all picked GitLab. > > > That said I have some issues with the blog. It doesn't distiguish very well > between Pagure as the dist-git instance, and Pagure as a general "upstream" > project hosting instance, so it is hard to intepret what applies to what. > The language is murky & contradictory > "Keep Pagure running with our oversight while we analyse a sunset > timeline which will give a minimum of 12 months notice once we > have a plan firmed up. We will fix blocker bugs, address critical > vulnerabilities and keep the lights on in the same manner that we > have committed to over the last 14 months where Pagure has not > been a staffed and supported initiative." > The word "sunset" here tells me that pagure.io is going away and we'll need > to move projects off it. Similarly the last sentence reinforces that Pagure > is considered abandonware. > We will continue with Pagure as a dist-git AND as a project hosting service for a minimum of 12 months once we have a timeline established. That could see the status quo remain for several months on top of that 12 month clock. > > At the same time the blog says "we do not want to abandon Pagure" and > >"provide them with guidance and oversight to help the Pagure > Community grow. We recognise that this is a growing and > unique ecosystem and we genuinely want to see it succeed and > will do our best to support it in that capacity" > > which says that pagure.io is intended to carry on living and even grow. > We will continue to host pagure.io for the foreseeable future but like all apps that we currently host or maintain, we will evaluate the difficulty in maintenance and strive for more community involvement in their upkeep as CPE cannot own and maintain every single Fedora application. > > And > > "Offer the maintenance of pagure.io to anyone in the community >interested in leading it." > > which says we want to abandon it, but perhaps some kind person might step > in to rescue it, but we've no idea who that will be aside from some > community > group yet to be clearly identified. > Put simply, CPE will not be driving the long term maintenance and growth of Pagure. We want the community to drive this and lead the way and give it the time and attention that we cannot. We will provide power and ping and try our best to keep it on the air but we would hope to have assistance with the latter as time goes on and if we get to a point where we can even hand the power and ping aspects over, then we will certainly do that to ensure Pagure has a future that is in the community's own hands. > > Overall I'm left with zero confidence about the future of general project > hosting on pagure.io I hope the above gives some clarity and confidence that pagure.io as a project hosting service is not going away any time soon, if ever. > > > Having lived through Fedora Hosted arriving and then being killed, and > now Pagure arriving and then being killed, I don't have any confidence > in the future. Better to accept now that general project hosting is never > going to be a core deliverable of Fedora I need to correct you here, is not a core deliverable of the CPE team. Our mission statement does not extend to Pagure and project hosting and we made that clear several months back. I can't speak for Fedora and would urge you to take that conversation up with the Council. > and projects shoul
Re: The Git forge decision (was CPE Weekly: 2020-03-28)
On Mon, Mar 30, 2020 at 12:31 PM Neal Gompa wrote: > On Mon, Mar 30, 2020 at 7:27 AM Iñaki Ucar > wrote: > > > > On Mon, 30 Mar 2020 at 13:20, Neal Gompa wrote: > > > > > > On Mon, Mar 30, 2020 at 7:02 AM Leigh Griffin > 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@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The Git forge decision (was CPE Weekly: 2020-03-28)
On Mon, Mar 30, 2020 at 12:24 PM Iñaki Ucar wrote: > On Mon, 30 Mar 2020 at 13:10, Leigh Griffin wrote: > > > > On Mon, Mar 30, 2020 at 10:29 AM Iñaki Ucar > 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@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The Git forge decision (was CPE Weekly: 2020-03-28)
On Mon, Mar 30, 2020 at 12:10 PM Neal Gompa wrote: > On Mon, Mar 30, 2020 at 7:02 AM Leigh Griffin 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@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The Git forge decision (was CPE Weekly: 2020-03-28)
On Mon, Mar 30, 2020 at 10:29 AM Iñaki Ucar wrote: > On Mon, 30 Mar 2020 at 09:15, Julen Landa Alustiza > 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 > 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 o
Re: The Git forge decision (was CPE Weekly: 2020-03-28)
ly 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.org/thread/ZBU4MYRMMAE2Z7DL4NPPECTMX2FBQAVL/ > >> [2]: https://news.ycombinator.com/item?id=19356307 > >> [3]: https://docs.fedoraproject.org/en-US/project/ > >> > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > > > -- > Julen Landa Alustiza > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The Git forge decision (was CPE Weekly: 2020-03-28)
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.org/thread/ZBU4MYRMMAE2Z7DL4NPPECTMX2FBQAVL/ > [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 lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CPE Git Forge Decision
On Mon, Mar 30, 2020 at 10:55 AM Iñaki Ucar wrote: > Hi Leigh, > > On Mon, 30 Mar 2020 at 11:30, Leigh Griffin wrote: > > > > Hi everyone, > > > > Thank you for your patience while the CPE Team worked through an > incredible number of requirements from multiple stakeholder sources. On > Friday evening we announced on the Community Blog our decision to adopt > Gitlab as our Git Forge and to retain pagure.io to ultimately hand over > to the Community to maintain. It wasn't an easy decision by any stretch of > the imagination and we hope that the compromise that we are striking will > help to allow Pagure flourish and to give a choice of Forges for your > usage. I'm happy to field any questions or comments about this decision. > > My question is, where's the open conversation about the requirements > gathered that you promised in the initial thread? > Hey Iñaki, we have had several rounds of open conversation facilitated via the Council threads on it to arrive on what the requirements were for the Fedora Project. This ultimately concluded with the formal requirements received from the Fedora Council which were shaped by the Community. For transparency, we have published the full User Story list which is linked within the blog and for ease of searching is here: https://hackmd.io/@My419-DISUGgo4gcmO1D6A/HJB74lcL8 This thread is also part of the open conversation on the decision. > > Thanks, > Iñaki > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
CPE Git Forge Decision
Hi everyone, Thank you for your patience while the CPE Team worked through an incredible number of requirements from multiple stakeholder sources. On Friday evening we announced on the Community Blog <https://communityblog.fedoraproject.org/making-a-git-forge-decision/> our decision to adopt Gitlab as our Git Forge and to retain pagure.io to ultimately hand over to the Community to maintain. It wasn't an easy decision by any stretch of the imagination and we hope that the compromise that we are striking will help to allow Pagure flourish and to give a choice of Forges for your usage. I'm happy to field any questions or comments about this decision. Kind regards, Leigh, on behalf of the CPE Team -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Announcement: EPEL Steering Committee Changes
On Tue, Feb 18, 2020 at 5:36 PM Stephen John Smoogen wrote: > Hi, > > It has been a pleasure for me to be a part of and help lead the > EPEL steering committee for the last couple of years. It has not > always been smooth sailing but I have found it an enjoyable experience. > Thank you for your passion, drive and commitment to making this such a success for our Communities. > > However, as you may know the Fedora project will be moving to a > different data-center later this spring (from Phoenix to northern > Virginia). Being involved in the planning and implementation of this > project, I do not think that I will be able to give EPEL the time > investment it deserve for the next 6 to 9 months. With EPEL-8 still > ramping up and the various opportunities with modularity, I do > not think it is a fair that EPEL suffers from this lack of time. > > As such, I would like to step down as chair/member of the steering > committee and nominate Troy Dawson as my replacement. Troy formerly > worked on Scientific Linux and has worked on OpenShift and other > projects at Red Hat for the last several years. It is clear he has a > good eye on the concerns and problems enterprise users have. Recently, > Troy helped get the initial RHEL-8 and EPEL-8 out the door with > multiple builds and updates to various macro files. > Troy has great experience in this area and more importantly shares the passion and drive that Smooge has always shown for this. I think he is a great choice. > > Once the move is completed and the close down of the old site is done, > I look forward to getting involved again in EPEL. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Who maintains the service at mbs.fedoraproject.org:443?
On Mon, Feb 17, 2020 at 2:55 PM Pierre-Yves Chibon wrote: > On Mon, Feb 17, 2020 at 09:44:21AM -0500, Michael McLean wrote: > >That's the fm-orchestrator rest api. The code maintenance has > transferred > >from the Factory 2.0 team to the RHEL Build team (i.e. the "Koji > team"). > >Historically, the Factory team has handled the Fedora infra > deployments. > >However, I think we should move towards having that work more like > Koji > >itself, where infra handles the infra parts. > > This is a discussion we may want to start sooner rather than later as it > involves resources which are already thin. > Happy to have that conversation but in the short term, this is not something we can call on and our relationship will be to run it, restart it and ping the right people when it hits a problem. > > > Pierre > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: infrastructure problem: koji and bodhi responding very slow / dl with 80kb/s
On Fri, Feb 14, 2020 at 12:59 AM Artem Tim wrote: > Same here. I am waiting several minutes for every my action. This is very > unproductive. > Log it as a ticket and I can get the CPE folks to investigate it and see if there is an obvious problem that we can help with. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Turning off keys.fedoraproject.org
On Sat, Feb 8, 2020 at 10:25 PM Kevin Fenzi wrote: > On Sat, Feb 08, 2020 at 08:59:40PM +0100, Björn Persson wrote: > > Josh Boyer wrote: > > > > We may want to replace it with a simple Web Key Directory server: > > > > https://wiki.gnupg.org/WKD > > > > > > > > That would make it easy to lookup keys based on @fedoraproject.org > > > > email addresses, and since keys can be replaced in the directory, it > > > > avoids the problems with SKS attacks. > > > > > > I don't see that being valuable enough to actually invest the effort > > > into doing it and maintaining it long term. If others are interested > > > in hosting such a service, that would likely be welcome. > > > > If such others were to step up to do the work, would they be able to > > get the access needed to run it on Fedora infrastructure and integrate > > with FAS? > > Fas is on life support mode, but something could be added to the new > coming account system interface. > Feel free to add anything as an issue and tag myself (lgriffin) within the issue and we can consider it for sure. > > > > Note that a Web Key Directory can't be run as a third-party service. > > It's a fundamental feature of the protocol that the directory server > > exists in the same domain as the email address. Technically a subdomain > > could be delegated, but this isn't a thing that should be tossed up on > > the first cloud service handy, because an intruder in the server would > > be able to replace people's keys and impersonate them. > > keys.openpgp.org offers a WKD as a service thing: > > https://keys.openpgp.org/about/usage > > > > I think a Web Key Directory server would be good for the Fedora > > Project's security, but it should run on hardware under the Fedora > > Project's control. > > Possibly. I'm really not sure how much it would be used. > > kevin > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Git Forge Requirements: Please see the Community Blog
On Thu, Feb 6, 2020, 21:14 Till Maas wrote: > On Tue, Jan 21, 2020 at 04:34:37PM +0000, Leigh Griffin wrote: > > > On behalf of the CPE team I want to draw the communities attention to a > > recent blog post which you may be impacted by: > > https://communityblog.fedoraproject.org/git-forge-requirements/ > > > > We will be seeking input and requirements in an open and transparent > manner > > on the future of a git forge solution which will be run by the CPE team > on > > Aleksandra's comment made me aware that for dist-git, we do not really > need a git forge, it is just that the pagure git forge was used to > implement a lot of workflows that pkgdb provided in the past. > > I tried to write the requirements as user stories to make them easier to > understand. What do you think? > This is a really welcome contribution thank you! > > - As a package maintainer, I can only commit to a dist-git repo, if I am > in the Fedora packager group. > - As a package maintainer, I can only commit to a dist-git repo, if I am > a maintainer of the branch. > - As a proven packager, I can commit to all dist-git repos that do not > have special restrictions set by FESCo or are retired. > - As a FESCO member, I can configure exceptions to disallow proven > packager access to a dist-git repo. > - As dist-git repo admin, I can easily add other maintainers to allow > commit or admin access for dist-git repo by using their FAS username > - As a dist-git repo admin, I cannot remove access to the repo from > Fedora infra, Releng or proven packagers without FESCo approval. > - As a package maintainer, I can easily orphan a dist-git repo or branch > to show that it is not maintained anymore. > - As a package maintainer, I can adopt any orphaned dist-git repo or > branch. > - As a package maintainer, I can easily unretire a retired dist-git repo > or branch. > - As a release engineer, I can easily approve unretire requests for a > dist-git repo or branch. > - As anybody, I can easily see the FAS usernames of maintainers for all > branches of a dist-git repo. > - As a non-releng member, I cannot remove any commits from any dist-git > repo that were used to build a Fedora package. > - As an external user, I can easily get a list of all orphaned or > retired dist-git repos and branches. > - As anybody, I can watch for issues (bugzillas) or PRs that are created > for a dist-git repository. > - As anybody, I can easily get a list of all dist-git repos that I am > watching. > - As anybody, I can easily get a list of all dist-git repos that a > specific Fedora account has admin/commit access to. > - As anybody, when looking at the dist-git repo it is clearly visible > which branches are still maintained. > - As anybody, when I look for a specific branch, EOL branches do not > clutter my view. > - As a package maintainer, I can easily request commit/admin access for > a specific branch or dist-git repo. > > Also since dist-git is a critical part of our infrastructure, there > should probably also be some security-related requirements such as: > > - As Fedora infra, I can easily audit that no git repo was accessed > without authorization. > - As Fedora infra/security response team, I have access to secure logs > to analyse the impact of unauthorized access to all dist-git repos. > - As anybody, the dist-git web page of a repo points me to Bugzilla to > report issues for a repository. > > I did not manage to read all other replies, so there might be some > duplicates but it also seems to me that many of these items were not > mentioned. > > Kind regards > Till > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Git Forge Requirements: Please see the Community Blog
On Sat, Feb 1, 2020 at 10:16 AM Dan Čermák wrote: > Dan Čermák writes: > > > Rahul Sundaram writes: > > > >> Hi > >> > >> On Fri, Jan 31, 2020 at 10:46 AM Pierre-Yves Chibon wrote: > >> > >>> > >>> Welcome to our lives! > >>> If it was mathematically possible to go above 100% that's how much > >>> agreement you > >>> would have from us. > >>> > >> > >> If Red Hat is using Pagure internally, it is really odd to discuss > >> replacing Pagure with something else. The usage is not uniform and not being 100% supported / hosted by the CPE team. The rationale behind a requirements gathering process is clearly outlined in the blog post and we have never said we are replacing Pagure, we may opt to drive resourcing and time into it as one of the viable paths forward. > The only viable replacement is > >> Gitlab which is a open code project written in a language that isn't a > >> strong fit for Fedora. There are 3 viable forges under consideration. > Red Hat should be assigning more resources > >> (development & infrastructure) to add the features needed to extend > Pagure > >> going forward and reduce the burden on the CPE team. Has CPE > leadership >> considered talking internally about that? > This is a key factor in the requirements exercise to know if Pagure is the optimal choice and to know how much to build and at what cost Vs other initiatives we could be focusing on. > > > I have to second this: why are we even *having* this discussion, when > > Pagure is used internally at RedHat and thus RedHat will require some > > form of maintenance anyway? Why is then the RedHat CPE team pushing to > > move away from Pagure, especially to Gitlab? We never stated we are moving to Gitlab. We stated why the CPE team are considering this exercise, if you have questions I'm happy to try clarify them but I urge you to re-read the problem statement and approach in the blog post. > Which albeit being a great > > platform, is written in Ruby and there's a lot less Ruby devs in the > > Fedora community than Python devs. > > I have to apologize, this was far too harsh. It seems to be an emotive topic but thank you for apologising! I still wanted to address the above though in case there was a concern. > What I wanted to say is the > following: wouldn't it be mutually beneficial for RedHat, Fedora and > specifically the CPE Team too, that someone¹ takes over maintenance of > Pagure since it's used by us all and there appear to be enough people > that want to continue using it? > It possibly might be, when the analysis is complete we can check that out. It would be premature and based on no real data to form that decision right now, hence the requirements exercise. Whatever solution is chosen will hopefully satisfy the requirements put forward by Fedora, CentOS, Red Hat and the CPE team. We might not hit all of them perfectly, there might be some trade offs in functionality but we hope to transparently show what those trade offs would be and why we take a certain path. > > > Cheers, > > Dan > > ¹: Yeah, I know that this is actually the tricky part to find this > someone… > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Git Forge Requirements: Please see the Community Blog
On Fri, Jan 31, 2020 at 3:53 PM Rahul Sundaram wrote: > Hi > > On Fri, Jan 31, 2020 at 10:46 AM Pierre-Yves Chibon wrote: > >> >> Welcome to our lives! >> If it was mathematically possible to go above 100% that's how much >> agreement you >> would have from us. >> > > If Red Hat is using Pagure internally, it is really odd to discuss > replacing Pagure with something else. The only viable replacement is > Gitlab which is a open code project written in a language that isn't a > strong fit for Fedora. Red Hat should be assigning more resources > (development & infrastructure) to add the features needed to extend Pagure > going forward and reduce the burden on the CPE team. Has CPE leadership > considered talking internally about that? > This ODF is being shared internally to get requirements as well. > > Rahul > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Git Forge Requirements: Please see the Community Blog
On Wed, Jan 29, 2020, 17:19 Iñaki Ucar wrote: > On Wed, 29 Jan 2020 at 16:23, Leigh Griffin wrote: > > > > On Wed, Jan 29, 2020 at 10:35 AM Iñaki Ucar > wrote: > >> > >> On Wed, 29 Jan 2020 at 00:08, Leigh Griffin > wrote: > >> > > >> > On Tue, Jan 28, 2020, 22:06 Iñaki Ucar > wrote: > >> >> > >> >> On Tue, 28 Jan 2020 at 20:58, Leigh Griffin > wrote: > >> >> > > >> >> > This thread is serving as a source of requirements (although it > has meandered dramatically away from that) > >> >> > >> >> When I first read the post, my thought was: wow, what a convoluted > and > >> >> abstruse way of saying "we want to abandon Pagure". Probably this > >> >> wasn't your intent, but that's what I got. And given the reactions, > >> >> other people too. > >> > > >> > The linked blog to the ODF is very explicit that Pagure is one of the > 3 forge options we are considering. I can't stress enough that it's a > viable choice and ultimately what we opt for will come down to an analysis > driven by the requirements gathered. I'm unsure how the blog has been > interpreted any other way but hopefully this clears it up. > >> > >> The ODF is very explicit in the problem statement, and it specifically > >> and clearly says that: > >> > >> 1. Pagure does not align with CPE. > > > > Correct and it's why we said this line, which you might have missed: > > "While we can make exceptions to the mission statement, we first need to > know why we should consider a specific exception." > > I didn't miss it, I was obviously cherry-picking It gives a very different view when considered in balance Vs a selective quote. That's why I replied on the off chance someone is driving by the thread and skips the key points in the post. , but the point was to > argue why this thread "meandered dramatically away from" the initial > purpose: if that was my initial feeling at first reading, probably > that was the case for others. > > CPE has not committed a team to it in over a year, we do state that as a > driving factor to why we want to engage in this conversation but your > assumption here is based on a particular outcome that sees Pagure not > chosen. If Pagure is chosen, we will commit a team. We are very clear on > that. > > It wasn't so clear to me, but good to know. > Glad I could clarify it, I'm happy to update the original ODF document if it makes it clearer for others. > > > Tell me what you do and how you interact with a forge? That's the point > of this exercise. > > Those with the most complex workflows would provide most value here. I > only maintain a few simple packages at src.fp, and most of my work is > in Copr. > I suspect that a bulk of our users are similar to you. Given that you are engaged on the thread (thank you!) what is your day to day needs? What features are part of your usage and interaction? What's missing or what would you like to see added? Your voice here can help represent that group and is most welcome. > However, I would say that integration with FAS should be a > requirement. Owning the development of the specific tool (whether a > forge or not) is not a must, in principle, but it's a good thing IMO. > Please correct me if I'm wrong, but that was one of the drivers e.g. > to develop Copr instead of going for OBS. > > Iñaki > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Git Forge Requirements: Please see the Community Blog
On Wed, Jan 29, 2020 at 3:30 PM Pierre-Yves Chibon wrote: > On Wed, Jan 29, 2020 at 04:06:22PM +0100, Julen Landa Alustiza wrote: > >Per git ref acls is not a common thing on git forges. If this is a > final > >requirement, we should start analyzing the viability of implementing > and > >maintain it on the different forges (and it should be feasible with > all of > >the rest of our strange ACLs on dist-git) > > > >On pagure side, now that our downstream instances are not using > gitolite, > >implementing them needs much less work that migrating all our > toolings to > >other solutions. > > I believe, and Leigh correct me if I'm wrong, that this will be the next > step in > the analysis. > > 1/ gather all the requirement > 2/ figure out which option have which requirement > 3/ figure out if it is "cheaper" to fix feature A in option 2, or add > feature B > in option 3 or leave without feature C in option 1 > Correct we will perform an analysis on the requirements Vs the offerings. It then becomes a cost benefit analysis to build out (or acquire) feature A at the cost of refactoring process B and so on. We will publish the wider requirements and the analysis to help support a transparent decision. > > Pierre > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Git Forge Requirements: Please see the Community Blog
On Wed, Jan 29, 2020 at 10:35 AM Iñaki Ucar wrote: > On Wed, 29 Jan 2020 at 00:08, Leigh Griffin wrote: > > > > On Tue, Jan 28, 2020, 22:06 Iñaki Ucar wrote: > >> > >> On Tue, 28 Jan 2020 at 20:58, Leigh Griffin > wrote: > >> > > >> > This thread is serving as a source of requirements (although it has > meandered dramatically away from that) > >> > >> When I first read the post, my thought was: wow, what a convoluted and > >> abstruse way of saying "we want to abandon Pagure". Probably this > >> wasn't your intent, but that's what I got. And given the reactions, > >> other people too. > > > > The linked blog to the ODF is very explicit that Pagure is one of the 3 > forge options we are considering. I can't stress enough that it's a viable > choice and ultimately what we opt for will come down to an analysis driven > by the requirements gathered. I'm unsure how the blog has been interpreted > any other way but hopefully this clears it up. > > The ODF is very explicit in the problem statement, and it specifically > and clearly says that: > > 1. Pagure does not align with CPE. > Correct and it's why we said this line, which you might have missed: "While we can make exceptions to the mission statement, we first need to know why we should consider a specific exception." > 2. CPE is not gonna commit a development team to Pagure. > CPE has not committed a team to it in over a year, we do state that as a driving factor to why we want to engage in this conversation but your assumption here is based on a particular outcome that sees Pagure not chosen. If Pagure is chosen, we will commit a team. We are very clear on that. > 3. The feature gap is big and growing, and basically Pagure is gonna > die because of this (and the document goes on saying that you're not > trying to solve the feature gap). > Pagure is a standalone community project. Our choice is not killing Pagure and irrespective of the decision we make I personally hope it stays strong and grows. Stating the feature gap is big and growing is factual, with no committed team we are behind on it. > > Then the ODF lists Pagure as a solution. How am I supposed to > interpret the above? > This is why we are opening it to be very explicit that for the past year we have not focused on Pagure but we now need to make a decision going forward. If Pagure is the choice we staff it accordingly and de-priortise other initiatives and include it within our scope going forward. That is why Pagure is listed as a choice and it is why the ODF is laid out like that. > > > If you (and others) elaborate on how you use Pagure (and other forges) > and what you value from your day to day usage, we will take that on board > and use it to drive our decision making. > > Asking for requirements for a *forge* is pointless. A forge doesn't > have requirements. What you do with a forge has requirements. Tell me what you do and how you interact with a forge? That's the point of this exercise. > As > others have already pointed out, Pagure is being used at the very > least for 3 distinct use cases: to maintain rpm packages, to maintain > upstream projects, and as an issue tracker. And they all have distinct > requirements. And we wish to hear all 3 as ultimately CPE become the owner of the solution that satisfies those requirements. > Only that, as it happens, Pagure has grown to cover > their necessities with more or less success, which doesn't necessarily > mean that a forge is the best solution for all of them (as, again, > others have pointed out already). But the ODF only lists forges as > solutions. > And if the requirements are stated we can have an open conversation about what does suit it. I get that things have organically grown around a forge that may / may not be the best fit for it now, lets examine that as a conversation when we know how people are using it. This topic is focused on what git forge the CPE team will choose based on requirements gathered but if there is a means to address a requirement gap by another tool that is not a forge, then that's a really good outcome of the conversation. > > So solutions for what? What are we talking about here? Requirements > for src.fp.org? Requirements for things that are in pagure.io? All? > Other? > > Iñaki > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@l
Re: Git Forge Requirements: Please see the Community Blog
On Tue, Jan 28, 2020, 22:06 Iñaki Ucar wrote: > On Tue, 28 Jan 2020 at 20:58, Leigh Griffin wrote: > > > > This thread is serving as a source of requirements (although it has > meandered dramatically away from that) > > When I first read the post, my thought was: wow, what a convoluted and > abstruse way of saying "we want to abandon Pagure". Probably this > wasn't your intent, but that's what I got. And given the reactions, > other people too. > The linked blog to the ODF is very explicit that Pagure is one of the 3 forge options we are considering. I can't stress enough that it's a viable choice and ultimately what we opt for will come down to an analysis driven by the requirements gathered. I'm unsure how the blog has been interpreted any other way but hopefully this clears it up. If you (and others) elaborate on how you use Pagure (and other forges) and what you value from your day to day usage, we will take that on board and use it to drive our decision making. > > Iñaki > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Git Forge Requirements: Please see the Community Blog
On Tue, Jan 28, 2020, 15:58 Adam Saleh wrote: > Way we were discussing this, I think there were several points I didn't > really see here. > > a) we are gathering requirements for Git Forge, but we need a good Dist > Git as well. > > There might be difference in requirements and tooling for Dist Git > compared to generic fully featured Git Forge. > It might still be useful to abandon Pagure as a full-featured git-forge > and instead focus on making it really useful as a dist-git solution. > > b) Whatever we decide, there will be significant investment required. > Either by re-investing in our existing solution, or in the migration > effort. > > I think we really want to avoid the `Polarion` situation, where we wouldn't > be clear about all of the costs involved in migration, and end up with a > solution that only saved effort/money on paper, > and in reality it could cost many a man-day of > migration/maintenance/workaround efforts. > > I am not yet sure how to make this less vague, and more "Gathering > requirements", > @Leigh Griffin will there be some sort of a poll in > the end, or how do we actually get a list of requirements? > This thread is serving as a source of requirements (although it has meandered dramatically away from that) but I will default to the Fedora Council for how a combined set from the input in this thread and others is collated and presented. When all requirements are gathered from all stakeholders I will share the distilled version out. > > I assume we are in the "Research" phase of ODF [1], but this is first time > I am interacting with the framework :-) > We are in that phase of getting requirements and analyzing them. Sorry on my phone here so I can't be 100% sure of the formal phases off hand. > > Adam > > [1] > https://github.com/red-hat-people-team/open-decision-framework/blob/master/ODF-community.md > > > > On Fri, Jan 24, 2020 at 4:56 PM Michael Catanzaro > wrote: > >> On Wed, Jan 22, 2020 at 11:37 am, Michael Catanzaro >> wrote: >> > It doesn't have as many features as github.com, >> >> Sorry, this was a typo. I meant: it doesn't have as many features as >> gitlab.com. >> >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org >> > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Git Forge Requirements: Please see the Community Blog
On Tue, Jan 21, 2020, 20:02 Fabio Valentini wrote: > On Tue, Jan 21, 2020 at 8:30 PM Leigh Griffin wrote: > > > > > > > > On Tue, Jan 21, 2020, 17:17 Fabio Valentini > wrote: > >> > >> On Tue, Jan 21, 2020 at 5:40 PM Leigh Griffin > wrote: > >> > > >> > Hey Everyone, > >> > > >> > On behalf of the CPE team I want to draw the communities attention to > a recent blog post which you may be impacted by: > >> > https://communityblog.fedoraproject.org/git-forge-requirements/ > >> > > >> > We will be seeking input and requirements in an open and transparent > manner on the future of a git forge solution which will be run by the CPE > team on behalf of the Fedora Community. This mail is being sent to the > devel, mindshare and council-discuss lists for maximum visibility on a BCC > to allow each list have their own views. Please forward it to any other > list you may feel is relevant to maximise the exposure. > >> > > >> > Thanks in advance, > >> > Leigh > >> > >> Alright, I have some questions that are not answered by the blog post. > >> > >> - What is going to happen to the two pagure instances at pagure.io, > >> and src.fedoraproject.org? > >> > >> I think pagure.io is a good home for fedora-related projects (it was > >> the successor to fedorahosted.org, after all, IIRC). I know that many > >> group efforts are hosting their source code, ticketing system, etc. > >> there (Go SIG, Stewardship SIG, FPC, FESCo, etc.). If it is decided to > >> shut down pagure.io, I assume those projects will have to be moved > >> somewhere? > > (snip) > > > That scenario assumes a certain result and decision from the > requirements analysis so I genuinely have no answer here. Whatever choice > we make, an impact analysis would be needed in some shape or form. That > (and our next steps) will be done collaboratively in the open. > > I'm sorry, but I'm genuinely confused now. Maybe I'm tired, or maybe > this is a language barrier issue ... but I'd hope that an impact > analysis of the different possibilities would be done *before* making > a decision, not after? > > I mean, whatever the "Git Forge Requirements" will be, we'd need to > know how any change will affect the projects and groups that are > currently using pagure ... > Sorry I should have been more detailed on the steps, that's on me. So we have a few steps in this process, first and foremost is this ODF document to figure out what are the real requirements/ use cases / features of a git forge. We gather and analyze that, combining the multiple stakeholder views and have our requirements to base an analysis on. We then evaluate what solution(s) meets the requirements and bring those solutions forward. We then perform impact analysis on what each path might look like from multiple perspectives which will include obvious costs from a time, money, resources perspective of using a git forge. A decision can be made then in an informed way as we know what we want to have, why we want it and what the cost may be. We haven't fully defined the criteria for that analysis yet as the requirements will no doubt throw up use cases and scenarios that we have to factor in. So this is very much a call to arms to help inform us of how you use a git forge and what your requirements are for one. Hope that clears it up and sorry for the lack of clarity. > > Fabio > > >> > >> Also, it's very nice to have a PR-based workflow for some > >> shared-maintenance packages on src.fedoraproject.org, and I don't > >> think losing that feature would be a good thing for fedora. > >> > >> - How is GitHub considered to be an alternative here? > >> > >> I don't think (public or hosted) GitHub can do what is currently done > >> on src.fedoraproject.org, can it? > >> I'd also not want to see fedora use a closed-source product for such a > >> core service ... > >> > >> - Which features are missing from pagure, compared to the other forges? > >> > >> For my purposes, I don't miss any feature on pagure.io compared to my > >> repositories on github.com, and OTTOMH, I can't come up with any > >> missing features, at all ... > >> > >> > >> TL;DR: > >> Can we please keep pagure? It already has the fedora-specific features > >> we need, and I don't mind a "slow" pace of development. > >> In my experience, it works really well, and I actually *like* to use > >> it (which is not true for GitLab ... which is slow and horrib
Re: Git Forge Requirements: Please see the Community Blog
On Tue, Jan 21, 2020, 17:17 Fabio Valentini wrote: > On Tue, Jan 21, 2020 at 5:40 PM Leigh Griffin wrote: > > > > Hey Everyone, > > > > On behalf of the CPE team I want to draw the communities attention to a > recent blog post which you may be impacted by: > > https://communityblog.fedoraproject.org/git-forge-requirements/ > > > > We will be seeking input and requirements in an open and transparent > manner on the future of a git forge solution which will be run by the CPE > team on behalf of the Fedora Community. This mail is being sent to the > devel, mindshare and council-discuss lists for maximum visibility on a BCC > to allow each list have their own views. Please forward it to any other > list you may feel is relevant to maximise the exposure. > > > > Thanks in advance, > > Leigh > > Alright, I have some questions that are not answered by the blog post. > > - What is going to happen to the two pagure instances at pagure.io, > and src.fedoraproject.org? > > I think pagure.io is a good home for fedora-related projects (it was > the successor to fedorahosted.org, after all, IIRC). I know that many > group efforts are hosting their source code, ticketing system, etc. > there (Go SIG, Stewardship SIG, FPC, FESCo, etc.). If it is decided to > shut down pagure.io, I assume those projects will have to be moved > somewhere? > That scenario assumes a certain result and decision from the requirements analysis so I genuinely have no answer here. Whatever choice we make, an impact analysis would be needed in some shape or form. That (and our next steps) will be done collaboratively in the open. > > Also, it's very nice to have a PR-based workflow for some > shared-maintenance packages on src.fedoraproject.org, and I don't > think losing that feature would be a good thing for fedora. > > - How is GitHub considered to be an alternative here? > > I don't think (public or hosted) GitHub can do what is currently done > on src.fedoraproject.org, can it? > I'd also not want to see fedora use a closed-source product for such a > core service ... > > - Which features are missing from pagure, compared to the other forges? > > For my purposes, I don't miss any feature on pagure.io compared to my > repositories on github.com, and OTTOMH, I can't come up with any > missing features, at all ... > > > TL;DR: > Can we please keep pagure? It already has the fedora-specific features > we need, and I don't mind a "slow" pace of development. > In my experience, it works really well, and I actually *like* to use > it (which is not true for GitLab ... which is slow and horrible) > > Fabio > > > -- > > > > Leigh Griffin > > > > Engineering Manager > > > > Red Hat Waterford > > > > Communications House > > > > Cork Road, Waterford City > > > > lgrif...@redhat.com > > M: +353877545162 IM: lgriffin > > > > @redhatjobs redhatjobs @redhatjobs > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Git Forge Requirements: Please see the Community Blog
Hey Everyone, On behalf of the CPE team I want to draw the communities attention to a recent blog post which you may be impacted by: https://communityblog.fedoraproject.org/git-forge-requirements/ We will be seeking input and requirements in an open and transparent manner on the future of a git forge solution which will be run by the CPE team on behalf of the Fedora Community. This mail is being sent to the devel, mindshare and council-discuss lists for maximum visibility on a BCC to allow each list have their own views. Please forward it to any other list you may feel is relevant to maximise the exposure. Thanks in advance, Leigh -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgrif...@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> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Discussion around app retirements and categorizations by the CPE team
On Sun, Jul 21, 2019, 22:38 Neal Gompa wrote: > On Wed, Jul 17, 2019 at 4:31 PM Jeremy Cline wrote: > > > > On Wed, Jul 17, 2019 at 08:33:02AM -0400, Neal Gompa wrote: > > > On Wed, Jul 17, 2019 at 6:46 AM Pierre-Yves Chibon < > pin...@pingoured.fr> wrote: > > > > > > > > Good Morning, > > > > > > > > We posted this [1] blog today and want to open a mailing thread to > garner > > > > feedback, field questions and get some thoughts from the Community on > > > > the approach that we in Community Platform Engineering (CPE) are > taking. > > > > > > > > [1] > https://communityblog.fedoraproject.org/application-service-categories-and-community-handoff/ > > > > > > > > > > Two things that concern me at this time: > > > > > > > > > > > > > Ipsilon — Ipsilon is our identity provider. It supports multiple > > > > authentication protocol (OpenID 2.0, OpenID Connect, SAML 2.0, …) > > > > and multiple backends (FAS, LDAP/FreeIPA, htpasswd, system > accounts…). > > > > While it was originally shipped as a tech preview in RHEL it no > longer is and > > > > the team working on this application has also been refocused on > other projects. > > > > We would like to move all our applications to use OpenID Connect or > SAML 2.0 > > > > (instead of OpenID 2.0 with (custom) extensions) and replace FAS > with an > > > > IPA-based solution, which in turn allows us to replace ipsilon by a > more > > > > maintained solution, likely Red Hat Single Sign On. The dependencies > > > > are making this a long term effort. We will need to announce to the > community > > > > that this means we will shut down the public OpenID 2.0 endpoints, > > > > which means that any community services that use this protocol need > > > > to be moved to OpenID Connect as well. > > > > > > There are two issues to unpack here: > > > > > > 1. We use a weird custom backend and custom protocol extensions. > > > > > > This should definitely be replaced if it makes sense. It’s more urgent > > > now that RHEL 6 is going EOL next year, and FAS 2 is still a Python > > > 2.6 application. FAS 3 *would* have fixed it, but interest by the FAS > > > developers died a while ago… > > > > > > Naturally, the replacement is equally in a poor state, but may have > > > some legs someday: https://github.com/fedora-infra/noggin > > > > > > 2. Ipsilon development was only considered important as part of being > > > tech preview in RHEL and now it’s not. > > > > > > There are some major problems here. First of all, Ipsilon development > > > has been gated by a single person. That person also seems to have > > > trouble making time to review pull requests. There has been interest > > > from the broader community about using and contributing to Ipsilon, > > > since unlike Keycloak, it is written in an accessible language > > > (Python). > > > > > > Getting Ipsilon to Python 3 would be enough for me to get started on > > > bootstrapping some of the other interested parties onto Ipsilon, and > > > hopefully give us a more sustainable community long-term. > > > > I guess my question to all this is... Why? What's the goal? If Keycloak > > does everything Ipsilon does and more, what's the point of keeping a > > dead project alive instead of contributing to the active, lively one? > > > > If there really, truly is interest from the broader community, why not > > do a friendly fork, get all the work you want in, and see what the > > original maintainer thinks? > > > > Keycloak is not generally Fedora contributor friendly. Aside from it > being written in Java (which is problematic with the Java stack in > Fedora slowly imploding...), Keycloak is a lot less flexible and a lot > more tied to aspects of RHEL/Fedora that make it annoying to use in > other environments. > > At least with Ipsilon, the Python codebase makes it easy for a broad > base of contributors to hack on the code. It's also much easier to set > up than Keycloak and easier to plug into more environments. > > The biggest issue with Ipsilon as a project is the lack of awareness > of its existence. That has allowed the fact that the maintainer hasn't > recently been able to focus on it in a while to be unnoticed. Now that > is changing, and this is a problem, as I outline later... > > > For Fedora, though, if FreeIPA can replace FAS, or GitLab can replace > > Pagure, or a generic notification service exists somewhere to replace > > FMN, or whatever, why spend time on such things we could be spending > > developing the few unique tools we need to continue building the Fedora > > distribution? Stopping along the way to build an identity and access > > management platform isn't going to make the distribution better. > > > > FreeIPA is a perfectly fine solution, since it's broadly available and > easy to deploy. The non-Java parts (everything but Dogtag) is quite > easy to understand and hack on. Reproducing the tooling and > environment is easy as well. I have no problems with it other than > FAS-specific functions still need
