I noticed tonight that downloads.jboss.org/jbosstools/updates/kepler/ now points to Alpha2-snapshot. Isn't this site referenced by our /development site where there is alpha1 that is not tested against alpha2? ps. tried investigate with https://github.com/ifedorenko/p2-browser but that seems to no longer launch with neither java6 nor java7 :( /max _______________________________________________ jbosstools-dev mailing list jbosstools-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev

On Thu, Mar 21, 2013 at 12:54:48AM -0400, Nick Boldt wrote: > Max: > > If you look in the git history for > https://github.com/jbosstools/jbosstools-download.jboss.org/commits/master, > you'll see my commits. As to pushing files from github to > download.jboss.org, there's a sync job for that but it only fires a > few times a day. > > The Alpha1 released bits and Alpha2-SNAPSHOT bits are nearly the same. > The only difference is the unannounced change which added Jetty 8 > stuff (JBIDE-13736). History is here: > https://github.com/jbosstools/jbosstools-target-platforms/commits/4.30.x so we are back at again pushing stuff into our TP without announcement and putting it live - please stop doing that. Thanks! > If you prefer I can set updates/kepler/ to point at Alpha1 released > bits (it was previously pointing at the Alpha1-SNAPSHOT bits), and > Alpha2-SNAPSHOT will be the full Kepler M6 set of changes I announced > earlier this week. Or, we can make the new M6 TP called > Alpha3-SNAPSHOT to differentiate it from this KeplerM5+Jetty8.19 > variation. Personally, I prefer that, but YMMV. I prefer we don't point updates/kepler to snapshot/unannounced/untested content. The whole point of the snapshot/release model we've been discussing is to stop these under the covers TP movements. /max > --- > > (2013-03-20 20:26:39) maxandersen: nickboldt: stupid question but why > is kepler now updated to alpha2 before we released alpha2 ?! > (2013-03-20 20:26:56) maxandersen: i.e. > https://github.com/jbosstools/jbosstools-download.jboss.org/pull/105/files > > (2013-03-20 20:29:40) maxandersen: and nickboldt I can see dgolovin > applied > https://github.com/jbosstools/jbosstools-download.jboss.org/pull/102 > but not seeing the effect on download.jboss.org ….did we miss to kick > up a sync somewhere? > > On 03/20/2013 09:03 PM, Max Rydahl Andersen wrote: >> I noticed tonight that downloads.jboss.org/jbosstools/updates/kepler/ >> now points to >> Alpha2-snapshot. >> >> Isn't this site referenced by our /development site where there is >> alpha1 that is not tested against alpha2? >> >> ps. tried investigate with https://github.com/ifedorenko/p2-browser >> but that seems to no longer launch with neither java6 nor java7 :( >> >> /max >> _______________________________________________ >> 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

Alpha2 (M5 + Jetty 8) and Alpha3 (Kepler M6 + Atlassian, etc.) won't be linked from there until were release JBT 4.1.0.Alpha2

On Sat, Mar 23, 2013 at 11:31:07AM +0100, Mickael Istria wrote: > On 03/23/2013 05:41 AM, Nick Boldt wrote: >> Alpha2 (M5 + Jetty 8) and Alpha3 (Kepler M6 + Atlassian, etc.) won't be >> linked from there until were release JBT 4.1.0.Alpha2 > Why would we need an Alpha3, and why would we release an Alpha2 ? I assume you mean why would we not just release an Alpha2 so the latest TP are available to use for next JBT release which coincidently is named Alpha2 too ?

On 03/23/2013 11:37 AM, Max Rydahl Andersen wrote: > On Sat, Mar 23, 2013 at 11:31:07AM +0100, Mickael Istria wrote: >> On 03/23/2013 05:41 AM, Nick Boldt wrote: >>> Alpha2 (M5 + Jetty 8) and Alpha3 (Kepler M6 + Atlassian, etc.) won't be >>> linked from there until were release JBT 4.1.0.Alpha2 >> Why would we need an Alpha3, and why would we release an Alpha2 ? > > I assume you mean why would we not just release an Alpha2 so the latest TP are available to use for next JBT release which coincidently is named Alpha2 too ? Yes, that's what I mean. I mainly mean: why do we already have an Alpha3 whereas we still are doing snapshots of Alpha2. All TP changes until we release a new milestone of JBT should be in the current snapshot (TP 4.30.5.Alpha2-SNAPSHOT). -- Mickael Istria Eclipse developer at JBoss, by Red Hat My blog - My Tweets

