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 >
