Hello -- I am interested in working on the Event Calendar Application for the XWiki. I have being doing something similar with CakePHP / PHP and ASP.NET MVC 3 /

Please let me know how I can be helpful in creating this application. A short startup exercise will be much appreciated to get familiar with the project.

On 04/01/2011 09:09 PM, Vincent Massol wrote: No SVN commits from now on for the XE/XEM related repositories. I didn't move the following projects: - xoffice - xeclipse - curriki - contrib Yes. Right now. 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. 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? 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. 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 devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

Hi Sergiu, On Apr 2, 2011, at 5:34 PM, Sergiu Dumitriu wrote: 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). +1 for a nicer notif mail that the default one. ok hope you're not going to remove my new commits from now on ;)

Cool.

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. +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.

+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

this is done I can do that (I'm in the train now but when I reach home).

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. -- 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). Exactly Sounds good since it's now easy to fork. +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 Either that or they use xwiki-contrib org, their choice I'd say. +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).