stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: [RFC] stdcxx release process
Date Mon, 05 Nov 2007 23:58:36 GMT
Travis Vitek wrote:
> 
> Section 2 [Roles During a Release] Paragraph 1 Sentence 6 reads 
> 
>     Changes to the Release Criteria require the consent of all
> committers.
> 
> 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.

Good catch! That's not what I meant. As Bill suggests, "consensus
among all interested committers" would be a better phrase. Let me
fix it.

> Not only that, but I currently see a list of 13 committers
> [http://incubator.apache.org/stdcxx/#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.

That's a valid point. We should discuss in a separate thread how to
get more people involved in the project.

> 
> 
> Section 4 [Primary Target Platforms] Paragraph 1 Sentence 1 reads
> 
>     A known set of platforms deemed to be the most important for the
> release.
> 
> 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?

We can certainly have a vote. It's important to remember that is
an open forum where everyone's input counts. If there is a broad
user base (or even a single vocal user or entity) that wants to
argue for a platform to receive more attention than any other,
they are free to do so. Their input will certainly be when we
as committers make our decision. In the absence of such input
we'll make our own decision :)

IIRC, Mark suggested (at least) Linux and Windows as the primary
platforms because they are the most widely used platforms by
potential committers. I agree that those should be among them,
but, personally, I don't think we should stop there. Solaris is
a major platform for us, especially since the KDE team has been
using stdcxx as their default C++ Standard Library, but also
because Sun C++ comes with an ancient version of our library.
I also think that HP aCC is an important platform because like
Sun, HP ships an older version of the Rogue Wave C++ Standard
Library with aCC and its users are likely to be interested in
upgrading to a more recent version of our library. HP might also
be inclined to do the same once we've implemented the new C++
Standard Library features. Ditto for Sun. There could hardly
be a more significant accomplishment for stdcxx and a better
opportunity to recruit potential committers than having a major
compiler vendor ship it as their default library.

Besides these four, the library that comes with IBM XLC++ has
been known to have issues that stdcxx doesn't suffer from, so
even it seems like a good candidate.

I'm tempted to think of platforms like gcc on OS/X and Intel C++
(either Linux or Windows) as Secondary simply because I suspect
they are as heavily used as the others. I could certainly be
wrong here and I'm looking for input from others.

Platforms like MIPSpro on IRIX and HP/Compaq C++ on Tru64 strike
me as good candidates for Best Effort platforms because they are
at the end of their lifespan. (I'm on the fence between Secondary
and Best Effort for HP/Compaq C++ on Tru64 only because it comes
with Rogue Wave libstd 3.0).

So to recap, here's my rough breakdown of 4.2.0 platforms by OS
(with the latest default compiler on each):

Primary: AIX 5.3 (POWER), HP-UX 11.31 and 11.23 (both IPF and PA),
          Fedora Core 6 (x86 and x86_64), Red Hat Enterprise Linux
          5.0 (x86 and x86_64), SuSE Enterprise Linux 10.0 (x86 and
          x86_64), Solaris 10 (SPARC, x86, and x86_64), Windows XP
          (x86 and x86_64), gcc 4.1.x on Solaris (x86, x86_64, and
          SPARC)

Secondary: AIX 5.2, FreeBSD 6.2 (x86 and x86_64), HP-UX 11.11 (PA),
            Red Hat Enterprise Linux 4 and 3 (x86 and x86_64), SuSE
            Enterprise Linux 9 (x86 and x86_64), Solaris 9, 8, 7
            (SPARC, x86, and x86_64), Intel C++ 9.0 and 10.0 on
            Linux and Windows

Best Effort: Mac OS X (x86 and x86_64), SGI IRIX 6.5 (MIPS),
              Windows 2000 and 2003 (x86 and x86_64)

Unsupported/Broken: Tru64 UNIX 5.1 (Alpha)

> 
> 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?

I don't think it would reasonable to make a recently released
compiler an unsupported platform as soon as it's superseded by
a newer one. Users don't tend to upgrade compilers as frequently
as compiler vendors put out new releases. My inclination would be
to target the most recent compiler version at the time of Feature
Freeze as a Primary Platform, and the remaining supported versions
of the same compiler as Secondary. Does that sound reasonable to
you?

> 
> 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
> area?

Unsupported are those that are known not to work. Maybe we could
find a better name. Is "Broken" better? If a target platform from
a previous release becomes unavailable for testing it should
probably be in a group of its own. "Unmaintained" maybe?

> 
> 
> 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?

They often do, although we usually try to work around them.

> 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?

I think we should try to work equally well with the most recent major
version of a compiler on every OS we target. We can't possibly make
certain that we actually do work equally well with all available
patches of all such compilers, but we can document how we verified
it (i.e., the patch number of each of these compilers that we
certified with).

So if the most recent gcc available at the time of our Feature Freeze
from Red Hat for their Enterprise Linux 5 is 4.1.1-52 we'll make it
our goal to verify the release criteria with this version and assume
the same quality for earlier patches of gcc 4.1.1, or even earlier
maintenance releases of gcc 4.1 on this OS. If our assumption turns
out to be wrong and someone reports a problem, we should, IMO, try
to deal with it as if it had been reported against the version we
actually did test with (within reason).

> 
> 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?

No, that wouldn't be feasible.

> 
> 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?

Yes, absolutely. We can't guarantee something that we don't know
anything about. Ideally, all new versions of every compiler would
be of the same quality as the last one or better but we all know
it doesn't always work out that way. stdcxx tries to adjust to
many kinds of compiler bugs and quirks (rather than hardwiring
assumptions about them), but we can never anticipate all kinds
of problems. But I think it's not unreasonable to claim that we
"support" compiler version 3.4.5 *and better* even if we never
tested any of the "better" versions.

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

The idea of Unsupported Platforms is to list those we've actually
tried to get to work (or someone has reported trying) and found
to be broken, and ideally also what the problem was. I agree that
it wouldn't make sense to list those we haven't even tried, or
such configurations.

Martin

> 
> Travis
> 
> 
>> -----Original Message-----
>> From: Martin Sebor [mailto:msebor@gmail.com] On Behalf Of Martin Sebor
>> Sent: Wednesday, October 31, 2007 9:11 PM
>> To: stdcxx-dev@incubator.apache.org
>> 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.
>>
>>     http://incubator.apache.org/stdcxx/releases.html
>>     http://incubator.apache.org/stdcxx/versions.html
>>
>> Please respond with suggestions for changes, additions, corrections,
>> comments, and/or questions.
>>
>> Thanks
>> Martin
>>


Mime
View raw message