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

Reply via email to