Martin Sebor wrote:
Only when your CLA shows up on the page below will we be able
to request an account for you:
http://people.apache.org/~jim/committers.html
A footnote, sometimes these fall out of sync; the master reference
that's accessible to Martin and other members / officers is at
FYI, it's live.
---BeginMessage---
A new wiki has just been created by root.
Wiki name: stdcxx
Wiki title: Apache C++ Standard Library
Commits:[EMAIL PROTECTED]
PMC notify: [EMAIL PROTECTED]
---End Message---
William A. Rowe, Jr. wrote:
About Noon CDT I'll make the transition from
http://svn.apache.org/repos/asf/incubator/stdcxx/
to
http://svn.apache.org/repos/asf/stdcxx/
This move is complete. If you attempt to svn up/diff/etc you will get
the error message:
svn: REPORT request failed
Martin Sebor wrote:
E.g., we don't want to change links like this:
http://svn.apache.org/viewcvs.cgi/incubator/stdcxx/trunk/src/time_put.cpp?rev=368527view=log
even though the file log is now at:
http://svn.apache.org/viewvc/stdcxx/trunk/src/time_put.cpp
and changing it (removing incubator/
Want to ensure this is as easy as possible, if you think you might
trip over this move, I'll be on irc.freenode.net #asf channel right
before the move.
About Noon CDT I'll make the transition from
http://svn.apache.org/repos/asf/incubator/stdcxx/
to
http://svn.apache.org/repos/asf/stdcxx/
Martin Sebor wrote:
Does anyone have any experience with either engine that might be
helpful in deciding between the two? Or preference for one over
the other?
All the projects I participate in use the MoinMoin wiki, and are
essentially happy with it.
Bill
Attached for your consideration,
Bill
Index: stdcxx/ChangeLog
===
--- stdcxx/ChangeLog (revision 603963)
+++ stdcxx/ChangeLog (working copy)
@@ -1,3 +1,7 @@
+2007-12-13 William Rowe [EMAIL PROTECTED]
+
+ * README: Struck
Martin Sebor wrote:
I see. Well, there's nothing we can do about that. I guess we'll have
to live with the compiler-specific #ifdefs in our code. I tell you, if
it weren't for Microsoft porting would be so boring... ;-)
C'mon - you can't say that aix CC and hpux aCC don't provide endless
Martin Sebor wrote:
I meant the problems that Liviu was talking about. I.e., if someone
is using a debug build of stdcxx 4.2.0 on Windows, will they be able
to step through stdcxx code? If not, I think it would be worthwhile
to document why and point them to a patch they can download to make
it
Although we've held the graduation vote, the board hasn't processed the
request. This month's report should probably be our presumed-final
incubation report and recap the graduation process, eh?
These are our last comments the board will read prior to voting on the
new top level project
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.
I agree with Travis' concerns.
I'd hint for something like requires consensus of the committers.
In order to ensure that all
Farid Zaripov wrote:
As they say, it's combined into the output .pdb, but in
general the src pdb contains information useless to anyone
except the object linker, so it is bloated.
Agreed. Fixed thus: http://svn.apache.org/viewvc?rev=590686view=rev
A fun way to test 'for free' without loading
Farid Zaripov wrote:
I don't completely understand which one unstable results could be?
After the patch:
1. in static builds the source pdb is generating in OutDir with
the name libstdxx.pdb; the binary pdb doesn't exist since the
static library is produced by lib.exe, but not by
[EMAIL PROTECTED] wrote:
Author: faridz
Date: Thu Oct 25 10:40:21 2007
New Revision: 588290
URL: http://svn.apache.org/viewvc?rev=588290view=rev
Log:
2007-10-25 Farid Zaripov [EMAIL PROTECTED]
* projectdef.js (projectCreateVCProject): Generate .pdb file
in $(OutDir) instead of
William A. Rowe, Jr. wrote:
patched, but combining them may lead to some unstable results and also
bloated .pdb's without benefits to the debugger (?).
Footnote - source .pdb's for a static .lib file that you distribute /are/
interesting to the end user, but you shouldn't generate one source
For dynamic libs, use /Fd to point to a DIFFERENT file name, because
that source-code .pdb is unrelated to the resulting binary .pdb that
results from link /debug /opt:ref (otherwise indistinguishable from
link /release but for massively useful information :-) I've taken
to calling these
Martin Sebor wrote:
I should have read the Graduation Guide more carefully -- my bad.
:)
Unless one of you has already beat me to it, I'll forward the
resolution in the expected format to the Board in time for the
next meeting, i.e., at least 3 days prior to 11/14.
Please do - in fact you
Farid Zaripov wrote:
But personally for me the version in the version info resource
would be more interesting. BTW there are more fields, i.e.
Copyright, Product Name, Company Name, Description, ...
From your answer, I presume it's no.
Martin Sebor wrote:
Are we making use of it? If not, should we be?
http://msdn2.microsoft.com/en-us/library/h88b7dc8(VS.80).aspx
It's not terribly interesting.
You really want to focus on the VERSIONINFO member of the library's dll
resource,
which provides a whole lot more meaningful
Martin Sebor wrote:
Just a heads up: I plan to make this change today. If anyone has
any concerns, please speak up now.
The trouble of course is that you break local checkouts unless those
folks use 'svn switch' to flip the repository location.
One alternative is to leave 4.2.0 in place for
Farid Zaripov wrote:
From: Martin Sebor [mailto:[EMAIL PROTECTED]
I just found out that the /Ehc flag enables the nothrow default for C
linkage functions. So changing the /EHsc flag to /EHs will fix this
for both VC7 and 8.
Do you happen to know if there's a #pragma that will let us
Martin Sebor wrote:
Here are a couple of articles from the Intel Knowledge Base that don't
appear to come with a restrictive license or even a copyright. The code
is Windows-specific but it should be possible to translate it to
something understandable to gcc and other compilers (Sun C++ on
Martin Sebor wrote:
1. Preparations.
i) Complete (and sign off) tasks documented in the status file.
Status file needs to be updated. The page that's up on the site
doesn't reflect the most recent changes to the file (see below).
The last time I tried to get the site
Amit Jindal wrote:
+1 definitely!
I have no doubt on the stability or the quality of this library. Its rock
solid
as it always has been.
Keep in mind, the 'graduation' isn't about releasing the library
(we've had one incubating release, and could have more at whatever
point we wanted).
Martin Sebor wrote:
In order to propose graduation to the Incubator PMC we all need to
formally agree that we are ready. This is a vote to ascertain this
agreement.
[+1] Check here (or use +1) to indicate you agree that stdcxx is
ready to graduate.
With a caviat - I'd expect the
Martin Sebor wrote:
Btw., does APR use RAT? If so, could you point us at the files
and supporting infrastructure you use to set it all up so we
could see if we could get it done quickly ourselves?
We never have that I know of - but as APR was written from the ground
up as an httpd project
Martin,
I'm thinking you could use this snapshot as a plea for someone on
[EMAIL PROTECTED] to run RAT against either a snapshot, or against
the subversion tag, if they have RAT installed and handy?
Bill
Martin Sebor wrote:
With Andrew's help I've created a page with the build and test
Martin Sebor wrote:
It got started but we never did go through all the files to check
that we didn't miss any (which we of course did). I just finished
a sweep through our sources and updated those that still needed
it. The record of the changes is here:
[How's that for optimism? please not corrected stdcxx-dev list address]
I'm including general in this thread to give the incubator community
some small insight into stdcxx's efforts and next steps to graduate.
As far as I can see there are no remaining obstacles.
Noel J. Bergman wrote:
William A. Rowe, Jr. wrote:
diversity is increasing (we wish it were broader, but I suspect this
project with the visibility of full ASF status will attract additional
committers who might have been hedging their bets on whether or not
the project would survive
Martin Sebor wrote:
I think the discussion has wound down so let's have a vote and
decide whether stdcxx committers should follow the Commit-Then
Review (CTR) or Review-Then-Commit (RTC) policy on stdcxx/trunk
by default.
[+1] All committers follow Commit-Then-Review for safe changes,
* I'm qurious about http://incubator.apache.org/stdcxx/#committers.
Why some people are following CTR and others RTC?
quoting that page
Stdcxx Committers are Developers with commit (or write) access to the stdcxx
codebase. Except where noted, all stdcxx committers follow the
Review-Then-Commit
William A. Rowe, Jr. wrote:
* I'm qurious about http://incubator.apache.org/stdcxx/#committers.
Why some people are following CTR and others RTC?
quoting that page
Stdcxx Committers are Developers with commit (or write) access to the stdcxx
codebase. Except where noted, all stdcxx
Drat. F/W of the belated reminder.
---BeginMessage---
Well this sort of sucks - with everyone so busy at ApacheCon EU, we've
neglected to remind you of the deadline on the 9th (posted months ago) for
http://wiki.apache.org/incubator/May2007
Abdera
Lokahi
NMaven
RCF
ServiceMix
stdcxx
Tika
TSIK
Yes, it's that time again. Who wants to pick this up?
I strongly suggest it's time to contemplate graduation; we've
been working at stdcxx-private to ensure all the major contributors
are accounted for so we could graduate with a comprehensive list of
committers and PMC members.
After
Martin Sebor wrote:
I agree. I also don't like the IDE hiding the command line. I like
seeing the exact command line for each source file just as it would
be issued by make, even if it's the same as for all the other sources.
Note that .dsp exports into .mak format allow you to do just that,
Farid Zaripov wrote:
Hi All.
I have found another way to generate solution and project files.
This way is using VisualStudio Automation objects so we do not need to
worry about solution and project files format.
Drinking the kool-aid, eh :-?
Intermediating with solutions and projects
Great news! Thanks for keeping us in the loop.
Martin Sebor wrote:
Hi,
We have heard that the Tuscany developers have been exploring
the option of using Apache stdcxx as the common implementation
of the C++ Standard Library for Tuscany/C++. We are wondering
whether this is in fact the case
FYI
I'm very satisfied with the overall progress of stdcxx, but see two
obstacles to graduation;
* the bug tracking system is being well utilized to discuss patches,
but the dev list is still a bit quiet on the design-decision front.
It's important that decisions are open and not made in
Martin Sebor wrote:
Okay, so just to make sure we're all clear, the process we seem
to be converging on goes like this:
1. branch X.Y.Z/ from trunk/
2. with N starting at 1, tag the X.Y.Z/ branch X.Y.X-rc-N/ and
create the corresponding tarball, stdcxx-X.Y.Z-rc-N.tar.gz;
vote
Martin Sebor wrote:
I have no objection to tagging the 1.2.3 branch 1.2.3-rcN for each
tarball that's about to be voted on but I suspect that may not fully
address your concerns (i.e., the fact that there is a 1.2.3 branch
before an official release has taken place).
I do believe it does,
Okay, thank you both for the clarification.
Just out of curiosity, when would the Board be the Sponsor?
If, for example, the board privately negotatied the movement of a
project from it's old home, after it privately appealed to the ASF for
consideration in the incubator.
This would be a very
At 02:54 AM 8/18/2005, Justin Erenkrantz wrote:
On Thu, Aug 04, 2005 at 02:15:46PM -0600, Martin Sebor wrote:
Mentors:
While Justin is named as the stdcxx sponsor in the STDCXX proposal
http://mail-archives.apache.org/mod_mbox/incubator-general/200505.mbox/[EMAIL
PROTECTED]
the policy
43 matches
Mail list logo
