Christian, Thanks for the info. I'll use this technique the next time we need to change the agg file (hopefully not soon).
Cheers, Greg On May 23, 2013, at 9:59 AM, "Campo, Christian" <[email protected]> wrote: > > 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: [email protected] > [mailto:[email protected]] Im Auftrag von > [email protected] > Gesendet: Donnerstag, 23. Mai 2013 15:44 > An: [email protected] > 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: [email protected] > [mailto:[email protected]] 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 <[email protected]> > 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 <[email protected]> > To: Cross project issues <[email protected]>, > 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: [email protected] > > > > 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 > [email protected] > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > > _______________________________________________ > cross-project-issues-dev mailing list > [email protected] > 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 > > 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 > [email protected] > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
