Benson Margulies 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.
Hi, At this point it looks like the switch is going to happen, and there has been this argument repeated a few times that the current situation with SVN is not broken and that changing will imply significant pain. It's most likely true :). However as a user of Felix and its sub-projects, I'd like to state that this switch would be very welcome and ease working with Felix and contributing patches a lot. First, the Felix SVN repo is humongous and mixes so many sub-projects that it's a pain to navigate through it to get the right ones, the right branch, the right commit. Second, there's the problem of hassle-free contribution: when I encounter an issue, I just want to just fork a sub-project, and create a pull request and the associated JIRA ticket, and go back to my routine. But forking the whole felix project just for a single a component is a big overhead, and last time I tried the Felix Git repo on GitHub did not look up-to-date. It might not look like it because you guys have your environments set up and you spent enough time to do so, but that is an artificial entry barrier to contribution (not because it's difficult, but because it's so heavy compared to the Git workflow we got used to). So while this switch might not go as smoothly as hoped, it will also benefit users and I believe will help the Felix project get contributors, new committers and even maybe new sub-projects, as long as there is no new overhead introduced by the way the switch is made :-) In my experience having one repo per bundle results in the opposite overhead (having too many repos to clone, update, etc), and I think having one repo per sub-project is the right compromise. That's also we've been doing at work for a while (we had one repo per bundle before for a long time). Finally, it would be great not to bump versions for bundles that have not changed just to avoid having several releases prefixes handled by the maven-release-plugin within the same repository. So I am not favourable to systematically making all bundles in a sub-project part of the same multi-module Maven project (and thus share bundle version by default) for that reason alone. Although proper package semantic versioning would make this transparent at runtime (or 'install' time), it makes it impossible to track releases and the evolution of the different bundles, and generally feels against OSGi principles' of proper modules and versions. A big non-binding +1 from me. :) -- Simon Chemouil
