David,
BTW, I do appreciate all the work you do to ensure the releases are successful. It can be a bit frustrating when things don't go quite right, so we need to all work together to ensure that everything goes as smoothly as possible.
Cheers, Greg
There's no change in policy. Projects choose
to be in the (our) common repo. Part of that is to provide valid input
to the build. Normally the tools work well to send out notifications for
problems. Occasionally the contributed input is so bad that the tool can't
even read it well enough to find the email addresses. You can wait until
someone tells you that, if you'd like. But, as tonight, sometimes that
takes 3 or 4 hours (or longer) for someone else to notice. As you said,
you were "waiting for a build" ... how long would you wait before
you looked at
https://hudson.eclipse.org/hudson/view/Repository%20Aggregation/job/simrel.kepler.runaggregator/
?
I looked at it and the error was "exec returned: 13". How am I supposed to know that this is related to ptp? Is your expectation that I should dig into how it works to determine what is causing this problem? I don't think so.
The automatic notifications may be deceptive,
because they say they are from "me" .... but .... its all automated.
I do not send them. I do not even see most of them ... at least, usually,
until after the contributors have already fixed their problem. If it fails
so badly that it can not find email addresses, I get an RSS notification
that the Hudson failed. But, you may be surprised to hear, I am not on-line
monitoring that queue 24 hours a day!
Come on David, you said that "it was ptp breaking the builds..." and you "...spent an extra hour of my time fixing that". So you obviously knew there was a problem, but chose not to inform anyone about it.
And, I'll be blunt, I'm sensitive to
this for the PTP project, because similar things have happened several
times before, most recently in M7... also last minute. (I know, I know,
you were on vacation then :)
But, I somehow how get the impression
your project has not yet learned the convenience of using the b3 aggregator
editor, a requirement that is well documented in
http://wiki.eclipse.org/Simrel/Contributing_to_Simrel_Aggregation_Build
Maybe it should be named the "b3
repository interactive compiler" and you'd have a different impression
of it :) But seriously, you say you have "no idea how the aggregation
works". Well, if you want to know, here it is: it works just like
p2 installing software ... and does a few extra quality checks. And,
if it can read the addresses, it sends email if it can not install someone's
contribution. That's about it.
If I may, I'll quote another contributor
who recently learned to use it ... that is, after I suggested him to use
the validate and validate aggregation functions ...
" Sure enough I am impressed :-)
That was easy and it does stuff :-) "
Actually the change was made using the b3 aggregation editor. I was going to make the change by hand because the editor doesn't appear to work for me in kepler, but Beth insisted on using it. So whatever went wrong was caused by your own tools.
I hope a few of my comments are constructive
and encouraging, I don't mean to argue about it.
But, I am pretty firm about schedules.
And you've not answered any of my original questions (except to provide
a bug number), so if you'd like an exception, I'll ask you go through the
full Planning Council exception process:
http://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements#Planning_Council_Exception_Process
(And, BTW, I'm not blind to the fact
that is it a very bad bug ... but ... at the time of this writing, it doesn't
say very much, such as what the fix is, if there are workarounds, etc.
Although the fix has zero chance of affecting anyone, I don't think it's worth the chance that there will be build problems at this late stage. _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
|