In the past, we've had this timeline:
* create mirrors as soon as bits are available on
eclipse.org (Thurs or Fri)
* submit PR for proposed changes to TP (Fri or Mon)
* wait 2 days to review
* apply changes on Wed (TP freeze day)
* trigger builds using updated TP on Thursday (code freeze day)
* build full stack & stage for QE on Friday
* release on Mon/Tuesday after QE signoff
So, if we intend to follow that same pattern, with a code freeze
tomorrow so we can build something for QE to review on Monday & can
then demo it on Tuesday at the close of Sprint #113, that means we
would need to have proposed this change, complete with PR and mirrors,
AT LEAST TWO DAYS AGO.
With Alexey's approval we COULD skip the review process, but given...
* this is a short sprint (most expected 3 weeks, not 2),
* this first release is only an Alpha1,
* several devs / teams are trying to audit changes in 4.3.x not pushed
to master,
... I'm not confident that it's a good time to change the target
platform this week.
M6 arrived a full month ago. If we'd wanted to move it it, we should
have done so last week or earlier.
-100, too late.
On Wed, Apr 27, 2016 at 10:21 AM, Mickael Istria <mistria(a)redhat.com> wrote:
Hi all,
If the goal of 1st milestone is to be compatible with Neon, does this
include adoption of the Smart Importer from Platform UI ? If so, it implies
that we need to have a TP update to use Neon M6.
Should we include this move into the current sprint?
Cheers,
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat
My blog - My Tweets
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com