[PROPOSAL] Managing branches for future releases

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[PROPOSAL] Managing branches for future releases

Andrea Pescetti-2
I'm starting a short series of occasional posts to capture the current
collective state of mind on the next release. I'll float them here for
refinement or lazy consensus, and then we may want to reuse this text in
wiki or blog posts to avoid repeating the same concepts over and over.

Let's start with branches.

We all wish 4.1.4 to be the last 4.1.x release.

We currently have an AOO415 branch at
http://svn.apache.org/viewvc/openoffice/branches/AOO415/ ; this branch
is a copy of AOO414 (that resulted in OpenOffice 4.1.4). The AOO415
branch will result in a release ONLY if we have some important bug fixes
to release and trunk is not ready yet. No new features, even small
enhancements, are added to it. No commits to AOO415 happen without
appropriate mailing list discussions (dev or security, depending on cases).

Trunk is where all development happens. It will be branched for a new
release (like, an AOO420 branch - name still provisional) when the code
is mature: beta or even RC. Until then, we simply keep working on trunk
as we are doing now.

In case we need to commit to a branch, any changes are still committed
to trunk first and then merged to branches using SVN merge in all
situations when this is possible (i.e., when there are no merge
conflicts). The mergeinfo for AOO414 and AOO415 isn't clear, so we'll
have to make sure that trunk contains all fixes done there (or
equivalent in case of conflicts) and, done that, we commit to AOO415
only if:
1. The fix is important and agreed upon on the relevant list
2. The commit is done with "svn merge" starting from a trunk commit

This will ensure that we can shift the focus to trunk while still
keeping a branch that remains ready for a quick release if needed. If we
are never in this situation, the next release will be from the current
trunk and AOO415 will never result in a release.

Regards,
   Andrea.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Managing branches for future releases

Kay Schenk-2

On 10/24/2017 01:25 PM, Andrea Pescetti wrote:

> I'm starting a short series of occasional posts to capture the current
> collective state of mind on the next release. I'll float them here for
> refinement or lazy consensus, and then we may want to reuse this text in
> wiki or blog posts to avoid repeating the same concepts over and over.
>
> Let's start with branches.
>
> We all wish 4.1.4 to be the last 4.1.x release.
>
> We currently have an AOO415 branch at
> http://svn.apache.org/viewvc/openoffice/branches/AOO415/ ; this branch
> is a copy of AOO414 (that resulted in OpenOffice 4.1.4). The AOO415
> branch will result in a release ONLY if we have some important bug fixes
> to release and trunk is not ready yet. No new features, even small
> enhancements, are added to it. No commits to AOO415 happen without
> appropriate mailing list discussions (dev or security, depending on cases).
>
> Trunk is where all development happens. It will be branched for a new
> release (like, an AOO420 branch - name still provisional) when the code
> is mature: beta or even RC. Until then, we simply keep working on trunk
> as we are doing now.
>
> In case we need to commit to a branch, any changes are still committed
> to trunk first and then merged to branches using SVN merge in all
> situations when this is possible (i.e., when there are no merge
> conflicts). The mergeinfo for AOO414 and AOO415 isn't clear, so we'll
> have to make sure that trunk contains all fixes done there (or
> equivalent in case of conflicts) and, done that, we commit to AOO415
> only if:
> 1. The fix is important and agreed upon on the relevant list
> 2. The commit is done with "svn merge" starting from a trunk commit
>
> This will ensure that we can shift the focus to trunk while still
> keeping a branch that remains ready for a quick release if needed. If we
> are never in this situation, the next release will be from the current
> trunk and AOO415 will never result in a release.
>
> Regards,
>    Andrea.

Would it be more clear to just remove the AOO415 branch and only
re-instate it if needed (hopefully not). I don't see anything in AOO415
that wasn't included in AOO414.

--
------------------------------------------
MzK

"Only the truth will save you now."
       -- Ensei Tankado, "Digital Fortress"

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Managing branches for future releases

Andrea Pescetti-2
Kay Schenk wrote:
> Would it be more clear to just remove the AOO415 branch and only
> re-instate it if needed (hopefully not).

No, it wouldn't. See https://bz.apache.org/ooo/show_bug.cgi?id=127552 -
there is a series of changes that need to be done for the release number
bump. It's better to have the code ready for it at any moment, so that
we can really just focus on committing the actual fixes and building in
case.

> I don't see anything in AOO415 that wasn't included in AOO414.

Of course. The two are identical right now. The only fixes that will go
into the branch are for the release number updates. Anything else will
go there only after it is fixed in trunk and only after approval on the
relevant list.

And if trunk is fast enough, we will simply remove the AOO415 branch
without releasing anything from it.

Regards,
   Andrea.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Managing branches for future releases

Patricia Shanahan
In reply to this post by Kay Schenk-2


On 10/24/2017 2:34 PM, Kay Schenk wrote:

>
> On 10/24/2017 01:25 PM, Andrea Pescetti wrote:
>> I'm starting a short series of occasional posts to capture the current
>> collective state of mind on the next release. I'll float them here for
>> refinement or lazy consensus, and then we may want to reuse this text
>> in wiki or blog posts to avoid repeating the same concepts over and over.
>>
>> Let's start with branches.
>>
>> We all wish 4.1.4 to be the last 4.1.x release.
>>
>> We currently have an AOO415 branch at
>> http://svn.apache.org/viewvc/openoffice/branches/AOO415/ ; this branch
>> is a copy of AOO414 (that resulted in OpenOffice 4.1.4). The AOO415
>> branch will result in a release ONLY if we have some important bug
>> fixes to release and trunk is not ready yet. No new features, even
>> small enhancements, are added to it. No commits to AOO415 happen
>> without appropriate mailing list discussions (dev or security,
>> depending on cases).
>>
>> Trunk is where all development happens. It will be branched for a new
>> release (like, an AOO420 branch - name still provisional) when the
>> code is mature: beta or even RC. Until then, we simply keep working on
>> trunk as we are doing now.
>>
>> In case we need to commit to a branch, any changes are still committed
>> to trunk first and then merged to branches using SVN merge in all
>> situations when this is possible (i.e., when there are no merge
>> conflicts). The mergeinfo for AOO414 and AOO415 isn't clear, so we'll
>> have to make sure that trunk contains all fixes done there (or
>> equivalent in case of conflicts) and, done that, we commit to AOO415
>> only if:
>> 1. The fix is important and agreed upon on the relevant list
>> 2. The commit is done with "svn merge" starting from a trunk commit
>>
>> This will ensure that we can shift the focus to trunk while still
>> keeping a branch that remains ready for a quick release if needed. If
>> we are never in this situation, the next release will be from the
>> current trunk and AOO415 will never result in a release.
>>
>> Regards,
>>    Andrea.
>
> Would it be more clear to just remove the AOO415 branch and only
> re-instate it if needed (hopefully not). I don't see anything in AOO415
> that wasn't included in AOO414.
>

The decision to keep the 4.1.5 branch around came out of a discussion on
the security mailing list. The potential problem is that someday we may
be faced with a bug for which we need to get a fix out into the field as
soon as possible.

Because of the sheer size of AOO, it takes time to get set up for a
release. The idea is to do as much as we can to prepare without
committing to a release. I have a check-out of AOO415 built. As the
version number changes get incorporated I'll update and rebuild. Not
having to wait for the branch to be prepared, check it out, and do a
full build reduces by about a day the time it would take from knowing a
fix to having it built, tested, and checked in.

I would like to make this an on-going policy. As soon as we ship 4.2.0,
we remove the AOO415 branch but create AOO421, identical except for
version numbers to AOO420, ready in case of an emergency fix.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Managing branches for future releases

Mechtilde Stehmann-2
+1

so we can also show to be ready to fix important bugs in time.

this is also a statement to the community

Regards

Mechtilde

Am 25.10.2017 um 01:00 schrieb Patricia Shanahan:

