On Oct 24, 2015 2:21 PM, "Marcel Offermans" <[email protected]> wrote: > > Within Felix we have “subprojects” that consist of one or more bundles and I would argue that they are always released together. This does not mean that for every release, every bundle needs to change, sometimes only a subset of the released bundles change. > > So I would definitely argue against getting a Git repository per bundle. Per subproject sounds like the right granularity to me. > > Regarding Maven I don’t have much experience on how to set that up with Git. Note that not all subprojects use Maven. Specifically the “dependency manager” uses a gradle/bndtools based setup. We could easily move that to its own Git repository. It is already setup for that. > > In general I like Git, and outside of the Apache projects I’m involved in I almost exclusively use it, but I’m +0 on making a switch because it’s also a lot of work and I don’t think the benefits are huge. If it works, don’t fix it. :)
+1 I don't care, but I agree the benefits aren't super compelling other than buzzword compliance. > > Greetings, Marcel > > On 24 October 2015 at 11:06:02, Benson Margulies ([email protected]) wrote: > > Here's the basic issue. The maven-release-plugin doesn't always work > with git when the pom you are releasing is not the top of the > repository. I put a great deal of work into fixing it, and yet others > continue to report problems. (It works for my favorite test case.) > > So, the conservative strategy is to put each group that are released > together into a repo. > > As far as migration, INFRA only understands 'one big flip.' That > offers us two choices if our goal is to subdivide: > > 1: Let infra do the flip, and then gradually get new repos and move > some things into them. > > 2: Do our own migration: one by one, get infra to make new, empty, > repos, and use the existing mirror repo as a source to push the pieces > into them. > > I don't see much value in item #1 over item #2. So I'd propose to > start by asking infra for a repo for the overall parent pom, which I > think needs to live in a repo by itself (that's how we do it at > Maven). Once we have released the pom from there, we can migrate > others in whatever grouping we prefer. > > As the new committer here, I have to ask: what decision-making process > would be good? > > > > > On Sat, Oct 24, 2015 at 1:00 AM, David Jencks <[email protected]> wrote: > > YAY!! > > > > as you can tell, I’m in favor of it. > > > > I think that 1 repo per project may be too small. For instance I think it makes sense to have one repo for the 3 gogo projects, even though they are released separately. I think soon there will be at least 4 scr projects and I’d like them to be in 1 repo. > > > > Do you know how infra feels about gradual migration? Are they fine with it or do they prefer all-at-once? > > > > thanks > > david jencks > > > >> On Oct 23, 2015, at 10:36 PM, Benson Margulies <[email protected]> wrote: > >> > >> There was some discussion a while back about git, which I recall > >> (perhaps inaccurately) as vaguely positive. It's a lot easier if each > >> releasable thing gets its own git repo. > >> > >> How do folks feel about starting with a migration of the bundle plugin? > >> > >> --benson > >
