Misha Bergal <[EMAIL PROTECTED]> writes:
> David Abrahams wrote:
>
>> It looks like you need to build your vc6 stlport debug
>> library also; that would account for the failure in the
>> testing library tests.
>
> Done.
Thanks for all the testing; the release looks pretty darned great!
http://ww
Aleksey Gurtovoy <[EMAIL PROTECTED]> writes:
> David Abrahams wrote:
>> Thanks for all the testing; the release looks pretty darned great!
>
> Just to make sure it's understood - although "expected", all the green
> failures are still failures. Not that we can do much about them, of course.
>
>>Fr
David Abrahams wrote:
> Thanks for all the testing; the release looks pretty darned great!
Just to make sure it's understood - although "expected", all the green
failures are still failures. Not that we can do much about them, of course.
>From a user POV, a darned great release would be the one f
David Abrahams wrote:
> It looks like you need to build your vc6 stlport debug
> library also; that would account for the failure in the
> testing library tests.
Done.
--
Misha Bergal
MetaCommunications Engineering
___
Unsubscribe & other changes: ht
Misha Bergal <[EMAIL PROTECTED]> writes:
> Misha Bergal <[EMAIL PROTECTED]> writes:
>
>> David Abrahams <[EMAIL PROTECTED]> writes:
>>
>> > I am slightly concerned about the number of unexpected failures with
>> > intel7.1-stlport. Is there a configuration problem?
>>
>> Yes, there is. The mai
David Abrahams <[EMAIL PROTECTED]> writes:
> Could you possibly do another regression run? There have been quite a
> few little changes since the last one.
Sure, actually we are running the regressions on RC_1_30_0
continuously, with the interruptions for configuration changes and
power outages
Misha Bergal <[EMAIL PROTECTED]> writes:
> David Abrahams <[EMAIL PROTECTED]> writes:
>
> > I am slightly concerned about the number of unexpected failures with
> > intel7.1-stlport. Is there a configuration problem?
>
> Yes, there is. The main trunks intel-win32-tools.jam,1.28 enables
> wchar
Misha Bergal <[EMAIL PROTECTED]> writes:
> "Misha Bergal" <[EMAIL PROTECTED]> writes:
>
>> "David Abrahams" <[EMAIL PROTECTED]> wrote in message
>> news:[EMAIL PROTECTED]
>> >
>> > Thanks. The hyperlinks to test failure logs don't ever scroll to the
>> > appropriate section of the output on IE6.
David Abrahams <[EMAIL PROTECTED]> writes:
> I am slightly concerned about the number of unexpected failures with
> intel7.1-stlport. Is there a configuration problem?
Yes, there is. The main trunks intel-win32-tools.jam,1.28 enables
wchar_t for our configuration but RC_1_30_0 intel-win32-tools
"Misha Bergal" <[EMAIL PROTECTED]> writes:
> "David Abrahams" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> >
> > Thanks. The hyperlinks to test failure logs don't ever scroll to the
> > appropriate section of the output on IE6.
Fixed
> The compiler_status changes from main tru
"David Abrahams" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> Thanks. The hyperlinks to test failure logs don't ever scroll to the
> appropriate section of the output on IE6.
The compiler_status changes from main trunk need to be integrated back to
RC_1_30_0 .
If I don't hear f
"Misha Bergal" <[EMAIL PROTECTED]> writes:
> "David Abrahams" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> "Bronek Kozicki" <[EMAIL PROTECTED]> writes:
>>
>> I another round of testing would be great. According to
>> ...
>>
> http://www.meta-comm.com/engineering/resources/cvs_
"Bronek Kozicki" <[EMAIL PROTECTED]> writes:
> David Abrahams wrote on July 16th:
>> Beman Dawes <[EMAIL PROTECTED]> writes:
> [...]
>>> How will we prevent a 1.30.1 release from delaying a 1.31.0 release?
>> By releasing one week from now?
>
> Hello
>
> what is current status for boost release 1.
David Abrahams wrote:
> Aleksey Gurtovoy <[EMAIL PROTECTED]> writes:
>
> > Any reason you cannot use
> >
http://www.meta-comm.com/engineering/resources/cvs_RC_1_30_0/developer_summary_page.html?
>
> None, in particular. This table is a little weird though:
>
>
http://www.meta-comm.com/engineering/
Beman Dawes <[EMAIL PROTECTED]> writes:
> At 09:36 AM 7/17/2003, David Abrahams wrote:
> >Beman Dawes <[EMAIL PROTECTED]> writes:
> >
> >> See win32-1_30_1 on http://boost.sourceforge.net/regression-logs/
> >>
> >> I found I had to update the .../tools/build sub-tree to the current
> >> main
At 11:02 AM 7/17/2003, David Abrahams wrote:
>David Abrahams <[EMAIL PROTECTED]> writes:
>
>> Beman Dawes <[EMAIL PROTECTED]> writes:
>>
>>> See win32-1_30_1 on http://boost.sourceforge.net/regression-logs/
>>>
>>> I found I had to update the .../tools/build sub-tree to the current
>>> main trunk i
At 09:36 AM 7/17/2003, David Abrahams wrote:
>Beman Dawes <[EMAIL PROTECTED]> writes:
>
>> See win32-1_30_1 on http://boost.sourceforge.net/regression-logs/
>>
>> I found I had to update the .../tools/build sub-tree to the current
>> main trunk in order to get the latest toolsets. Other than that,
At 09:35 AM 7/17/2003, David Abrahams wrote:
>Beman Dawes <[EMAIL PROTECTED]> writes:
>
>> See win32-1_30_1 on http://boost.sourceforge.net/regression-logs/
>>
>> I found I had to update the .../tools/build sub-tree to the current
>> main trunk in order to get the latest toolsets. Other than that,
David Abrahams <[EMAIL PROTECTED]> writes:
> Beman Dawes <[EMAIL PROTECTED]> writes:
>
>> See win32-1_30_1 on http://boost.sourceforge.net/regression-logs/
>>
>> I found I had to update the .../tools/build sub-tree to the current
>> main trunk in order to get the latest toolsets. Other than that,
Beman Dawes <[EMAIL PROTECTED]> writes:
> See win32-1_30_1 on http://boost.sourceforge.net/regression-logs/
>
> I found I had to update the .../tools/build sub-tree to the current
> main trunk in order to get the latest toolsets. Other than that, the
> tests were run on the RC_1_30_0 branch.
How
Beman Dawes <[EMAIL PROTECTED]> writes:
> See win32-1_30_1 on http://boost.sourceforge.net/regression-logs/
>
> I found I had to update the .../tools/build sub-tree to the current
> main trunk in order to get the latest toolsets. Other than that, the
> tests were run on the RC_1_30_0 branch.
Woul
At 11:50 AM 7/16/2003, David Abrahams wrote:
>... The only issue remaining is how we can get the
>testing infrastructure to start testing RC_1_30_0. I would like to
>see the results of a round of testing on the current CVS state of that
>branch before we commit to a 1.30.1 release, just to make
Misha Bergal wrote:
> > Here are the results we have:
> >
> > 1.30.0 tarball: http://tinyurl.com/h6cx
> > CVS main trunk (relative to 1.30.0 tarball): http://tinyurl.com/h6d0
> > CVS RC_1_30_0 branch (relative to 1.30.0 tarball):
http://tinyurl.com/h6d7
> > (will be available in 9 hours)
>
> CVS RC
> From: Misha Bergal
> Sent: Wednesday, July 16, 2003 9:45 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE: [boost] Re: plans for a bugfix release ?
>
>
>
> > Sounds fine to me. The only issue remaining is how we can
> > get the testing infrastructur
Aleksey Gurtovoy wrote:
Martin Wille writes:
I'll run the tests for Linux and upload them as Linux-rc-1.30.0.
They should be available in a few hours.
Can you arrange the html so that it shows regressions from the 1.30.0
release results?
Hmm, I'd have to find out how I would do that. Is there alre
- Original Message -
From: "Aleksey Gurtovoy" <[EMAIL PROTECTED]>
> Beman Dawes wrote:
> > What is really needed is to add a "history" element to the test_log.xml
> > files. That would be far more reliable. Let me think about it overnight.
>
> The way we do it in the new reports is to extra
Beman Dawes wrote:
> At 04:54 PM 7/16/2003, David Abrahams wrote:
>
> >Martin Wille <[EMAIL PROTECTED]> writes:
> >> Hmm, I'd have to find out how I would do that. Is there already
> >> some support for showing diffs between two versions of the test
> >> result tables?
> >
> >Yes. Beman?
>
>
Martin Wille writes:
> >>I'll run the tests for Linux and upload them as Linux-rc-1.30.0.
> >>They should be available in a few hours.
> > Can you arrange the html so that it shows regressions from the 1.30.0
> > release results?
>
> Hmm, I'd have to find out how I would do that. Is there already
>
> From: David Abrahams [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, July 16, 2003 10:51 AM
> Sounds fine to me. The only issue remaining is how we can
> get the testing infrastructure to start testing RC_1_30_0. I
> would like to see the results of a round of testing on the
> current CVS st
At 04:54 PM 7/16/2003, David Abrahams wrote:
>Martin Wille <[EMAIL PROTECTED]> writes:
>> Hmm, I'd have to find out how I would do that. Is there already
>> some support for showing diffs between two versions of the test
>> result tables?
>
>Yes. Beman?
I have a hack that I use to produce
http:/
At 11:50 AM 7/16/2003, David Abrahams wrote:
>Beman Dawes <[EMAIL PROTECTED]> writes:
>> So a schedule might look something like the following?
>>
>> -- 1.30.1 - Selected bug fixes only (details up to release
manager).
>> Schedule: a week or two from now
>
>I would be more hard
Martin Wille <[EMAIL PROTECTED]> writes:
F> David Abrahams wrote:
>> Martin Wille writes:
>>
>>>Hi,
>>>
>>>you wrote:
>>>
>>>
Sounds fine to me. The only issue remaining is how we can get the
testing infrastructure to start testing RC_1_30_0. I would like to
see the results of a rou
Beman Dawes <[EMAIL PROTECTED]> writes:
> At 08:36 PM 7/15/2003, David Abrahams wrote:
>
> >Beman Dawes <[EMAIL PROTECTED]> writes:
> >
> >...
> >
> >> Hum... You must be seeing some way of getting a 1.30.1 release out
> >> that eludes me. What would go into 1.30.1?
> >
> >Exactly what's o
Alisdair Meredith wrote:
Spirit has also just released its next version, should this also be
integrated into any boost 1.30.1?
Yes, Spirit 1.6.1 should be incorporated into a Boost 1.30.1
release (if we actually decide to release 1.30.1).
[I will ask same question on Spirit list, and direct discu
At 06:17 AM 7/16/2003, Alisdair Meredith wrote:
>David Abrahams wrote:
>
>> Only *critical* fixes to the 1.30.0 release.
>
>What about updated compiler configs? For instance, Borland released a
>compiler update pretty much the same week that Boost 1.30 went out, so
>several version checks fail.
At 08:36 PM 7/15/2003, David Abrahams wrote:
>Beman Dawes <[EMAIL PROTECTED]> writes:
>
>...
>
>> Hum... You must be seeing some way of getting a 1.30.1 release out
>> that eludes me. What would go into 1.30.1?
>
>Exactly what's on the end of the RC_1_30_0 branch plus whatever
>additional small fi
From: "Alisdair Meredith" <[EMAIL PROTECTED]>
> > Only *critical* fixes to the 1.30.0 release.
>
> What about updated compiler configs? For instance, Borland released a
> compiler update pretty much the same week that Boost 1.30 went out, so
> several version checks fail. Any other compilers rel
"Johannes Brunen" <[EMAIL PROTECTED]> writes:
> At our company we use a slightly different approach. We have two development
> streams, which we call 'Master' and 'Release'. At some time, when we are
> releasing a version from our main development branch ('Master'), we just make
> a copy of the
Alisdair Meredith <[EMAIL PROTECTED]> writes:
> David Abrahams wrote:
>
>> > [Beman Dawes]
>> > Hum... You must be seeing some way of getting a 1.30.1 release out
>> > that eludes me. What would go into 1.30.1?
>
>> Exactly what's on the end of the RC_1_30_0 branch plus whatever
>> additional smal
David Abrahams wrote:
> > [Beman Dawes]
> > Hum... You must be seeing some way of getting a 1.30.1 release out
> > that eludes me. What would go into 1.30.1?
> Exactly what's on the end of the RC_1_30_0 branch plus whatever
> additional small fixes were deemed important and can be applied in a
>
Beman Dawes wrote:
Seems like we are very close to being ready to do a 1.31.0 release. One
new library has been added since 1.30.0, at least two libraries have had
interface upgrades, and a large number of bugs have been fixed in
numerous libraries.
How about 1 or maybe more betas of 1.31.0 (li
Hi,
On Tue, 15 Jul 2003 23:38:12 +0200, Daniel Frey wrote:
> I think it's too late, let's go for a 1.31.0. I think that we'll hear
> about problems with the 1.31.0 really soon after release and probably a
> 1.31.1 can follow shortly after.
Agreed.
At our company we use a slightly different appr
Daniel Frey <[EMAIL PROTECTED]> writes:
> On Tue, 15 Jul 2003 16:26:43 +0200, David Abrahams wrote:
>
>> What does everybody think about doing a 1.30.1 release "RSN?"
>
> I think it's too late, let's go for a 1.31.0. I think that we'll hear
> about problems with the 1.31.0 really soon after releas
Beman Dawes <[EMAIL PROTECTED]> writes:
> At 11:50 AM 7/15/2003, David Abrahams wrote:
> >Beman Dawes <[EMAIL PROTECTED]> writes:
> >
> >> At 10:26 AM 7/15/2003, David Abrahams wrote:
> >>
> >> >Dominique Devriese <[EMAIL PROTECTED]>
> writes:
> >> >
> >> >>> In general, they are r
- Original Message -
From: "Daniel Frey" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, July 15, 2003 11:38 PM
Subject: [boost] Re: plans for a bugfix release ?
> On Tue, 15 Jul 2003 16:26:43 +0200, David Abrahams w
inors are like once a month.. And patchs as soon as there
is enough problems to require one.
Ben
- Original Message -
From: "Rozental, Gennadiy" <[EMAIL PROTECTED]>
To: "'Boost mailing list'" <[EMAIL PROTECTED]>
Sent: Tuesday, July 15, 2003 3:09
On Tue, 15 Jul 2003 16:26:43 +0200, David Abrahams wrote:
> What does everybody think about doing a 1.30.1 release "RSN?"
I think it's too late, let's go for a 1.31.0. I think that we'll hear
about problems with the 1.31.0 really soon after release and probably a
1.31.1 can follow shortly after.
At 11:50 AM 7/15/2003, David Abrahams wrote:
>Beman Dawes <[EMAIL PROTECTED]> writes:
>
>> At 10:26 AM 7/15/2003, David Abrahams wrote:
>>
>> >Dominique Devriese <[EMAIL PROTECTED]>
writes:
>> >
>> >>> In general, they are released when all of Boost is ready. I think
>> >>> it would be a *rea
On Tue, 15 Jul 2003 19:19:08 +0200, Thomas Witt wrote
> David Abrahams wrote:
> > Beman Dawes <[EMAIL PROTECTED]> writes:
> >
> > When we released 1.30.0, despite extensive pre-release testing, it
> > went out with several prominent showstopper bugs. Don't you think
> > we'll make the same mista
> David Abrahams wrote:
> > Beman Dawes <[EMAIL PROTECTED]> writes:
> >
> > When we released 1.30.0, despite extensive pre-release testing, it
> > went out with several prominent showstopper bugs. Don't you think
> > we'll make the same mistake for 1.31.0? Also, AFAICT 1.30.1 can go
> > out
David Abrahams wrote:
Beman Dawes <[EMAIL PROTECTED]> writes:
When we released 1.30.0, despite extensive pre-release testing, it
went out with several prominent showstopper bugs. Don't you think
we'll make the same mistake for 1.31.0? Also, AFAICT 1.30.1 can go
out much, much sooner.
I agree w
Beman Dawes <[EMAIL PROTECTED]> writes:
> At 10:26 AM 7/15/2003, David Abrahams wrote:
>
> >Dominique Devriese <[EMAIL PROTECTED]> writes:
> >
> >>> In general, they are released when all of Boost is ready. I think
> >>> it would be a *really* good idea for Boost to do at least one minor
> >
At 10:26 AM 7/15/2003, David Abrahams wrote:
>Dominique Devriese <[EMAIL PROTECTED]> writes:
>
>>> In general, they are released when all of Boost is ready. I think
>>> it would be a *really* good idea for Boost to do at least one minor
>>> version release shortly after any major version release.
Dominique Devriese <[EMAIL PROTECTED]> writes:
>> In general, they are released when all of Boost is ready. I think
>> it would be a *really* good idea for Boost to do at least one minor
>> version release shortly after any major version release. Now that
>> we have a reasonable testing strategy
Dominique Devriese <[EMAIL PROTECTED]> writes:
> David Abrahams writes:
>
>>> Hi,
>>>
>>> I'm the main developer of Kig [1]. I have just committed the code
>>> for python scripting to the CVS repository
>
>> Using Boost.Python? Cool!
>
> Yups, I was going to post something separately about inclu
The following message is a courtesy copy of an article
that has been posted to gmane.comp.python.c++ as well.
Dominique Devriese <[EMAIL PROTECTED]> writes:
> Hi,
>
> I'm the main developer of Kig [1]. I have just committed the code for
> python scripting to the CVS repository
Using Boost.Pytho
56 matches
Mail list logo
