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.
Seriously, thanks for your comments
and and thanks for your contributions to Eclipse.
From:
Greg Watson <g.watson@xxxxxxxxxxxx>
To:
Cross project issues
<cross-project-issues-dev@xxxxxxxxxxx>,
Date:
05/22/2013 10:28 PM
Subject:
Re: [cross-project-issues-dev]
Status and outlook for RC1 ...
its going
to be a late night!
Sent by:
cross-project-issues-dev-bounces@xxxxxxxxxxx
David,
Somewhat late at night to be arguing, but I find this
statement perplexing:
All projects are responsible for making
sure the build works, notified or not.
I have no idea how the aggregation works, nor have I seen
any policy that indicates that I need to. I'm happy to take responsibility
for our repo, but I think those responsible for the aggregation are also
responsible for contacting projects if there are any problems. Isn't this
is why we are listed as contacts in the simrel.b3aggr file, after all?
As far as I'm aware, this is how it has worked in the past. Are you
proposing a change to the process?
Greg
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
|