There is a relatively standard Apache workflow that handles GH PR's. The committer merges the PR and pushes it, editing a comment to say 'closes #nnn" and the PR gets closed.
On Sun, Oct 25, 2015 at 12:51 PM, David Jencks <[email protected]> wrote: > While working on bnd and OSGI at github I’ve become quite attached to the > triangular workflow model. (cf > https://github.com/blog/2042-git-2-5-including-multiple-worktrees-and-triangular-workflows > > <https://github.com/blog/2042-git-2-5-including-multiple-worktrees-and-triangular-workflows>) > I probably should know already, but does anyone know how practical it is to > do this with apache git and developer branches at github? > > I don’t know if apache git is at version 2.5 yet, but from the above link it > looks like the new worktree feature may provide an alternate solution to the > multiple-branches problem. > > david jencks > >> On Oct 25, 2015, at 12:12 PM, David Jencks <[email protected]> wrote: >> >> Hi, >> >> In the 12+ years I’ve been working on apache projects I can’t recall any >> time when I’ve wanted to simultaneously check out different branches of >> modules of the same top level project. Therefore, unless anyone has actual >> contrary experience, I’d be in favor of trying a single git repo and >> refining it into multiple repos if we discover problems in real life use. >> (I have wanted to check out different branches of the same project >> simultaneously, but with git this is not helped by more repos). >> >> thanks >> david jencks >> >>> On Oct 25, 2015, at 2:47 AM, Christian Schneider <[email protected]> >>> wrote: >>> >>> I am not sure if one git repo for everything would be a good idea. The main >>> reason is that in git (unlike in subversion) each branch and tag you do >>> contains all the other unrelated projects too. >>> I think it would also be quite difficult to checkout a state of the repo >>> where you need bundle A in branch A1 and bundle B in branch B2. Probably >>> this would mean that you need to checkout two instances of the repo >>> to have both branches visisble at the same time. You would then also have >>> to be really careful to not pick a project from the wrong checkout as it >>> would be in kind of an undefined state there. >>> >>> The other solution of having one git repo per bundle also seems to be quite >>> difficult to manage as you need to checkout and sync every such checkout in >>> the correct way. I have seen a project that does this at a customer and it >>> is not very easy to work in this structure. >>> >>> In the Aries project we went for kind of a compromise. >>> >>> We aim for releases by subproject. So each subproject can go into one git >>> repo. >>> The advantage is that each tag in git really covers the whole subproject. >>> So from the git side this is natural. >>> >>> The downside is of course that in many cases bundles are released that did >>> not change at all. >>> We make sure the package versions are done with semantic versioning. So >>> from the OSGi point of view the versioning >>> is still working as before. >>> >>> At the moment we have not yet done the migration to git but it is planned. >>> We are currently moving each subproject to the release by subproject model >>> gradually. >>> Theoretically we can then move each subproject to git independently. I am >>> not sure though how to move the change history over in that case. >>> In any case the Aries JPA project is the first one that is fully converted >>> to the release by subproject model if you want to take a look. >>> https://github.com/apache/aries/tree/trunk/jpa >>> >>> Christian >>> >>> Am 24.10.2015 um 23:32 schrieb Benson Margulies: >>>> On Sat, Oct 24, 2015 at 4:21 PM, David Jencks <[email protected]> >>>> wrote: >>>>> I like having several felix subprojects open in one eclipse instance at >>>>> once, which the current svn structure facilitates. Having just one git >>>>> svn rebase to run is nice. Is there a way to stitch together several >>>>> smaller git repos that would work similarly? Not knowing how to do this, >>>>> I am starting to lean towards one big repo. >>>> Well, there are git submodules. But I hate to take everyone into that >>>> rabbit hole. I think we should aim to start with one big repo and >>>> assume we can tame the maven-release-plugin to start with. >>>> >>>> >>>>> FWIW, I’m hoping to move DS onto a gradle based build soon. >>>>> >>>>> thanks >>>>> david jencks >>>>> >>>>>> On Oct 24, 2015, at 2:51 PM, Benson Margulies <[email protected]> >>>>>> wrote: >>>>>> >>>>>> Greeting, Marcel, >>>>>> >>>>>> It's not my intention to try to talk anyone into changing how they >>>>>> release anything. For the things that are built with Maven, it's my >>>>>> preference to avoid exercising the maven-release-plugin's feature of >>>>>> handling multiple released items in a repo, but it's just a >>>>>> preference. If the acceptable compromise is to have less repos than >>>>>> releasable items (possibly as few as one repo), I'd personally rather >>>>>> do that than not move to git at all. >>>>>> >>>>>> regards, >>>>>> >>>>>> benson >>>>>> >>>>>> >>>>>> On Sat, Oct 24, 2015 at 2:43 PM, Marcel Offermans >>>>>> <[email protected]> wrote: >>>>>>> On 24 October 2015 at 11:36:03, Benson Margulies >>>>>>> ([email protected](mailto:[email protected])) wrote: >>>>>>> >>>>>>>>> So I would definitely argue against getting a Git repository per >>>>>>>>> bundle. >>>>>>>>> Per subproject sounds like the right granularity to me. >>>>>>>> If a subproject is released all at once, then we're completely >>>>>>>> agreeing. If not, then your preference means exercising the >>>>>>>> occasionally squishy part of the release plugin; maybe it will get >>>>>>>> fixed once and for all. >>>>>>> So for the dependency manager we reasoned as follows: >>>>>>> >>>>>>> 1) When talking about releases within Apache, we are talking about >>>>>>> source code. Releasing that a subproject at a time makes sense to me as >>>>>>> the code, even if it ends up in different bundles, clearly belongs >>>>>>> together. >>>>>>> >>>>>>> 2) Binary releases are a matter of convenience and “what is convenient” >>>>>>> depends a lot on where you’re coming from. A lot of people would argue >>>>>>> that putting a binary in Maven is convenient, but there are definitely >>>>>>> other options. The binary releases also don’t have to have a 1:1 >>>>>>> mapping with the source, so we can have N bundles being put in Maven >>>>>>> and other repositories all from the same source release. >>>>>>> >>>>>>> Greetings, Marcel >>>>>>> >>>>>>> >>> >> >