On Sat, Mar 23, 2013 at 10:12:47AM -0400, Nick Boldt wrote: > Because Alpha2 was an interim state: Kepler M5 w/ newer Jetty 8 (plus > Atlassian 3.0.7, SWTBot 2.0.5). but as Micakel mention, alpha2-snapshot is where interim state is fine and its not published anywhere so why not just add what you call alpha3 into this ? /max > Alpha3 is incompatible w/ Alpha2 as it includes Kepler M6, Atlassian > 3.2, and SWTBot 2.1. > N > > On 03/23/2013 09:01 AM, Mickael Istria wrote: >> On 03/23/2013 11:37 AM, Max Rydahl Andersen wrote: >>> On Sat, Mar 23, 2013 at 11:31:07AM +0100, Mickael Istria wrote: >>>> On 03/23/2013 05:41 AM, Nick Boldt wrote: >>>>> Alpha2 (M5 + Jetty 8) and Alpha3 (Kepler M6 + Atlassian, etc.) >>>>> won't be >>>>> linked from there until were release JBT 4.1.0.Alpha2 >>>> Why would we need an Alpha3, and why would we release an Alpha2 ? >>> >>> I assume you mean why would we not just release an Alpha2 so the >>> latest TP are available to use for next JBT release which coincidently >>> is named Alpha2 too ? >> Yes, that's what I mean. >> I mainly mean: why do we already have an Alpha3 whereas we still are >> doing snapshots of Alpha2. All TP changes until we release a new >> milestone of JBT should be in the current snapshot (TP >> 4.30.5.Alpha2-SNAPSHOT). >> >> -- >> Mickael Istria >> Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools> >> My blog <http://mickaelistria.wordpress.com> - My Tweets >> <http://twitter.com/mickaelistria> > > -- > Nick Boldt :: JBoss by Red Hat > Productization Lead :: JBoss Tools & Dev Studio > http://nick.divbyzero.com

> Does it really matter as long as the version goes up? It will introduce many "useless" TP versions and confuse us, and the rest of the team. I'm in favor in releasing as few TPs as necessary. -- Mickael Istria Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools> My blog <http://mickaelistria.wordpress.com> - My Tweets <http://twitter.com/mickaelistria>

Then we should coordinate the changes better. Your addition of Jetty (to Alpha2) happened a week before I started on the move to Kepler M6. Had they all happened the same day, then yes, they would have all been part of Alpha2. But because there was a chance someone was using Alpha2 with the new Jetty with Kepler M5, I didn't want to break them by suddenly changing the underlying baseline. The last time we had a workflow where contents of the target platform could change "at random", to use Max's favourite phrase, Max complained every time.

Now, I version them explicitly so that every substantial commit is a new version... and ya'll complain about that too.

In the grand scheme of things, wouldn't you rather have snapshots you can ignore (Alpha2, than snapshots that no longer exist because they were overwritten?

IMHO it's *more confusing* if you're building one day with Alpha2 and it works (because Kepler M5) and the next day it stops working (because Kepler M6), than if you discover an email saying "want to use Kepler M6? Grab the Alpha3 version of the target platform."