>
>
> On 10/24/2017 2:34 PM, Kay Schenk wrote:
>>
>> On 10/24/2017 01:25 PM, Andrea Pescetti wrote:
>>> I'm starting a short series of occasional posts to capture the
>>> current collective state of mind on the next release. I'll float them
>>> here for refinement or lazy consensus, and then we may want to reuse
>>> this text in wiki or blog posts to avoid repeating the same concepts
>>> over and over.
>>>
>>> Let's start with branches.
>>>
>>> We all wish 4.1.4 to be the last 4.1.x release.
>>>
>>> We currently have an AOO415 branch at
>>> http://svn.apache.org/viewvc/openoffice/branches/AOO415/ ; this
>>> branch is a copy of AOO414 (that resulted in OpenOffice 4.1.4). The
>>> AOO415 branch will result in a release ONLY if we have some important
>>> bug fixes to release and trunk is not ready yet. No new features,
>>> even small enhancements, are added to it. No commits to AOO415 happen
>>> without appropriate mailing list discussions (dev or security,
>>> depending on cases).
>>>
>>> Trunk is where all development happens. It will be branched for a new
>>> release (like, an AOO420 branch - name still provisional) when the
>>> code is mature: beta or even RC. Until then, we simply keep working
>>> on trunk as we are doing now.
>>>
>>> In case we need to commit to a branch, any changes are still
>>> committed to trunk first and then merged to branches using SVN merge
>>> in all situations when this is possible (i.e., when there are no
>>> merge conflicts). The mergeinfo for AOO414 and AOO415 isn't clear, so
>>> we'll have to make sure that trunk contains all fixes done there (or
>>> equivalent in case of conflicts) and, done that, we commit to AOO415
>>> only if:
>>> 1. The fix is important and agreed upon on the relevant list
>>> 2. The commit is done with "svn merge" starting from a trunk commit
>>>
>>> This will ensure that we can shift the focus to trunk while still
>>> keeping a branch that remains ready for a quick release if needed. If
>>> we are never in this situation, the next release will be from the
>>> current trunk and AOO415 will never result in a release.
>>>
>>> Regards,
>>>    Andrea.
>>
>> Would it be more clear to just remove the AOO415 branch and only
>> re-instate it if needed (hopefully not). I don't see anything in
>> AOO415 that wasn't included in AOO414.
>>
>
> The decision to keep the 4.1.5 branch around came out of a discussion on
> the security mailing list. The potential problem is that someday we may
> be faced with a bug for which we need to get a fix out into the field as
> soon as possible.
>
> Because of the sheer size of AOO, it takes time to get set up for a
> release. The idea is to do as much as we can to prepare without
> committing to a release. I have a check-out of AOO415 built. As the
> version number changes get incorporated I'll update and rebuild. Not
> having to wait for the branch to be prepared, check it out, and do a
> full build reduces by about a day the time it would take from knowing a
> fix to having it built, tested, and checked in.
>
> I would like to make this an on-going policy. As soon as we ship 4.2.0,
> we remove the AOO415 branch but create AOO421, identical except for
> version numbers to AOO420, ready in case of an emergency fix.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
--
Mechtilde Stehmann
## Apache OpenOffice.org
## Freie Office Suite für Linux, MacOSX, Windows
## Debian Developer
## Loook, calender-exchange-provider, libreoffice-canzeley-client
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Managing branches for future releases

Marcus (OOo)
In reply to this post by Patricia Shanahan
Am 25.10.2017 um 01:00 schrieb Patricia Shanahan:

>
> On 10/24/2017 2:34 PM, Kay Schenk wrote:
>>
>> On 10/24/2017 01:25 PM, Andrea Pescetti wrote:
>>> I'm starting a short series of occasional posts to capture the
>>> current collective state of mind on the next release. I'll float them
>>> here for refinement or lazy consensus, and then we may want to reuse
>>> this text in wiki or blog posts to avoid repeating the same concepts
>>> over and over.
>>>
>>> Let's start with branches.
>>>
>>> We all wish 4.1.4 to be the last 4.1.x release.
>>>
>>> We currently have an AOO415 branch at
>>> http://svn.apache.org/viewvc/openoffice/branches/AOO415/ ; this
>>> branch is a copy of AOO414 (that resulted in OpenOffice 4.1.4). The
>>> AOO415 branch will result in a release ONLY if we have some important
>>> bug fixes to release and trunk is not ready yet. No new features,
>>> even small enhancements, are added to it. No commits to AOO415 happen
>>> without appropriate mailing list discussions (dev or security,
>>> depending on cases).
>>>
>>> Trunk is where all development happens. It will be branched for a new
>>> release (like, an AOO420 branch - name still provisional) when the
>>> code is mature: beta or even RC. Until then, we simply keep working
>>> on trunk as we are doing now.
>>>
>>> In case we need to commit to a branch, any changes are still
>>> committed to trunk first and then merged to branches using SVN merge
>>> in all situations when this is possible (i.e., when there are no
>>> merge conflicts). The mergeinfo for AOO414 and AOO415 isn't clear, so
>>> we'll have to make sure that trunk contains all fixes done there (or
>>> equivalent in case of conflicts) and, done that, we commit to AOO415
>>> only if:
>>> 1. The fix is important and agreed upon on the relevant list
>>> 2. The commit is done with "svn merge" starting from a trunk commit
>>>
>>> This will ensure that we can shift the focus to trunk while still
>>> keeping a branch that remains ready for a quick release if needed. If
>>> we are never in this situation, the next release will be from the
>>> current trunk and AOO415 will never result in a release.
>>>
>>> Regards,
>>>    Andrea.
>>
>> Would it be more clear to just remove the AOO415 branch and only
>> re-instate it if needed (hopefully not). I don't see anything in
>> AOO415 that wasn't included in AOO414.
>>
>
> The decision to keep the 4.1.5 branch around came out of a discussion on
> the security mailing list. The potential problem is that someday we may
> be faced with a bug for which we need to get a fix out into the field as
> soon as possible.
>
> Because of the sheer size of AOO, it takes time to get set up for a
> release. The idea is to do as much as we can to prepare without
> committing to a release. I have a check-out of AOO415 built. As the
> version number changes get incorporated I'll update and rebuild. Not
> having to wait for the branch to be prepared, check it out, and do a
> full build reduces by about a day the time it would take from knowing a
> fix to having it built, tested, and checked in.
>
> I would like to make this an on-going policy. As soon as we ship 4.2.0,
> we remove the AOO415 branch but create AOO421, identical except for
> version numbers to AOO420, ready in case of an emergency fix.

+1
This is an good and cheap idea to speed things up.

Marcus


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Managing branches for future releases

Alex Suk
In reply to this post by Andrea Pescetti-2
We all wish for more frequent, more major releases. 4.1.x is just a
number...
No one will report you to the International Software Police if the next
release will be 4.1.5 and have ten times more bug fixes and a dozen new
features :)

On Tue, Oct 24, 2017 at 11:25 PM, Andrea Pescetti <[hidden email]>
wrote:

>
>
> We all wish 4.1.4 to be the last 4.1.x release.
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Managing branches for future releases

Matthias Seidel
In reply to this post by Marcus (OOo)
Am 25.10.2017 um 19:44 schrieb Marcus:

