I lean towards forks as well. I understand Naba's concerns but for most of the
work we do, forks are a straightforward way to work on contributions to Geode.
It's easy to give people rights on your fork if you work with multiple
contributors.
Joris
________________________________
From: Ernie Burghardt <burghar...@vmware.com>
Sent: June 2, 2020 22:17
To: dev@geode.apache.org <dev@geode.apache.org>
Subject: Re: [DISCUSSION] Stop using the Geode Repository for Feature/WIP
Branches
I'm a fan of features on forks! It's fairly simple to make forks accessible to
other folks.
I know this isn't a vote, but I'm a +1 for the concept...
EB
On 6/2/20, 3:42 PM, "Jacob Barrett" <jbarr...@pivotal.io> wrote:
I know this has been brought up multiple times without resolution. I want
us resolve to ban the use of Geode repository for work in progress, feature
branches, or any other branches that are not release or support branches. There
is no reason given the nature of GitHub why you can’t fork the repository to
contribute.
* Work done on these branches results in the ASF bots updating the
associated JIRAs and email blasting all of us with your work.
* People don’t clean up these branches, which leads to a mess of branches
on everyones clones and in the UI.
* All your intermediate commits get synced to the repo, which bloats the
repo for everyone else. Even your commits you rebase over and force push are
left in the repo. When you delete your branch these commits are not removed.
There is no way for us to prune unreferenced commits. Nobody else needs your
commits outside of what was merged to a production branch.
If anyone has a use case for working directly from Geode repo that can’t
work from a fork please post it here so we can resolve.
Thanks,
Jake
