preparing for release 1.1

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

preparing for release 1.1

Markus Wanner-2
Hi,

I finally got around cleaning up things for a 1.1 release.

Most importantly, I revived some of the buildbot infrastructure and
added a couple of build slaves. As expected (by manual testing) these
roughly look okay. (Intermittent failures on the extra tests 'buildbot'
and 'mail-notify'. Didn't look into these, yet.)

@Richard and Jeff: you used to run a buildbot slave or two. Care to
revive those? Or shall I drop them?

I updated the UPGRADE, NEWS and INSTALL documents a bit. Please review.

Regards

Markus Wanner


_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel

signature.asc (250 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: preparing for release 1.1

Stephen Leake-3
Markus Wanner <[hidden email]> writes:

> I finally got around cleaning up things for a 1.1 release.

Thanks for working on this

> I updated the UPGRADE, NEWS and INSTALL documents a bit. Please
> review.

Cygwin now comes in two flavors; 32 bit and 64 bit; which are you using?
I have Cygwin 64; I'll see if I can compile monotone on that.

I'll also update my mingw install and test there.

That will probably take me a couple of weeks.

--
-- Stephe

_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel
Reply | Threaded
Open this post in threaded view
|

Re: preparing for release 1.1

Markus Wanner-2
On 04/18/2014 11:20 AM, Stephen Leake wrote:
> Cygwin now comes in two flavors; 32 bit and 64 bit; which are you using?
> I have Cygwin 64; I'll see if I can compile monotone on that.

I tested on Cygwin 64. However, I'd expect the provided versions of
dependent libraries to be the same, so most of the INSTALL document for
cygwin should be the same. But yeah, we should clarify that.

As evident from the buildbot, cygwin currently fails on some tests,
which I consider a release blocker.

> I'll also update my mingw install and test there.
>
> That will probably take me a couple of weeks.

I tried with mingw (and MSVC), but no success so far on these.

Can you possibly provide a buildbot slave?

Regards

Markus Wanner



_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel

signature.asc (250 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: preparing for release 1.1

Stephen Leake-3
Markus Wanner <[hidden email]> writes:

> On 04/18/2014 11:20 AM, Stephen Leake wrote:
>> Cygwin now comes in two flavors; 32 bit and 64 bit; which are you using?
>> I have Cygwin 64; I'll see if I can compile monotone on that.
>
> I tested on Cygwin 64. However, I'd expect the provided versions of
> dependent libraries to be the same, so most of the INSTALL document for
> cygwin should be the same. But yeah, we should clarify that.
>
> As evident from the buildbot, cygwin currently fails on some tests,
> which I consider a release blocker.

We have always had failing tests on Cygwin (I believe). Not enough
motivation to fix them.

> Can you possibly provide a buildbot slave?

My past experience with buildbot slaves is that they are much more pain
than they are worth.

--
-- Stephe

_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel
Reply | Threaded
Open this post in threaded view
|

Re: preparing for release 1.1

Markus Wanner-2
Stephen,

On 04/22/2014 04:45 PM, Stephen Leake wrote:
> We have always had failing tests on Cygwin (I believe). Not enough
> motivation to fix them.

I already fixed all but one. And netsync_largish_file seems important
enough to have a deeper look.

> My past experience with buildbot slaves is that they are much more pain
> than they are worth.

Well, in my past experience, proper testing makes the difference between
quality work and BS. So I use unit testing quite a lot.

That being said, I agree that time spent to write tests vs actual code
needs to maintain a reasonable balance. I've just disabled some tests
that failed and which I think are beyond that balance to maintain.

Another aspect of this is that shipping tests that fail give the user a
bad impression. Therefore, I'm rather disabling a test that's hard to
fix and of questionable value than shipping it, knowing it's failing.

Regards

Markus Wanner




_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel

signature.asc (250 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: preparing for release 1.1

Stephen Leake-3
Markus Wanner <[hidden email]> writes:

> Stephen,
>
> On 04/22/2014 04:45 PM, Stephen Leake wrote:
>> We have always had failing tests on Cygwin (I believe). Not enough
>> motivation to fix them.
>
> I already fixed all but one. And netsync_largish_file seems important
> enough to have a deeper look.
>
>> My past experience with buildbot slaves is that they are much more pain
>> than they are worth.
>
> Well, in my past experience, proper testing makes the difference between
> quality work and BS. So I use unit testing quite a lot.

I have no problem running the tests on request (although not with 1 hr
response time); I just don't think maintaining a buildbot is worth the
trouble.

> That being said, I agree that time spent to write tests vs actual code
> needs to maintain a reasonable balance. I've just disabled some tests
> that failed and which I think are beyond that balance to maintain.

And time is better spent actually running tests and fixing problems, as
opposed to fixing the buildbot infrastructure.

> Another aspect of this is that shipping tests that fail give the user a
> bad impression. Therefore, I'm rather disabling a test that's hard to
> fix and of questionable value than shipping it, knowing it's failing.

+1

I think we are violently agreeing :).

--
-- Stephe

_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel
Reply | Threaded
Open this post in threaded view
|

Re: preparing for release 1.1

Stephen Leake-3
In reply to this post by Stephen Leake-3
Stephen Leake <[hidden email]> writes:

> I'll also update my mingw install and test there.

progress report; I updated to the latest 32 bit MinGW installer, and
something is wrong. mtn compiles, and 'mtn version' works, but 'mtn
automate get_base_revision_id' crashes.

I'll try:

- MinGW64

- previous release of 32 bit MinGW

Does anyone have experience setting up a MinGW64 environment? There seem
to be many choices.

--
-- Stephe

_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel
Reply | Threaded
Open this post in threaded view
|

Re: preparing for release 1.1

Markus Wanner-2
Stephen,

On 04/27/2014 03:39 PM, Stephen Leake wrote:
> progress report; I updated to the latest 32 bit MinGW installer, and
> something is wrong. mtn compiles, and 'mtn version' works, but 'mtn
> automate get_base_revision_id' crashes.

Thanks for testing.

I'm just about to add a (32-bit) MinGW build slave (boar). The bot
didn't run through all tests just yet, but that box ran through all of
them just fine, before, so I'm surprised you're reporting such a
problem. A smoke test of 'mtn au get_base_revision_id' seems to work
fine for me as well.

The mtn.exe there reports:

C:\Users\buildbot\slaves\mtn-mingw-boar\quick-boar\build>mtn version --full
monotone 1.1 (base revision: 81f946245b7019f6100fa4d9a1156096245640a7)
Running on          : Windows NT/2000/XP/2003 (6.1, build 7601, Service
Pack 1)
on ia32 (level 6, rev 15361)
C++ compiler        : GNU C++ version 4.8.1
C++ standard library: GNU libstdc++ version 20130531
Boost version       : 1_55
SQLite version      : 3.8.4.3 (compiled against 3.8.4.3)
Lua version         : Lua 5.2
PCRE version        : 8.35 2014-04-04 (compiled against 8.35)
Botan version       : 1.10.8 (compiled against 1.10.8)
Changes since base revision:
format_version "1"

new_manifest [2d59b8cc3c138737797b59f9a401e2fadb2991ca]

old_revision [81f946245b7019f6100fa4d9a1156096245640a7]


> I'll try:
>
> - MinGW64

That'd be great as well, yes. I won't have time to go through compiling
all the dependencies again for 64-bit.

> - previous release of 32 bit MinGW

Hm.. I just let the setup process update catalogs. Not sure what
"release" I'm running. How do I check?

Can you run your mtn.exe from a debugger to see what's wrong (or get a
core dump, if such a thing exists on Windows)?

> Does anyone have experience setting up a MinGW64 environment? There seem
> to be many choices.

I played a bit with mingw-w64. Doesn't seem all that different to me,
but I obviously didn't go through a complete build, yet.

I recently updated the Windows build documentation a bit and would
appreciate a review.

Regards

Markus Wanner


_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel
Reply | Threaded
Open this post in threaded view
|

Re: preparing for release 1.1

Markus Wanner-2
On 04/27/2014 05:53 PM, Markus Wanner wrote:
> I'm just about to add a (32-bit) MinGW build slave (boar). The bot
> didn't run through all tests just yet, but that box ran through all of
> them just fine, before, so I'm surprised you're reporting such a
> problem. A smoke test of 'mtn au get_base_revision_id' seems to work
> fine for me as well.

Oh, before I forget: The -static-lib{gcc,stdc++} options didn't work for
me. I compiled without those (so does the build slave).

And a minor correction: All *except* the extra tests run through fine,
just as the buildbot currently shows.

Regards

Markus


_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel
Reply | Threaded
Open this post in threaded view
|

Re: preparing for release 1.1

Stephen Leake-3
In reply to this post by Markus Wanner-2
Markus Wanner <[hidden email]> writes:

> Can you run your mtn.exe from a debugger to see what's wrong (or get a
> core dump, if such a thing exists on Windows)?

I can, but the last time I investigated a bug like this it turned out to
be the compiler version, so I'd rather mess with the tools some more first.

>> Does anyone have experience setting up a MinGW64 environment? There seem
>> to be many choices.
>
> I played a bit with mingw-w64. Doesn't seem all that different to me,
> but I obviously didn't go through a complete build, yet.
>
> I recently updated the Windows build documentation a bit and would
> appreciate a review.

Ah. Apparently I forgot to pull/update; I thought I had done that.

It looks like you compiled Lua yourself, rather than using the MinGW
package; that may be the bug.

Since the 32 bit build is working for you, I'll work on the 64 bit version.

--
-- Stephe

_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel
Reply | Threaded
Open this post in threaded view
|

Re: preparing for release 1.1

Stephen Leake-3
In reply to this post by Markus Wanner-2
Markus Wanner <[hidden email]> writes:

> On 04/27/2014 05:53 PM, Markus Wanner wrote:
>> I'm just about to add a (32-bit) MinGW build slave (boar). The bot
>> didn't run through all tests just yet, but that box ran through all of
>> them just fine, before, so I'm surprised you're reporting such a
>> problem. A smoke test of 'mtn au get_base_revision_id' seems to work
>> fine for me as well.
>
> Oh, before I forget: The -static-lib{gcc,stdc++} options didn't work for
> me. I compiled without those (so does the build slave).

Ok. But they are still in INSTALL_windows_mingw.txt

--
-- Stephe

_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel
Reply | Threaded
Open this post in threaded view
|

Re: preparing for release 1.1

Markus Wanner-2
In reply to this post by Stephen Leake-3
On 04/27/2014 08:52 PM, Stephen Leake wrote:
> It looks like you compiled Lua yourself, rather than using the MinGW
> package; that may be the bug.

Oh, I didn't realize there's a MinGW package for lua. The
INSTALL_windows_mingw.txt document recommends installation from source.

I reverted back to the MinGW provided lua package (5.2.0) and things
still seem to work fine.

> Since the 32 bit build is working for you, I'll work on the 64 bit version.

Great, thanks.

Regards

Markus Wanner


_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel
Reply | Threaded
Open this post in threaded view
|

static libs on mingw [was: preparing for release 1.1]

Markus Wanner-2
In reply to this post by Stephen Leake-3
On 04/27/2014 08:55 PM, Stephen Leake wrote:
> Markus Wanner <[hidden email]> writes:
>> Oh, before I forget: The -static-lib{gcc,stdc++} options didn't work for
>> me. I compiled without those (so does the build slave).
>
> Ok. But they are still in INSTALL_windows_mingw.txt

Well, it generally seems like a reasonable option to consider.

I figured that "-static-libstdc++" alone works just fine for me, so it
seems only "-static-libgcc" is to blame. I'm wondering how mingw-w64
behaves.

OTOH, I don't see much of a difference in starting time. Certainly not
in the order of seconds ('mtn.exe version' runs in about 0.1 seconds
either way).

Regards

Markus Wanner


_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel