Re: [cross-project-issues-dev] Missing release information for some Kepler projects
On Wed, Jun 12, 2013 at 12:47 AM, Ralf Sternberg rsternb...@eclipsesource.com wrote: I don't know about the SRs but I remember that EGit updated from 1.3 to 2.0 in Juno RC2 or RC3. For me this feels like a pretty risky change for an RC. I don't mean to point the finger at EGit, I just think we should agree that RC1 should really be a release candidate, i.e. almost the thing that is going to be released except for some minor fixes. The code should cool down after that point. At least major versions should not change anymore. I agree we should contribute to the release train earlier than that. Due to our faster release cycle (4 releases per year) M6 is usually shortly after our previous release in the same year. Hence for Kepler we did the first 3.0 contribution with M7. AFAIK those who depend on us know our nightly build, watch code reviews and discussions on our mailing lists and speak up early in case they see a problem. -- Matthias ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Xtext RC4
Hi Sven Doesn't it need PMC approvals before being resolved as fixed? From the yet to be superseded http://wiki.eclipse.org/Modeling_Project_Ramp_Down_Policy/Helios After RC3: Two additional Committers and at least 2 PMC members must review and vote +1 after reviewing the bug for appropriateness and risk. After reviewing the commit myself, I see quite a lot of new lines and control flow changes in core code, but the bug description reads as a UI inelegance rather than a killer. So IMHO not really appropriate for RC4. Regards Ed Willink On 12/06/2013 10:28, Sven Efftinge wrote: Here you are : https://bugs.eclipse.org/bugs/show_bug.cgi?id=410571 The respective hudson job is : https://hudson.eclipse.org/hudson/job/Xtext-nightly-HEAD/ On Jun 12, 2013, at 11:16 AM, Ed Willink e...@willink.me.uk wrote: Hi What's the fix, what's the Bugzilla, what's the commit? Where's the build? dashboard shows no builds in the last 24 hours. Regards Ed Willink On 12/06/2013 10:00, Sven Efftinge wrote: Hi all, I just wanted to inform you that we are building an RC4a today (now). It contains an important bug fix, which won't affect any downstream projects, but is important for end users. Regards, Sven ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev - No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3345 / Virus Database: 3199/6403 - Release Date: 06/11/13 ___ cross-project-issues-dev mailing list 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 https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev - No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3345 / Virus Database: 3199/6403 - Release Date: 06/11/13 ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Xtext RC4
Ed, comments inline On Jun 12, 2013, at 11:47 AM, Ed Willink e...@willink.me.uk wrote: Doesn't it need PMC approvals before being resolved as fixed? No, we don't follow that policy anymore. From the yet to be superseded http://wiki.eclipse.org/Modeling_Project_Ramp_Down_Policy/Helios After RC3: Two additional Committers and at least 2 PMC members must review and vote +1 after reviewing the bug for appropriateness and risk. Two additional committers have reviewed the change. I don't see why votes from the PMC would help. After reviewing the commit myself, I see quite a lot of new lines and control flow changes in core code, but the bug description reads as a UI inelegance rather than a killer. So IMHO not really appropriate for RC4. It's an important missing compiler analysis. I don't think UI is mentioned at all. Regards, Sven___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Xtext RC4
Hi all, Xtext RC4a was contributed to the simrel aggregator. The changes should be available with the next simrel.kepler.runaggregator build. Best regards, Dennis. Am 12.06.2013 um 11:00 schrieb Sven Efftinge: Hi all, I just wanted to inform you that we are building an RC4a today (now). It contains an important bug fix, which won't affect any downstream projects, but is important for end users. Regards, Sven ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev Dennis Hübner Xtext Commiter / Build Engineer Mobile: +49 (0) 151 / 17 39 67 07 Telefon: +49 (0) 431 / 990 268 70 Fax: +49 (0) 431 / 990 268 72 itemis AG Niederlassung Kiel Am Germaniahafen 1 24143 Kiel http://www.itemis.de/ Rechtlicher Hinweis: Amtsgericht Dortmund, HRB 20621 Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] hudson problem
It looks like hudson has a problem: Started by user gwatson Building remotely on hudson-slave2 Checkout:ptp-nightly / /opt/buildhomes/hudsonBuild/workspace/ptp-nightly - hudson.remoting.Channel@3e125554:hudson-slave2 Using strategy: Default Last Built Revision: Revision 65855817ce0f1da63d0d6b536ebdb89da404180b (origin1/master) FATAL: cannot assign instance of hudson.EnvVars to field hudson.plugins.git.GitSCM$3.val$environment of type hudson.EnvVars in instance of hudson.plugins.git.GitSCM$3 java.lang.ClassCastException : cannot assign instance of hudson.EnvVars to field hudson.plugins.git.GitSCM$3.val$environment of type hudson.EnvVars in instance of hudson.plugins.git.GitSCM$3 at java.io.ObjectStreamClass$FieldReflector.setObjFieldValues(ObjectStreamClass.java:2032) at java.io.ObjectStreamClass.setObjFieldValues(ObjectStreamClass.java:1212) at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1953) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) at hudson.remoting.UserRequest.deserialize(UserRequest.java:178) at hudson.remoting.UserRequest.perform(UserRequest.java:98) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:283) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Xtext RC4
FYI, I trust that project leads generally know what's best for their projects and for their downstream users, so I see no general need to police or review their decisions. Regards, Ed On 12/06/2013 12:42 PM, Sven Efftinge wrote: Ed, comments inline On Jun 12, 2013, at 11:47 AM, Ed Willink e...@willink.me.uk mailto:e...@willink.me.uk wrote: Doesn't it need PMC approvals before being resolved as fixed? No, we don't follow that policy anymore. From the yet to be superseded http://wiki.eclipse.org/Modeling_Project_Ramp_Down_Policy/Helios * After RC3 http://wiki.eclipse.org/Helios#Milestones_and_Release_Candidates: Two additional Committers and at least 2 PMC members must review and vote +1 after reviewing the bug for appropriateness and risk. Two additional committers have reviewed the change. I don't see why votes from the PMC would help. After reviewing the commit myself, I see quite a lot of new lines and control flow changes in core code, but the bug description reads as a UI inelegance rather than a killer. So IMHO not really appropriate for RC4. It's an important missing compiler analysis. I don't think UI is mentioned at all. Regards, Sven ___ cross-project-issues-dev mailing list 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 https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] Disk usage report for Hudson/Build
Compiled 2013-06-12T12:07 build.eclipse.org - Usage exceeding 1GB for: Hudson master jobs and workspace (2013-06-12T10:00) 32.7G ep4-unit-lin64 3.1G koneki-ldt-maintenance 2.8G emf-emfclient-maintenance 2.3G Xtext-nightly-HEAD 2.0G stardust-kepler 1.9G stardust-7-nightly 1.9G emf-cdo-integration 1.7G gef4-master 1.6G papyrus-trunk-nightly 1.6G tycho-gmp.gmf.tooling.maintenance 1.6G emf-core-maintenance 1.5G papyrus-0.9-maintenance-nightly 1.4G amp-integration 1.2G tycho-gmp.gmf.tooling 1.2G webtools-vjet-juno 1.2G buckminster-voicetools-targetplatform 1.1G buckminster-egf-juno 1.0G mdt-sphinx-0.7-juno - Usage exceeding 1GB for: /shared (1000G capacity) (2013-06-12T10:00) 156.6G technology 126.9G jobs 102.4G eclipse 75.8G rt 25.7G webtools 20.1G SLES 9.7G tools 7.2G common 7.1G cbi-ng 6.0G simrel 5.1G modeling 2.0G orbit 1.6G mylyn 1.4G soa 1.3G cbi - Usage exceeding 1GB for: /shared/modeling 3.1G build - Usage exceeding 1GB for: /shared/tools 4.6G tm 1.4G mtj 1.3G windowbuilder 1.1G aspectj - Usage exceeding 1GB for: /shared/technology 133.3G epp 8.2G sapphire 4.8G stem 4.3G babel 2.4G cosmos 1.3G actf END: build.eclipse.org hudson-slave1.eclipse.org /dev/xvda1158G 90G 68G 58% / - Usage exceeding 1GB for: Hudson workspace on hudson-slave1 (50G capacity) (2013-06-11T21:00) 3.1G ptp-master-release 2.8G koneki-ldt 2.1G ptp-nightly 1.9G tycho-mat-nightly 1.8G papyrus-0.8-EYY-maintenance 1.7G ptp-master-nightly 1.7G tycho-its-linux-nightly 1.7G linuxtools-kepler 1.6G cdt-nightly 1.5G cdt-maint 1.4G sapphire-0.7.x 1.4G papyrus-trunk-nightly 1.3G emf-cdo-integration 1.3G Xtext-nightly-Maintenance 1.3G Xtext-nightly-HEAD 1.2G cdt-legacy 1.2G matt_linuxtools-test 1.2G gef-master 1.2G emft-texo-nightly 1.1G emf-core-head 1.0G Xtext-integration-test 1.0G gyrex-integration END: hudson-slave1.eclipse.org hudson-slave2.eclipse.org - Usage exceeding 1GB for: END: hudson-slave2.eclipse.org hudson-slave3.eclipse.org /dev/xvda1 55G 32G 24G 58% / - Usage exceeding 1GB for: Hudson workspace on hudson-slave3 (50G capacity) (2013-06-11T18:00) 1.0G emf-core-maintenance END: hudson-slave3.eclipse.org ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] Kepler's final staging repository is complete
Here we are, at (near) the end of RC4 already! EPP packages will be complete in a day or two. Everyone, and especially anyone who pushed changes late in the day, should confirm the staging repo contains what you expect it to. http://download.eclipse.org/releases/staging/ The final repo-reports are available at the usual place: http://build.eclipse.org/simrel/kepler/reporeports/ For those of you with missing legal files ... it is between you and the EMO if they will grant an exception for the release. I know of only one project that as requested it (bug 401273). As for other things, such as unsigned jars, technically you should work with your PMC and planning representative to ask for exceptions, but suspect if you have not done so by now, it's simply a matter that you don't care. But, if you do, the reference is http://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements#Planning_Council_Exception_Process Beyond that, I'll leave it up to the rest of the Planning Council to raise objections if they think any violations are so egregious it deserves discussing whether or not to included in the common repo. Remember that as we enter quiet week we do NOT promote the builds to their usual place, since to do so is basically making the release available early. The purpose of quiet week is partially to allow adopters to do final acceptance testing, but to also serve as a buffer in case a build is required -- but, rebuilds are very risky, and rare, so has to be an especially bad bug (such as one which prevents install or update from working, or perhaps where one project prevents another project from working). Otherwise, the extra time is for projects to prepare hot fix feature patches to be available from their own project repositories. If you like to read wordy, but possibly educational, documents, don't forget about http://wiki.eclipse.org/Kepler/Final_Daze Thanks everyone. Good luck with your final testing and wrap-up. ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
