On Wed, Feb 13, 2013 at 9:36 AM, Bruno Dilly <bdi...@profusion.mobi> wrote: > On Mon, Feb 11, 2013 at 2:07 PM, Daniel Willmann <d.willm...@samsung.com> > wrote: >> Hello, >> >> beware, the switch to Git will be happening soon! We will migrate efl, >> elementary and enlightenment one-by-one and send mails with specific >> details when each will happen. >> >> For the time when we are using Git here is a really small list of what >> you need to change: >> >> First setup Git as it will need to know your name and email (global here >> means per-user) >> $ git config --global user.name "Jane Doe" >> $ git config --global user.email "jane...@example.com" >> >> Useful commands: >> To get the repository, run >> $ git clone ssh://g...@phab.enlightenment.org/<reponame> >> -> (svn checkout) >> The names will be announced as we switch - the first ones will most >> likely be core/efl.git, core/elementary.git and core/enlightenment.git >> >> To update to the newest version >> $ git pull --rebase >> -> (svn update) >> >> To commit all local changes >> $ git commit -a >> $ git push >> -> (svn ci) >> OR (better) if you just want to commit specific files >> $ git add <files> >> $ git commit >> $ git push >> -> (svn ci <files>) >> >> Here's more Git for SVN users: >> http://git-scm.com/course/svn.html >> >> >> If you want to know more I recommend reading (part of) the Git book at >> http://git-scm.com/book >> I even recommend reading it if you don't want to know more. >> A sneak peek of the awesomeness that awaits you at the other side of >> that link: >> >> # Enable color in diffs, etc. (should be default by now) >> $ git config --global color.ui true >> >> # Change your editor if you don't like what $EDITOR points to >> $ git config --global core.editor vim >> >> # Configure shortcuts for commands >> $ git config --global alias.ci commit >> >> >> >> These were the very basics of how to work with Git on a technical level. >> In the following paragraphs I want to introduce some common work flows >> that I think are useful to adopt. If you don't understand it all - >> that's okay. It's not a MUST. But please feel free to ask if anything is >> unclear. >> >> Structure of the repositories >> ----------------------------- >> >> Official: >> These branches will be fast-forward only (you cannot rewrite >> history/commits that have been published to the server). This is what >> people expect from official branches and the same behaviour as with SVN. >> Once commits are made you cannot "uncommit" something - only revert. >> >> * "master" is what trunk used to be. All official development happens >> there. >> * For a stabilization branch we will have "<packagename>-<version>" >> branching off of master. This is analog to the way SVN branches were >> used in the past. An example would be "elementary-1.7" >> * Git tags will mark the exact commit that was used for a release. As >> such these commits will usually reside within the release branches or >> be the starting point for one. Tags will follow the naming scheme >> v<version>, so for example "v1.7.5". >> >> Topic branches: >> * In each repository every developer with commit access will be able to >> push/update branches in their own namespace (devs/<name>/*). These >> branches will allow non-fastforward updates and no one should expect >> these to be stable. >> * This is a testing ground for developers where new features can be >> developed, debugged and shared with fellow developers. Ideally any new >> feature would live in its own branch until it matures and is merged >> into master. > > It's a nice proposal, but what about master branch permissions ? > Every developer would be allowed to push stuff on there (with a flow > similar to svn) ? Or we'll try to establish some kind of policy about > it (maintainers, review, etc) ?
We did have some discussion and sharing idea about that during fosdem. The consensus is that we were not ready as a group of developers to move to that kind of organisation. Instead something that maybe would fit us more is a release cycle and development process based on time. 1 week of feature addition 2 week of bug fixing This cycle would be repeated 3 times, then followed by : a release candidate 2 additional weeks of stabilization (maybe another RC) a beta 1 additional week of polishing release (if everything is good of course) Of course we don't start a feature addition cycle if current master branch is unstable. The hope is to be on a more rapid development cycle, but still stable and avoiding glacial era like we have before each release. Finally it should give us a good release every 3 months. It should not change our workflow to much and still be an improvement over our current model. Any though or improvement about it ? Or a better proposal ? -- Cedric BAIL ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel