[HN Gopher] OpenDev is a collaboratory for open source software ...
___________________________________________________________________
OpenDev is a collaboratory for open source software development at
scale
Author : xo5vik
Score : 55 points
Date : 2024-01-09 18:14 UTC (4 hours ago)
(HTM) web link (opendev.org)
(TXT) w3m dump (opendev.org)
| stonogo wrote:
| This seems to be squarely aimed at Gerrit fans, which is
| difficult for me to wrap my head around. The projects I'm on
| which are Gerrit-encumbered all seem to regard it as a necessary
| evil rather than a selling point. Still, the project is well-
| thought-out and I hope it's successful!
| enasterosophes wrote:
| From what I've seen, it's more like "what patterns you should
| follow if you want to do a lot of collaboration with openstack
| upstream."
|
| OpenStack uses opendev, so anyone who wants to contribute
| upstream to openstack will need to know about the opendev
| ecosystem, possibly by dogfooding tools like Gerrit and Zuul in
| their own infrastructure.
|
| I don't think openstack will go away any time soon, and I don't
| think they'll stop using Gerrit etc any time soon, so everyone
| else in their vicinity also remains encumbered with tooling
| that sometimes feels legacy or over-complicated :)
|
| Personally, I don't mind gerrit as a code submitter and code
| reviewer. The workflow feels pretty straightforward to me. Some
| aspects of Gerrit administration are annoying though. It also
| seems a bit encumbered by being written in java; this flows on
| to annoyances like not supporting FIDO2 keys yet, and probably
| not in the near or medium future either (correct me if I'm
| wrong).
| jayofdoom wrote:
| There's an interesting thing about complicated tools: they
| often exist to serve complicated requirements.
|
| OpenStack is a large, complex piece of infrastructure
| software used at scale that many people, even on HN, will
| never experience directly. Why don't you hear about us much?
| Because people running at that scale frequently don't enjoy
| talking about the details of their infrastructure.
|
| Ask the question next time you see something in a software
| tool, e.g. gerrit, that seems over-complicated: What can this
| software do because of this complication that I'm missing?
|
| I don't think the tooling we use is what everyone should use,
| by any stretch, but don't assume things are being done in an
| antiquated way just because they're different than you're
| previous experiences or because they've been done that way
| for a long time.
| jayofdoom wrote:
| So time for a history lesson.
|
| First, who am I? I'm JayF -- I've been working on OpenStack for
| about a decade, and am the currently serving TC Chair. This is
| not an official history, but my attempt to give you the story
| behind this from my perspective.
|
| OpenDev collaboratory originally started as part of OpenStack
| itself -- as the team that enabled us to test the giant software
| suite. When it became clear that the tooling created and used by
| that team had general interest, it became time for them to spin
| off into their own group. I'll note that this maps similarly to
| what happened with Zuul -- a tool created around OpenStack, that
| was generally useful and split into it's own project. OpenDev was
| infrastructure services created around OpenStack and for
| OpenStack, that are generally useful and split into it's own
| project.
|
| This context is important as to where it puts things on the
| timeline: OpenDev, and the associated technologies, were not
| created as an alternative to some incumbant power like Github or
| Gitlab -- when it was created, there were few, if any, other
| tools that could operate at that level of scale. (It's unclear to
| me if Github, as we think of it today, even existed or was at any
| level of popularity at this point in time.)
|
| So as this thread hopefully picks up steam, lets avoid terms like
| "alternative to" or things that miss the context. OpenDev has
| been around, and open, for a long time. It will continue to be
| around, and open, for a long time. They aren't going to feed your
| code into an AI to train it, and they aren't going to try and
| turn your collaboration toolset into a social media platform.
| It's a tool to get work done, and I've been lucky to work in it
| for the last ten years.
| ReleaseCandidat wrote:
| > It's unclear to me if Github, as we think of it today, even
| existed or was at any level of popularity at this point in
| time.
|
| In 2010, when Openstack has had its first release, Github
| already hosted 1 million repos.
| https://github.blog/2010-07-25-one-million-repositories/
|
| For comparison: Sourceforge had less than 250,000 in 2010 https
| ://en.wikipedia.org/wiki/SourceForge#/media/File:SF.net....
| jeblair wrote:
| Some of the folks running this (of which I am one) are going to
| be talking about it in a livestream in a little over a week:
| https://openinfra.dev/live/
| lucideer wrote:
| > _The difference is subtle, but significant. In the pull request
| model, you create a fork of the original repository, push changes
| to it, and ultimately propose to merge changes back. In the
| change proposal model, you prepare a change, and propose it. You
| do not create a complete fork and everyone contributes into the
| same original repository with what are basically lightweight,
| ephemeral topic branches_
|
| This is an odd distinction to make. Forking in GitHub is an
| entirely optional process - in my experience it's primarily used
| to invite outside collaborators to open source projects. I've
| never worked on a team that uses this process for their owned
| repos. I've only ever used GitHub Pull Requests according to the
| process described here as the "Gerrit way".
|
| I've never used Gerrit so not sure if I'm missing something here:
| it sounds like they're just describing a process that works
| identically to PRs with the exception that the platform doesn't
| support forks?
| reactordev wrote:
| Quite the contrary to their claim, we restrict forking on ALL
| our repos and still have meaningful PRs.
|
| Your assertion is correct that most organizations operate this
| way.
|
| However, open source is different. Often you'll have someone
| fork - hack on it - devise a novel change - and request a PR
| from their fork:branch to origin:branch.
|
| In this scenario, the fork - and subsequent hacking - are
| exploratory while submitting the change and PR is distinctive.
| Not sure how one is supposed to explore and hack and provide
| PRs in their model as you're forced to branch. A local copy is
| still a "fork" but with a separate origin.
|
| You can still do a dual origin setup or do a merge main onto
| yours but I find this extremely limiting to contributors and
| overly controlling by project owners. There's nothing stopping
| you from enforcing squash on merge or having standards on your
| SDLC. Enforcing that on everybody else isn't in our best
| interest though. A diarrhea of commits is how you end up with
| spaghetti code.
| bityard wrote:
| From where I sit, the primary distinction seems to be where the
| fork lives. On Github, forks are public. You get a copy of the
| repo in your own namespace on Github which you can pull from
| and push to from wherever. Others can see it and any changes
| you make to it as well.
|
| On OpenDev, your clone/fork/personal branch is only on your dev
| machine and you only push patches, if I'm reading it right.
|
| I guess the OpenDev model discourages people from forking the
| repo, modifying it to suit their needs, and then not sharing
| the results. To some degree.
|
| I think I actually prefer the GitHub model where people's
| branches/changes are public by default unless they choose to go
| through the trouble to make their fork private. I have found
| many good bug fixes and enhancements for repos abandoned by
| their upstream authors this way.
| levkk wrote:
| The UI is much faster than Github, which is great, big selling
| point for me. The "iterative change" approach is pretty much how
| companies use Github I think. Contributors are given push
| permissions for the repo, the main branch being off limits, and
| PRs are required an approval before they can be merged. The
| Github model with forks is not great imo, because forks get out
| of sync pretty immediately.
|
| Some features I would like to see is ranking of repos by
| popularity, e.g. "Github stars".
___________________________________________________________________
(page generated 2024-01-09 23:00 UTC)