On 09/25/2017 11:24 AM, Geertjan Wielenga wrote: > I would prefer this approach too, also since we're working in this way > naturally already, however I have seen "Can't you do that in a branch of > the ASF repository instead? It's better IMO if things stay here.” from > Bertrand, one of our mentors. Hoping there'll be clarity on this point from > our mentors via this thread.
You are really free to do as you please there. Typically, once you have the commit bit to the ASF repo, you'll wanna work on branches on that repo, so you can collaborate on changes with others, but for drive-by commits, forking is acceptable. However, do note that if you merge from a fork via a PR, GitHub does some weird magic where it silently inserts the changes into our repo and then merges it. This messes up the diffs you get to the mailing list (they'll appear as having already been committed to the repo before the merge in some cases), which means you'll risk getting a merge summary but no diff on the mailing list. So I'd recommend that _committers_ at least work off the main repo. With regards, Daniel. > > Gj > > On Mon, Sep 25, 2017 at 1:38 AM, Matthias Bläsing <[email protected] >> wrote: > >> Hi, >> >> Am Montag, den 25.09.2017, 01:05 +0200 schrieb Geertjan Wielenga: >>> See: >>> https://cwiki.apache.org/confluence/display/INFRA/Git+workflow+for+in >>> frastructure-puppet+repo >>> >>> Gj >>> >>> On Mon, Sep 25, 2017 at 12:54 AM, Geertjan Wielenga < >> [email protected]> wrote: >>> >>>> The Apache Way is to branch, rather than fork -- the idea being >>>> that via >>>> branches, the code stays at Apache, rather than being somewhere >>>> else, i.e., >>>> in someone else's Git repo. >>>> >>>> From the branch, reviews are done, prior to merging. >> >> The means everybody that wants code merged needs write access to the >> netbeans git repository. >> >> I don't see any benefit here. The normal github way is: >> >> * fork the project >> * create a working branch for your changeset from the development >> branch/target branch and name it matching your intention >> * do your changes >> * create a PR (on github via their system, in other environment via >> Email), which details your changes >> >> Now this PR is reviewed: >> >> * Has the author an ICLA on file @apache (this might be >> interesting...) >> * Are the changes ok? >> >> If review fails, the necessary adjustments can be done on the "working >> branch" created above, as the PR tracks that. >> >> If all changes are ok, this branch is merged in the target branch (pull >> the target branch, merge the "working branch", push changes to the >> central repository). The "Merge changes" Button in github PRs does >> exactly that ans there is also a "Command line instructions" link, that >> shows what happens under the hood. >> >> For the merge to master a committer is needed, all interaction on the >> PR can be done by "non-committers". >> >> The current PR on github show the "normal" way. A committer would now >> merge these (after review or whatever). >> >> The big question: Is the github mirroring of the netbeans repository >> two way? So are merges done on github cloned into the apache >> repository? >> >> >> Am I missing something? >> >> Greetings >> >> Matthias >> >
