My introduction to git was really from a pre-ASF GitHub usage context so that very common fork/PR workflow is more familiar to me :-) It’s a nice environment for collaboration.
Note if PLC4X were setup to have its GitHub repo as its main repo, not this non-writeable mirror thing, merging a PR would involve a committer just pushing the PR’s merge button. Also we could use Github Issues. I’ll just mention a couple of other benefits of using the Github/fork/PR flow in case they weren’t obvious: you don’t clutter up the ASF-repo or GitHub mirror with personal short-lived feature/bugfix branches, they only exist in your fork/clone. Hence a clone or pull of the ASF-repo/mirror doesn’t include them / bring them into your private clone. PRs nicely group changes and comments/discussion that involve multiple commits people can browse a feature’s/fix's WIP just by pushing your WIP to your fork (no need to pull into your clone. When you create a PR (even if it's [WIP]) it provides additional visibility in to ongoing work. Having everyone use the same (fork/PR) mechanism make everyone feel “equal” :-) As you note, a committer can merge their own PR if they choose to There seem to be a lot of benefits to using the fork/PR model so I wonder why we wouldn’t strongly encourage committers to use them too. Are there good arguments for not using them? Maybe I’m just in the minority here… and so be it :-) — Dale > On Jan 9, 2018, at 10:23 AM, Christofer Dutz <[email protected]> > wrote: > > Hi all, > > I just had Infra turn on Travis support for our Github repo and it > immediately seems to have worked correctly :-) > > So, we should discuss how we want to use Github in general. I know there are > projects that don’t really use GitHub especially Github PullRequests at all > and for example in Apache Edgent almost everything is done in Pull Requests. > So how do we want to do things here? > > My opinion would be to utilize whatever the contributor wants. I personally > prefer to create a feature branch on the ASF Git and have Apache Jenkins auto > build it. But I think, especially for getting new people on board, Github’s > workflow is a valuable addition. > > So how about this: > If someone inside the team wants to work on Github, he just does it, creates > a pull request and merges it himself as soon as he sees the PR being fit for > merge. If he wants feedback he asks for feedback on the list and someone else > merges this as soon as the review has been done. If some outside user creates > a PR, we review within the team it and apply it if we see it fit of being > merged. > > I wouldn’t make things too complicated or restrict ourselves to one set of > tools. I think we have setup everything to allow all sorts of paths for > getting code in and having it tested. Allowing all of them keeps the > community most open to others. > > What do you think? > > Chris > >