> Am 25.10.2017 um 01:00 schrieb Patricia Shanahan:
>>
>> On 10/24/2017 2:34 PM, Kay Schenk wrote:
>>>
>>> On 10/24/2017 01:25 PM, Andrea Pescetti wrote:
>>>> I'm starting a short series of occasional posts to capture the
>>>> current collective state of mind on the next release. I'll float
>>>> them here for refinement or lazy consensus, and then we may want to
>>>> reuse this text in wiki or blog posts to avoid repeating the same
>>>> concepts over and over.
>>>>
>>>> Let's start with branches.
>>>>
>>>> We all wish 4.1.4 to be the last 4.1.x release.
>>>>
>>>> We currently have an AOO415 branch at
>>>> http://svn.apache.org/viewvc/openoffice/branches/AOO415/ ; this
>>>> branch is a copy of AOO414 (that resulted in OpenOffice 4.1.4). The
>>>> AOO415 branch will result in a release ONLY if we have some
>>>> important bug fixes to release and trunk is not ready yet. No new
>>>> features, even small enhancements, are added to it. No commits to
>>>> AOO415 happen without appropriate mailing list discussions (dev or
>>>> security, depending on cases).
>>>>
>>>> Trunk is where all development happens. It will be branched for a
>>>> new release (like, an AOO420 branch - name still provisional) when
>>>> the code is mature: beta or even RC. Until then, we simply keep
>>>> working on trunk as we are doing now.
>>>>
>>>> In case we need to commit to a branch, any changes are still
>>>> committed to trunk first and then merged to branches using SVN
>>>> merge in all situations when this is possible (i.e., when there are
>>>> no merge conflicts). The mergeinfo for AOO414 and AOO415 isn't
>>>> clear, so we'll have to make sure that trunk contains all fixes
>>>> done there (or equivalent in case of conflicts) and, done that, we
>>>> commit to AOO415 only if:
>>>> 1. The fix is important and agreed upon on the relevant list
>>>> 2. The commit is done with "svn merge" starting from a trunk commit
>>>>
>>>> This will ensure that we can shift the focus to trunk while still
>>>> keeping a branch that remains ready for a quick release if needed.
>>>> If we are never in this situation, the next release will be from
>>>> the current trunk and AOO415 will never result in a release.
>>>>
>>>> Regards,
>>>>    Andrea.
>>>
>>> Would it be more clear to just remove the AOO415 branch and only
>>> re-instate it if needed (hopefully not). I don't see anything in
>>> AOO415 that wasn't included in AOO414.
>>>
>>
>> The decision to keep the 4.1.5 branch around came out of a discussion on
>> the security mailing list. The potential problem is that someday we may
>> be faced with a bug for which we need to get a fix out into the field as
>> soon as possible.
>>
>> Because of the sheer size of AOO, it takes time to get set up for a
>> release. The idea is to do as much as we can to prepare without
>> committing to a release. I have a check-out of AOO415 built. As the
>> version number changes get incorporated I'll update and rebuild. Not
>> having to wait for the branch to be prepared, check it out, and do a
>> full build reduces by about a day the time it would take from knowing a
>> fix to having it built, tested, and checked in.
>>
>> I would like to make this an on-going policy. As soon as we ship 4.2.0,
>> we remove the AOO415 branch but create AOO421, identical except for
>> version numbers to AOO420, ready in case of an emergency fix.
>
> +1
> This is an good and cheap idea to speed things up.
>
> Marcus
To be prepared we should now complete the missing steps to make the 415
branch ready.

I am not sure if only the release manager is allowed to do it?

Matthias

>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>



smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Managing branches for future releases

Peter Kovacs-3
In reply to this post by Marcus (OOo)
Why do you want to branch all the time with names that can change? I think it is an expensive way of getting flexibility. I suggest a more abstract branches.

Why not have 4 permanent branches that are dev/trunc , test, hotfix and Release?

Dev/trunc would contain latest development.
Test would contain the latest release candidate that gets prepared. It bases of from dev and propagates to release.
Hotfix is the one that bases on release and propagates back to release branch.
With this schema you have an abstract way in doing the same thing without the limitation of naming.

We could even post vote result into comments. When propagate version to release. Also we can decide on release name at the latest possible moment.

It would be less confusing especially if we rename a release. (4.2.0 is not final decided. But we may now have branch. Or we wait until we have decided but that would delay the result until we are done with the naming.)



Am 25. Oktober 2017 19:44:39 MESZ schrieb Marcus <[hidden email]>:

>Am 25.10.2017 um 01:00 schrieb Patricia Shanahan:
>>
>> On 10/24/2017 2:34 PM, Kay Schenk wrote:
>>>
>>> On 10/24/2017 01:25 PM, Andrea Pescetti wrote:
>>>> I'm starting a short series of occasional posts to capture the
>>>> current collective state of mind on the next release. I'll float
>them
>>>> here for refinement or lazy consensus, and then we may want to
>reuse
>>>> this text in wiki or blog posts to avoid repeating the same
>concepts
>>>> over and over.
>>>>
>>>> Let's start with branches.
>>>>
>>>> We all wish 4.1.4 to be the last 4.1.x release.
>>>>
>>>> We currently have an AOO415 branch at
>>>> http://svn.apache.org/viewvc/openoffice/branches/AOO415/ ; this
>>>> branch is a copy of AOO414 (that resulted in OpenOffice 4.1.4). The
>
>>>> AOO415 branch will result in a release ONLY if we have some
>important
>>>> bug fixes to release and trunk is not ready yet. No new features,
>>>> even small enhancements, are added to it. No commits to AOO415
>happen
>>>> without appropriate mailing list discussions (dev or security,
>>>> depending on cases).
>>>>
>>>> Trunk is where all development happens. It will be branched for a
>new
>>>> release (like, an AOO420 branch - name still provisional) when the
>>>> code is mature: beta or even RC. Until then, we simply keep working
>
>>>> on trunk as we are doing now.
>>>>
>>>> In case we need to commit to a branch, any changes are still
>>>> committed to trunk first and then merged to branches using SVN
>merge
>>>> in all situations when this is possible (i.e., when there are no
>>>> merge conflicts). The mergeinfo for AOO414 and AOO415 isn't clear,
>so
>>>> we'll have to make sure that trunk contains all fixes done there
>(or
>>>> equivalent in case of conflicts) and, done that, we commit to
>AOO415
>>>> only if:
>>>> 1. The fix is important and agreed upon on the relevant list
>>>> 2. The commit is done with "svn merge" starting from a trunk commit
>>>>
>>>> This will ensure that we can shift the focus to trunk while still
>>>> keeping a branch that remains ready for a quick release if needed.
>If
>>>> we are never in this situation, the next release will be from the
>>>> current trunk and AOO415 will never result in a release.
>>>>
>>>> Regards,
>>>>    Andrea.
>>>
>>> Would it be more clear to just remove the AOO415 branch and only
>>> re-instate it if needed (hopefully not). I don't see anything in
>>> AOO415 that wasn't included in AOO414.
>>>
>>
>> The decision to keep the 4.1.5 branch around came out of a discussion
>on
>> the security mailing list. The potential problem is that someday we
>may
>> be faced with a bug for which we need to get a fix out into the field
>as
>> soon as possible.
>>
>> Because of the sheer size of AOO, it takes time to get set up for a
>> release. The idea is to do as much as we can to prepare without
>> committing to a release. I have a check-out of AOO415 built. As the
>> version number changes get incorporated I'll update and rebuild. Not
>> having to wait for the branch to be prepared, check it out, and do a
>> full build reduces by about a day the time it would take from knowing
>a
>> fix to having it built, tested, and checked in.
>>
>> I would like to make this an on-going policy. As soon as we ship
>4.2.0,
>> we remove the AOO415 branch but create AOO421, identical except for
>> version numbers to AOO420, ready in case of an emergency fix.
>
>+1
>This is an good and cheap idea to speed things up.
>
>Marcus
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [hidden email]
>For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Managing branches for future releases

Kay Schenk-2
In reply to this post by Patricia Shanahan
On Tue, Oct 24, 2017 at 4:00 PM, Patricia Shanahan <[hidden email]> wrote:

