On Sat, Oct 24, 2015 at 2:27 PM, Richard Hall <[email protected]> wrote: > 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.
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. >> >> 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 >> >
