Re: Git Forge Requirements: Please see the Community Blog

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

It is self-hosted.

>
>>
>>
>> --
>> Ernestas Kulik
>> Associate Software Engineer - Base Operating Systems (Core
>> Services/ABRT)
>> Red Hat Czech, s.r.o.
>> _______________________________________________
>> devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
>> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
>> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
>
> _______________________________________________
> devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux