Hi Sergiu, On Apr 2, 2011, at 5:34 PM, Sergiu Dumitriu wrote:
> 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'd make it readonly FTM till we sort out what we want to do with our tools that use it: - ohloh - svnsearch - jira/svn integration - etc After this interim period I'm +1 to hide or remove it (backup it first). >> * 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? +1 for a nicer notif mail that the default one. >> * 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 hope you're not going to remove my new commits from now on ;) >> 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. Cool. > == 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 ok. I think they should be split only if they have independent release cycles which isn't the case now so +1 to keep them together until that changes. > - platform/skin and platform/xwiki-tools are also in one repository > each, although I'd like to split them into individual repositories > sometime later +1 to split skins since they already have independent release cycles. For tools I think they should have the same release cycle as platform/core and platform/web and thus stay where they are. Note that we've put common tools in xwiki-commons too so it makes sense to keep platform related tools in platform. > 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 +1 for what you've done. > == 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 this is done > -- enable the mail notifications I can do that (I'm in the train now but when I reach home). > -- add descriptions and homepage URLs for all repositories > - Swallow the delay introduced by learning the new tools :( More things to do: - configure new locations in ohloh (I've seen that it supports Git repos) - I can do that - check if sonar supports Git and ask the sonar guys to update the XWiki view on nemo - I can do that - update the Release Process page on xwiki.org - make the svn repo read only (minimum) - This is the first step to do (should have been done earlier to prevent committers from committing in them). - since a lot of us are learning Git I'd suggest doing a git clone of all repos on a server machine with a crontab to do git pull in order to keep a backup in case we need to restore something. > 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 -- we don't control the quality of contrib repositories and they're not done by the xwiki dev team and there's no easy way to make that clear for users I think (a README maybe but I don't think that's enough). > 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 Exactly > - /sandbox/ projects could go under their maintainer's repository Sounds good since it's now easy to fork. > - /retired/ and small /projects/ could be repositories under either the > xwiki or the xwiki-contrib organization +1 to move back retired stuff from the xwiki dev team into the xwiki org in a retired repo. +1 to move the rest in the xwiki-contrib org > - big /projects/ (wiki30 and concerto) could go under their own > organizations, since they aren't 100% XWiki and they have different > committers, goals, lifecycles Either that or they use xwiki-contrib org, their choice I'd say. > 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. +1 > == 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). Thanks -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