>
>
> On 10/24/2017 2:34 PM, Kay Schenk wrote:
>
>>
>> On 10/24/2017 01:25 PM, Andrea Pescetti wrote:
>>
>>> I'm starting a short series of occasional posts to capture the current
>>> collective state of mind on the next release. I'll float them here for
>>> refinement or lazy consensus, and then we may want to reuse this text in
>>> wiki or blog posts to avoid repeating the same concepts over and over.
>>>
>>> Let's start with branches.
>>>
>>> We all wish 4.1.4 to be the last 4.1.x release.
>>>
>>> We currently have an AOO415 branch at http://svn.apache.org/viewvc/o
>>> penoffice/branches/AOO415/ ; this branch is a copy of AOO414 (that
>>> resulted in OpenOffice 4.1.4). The AOO415 branch will result in a release
>>> ONLY if we have some important bug fixes to release and trunk is not ready
>>> yet. No new features, even small enhancements, are added to it. No commits
>>> to AOO415 happen without appropriate mailing list discussions (dev or
>>> security, depending on cases).
>>>
>>> Trunk is where all development happens. It will be branched for a new
>>> release (like, an AOO420 branch - name still provisional) when the code is
>>> mature: beta or even RC. Until then, we simply keep working on trunk as we
>>> are doing now.
>>>
>>> In case we need to commit to a branch, any changes are still committed
>>> to trunk first and then merged to branches using SVN merge in all
>>> situations when this is possible (i.e., when there are no merge conflicts).
>>> The mergeinfo for AOO414 and AOO415 isn't clear, so we'll have to make sure
>>> that trunk contains all fixes done there (or equivalent in case of
>>> conflicts) and, done that, we commit to AOO415 only if:
>>> 1. The fix is important and agreed upon on the relevant list
>>> 2. The commit is done with "svn merge" starting from a trunk commit
>>>
>>> This will ensure that we can shift the focus to trunk while still
>>> keeping a branch that remains ready for a quick release if needed. If we
>>> are never in this situation, the next release will be from the current
>>> trunk and AOO415 will never result in a release.
>>>
>>> Regards,
>>>    Andrea.
>>>
>>
>> Would it be more clear to just remove the AOO415 branch and only
>> re-instate it if needed (hopefully not). I don't see anything in AOO415
>> that wasn't included in AOO414.
>>
>>
> The decision to keep the 4.1.5 branch around came out of a discussion on
> the security mailing list. The potential problem is that someday we may
> be faced with a bug for which we need to get a fix out into the field as
> soon as possible.
>
> Because of the sheer size of AOO, it takes time to get set up for a
> release. The idea is to do as much as we can to prepare without
> committing to a release. I have a check-out of AOO415 built. As the
> version number changes get incorporated I'll update and rebuild. Not
> having to wait for the branch to be prepared, check it out, and do a
> full build reduces by about a day the time it would take from knowing a
> fix to having it built, tested, and checked in.
>
> I would like to make this an on-going policy. As soon as we ship 4.2.0,
> we remove the AOO415 branch but create AOO421, identical except for
> version numbers to AOO420, ready in case of an emergency fix.
>


​Thanks for this explanation. It makes good sense.​

--
----------------------------------------------------------------------
MzK

"Only the truth will save you now."
                         -- Ensei Tankado, "Digital Fortress"
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Managing branches for future releases

Marcus (OOo)
In reply to this post by Peter Kovacs-3
Am 25.10.2017 um 20:50 schrieb Peter kovacs:
> Why do you want to branch all the time with names that can change? I think it is an expensive way of getting flexibility. I suggest a more abstract branches.
>
> Why not have 4 permanent branches that are dev/trunc , test, hotfix and Release?
>
> Dev/trunc would contain latest development.
> Test would contain the latest release candidate that gets prepared. It bases of from dev and propagates to release.
> Hotfix is the one that bases on release and propagates back to release branch.
> With this schema you have an abstract way in doing the same thing without the limitation of naming.

sorry but this is totally confusing.

> We could even post vote result into comments. When propagate version to release. Also we can decide on release name at the latest possible moment.

Deciding on the name (or better said version numnber) when the build is
nearly finished dooesn't make sense. We need to know what we are working on.

> It would be less confusing especially if we rename a release. (4.2.0 is not final decided. But we may now have branch. Or we wait until we have decided but that would delay the result until we are done with the naming.)

There are only a few moments when we need to agree on a new version
number. The new release will be one of these. Currently it's 4.2.0 but
who knows.

Every bugfix release is a minor release. So, only the last number will
be increased.

Sure, it's not yet written in stop. But when we need to build it it has
to be.

Furthermore, when releasing from "test" or "release" or similar, what to
do with these branches? I hope you do not suggest "then we can recycle
them and reuse for the next build". ;-)

Marcus



> Am 25. Oktober 2017 19:44:39 MESZ schrieb Marcus <[hidden email]>:
>> Am 25.10.2017 um 01:00 schrieb Patricia Shanahan:
>>>
>>> On 10/24/2017 2:34 PM, Kay Schenk wrote:
>>>>
>>>> On 10/24/2017 01:25 PM, Andrea Pescetti wrote:
>>>>> I'm starting a short series of occasional posts to capture the
>>>>> current collective state of mind on the next release. I'll float
>> them
>>>>> here for refinement or lazy consensus, and then we may want to
>> reuse
>>>>> this text in wiki or blog posts to avoid repeating the same
>> concepts
>>>>> over and over.
>>>>>
>>>>> Let's start with branches.
>>>>>
>>>>> We all wish 4.1.4 to be the last 4.1.x release.
>>>>>
>>>>> We currently have an AOO415 branch at
>>>>> http://svn.apache.org/viewvc/openoffice/branches/AOO415/ ; this
>>>>> branch is a copy of AOO414 (that resulted in OpenOffice 4.1.4). The
>>
>>>>> AOO415 branch will result in a release ONLY if we have some
>> important
>>>>> bug fixes to release and trunk is not ready yet. No new features,
>>>>> even small enhancements, are added to it. No commits to AOO415
>> happen
>>>>> without appropriate mailing list discussions (dev or security,
>>>>> depending on cases).
>>>>>
>>>>> Trunk is where all development happens. It will be branched for a
>> new
>>>>> release (like, an AOO420 branch - name still provisional) when the
>>>>> code is mature: beta or even RC. Until then, we simply keep working
>>
>>>>> on trunk as we are doing now.
>>>>>
>>>>> In case we need to commit to a branch, any changes are still
>>>>> committed to trunk first and then merged to branches using SVN
>> merge
>>>>> in all situations when this is possible (i.e., when there are no
>>>>> merge conflicts). The mergeinfo for AOO414 and AOO415 isn't clear,
>> so
>>>>> we'll have to make sure that trunk contains all fixes done there
>> (or
>>>>> equivalent in case of conflicts) and, done that, we commit to
>> AOO415
>>>>> only if:
>>>>> 1. The fix is important and agreed upon on the relevant list
>>>>> 2. The commit is done with "svn merge" starting from a trunk commit
>>>>>
>>>>> This will ensure that we can shift the focus to trunk while still
>>>>> keeping a branch that remains ready for a quick release if needed.
>> If
>>>>> we are never in this situation, the next release will be from the
>>>>> current trunk and AOO415 will never result in a release.
>>>>>
>>>>> Regards,
>>>>>     Andrea.
>>>>
>>>> Would it be more clear to just remove the AOO415 branch and only
>>>> re-instate it if needed (hopefully not). I don't see anything in
>>>> AOO415 that wasn't included in AOO414.
>>>>
>>>
>>> The decision to keep the 4.1.5 branch around came out of a discussion
>> on
>>> the security mailing list. The potential problem is that someday we
>> may
>>> be faced with a bug for which we need to get a fix out into the field
>> as
>>> soon as possible.
>>>
>>> Because of the sheer size of AOO, it takes time to get set up for a
>>> release. The idea is to do as much as we can to prepare without
>>> committing to a release. I have a check-out of AOO415 built. As the
>>> version number changes get incorporated I'll update and rebuild. Not
>>> having to wait for the branch to be prepared, check it out, and do a
>>> full build reduces by about a day the time it would take from knowing
>> a
>>> fix to having it built, tested, and checked in.
>>>
>>> I would like to make this an on-going policy. As soon as we ship
>> 4.2.0,
>>> we remove the AOO415 branch but create AOO421, identical except for
>>> version numbers to AOO420, ready in case of an emergency fix.
>>
>> +1
>> This is an good and cheap idea to speed things up.
>>
>> Marcus

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Managing branches for future releases

Marcus (OOo)
In reply to this post by Andrea Pescetti-2
Am 24.10.2017 um 22:25 schrieb Andrea Pescetti:

> I'm starting a short series of occasional posts to capture the current
> collective state of mind on the next release. I'll float them here for
> refinement or lazy consensus, and then we may want to reuse this text in
> wiki or blog posts to avoid repeating the same concepts over and over.
>
> Let's start with branches.
>
> We all wish 4.1.4 to be the last 4.1.x release.
>
> We currently have an AOO415 branch at
> http://svn.apache.org/viewvc/openoffice/branches/AOO415/ ; this branch
> is a copy of AOO414 (that resulted in OpenOffice 4.1.4). The AOO415
> branch will result in a release ONLY if we have some important bug fixes
> to release and trunk is not ready yet. No new features, even small
> enhancements, are added to it. No commits to AOO415 happen without
> appropriate mailing list discussions (dev or security, depending on cases).
>
> Trunk is where all development happens. It will be branched for a new
> release (like, an AOO420 branch - name still provisional) when the code
> is mature: beta or even RC. Until then, we simply keep working on trunk
> as we are doing now.
>
> In case we need to commit to a branch, any changes are still committed
> to trunk first and then merged to branches using SVN merge in all
> situations when this is possible (i.e., when there are no merge
> conflicts). The mergeinfo for AOO414 and AOO415 isn't clear, so we'll
> have to make sure that trunk contains all fixes done there (or
> equivalent in case of conflicts) and, done that, we commit to AOO415
> only if:
> 1. The fix is important and agreed upon on the relevant list
> 2. The commit is done with "svn merge" starting from a trunk commit
>
> This will ensure that we can shift the focus to trunk while still
> keeping a branch that remains ready for a quick release if needed. If we
> are never in this situation, the next release will be from the current
> trunk and AOO415 will never result in a release.

