[VOTE] Branching policy for 1.0

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

[VOTE] Branching policy for 1.0

vmassol
Administrator
Hi,

Sergiu said in an email he wanted to modify the branching policy for  
1.0. So I'm proposing 2 choices and let you vote about them:

Option 1 (current policy):
====================

* Work on trunk till we cut the RC. At that point in time create a  
branch

Pros:
* Simple. Minimal merging from branch to trunk to do.
* No risk of forgetting something (like something is on trunk but not  
in branch where it should be, and no risk of forgetting to merge back  
on trunk something from the branch)

Cons:
* If someone introduces a big instability, we'll need to revert it
* Committers cannot commit something not working on trunk (in any  
case nobody should ever do that)
* If a new feature is committed that impacts other features, it's  
possible that it won't be stable enough. This is especially true as  
we don't have lots of automated tests to discover regression. Note:  
If we had strong automated tests we would never need to create a  
branch (this is how I do it on the Cargo project and I've never had  
any issue).

Option 2:
========

* Create a 1.0 branch right now. All work leading to 1.0 must go to  
that branch. Trunk is for work for 1.1.

Pros:
* People working on 1.1 can do so on trunk
* Less stabilization risk issues

Cons:
* Requires more discipline. People must be careful to commit on the  
right branch/trunk.
* We absolutely need to merge to trunk whenever someone commits to  
the 1.0 branch as otherwise merging is a big pain later on.

Please cast your votes.

I'm +1 for Option 2 but provided all committers agree as it's a  
little bit more work and more importantly requires discipline.

Thanks
-Vincent


       

       
               
___________________________________________________________________________
Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire.
http://fr.mail.yahoo.com



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Branching policy for 1.0

Sergiu Dumitriu
+1 for option 2

On 1/25/07, Vincent Massol <[hidden email]> wrote:
Hi,

Sergiu said in an email he wanted to modify the branching policy for
1.0. So I'm proposing 2 choices and let you vote about them:

Option 1 (current policy):
====================

* Work on trunk till we cut the RC. At that point in time create a
branch

Pros:
* Simple. Minimal merging from branch to trunk to do.
* No risk of forgetting something (like something is on trunk but not
in branch where it should be, and no risk of forgetting to merge back
on trunk something from the branch)

Cons:
* If someone introduces a big instability, we'll need to revert it
* Committers cannot commit something not working on trunk (in any
case nobody should ever do that)
* If a new feature is committed that impacts other features, it's
possible that it won't be stable enough. This is especially true as
we don't have lots of automated tests to discover regression. Note:
If we had strong automated tests we would never need to create a
branch (this is how I do it on the Cargo project and I've never had
any issue).

Option 2:
========

* Create a 1.0 branch right now. All work leading to 1.0 must go to
that branch. Trunk is for work for 1.1.

Pros:
* People working on 1.1 can do so on trunk
* Less stabilization risk issues

Cons:
* Requires more discipline. People must be careful to commit on the
right branch/trunk.
* We absolutely need to merge to trunk whenever someone commits to
the 1.0 branch as otherwise merging is a big pain later on.

Please cast your votes.

I'm +1 for Option 2 but provided all committers agree as it's a
little bit more work and more importantly requires discipline.

Thanks
-Vincent






___________________________________________________________________________
Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire.
http://fr.mail.yahoo.com




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws





--
http://purl.org/net/sergiu

--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Branching policy for 1.0

Marta Girdea
In reply to this post by vmassol
+1 for the second option

On 1/25/07, Vincent Massol <[hidden email]> wrote:

