Potentially merging cxx-mem-model with mainline.

Potentially merging cxx-mem-model with mainline.

[Andrew MacLeod]

I'd like to have the cxx-mem-model branch considered for merging with 
mainline before we end stage 1 for GCC 4.7.

What it is
==========

GCC has had the __sync built-ins for atomic operations for a number of 
years now.  They implement a "sequential consistent" (AKA seq-cst) 
synchronization model which is the most restrictive (ie expensive) form 
of synchronization.  It requires that all processes can see a consistent 
value for other shared memory variables at the point of the atomic 
operation.  The new C++ standard defines other less restrictive modes 
which many newer architecture can make use of for improved performance 
in multi-threaded environments.  These will also allow the optimizer 
more freedom in moving code around as well.

This branch has developed a new set of atomic built-ins which include a 
memory model parameter and meet the atomic requirements of C++11.

During development, I've kept a wiki page pretty updates about what its 
all about, rooted here: http://gcc.gnu.org/wiki/Atomic/GCCMM

What it involves
===============

The new __atomic prefixed built-ins have been implemented with ease of 
target migration and maintenance in mind:

   - The __atomic expanders first look for a new __atomic RTL pattern 
and use that if present.
   - failing that, they fall back to using the original __sync 
implementation and patterns. This is less efficient if the memory model 
specified isn't seq-cst, but is correct in functionality.  This also 
means all the __atomic built-ins work correctly today if a target has 
__sync support.

The original __sync builtins now invoke the __atomic expanders with the 
seq-cst memory model.  This means that if a target has not been migrated 
to the new __atomic patterns, the __sync functions behave exactly as 
they do today (since __atomic expanders fall back to the original __sync 
patterns).   When a target does specify new __atomic RTL patterns, the 
legacy __sync routines will automatically start using those patterns.

This means that a target does not need to support both __atomic and 
__sync patterns.  Migrating involves simply renaming the __sync patterns 
and modifying them to deal with the memory model parameter.

There are new generic __atomic routines which provide support for 
arbitrary sized objects.  Whenever possible, atomic operations are 
mapped to lock-free instruction sequences. This is not always possible 
either due to target restrictions, or oddly/large sized objects.

The __atomic builtins leave external function calls for these cases, but 
they target a well defined library interface documented here: 
http://gcc.gnu.org/wiki/Atomic/GCCMM/LIbrary   I expect to spin off a 
small side project to implement this library in the next few months so 
that a library is easily available to resolve these calls.

With a few C++ template changes to utilize these new built-ins, 
libstdc++-v3  should have a fully functional implementation of atomics 
for this release.

What it doesn't do
=================

It does not address other missing aspects of the c++ memory model.  In 
particular, bitfields are still not compliant with not introducing new 
potential data races.

There are flags for load and store data races in mainline already, and 
some work has gone into limiting store data races, but testing is by no 
means thorough.


Whats left
===========
Functionality is pretty much complete, but there are a few minor lose 
ends still to deal with. They could be done after a merge, in the next 
stage, or required before... you tell me :-)

- potentially implement -f[no]-inline-atomics  (to never produce inline 
code and always call the library) and -f[no]-atomic-compare-swap-loop  
(To not fall back to a compare_and_swap loop to implement missing 
functionality)

- unaligned objects have undefined behaviour at the moment.  Behaviour 
could be defined and add alignment checks and a parameter to 
__atomic_is_lock_free() for alignment checking purposes.  Anything which 
doesn't map to one of the properly aligned  5 sized built-ins gets a 
library call.

- A bit of C++ template restructuring in the include files to remove the 
old fall back locked implementation and fully use the new __atomic 
builtins. (*in progress now*)

- Change external library calls for __atomic_op_fetch routines. (*patch 
submitted already*)

- There are a bunch of new tests that have been developed along the way, 
but I I expect to spend the next 2 months writing more detailed and 
specific runtime and compile time tests. And of course, fixing any of 
the fall out from those tests.

- There have been no new __atomic RTL patterns created. I was thinking 
about leaving this until the next release, but I suppose we could 
migrate a couple of the more popular targets

The final word
=============
So what is the opinion/consensus on merging the branch?  It would be 
nice to get this infrastructure in place for this release so we can get 
people to start using it, and then we can work out any issues that arise.

I'd have Aldy do the actual merge because if I do something will go amok 
for sure.  I wont be around this weekend to fix any fallout, but I am 
around until Friday evening.  I'm around all next week.  I don't 
anticipate much problem since this is all new functionality for the most 
part, and mainline was merged with the branch a week or two ago.