"First trunk, then the branch(es)" is not new. I think we are working
already in this way. But just to make it clear.

so, to keep it short:
I like the proposal.

Marcus


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Managing branches for future releases

Pedro Lino-3
In reply to this post by Andrea Pescetti-2
Hi Andrea, all

On 24/10/2017 21:25, Andrea Pescetti wrote:

> This will ensure that we can shift the focus to trunk while still
> keeping a branch that remains ready for a quick release if needed. If
> we are never in this situation, the next release will be from the
> current trunk and AOO415 will never result in a release.


+1
One of the major criticisms to AOO is that it took too long to fix some
security issue and left the "community" at risk. So it is a good plan to
have a branch in ready-to-launch state.

Pedro

Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Managing branches for future releases

Peter Kovacs-3
In reply to this post by Marcus (OOo)


Am 25. Oktober 2017 21:25:42 MESZ schrieb Marcus <[hidden email]>:

>Am 25.10.2017 um 20:50 schrieb Peter kovacs:
>> Why do you want to branch all the time with names that can change? I
>think it is an expensive way of getting flexibility. I suggest a more
>abstract branches.
>>
>> Why not have 4 permanent branches that are dev/trunc , test, hotfix
>and Release?
>>
>> Dev/trunc would contain latest development.
>> Test would contain the latest release candidate that gets prepared.
>It bases of from dev and propagates to release.
>> Hotfix is the one that bases on release and propagates back to
>release branch.
>> With this schema you have an abstract way in doing the same thing
>without the limitation of naming.
>
>sorry but this is totally confusing.
>
>> We could even post vote result into comments. When propagate version
>to release. Also we can decide on release name at the latest possible
>moment.
>
>Deciding on the name (or better said version numnber) when the build is
>
>nearly finished dooesn't make sense. We need to know what we are
>working on.
>
>> It would be less confusing especially if we rename a release. (4.2.0
>is not final decided. But we may now have branch. Or we wait until we
>have decided but that would delay the result until we are done with the
>naming.)
>
>There are only a few moments when we need to agree on a new version
>number. The new release will be one of these. Currently it's 4.2.0 but
>who knows.
That's exactly what I mean. Our release cycles are slow. We have decided a year ago we stick to 4.2.0 but it was not final it seems.
Better decide on the name when ready.
>
>Every bugfix release is a minor release. So, only the last number will
>be increased.
I think this is not critical. But decision 4.2.0 or 5.0.0 is more political then technical.

>
>Sure, it's not yet written in stop. But when we need to build it it has to be.
>
>Furthermore, when releasing from "test" or "release" or similar, what
>to
>do with these branches? I hope you do not suggest "then we can recycle
>them and reuse for the next build". ;-)
Why do you think it is a problem to go by state?

I see the benefit that there is no need to delete 4.1.5 if we do not need it.
We simply promote the code in the branch from release. Maybe state as a comment.
Rebase to 4.2.0 release. Done.
Also a new release is done the same way.
No need for new branches and maybe explain people what's the release because release manager had no time to make a new branch.

Also I think for people. Testers will check out test or hot fix (Maybe maintenance is a better word).
A someone who wants a release version simply checks out release branch. There is no need explaining anyone which one is the current release what is maintenance.

It is error proove.
Also if you think on auto builds. No maintenance. If you use version names you have to make sure that the release builder always points at release branch. That maintenance builder points on the current machine branch. There will be always manually tasks involved. And manuall means potential failures.

Also if you think on our release cycles we have discussed.
1-2 years for feature release
1-2 additional maintenance. Maybe we do more maintenance.
We will develop parallel in various branches.
At least for maintenance and one for features. I assume we will stick to long freeze code times since quality is our concern.

If we would like to use the classics open source release cycle to release often. I'd say version numbers are a good thing. Because we will have one development and release that in a cycle.
But we talk not in this way. So I suggest we need a different way to manage our code.

The method I suggest is used by SUSE document group. You can see that in their talk on FOSDEM 2017. At least the idea I have from them.

>
>Marcus
>
>
>
>> Am 25. Oktober 2017 19:44:39 MESZ schrieb Marcus
><[hidden email]>:
>>> Am 25.10.2017 um 01:00 schrieb Patricia Shanahan:
>>>>
>>>> On 10/24/2017 2:34 PM, Kay Schenk wrote:
>>>>>
>>>>> On 10/24/2017 01:25 PM, Andrea Pescetti wrote:
>>>>>> I'm starting a short series of occasional posts to capture the
>>>>>> current collective state of mind on the next release. I'll float
>>> them
>>>>>> here for refinement or lazy consensus, and then we may want to
>>> reuse
>>>>>> this text in wiki or blog posts to avoid repeating the same
>>> concepts
>>>>>> over and over.
>>>>>>
>>>>>> Let's start with branches.
>>>>>>
>>>>>> We all wish 4.1.4 to be the last 4.1.x release.
>>>>>>
>>>>>> We currently have an AOO415 branch at
>>>>>> http://svn.apache.org/viewvc/openoffice/branches/AOO415/ ; this
>>>>>> branch is a copy of AOO414 (that resulted in OpenOffice 4.1.4).
>The
>>>
>>>>>> AOO415 branch will result in a release ONLY if we have some
>>> important
>>>>>> bug fixes to release and trunk is not ready yet. No new features,
>>>>>> even small enhancements, are added to it. No commits to AOO415
>>> happen
>>>>>> without appropriate mailing list discussions (dev or security,
>>>>>> depending on cases).
>>>>>>
>>>>>> Trunk is where all development happens. It will be branched for a
>>> new
>>>>>> release (like, an AOO420 branch - name still provisional) when
>the
>>>>>> code is mature: beta or even RC. Until then, we simply keep
>working
>>>
>>>>>> on trunk as we are doing now.
>>>>>>
>>>>>> In case we need to commit to a branch, any changes are still
>>>>>> committed to trunk first and then merged to branches using SVN
>>> merge
>>>>>> in all situations when this is possible (i.e., when there are no
>>>>>> merge conflicts). The mergeinfo for AOO414 and AOO415 isn't
>clear,
>>> so
>>>>>> we'll have to make sure that trunk contains all fixes done there
>>> (or
>>>>>> equivalent in case of conflicts) and, done that, we commit to
>>> AOO415
>>>>>> only if:
>>>>>> 1. The fix is important and agreed upon on the relevant list
>>>>>> 2. The commit is done with "svn merge" starting from a trunk
>commit
>>>>>>
>>>>>> This will ensure that we can shift the focus to trunk while still
>>>>>> keeping a branch that remains ready for a quick release if
>needed.
>>> If
>>>>>> we are never in this situation, the next release will be from the
>>>>>> current trunk and AOO415 will never result in a release.
>>>>>>
>>>>>> Regards,
>>>>>>     Andrea.
>>>>>
>>>>> Would it be more clear to just remove the AOO415 branch and only
>>>>> re-instate it if needed (hopefully not). I don't see anything in
>>>>> AOO415 that wasn't included in AOO414.
>>>>>
>>>>
>>>> The decision to keep the 4.1.5 branch around came out of a
>discussion
>>> on
>>>> the security mailing list. The potential problem is that someday we
>>> may
>>>> be faced with a bug for which we need to get a fix out into the
>field
>>> as
>>>> soon as possible.
>>>>
>>>> Because of the sheer size of AOO, it takes time to get set up for a
>>>> release. The idea is to do as much as we can to prepare without
>>>> committing to a release. I have a check-out of AOO415 built. As the
>>>> version number changes get incorporated I'll update and rebuild.
>Not
>>>> having to wait for the branch to be prepared, check it out, and do
>a
>>>> full build reduces by about a day the time it would take from
>knowing
>>> a
>>>> fix to having it built, tested, and checked in.
>>>>
>>>> I would like to make this an on-going policy. As soon as we ship
>>> 4.2.0,
>>>> we remove the AOO415 branch but create AOO421, identical except for
>>>> version numbers to AOO420, ready in case of an emergency fix.
>>>
>>> +1
>>> This is an good and cheap idea to speed things up.
>>>
>>> Marcus
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [hidden email]
>For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Managing branches for future releases