On 03/25/2013 05:32 PM, Nick Boldt wrote: > Then we should coordinate the changes better. Your addition of Jetty > (to Alpha2) happened a week before I started on the move to Kepler M6. > Had they all happened the same day, then yes, they would have all been > part of Alpha2. > But because there was a chance someone was using Alpha2 with the new > Jetty with Kepler M5, I didn't want to break them by suddenly changing > the underlying baseline. > The last time we had a workflow where contents of the target platform > could change "at random", to use Max's favourite phrase, Max > complained every time. In my understanding SNAPSHOT means "Work in Progress/nothing guaranteed" and includes that it can change more or less "at random". So we can make incremental changes on the target-platform. But that's only my understanding, maybe in our context it means something different. If we keep my definition of SNAPSHOT, the fact that Alpha2 has not been released means that we are free to change it. The general idea of a SNAPSHOT is that we won't be able to make the target-platform at first shot, it gives us the right to make mistakes that we can fix easily (by fixing and respinning this snapshot) and to make incremental changes, which will make the team happy as different requests for TP change happen multiple times during a dev stream. > Now, I version them explicitly so that every substantial commit is a > new version... and ya'll complain about that too. It's better ;) But I'm wondering about the usefulness of moving to Alpha3-SNAPSHOT when there is still an Alpha2 pending. > In the grand scheme of things, wouldn't you rather have snapshots you > can ignore (Alpha2, than snapshots that no longer exist because they > were overwritten? What is the benefit? This is going to lead us to have one version for each TP revision. We already have revisions to track atomic changes, I'm not sure we need something as fine-grained for public Maven versuins. Also, your proposal about more TP versions (with some ignored) will imply more maintenance effort to switch from a TP to another. We (ie you and me) won't like it. > IMHO it's *more confusing* if you're building one day with Alpha2 and > it works (because Kepler M5) and the next day it stops working > (because Kepler M6), than if you discover an email saying "want to use > Kepler M6? Grab the Alpha3 version of the target platform." If you're using one day Alpha2*-SNAPSHOT* and it works means that there will be some changes that may break you. So we make master use SNAPSHOT, and make changes on SNAPSHOT, and if we do something wrong, people will see it, us included. -- Mickael Istria Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools> My blog <http://mickaelistria.wordpress.com> - My Tweets <http://twitter.com/mickaelistria>

On 03/25/2013 05:39 PM, Max Andersen wrote: >Noone *required* those jetty deps in the published TP yet. Isn't https://issues.jboss.org/browse/JBIDE-13736 a request?

I fixed this immediately and agree on the need to get feedback from the team before we change the TP. I also suggest that when the PR is submitted, someone deploys a "specific" snapshot to make test easier (ie something like a 4.3.0.5.Alpha2-<jiraId>-SNAPSHOT), so this new TP can be tested with a simple command-line overriding TARGET_PLATFORM_VERSION.

-- Mickael Istria Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools> My blog <http://mickaelistria.wordpress.com> - My Tweets <http://twitter.com/mickaelistria>

Since, the fix is so trivial, it could be merged into 4.0.x. Is it ok to have it included into 4.0.1 version, or should it wait until 4.0.2?

On Tue, Mar 26, 2013 at 04:34:45PM -0400, Max Rydahl Andersen wrote: >> Since, the fix is so trivial, it could be merged into 4.0.x. Is it ok >> to have it included into 4.0.1 version, or should it wait until 4.0.2? > > Does all test pass ? Did the fix have some great effect and have you pinged QE to do a test run ? > > Since 4.0.1 is to go out anytime soon I would probably wait to avoid any surprises. Slava, Alexey, Nick - just to repeat what was talked about on irc: talking through with dgolovin we say do *not* apply/include these for 4.0.1; its too close. only put it in 4.0.2. No more extra builds for 4.0.1 > /max > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev _______________________________________________ jbosstools-dev mailing list jbosstools-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev

On Tue, Mar 26, 2013 at 11:53:36PM -0400, Nick Boldt wrote: > Regrettably, the jobs had already spun by the time I saw your comments > here. Next time please disable jobs that should not be run AND > announce the fact that commits in the branch should NOT be included in > the build stack. What went wrong is that Alexey believed the jobs were disabled so they would not get in - but yes, I agree it was premature to put them in. > It's better to wait until after the 4.0.1.Final release if you want it > to end up in a hypothetical unscheduled future 4.0.2 release. It is in there now. If QE do not want it we will have to revert;but lets see what QE sees/finds before spending more time back and forth. But from now - 4.0.x is *frozen solid*. /max > N > > On 03/26/2013 06:08 PM, Max Rydahl Andersen wrote: >> On Tue, Mar 26, 2013 at 04:34:45PM -0400, Max Rydahl Andersen wrote: >>>> Since, the fix is so trivial, it could be merged into 4.0.x. Is it ok >>>> to have it included into 4.0.1 version, or should it wait until 4.0.2? >>> >>> Does all test pass ? Did the fix have some great effect and have you >>> pinged QE to do a test run ? >>> >>> Since 4.0.1 is to go out anytime soon I would probably wait to avoid >>> any surprises. >> >> Slava, Alexey, Nick - just to repeat what was talked about on irc: >> talking through with dgolovin we say do *not* apply/include these for >> 4.0.1; its too close. >> >> only put it in 4.0.2. >> >> No more extra builds for 4.0.1 >> >>> /max >>> _______________________________________________ >>> jbosstools-dev mailing list >>> jbosstools-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >> _______________________________________________ >> 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