Andrew

Re: Potentially merging cxx-mem-model with mainline.

[David Gilbert]

On 26 October 2011 16:38, Andrew MacLeod <amacleod@redhat.com> wrote:
> I'd like to have the cxx-mem-model branch considered for merging with
> mainline before we end stage 1 for GCC 4.7.
>
> What it is
> ==========
>
> GCC has had the __sync built-ins for atomic operations for a number of years
> now.  They implement a "sequential consistent" (AKA seq-cst) synchronization
> model which is the most restrictive (ie expensive) form of synchronization.
>  It requires that all processes can see a consistent value for other shared
> memory variables at the point of the atomic operation.  The new C++ standard
> defines other less restrictive modes which many newer architecture can make
> use of for improved performance in multi-threaded environments.  These will
> also allow the optimizer more freedom in moving code around as well.
>
> This branch has developed a new set of atomic built-ins which include a
> memory model parameter and meet the atomic requirements of C++11.
>
> During development, I've kept a wiki page pretty updates about what its all
> about, rooted here: http://gcc.gnu.org/wiki/Atomic/GCCMM
>
> What it involves
> ===============
>
> The new __atomic prefixed built-ins have been implemented with ease of
> target migration and maintenance in mind:
>
>  - The __atomic expanders first look for a new __atomic RTL pattern and use
> that if present.
>  - failing that, they fall back to using the original __sync implementation
> and patterns. This is less efficient if the memory model specified isn't
> seq-cst, but is correct in functionality.  This also means all the __atomic
> built-ins work correctly today if a target has __sync support.
>
> The original __sync builtins now invoke the __atomic expanders with the
> seq-cst memory model.  This means that if a target has not been migrated to
> the new __atomic patterns, the __sync functions behave exactly as they do
> today (since __atomic expanders fall back to the original __sync patterns).
>   When a target does specify new __atomic RTL patterns, the legacy __sync
> routines will automatically start using those patterns.
>
> This means that a target does not need to support both __atomic and __sync
> patterns.  Migrating involves simply renaming the __sync patterns and
> modifying them to deal with the memory model parameter.
>
> There are new generic __atomic routines which provide support for arbitrary
> sized objects.  Whenever possible, atomic operations are mapped to lock-free
> instruction sequences. This is not always possible either due to target
> restrictions, or oddly/large sized objects.
>
> The __atomic builtins leave external function calls for these cases, but
> they target a well defined library interface documented here:
> http://gcc.gnu.org/wiki/Atomic/GCCMM/LIbrary   I expect to spin off a small
> side project to implement this library in the next few months so that a
> library is easily available to resolve these calls.

So what happens on a target that implements the __sync calls via
routines in libgcc
(e.g. older ARM) ?  Will the __atomic's get turned into the __sync calls?

Dave

Re: Potentially merging cxx-mem-model with mainline.

[Benjamin Kosnik]

> Whats left
> ===========
> Functionality is pretty much complete, but there are a few minor lose 
> ends still to deal with. They could be done after a merge, in the
> next stage, or required before... you tell me :-)
> 
> - potentially implement -f[no]-inline-atomics  (to never produce
> inline code and always call the library) and
> -f[no]-atomic-compare-swap-loop (To not fall back to a
> compare_and_swap loop to implement missing functionality)
> 
> - unaligned objects have undefined behaviour at the moment.
> Behaviour could be defined and add alignment checks and a parameter
> to __atomic_is_lock_free() for alignment checking purposes.  Anything
> which doesn't map to one of the properly aligned  5 sized built-ins
> gets a library call.


> - A bit of C++ template restructuring in the include files to remove
> the old fall back locked implementation and fully use the new
> __atomic builtins. (*in progress now*)

Hit me off-line about this. Hopefully I can help expedite.
 
> - Change external library calls for __atomic_op_fetch routines.
> (*patch submitted already*)
> 
> - There are a bunch of new tests that have been developed along the
> way, but I I expect to spend the next 2 months writing more detailed
> and specific runtime and compile time tests. And of course, fixing
> any of the fall out from those tests.

Yes. I don't see this as a blocker for the merge.
 

> The final word
> =============
> So what is the opinion/consensus on merging the branch?  It would be 
> nice to get this infrastructure in place for this release so we can
> get people to start using it, and then we can work out any issues
> that arise.
> 
> I'd have Aldy do the actual merge because if I do something will go
> amok for sure.  I wont be around this weekend to fix any fallout, but
> I am around until Friday evening.  I'm around all next week.  I don't 
> anticipate much problem since this is all new functionality for the
> most part, and mainline was merged with the branch a week or two ago.

