Hi all, bit late to the game here, sorry for that, but I'd like to add my two cents as well.
I am somewhat in the middle I think, I am heavily opposed to creating something like the examples that Lars mentioned in his mail where there are a lot of branches that no one can really tell where they come from, what they are for and if they still serve a purpose. I am 99% sure, and this may be the German in me speaking, that without any rules this will happen. That being said, I also have absolutely no issue with people opening branches in the Apache repository to collaborate - but I'd like to propose that we at least agree on having an issue for these branches to track progress, and delete the branch once the issue has been closed. Would that be an acceptable compromise? Best regards, Sönke On Fri, 17 May 2019 at 11:29, Lars Francke <[email protected]> wrote: > Hi everyone, > > I see that most in this discussion are of a different opinion than me and > that's fine. I haven't changed mine though. > > Similar to Chris's opinion on demoralizing: A CTR workflow & lots of > branches without documentation is very demotivating for me because it's one > of the major (and I'm not exaggerating) pain points during my daily work. > Trying to decrypt why someone changed something without adding any > information, leaving open ends etc. ("we'll fix this later"). > > I just want to summarize my opinion and then I'm happy to bow out of the > discussion. > > 1) I also believe branches in the main repo make sense when they are used > for "longer" tasks to collaborate on > 2) I believe hundreds of branches are very confusing (e.g. < > https://github.com/apache/hadoop> master & trunk branches?) and make a > collaboration for newcomers harder, in fact I know so because I'm in this > exact situation almost every month. > 3) Branches itself don't convey any information about who did what, when > and why. Is this abandoned? Was this an experiment? Has it been merged? Is > "feature-better-template" better than "feature-template-improvements" or > have they both been made obsolete by "feature-template-v2" (e.g. < > https://github.com/apache/hive> spark, spark-new, spark2, master-fixed, > ...), if every branch were accompanied by an issue then that'd be better, > then we'd at least have some documentation/intention > 4) RTC makes sense everywhere (remember: my opinions), even if it's just > for the purpose of checking whether something makes sense at all > 5) Fixing stuff directly in master makes it harder to collaborate because > there's no coordination > > Cheers, > Lars > > > > > On Fri, May 17, 2019 at 10:24 AM Christofer Dutz < > [email protected]> > wrote: > > > 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 > > > > > > > > > -- Sönke Liebau Partner Tel. +49 179 7940878 OpenCore GmbH & Co. KG - Thomas-Mann-Straße 8 - 22880 Wedel - Germany
