Hi all, Just my opinion on this (and related ones) : I've noticed we've invested far more time in defining rules and restrictions for contributing than actually contributing.
How about starting with as few as possible rules and defining them as we go where necessary? As this way we are doing it at the moment is not very welcoming (at least it feels this way for me). We want people to join and not to think: awww, lost my drive when reading about all the rules. I know that if I have to manually re-sync my repo fork this is another step needed. I already thought it silly not to fix things in master directly. Now you want me to do it even more beurocratic?... Let's say it's not fuling my enthusiasm. Chris Outlook für Android<https://aka.ms/ghei36> herunterladen ________________________________ From: Lars Francke <[email protected]> Sent: Thursday, May 16, 2019 8:18:59 PM To: [email protected] Subject: Re: Git branches Hi, On Thu, May 16, 2019 at 1:00 AM Justin Mclean <[email protected]> wrote: > Hi, > > > I don't understand: Isn't that what you do Justin? You prepared your PRs > in > > your own fork and commits and commit messages don't get lost. I don't see > > the connection. > > You can rewrite history outside of the ASF repos. > I still fail to see the connection. Once we've merged a PR we have the history (if we don't choose to squash, which I usually do) and it can't be changed. Again: You've done it exactly like this with all your pull requests so it seems to work for you? > This is also the "standard" model for basically all ASF projects I know > > It’s not the standard ASF model, it's GitHub standard model, I think you > may be confusing the two and even though a lot projects use GitHub not all > use PRs as the only way to change code. ASF uses git (although that’s also > newish) which doesn’t even have pull requests. The integration with Github > is a recent thing at the ASF. > With "this" I mean that people prepare content (e.g. patches) outside of ASF infrastructure and then submit said content to various projects (which are then often reviewed and iterated on, etc.). This has been the standard way to operate for as long as I can think. Example: Someone opens a Jira ticket and works on his own machine on a patch and submits said patch as a diff to Jira. None of my concerns are related to Github, in fact, I didn't even use that word in my initial mail. > > Also: Most people don't have the privilege of being able to create > branches > > in the official git repository. > > Most people working on the project do, if the majority don’t then IMO the > project has set it committer bar too high and not recognising merit. > Still: There will always be more people not having access than people having access even if we give someone committer status after the very first contribution. > > It's much easier to give some externalcnot-yet-committer access to some > "private" fork to collaborate. Isn't this > > the whole idea of git being distributed? > > Wouldn't it be more open and transparent to do the work in public? > Yes, you are right, it would be more open and transparent. Apart from it not being a requirement to be open and transparent to contribute to an ASF project (I could cite thousands of examples) I chose my word poorly: With "private" I really meant non-ASF infrastructure. Do I understand you and Chris right that you'd like to have branches for every little issue that anyone (whether the person is a committer or not) wants to contribute? Cheers, Lars Thanks, > Justin
