9:47 a.m.
Hi,
I thought it was time to turn the last red build into a green one. We
have had that one for a very long time. I thought it would be a simple
type mismatch that possibly could be handled with a cast. But...
When I looked into it I realized it was much harder and that it raises
a number of questions.
- First of all the problem is the same with the other windows builds
but these are built with gcc and the one that fails is built with
g++. c++ is a bit harder on type mismatch causing errors instead of
warnings.
Conclusion: All windows builds ought to be fixed.
- Fixing it is both easy and hard.
- Fixing it is hard because unicode support on windows seems to be
a can of worms.
If I get it right we are also trying hard to build one binary
that will work on all windows flavors going back to Windows-98
(or even further?) This doesn't make things easier.
The current cygwin version has dropped support for the old
versions of windows. This raises the question.
Q: Can we drop that support to?
Since I don't understand the code fully I'm not sure but it feels
like that your code will be simpler if we could drop the runtime
check on Windows version. Later versions of Windows might have
more stable APIs making our code even simpler?
- Fixing it is easy because these functions that causes the error
isn't used!?
We could simply remove them. If I get it right there is in
intl-auto-encap-win32.c and intl-encap-win32.c a small framework
for supporting windows APIs that could potentially be used. So
they are ready to be used once we need them. It also has trip
wires to alert you when using the wrong function names.
Am I missing something here? Are they maybe useful for users
writing there own modules so removing them would be a bad idea?
Is the framework really paying of? It seems strange to me to have
a bunch of loose functions hanging around. (If I fix the error
how would I know that I did it right?) But I guess once I would
need a function in the framework I would be grateful that it was
already provided (if it was implemented right that is!)
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:21 p.m.
Mats -
On Sun, Dec 11, 2011 at 4:47 AM, Mats Lidell <matsl(a)xemacs.org> wrote:
I thought it was time to turn the last red build into a green one.
We
have had that one for a very long time. I thought it would be a simple
type mismatch that possibly could be handled with a cast. But...
When I looked into it I realized it was much harder and that it raises
a number of questions.
Can you send me a link so I can look at the results? I can build 21.4
and 21.5 both Windows native and cygwin versions, at least under XP.
Thanks,
Vin
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
9:46 p.m.
>>>> Vin Shelton <acs(a)alumni.princeton.edu> writes:
Can you send me a link so I can look at the results? I can build
21.4
and 21.5 both Windows native and cygwin versions, at least under XP.
Don't you visit the buildbot daily? ;-) (I haven't found a good way to
post the build results to the build-report-list. It will create to
much noise as it is now. But you can use the rss-feed from the
buildbot to create your own reminder.)
This is the link to the buildbot.
http://lidell.nu/xemacs-buildbot/
You'll find the cygwin builds under windows XP there. For instance:
http://lidell.nu/xemacs-buildbot/builders/x86%20windows%20cfg3/builds/39/...
As I said the warnings and errors comes from functions that are not
used so they don't have any impact on the binary at this moment any
way. The error build above is done with g++ which causes an error. The
three other windows builds uses gcc where the problem just causes a
warning.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:54 a.m.
Mats Lidell writes:
Don't you visit the buildbot daily? ;-) (I haven't found a
good way to
post the build results to the build-report-list. It will create to
much noise as it is now.
People don't have to subscribe to the xemacs-build-reports list. They
can also choose to receive a digest; I would think a weekly digest
would not be too annoying. So don't worry about noise.
I would suggest that you arrange for the subject of each post to
summarize the results for all bots.
Subject: [build-reports] Buildbot: 3 bots green, 1 bots red
But you can use the rss-feed from the buildbot to create your own
reminder.)
This is also a good method, but not a perfect substitute for the list.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
1:03 p.m.
On Mon, Dec 12, 2011 at 10:54 PM, Stephen J. Turnbull
<stephen(a)xemacs.org> wrote:
I would suggest that you arrange for the subject of each post to
summarize the results for all bots.
Subject: [build-reports] Buildbot: 3 bots green, 1 bots red
+1
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
9:34 p.m.
>>>> Stephen J Turnbull <stephen(a)xemacs.org> writes:
I would suggest that you arrange for the subject of each post to
summarize the results for all bots.
Subject: [build-reports] Buildbot: 3 bots green, 1 bots red
I know. The problem is that the only built in support, that I know of,
is to send one mail per build-slave and build. That would currently
mean 28 mails for each build. That is what I consider noise.
Creating a summary is somewhat problematic since the builds are
asynchronous. Build slaves build at different speed and might be
offline and do their part later. If they are to late they will not
built that build at all.
And if we could come up with a scheme that takes care of this it would
have to be implemented. The hardest party of it all ;-) I'll check if
there are some prior art in the buildbot community that we could
use. Feel free to suggest solutions.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
10:38 p.m.
>>>> Mats Lidell <matsl(a)xemacs.org> writes:
I'll check if there are some prior art in the buildbot community
that we could use. Feel free to suggest solutions.
Reading the docs provided some insight! The built in MailNotifier
component can be easily customized so that it will only send mail on
for example builds that fail, fail+warnings and those that change
state from good to fail.
Our current situation is that nearly all builds create warnings so
fail+warning would not be an option right now (if we are not pushing
hard for fixing the warnings?)
So I suggest giving the option to send mail for builds that fail a
try. That would under current situation create one mail for the
failing windows build. It will create 28 mails the day there is
something really bad. But then it would get some focus.
What do you say? Good enough?
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
8:20 a.m.
Mats Lidell writes:
Our current situation is that nearly all builds create warnings so
fail+warning would not be an option right now (if we are not pushing
hard for fixing the warnings?)
We do push hard for fixing warnings, but we've done that for decades
now. We don't need the buildbot to annoy us into doing the right
thing now. We do need the buildbot so that people can see breakage on
platforms they can't build on.
Also, there are a number of warnings we can't easily fix AFAIK (eg,
warnings about non-prototyped functions in lib-src, and certain
warnings on Mac).
So I suggest giving the option to send mail for builds that fail a
try. That would under current situation create one mail for the
failing windows build. It will create 28 mails the day there is
something really bad. But then it would get some focus.
That's a bit much, even for something that breaks all the builds. :-)
Does the buildbot mail contain a commit ID (anything that
distinguishes one series of builds from another)? I could add a
filter to Mailman to only let the first one through very easily, and
it might not be massively difficult to set up a system that lets the
first mail from a commit go through, and digests the rest, or even
lets only the first fail message through, and bundles all successes
into one and any other failures into one.
It would probably also be possible to borrow some code from Mailman to
do those things at buildbot.
Steve
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
11 p.m.
>>>> Stephen J Turnbull <stephen(a)xemacs.org> writes:
That's a bit much, even for something that breaks all the
builds. :-)
OK.
Does the buildbot mail contain a commit ID (anything that
distinguishes one series of builds from another)? I could add a
[...]
I'll see what can be done at this side first.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
12:48 a.m.
New subject: Proper way to report build failure (was: Issues raised by the red windows build)
>>>> Mats Lidell <matsl(a)xemacs.org> writes:
I'll see what can be done at this side first.
One complementary way to report, that buildbot supports, is to mail to
the user doing the push that makes the build fail. This will not
offend the list but might lead to some mail to single persons. I hope
that is OK?
With that in place. (It will need some more tweaking I'm afraid). The
need to produce a mail rapidly to the build list is less. Right?
Given that then maybe a report on a daily or weekly basis with a
summary about the build situation would be enough for general
consumption!? It seems like support for something similar is
implemented in a newer version of buildbot than we are using at the
moment. So with time we'll get this.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
12:22 a.m.
New subject: Proper way to report build failure (was: Issues raised by the red windows build)
Mats Lidell writes:
One complementary way to report, that buildbot supports, is to mail
to
the user doing the push that makes the build fail.
This is a good idea only if we can really identify the push that makes
the build fail. But we currently tend to have red bots most of the
time. We could just send mail on "red edges" (ie, when a bot goes
from green to red), I guess.
This will not offend the list but might lead to some mail to single
persons.
I don't understand why you're worried about offending the list. There
are 10 members, of which 3 look to be spambots and one is Gmane, with
one set to "no mail". That's five people to offend at the moment.
Given that then maybe a report on a daily or weekly basis with a
summary about the build situation would be enough for general
consumption!?
You seem to think that these reports are going to a list with the wide
distribution of xemacs-beta. I suppose a weekly report to xemacs-beta
might be in order, but the reports to xemacs-buildreports should be at
least daily.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
11:10 p.m.
New subject: Proper way to report build failure
>>>> Stephen J Turnbull <stephen(a)xemacs.org> writes:
This is a good idea only if we can really identify the push that
makes the build fail. But we currently tend to have red bots most
of the time.
No. All builds are green except one of the windows builds (Which I
have posted about and don't know how to handle...) But except that one
all builds are fine.
We could just send mail on "red edges" (ie, when a bot goes
from
green to red), I guess.
Yes I think that is supported.
I don't understand why you're worried about offending the
list.
There are 10 members, of which 3 look to be spambots and one is
Gmane, with one set to "no mail". That's five people to offend at
the moment.
Well I talked about the 28 mails per build before and I thought I got
an acknowledge on that that would be bit to much!? But I can easily
activate that and well see how it feels. Alternatively I could set it
up to just mail the failed builds. OK?
You seem to think that these reports are going to a list with the
wide distribution of xemacs-beta. I suppose a weekly report to
xemacs-beta might be in order, but the reports to
xemacs-buildreports should be at least daily.
I'm obviously not aware of the amount of people on the list. ;-)
I'll start with a daily summary to xemacs-buildreports and we'll take
it from there.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
6:55 a.m.
New subject: Proper way to report build failure
Mats Lidell writes:
>>>>> Stephen J Turnbull <stephen(a)xemacs.org>
writes:
> This is a good idea only if we can really identify the push that
> makes the build fail. But we currently tend to have red bots most
> of the time.
No. All builds are green except one of the windows builds (Which I
have posted about and don't know how to handle...) But except that one
all builds are fine.
Which means that there will be at least one mail on every patch,
although status hasn't changed, if we mail on red bots instead of
green->red transitions. That's bad, because people will tend to (a)
unsubscribe or (b) otherwise ignore the mails. As long as "mail on
red edge" is supported, that's the way we should go.
Well I talked about the 28 mails per build before and I thought I
got
an acknowledge on that that would be bit to much!?
Sure, if there's a way to reduce that, we should. But it's not the
number of mails that's the problem, it's the low signal-to-noise ratio.
But I can easily activate that and well see how it
feels. Alternatively I could set it up to just mail the failed
builds. OK?
Yes, please, but just the failed builds.
I'll start with a daily summary to xemacs-buildreports and
we'll take
it from there.
Thank you!
Oh, it occurs to me that it would be preferable if mail to
xemacs-buildreports has *no* personal addresses in it (not in the
headers, not in the text) because the chances seem to be good that
spammers are grepping our lists.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
9:41 p.m.
New subject: Proper way to report build failure
>>>> Stephen J Turnbull <stephen(a)xemacs.org> writes:
As long as "mail on red edge" is supported, that's the
way we should
go.
The buildbot term here is "problem". When a build changes state from
green to red a mail is sent. (At least that is the idea. I haven't
verified that it works!) I have activated that now anyway so we'll see
how it turns out. Look out for buildbot mails in xemacs-buildreports!
Oh, it occurs to me that it would be preferable if mail to
xemacs-buildreports has *no* personal addresses in it (not in the
headers, not in the text) because the chances seem to be good that
spammers are grepping our lists.
There is the id of the user who have pushed changes causing the build
to take place. It is only an id, no mail address. Then there is the
address of the sender, ie the buildbot.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:20 a.m.
New subject: Proper way to report build failure
Mats Lidell writes:
>>>>> Stephen J Turnbull <stephen(a)xemacs.org>
writes:
> As long as "mail on red edge" is supported, that's the way we should
> go.
The buildbot term here is "problem".
Fine by me. Looking forward to having my mailbox stuffed! :-)
There is the id of the user who have pushed changes causing the
build
to take place. It is only an id, no mail address. Then there is the
address of the sender, ie the buildbot.
Thank you for the confirmation.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
8:09 a.m.
Mats Lidell writes:
I know. The problem is that the only built in support, that I know
of,
is to send one mail per build-slave and build. That would currently
mean 28 mails for each build. That is what I consider noise.
OK, so we create an xemacs-buildbot-raw ML which has one (daily
digest[1]) subscriber, the xemacs-buildbot ML. ;-)
WDYT?
Footnotes:
[1] And with a little bit of not too difficult Mailman hacking it
should be possible to create one that digests on a half-daily or
3-hour interval.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4718
days inactive
4730
days old
15 comments
3 participants
participants (3)
-
Stephen J. Turnbull -
The XEmacs Package Smoketest -
Vin Shelton