Re: [Fwd: [jira] Closed: (INFRA-1424) create stdcxx UNIX group]
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 https://svn.apache.org/repos/private/foundation/officers/iclas.txt where Mark is definitely missing.
[Fwd: New wiki created: stdcxx]
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---
[Announcement] stdcxx Subversion repository moved
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 on '/repos/asf/!svn/vcc/default' svn: Target path does not exist You may first update to the final rev at that location; svn up -r 611450 and then a committer with a r/w checkout MUST svn switch https://svn.apache.org/repos/asf/stdcxx/trunk or any anonymous checkout MUST svn switch http://svn.apache.org/repos/asf/stdcxx/trunk Be sure you first issue an svn info in the directory you are moving so you which branch and where to switch to. The only change between the svn info of the checkout path and the new path is to drop /incubator from that path. Thank you for your patience
Re: Site documentation migrated
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/ from the first one) isn't supposed to work: http://svn.apache.org/viewvc/stdcxx/trunk/src/time_put.cpp?view=logpathrev=368527 Exactly; at that point in time (368527) it didn't live at /stdcxx/ but over at /incubator/stdcxx/. Good thing to note for anyone who's trying to review history ;-) Bill
SATURDAY Moving Day for stdcxx Subversion repository
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/ Following that move, you will want to jump into your stdcxx checkouts, for example trunk/ - you'll invoke the command svn switch http://svn.apache.org/repos/asf/stdcxx/trunk Be sure you first issue an svn info in the directory you are moving so you know where to switch to. For example, a committer must svn switch https://svn.apache.org/repos/asf/stdcxx/trunk using the https instead of http server. This message will be repeated upon completion. Bill
Re: stdcxx wiki
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
[patch] drop incubating disclaimer
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 incubating disclaimer, stdcxx is a top level project + 2007-10-16 Martin Sebor [EMAIL PROTECTED] * ChangeLog: Generated a single per-project ChangeLog. Index: stdcxx/README === --- stdcxx/README (revision 603963) +++ stdcxx/README (working copy) @@ -4,28 +4,9 @@ Apache C++ Standard Library (STDCXX) 4.2.0 -- - i. Disclaimer - - - - The ASF Incubation Policy requires every Podling (project of the - Apache Incubator) to include a clear disclaimer on its Web site and - in all documentation stating that it is undergoing incubation. The - following is the text of the required disclaimer. - - STDCXX is an effort undergoing incubation at the Apache Software - Foundation (ASF), sponsored by the Apache Incubator PMC. Incubation - is required of all newly accepted projects until a further review - indicates that the infrastructure, communications, and decision - making process have stabilized in a manner consistent with other - successful ASF projects. While incubation status is not necessarily - a reflection of the completeness or stability of the code, it does - indicate that the project has yet to be fully endorsed by the ASF. - - 0 Index - Disclaimer ... i Index 0 Contents . 1 Compatibility 1.1 @@ -156,12 +137,12 @@ - The distribution consists entirely of a single file named either - stdcxx-incubating-X.Y.Z.tar.gzforafinal release,or - stdcxx-incubating-X.Y.Z-MMDD.tar.gz for snapshots. + stdcxx-X.Y.Z.tar.gzforafinal release,or + stdcxx-X.Y.Z-MMDD.tar.gz for snapshots. To unpack the tarball, execute the following command: - $ gunzip -c stdcxx-incubating-X.Y.Z.tar.gz | tar -xf - + $ gunzip -c stdcxx-X.Y.Z.tar.gz | tar -xf - Above, X, Y, and Z are the major, minor, and micro version number of the library, respectively, and the optional -MMDD part is the
Re: [PATCH] MSVC has non-standard prototype of the wcstok()
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 hours of amusement, too :)
Re: [PING] Re: svn commit: r588290 - /incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js
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 possible (i.e., your change), or explain how to do it otherwise. They can step through a debug or release build. What is especially nice about using the (/Zi) flag to cc and (/debug /opt:ref) flags to link.exe is that your .exe looks like a unix stripped binary, no extra debugger noise, but that the .pdb contains all the binary - source/diagnostics you would wish from a unix -g build (unstripped). All that's required is that your favorite win debugger/dr watson can see the .pdb alongside the binary (or you put in some horribly complex pathing or resolve to a symbol server), and that somewhere you have the sources where the debugger can load them up. It will prompt the user for where is foo.c? In httpd, I'd simply set up a subdirectory of binaries (and I've now moved all of this to http://archive.apache.org/dist/httpd/binaries/win32/ in the symbols/ subdirectory - so it never hits www. mirror server) and the rare soul who wants the symbols just unzip's them right on top of an installed program. If they really use a debug build, that's a different story, you want those to use /O- no-optimization flags so that single stepping is not half as confusing ;-) Bill
[Fwd: November Incubator Reports]
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 resolution ;-) Bill Original Message Subject: November Incubator Reports Date: Sun, 4 Nov 2007 13:57:27 -0500 From: Noel J. Bergman [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] It's that time again ... :-) The Board is meeting at ApacheCon, so we're going to need to be a bit earlier this month. Please have your reports completed by THIS WEEKEND at the latest. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RFC] stdcxx release process
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 committers have a voice in the discussion, Release Criteria votes will run no less than 10 days. It should go without saying that discussion happens on [EMAIL PROTECTED] So no, a committer might be overruled if the vast majority of the PMC votes in favor of the change. But their voice should be heard and respected, and their concerns addressed if possible. If you are in Fiji for 2 weeks, of course, enjoy yourself and trust your fellow committers to express your concerns LOL Bill
Re: svn commit: r588290 - /incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js
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 up a ton of visual studio onto a given machine (e.g. a QA/test box) is to use WinDbg; http://www.microsoft.com/whdc/devtools/debugging/default.mspx this will help validate that .pdb's are usable.
Re: svn commit: r588290 - /incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js
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 link.exe. This is exactly what you want, yes! 2. in dynamic builds the source pdb and the binary pdb both generating in OutDir using the single file with the name libstdxx.pdb. This one is more problematic. Source and Binary .pdb's are two different file formats, you've corrupted the one creating the other. You might want to deploy the source pdb as $(IntDir)/stdlibxx_src.pdb - which is as temporary as any of the object files in the build. But - if you tweak one file and recompile, you won't have problems with the resulting $(OutDir)/stdlibxx.pdb losing any context from the previous .pdb for the modules that aren't rebuilt. So you propose to revert the patch only for dynamic builds? Don't revert, you were on the right track :) I'd just take this one step further as I mentioned above.
Re: svn commit: r588290 - /incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js
[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 $(IntDir). Use common .pdb file instead of two (compiler's and linker's). Are you sure you didn't mean to continue inverting these, therefore storing the compiler's pdb results in the IntDir? Yes, the resulting link-output pdb must reside in OutDir as you have patched, but combining them may lead to some unstable results and also bloated .pdb's without benefits to the debugger (?). Bill
Re: svn commit: r588290 - /incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js
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 pdb anyways for both the static and dynamic compilation of the library.
Re: Use of /Fd option on Windows
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 /FdRelease\libapr_src where _src is a different collection of pdb info from the libapr-1.pdb that corresponds to a dll. For static libs, I've taken to compiling all the lib's sources into a /Fd pdb named for the static lib, so that they move nicely together. E.g for apr-1.lib static library, /FdRelease\apr-1 gives us a nice source-code pdb. Once apr-1.lib+apr-1.pdb have been link /debug 'ed into a resulting binary, neither is interesting anymore, so these are very much for the library consumer. Bill
Re: [Fwd: [VOTE RESULT] graduate stdcxx to TLP]
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 can go ahead and do that now, we'll make sure it lands in the agenda.
Re: /VERSION linker option on Windows
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. http://svn.apache.org/repos/asf/apr/apr/trunk/libapr.rc would be a source example (ignoring the oodles of garbage microsoft typically fills .rc source files with.)
Re: /VERSION linker option on Windows
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 information to the user/developer. I presume you already attach that? Bill
Re: renaming branches/4.2.0 to branches/4.2
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 now, and fix this at the time you move the entire svn from it's incubation location over to a TLP (top level project) subversion location, which breaks everyone anyways.
Re: svn commit: r565959 - /incubator/stdcxx/trunk/etc/config/src/EXTERN_C_EXCEPTIONS.cpp
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 select the mode we need for just the one function? There's no #pragma for that, but we can compile all cpp files with /Ehsc, and some set of specified files with /EHs. But, there is __declspec(throw) - right?
Re: atomic tests timing out on Windows
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 x86). How to Determine Whether a Processor Supports Hyper-Threading Technology: http://www3.intel.com/cd/ids/developer/asmo-na/eng/dc/threading/knowledgebase/43843.htm How to Determine the Number of Logical Processors per Physical Processor: http://www.intel.com/cd/ids/developer/asmo-na/eng/dc/threading/knowledgebase/43842.htm If you are looking for BSD-license compatible logic for this, I'm just guessing that the BSD OS sources themselves might be a great resource. Bill
Re: next steps toward graduation
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 updated using the Apache infrastructure I ran into a number of problems that I wasn't able to overcome even with the help of other on [EMAIL PROTECTED] Maybe someone else can take a crack at it this time -- who's willing to take this on? Martin, send me a patch to the xml source and I'll be happy to apply it and regenerate the site. 4. Subproject acceptance VOTE by destination Project (subproject candidates only). [Not applicable.] The remaining two are not quite relevant yet. Right, the IPMC votes, then the board votes. 5. Incubator PMC (IPMC): i) For top level candidates, this is a recommendation VOTE. ii) For subproject candidates, this is a graduation approval VOTE. That's next.
Re: [VOTE] ready to graduate
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). It's about the quality of the community. While still small, and while there is still a preponderance of employees of one company, I'll say my observation is this *community* is rock solid and standing on solid Apache Software Foundation principals. To twist your words, lets Let Get Them Out of incubation :) Bill
Re: [VOTE] ready to graduate
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 crew to run the next possible release tarball against the RAT tool to make sure every copyright licensing wrinkle has been ironed out. That can happen before, or after graduation.
Re: [VOTE] ready to graduate
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 (even httpd fragments were reviewed and adjusted for their new home) it wasn't quite the concern as a large wholesale import. But it sure is an interesting idea, and I plan to bug rdd and fill you in when I learn more. Summer is just a horrible time for me to add more todo's to my list :) Bill
Re: 4.2.0 build and test results
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 results of the stdcxx/4.2.0 branch to use as a baseline after the merge from trunk I'm planning to do later today: http://people.apache.org/~sebor/stdcxx-4.2.0/results/ Andrew, I'm having trouble opening the logs. Instead of opening them up in the browser it pops up the What should SeaMonkey do with this file? window. I know we (or was it just me?) had this problem before (https://issues.apache.org/jira/browse/INFRA-989) but I can open the new logs for trunk just fine. Any idea? Does it work for you? Martin
Re: STDCXX progress to graduation
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: https://issues.apache.org/jira/browse/STDCXX-457 Had you happened to run RAT through the sources yet?
STDCXX progress to graduation
[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. http://incubator.apache.org/stdcxx/ is of a caliber higher than expected in open source efforts, the new steady contributors are recognized quickly with commit access (and later then with 'PMC membership' in the form of their PPMC), and 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 incubation.) It's survived, the community appears healthy - most code-discussion occurs in the actual jira incidents that the discussion applies to, and things are as quiet as expected for a mature implementation of a reference standard. Even issues raised by board/IPMC have been addressed quickly and sufficiently. (The issue with two-classes of CTR and RTC committers is resolved, while The Committers in italics do not have a signed Contributor License Agreement on file. comment does not and will not become applicable, and can be removed the next time that file is touched.) If anyone has concerns about stdcxx's graduation, please share them with the [EMAIL PROTECTED] community. Bill
Re: STDCXX progress to graduation
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 incubation.) What effect do you believe GPLv3 will have, now that the FSF is acknowledging that GPL projects may freely take advantage of Apache Licensed code? I suspect most GPL authors already felt quite free to combine and ship AL code in their GPL developer toolchains, when useful. Most J2 stacks haven't bothered to replace every .jar, they consume AL libraries when it suits their purpose. It would be really cool to see some of the FLOSS C++ groups to both consume and contribute to stdcxx, we'll see what happens. As far as other packagers blending proprietary and open source solutions, the very nature of an 'incubating' ASF project says we don't yet give it our full confidence, so a packager is behind the curve to rely on any project until it's graduated. We'll learn what the real delta is some year after stdcxx has graduated. things are as quiet as expected for a mature implementation of a reference standard. Any concern that because of the maturity, it could stagnate and lose community? Not at this time. Because it is widely deployed, there will be a long term demand. Because it's transparent to the developer, and in debugging their apps they can drill right into flaws within stdcxx, I suspect we will see bug feedback folks turn patchers turn contributors turn project members for years, as long as C++ is a widely adopted language. Bill
Re: [VOTE] commit-then-review vs review-then-commit policy
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, Review-Then-Commit for potentially breaking changes. What constitutes a breakng change is a judgment call to be made by each committer. The rule of thumb is that changes which involve advanced/sophisticated C++ features, C99 features, or optional POSIX (and other) extensions may cause breakage on some platforms. [+/-0] All committers follow Review-Then-Commit for all changes with no exceptions. [-1] New committers and committers who haven't been active in more than [ ] months follow the RTC policy for at least [ ] weeks of sustained activity, all others CTR. Please check the box you're voting for (or put +1/-1 in any or all of them). When voting for #3, also put numbers in the two [ ] boxes to complete the rules. I was concerned about the legitimacy of the last bullet, but the way in which you composed #3 leads me to merely disfavor it, not object to it as an invalid option. If the group accepted it, I don't think that a neutral, well-stated policy like this would be invalid to the ASF. Bill
Questions raised by May report
* 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 policy. The list of current committers in alphabetical order is below: I think this is a misunderstanding, but perhaps worse. The statement is that except where there is C-T-R code bases, svn operates under R-T-C. I don't believe this was ment to apply to individuals, please correct me if I'm wrong. Perhaps this should have been a seperate paragraph, and we shouldn't speak to the committers but instead all stdcxx repositories operate under... * Also, the comment committers in italics do not have a signed Contributor License Agreement on file doesn't make sense. You can't be a committer without a CLA on file. That's a non-sequitor, it's legacy from the original text. There *are* no italicized committer names. (This is common during the initial adoption phase, as established committers on the incoming project review the CLA language and raise questions about it.) I'll redact when there is clarification/decision on the paragraph above. Bill
Re: Questions raised by May report
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 committers follow the Review-Then-Commit policy. The list of current committers in alphabetical order is below: I think this is a misunderstanding, but perhaps worse. The statement is that except where there is C-T-R code bases, svn operates under R-T-C. I don't believe this was ment to apply to individuals, please correct me if I'm wrong. Having read this more closely, I see the comment next to sebor. My bad. This isn't acceptable, in that each Project/Podling of the ASF operates as a committee of equals. Therefore this isn't a legitimate distinction. STDCXX, would you rather operate entirely R-T-C, or C-T-R, for trunk? You can certainly call out *subversion* repositories or subsets that operate differently, but again with the same rule applied to each committer. Bill
[Fwd: WARNING - 2 days to deadline for May reports]
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 Tuscany Woden WSRP4J XAP Yoko must report. PLEASE rush to get this done, so we have time to review the reports and get them to the board. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ---End Message---
[Fwd: REMINDER: BOARD REPORTS]
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 navigating the incubating release process, sustained maintainance and development of the community it certainly seems like it's time to put this to a vote, once http://incubator.apache.org/projects/stdcxx is up to date. Thoughts before we start the graduation wheels turning? ---BeginMessage--- See http://wiki.apache.org/incubator/ReportingSchedule This month's reports are DUE BY February 14. That's next Wednesday. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] . ---End Message---
Re: Generation of the solution and projects for MSVC/ICC
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, if you would rather build from command line, while at the same time building within the gui if that's your preference. They broke exporting .mak files with the introduction of sln/vcproj format files, but you gain the ability to parallel compile in modern dev studio versions, it does log the commands invoked, and can be launched from the command line without the gui.
Re: Generation of the solution and projects for MSVC/ICC
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 provides a huge benefit of being able to unwind build problems with wrong flags, etc, something that the automation interfaces don't help much with.
Re: using stdcxx in tuscany/C++
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 and, if so, what the stdcxx team can do in order to make it as smooth as possible. Martin .
Steps twords graduations
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 the conference room amoung a closed circle of individuals. I believe adding tuscany folks to this effort, having a more diverse group of committers, will go a long ways to alleviating this quiet :) * the diversity remains an issue. Here again, having multiple groups of users who submit patches, become committers will go a long way in solving this issue as well. Although open source is ready when it's ready, I'd really like to look ahead to the end of September to attempt to graduate stdcxx. I know the current PMC understands the ASF concept, meritocracy etc, and is doing a noble job maintaining the codebase. Let's all watch these two areas so that we can retitle this effort as the Apache stdcxx Library [graduated]. Bill
Re: x.y.z numbering and releases
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 on tarball 3.1 if the vote passes, rename tarball to stdcxx-X.Y.Z.tar.gz and proceed to publish it 3.2 otherwise, fix problems on the X.Y.Z branch, increment N by 1 and go to 2 I like. Is there anyway we can rename branches/x.y.z/ in such a way as to avoid confusing users that it is the final release? E.g. branches/x.y.z-candidate/ ? When x.y.z is released, the original branches/x.y.z-candiate tree can be svn rm'ed. Bill
Re: x.y.z numbering and releases
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, granted the 1.2.3-rc3 branch would be internally labeled (version id) 1.2.3, but the branch it sits on and the tarballs it's packaged in both clearly designate 1.2.3. This resolves Justin's concern about rerolling the tarball, and addresses your concern that like several other Apache packages, you would like to have several review cycles. If there is an easy way to rename a branch I suppose we could start with a 1.2.3-not-an-official-release-yet (or whatever) branch and, once the release is approved, rename it to 1.2.3. svn rm? It's a lovely thing :) It would even point the file renamed back at the branch it originated from (documenting that yes, in fact the -rc3 candidate became official.) I wonder what it is about the ASF that makes us different from the other open source projects and that requires us to adopt such an unconventional policy. It's not, this isn't ASF policy, it's the original httpd committer's policy, so don't be surprized by Roy or others chiming in that there is only one right way :) It's been that way in httpd-land forever. But that doesn't mean that projects can't adopt, with appropriate safeguards against confusion, policies that match their own style. Bill
Re: who is stdcxx sponsor?
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 rare, very exceptional occurance. Also, perhaps the president has a project for the ASF's own infrastructure under his jurisdiction, and decides that it should be a project rather than an infrastructure effort. Mostly, it's a project with a related interest, or defaults to infrastructure's pmc if not. Bill
Re: who is stdcxx sponsor?
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 doesn't seem to allow for individuals to be sponsors. Sorry, as I replied to a few folk, I've been very busy at my own efforts at work :( But in terms of mentors, Justin and I are both here for you. And as far as the sponsor, yes, because you aren't coming in on a tangent, the incubator is your sponsor. Bill
