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:
Thanks,
Fabio
On Sat, Apr 2, 2011 at 5:34 PM, Sergiu Dumitriu <sergiu(a)xwiki.com> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs