hello, +1 for the move (after Christmas). See in-line
On 10/12/2018 12:39, Francesco Mari wrote: > Hi, > > On Mon, 10 Dec 2018 at 11:45, Robert Munteanu <[email protected]> wrote: > >> - one repository for Oak or one repository per module (oak-commons, >> oak-api, etc )? >> > I don't think we should change the structure of the repository during the > migration. I would maintain one single repository for Oak. +1 > >> - how does this tie into the potential modularisation work? >> > The migration to Git and the modularisation work look orthogonal to me. +1 > > >> - who will do the work for migrating repositories, release scripts, >> Jenkins setup, etc? >> > I'm willing to drive the effort if we decide to go further. Before the > migration we should come up with a list of consumers of the SVN repository > and figure out the amount of additional work after the migration. probably is mainly jenkins and github. We could make it clearer by advertising officially the move and see if any other consumer comes up. Another point to keep in mind is the version number for diagnostic builds[0]. So far we used the SVN revision which is unique and incremental. This works perfectly in the OSGi world making sure any diagnostic build will apply as planned. If moving to git purely, commits are tracked as SHA and I don't think the incremental version aspect can be enforced the same way. 0) http://jackrabbit.apache.org/oak/docs/diagnostic-builds.html We have to find a way to achieve the same when moving to git. Probably by appending the full timestamp of the commit or some other form of time related information. It probably won't be enough as if someone merge in a commit "older" than the current HEAD, re-releasing a diagnostic build will produce the same timestamp. Again, just quickly crushing my head on it, we could work out something with the release-plugin skipping the tagging, but adding a commit every time before we produce a diagnostic build. Something to be investigated. > > >> - what is the transition plan for the SVN repositories and what will >> happen to the existing github mirrors? >> > I would leave the SVN repository in read-only mode after the migration. The > GitHub mirror should be replaced by the migrated repository. +1 Davide
