Re: [epp-dev] Exceptions when starting Neon M4 packages

["David M Williams" <david_williams@xxxxxxxxxx>]

> - Do not enable
the EPP p2 repository with the M4 version of the packages today

I see this as the same as "not
releasing M4" (since no one could "update" an M3 package).

I suggest to either "wait for all",
or "push more aggressively" to release today. 

I am not very aware of your "time
constraints" (i.e. your "day" ends before mine does). 

If it helps, I could "flip your
switch" around 3 or 4 PM, if the rebuilds got positive votes? 

As a possible "third" alternative,
release all today -- at least open up repository -- then early next week
create your M4a, so that anyone who got "todays" build, and encountered
the "break" could "check for updates" Tuesday or so
to get the fix? 






From:      
 Markus Knauer <mknauer@xxxxxxxxxxxxxxxxx>
To:      
 EPP Developer Mailing
List <epp-dev@xxxxxxxxxxx>, 
Date:      
 12/18/2015 09:26 AM
Subject:    
   Re: [epp-dev]
Exceptions when starting Neon M4 packages
Sent by:    
   epp-dev-bounces@xxxxxxxxxxx

---

Thank you for providing the workaround. It looks good
to me and I would push it as soon as I verified the results from the verification
job.

How do we proceed from here? I suggest the following:

*TODAY*
- Wait for the verification job and verify that is a valid
workaround that solves the problem in M4 and does not introduce any unwanted
side effects.
- Publish the M4 packages that received a +1 as planned
today, hold back those that got a -1
- Do not enable the EPP p2 repository with the M4 version
of the packages today

*BEGINNNG OF NEXT WEEK*
- Create an M4a based on the workaround
- Publish M4a packages for those with a -1 in M4 (probably
on Tuesday, Wednesday at the latest depending on mirror servers and package
maintainers)
- Enable the M4a EPP p2 repository together with the M4a
packages

Current voting status:

?  C/C++
+1  Java, Modeling, Android, DSL, Testers, Automotive,
RCP/RAP
-1  Parallel

Does anyone have any objections? Or better proposals? If I don't hear any
objections until, let's say 11am eastern I'd move on as proposed.

Thanks and regards,
Markus



On 18 December 2015 at 14:57, Andreas Sewe <andreas.sewe@xxxxxxxxxxxxxx>
wrote:
> Agreed. I wouldn't want to do a whole simre-repo-rebuild
cycle. But
> maybe we can fix it just with a few lines on a .product or feature.xml.
> I'll try this locally.

Workaround is in Gerrit [1]. This adds the org.eclipse.jdt.annotations
bundles as a dependency to the org.eclipse.epp.package.common.feature,
from which it should be removed again Marcel has time to fix Bug 484629.

Best wishes,

Andreas

[1] <https://git.eclipse.org/r/#/c/63020/>

--
Codetrails GmbH
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt
Phone: +49-6151-276-7092
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940
_______________________________________________
epp-dev mailing list
epp-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/epp-dev



-- 

###
EclipseSource Group
Telefon: +49 721 664733-0 (GMT +2)
Telefax: +49 721 66473329

http://eclipsesource.com


Innoopract Informationssysteme GmbH
Lammstrasse 21, 76133 Karlsruhe Germany 
General Manager: Jochen Krause
Registered Office: Karlsruhe, Commercial Register Mannheim HRB 107883_______________________________________________
epp-dev mailing list
epp-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/epp-dev