Hi, maybe I can step up here, since comments from me :-) are already in this thread. I have to admit that Riena had problems with the aggregation too in the past.
I also thought for a long time (actually years) that the only way to "try" a new contribution is to build, sign, upload, change b3aggrcon,commit,push wait for the aggregation to kick off and pray that there is a reasonable result while I am still awake. (because of the time difference sometimes). Try a new run while its actually already after bed-time in my country. Now yesterday I found that all you need to do is run Eclipse, with org.eclipse.simrel.build checked out in your workspace and the b3 aggregator editor installed (i.e. http://download.eclipse.org/modeling/emft/b3/updates-4.2/) Now I can try to add a new version of Riena, build, sign, upload, change b3aggrcon but now instead of committing,pushing, praying (you remember from above) you can in the aggregation editor right click and say "Validate Aggregation". It takes under 5 minutes and you get exactly the same message that you have to search and find in the aggregation build console. Of course you can also locally disable other projects that get in the way of validating your project. Really really EASY and I wish I had tried that years ago.... Christian campo Von: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] Im Auftrag von sven.rottst...@sungard.com Gesendet: Donnerstag, 23. Mai 2013 15:44 An: cross-project-issues-dev@eclipse.org Betreff: 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-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org> [mailto:cross-project-issues-dev-boun...@eclipse.org] 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_willi...@us.ibm.com<mailto:david_willi...@us.ibm.com>> 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.wat...@computer.org<mailto:g.wat...@computer.org>> To: Cross project issues <cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>>, 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-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org> ________________________________ 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@eclipse.org<mailto:cross-project-issues-dev@eclipse.org> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ------------------------------------------------------------- compeople AG Untermainanlage 8 60329 Frankfurt/Main fon: +49 (0) 69 / 27 22 18 0 fax: +49 (0) 69 / 27 22 18 22 web: www.compeople.de<http://www.compeople.de/> Vorstand: J?rgen Wiesmaier Aufsichtsratsvorsitzender: Christian Glanz Sitz der Gesellschaft: Frankfurt/Main Handelsregister Frankfurt HRB 56759 USt-IdNr. DE207665352 -------------------------------------------------------------
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