I am really expecting this branch to be merged for 4.7. The current
status is very presentable IMHO.

-benjamin

Re: Potentially merging cxx-mem-model with mainline.

[Joseph S. Myers]

On Wed, 26 Oct 2011, Andrew MacLeod wrote:

> Whats left

Out of interest, do you have any plans for the C1X side of things 
(_Atomic, stdatomic.h etc.)?  That would of course be for 4.8 or later.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Potentially merging cxx-mem-model with mainline.

[Richard Guenther]

On Wed, Oct 26, 2011 at 6:31 PM, Benjamin Kosnik <bkoz@redhat.com> wrote:
>
>> Whats left
>> ===========
>> Functionality is pretty much complete, but there are a few minor lose
>> ends still to deal with. They could be done after a merge, in the
>> next stage, or required before... you tell me :-)
>>
>> - potentially implement -f[no]-inline-atomics  (to never produce
>> inline code and always call the library) and
>> -f[no]-atomic-compare-swap-loop (To not fall back to a
>> compare_and_swap loop to implement missing functionality)
>>
>> - unaligned objects have undefined behaviour at the moment.
>> Behaviour could be defined and add alignment checks and a parameter
>> to __atomic_is_lock_free() for alignment checking purposes.  Anything
>> which doesn't map to one of the properly aligned  5 sized built-ins
>> gets a library call.
>
>
>> - A bit of C++ template restructuring in the include files to remove
>> the old fall back locked implementation and fully use the new
>> __atomic builtins. (*in progress now*)
>
> Hit me off-line about this. Hopefully I can help expedite.
>
>> - Change external library calls for __atomic_op_fetch routines.
>> (*patch submitted already*)
>>
>> - There are a bunch of new tests that have been developed along the
>> way, but I I expect to spend the next 2 months writing more detailed
>> and specific runtime and compile time tests. And of course, fixing
>> any of the fall out from those tests.
>
> Yes. I don't see this as a blocker for the merge.
>
>
>> The final word
>> =============
>> So what is the opinion/consensus on merging the branch?  It would be
>> nice to get this infrastructure in place for this release so we can
>> get people to start using it, and then we can work out any issues
>> that arise.
>>
>> I'd have Aldy do the actual merge because if I do something will go
>> amok for sure.  I wont be around this weekend to fix any fallout, but
>> I am around until Friday evening.  I'm around all next week.  I don't
>> anticipate much problem since this is all new functionality for the
>> most part, and mainline was merged with the branch a week or two ago.
>
> I am really expecting this branch to be merged for 4.7. The current
> status is very presentable IMHO.

If you get (or already got) ack from maintainers covering the areas you
touch then I am fine with merging this branch for 4.7 from a RM point
of view.  You do not have too much time left though, see my upcoming
status report.

Thanks,
Richard.

> -benjamin
>

Re: Potentially merging cxx-mem-model with mainline.

[Andrew MacLeod]

On 10/27/2011 04:55 AM, Richard Guenther wrote:
>
>> I am really expecting this branch to be merged for 4.7. The current
>> status is very presentable IMHO.
> If you get (or already got) ack from maintainers covering the areas you
> touch then I am fine with merging this branch for 4.7 from a RM point
> of view.  You do not have too much time left though, see my upcoming
> status report.
>

Yeah, I forgot to mention in the original note,  either bkoz or rth 
approved pretty much everything on this branch before it got checked in.

I'll sync with Aldy, I suspect we'll try to merge it in monday Oct 31. 
that give me a little time to wrap a couple of little things up.  I'll 
confirm once we sort it out.

Andrew

Re: Potentially merging cxx-mem-model with mainline.

[Aldy Hernandez]

> It does not address other missing aspects of the c++ memory model.  In
> particular, bitfields are still not compliant with not introducing new
> potential data races.

Can we treat this as a bugfix to be done during stage2?  There is
already some support in mainline, but it performs lousy on anything but
the most simple of testccases.  After much iterations with Richi, we
couldn't come to an agreement on the remaining fixes.  I would like to
take another stab at this during stage2, if it is OK with Richi and
others.

Renaming Stage 1 and Stage 3

[Gerald Pfeifer]