> Hi,
>
> Sergiu said in an email he wanted to modify the branching policy for
> 1.0. So I'm proposing 2 choices and let you vote about them:
>
> Option 1 (current policy):
> ====================
>
> * Work on trunk till we cut the RC. At that point in time create a
> branch
>
> Pros:
> * Simple. Minimal merging from branch to trunk to do.
> * No risk of forgetting something (like something is on trunk but not
> in branch where it should be, and no risk of forgetting to merge back
> on trunk something from the branch)
>
> Cons:
> * If someone introduces a big instability, we'll need to revert it
> * Committers cannot commit something not working on trunk (in any
> case nobody should ever do that)
> * If a new feature is committed that impacts other features, it's
> possible that it won't be stable enough. This is especially true as
> we don't have lots of automated tests to discover regression. Note:
> If we had strong automated tests we would never need to create a
> branch (this is how I do it on the Cargo project and I've never had
> any issue).
>
> Option 2:
> ========
>
> * Create a 1.0 branch right now. All work leading to 1.0 must go to
> that branch. Trunk is for work for 1.1.
>
> Pros:
> * People working on 1.1 can do so on trunk
> * Less stabilization risk issues
>
> Cons:
> * Requires more discipline. People must be careful to commit on the
> right branch/trunk.
> * We absolutely need to merge to trunk whenever someone commits to
> the 1.0 branch as otherwise merging is a big pain later on.
>
> Please cast your votes.
>
> I'm +1 for Option 2 but provided all committers agree as it's a
> little bit more work and more importantly requires discipline.
>
> Thanks
> -Vincent
>
>
>
>
>
>
> ___________________________________________________________________________
> Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire.
> http://fr.mail.yahoo.com
>
>
>
>
> --
> You receive this message as a subscriber of the [hidden email] mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
>
>
>


--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Branching policy for 1.0

Sébastien Gaïde
In reply to this post by vmassol
+1 for option 2

S.



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Branching policy for 1.0

Phung Nam
In reply to this post by vmassol
Hi Vincent !

I'm +1 for the second option

Best regards !
- Phung Nam.

On 1/25/07, Vincent Massol <[hidden email]> wrote:
Hi,

Sergiu said in an email he wanted to modify the branching policy for
1.0. So I'm proposing 2 choices and let you vote about them:

Option 1 (current policy):
====================

* Work on trunk till we cut the RC. At that point in time create a
branch

Pros:
* Simple. Minimal merging from branch to trunk to do.
* No risk of forgetting something (like something is on trunk but not
in branch where it should be, and no risk of forgetting to merge back
on trunk something from the branch)

Cons:
* If someone introduces a big instability, we'll need to revert it
* Committers cannot commit something not working on trunk (in any
case nobody should ever do that)
* If a new feature is committed that impacts other features, it's
possible that it won't be stable enough. This is especially true as
we don't have lots of automated tests to discover regression. Note:
If we had strong automated tests we would never need to create a
branch (this is how I do it on the Cargo project and I've never had
any issue).

Option 2:
========

* Create a 1.0 branch right now. All work leading to 1.0 must go to
that branch. Trunk is for work for 1.1.

Pros:
* People working on 1.1 can do so on trunk
* Less stabilization risk issues

Cons:
* Requires more discipline. People must be careful to commit on the
right branch/trunk.
* We absolutely need to merge to trunk whenever someone commits to
the 1.0 branch as otherwise merging is a big pain later on.

Please cast your votes.

I'm +1 for Option 2 but provided all committers agree as it's a
little bit more work and more importantly requires discipline.

Thanks
-Vincent






___________________________________________________________________________
Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire.
http://fr.mail.yahoo.com




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws





--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Branching policy for 1.0

Ludovic Dubost
In reply to this post by vmassol

+1

In this scenario we would put Curriki at least on the 1.0 branch. I was
even thinking creating a Curriki branch.
We want a high level of stability on what we get from XWiki in the
Curriki project.

This scenario requires a lot of discipline to not forget to merge 1.0
code into the trunk or vice-versa.

Could we get from those who know best some efficient ways to merge code
from the branch to the trunk and vice-versa. Everytime I do some merges
I'm not sure about what I'm doing.

Ludovic

Vincent Massol a écrit :

