Re: [PROPOSAL] Managing branches for future releases

[Andrea Pescetti]

Peter Kovacs wrote:

Am Samstag, den 28.10.2017, 00:40 +0200 schrieb Andrea Pescetti:

this thread was actually to address the problem with actually
changing release numbers in code, nothing else.

It does not adress the problem with release models. It works only
around them. Is there a bug report for the Problem?


https://bz.apache.org/ooo/show_bug.cgi?id=127552 but the right way would 
be to simply script it, so using the occasion for performing that 
specific set of changes, but also for improving our tools so that we can 
execute a script to achieve the same effect.


Regards,
  Andrea.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [PROPOSAL] Managing branches for future releases

[Peter Kovacs]

Am Freitag, den 27.10.2017, 23:36 +0200 schrieb Marcus:
> 
> 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.
I see. I am sorry. I will keep then my Ideas to me. Do them if I have
time, suggest if I have a solution. suggest only non scary things.
> 
> If the majority of the community is supporting your 
> proposal/suggestion/..., then fine.
Dont think there is a support, for the usual reasons.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [PROPOSAL] Managing branches for future releases

[Peter Kovacs]

Am Samstag, den 28.10.2017, 00:40 +0200 schrieb Andrea Pescetti:
> Peter Kovacs wrote:
> > I hope I did not scare anyone with this lengthy explanation now.
> 
> No, but it is just off-topic. This is partially my fault since
> "Managing 
> branches" in the subject could be read as a proposal for a branching 
> model. But this is totally not the topic here.
I am not objecting it.
> 
> The issue here is very simple and unrelated to the branching model.
> The 
> issue is: if you want a release to be named "4.1.4" you have to
> update 
> dozens of files to get it done properly, it is not a one-line change
> to 
> set "VERSION = 4.1.4" as some would expect. This is stupid, should
> be 
> scripted, caused two rebuilds of binaries in 4.1.4 due to
> distraction.
We have a lots of convenieance Programming antipatterns in the code.
I dont like those, because to me they are very much unconvenient.
This should be handled by the build system.
> 
> If we have to release 4.1.5 (not foreseen at the moment) we will want
> to 
> spend our time in actually fixing the bugs, and not in the painful 
> update of release numbers here and there. If we do it now, and maybe 
> take the occasion for scripting it, we won't risk useless delays.
> 
> This is all I wanted to say, and I hope it's clear now.
> 
> We could go on for ages discussing branching models, but the point
> of 
> this thread was actually to address the problem with actually
> changing 
> release numbers in code, nothing else.
It does not adress the problem with release models. It works only
around them. Is there a bug report for the Problem?
> 
> Regards,
>Andrea.
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [PROPOSAL] Managing branches for future releases

[Andrea Pescetti]

Peter Kovacs wrote:

I hope I did not scare anyone with this lengthy explanation now.


No, but it is just off-topic. This is partially my fault since "Managing 
branches" in the subject could be read as a proposal for a branching 
model. But this is totally not the topic here.


The issue here is very simple and unrelated to the branching model. The 
issue is: if you want a release to be named "4.1.4" you have to update 
dozens of files to get it done properly, it is not a one-line change to 
set "VERSION = 4.1.4" as some would expect. This is stupid, should be 
scripted, caused two rebuilds of binaries in 4.1.4 due to distraction.


If we have to release 4.1.5 (not foreseen at the moment) we will want to 
spend our time in actually fixing the bugs, and not in the painful 
update of release numbers here and there. If we do it now, and maybe 
take the occasion for scripting it, we won't risk useless delays.


This is all I wanted to say, and I hope it's clear now.

We could go on for ages discussing branching models, but the point of 
this thread was actually to address the problem with actually changing 
release numbers in code, nothing else.


Regards,
  Andrea.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [PROPOSAL] Managing branches for future releases

[Dave Fisher]

Hi -

I’ll bite on a discussion. Overall I think that we are mixing two different 
purposes.

(1) Keeping track of what is or may be released. This is what the current 
scheme does well when we are on a branch and not so well when we are on trunk.
(2) Managing the lifecycle of a particular release. You propose a fairly common 
step model. I think that we go to a release branch sometime in your TEST.

We have a very complex build process where a little change on Windows might 
make the Unix or Mac build unstable.

I would propose that we operate more like so.

We have two types of branches.