Peter Kovacs-3
In reply to this post by Marcus (OOo)
Just to be clear.
I follow by all passionate argumentation, my vote goes to whatever Jim and Matthias decide. They do releases, and they earned the most kudos on that.
I am in whatever makes them happy!
I like meritocracy! Even if that leaves me rather at the edge in a lot of topics.

All the best
Peter

Am 26. Oktober 2017 00:18:25 MESZ schrieb Marcus <[hidden email]>:

>Am 24.10.2017 um 22:25 schrieb Andrea Pescetti:
>> I'm starting a short series of occasional posts to capture the
>current
>> collective state of mind on the next release. I'll float them here
>for
>> refinement or lazy consensus, and then we may want to reuse this text
>in
>> wiki or blog posts to avoid repeating the same concepts over and
>over.
>>
>> Let's start with branches.
>>
>> We all wish 4.1.4 to be the last 4.1.x release.
>>
>> We currently have an AOO415 branch at
>> http://svn.apache.org/viewvc/openoffice/branches/AOO415/ ; this
>branch
>> is a copy of AOO414 (that resulted in OpenOffice 4.1.4). The AOO415
>> branch will result in a release ONLY if we have some important bug
>fixes
>> to release and trunk is not ready yet. No new features, even small
>> enhancements, are added to it. No commits to AOO415 happen without
>> appropriate mailing list discussions (dev or security, depending on
>cases).
>>
>> Trunk is where all development happens. It will be branched for a new
>
>> release (like, an AOO420 branch - name still provisional) when the
>code
>> is mature: beta or even RC. Until then, we simply keep working on
>trunk
>> as we are doing now.
>>
>> In case we need to commit to a branch, any changes are still
>committed
>> to trunk first and then merged to branches using SVN merge in all
>> situations when this is possible (i.e., when there are no merge
>> conflicts). The mergeinfo for AOO414 and AOO415 isn't clear, so we'll
>
>> have to make sure that trunk contains all fixes done there (or
>> equivalent in case of conflicts) and, done that, we commit to AOO415
>> only if:
>> 1. The fix is important and agreed upon on the relevant list
>> 2. The commit is done with "svn merge" starting from a trunk commit
>>
>> This will ensure that we can shift the focus to trunk while still
>> keeping a branch that remains ready for a quick release if needed. If
>we
>> are never in this situation, the next release will be from the
>current
>> trunk and AOO415 will never result in a release.
>
>"First trunk, then the branch(es)" is not new. I think we are working
>already in this way. But just to make it clear.
>
>so, to keep it short:
>I like the proposal.
>
>Marcus
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [hidden email]
>For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Managing branches for future releases

Don Lewis-2
In reply to this post by Peter Kovacs-3
On 26 Oct, Peter kovacs wrote:

>
>
> Am 25. Oktober 2017 21:25:42 MESZ schrieb Marcus <[hidden email]>:
>>Am 25.10.2017 um 20:50 schrieb Peter kovacs:
>>> Why do you want to branch all the time with names that can change? I
>>think it is an expensive way of getting flexibility. I suggest a more
>>abstract branches.
>>>
>>> Why not have 4 permanent branches that are dev/trunc , test, hotfix
>>and Release?
>>>
>>> Dev/trunc would contain latest development.
>>> Test would contain the latest release candidate that gets prepared.
>>It bases of from dev and propagates to release.
>>> Hotfix is the one that bases on release and propagates back to
>>release branch.
>>> With this schema you have an abstract way in doing the same thing
>>without the limitation of naming.
>>
>>sorry but this is totally confusing.
>>
>>> We could even post vote result into comments. When propagate version
>>to release. Also we can decide on release name at the latest possible
>>moment.
>>
>>Deciding on the name (or better said version numnber) when the build
>>is
>>
>>nearly finished dooesn't make sense. We need to know what we are
>>working on.
>>
>>> It would be less confusing especially if we rename a release. (4.2.0
>>is not final decided. But we may now have branch. Or we wait until we
>>have decided but that would delay the result until we are done with
>>the naming.)
>>
>>There are only a few moments when we need to agree on a new version
>>number. The new release will be one of these. Currently it's 4.2.0 but
>>who knows.
> That's exactly what I mean. Our release cycles are slow. We have
> decided a year ago we stick to 4.2.0 but it was not final it seems.
> Better decide on the name when ready.
>>
>>Every bugfix release is a minor release. So, only the last number will
>>be increased.
> I think this is not critical. But decision 4.2.0 or 5.0.0 is more
> political then technical.
>
>>
>>Sure, it's not yet written in stop. But when we need to build it it
>>has to be.
>>
>>Furthermore, when releasing from "test" or "release" or similar, what
>>to
>>do with these branches? I hope you do not suggest "then we can recycle
>>them and reuse for the next build". ;-)
> Why do you think it is a problem to go by state?
>
> I see the benefit that there is no need to delete 4.1.5 if we do not
> need it. We simply promote the code in the branch from release. Maybe
> state as a comment. Rebase to 4.2.0 release. Done.
> Also a new release is done the same way.
> No need for new branches and maybe explain people what's the release
> because release manager had no time to make a new branch.

We need at least as many branches as we have releases.  If you try to
reuse a branch, then you will lose whatever history is associated with
it.  We have branches for 4.1.0, 4.1.1, 4.1.2, 4.1.3, 4.1.4, plus lots
more for older releases.  That allows us to look at what is in each of
those releases as well as look back at the changes that were part of
those releases.  Running the svn command to create a new branch isn't
the time consuming part.  Most of the effort is spent on tweaking all
of the source files that contain version-specific information,
solenv/inc/minor.mk for one example.  That would still have to be done
manually even if you try to reuse a branch.

svn doesn't have anything like git rebase.  Even in git, rebase is
problematic.  If you rebase a branch checked out from a remote
repository, git won't let you push it back.  If you do a force push,
you'll hose anyone else who has a copy of that branch.  They'll have to
delete their local copy of that branch and refetch.  About the only way
to safely use rebase is to create a new local branch, rebase that, and
then push to create a new remote branch.

> Also I think for people. Testers will check out test or hot fix (Maybe
> maintenance is a better word). A someone who wants a release version
> simply checks out release branch. There is no need explaining anyone
> which one is the current release what is maintenance.

You really can't reuse hotfix branches, you have to generate unique
names for them.  With a git-based workflow, you might want to create a
new branch to test a hotfix, and you can delete it after the fix has
been tested successfully and merged, but later creating a new branch
with the same name will cause problems.  Anybody who has a copy of the
old version of that branch will run into problems when trying to pull
the new version because the history of the local and remote copies will
not match.

> It is error proove.
> Also if you think on auto builds. No maintenance. If you use version
> names you have to make sure that the release builder always points at
> release branch. That maintenance builder points on the current machine
> branch. There will be always manually tasks involved. And manuall
> means potential failures.
>
> Also if you think on our release cycles we have discussed.
> 1-2 years for feature release
> 1-2 additional maintenance. Maybe we do more maintenance.
>
> We will develop parallel in various branches.
>
> At least for maintenance and one for features. I assume we will stick
> to long freeze code times since quality is our concern.

We already sort of do that, trunk gets a mix of new features and
maintenance.  Mostly the latter since there is a lot of maintenance
backlog and not enough developer cycles to spend on many new features.
Bug fixes if they are important enough get merged to the 4.1.x release
branches.  At some point in the future, we'll create a 4.2.0 branch
which we will only get bug fixes from trunk, which will allow us to try
to make it stable enough for a 4.2.0 release.