> Hi,
>
> Sergiu said in an email he wanted to modify the branching policy for
> 1.0. So I'm proposing 2 choices and let you vote about them:
>
> Option 1 (current policy):
> ====================
>
> * Work on trunk till we cut the RC. At that point in time create a branch
>
> Pros:
> * Simple. Minimal merging from branch to trunk to do.
> * No risk of forgetting something (like something is on trunk but not
> in branch where it should be, and no risk of forgetting to merge back
> on trunk something from the branch)
>
> Cons:
> * If someone introduces a big instability, we'll need to revert it
> * Committers cannot commit something not working on trunk (in any case
> nobody should ever do that)
> * If a new feature is committed that impacts other features, it's
> possible that it won't be stable enough. This is especially true as we
> don't have lots of automated tests to discover regression. Note: If we
> had strong automated tests we would never need to create a branch
> (this is how I do it on the Cargo project and I've never had any issue).
>
> Option 2:
> ========
>
> * Create a 1.0 branch right now. All work leading to 1.0 must go to
> that branch. Trunk is for work for 1.1.
>
> Pros:
> * People working on 1.1 can do so on trunk
> * Less stabilization risk issues
>
> Cons:
> * Requires more discipline. People must be careful to commit on the
> right branch/trunk.
> * We absolutely need to merge to trunk whenever someone commits to the
> 1.0 branch as otherwise merging is a big pain later on.
>
> Please cast your votes.
>
> I'm +1 for Option 2 but provided all committers agree as it's a little
> bit more work and more importantly requires discipline.
>
> Thanks
> -Vincent
>
>
>    
>
>    
>        
> ___________________________________________________________________________Yahoo!
> Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son
> interface révolutionnaire.
> http://fr.mail.yahoo.com
>
> ------------------------------------------------------------------------
>
>
> --
> You receive this message as a subscriber of the [hidden email] mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
>  

--
Ludovic Dubost
Blog: http://www.ludovic.org/blog/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
AIM: nvludo Yahoo: ludovic




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Branching policy for 1.0

Jean-Vincent Drean
+1 for the second option.

2007/1/26, Ludovic Dubost <[hidden email]>:
>
> Could we get from those who know best some efficient ways to merge code
> from the branch to the trunk and vice-versa. Everytime I do some merges
> I'm not sure about what I'm doing.
>

+1

Merges are always painful for me :)

JV.



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Branching policy for 1.0 (SUMMAY)

vmassol
Administrator
In reply to this post by vmassol
Result: 7 +1

- Sergiu
- Marta
- Sebastien
- Nam
- Ludovic
- Jean-Vincent

This vote is passed and I'll create the 1.0 branch tomorrow.

Make sure you all:
-  switch to the 1.0 branch for 1.0 development
- use the trunk for 1.1 development
- Merge *immediately* on the trunk when you make a change on the 1.0  
branch

Thanks
-Vincent

On Jan 25, 2007, at 10:15 AM, Vincent Massol wrote:

> Hi,
>
> Sergiu said in an email he wanted to modify the branching policy  
> for 1.0. So I'm proposing 2 choices and let you vote about them:
>
> Option 1 (current policy):
> ====================
>
> * Work on trunk till we cut the RC. At that point in time create a  
> branch
>
> Pros:
> * Simple. Minimal merging from branch to trunk to do.
> * No risk of forgetting something (like something is on trunk but  
> not in branch where it should be, and no risk of forgetting to  
> merge back on trunk something from the branch)
>
> Cons:
> * If someone introduces a big instability, we'll need to revert it
> * Committers cannot commit something not working on trunk (in any  
> case nobody should ever do that)
> * If a new feature is committed that impacts other features, it's  
> possible that it won't be stable enough. This is especially true as  
> we don't have lots of automated tests to discover regression. Note:  
> If we had strong automated tests we would never need to create a  
> branch (this is how I do it on the Cargo project and I've never had  
> any issue).
>
> Option 2:
> ========
>
> * Create a 1.0 branch right now. All work leading to 1.0 must go to  
> that branch. Trunk is for work for 1.1.
>
> Pros:
> * People working on 1.1 can do so on trunk
> * Less stabilization risk issues
>
> Cons:
> * Requires more discipline. People must be careful to commit on the  
> right branch/trunk.
> * We absolutely need to merge to trunk whenever someone commits to  
> the 1.0 branch as otherwise merging is a big pain later on.
>
> Please cast your votes.
>
> I'm +1 for Option 2 but provided all committers agree as it's a  
> little bit more work and more importantly requires discipline.
>
> Thanks
> -Vincent
>
>
>
>
>
>
> ______________________________________________________________________
> _____Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo!  
> Mail et son interface révolutionnaire.
> http://fr.mail.yahoo.com
>
>
> --
> You receive this message as a subscriber of the xwiki-
> [hidden email] mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/ 
> wws





___________________________________________________________________________
Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire.
http://fr.mail.yahoo.com



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Branching policy for 1.0 (SUMMAY)

vmassol
Administrator

On Jan 31, 2007, at 8:46 PM, Vincent Massol wrote:

> Result: 7 +1
>
> - Sergiu
> - Marta
> - Sebastien
> - Nam
> - Ludovic
> - Jean-Vincent
>
> This vote is passed and I'll create the 1.0 branch tomorrow.
Done.

-Vincent

>
> Make sure you all:
> -  switch to the 1.0 branch for 1.0 development
> - use the trunk for 1.1 development
> - Merge *immediately* on the trunk when you make a change on the  
> 1.0 branch
>
> Thanks
> -Vincent
>
> On Jan 25, 2007, at 10:15 AM, Vincent Massol wrote:
>
>> Hi,
>>
>> Sergiu said in an email he wanted to modify the branching policy  
>> for 1.0. So I'm proposing 2 choices and let you vote about them:
>>
>> Option 1 (current policy):
>> ====================
>>
>> * Work on trunk till we cut the RC. At that point in time create a  
>> branch
>>
>> Pros:
>> * Simple. Minimal merging from branch to trunk to do.
>> * No risk of forgetting something (like something is on trunk but  
>> not in branch where it should be, and no risk of forgetting to  
>> merge back on trunk something from the branch)
>>
>> Cons:
>> * If someone introduces a big instability, we'll need to revert it
>> * Committers cannot commit something not working on trunk (in any  
>> case nobody should ever do that)
>> * If a new feature is committed that impacts other features, it's  
>> possible that it won't be stable enough. This is especially true  
>> as we don't have lots of automated tests to discover regression.  
>> Note: If we had strong automated tests we would never need to  
>> create a branch (this is how I do it on the Cargo project and I've  
>> never had any issue).
>>
>> Option 2:
>> ========
>>
>> * Create a 1.0 branch right now. All work leading to 1.0 must go  
>> to that branch. Trunk is for work for 1.1.
>>
>> Pros:
>> * People working on 1.1 can do so on trunk
>> * Less stabilization risk issues
>>
>> Cons:
>> * Requires more discipline. People must be careful to commit on  
>> the right branch/trunk.
>> * We absolutely need to merge to trunk whenever someone commits to  
>> the 1.0 branch as otherwise merging is a big pain later on.
>>
>> Please cast your votes.
>>
>> I'm +1 for Option 2 but provided all committers agree as it's a  
>> little bit more work and more importantly requires discipline.
>>
>> Thanks
>> -Vincent
>>
>>
>>
>>
>>
>>
>> _____________________________________________________________________
>> ______Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo!  
>> Mail et son interface révolutionnaire.
>> http://fr.mail.yahoo.com
>>
>>
>> --
>> You receive this message as a subscriber of the xwiki-
>> [hidden email] mailing list.
>> To unsubscribe: mailto:[hidden email]
>> For general help: mailto:[hidden email]?subject=help
>> ObjectWeb mailing lists service home page: http://
>> www.objectweb.org/wws
>
>
>
>
>
>
> ______________________________________________________________________
> _____
> Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et  
> son interface révolutionnaire.
> http://fr.mail.yahoo.com
>
>
> --
> You receive this message as a subscriber of the xwiki-
> [hidden email] mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/ 
> wws





___________________________________________________________________________
Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire.
http://fr.mail.yahoo.com



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Branching policy for 1.0

vmassol
Administrator
In reply to this post by Jean-Vincent Drean
On 1/26/07, Jean-Vincent Drean <[hidden email]> wrote:

> +1 for the second option.
>
> 2007/1/26, Ludovic Dubost <[hidden email]>:
> >
> > Could we get from those who know best some efficient ways to merge code
> > from the branch to the trunk and vice-versa. Everytime I do some merges
> > I'm not sure about what I'm doing.
> >
>
> +1
>
> Merges are always painful for me :)
Merges are always painful for everyone. This is why I'm always
advocating not doing them... (which is what I do on all my projects -
Here we are currently not good enough in term of automated tests and
quality in general to do this).

Here's how to do it with the svn command line client:

svn merge --revision 2021:2028
svn+ssh://[hidden email]/svnroot/xwiki/xwiki/trunk
XWIKI_1_0

Note: This will merge revisions 2022 to 2028 included. You must always
specify a revision *before* the one you wish to merge

This command was applied in trunk. If you wish to merge from 1.0 to
trunk the go in 1.0 and merge to trunk.

If you're using a different svn client then it all depends on your client...

Hope it helps,
-Vincent



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws