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