> If we would like to use the classics open source release cycle to
> release often. I'd say version numbers are a good thing. Because we
> will have one development and release that in a cycle. But we talk not
> in this way. So I suggest we need a different way to manage our code.
>
> The method I suggest is used by SUSE document group. You can see that
> in their talk on FOSDEM 2017. At least the idea I have from them.
>>
>>Marcus
>>
>>
>>
>>> Am 25. Oktober 2017 19:44:39 MESZ schrieb Marcus
>><[hidden email]>:
>>>> Am 25.10.2017 um 01:00 schrieb Patricia Shanahan:
>>>>>
>>>>> On 10/24/2017 2:34 PM, Kay Schenk wrote:
>>>>>>
>>>>>> On 10/24/2017 01:25 PM, Andrea Pescetti wrote:
>>>>>>> I'm starting a short series of occasional posts to capture the
>>>>>>> current collective state of mind on the next release. I'll float
>>>> them
>>>>>>> here for refinement or lazy consensus, and then we may want to
>>>> reuse
>>>>>>> this text in wiki or blog posts to avoid repeating the same
>>>> concepts
>>>>>>> over and over.
>>>>>>>
>>>>>>> Let's start with branches.
>>>>>>>
>>>>>>> We all wish 4.1.4 to be the last 4.1.x release.
>>>>>>>
>>>>>>> We currently have an AOO415 branch at
>>>>>>> http://svn.apache.org/viewvc/openoffice/branches/AOO415/ ; this
>>>>>>> branch is a copy of AOO414 (that resulted in OpenOffice 4.1.4).
>>The
>>>>
>>>>>>> AOO415 branch will result in a release ONLY if we have some
>>>> important
>>>>>>> bug fixes to release and trunk is not ready yet. No new features,
>>>>>>> even small enhancements, are added to it. No commits to AOO415
>>>> happen
>>>>>>> without appropriate mailing list discussions (dev or security,
>>>>>>> depending on cases).
>>>>>>>
>>>>>>> Trunk is where all development happens. It will be branched for
>>>>>a new
>>>>>>> release (like, an AOO420 branch - name still provisional) when
>>the
>>>>>>> code is mature: beta or even RC. Until then, we simply keep
>>working
>>>>
>>>>>>> on trunk as we are doing now.
>>>>>>>
>>>>>>> In case we need to commit to a branch, any changes are still
>>>>>>> committed to trunk first and then merged to branches using SVN
>>>> merge
>>>>>>> in all situations when this is possible (i.e., when there are no
>>>>>>> merge conflicts). The mergeinfo for AOO414 and AOO415 isn't
>>clear,
>>>> so
>>>>>>> we'll have to make sure that trunk contains all fixes done there
>>>> (or
>>>>>>> equivalent in case of conflicts) and, done that, we commit to
>>>> AOO415
>>>>>>> only if:
>>>>>>> 1. The fix is important and agreed upon on the relevant list
>>>>>>> 2. The commit is done with "svn merge" starting from a trunk
>>commit
>>>>>>>
>>>>>>> This will ensure that we can shift the focus to trunk while
>>still keeping a branch that remains ready for a quick release if
>>needed.
>>>> If
>>>>>>> we are never in this situation, the next release will be from
>>>>>>> the current trunk and AOO415 will never result in a release.
>>>>>>>
>>>>>>> Regards,
>>>>>>>     Andrea.
>>>>>>
>>>>>> Would it be more clear to just remove the AOO415 branch and only
>>>>>> re-instate it if needed (hopefully not). I don't see anything in
>>>>>> AOO415 that wasn't included in AOO414.
>>>>>>
>>>>>
>>>>> The decision to keep the 4.1.5 branch around came out of a
>>discussion
>>>> on
>>>>> the security mailing list. The potential problem is that someday
>>>>>we may
>>>>> be faced with a bug for which we need to get a fix out into the
>>field
>>>> as
>>>>> soon as possible.
>>>>>
>>>>> Because of the sheer size of AOO, it takes time to get set up for
>>>>> a release. The idea is to do as much as we can to prepare without
>>>>> committing to a release. I have a check-out of AOO415 built. As
>>>>> the version number changes get incorporated I'll update and
>>rebuild. Not
>>>>> having to wait for the branch to be prepared, check it out, and do
>>a
>>>>> full build reduces by about a day the time it would take from
>>knowing
>>>> a
>>>>> fix to having it built, tested, and checked in.
>>>>>
>>>>> I would like to make this an on-going policy. As soon as we ship
>>>> 4.2.0,
>>>>> we remove the AOO415 branch but create AOO421, identical except
>>>>> for version numbers to AOO420, ready in case of an emergency fix.
>>>>
>>>> +1
>>>> This is an good and cheap idea to speed things up.
>>>>
>>>> Marcus
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [hidden email]
>>For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Managing branches for future releases

Jim Jagielski
In reply to this post by Patricia Shanahan
+1. Having a branch ready to roll is cheap insurance.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Managing branches for future releases

Marcus (OOo)
In reply to this post by Peter Kovacs-3
Am 26.10.2017 um 07:03 schrieb Peter kovacs:
> Am 25. Oktober 2017 21:25:42 MESZ schrieb Marcus <[hidden email]>:
>>
>> Sure, it's not yet written in stop. But when we need to build it it has to be.
>>
>> Furthermore, when releasing from "test" or "release" or similar, what
>> to
>> do with these branches? I hope you do not suggest "then we can recycle
>> them and reuse for the next build". ;-)
> Why do you think it is a problem to go by state?

I cannot see what is behind the names. "test" - from what? Is it still
for 4.1.x or the new 4.2.0 or what? I really think it is not clear for
everyone.

And again:
Never, never, ever reuse a branch that has seen a release. You will
destroy the history. In the worst case you will loose the overview and
therefore loose time when you actually don't have it.

Creating a new branch just after we have released a version is fast and
cheap.

Marcus



>>> Am 25. Oktober 2017 19:44:39 MESZ schrieb Marcus
>> <[hidden email]>:
>>>> Am 25.10.2017 um 01:00 schrieb Patricia Shanahan:
>>>>>
>>>>> On 10/24/2017 2:34 PM, Kay Schenk wrote:
>>>>>>
>>>>>> On 10/24/2017 01:25 PM, Andrea Pescetti wrote:
>>>>>>> I'm starting a short series of occasional posts to capture the
>>>>>>> current collective state of mind on the next release. I'll float
>>>> them
>>>>>>> here for refinement or lazy consensus, and then we may want to
>>>> reuse
>>>>>>> this text in wiki or blog posts to avoid repeating the same
>>>> concepts
>>>>>>> over and over.
>>>>>>>
>>>>>>> Let's start with branches.
>>>>>>>
>>>>>>> We all wish 4.1.4 to be the last 4.1.x release.
>>>>>>>
>>>>>>> We currently have an AOO415 branch at
>>>>>>> http://svn.apache.org/viewvc/openoffice/branches/AOO415/ ; this
>>>>>>> branch is a copy of AOO414 (that resulted in OpenOffice 4.1.4).
>> The
>>>>
>>>>>>> AOO415 branch will result in a release ONLY if we have some
>>>> important
>>>>>>> bug fixes to release and trunk is not ready yet. No new features,
>>>>>>> even small enhancements, are added to it. No commits to AOO415
>>>> happen
>>>>>>> without appropriate mailing list discussions (dev or security,
>>>>>>> depending on cases).
>>>>>>>
>>>>>>> Trunk is where all development happens. It will be branched for a
>>>> new
>>>>>>> release (like, an AOO420 branch - name still provisional) when
>> the
>>>>>>> code is mature: beta or even RC. Until then, we simply keep
>> working
>>>>
>>>>>>> on trunk as we are doing now.
>>>>>>>
>>>>>>> In case we need to commit to a branch, any changes are still
>>>>>>> committed to trunk first and then merged to branches using SVN
>>>> merge
>>>>>>> in all situations when this is possible (i.e., when there are no
>>>>>>> merge conflicts). The mergeinfo for AOO414 and AOO415 isn't
>> clear,
>>>> so
>>>>>>> we'll have to make sure that trunk contains all fixes done there
>>>> (or
>>>>>>> equivalent in case of conflicts) and, done that, we commit to
>>>> AOO415
>>>>>>> only if:
>>>>>>> 1. The fix is important and agreed upon on the relevant list
>>>>>>> 2. The commit is done with "svn merge" starting from a trunk
>> commit
>>>>>>>
>>>>>>> This will ensure that we can shift the focus to trunk while still
>>>>>>> keeping a branch that remains ready for a quick release if
>> needed.
>>>> If
>>>>>>> we are never in this situation, the next release will be from the
>>>>>>> current trunk and AOO415 will never result in a release.
>>>>>>>
>>>>>>> Regards,
>>>>>>>      Andrea.
>>>>>>
>>>>>> Would it be more clear to just remove the AOO415 branch and only
>>>>>> re-instate it if needed (hopefully not). I don't see anything in
>>>>>> AOO415 that wasn't included in AOO414.
>>>>>>
>>>>>
>>>>> The decision to keep the 4.1.5 branch around came out of a
>> discussion
>>>> on
>>>>> the security mailing list. The potential problem is that someday we
>>>> may
>>>>> be faced with a bug for which we need to get a fix out into the
>> field
>>>> as
>>>>> soon as possible.
>>>>>
>>>>> Because of the sheer size of AOO, it takes time to get set up for a
>>>>> release. The idea is to do as much as we can to prepare without
>>>>> committing to a release. I have a check-out of AOO415 built. As the
>>>>> version number changes get incorporated I'll update and rebuild.
>> Not
>>>>> having to wait for the branch to be prepared, check it out, and do
>> a
>>>>> full build reduces by about a day the time it would take from
>> knowing
>>>> a
>>>>> fix to having it built, tested, and checked in.
>>>>>
>>>>> I would like to make this an on-going policy. As soon as we ship
>>>> 4.2.0,
>>>>> we remove the AOO415 branch but create AOO421, identical except for
>>>>> version numbers to AOO420, ready in case of an emergency fix.
>>>>
>>>> +1
>>>> This is an good and cheap idea to speed things up.
>>>>
>>>> Marcus


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Managing branches for future releases

