Re: [cross-project-issues-dev] Status and outlook for RC1 ... its going

[David M Williams <david_williams@xxxxxxxxxx>]

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/
? 

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! 

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 :-) "

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.


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