(A) Release branches as we do now. These have Test, Release and Maintenance 
phases. In this case all of our 4.1.X branches including 4.1.5 are in 
maintenance.
(B) Feature branches would be new for AOO. In these branches we co-operate 
between DEV and Test phases. We work out build issues on each platform for the 
feature in isolation. Community testers can be given test builds, etc.

Branches are merged to Trunk or a Release at certain times in the lifecycle. 
When a merge is done a phase of TEST is required on the result.

Example.

(1) Create an SDBC feature branch from trunk.
(2) Create a 4.2.0 release branch from trunk.
(3) Create an update Java feature branch from trunk.
(4) Develop and test the Java update.
(5) Merge the Java feature branch to SDBC feature branch.
(6) Develop and test the SDBC feature branch.
(7) Merge the SDBC feature branch to trunk and TEST.
(8) Merge trunk to 4.2.0 release branch.
(9) Test the 4.2.0 release branch.
(10) Release 4.2.0.

Other feature branches could be:
- Sign the Mac Application with an Apple Developer key.
- Bullet proof Windows Installer to reject spammers.

Regards,
Dave


> On Oct 27, 2017, at 2:28 PM, Peter Kovacs  wrote:
> 
> 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---xx--x-+-A---x--x---x-
> Dev xx-+-xxx-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--xx-+-xx---x-x--x--xx--xx-x+-+--x--x---x-
> 4.1.4 -x--x---+
> 4.1.5 +--x--x---x+
> 4.2.0+-xx---x-x--x--x---xx--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 

Re: [PROPOSAL] Managing branches for future releases

[Marcus]

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.


[ looong 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: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [PROPOSAL] Managing branches for future releases

[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.
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---xx--x-+-A---x--x---x-
Dev xx-+-xxx-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--xx-+-xx---x-x--x--xx--xx-x+-+--x--x---x-
4.1.4 -x--x---+
4.1.5 +--x--x---x+
4.2.0+-xx---x-x--x--x---xx--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 

Re: [PROPOSAL] Managing branches for future releases

[Marcus]

Am 26.10.2017 um 07:03 schrieb Peter kovacs:

Am 25. Oktober 2017 21:25:42 MESZ schrieb Marcus :


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

:

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: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [PROPOSAL] Managing branches for future releases

[Jim Jagielski]

+1. Having a branch ready to roll is cheap insurance.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [PROPOSAL] Managing branches for future releases

[Don Lewis]

On 26 Oct, Peter kovacs wrote:
> 
> 
> Am 25. Oktober 2017 21:25:42 MESZ schrieb Marcus :
>>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 

Re: [PROPOSAL] Managing branches for future releases

[Peter kovacs]

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 :
>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: dev-unsubscr...@openoffice.apache.org
>For additional commands, e-mail: dev-h...@openoffice.apache.org

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [PROPOSAL] Managing branches for future releases

[Peter kovacs]

Am 25. Oktober 2017 21:25:42 MESZ schrieb Marcus :
>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
>:
>>> 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 

Re: [PROPOSAL] Managing branches for future releases

[Pedro Lino]

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

Re: [PROPOSAL] Managing branches for future releases

[Marcus]

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: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [PROPOSAL] Managing branches for future releases

[Marcus]

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 :

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

Re: [PROPOSAL] Managing branches for future releases

[Kay Schenk]

On Tue, Oct 24, 2017 at 4:00 PM, Patricia Shanahan  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"

Re: [PROPOSAL] Managing branches for future releases

[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.

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 :
>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: dev-unsubscr...@openoffice.apache.org
>For additional commands, e-mail: dev-h...@openoffice.apache.org

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [PROPOSAL] Managing branches for future releases

[Matthias Seidel]

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: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [PROPOSAL] Managing branches for future releases

[esh1907]

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 
wrote:

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

Re: [PROPOSAL] Managing branches for future releases

[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 unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [PROPOSAL] Managing branches for future releases

[Mechtilde]

+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: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 

-- 
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
Description: OpenPGP digital signature

Re: [PROPOSAL] Managing branches for future releases

[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: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [PROPOSAL] Managing branches for future releases

[Andrea Pescetti]

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: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [PROPOSAL] Managing branches for future releases

[Kay Schenk]

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: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

[PROPOSAL] Managing branches for future releases

[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.


Regards,
  Andrea.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org