stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Travis Vitek" <>
Subject RE: [RFC] stdcxx release process
Date Mon, 05 Nov 2007 19:56:15 GMT

Section 2 [Roles During a Release] Paragraph 1 Sentence 6 reads 

    Changes to the Release Criteria require the consent of all

Are we comfortable with requiring all committers to agree? If the stdcxx
committers is truly a diverse community, then not every committer will
be available to vote at any given time. Someone will be in Fiji for two
weeks. Not only that, but I currently see a list of 13 committers
[], 3 of which are
'retired'. Of the remaining 10 I've only seen messages from 6 of them in
the past 3 months or so. Of those 6, only a handful are actually
involved in the release process.

Section 4 [Primary Target Platforms] Paragraph 1 Sentence 1 reads

    A known set of platforms deemed to be the most important for the

I'm curious to hear what the criteria for selecting these platforms will
be. Would there be a vote, would the information be gathered from some
external source, or do we draw names and versions from a hat?

What are the rules for maintaining platforms on this list. i.e. if Sun
Studio 12 on Solaris 10/SPARC is a Primary Platform this release, can it
be expected to be a primary platform next release or can it be an
Unsupported Platform?

What are the rules for deprecating a platform? We may have claim Compaq
C++ 6 on Tru64 V6 is a Best Effort platform this release, but how and
when do we decide to move that platform off to the Unsupported Platform

Section 4 [Primary Target Platforms] Paragraph 1 Sentence 2 reads

    Typically, this is a set of combinations of compilers, operating
systems, and hardware architectures, and their major versions.

Don't minor and maintenance versions of compilers fix bad behaviors such
as internal compiler errors? If this is the case, then is 'major
version' is a reasonable criteria for defining a target platform?i.e.
Assume gcc 3.4.6-3 fixes an ICE that occurred in 3.4.4-2. As part of the
release process we would be required to make _all_ 3.x.y-z versions of
gcc work without warning, assertion or error. Is that reasonable?

In addition, we may not have all versions of some compilers at our
disposal for testing. In the environment I'm using, only a few versions
of gcc are available. If we define a primary platform using the major
version, do we need to validate all of the released versions?

What about future versions of the OS/compiler? We may know that stdcxx
builds and runs cleanly with Sun Studio 12 on Solaris 10/SPARC, but how
will it behave with a compiler patch that hasn't been released yet?
Shouldn't we only claim support for versions of the compiler prior to
and including the latest version tested with?

Section 7 [Unsupported Platforms] Paragraph 1

Should we have a separate category for all platforms for which the state
is unknown? The Unsupported Platform category seems to indicate that we
explicitly provide a list of those unsupported platforms. There will be
many configurations that we just don't know if they work, or we don't
care. We shouldn't have to explicitly list all platforms that we haven't
tried or don't know about. Maybe this section should get a disclaimer
that allows us to include any platform not mentioned in the Primary,
Secondary or Best Effort Platform categories.


>-----Original Message-----
>From: Martin Sebor [] On Behalf Of Martin Sebor
>Sent: Wednesday, October 31, 2007 9:11 PM
>Subject: [RFC] stdcxx release process
>I've checked in the first draft of a document outlining our release
>process. It should be read along with the versioning policy that was
>circulated earlier. I would like to integrate both into one coherent
>policy in the near future and put it in place for 4.2.1.
>Please respond with suggestions for changes, additions, corrections,
>comments, and/or questions.

View raw message