[xwiki-devs] Git Migration - What's the plan?
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? * Can we commit in the git repos created on github right now? If not when? * Are we going to continue having the git repos synced with the svn repo and if so for how long? * 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? * 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? Ok enough question to get started. Thanks -Vincent
On Apr 1, 2011, at 9: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? * Can we commit in the git repos created on github right now? If not when? * Are we going to continue having the git repos synced with the svn repo and if so for how long? * 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?
I've found how to do it. I'm starting to set them up.
* 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?
* We should remove Wiki and Issues in github for all repos. Thanks -Vincent
Ok enough question to get started.
Thanks -Vincent
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/
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 / C#. 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. Thank you. Sincerely, Michael Aro Student, IT-4 VAMK, UAS
On 04/03/2011 12:45 PM, Michael wrote:
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 / C#.
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.
http://platform.xwiki.org/xwiki/bin/DevGuide/FAQTutorial You can find more details at: http://platform.xwiki.org/xwiki/bin/DevGuide/ http://dev.xwiki.org/xwiki/bin/Community/ -- Sergiu Dumitriu http://purl.org/net/sergiu/
Sergiu Dumitriu -- Do you mean I should create an FAQ app or just get familiar with the XWiki? Michael Aro Student, IT-4 VAMK, UAS ________________________________ From: Sergiu Dumitriu <[email protected]> To: XWiki Developers <[email protected]> Sent: Sun, April 3, 2011 2:16:57 PM Subject: Re: [xwiki-devs] [GSoC-2011] Calendar Application On 04/03/2011 12:45 PM, Michael wrote:
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 / C#.
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.
http://platform.xwiki.org/xwiki/bin/DevGuide/FAQTutorial You can find more details at: http://platform.xwiki.org/xwiki/bin/DevGuide/ http://dev.xwiki.org/xwiki/bin/Community/ -- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Tue, Apr 5, 2011 at 16:40, Michael <[email protected]> wrote:
Sergiu Dumitriu -- Do you mean I should create an FAQ app or just get familiar with the XWiki?
get familiar with XWiki by playing with the tutorial and documentation. Thanks, Caty
Michael Aro Student, IT-4 VAMK, UAS
________________________________ From: Sergiu Dumitriu <[email protected]> To: XWiki Developers <[email protected]> Sent: Sun, April 3, 2011 2:16:57 PM Subject: Re: [xwiki-devs] [GSoC-2011] Calendar Application
On 04/03/2011 12:45 PM, Michael wrote:
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 / C#.
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.
http://platform.xwiki.org/xwiki/bin/DevGuide/FAQTutorial
You can find more details at: http://platform.xwiki.org/xwiki/bin/DevGuide/ http://dev.xwiki.org/xwiki/bin/Community/
-- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi, this is proabably not related to the previous mail, but I just wanted to mention this interesting article about a "successful branching model with Git". Maybe you have already heard of this but nevertheless I think it's worth to send it here: http://nvie.com/posts/a-successful-git-branching-model/ Thanks, Fabio On Sat, Apr 2, 2011 at 5:34 PM, Sergiu Dumitriu <[email protected]> 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'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
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
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/
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/
participants (5)
-
Ecaterina Moraru (Valica) -
Fabio Mancinelli -
Michael -
Sergiu Dumitriu -
Vincent Massol