On Mon, 31 Oct 2011, Ian Lance Taylor wrote:
> No opinion on your actual question, but note that there is no more
> stage2.  We now go directly from stage1 to stage3.  This is just another
> feature of gcc development seemingly designed to confuse newbies, and
> evidently even confuses experienced developers.

So, let's fix this!  In fact, this is something Mark, David and me
discussed at the last GCC Summit and which fell through the cracks
on my side.

Instead of renaming Stage 3 to Stage 2 at that point we figured that
using different terminology would reduce confusion.  I am not wedded
to Stage A and B, though this seems to be the most straightforward
option (over colors, Alpha and Beta carrying a different meaning in 
software development,...).

Thoughts?

Gerald

Index: develop.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/develop.html,v
retrieving revision 1.127
diff -u -3 -p -r1.127 develop.html
--- develop.html	22 Mar 2012 07:57:04 -0000	1.127
+++ develop.html	10 Jun 2012 21:54:42 -0000
@@ -97,30 +97,27 @@ well), then we can seriously confuse use
 
 <h3>Schedule</h3>
 
-<p>Development on our main branch will proceed in three stages.</p>
+<p>Development on our main branch will proceed as two main stages
+followed by concrete preparations for the release.</p>
 
-<h4><a name="stage1">Stage 1</a></h4>
+<h4><a name="stageA">Stage A</a></h4>
 
 <p>During this period, changes of any nature may be made to the
 compiler.  In particular, major changes may be merged from branches.
-Stage 1 is feature driven and will last at least four months.
-In order to avoid chaos, the Release Managers will ask for a list of
+Stage A is feature driven and will last at least four months.</p>
+
+<p>In order to avoid chaos, the Release Managers will ask for a list of
 major projects proposed for the coming release cycle before the start
 of this stage.  They will attempt to sequence the projects
 in such a way as to cause minimal disruption.  The Release Managers
 will not reject projects that will be ready for inclusion before the
-end of Stage 1.  Similarly, the Release Managers have no special
+end of this stage.  Similarly, the Release Managers have no special
 power to accept a particular patch or branch beyond what their status
 as maintainers affords.  The role of the Release Managers is merely
-to attempt to order the inclusion of major features in an organized
+to help order the inclusion of major features in an organized
 manner.</p>
 
-<h4><a name="stage2">Stage 2</a></h4>
-
-<p>Stage 2 has been abandoned in favor of an extended feature driven
-Stage 1 since the development of GCC 4.4.</p>
-
-<h4><a name="stage3">Stage 3</a></h4>
+<h4><a name="stageB">Stage B</a></h4>
 
 <p>During this two-month period, the only (non-documentation) changes
 that may be made are changes that fix bugs or new ports which do not
@@ -196,7 +193,7 @@ remain working, to avoid impeding other 
 
 <h3>Schedule</h3>
 
-<p>At the conclusion of Stage 3, the trunk will go into release
+<p>At the conclusion of Stage B, the trunk will go into release
 branch mode which allows documentation and regression fixes only.
 During this phase, the focus will be fixing any regressions
 from the previous release, so that each release is better than the one
@@ -204,7 +201,7 @@ before.</p>
 
 <p>At the point the trunk is in a state suitable for releasing
 a release branch will be created, a release candidate is made available
-and Stage 1 of the next release cycle starts.
+and Stage A of the next release cycle starts.
 The decision on when this point is reached is up to the Release Managers.
 In particular at this point no P1 regressions are present on the trunk.</p>
 
@@ -460,7 +457,7 @@ stages of development, branch points, an
        +-- GCC 4.7 branch created ------+
        |                                 \
        v                                  v
-  GCC 4.8 Stage 1 (starts 2012-03-02)      GCC 4.7.0 release (2012-03-22)
+  GCC 4.8 Stage A (starts 2012-03-02)      GCC 4.7.0 release (2012-03-22)
        |
        |
        v

Re: Renaming Stage 1 and Stage 3

[Richard Guenther]

On Mon, Jun 11, 2012 at 12:03 AM, Gerald Pfeifer <gerald@pfeifer.com> wrote:
> On Mon, 31 Oct 2011, Ian Lance Taylor wrote:
>> No opinion on your actual question, but note that there is no more
>> stage2.  We now go directly from stage1 to stage3.  This is just another
>> feature of gcc development seemingly designed to confuse newbies, and
>> evidently even confuses experienced developers.
>
> So, let's fix this!  In fact, this is something Mark, David and me
> discussed at the last GCC Summit and which fell through the cracks
> on my side.
>
> Instead of renaming Stage 3 to Stage 2 at that point we figured that
> using different terminology would reduce confusion.  I am not wedded
> to Stage A and B, though this seems to be the most straightforward
> option (over colors, Alpha and Beta carrying a different meaning in
> software development,...).
>
> Thoughts?

