Hi all, I'm cautiously +1 on the direction for master. Taking the Gerrit/Jenkins burden off Ian, and getting rid of the manual push to the ASF repo, are both worth a lot.
I'd like to raise one thing that hasn't come up explicitly yet: downstream extensions. Some projects build on AsterixDB and develop changes that span AsterixDB and their own repositories. They test those change sets together before either half lands. Today this works because Gerrit topics can link changes across servers. Some of those extensions also maintain long-lived non-master branches on our Gerrit. Those branches have never been pushed to the ASF GitHub repo, so today they live only on UCI infrastructure. I think we might handle both without slowing the migration down: 1. Split by branch. Master moves to GitHub PRs and Actions as proposed. For the non-master branches that exist only on Gerrit used exclusively for extensions, those extensions could take them to their own infrastructure. Nothing leaves ASF infrastructure, because they were never on it, and it's one less thing tied to UCI. Any branch that is in carries an ASF release line. Any branch that does should obviously come to GitHub with master. 2. Downstream handles cross-repo testing. An extension can link its own change to an AsterixDB PR on its side (a "Depends-On: <PR URL>" style reference) and fetch the PR head for its CI. That needs nothing from ASF Infra and adds nothing to our commit messages. The one request I'd make of the new setup is to allow merge commits on master, so forward-merges from maintained branches can still arrive as ordinary PRs. 3. One home per branch. On Hussain's side-by-side suggestion: I'd rather not run the same branch on both systems for a month. It's changing horses mid-stream, and two sources of truth for one branch is how commits go missing. A pilot period where a handful of PRs go through GitHub, while Gerrit remains the branch of record, might give us the confidence without that risk. Thanks, -MDB On Tue, Sep 22, 2026 at 8:09 PM Hussain Towaileb <[email protected]> wrote: > > This looks like a move in the right direction to me, especially with the > freebies we will get from Github, and it would offload quite a bit of the > stress from Ian when he needs to wake up in the middle of the night to fix > the machines. > > However, I have few concerns, all seem to be stemming from people using AI > and spamming Github now: > - I've seen people commenting that Github can get super slow more > frequently now than before, although I'm hoping it's not as bad as they > claim. > - Related to the above point, I wonder if that will have any impact on our > code reviews/jobs running. On an average day that's fine, but when dealing > with criticals and tight timelines, that might add some stress. > - The quotas on tests is a concerning factor for me, I don't know how bad > that would be, but hopefully not a common occurrence. > > I think 3 things would make me more comfortable with migrating: > - If we can set up Github and just have a quick demo on how things will > work, right now your explanation is clear, but it still is all theoretical > for me. > - If we can have Github running with Gerrit side by side for a while (maybe > a month?) just to check how stable it is. > - And this is more of a question, does moving to Github mean the infra for > Gerrit is gone? Would be nice to have it on the side so in case of > emergencies, we can fire things up on Gerrit until Github is back so we > don't get blocked. > > - Hussain > > > > > On Fri, Sep 18, 2026 at 3:14 AM Ian Maxon <[email protected]> wrote: > > > Hi all, > > The build infra for AsterixDB has been relatively unchanged since > > before incubation. I would say > > at the time, it was pretty state of the art. Code review wasn't de > > rigueur in software. Google code still existed, and GitHub hadn't > > introduced PRs. There was no ASF infrastructure during incubation that > > we could use to support the practice. So it made sense to keep Gerrit > > as it was, and Jenkins along with it to support CI. I think the > > project can look back and be proud that we were basically ahead of the > > curve. > > > > However now, the infrastructure does exist within the ASF- because now > > there is a more tight integration with GitHub. I think most projects > > just start there today by default. With that, you get PRs and Actions > > for "free" basically. Nobody has to take care of the infra side of it, > > like I have to with Gerrit and Jenkins. ASF Infra takes care of that. > > I'm also just one person, and having a fundamental piece of the daily > > operations of the project reliant on me and UCI in general is not a > > particularly sustainable practice, although it's worked out OK so far. > > > > We also have the agreement we came to with our Mentors at the time > > regarding pushing code from Gerrit to ASF repositories. I think this > > has worked about as well as it could have, but it's been shown over > > time to be both something that is easy to forget and also something > > that is confusing to new Committers. I don't think there is an easy > > way to make it automatic. It would require us to somehow come to an > > agreement with Infra about a bot account, and I am not sure how they > > would feel about that. As annoying as it is today the human in the > > loop does serve a few validation functions. > > > > With these things considered, I would like to discuss an idea that has > > come up informally more than once with other PMC members, of simply > > migrating all CR and CI/CD to Github. I will list out the pros, cons, > > and work involved as I understand it: > > > > Pros: > > - Lower maintenance overhead (uptime and security) > > - More familiar interface for new committers > > - Workflows are easier for everyone to contribute to than Jenkins jobs > > - Direct integration with ASF release infrastructure (particularly > > for containers) > > - Organizationally cleaner (direct control by ASF, rather than > > time/resources donated by other org) > > Cons: > > - GitHub is a MSFT product, not an open source project- so it could > > be rugpulled at any time. > > - Some people (like me) actually enjoy Gerrit's interface > > - Jenkins is extremely flexible, to a fault > > - All Jenkins jobs need to be migrated to actions. We have over 12 > > jobs that run with every commit. > > - GitHub's reliability has been noticeably terrible lately, and > > particularly bad in the past year. There are certain days where it's > > almost entirely unusable in some way for large parts of the working > > day. > > - The pool of GitHub Actions Runners is shared among the whole ASF. > > Once it's depleted, that's it- no projects can run more actions until > > the quota resets. > > - AFAIK self-hosted runners for ASF is kind of a new/untested thing. > > We might be able to sidestep the issue above somehow by doing that, > > but it's not a sure thing. > > > > What does everyone think? > > - Ian > > > > > -- > Regards, > Hussain Towaileb
