Projets Source Code Management Interest Group


What's up doc?


Putting more files in the blessed repository

We are committed to expose all source files to the community

After a discussion with Alexis today it appears that Github repositories won't be able, alone, to provide yacs archives useful to new installations or to upgrades.

On the other hand, I have on my hard drive a number of source files that should be shared openly to allow for easy change.

As a result, all intermediate files that support internationalization of yacs have been added to the repository. This means that any translator can get direct access to a .po file used in one version of yacs, change it with poEdit if necessary, and submit a pull request to yacs/yacs.

The improvement in yacs internationalization and translation is obvious. Before using github, changes were submitted in a forum at, and I had to change .po files on my computer. Nowadays, any person able to use poEdit can do the change by himself. And since they are three integrators, the probability that the integration is delayed is reduced.

In the future we may add more files to the blessed repository, such as unitary test files for example.

Also, we will have to adapt the process that produces ready-to-use archives of yacs. But that's another story.


Collaborative development models on githubs


Quick note


There are two popular models of collaborative development on GitHub:

  1. The Fork + Pull Model lets anyone fork an existing repository and push changes to their personal fork without requiring access be granted to the source repository. The changes must then be pulled into the source repository by the project maintainer. This model reduces the amount of friction for new contributors and is popular with open source projects because it allows people to work independently without upfront coordination.

  2. The Shared Repository Model is more prevalent with small teams and organizations collaborating on private projects. Everyone is granted push access to a single shared repository and topic branches are used to isolate changes.

Pull requests are especially useful in the Fork + Pull Model because they provide a way to notify project maintainers about changes in your fork. However, they're also useful in the Shared Repository Model where they're used to initiate code review and general discussion about a set of changes before being merged into a mainline branch.


proposition for yacs on github

  • any contibutors could use the Fork+pull request model.
  • Only trusted maintainers could merge the request into yacs repository.
  • for normal purpose, maintainers use also the fork + pull request model. The job is merged by a fellow.
  • for emergency purpose, maintainers could commit directly into yacs repo.

Github features

while using pull-request github offer nice code-reviewing feature. see link below

[decorated]Sending a pull request :[/decorated]



Created yacs/yacs repository

  • I created the yacs acount with yacs repository, for testing purpose, and maybe it will become the official repository for yacs on github.

  • I added Bernard (bernard357), Christophe (cbattarel) and myself (rair) as collaborator on this project. So we are able to commit in this repository
  • but the administration of this project must be done with yacs account (like adding new collaborators). This account could be shared by trusted members.


  • to contribute, everyone can register on github, and fork the project by pressing one button.
  • that will be I think the way we will contribute : Bernard, Christophe and I, will fork the yacs/yacs project, and put our public works on yacs in ours own repositories, available for test.
  • After being tested and reviewed, jobs would be integrated in the official repo.

master branch

  • I created the master branch by importing existing svn google code repo. Not by direct import on github interface, but first by fetching localy svn repo with git-svn, then pushing it to github.
  • I tagged 3 versions v10.7.11, v10.5.27, v9.8.31, so they are available for download. We could tag older version if needed.

other branches

  • I think we need to import yacs martin branch as maintenance branch.

other test

  • i have to test the "fork" feature, and the pull procedure.

proposal of a policy for managing yacs sources with git

where to host ?

what branches ?

what workflow ?



Choosing a workflow

there are differents way to collaborate with GIT. We have to choose one.



First steps with git, through tutorials

After installing GIT (on a linux machine) i tried a bit of it.

A good place to start is

you find there a tutorial easy to understand. I've done it until collaboration steps.

it's great, GIT can help to manage version even for one person, localy. It's very fast to branch and merge.


Where should we host our software repository?

Some requirements:

- ensure that the community has full control on stored content

- be entirely based on open-source software

- prefer open hosting over closed hosting, if possible

- technology should allow the community to host its own repository in the future

- ensure consistent usage across various operating systems (namely, Windows, Mac OSX and Linux)

- be provided at no cost for the community


What else?


Why should we move from SVN to Git?

There are at least four reasons to use Git:

- Linus Torwald recommends to do it in a famous Google Talk video

- We have decided to branch development of yacs, and experts says that merging is painful with SVN

- We want powerful developers to benefit from powerful tools to manage code at their powerful computers

- We want to embrace parallel development on a large scale, instead of discussing "who is allowed to commit?"


Maybe you would like to add your own reason for using Git instead of SVN or CVS?


Why do we speak English in this group?

The core team that initiated the yacs project some time ago is massively speaking French, and French is still the most used language within the yacs community.

However, when it comes to software development the common language between developers is English.

More specifically, most common tools and best practices related to source code management are coming either from U.K. or from U.S.A. That's a fact!

Let's grant it, and open the game to all talented developers that are ready to contribute to the yacs project, at last to the working grooup devoted to source code management.


What is source code management, and what is the challenge?

This public group is aiming to synchronize people interested into the management of yacs reference code.

At the moment yacs is distributed mainly through archive downloads, and contributions are made by uploading files to web pages at

These mechanisms have proven quite efficient to spread the software to end users.

However, downloads and uploads are painful to most software developers, and we have to facilitate collaboration across contributors.

Some challenges that this group is aiming to address:

- provide early access to on-going changes (to not wait until final release),

- facilite the integration of small patches or changes (from almost any community member)

- enable parallel developments and forks (this is open source, and anybody should be able to get the full software)

- allow easy merge and integration of developments from various developers

- scale to a large number of contributors if required

- guarantee the availability of the code over time (independance is an important criteria)

- adopt modern and efficient best practices on code management

- train and coach developers coming to the yacs project on code management


Any community member may participate to this group, either through the discussion board, or by contributing to the wiki pages, etc.