Eh - why not give them names with an actual meaning? "Development Stage"
and "Stabilizing Stage"?  I realize those are rather long names, but you
can always put short forms in tables, like Dev Stage and Stab Stage.

Richard.

> Gerald
>
> Index: develop.html
> ===================================================================
> RCS file: /cvs/gcc/wwwdocs/htdocs/develop.html,v
> retrieving revision 1.127
> diff -u -3 -p -r1.127 develop.html
> --- develop.html        22 Mar 2012 07:57:04 -0000      1.127
> +++ develop.html        10 Jun 2012 21:54:42 -0000
> @@ -97,30 +97,27 @@ well), then we can seriously confuse use
>
>  <h3>Schedule</h3>
>
> -<p>Development on our main branch will proceed in three stages.</p>
> +<p>Development on our main branch will proceed as two main stages
> +followed by concrete preparations for the release.</p>
>
> -<h4><a name="stage1">Stage 1</a></h4>
> +<h4><a name="stageA">Stage A</a></h4>
>
>  <p>During this period, changes of any nature may be made to the
>  compiler.  In particular, major changes may be merged from branches.
> -Stage 1 is feature driven and will last at least four months.
> -In order to avoid chaos, the Release Managers will ask for a list of
> +Stage A is feature driven and will last at least four months.</p>
> +
> +<p>In order to avoid chaos, the Release Managers will ask for a list of
>  major projects proposed for the coming release cycle before the start
>  of this stage.  They will attempt to sequence the projects
>  in such a way as to cause minimal disruption.  The Release Managers
>  will not reject projects that will be ready for inclusion before the
> -end of Stage 1.  Similarly, the Release Managers have no special
> +end of this stage.  Similarly, the Release Managers have no special
>  power to accept a particular patch or branch beyond what their status
>  as maintainers affords.  The role of the Release Managers is merely
> -to attempt to order the inclusion of major features in an organized
> +to help order the inclusion of major features in an organized
>  manner.</p>
>
> -<h4><a name="stage2">Stage 2</a></h4>
> -
> -<p>Stage 2 has been abandoned in favor of an extended feature driven
> -Stage 1 since the development of GCC 4.4.</p>
> -
> -<h4><a name="stage3">Stage 3</a></h4>
> +<h4><a name="stageB">Stage B</a></h4>
>
>  <p>During this two-month period, the only (non-documentation) changes
>  that may be made are changes that fix bugs or new ports which do not
> @@ -196,7 +193,7 @@ remain working, to avoid impeding other
>
>  <h3>Schedule</h3>
>
> -<p>At the conclusion of Stage 3, the trunk will go into release
> +<p>At the conclusion of Stage B, the trunk will go into release
>  branch mode which allows documentation and regression fixes only.
>  During this phase, the focus will be fixing any regressions
>  from the previous release, so that each release is better than the one
> @@ -204,7 +201,7 @@ before.</p>
>
>  <p>At the point the trunk is in a state suitable for releasing
>  a release branch will be created, a release candidate is made available
> -and Stage 1 of the next release cycle starts.
> +and Stage A of the next release cycle starts.
>  The decision on when this point is reached is up to the Release Managers.
>  In particular at this point no P1 regressions are present on the trunk.</p>
>
> @@ -460,7 +457,7 @@ stages of development, branch points, an
>        +-- GCC 4.7 branch created ------+
>        |                                 \
>        v                                  v
> -  GCC 4.8 Stage 1 (starts 2012-03-02)      GCC 4.7.0 release (2012-03-22)
> +  GCC 4.8 Stage A (starts 2012-03-02)      GCC 4.7.0 release (2012-03-22)
>        |
>        |
>        v

Re: Renaming Stage 1 and Stage 3

[Dodji Seketeli]

Richard Guenther <richard.guenther@gmail.com> a écrit:

