Hi Oliver and others, I don't agree that there has to be the one or the other ... In my opinion small things should be fixable directly without any branching. If you are part of the project and hereby can commit to the repo, I'd prefer people working on branches of the official repo. If you're not yet part of the project, you fork it and submit PRs from there. Should all work together nicely without too many rules.
And we're currently not talking about hundreds of parallel people working on things ... at the moment we have one or two Presentations, a presentation tool and a website. I would opt for starting without too many rules and to add some as they become necessary. As I said, the current process RTC is sort of demotivating me and not having branches and having to work outside would even more. RTC makes sense in tools that effect a lot of people ... Like changes to Apache Infra ... Apache Maven ... stuff like that. But I agree ... we're doing Presentations, not brain-surgery or control systems for nuclear power plants. (Perhaps we should change to RTC in Apache PLC4X ... as it could be used in said power plants ;-) ) Chris Am 17.05.19, 10:06 schrieb "Kuebel, Oliver" <[email protected]>: Hi, I'm not sure if I'm missing something, but the conversation looks for me as there is either the one or the other way. Either edit in a git branch directly (incl. master) or fork everything. I see Justin/Chis' point in some way - keep it simple. And I agree. Working on the project should be as less laborious as possible. But I also agree Lars' Point of view. It's important to keep on regularity. Without it you are losing the overview because of dozens of single "standards". But then I am thinking about what we are doing here: We are talking about slides for a presentation - not the control unit for a nuclear power plant. A strict order is important (especially for a german like me ;) ) but I think changes on slides should be allowed to be done as easy as possible. As a non-commiter who is willing to help, I have to accept that there are people who edit the code right in the master branch while I'm not allowed to do so. But I know that they have done this more often than me before. The (hopefully) know exactly what they are doing. Their contribution is not better than mine. Besides this, perhaps you could even split the check in process for commiters. Allow changes on the content of the slides directly. Changes on the other stuff (content of the website, the "engine" for building the slides, etc.) should be branched. So my conclusion/opinion after reading this conversation is: Allow both. Commiters should allowed to change slides in the master directly and need a branch for changes on the remains. People like me have to do a PullRequest. Oli -----Ursprüngliche Nachricht----- Von: Justin Mclean <[email protected]> Gesendet: Freitag, 17. Mai 2019 01:54 An: [email protected] Betreff: Re: Git branches Hi, > Again: You've done it exactly like this with all your pull requests so > it seems to work for you? Because I was asked to do it this way. The process has been sub-optimal IMO. > 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. For external contributors yes. > None of my concerns are related to Github, in fact, I didn't even use > that word in my initial mail. A pull request is a gifthub feature its not a feature of git, git uses patch files. (Although it recently added a similar feature via the request-pull command which generate a summary of changes.) Some context may help, there’s currently 2,634 people in the ASF GitHub organisation [1], which is about a 1/3 of the total ASF committers (currently 6901). > 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. I’ve not seen this on projects I’ve been on, usually the committers/PMC members outnumber the external contributors. It may be different on very large popular projects like Spark, but that’s probably not a good example for a number of other reasons. > 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? For small stuff why even have a branch? Work right off master. For larger stuff it best to work in one sure. External contributors can choose how they want to work forcing people down one path may mean they don’t contribute. If someone puts some power point slides as an attachment in a JIRA and asks would we like them, (licensing consideration aside) I’m not going to turn around sorry I cannot accept that, you get to get a GitHub account and fork the repo, make a branch and provide a pull request. Thanks, Justin 1. https://github.com/orgs/apache/people
