13:09:20 <bshum> #startmeeting 2014-01-10 - Developer Meeting
13:09:20 <pinesol_green> Meeting started Fri Jan 10 13:09:20 2014 US/Eastern.  The chair is bshum. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:09:20 <pinesol_green> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:09:20 <pinesol_green> The meeting name has been set to '2014_01_10___developer_meeting'
13:09:44 <bshum> #link Agenda:  http://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2014-01-10
13:09:49 <bshum> #topic Introductions
13:09:56 <bshum> #info bshum = Ben Shum, Bibliomation
13:09:58 <gmcharlt> #info gmcharlt = Galen Charlton, ESI
13:10:08 <Dyrcona> #info Dyrcona = Jason Stephenson, MVLC
13:10:13 <jeff> #info jeff = Jeff Godin, Traverse Area District Library (TADL)
13:10:21 <dbs> #info dbs = Dan Scott, Conifer
13:10:22 <DPearl> #info DPearl = Dan Pearl, C/W MARS
13:10:26 <senator> #info senator = Lebbeous Fogle-Weekley, ESI
13:10:30 <RoganH> #info RoganH = Rogan Hamby, SCLENDS
13:10:43 <ldwhalen> #info = Liam Whalen, Sitka
13:11:12 <eeevil> #info eeevil = Mike Rylander, ESI
13:11:13 <berick> #info berick Bill Erickson ESI
13:11:33 <kmlussier> #info kmlussier = Kathy Lussier, MassLNC
13:12:18 <bshum> Okay, others feel free to introduce yourselves as you arrive, we're going to continue with the meeting.
13:12:29 <bshum> #topic Past action items
13:12:46 <bshum> I'm assuming all four of those need to be deferred.
13:12:55 <bshum> Since I haven't seen movement on them yet.  (mine included :(
13:12:57 <dbwells> #info dbwells = Dan Wells, Calvin College
13:13:08 <eeevil> bshum: well, I think dbs has added some pgtap info
13:13:16 <bshum> Oh cool
13:13:23 <bshum> Do you have a link to that for the ntoes?
13:13:25 <bshum> *notes
13:13:30 <eeevil> I'll find it
13:13:49 <bshum> #action bshum to summarize bug tracking based on feedback from developers
13:13:58 <bshum> I'm putting down deferred actions as actual actions for the notes
13:14:02 <dbs> Think it's a README in src/sql/PG/t IIRC
13:14:11 <bshum> gmcharlt: OpenSRF 2.3-beta?
13:14:48 <gmcharlt> bshum: a couple mroe useful patches have come in, but now that those are ready, and more importantly, now that it's after the holidays, I'll cut next week
13:14:58 <bshum> Cool, thanks
13:15:07 <bshum> #action gmcharlt to cut OpenSRF 2.3-beta next week
13:15:14 <dbs> eeevil: Oh, that README is bound up in a branch with the Encode.pm fixes
13:15:17 <eeevil> dbs: ah, well, that's a one-liner for me ...
13:15:23 <eeevil> ah!
13:15:26 <dbs> (Because I added more tests for the Encode stuff)
13:15:33 <eeevil> dbs++
13:15:35 <bshum> Ah, dbs++
13:15:47 <dbs> If we could merge that, we'd fix Fedora and get docs too.. *ahem* :)
13:15:55 <bshum> Can I mark an action item for someone (maybe eeevil to check that in?)
13:16:15 <bshum> #action eeevil to publish detailed plan about freezing baseline schemas between EG releases and using deprecates/supersedes in database upgrade scripts. This will go on the mailing list and the thread should structure further discussion of pros and cons of eeevil's plan.
13:16:34 <dbs> #info branch with pgTAP tests and Encode fixes is in https://bugs.launchpad.net/evergreen/+bug/1242999
13:16:34 <pinesol_green> Launchpad bug 1242999 in Evergreen "Encode.pm 2.54 breaks database functions (naco_normalize, maintain_control_numbers, others)" (affected: 1, heat: 10) [High,Confirmed]
13:16:36 <dbwells> I intend to re-review and push the Encode.pm stuff later today, or Monday at the latest.
13:16:42 <dbs> dbwells++
13:16:53 <bshum> Cool deal.
13:17:10 <bshum> #action dbwells to review bug 1242999
13:17:22 <bshum> That's it for past items for the moment.
13:17:28 <dbwells> yay, an action item :)
13:17:38 <berick> heh
13:18:11 <bshum> #topic OpenSRF releases
13:18:31 <bshum> I think we already covered the next 2.3 stuff, but is there anything else in the stable side?
13:18:32 <eeevil> see: above ;)
13:18:41 <bshum> #info See above for OpenSRF 2.3 beta.
13:19:07 <eeevil> gmcharlt: do you plan to merge the few outstanding opensrf pullrequests before 2.3-b?
13:19:13 <gmcharlt> eeevil: yep
13:19:16 <eeevil> rock
13:19:23 <dbs> awzzzzome
13:19:25 <gmcharlt> eeevil: no, roll!
13:20:11 <bshum> Okay.
13:20:22 <bshum> #topic Evergreen releases
13:20:57 <eeevil> 2.4.5 has been sitting in preview ... I guess we should make it live :)
13:21:05 <bshum> For this, I think I'm going to take an action item to go untangle the 2.4.5 milestones since eeevil did manage to get 2.4.5 done before the holidays.
13:21:07 <eeevil> I'll be cutting 2.4.6 next weds IIRC
13:21:18 <eeevil> bshum++
13:21:29 <bshum> #action bshum to fix up the 2.4.5 and set 2.4.6 milestones in LP
13:22:15 <bshum> #info eeevil plans to cut 2.4.6 next Wednesday (2014-01-15) for next monthly maintenance release.
13:22:33 <dbwells> #info cutoff for targetting bugs for inclusion in 2.6.0-alpha is next Thursday (1/16)
13:22:38 <bshum> I assume we'll get a 2.5.2 release at the same time.
13:22:45 <Dyrcona> Did someone else take over 2.5 from dbwells?
13:22:50 <bshum> Or, yeah
13:23:02 <Dyrcona> It doesn't seem fair that he would do 2.6 and 2.5.
13:24:05 <dbwells> 2.5.2 will come next week as well.  So, far, I will be doing it, and we'll see how it goes.
13:24:44 <berick> dbwells: i pushed some fixes for make_release that will make the job %0.2 easier ;)
13:25:02 <dbwells> berick: yes, thanks!
13:25:30 <eeevil> berick: I'd call them a 7% improvement, personally
13:25:32 <Dyrcona> dbwells: If you want help or someone else to take over, I could do it.
13:25:45 <eeevil> (I need to kill --right-only, or fix my git)
13:26:00 <berick> eeevil: heh, didn't want to brag, or anything
13:27:18 <dbwells> berick: eeevil: there are still a couple more bugs in make_release which I have been pulling in, I'll try to get those branched and in a bug.  I don't think they make anything easier, though, just a little more accurate
13:27:40 <eeevil> dbwells: thanks muchly!
13:27:47 <dbwells> small stuff :)
13:28:54 <dbs> On 2.6 - I know a few people have taken a look at at bug # 1261939 (thanks bshum / kmlussier!), but I'm wondering if, as a relatively largeish feature, it has a chance of actually getting in 2.6
13:29:18 * eeevil looks
13:29:23 <bshum> So we're moving into newish business, so I'm changing topics
13:29:37 <bshum> #info Dyrcona offers to dbwells help on 2.5 maintaining (follow up on this)
13:29:44 <bshum> #topic Evergreen 2.6 discussions
13:29:45 <dbs> bshum: sorry, I thought this was in the "Evergreen release" territory
13:30:04 <bshum> That's okay, I'm just trying to organize thoughts for the bot.  (I'm underprepared today)
13:30:08 <eeevil> dbs: IMO, it should.
13:30:23 <kmlussier> dbs: I would like to see it in 2.6 if possible.
13:30:41 <bshum> bug 1261939
13:30:41 <pinesol_green> Launchpad bug 1261939 in Evergreen "Add per-library TPAC pages with schema.org structured data support" (affected: 1, heat: 6) [Wishlist,New] https://launchpad.net/bugs/1261939
13:30:42 <bshum> (cause I'm lazy
13:30:49 <bshum> Ah okay
13:30:54 <bshum> +1 for 2.6
13:31:09 <Dyrcona> +1 for 2.6
13:31:46 <eeevil> dbs: the first chunk of that branch is in master now, yes?
13:31:50 <dbs> (bshum was tempting me into auto-including google maps beside the addresses, and I have code for most of that, but I'm leery about weighing down this branch) :)
13:32:23 <kmlussier> dbs / bshum: That would be awesome! But maybe in a separate branch?
13:32:58 <dbs> eeevil: first chunk = move sample aou data out of 950 into concerto + add more realistic aou sample data was a separate bug
13:33:08 <eeevil> aye
13:33:22 <eeevil> "earliest"
13:34:10 <dbwells> dbs: there are still other big features incoming which may get in.  The fact that your code is already ready means I think it should get into 2.6 AND you get a gold star.
13:34:12 <dbs> kmlussier: yep, that's what I was thinking too. a nice-to-have but not necessary
13:34:35 <bshum> "gold star"++
13:34:44 * dbs blushes
13:35:24 <dbs> #action dbs will write up the release notes as promises in bug # 1261939 for per-library TPAC pages
13:36:41 * dbwells starts planning the "Evergreenies" awards ceremony for the 2.6 release party
13:36:52 <bshum> dbwells++
13:37:11 <bshum> dbwells: Was there anything else you would like to say about 2.6 development plans at this time?
13:37:12 <berick> who's that coming down the green carpet?
13:37:25 <bshum> An idea I just had is to put your ideal milestone dates into the Evergreen development calendar.
13:37:34 <bshum> So that we have one more reminder of key events
13:37:49 <dbwells> yes, I am just starting to get back into the LP side of things.
13:37:55 <dbs> bshum++
13:38:11 <dbwells> I changed the 2.next tag to 2.6.0-alpha earlier today.
13:38:17 <bshum> I'll take an action item to help do that.  Or give dbwells access to the google calendar to set it himself.
13:38:39 <bshum> (probably both actually)
13:38:41 <egbuilder> build #470 of evergreen-master-debian-6.00-x86_64 is complete: Success [build successful]  Build details are at http://testing.evergreen-ils.org/buildbot/builders/evergreen-master-debian-6.00-x86_64/builds/470
13:38:54 <dbwells> bshum++
13:40:24 <bshum> #action bshum to set new calendar entries for 2.6 milestone events and give access to dbwells to dev calendar.
13:40:32 <bshum> Okay, anything else before we move on?
13:41:00 <dbwells> nothing from me
13:41:40 <bshum> Okay.
13:41:50 <bshum> Go forth and target things
13:41:59 <bshum> Next up, more new business
13:42:08 <bshum> #topic Technical feedback on staff client prototype
13:42:20 <bshum> berick: floor is yours
13:42:27 <bshum> (to give to others)
13:42:45 <berick> yep, I'm wondering if there are any comments on the techincal bits, since feedback has been sparse so far.
13:43:49 <ldwhalen> I am concerned about the speed of Angularjs on older machines.  I am not sure if this is a valid concern because I have not done any testing.
13:44:05 <berick> ldwhalen: where does the concern come from?
13:44:17 <bshum> #link Prototype wrap-up report: http://yeti.esilibrary.com/dev/pub/web-staff-report.html
13:44:46 <ldwhalen> Angularjs is obviously doing a lot of work manipulating the DOM and passing information back and forth via the $scope object
13:45:11 <RoganH> I have done very limited testing.  I've done demos to get feedback from front line staff on our "spare" machine the front desk.
13:45:29 <RoganH> It's about a five year old low end intel with 2 gigs of RAM.  The demo at least ran very well on it.
13:45:46 <berick> so, my usual spiel on angular is that if we weren't using it, we would be doing all the same stuff manually w/ our own code (assuming a dhtml ui).
13:46:09 <ldwhalen> my concern is with a bad model and view implementation it might be slow.  I am not concerned with the current prototype.
13:46:36 <berick> so, i understandn the concern in general about js UIs on older machines, but i'd be surprised if angular was slower than any other js toolkit
13:46:37 <gmcharlt> ldwhalen: that's a rather ... generalized concern
13:46:42 <gmcharlt> anything can be too slow if coded badly
13:46:49 <ldwhalen> I want to idenitfy if there is a limit to chainging models and views in one screen and how we might avoid
13:46:59 <dbs> ldwhalen: Angular is extremely lean, as far as JavaScript frameworks go
13:47:32 <ldwhalen> alright.  I will go and test and come back if I have any concerns.
13:48:06 <dbs> berick: is bootstrap 2 or 3 in use? (Yes, I have not dived into the prototype code yet)
13:48:07 <jeff> ldwhalen++
13:48:24 <berick> ldwhalen: cool, testing very much appreicated
13:48:56 <jeff> dbs: it appears to be 3.0.1
13:49:10 * dbs looked and confirmed that too
13:49:20 <Dyrcona> My only question is: Are AngularJS and Bootstrap the final word on the staff client?
13:49:23 <dbs> Good!
13:49:36 <Dyrcona> That is, are these these the toolkits that will be used for the final version?
13:49:37 <berick> Dyrcona: that's pretty much what I'm trying to answer here
13:49:48 <berick> looking for some consensus
13:50:31 <Dyrcona> I want to know before I invest a lot of time in learning them. I'm always up for learning something new, but my time is more limited than ever.
13:50:56 <dbs> They seem like pretty solid choices from an adoption front at this point in time. Also reassured that Bill's prototype report didn't point out any horrifying deadends.
13:51:01 <dbwells> I think they are both good choices based on widespread use.
13:51:17 <RoganH> we have several strong arguments for, are there any dissenting opinions?
13:51:25 <ldwhalen> Are we willing to consider native app development?
13:51:37 <Dyrcona> I believe they are good choices from what I have read about them. I have no suggestions for anything different.
13:51:42 <berick> ldwhalen: we've already passed that bridge at the hackaway
13:51:49 <ldwhalen> ok
13:52:02 <dbs> Boostrap 3 is notable because of partial support for IE 8 / 9 per http://getbootstrap.com/getting-started/#browsers
13:52:12 <RoganH> If there are no alternatives proposed I think we should consider that consensus.
13:52:23 <RoganH> Unless we want to form action committees to strategize or something else equally painful.
13:52:31 <berick> dbs: note, however, the js in the prototype is not IE compatible
13:52:42 <dbwells> dbs: are you saying notable that they support it at all, or notable for being partial?
13:52:44 <dbs> berick: ah, that is good to note!
13:53:06 <dbs> notable for being partial, i.e. set expectations for IE accordingly (see what I did there?)
13:53:17 * Dyrcona sees lack of IE support as a good thing.
13:53:27 * berick too
13:53:43 * RoganH works at a library that officially offers no support for IE for our patrons.
13:53:49 <ldwhalen> RoganH: I would add that as long as doing sensible MVC stuff with Angularjs is not too slow on older machiens
13:54:00 <jboyer-isl> The only real benefit I see to that is that a non-default browser means you can have printer defaults more amenable to receipts.
13:54:16 <RoganH> ldwhalen: I think we always have to leave the door open to re considering if we hit a land mine.
13:54:29 <dbs> berick: your report made no mention of printing support; any thoughts on that?
13:54:30 <jboyer-isl> (The non-IE support, that is_
13:54:38 <dbwells> berick: I think last I checked, you were using a third party integration of Angular and Bootstrap.  Is that still true?
13:54:39 <ldwhalen> I hope to rid myself of that concern with the testing
13:54:58 <jeff> I understand that bootstrap 3.x is not backward compatible with bootstrap 2.x, and that the effort involved in porting from 2.x to 3.x can vary by site/app, but can be significant. Does bootstrap 3.x have a stated/expected lifespan / support lifecycle?
13:55:01 <berick> dbs: it's covered more fully in the specs and original proposal:  printing and offline storage will be a separate project
13:55:30 <berick> dbwells: 3rd-party hosted, yes, that will have to change eventually, but it's easier for testing
13:56:01 <berick> jeff: good question.
13:56:04 <dbwells> berick: no, I mean the AngularUI stuff.  I think that is a third party, right?
13:56:20 <berick> dbwells: oh, yes, that is.
13:56:34 <rfrasur> Is this a meeting or general discussion?
13:56:48 <berick> i pulled that in to get bootstrap-via-angular support (no bootstrap.js or jquery required)
13:56:53 <dbs> jeff: well, worst case scenario we just roll with Bootstrap 3 until we can address the technical debt, no?
13:56:53 <bshum> rfrasur: dev meeting
13:56:54 <jeff> rfrasur: discussion during the course of a meeting. :-)
13:56:55 <rfrasur> k
13:56:58 <bshum> And both
13:57:02 * rfrasur shushes
13:57:41 <dbwells> berick: Do you have any sense of how dependent we will be on that project?  It seems like the weakest link, but I can't really judge how weak at this point.
13:57:57 <gmcharlt> dbs: and hope that the Bootstrap team got enough flack that they think more carefully about backwards compatiblity issues when they bump up to 4
13:58:18 <dbs> gmcharlt++
13:58:28 <Dyrcona> You guys are talking like it is commercial software or something.... ;)
13:58:33 <berick> dbwells: agreed it is the weekest link.  right now, we're only using the bootstrap bits.  what we use for other UI components is yet to be determined.
13:58:43 <berick> i'd like to use it, since we have it, but it is young
13:58:54 <berick> so, i'm open to discussion on that
13:59:15 <berick> dbs: gmcharlt:  my thoughts exactly
13:59:43 <berick> i'm assuming keeping up with bootstrap versions will be easier than rolling our own
13:59:58 <bshum> Cool, so any other thoughts for berick before we move on?  (feel free to continue discussions post-meeting, via lists, etc.)
14:00:05 <jeff> berick++
14:00:13 <bshum> Also, berick++ and thanks to everyone who contributed to the prototype's creation
14:00:16 <RoganH> berick++
14:00:17 <berick> (though we clearly need to make version tracking a high priority)
14:00:27 <gmcharlt> berick: certainly in the long run; we've tasted the bitterness of staying stuck on older library versions
14:00:32 <berick> yes, thanks to all the contributers!
14:00:36 <dbwells> berick++
14:00:41 <gmcharlt> berick++
14:00:55 <bshum> Okay
14:00:56 <ldwhalen> I know I am being very criticl, but I am also concerned with the use of TT2 wihtin an Angularjs app.
14:01:07 <ldwhalen> and berick++
14:01:34 <jboyer-isl> ldwhalen: as far as tt2 is concerned, that's all server side, no?
14:01:44 <dbs> ldwhalen: what is the specific concern?
14:02:27 <ldwhalen> yes, but there are plans for server side compilation of Angularjs apps and I am worried that having TT2 in the app may prevent us from capitalizing on benefits that might be offered there
14:02:55 <ldwhalen> As well, I think it complicates the conceptual nature of the MVC within Angularjs
14:03:28 <bshum> ldwhalen: For consideration, I think it'd be great if you could write up your concerns as a reply on the list to berick's thread asking for technical feedback.
14:03:30 <jboyer-isl> I see.
14:03:45 <ldwhalen> bshum: I will do that
14:03:52 <eeevil> ldwhalen: we need a templating system to support local customization ... we know tt2, and it's both fast and already integrated ...
14:03:54 <bshum> ldwhalen: Thanks.
14:04:03 <bshum> So last topic on the agenda:
14:04:08 <berick> the browser gets a page that angular drives, how it gets that page has no impact on angular / mvc
14:04:11 <bshum> #topic OS support
14:04:19 <berick> bshum: one sec!
14:04:26 <berick> i have a final question in my talking points
14:04:27 <bshum> berick: Okay :)
14:04:35 <berick> maybe this is better on the list, though..
14:04:47 <berick> websockets -- toss it on the list?
14:04:58 <berick> my question is, are there any objections to moving in that direction?
14:05:06 <RoganH> websockets++
14:05:10 <eeevil> I object to not moving in that direction
14:05:15 <berick> :)
14:05:36 <berick> i have solved the last problem, one that tsbere raised and added support for shared websocket connections across browser tabs (this morning)
14:05:37 <dbwells> I object to even asking for objections
14:05:42 <berick> that was my last big concern
14:05:45 <jeff> berick: what is your thought/plan on server-side support for websockets? anything new from early websocket blog posts?
14:06:35 <bshum> berick: I remember websocket talk from two hackaways ago, but could use a refresher too.  Could you publish some more details in a dev posting for me (and others)?
14:06:35 <berick> jeff: nothing has changed since my post, but i'm open to discussion.  separate apache instance still seems like the best path.  it will complicate the install and admin, though, which is unfortunate
14:06:39 <eeevil> berick: sweet, that means 1 socket per client... that's doable (with a non-apache server for web sockets)
14:06:57 <berick> eeevil: exactly (minus apache comments ;)
14:07:07 <jeff> berick: slightly unfortunate, but you install far fewer times than you pass a message between client and server. ;-)
14:07:17 <eeevil> or, rather, non-bloated-with-modperl-etc server
14:07:28 <berick> yeah, the benefits are nice
14:07:30 <berick> eeevil: right
14:08:09 <berick> #action bill to open opensrf LP websocket ticket with current info
14:08:23 <kmlussier> berick++
14:08:24 <bshum> berick++
14:08:27 <eeevil> berick++
14:08:33 <berick> sorry bshum, proceed :)
14:08:35 <jboyer-isl> berick++
14:08:47 <bshum> berick: Heh, all good.
14:09:04 <bshum> So, the OS support question I tacked on because I was just thinking about starting to look at the upcoming 14.04 Ubuntu stuff
14:09:31 <bshum> The question I wanted to check is how we plan to support that?  Additionally, I wanted to see if we could codify where we stood with the Debian side as well.
14:10:09 <gmcharlt> for Debian, my preferred suport policy is that we support stable and oldstable
14:10:17 <berick> gmcharlt: +1
14:10:27 <gmcharlt> keeping in mind that oldstable general is expected to go away a year after the release of the current stable
14:10:33 <jeff> +1 stable and oldstable
14:11:02 <dbs> +1 stable and oldstable
14:11:03 <Dyrcona> But, I think the question at hand is how do you support new stable on day one if you haven't started working with testing?
14:11:23 <berick> fwiw, i had wheezy patches on LP 6 months before it was released
14:11:32 <berick> give or take, i don't remember ;)
14:11:37 * csharp appears
14:12:02 <gmcharlt> Dyrcona: fair question; but yes, supporting stable does imply that folks exercise OpenSRF and Evergreen in testing beforehand
14:12:07 <jeff> it's probably time to start testing with testing/jessie. i'm happy to help.
14:12:28 <csharp> I think it would be reasonable to take a similar approach to ubuntu LTS and treat the old LTS like Debian oldstable and support it for a year after a new LTS release
14:12:34 <gmcharlt> jeff: just avoid running sudo apt-get install kaboom
14:12:56 * Dyrcona always installs kaboom.... It's so much fun. :)
14:13:20 <jeff> the idea being that we don't support testing until it's stable, but that devs have started incorporating support for testing into opensrf and evergreen before said debian release is released.
14:13:38 <jeff> i.e., we don't recommend running your evergreen system on a not-yet-released version of debian.
14:13:46 <gmcharlt> jeff: exactly
14:14:11 <berick> if the trend follows, we still have well over a year before jessie is out
14:14:59 <dbs> And we're not expected to shoehorn new-stable support into an old OpenSRF or Evergreen release, right?
14:15:28 <berick> for debian, should we try to have installer targets, say, 6 months before the assumed release?
14:15:36 <csharp> dbs: that's an even better question
14:15:36 <berick> dbs: i would assume not
14:15:46 <csharp> I would assume not too
14:16:04 <bshum> Hmm
14:16:05 <gmcharlt> I'd think it would be an option, though, but not a requirement
14:16:11 <gmcharlt> particular around the time of a new stable release
14:16:17 <jeff> it's likely that during the support lifetime of a given evergreen release, the two debian releases that that evergreen release supports will be shifted, and what was "oldstable" will no longer be supported by debian. I don't think we have a situation where both would shift.
14:16:28 <dbs> Statement would be something like: "If you want to install on the latest Debian stable or Ubuntu LTS, please install the most recent evergreen release"
14:16:36 <bshum> In that case, I think it'll be good to list out in the README of a given release which systems we support.
14:16:38 <dbs> and yes, support could be optionally backported, just not mandated
14:16:47 <bshum> Which was something else I was thinking to do anyways, for other reasons
14:16:50 <gmcharlt> +1 to anything that encourages folks to stay up to date with EG and OpenSRF releases
14:16:57 <dbs> gmcharlt++
14:17:15 <jeff> bshum: so that the "supported linux distros/versions" is codified in the branch, not just on a downloads page? is it that way now?
14:17:23 <gmcharlt> and heck, I'm sure we wouldn't be the only ones to "blame" Debian for deprecating older releases ;)
14:17:27 <jeff> bshum: i mean, the makefile targets are in the readme, correct?
14:17:50 <bshum> jeff: Right, I think we should update all of those places.
14:17:52 * dbs did enjoy a "upgrade OpenSRF + Evergreen + Debian inplace in one shot" upgrade once upon a time
14:18:27 <csharp> yeah we did that last year with a move to Ubuntu from Debian
14:18:29 <bshum> The other thing with Ubuntu is timing though.  14.04 is out a month after the intended March cycle, so if we don't support a thing till it's released, that means no official release Evergreen till the September one.
14:18:36 <bshum> ?
14:18:43 <bshum> Unless we optionally backport
14:19:00 <dbs> Right. Seems likely that that would be a chosen option
14:19:12 <gmcharlt> backporting formal LTS support into 2.6.1 or 2.6.2 seems reasonable
14:19:24 <csharp> +1
14:19:27 <bshum> Okay.
14:19:46 <Dyrcona> When 12.04 came out, I tried to have it ready for the upcoming release in April.
14:19:49 <gmcharlt> bshum: I assume Ubuntu has some mechansim for providing the equivalent of a testing socket for an upcoming LTS?
14:20:00 <Dyrcona> That makes no sense.
14:20:21 <Dyrcona> What I said, not what gmcharlt said. :0
14:20:51 <gmcharlt> :)
14:20:53 <bshum> gmcharlt: I'm not sure, but I can try to find out.  Last time I just helped Dyrcona with testing things out over time.
14:21:01 <csharp> gmcharlt: yeah, you can usually be more or less stable on an LTS beta
14:21:18 <csharp> similar (much shorter) testing period than Debian testing
14:21:23 <gmcharlt> csharp: that sounds good enough
14:21:27 <Dyrcona> I started testing Evergreen with 12.04 right after the first alpha of 12.04.
14:21:31 <csharp> s/than/to/
14:22:03 <Dyrcona> I haven't started on 14.04, yet, and I agree with csharp that waiting for the beta may be reasonable.
14:22:11 * Dyrcona checks the release schedule.
14:22:30 <bshum> Ubuntu 14.04 beta1 is Feb 27th
14:22:33 <bshum> (slated for)
14:23:07 <Dyrcona> Right.
14:23:15 <bshum> Alright, so, to summarize
14:23:16 <Dyrcona> Maybe Alpha2, then.
14:23:41 <bshum> OS support is generally agreed as stable and oldstable (for Debian).  And current LTS and one past for Ubuntu.
14:24:23 <bshum> I'll try and carve out some time to put that somewhere on the websites.
14:24:34 <csharp> although interest drops out pretty fast for "one past"
14:24:40 <bshum> Right
14:25:15 <bshum> Okay, well, maybe we should try summarizing this into an email post to finalize and then post somewhere.
14:25:22 <csharp> I mentioned above that we might consider supporting "old" LTS for a year after "new" LTS release - may have gotten lost in the Debian discussion
14:25:44 <csharp> "after a year, you're on your own"
14:26:26 <bshum> Good point csharp.
14:26:39 <bshum> Alrighty, well, anything else to discuss today before we close this meeting?
14:27:17 <bshum> Okay.
14:27:22 <bshum> Thanks everyone, and enjoy the weekend.
14:27:30 <csharp> bshum++
14:27:31 <gmcharlt> bshum++
14:27:32 <bshum> #endmeeting