Summary of IRC Meeting in #aurora

[ASF IRC Bot <as...@urd.zones.apache.org>]

Summary of IRC Meeting in #aurora at Mon Sep 14 18:00:52 2015:

Attendees: jfarrell, jcohen, wfarner, ptc, Yasumoto, kts, mkhutornenko, zmanji, dlester, qorio

- Preface
- SF Bay Area meetup/workshop
- New mailing lists
- 0.10.0 release goals
- Project roadmap
- Mesos version tracking
- jax-rs provider


IRC log follows:

## Preface ##
[Mon Sep 14 18:00:59 2015] <wfarner>: let's start with a roll call
[Mon Sep 14 18:01:00 2015] <wfarner>: here
[Mon Sep 14 18:01:11 2015] <zmanji>: here
[Mon Sep 14 18:01:19 2015] <kts>: here
[Mon Sep 14 18:02:12 2015] <mkhutornenko>: here
[Mon Sep 14 18:02:14 2015] <qorio>: here
[Mon Sep 14 18:02:23 2015] <dlester>: present
[Mon Sep 14 18:02:40 2015] <jcohen>: here
[Mon Sep 14 18:03:41 2015] <jfarrell>: here
## SF Bay Area meetup/workshop ##
[Mon Sep 14 18:05:49 2015] <wfarner>: http://www.meetup.com/Bay-Area-Apache-Aurora-Users-Group/events/225070323/?a=ra1_vl&_af=event&_af_eid=225070323
[Mon Sep 14 18:06:11 2015] <dlester>: \m/ should be a good one
[Mon Sep 14 18:06:18 2015] <wfarner>: just a quick announcement that we have a few remaining open spots for our workshop tomorrow!  if you're local, this will be a good time to chat about getting started and where the project is going!
[Mon Sep 14 18:06:30 2015] <jcohen>: Wish I could be there, sounds like it should be fun!
## New mailing lists ##
[Mon Sep 14 18:08:10 2015] <wfarner>: we have two new mailing lists - user@aurora.apache.org and announce@aurora.apache.org
[Mon Sep 14 18:08:24 2015] <wfarner>: if you're currently subscribed to the dev list, you will probably want to subscribe to those two lists
[Mon Sep 14 18:08:50 2015] <wfarner>: and if you've avoided/filtered the dev list because of too much noise, you can expect those lists to be higher-signal
[Mon Sep 14 18:08:51 2015] <kts>: free advice - subscribe by mailing user-subscribe@aurora.apache.org and announce-subscribe@aurora.apache.org
[Mon Sep 14 18:08:57 2015] <wfarner>: https://aurora.apache.org/community/
[Mon Sep 14 18:09:34 2015] <wfarner>: jfarrell: i noticed the archive links for the new lists are funky/broken - any idea what's up with that?
[Mon Sep 14 18:09:39 2015] <wfarner>: is there more setup we need to do?
[Mon Sep 14 18:09:58 2015] <jfarrell>: they dont exist until mail is recv
[Mon Sep 14 18:10:10 2015] <wfarner>: ok, makes sense
## 0.10.0 release goals ##
[Mon Sep 14 18:10:46 2015] <wfarner>: http://mail-archives.apache.org/mod_mbox/aurora-dev/201508.mbox/%3CCAK7Zj13Ufpk%3D%2BYPftNX-PXEzaZyi-h2nX0PZiX0jxmSObBQ9Xg%40mail.gmail.com%3E
[Mon Sep 14 18:10:49 2015] <wfarner>: AURORA-1250
[Mon Sep 14 18:11:08 2015] <zmanji>: Please share what you want in 0.10.0 otherwise this release is going to be whatever wfarner wants it to be
[Mon Sep 14 18:11:34 2015] <wfarner>: zmanji: i think at this point we should get started, we can definitely still collect input
[Mon Sep 14 18:11:49 2015] <zmanji>: agreed, I’ll be updating JIRA today or tomorrow
[Mon Sep 14 18:11:58 2015] <wfarner>: thank you!
## Project roadmap ##
[Mon Sep 14 18:12:34 2015] <wfarner>: https://docs.google.com/document/d/1vyhTZSlEPeibQm2_7HK6JXOkydO0ZllZNQZ2O3cC4_0
[Mon Sep 14 18:12:40 2015] <jfarrell>: zmanji: are you playing the role or RM for .10 ?
[Mon Sep 14 18:13:05 2015] <wfarner>: jfarrell: i believe he is
[Mon Sep 14 18:13:47 2015] <wfarner>: we've gotten a bunch of great feedback on the roadmap document above.  i'd like to try to close up all outstanding threads this week if possible
[Mon Sep 14 18:14:28 2015] <wfarner>: if there are contentious/unclear topics, i suggest that we remove them from the roadmap and let individuals clarify/champion them in dev@ threads to add them later
[Mon Sep 14 18:14:39 2015] <wfarner>: sound good?
[Mon Sep 14 18:15:02 2015] <zmanji>: +1
## Mesos version tracking ##
[Mon Sep 14 18:17:11 2015] <wfarner>: now that we are building packages, should we have a plan for how we track mesos versions?
[Mon Sep 14 18:18:00 2015] <wfarner>: our 0.9.0 release depends on mesos 0.22.0, master depends on 0.23.0, and 0.24.0 was just released
[Mon Sep 14 18:18:24 2015] <kts>: are you suggesting we try to match their release cadence?
[Mon Sep 14 18:18:25 2015] <wfarner>: should we be doing patch releases bumping mesos versions?
[Mon Sep 14 18:18:41 2015] <zmanji>: Do we know what the compatability guarantees are?
[Mon Sep 14 18:18:54 2015] <wfarner>: kts: no, i think that would be disruptive
[Mon Sep 14 18:19:09 2015] <wfarner>: zmanji: i don't know about that
[Mon Sep 14 18:19:14 2015] <Yasumoto>: doing patch versions would be helpful for those that want to have stable frameworks while upgrading Mesos.. but I'm not sure what the demand for that is
[Mon Sep 14 18:19:42 2015] <Yasumoto>: as an operator, that'd help decouple my upgrade cycle of framework + mesos, which would be nice
[Mon Sep 14 18:20:01 2015] <kts>: i think that's an abuse of patch releases
[Mon Sep 14 18:20:03 2015] <wfarner>: fwiw in the last week, there's been a handful of questions about whether 0.9.0 should work with mesos 0.22.1, 0.23.0, etc
[Mon Sep 14 18:20:08 2015] <kts>: in semver terms
[Mon Sep 14 18:20:13 2015] <wfarner>: kts: true
[Mon Sep 14 18:20:33 2015] <wfarner>: is this a problem we should not try to solve right now?
[Mon Sep 14 18:20:38 2015] <kts>: any 0.9.x should be able to substitute for any other
[Mon Sep 14 18:20:57 2015] <zmanji>: I would like to see what the mesos developers think about this
[Mon Sep 14 18:21:20 2015] <jcohen>: zmanji: what do you think they’d offer in this case?
[Mon Sep 14 18:21:26 2015] <jfarrell>: probably shoud track this in the NEWS file so people can see which versions where built agains which
[Mon Sep 14 18:21:27 2015] <kts>: i think backporting mesos patch releases would be okay for a patch release
[Mon Sep 14 18:21:44 2015] <kts>: i.e. we can release a 0.9.1 that depends on 0.22.1
[Mon Sep 14 18:21:47 2015] <zmanji>: jcohen: I think they would have some idea on what frameworks should be doing
[Mon Sep 14 18:21:48 2015] <wfarner>: jfarrell: we do that currently
[Mon Sep 14 18:22:16 2015] <jcohen>: zmanji: I don’t think they’d be interested in how frameworks are released though, that seems like a lot for them to manage.
[Mon Sep 14 18:23:18 2015] <kts>: as far as i understand their compatibility guarantees are semver-like for (0.N -> 0.(N+1))
[Mon Sep 14 18:23:27 2015] <Yasumoto>: I'm okay with not solving now
[Mon Sep 14 18:23:34 2015] <kts>: (upstream mesos)
[Mon Sep 14 18:23:46 2015] <Yasumoto>: fwiw the process of upgrading aurora in ~lockstep with mesos is okay, and will help reduce fragmentation
[Mon Sep 14 18:23:59 2015] <Yasumoto>: (where lockstep == major Aurora release versions)
[Mon Sep 14 18:24:33 2015] <kts>: im okay with doing patch releases for mesos versions, let's just call them 0.N+1.0
[Mon Sep 14 18:24:49 2015] <ptc>: i can say as a user, just knowing you can run aurora 0.9.0 with mesos versions 0.22.0, 0.23.0, etc. would be useful. Just more upgrade guidance would be great.
[Mon Sep 14 18:25:04 2015] <wfarner>: agreed re: guidance
[Mon Sep 14 18:26:00 2015] <kts>: agreeing on a convention will also help us developers internally
[Mon Sep 14 18:26:04 2015] <wfarner>: kts: can you give an example?  say we go back to have 0.9.0 depend on mesos 0.24.0, what's our version number?
[Mon Sep 14 18:26:13 2015] <kts>: 0.10.0
[Mon Sep 14 18:26:47 2015] <wfarner>: that's what i was afraid of :-/
[Mon Sep 14 18:27:15 2015] <wfarner>: at least, that's what i was referring to when i said it could be disruptive
[Mon Sep 14 18:27:39 2015] <jcohen>: I was going to suggest that perhaps we always release a new version whenever mesos releases a new version, but it gets tricky with regards to in-flight features.
[Mon Sep 14 18:28:06 2015] <jcohen>: we might have to develop features on branches if we wanted to adopt that sort of model.
[Mon Sep 14 18:28:17 2015] <kts>: 0.10.0 could just be a cherry-pick on 0.9.0 if mesos has minimal changes
[Mon Sep 14 18:28:37 2015] <mkhutornenko>: jcohen: in-flight features is my biggest concern, we could get too much fragmentation to make sense for anyone
[Mon Sep 14 18:28:58 2015] <kts>: sometimes mesos will have new features though, and upgrading mesos version will be non-trivial
[Mon Sep 14 18:29:06 2015] <kts>: which would make it just like any other new feature
[Mon Sep 14 18:29:12 2015] <mkhutornenko>: I am -1 on feature-branch development
[Mon Sep 14 18:29:30 2015] <mkhutornenko>: is it really pressing us to adopt mesos version urgently?
[Mon Sep 14 18:29:36 2015] <jcohen>: perhaps every time we’re going to release we also update to the altest stable mesos version?
[Mon Sep 14 18:29:44 2015] <mkhutornenko>: why can’t we bundle it with the next scheduled release?
[Mon Sep 14 18:29:46 2015] <jcohen>: s/altest/latest
[Mon Sep 14 18:30:02 2015] <kts>: yeah - "release more often" seems like the least confusing way around this
[Mon Sep 14 18:30:11 2015] <mkhutornenko>: agree
[Mon Sep 14 18:30:31 2015] <jcohen>: sounds good to me ;)
[Mon Sep 14 18:30:39 2015] <kts>: we don't really have the scale to support feature branches
[Mon Sep 14 18:30:53 2015] <kts>: or backport branches
[Mon Sep 14 18:31:52 2015] <wfarner>: +1
[Mon Sep 14 18:33:42 2015] <wfarner>: that exhausts my topics for today - does anyone else have a topic to discuss?
[Mon Sep 14 18:34:54 2015] <wfarner>: oh, actually - one more
## jax-rs provider ##
[Mon Sep 14 18:35:51 2015] <wfarner>: background - we're currently depending on jersey 1.x as a jax-rs provider.  upgrading to 2.x is non-trivial since jersey built their own dependency injection system and the integration with guice is shaky/broken
[Mon Sep 14 18:36:16 2015] <wfarner>: i would like to suggest that we consider switching providers, since our current jersey dep has a large/old dependency tree
[Mon Sep 14 18:36:31 2015] <kts>: +1
[Mon Sep 14 18:37:11 2015] <wfarner>: i have a branch that switches us to resteasy, which was not a dramatic change
[Mon Sep 14 18:37:12 2015] <zmanji>: What other providers are there?
[Mon Sep 14 18:37:33 2015] <jcohen>: resteasy?
[Mon Sep 14 18:37:44 2015] <wfarner>: zmanji: https://en.wikipedia.org/wiki/Java_API_for_RESTful_Web_Services#Implementations
[Mon Sep 14 18:38:08 2015] <wfarner>: for anyone interested in the jersey issues: https://java.net/jira/browse/JERSEY-1950
[Mon Sep 14 18:38:15 2015] <kts>: it looks like there's an apache project purporting to implement JAX-RS as well - have you investigated that? http://cxf.apache.org/docs/jax-rs.html
[Mon Sep 14 18:38:24 2015] <zmanji>: so long as we clearly document (guice integration) why we are swtiching provideres I don’t really care what we use
[Mon Sep 14 18:39:13 2015] <wfarner>: zmanji: where would documentation like that go?  or do you just mean a discussion?
[Mon Sep 14 18:39:22 2015] <zmanji>: A discussion like in the ticket or review
[Mon Sep 14 18:39:40 2015] <zmanji>: just so one year down the road when someone asks why are we using $FOO instead of jersey 2.x we know why
[Mon Sep 14 18:40:05 2015] <wfarner>: gotcha
[Mon Sep 14 18:40:38 2015] <jfarrell>: should move to a discussion thread on dev@
[Mon Sep 14 18:40:40 2015] <wfarner>: kts: i have not investigated cxf, but i did run across it.  my starting point was basically finding the most popular frameworks, then filtering by explicit guice support
[Mon Sep 14 18:40:59 2015] <wfarner>: jfarrell: yes yes, of course.  i just wanted to take a pulse on the topic
[Mon Sep 14 18:41:24 2015] <wfarner>: that's it for me today, floor is open
[Mon Sep 14 18:42:00 2015] <kts>: it has a class called AbstractServiceFactoryBean - it's like all the java things at once
[Mon Sep 14 18:43:53 2015] <wfarner>: sounds like we've quiesced. thank for joining, everyone!
[Mon Sep 14 18:43:56 2015] <wfarner>: ASFBot: meeting stop


Meeting ended at Mon Sep 14 18:43:56 2015