Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Status and outlook for RC1 ... its going to be a late night!

Hi Greg,

 

[1] shows that the build was triggered by only one SCM change with the comment: “For ptp, add org.eclipse.ptp.debug.sdm feature”. Before of this change the build was working. So IMO it suggests itself that this commit was breaking the build.

 

BTW: This is exactly the way how I was checking that my change for Kepler RC1 was not breaking the build (because it was my first commit into the simrel repo), that was obviously not that case [2] ;)

 

In general I would vote to use Gerrit and CI a little bit closer together how it is mentioned in [3]. But IMO this is not acceptable for such a “build sprint”.

 

[1] https://hudson.eclipse.org/hudson/job/simrel.kepler.runaggregator/476/

[2] https://hudson.eclipse.org/hudson/job/simrel.kepler.runaggregator/472/

[3] http://blogs.collab.net/teamforge/teamforge-git-gerrit-integration-with-jenkins-ci

 

Cheers,

Sven

 

Von: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] Im Auftrag von Greg Watson
Gesendet: Donnerstag, 23. Mai 2013 13:38
An: Cross project issues
Betreff: Re: [cross-project-issues-dev] Status and outlook for RC1 ... its going to be a late night!

 

 

On May 22, 2013, at 11:43 PM, David M Williams <david_williams@xxxxxxxxxx> wrote:



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

 


Back to the top