On 04/01/2011 09:09 PM, Vincent Massol wrote: > Hi devs, > > I see Sergiu has started the git migration, cool. However could we list the > different actions to be done and when they'll be done by whom. > > I'll start listing some questions: > > * Can we continue commit in svn? Has it been put readonly? If not, shouldn't > this be done first step?
No SVN commits from now on for the XE/XEM related repositories. I didn't move the following projects: - xoffice - xeclipse - curriki - contrib > * Can we commit in the git repos created on github right now? If not when? Yes. Right now. > * Are we going to continue having the git repos synced with the svn repo and > if so for how long? Depends on what we want to achieve: 1. commit in either of them and automatically mirror in the other repo 2. commit only in git, but the read-only svn repository should mirror github 3. keep the svn repo as a backup, without any other commits in it 4. hide the svn repo 5. delete the svn repo Personally I'd go for 4, since it doesn't require maintainance (I don't know how git branches and merges will integrate in svn), and it avoids confusion from users downloading sources from the wrong place. I wouldn't delete it completely, though, since the github experience might turn out bad enough to push us back to svn, although I doubt it. > * I've done a commit on git earlier today but didn't see any email > notifications on the notifications list? Can this be set up quickly so that > we can see what's happening? GitHub offers an automatic mailing hook, which is nice, but doesn't show the full diff as our notification mails used to do. Personally I'd like to have diffs back, even if it means more work. The best option would be to patch the official mail hook so that it has an option to send the diff inside the mail, but it will take a while to learn how to do that. Does anybody know ruby? > * I'm surrounded by git users for the week end and they're telling me there > are several ways to use git (one master repo, 2 repos, etc) and that we need > to define best practices of how we want to use git since there are lots of > ways to use it. Any idea about this? Yes, I've been thinking about that as well. I'll send a second mail with proposals, and continue this one with status/roadmap points. For the moment, until we define a new strategy, we can continue working as if it were a central repository, like we did so far with subversion, by pushing changes to the master branches on the official repositories. > Ok enough question to get started. So, right now I have two more projects to synchronize, skins and the old xwiki-tools, which should be ready in an hour or so. After that, all the repositories should be in place. == Repositories vs. projects/modules For the moment, I kept one repository for the main top projects which used to have a trunk/branch/tags structure: - platform/core, platform/web, enterprise, manager, watch, rendering, commons-core, commons-pom, commons-tools, and they should stay this way since all the submodules are released together, so tagging them together makes sense; we'll decide later if they should be split if we want to release each submodule individually - platform/skin and platform/xwiki-tools are also in one repository each, although I'd like to split them into individual repositories sometime later I split+merged xwiki-applications and xwiki-plugins into one repository per extension, holding together the plugin and the related application where both modules make up an extension (for example the tag plugin and the tag application). Although this might seem like there are a lot of repositories, IMO it's a lot better since: - it's not possible to checkout just one subdirectory from a repository, as can be done in subversion; with only one big repo with all the extensions in it, people wanting to fork an extension to patch it would also have to fork unrelated and unused/deprecated extensions like the selenium application - each extension has its own lifecycle, while tagging/branching is done per repository; it wouldn't look nice to have one repository with a thousand different tags, each one actually relevant to only one of the extensions - putting all the extensions together is easy with a parent repository including all the extensions as submodules (similar to svn externals), so it will still be easy to have all the extensions checked out == More setup work needed There's still some work left to do after all the repositories are in place: - Make parent poms for the extensions made of plugin+app - Finish setting up the aggregation repositories by adding the recently migrated submodules and writing parent poms - Update all the poms with the new scm information - Update dev:Community.SourceRepository and related pages - Send an announcement ---------------- I hope that this should all be done by Monday morning - Configure Jenkins with the new repositories - Configure all the GitHub repositories: -- remove the wiki and issue tracker offered by github -- enable the mail notifications -- add descriptions and homepage URLs for all repositories - Swallow the delay introduced by learning the new tools :( Later steps: - See how to write notification emails with the diff in them - Add README files in each repository, to be displayed on the github page - Decide what to do with contrib == Ideas for Contrib We should migrate contrib as well to github, either under the xwiki organization, or under a related xwiki-contrib organization. I don't have a strong opinion about this choice. - Keeping them together seems like the right thing to do, since they are all related to XWiki -- it's easy to find incubating or retired projects -- it's possible to give rights to users only on some repositories, so there's no technical reason not to do it - Keeping them separate makes sense since: -- we mention that contrib projects don't have to be that closely related to XWiki, so contrib could host personal projects not related to the main goal of the XWiki projects -- it could dilute the focus on the main projects by polluting the organization dashboard Thinking more about it, I think the contrib as it is right now doesn't make sense as a whole: - /people/ shouldn't be at all under the xwiki organization, since each committer can have their own repositories on github now - /sandbox/ projects could go under their maintainer's repository - /retired/ and small /projects/ could be repositories under either the xwiki or the xwiki-contrib organization - big /projects/ (wiki30 and concerto) could go under their own organizations, since they aren't 100% XWiki and they have different committers, goals, lifecycles As per granularity, IMO one repository per module is again the right approach; GitHub was designed with many repositories in mind, we don't have to keep their number to a minimum. == Git help I'll be available on IRC to answer questions. Git has good documentation, many tutorials, and I think it has good and intuitive support in all modern IDEs (I'm a console user myself). -- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