> On Mon, Jun 11, 2012 at 12:03 AM, Gerald Pfeifer <gerald@pfeifer.com> wrote:
>> On Mon, 31 Oct 2011, Ian Lance Taylor wrote:
>>> No opinion on your actual question, but note that there is no more
>>> stage2.  We now go directly from stage1 to stage3.  This is just another
>>> feature of gcc development seemingly designed to confuse newbies, and
>>> evidently even confuses experienced developers.
>>
>> So, let's fix this!  In fact, this is something Mark, David and me
>> discussed at the last GCC Summit and which fell through the cracks
>> on my side.
>>
>> Instead of renaming Stage 3 to Stage 2 at that point we figured that
>> using different terminology would reduce confusion.  I am not wedded
>> to Stage A and B, though this seems to be the most straightforward
>> option (over colors, Alpha and Beta carrying a different meaning in
>> software development,...).
>>
>> Thoughts?
>
> Eh - why not give them names with an actual meaning? "Development Stage"
> and "Stabilizing Stage"?  I realize those are rather long names, but you
> can always put short forms in tables, like Dev Stage and Stab Stage.

Seconded, for what it's worth.

-- 
		Dodji

Re: Renaming Stage 1 and Stage 3

[Paolo Bonzini]

Il 11/06/2012 11:18, Richard Guenther ha scritto:
> > Instead of renaming Stage 3 to Stage 2 at that point we figured that
> > using different terminology would reduce confusion.  I am not wedded
> > to Stage A and B, though this seems to be the most straightforward
> > option (over colors, Alpha and Beta carrying a different meaning in
> > software development,...).
> >
> Eh - why not give them names with an actual meaning? "Development Stage"
> and "Stabilizing Stage"?  I realize those are rather long names, but you
> can always put short forms in tables, like Dev Stage and Stab Stage.

Or just "Development" and "Feature freeze"?

Paolo

Re: Renaming Stage 1 and Stage 3

[Andrew MacLeod]

On 06/11/2012 06:27 AM, Dodji Seketeli wrote:
> Richard Guenther<richard.guenther@gmail.com>  a écrit:
>
>> Eh - why not give them names with an actual meaning? "Development Stage"
>> and "Stabilizing Stage"?  I realize those are rather long names, but you
>> can always put short forms in tables, like Dev Stage and Stab Stage.
> Seconded, for what it's worth.
>
Indeed, that my first thought as well... make the name mean something.

Development and Stabilization work for me.

Andrew

Re: Renaming Stage 1 and Stage 3

[Diego Novillo]

On 12-06-11 08:20 , Andrew MacLeod wrote:
> On 06/11/2012 06:27 AM, Dodji Seketeli wrote:
>> Richard Guenther<richard.guenther@gmail.com> a écrit:
>>
>>> Eh - why not give them names with an actual meaning? "Development Stage"
>>> and "Stabilizing Stage"? I realize those are rather long names, but you
>>> can always put short forms in tables, like Dev Stage and Stab Stage.
>> Seconded, for what it's worth.
>>
> Indeed, that my first thought as well... make the name mean something.
>
> Development and Stabilization work for me.

Likewise.  I don't particularly care about the specific labels we use, 
as long as they have the right semantics.


Diego.

Re: Renaming Stage 1 and Stage 3

[Miles Bader]

Richard Guenther <richard.guenther@gmail.com> writes:
> why not give them names with an actual meaning? "Development Stage"
> and "Stabilizing Stage"?  I realize those are rather long names, but you
> can always put short forms in tables, like Dev Stage and Stab Stage.

The latter is when the knives come out, eh...?

-miles

-- 
Mayonnaise, n. One of the sauces that serve the French in place of a state
religion.

Re: Renaming Stage 1 and Stage 3

[Richard Guenther]

On Mon, Jun 11, 2012 at 4:15 PM, Miles Bader <miles@gnu.org> wrote:
> Richard Guenther <richard.guenther@gmail.com> writes:
>> why not give them names with an actual meaning? "Development Stage"
>> and "Stabilizing Stage"?  I realize those are rather long names, but you
>> can always put short forms in tables, like Dev Stage and Stab Stage.
>
> The latter is when the knives come out, eh...?

Yes.  You have been warned ;)

Richard.

Re: Renaming Stage 1 and Stage 3

[Jakub Jelinek]

On Mon, Jun 11, 2012 at 11:18:23AM +0200, Richard Guenther wrote:
> Eh - why not give them names with an actual meaning? "Development Stage"
> and "Stabilizing Stage"?  I realize those are rather long names, but you
> can always put short forms in tables, like Dev Stage and Stab Stage.

Shouldn't we have names for the 3 phases we actually use, rather than just
two?  I.e. development phase, stabilization phase (no new features,
bugfixes allowed) and release branch freeze phase (only regression bugfixes and
documentation, same as for release branches)?

	Jakub