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 > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
