On Wed, Feb 13, 2013 at 12:18 AM, Cedric BAIL <cedric.b...@free.fr> wrote: > 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 ?
It sounds good. Let's try it =) > -- > 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 -- Bruno Dilly Lead Developer ProFUSION embedded systems http://profusion.mobi ------------------------------------------------------------------------------ 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
