On 04/04/2011 10:50 AM, Sergiu Dumitriu wrote: > 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).
I forgot to say that I've already did something like this by removing the XWikiCommitters groups from the migrated projects. In theory, commits shouldn't be possible anymore, but I haven't checked. >> - 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
