On 04/04/2011 09:31 AM, Vincent Massol wrote: > 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
OK. > 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 ;) No more lost commits, I've done all the imports. >>> 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. Done already, everything is 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 > > 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. Yes, I thought that as well, so I split them this morning. Now skins are under xwiki-extensions, as proposed on http://xwiki.markmail.org/thread/k6hb7v63igrbtxiy > Note that we've put common tools in xwiki-commons too so it makes sense to > keep platform related tools in platform. Yes, I put them under xwiki-platform, which now contains: - components, the old platform/core - web, the old platform/web, but should be split into GWT and standard - tools, the old platform/xwiki-tools >> 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 ^ Working on it right now. >> - Finish setting up the aggregation repositories by adding the recently >> migrated submodules and writing parent poms ^ Done. >> - 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). I did it this morning. >> -- 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). I've been working on a guide, based on my older guide for git usage, currently at http://incubator.myxwiki.org/xwiki/bin/Main/UsingGitHub but I'll move it to documentation drafts after I finish a first pass on it to remove all references to svn. -- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
