4 Apr
2011
4 Apr
'11
9:31 a.m.
Hi Sergiu,
On Apr 2, 2011, at 5:34 PM, Sergiu Dumitriu wrote:
+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.
On 04/01/2011 09:09 PM, Vincent Massol 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).
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
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