Peter Kovacs-4
Disclaimer:
I do not claime that one solution is the ultimate solution over the
other.

But I would like to explain my approach as long as it takes until
everybody says he understood what I am suggesting. Nothing more nothing
less. No religeous war is intended or whished from my side.
end disclaimer.

Am Donnerstag, den 26.10.2017, 20:27 +0200 schrieb Marcus:
> > Why do you think it is a problem to go by state?
>
> I cannot see what is behind the names. "test" - from what? Is it
> still
> for 4.1.x or the new 4.2.0 or what? I really think it is not clear
> for
> everyone.
It is a life cyle model. You do not need to know a release number.
A release number does tell nothing.
A life Cycle state tells you exactly which state the Product is in.

DEV: It is under development. The code can have serious bugs, break.
But can also have the newst feature that may only partial implemented.
In general the code is good enough that it compiles on the dev
machines.

TEST: Often revered to unstable.
The Code is in a feature freeze. It recieves bugfixes, that stabilize
the Code until it reaches the maturity that we expect from it. TEST
unlike DEV takes picks only new features up at a certain time.
Usually after the Code has reached a maturity state.


Release: often reverred to Stable.
The branch that only contains best possible code, to have transperency.
It also is the source to give people a clear state what is changing
from one change to the next.

hotfix, means maintenance:
This should be an exception. When we feel we need to fix something on
release level, because we missed a bug in the maturity phase.

It is a complete different development model. We can use Release
numbers to name a specific cycle. But we control the code not by that
number. We could give it also a Name like "Eternia Version" Would have
the same meaning.

Let me draw a picture, a fantasy example for illustration:
Time -------->
by live cycle:
              4.1.4                   4.1.5
hotfix  -x--x---+            +--x--x---x+              4.2.0  
Release --------V------------+----------V---------------A-------------
              born:4.2.0   every x here a bugfix     born:5.0.0        
                               
Test    -----------A------x---x-----x--x--x---x----x--x-+-A---x--x---x-
Dev     ----x----x-+-x--------x------------x---------x--V-+------------
           PSQL1&2  OOXML   Googlestuff  Root-lib    | fix integration
                                                video feature

by release Number:
           PSQL1&2  OOXML   Googlestuff  Root-lib  Sience-interface
trunc -x--x----x-+-x----x---x-----x--x--xx--x----x-x----+-+--x--x---x-
4.1.4 -x--x---+
4.1.5                     +--x--x---x+
4.2.0            +-x----x---x-----x--x--x---x----x--x-+
5.0.0                                                     +---x--x---x-

The above example does not break any history. You have a clear state,
on the advancement of the code.
You can compare at any given time the code (I.E. using fisheye). And
you can archieve by time.
In the above model we restrict sharing of changes to certain moments of
time. So the state is always defined.

The lower example due the nature of the approach you have in each
branch a single "fork". The advantage is that you can maintain each
Version from the other. You can also reintegrate a external Fork based
on someotherworks with ease.
But comparing branches is not guaranteed, since they are disconected to
each other. Both could be potential be maintained.
Plus at any moment you can have bugs or features introduce to your
branch, as you like, but probably it is not intended.
Archiving is done by time on trunc, and by release on branche. Getting
time and branch together again might be difficult. Maybe we could
archieve both if we go by time and branch so only complete branches are
saved.

Of course a lot of things assumed here is pure agreement and disciplin.
However I do not see any benefit to us in maintaining each version as
an own branch, since we do not want to maintain the branches.
As you see in the Picture.

It is the methology of thinging. In released based production it is of
course dreadfull to mix branches, because you do your controling by
release numbering.
In my suggested model you do not controlling by a release number but by
state of the code. by which we push our core value "stability over
Feature" into our steering centre.

Also we would like to have almost none hotfixes. Maybe they can be done
as branches  seperatly since there it can realy get confusing which
state a hotfix branch is in. And we need it only for ensuring that fix
does not break anything else. So normaly hoitfix brnches have a short
live period.

Also some thoughts about Release number:
The methology of Agile programming is often reduced to release often.
Which may translate to the idea that release number needs to rattle up.
(Firefox anyone?)
I think it is a stupid Idea, and does not work. It comes from an aera
when Versionening systems were none existand.
Does anyone use time dates to version his documents on disk?
It is the same system just less abstract.

I think we need to pull the community together. If there are companies
out there using open office, we must convince them to integrate our
process of updating in their workstream.
Only then we will get business interest, and an effective drive on a
clear open source model.

Relase Model can give a business entity to skipp specifying their
requirements on us and take the lazy method in trying to stick to the
Version they have. A "rolling release" discourages this.

I also would like to add as an argument against rolling modell, that
our build environment and our publish procedures are closely tied to
the release model.
To switch the modell is probably not an easy thing to do.
Things I have noted from the discussion:
- Automated builds is super important I think in a rolling modell.
- Version number is tied in multiple places, which is awkward at best.
- Dictionaries are not covered in the modell. And I am not sure how
they move with that, because they have their own cycle.
If we could make code more intependant from the dictionaries, we could
let them swing independently from each other, which would be super
cool. but that would mean that an dictionary update is done compile
free.
- We must get better at updateing an installed version. I think the
need to reset or delete the profile is in general not good.

So I hope this rather lengthy email is explaining all stuff.
I hope I did not scare anyone with this lengthy explanation now.

All the best
Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Managing branches for future releases

Marcus (OOo)
Am 27.10.2017 um 23:28 schrieb Peter Kovacs:

> Disclaimer:
> I do not claime that one solution is the ultimate solution over the
> other.
>
> But I would like to explain my approach as long as it takes until
> everybody says he understood what I am suggesting. Nothing more nothing
> less. No religeous war is intended or whished from my side.
> end disclaimer.
>
> Am Donnerstag, den 26.10.2017, 20:27 +0200 schrieb Marcus:
>>> Why do you think it is a problem to go by state?
>>
>> I cannot see what is behind the names. "test" - from what? Is it
>> still
>> for 4.1.x or the new 4.2.0 or what? I really think it is not clear
>> for
>> everyone.
>
> [ looooooong mail]
>
> So I hope this rather lengthy email is explaining all stuff.
> I hope I did not scare anyone with this lengthy explanation now.

sorry, but yes.

At the moment I've not the time and mood to read and understand such
long mails. So, please don't expect an answer from me.

If the majority of the community is supporting your
proposal/suggestion/..., then fine.

Marcus


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

12