13:02:46 <bshum> #startmeeting 2012-03-19 - Developer Meeting
13:02:46 <pinesol_green> Meeting started Mon Mar 19 13:02:46 2012 US/Eastern.  The chair is bshum. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:02:46 <pinesol_green> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:03:21 <bshum> We'll try to keep this one short (heh), since I think there's things happening at 2 for others.
13:03:49 <bshum> #topic Who's here?
13:04:02 * mrpeters-isl is Michael Peters, Evergreen Indiana
13:04:07 <bshum> #info Ben Shum, Bibliomation
13:04:15 <phasefx_> #info Jason Etheridge, Equinox
13:04:16 <mrpeters-isl> #info  Michael Peters, Evergreen Indiana
13:04:22 <Dyrcona> #info Jason Stephenson, MVLC
13:04:28 <tsbere> #info Thomas Berezansky, MVLC
13:04:37 <berick> #info Bill Erickson, Equinox
13:04:42 <denials> #info Dan Scott, Laurentian University
13:04:50 <rwalsh> #info Rob Walsh, Excalibur Solutions
13:05:20 <denials> phasefx_: bugs don't get fixed if someone doesn't fix'em  :)
13:05:26 <kmlussier> #info Kathy Lussier, MassLNC
13:06:00 <tspindler> #info Tim Spindler, CW MARS
13:06:01 <phasefx_> denials: laziness on my part, was hoping the guilty party would notice and dive in
13:06:02 <senator> #info Lebbeous Fogle-Weekley, Equinox
13:06:22 <bshum> Alrighty, thanks for attending this meeting.  kmlussier++ for helping with the doodle poll again
13:06:30 <bshum> #topic Review past action items
13:06:34 <mrpeters-isl> forgive me, but is the agenda posted somewhere?
13:06:38 <bshum> Oops, yeah
13:06:41 <mrpeters-isl> i can't find it
13:06:50 <bshum> #link Agenda:  http://evergreen-ils.org/dokuwiki/doku.php?id=dev:meetings:2012-03-19
13:06:54 <mrpeters-isl> thanks
13:07:25 <bshum> #info I went through the action items and everything looked to be done except for some questions about DIG's involvement with the release team.
13:08:27 <bshum> For that, I think we ought to set an action item aside to review the release process again and update information accordingly.
13:08:52 * denials tries to remember what rsoulliere was asking about
13:09:48 <bshum> denials: http://markmail.org/message/5rym5hmrlezpbuzz
13:09:59 <bshum> Specifically I think his question was the role of the release notes writer
13:10:24 <bshum> Which has changed slightly I think, since we now include release notes right in Evergreen?
13:10:32 <bshum> Instead of wiki pages outside
13:11:31 * mrpeters-isl thinks the release notes txt is pretty good, as it is
13:11:34 <denials> We have some right in Evergreen - docs/RELEASE_NOTES.txt IIRC - and I think we're producing HTML versions to post at evergreen-ils.org/documentation/foo
13:12:38 * dbwells is Dan Wells, Hekman Library, and sorry for being late
13:12:58 <kmlussier> The release notes for 2.2 could probably use some help for the enhancements that were released prior to the notes being included in the commits.
13:13:17 <denials> The "release-notes-writer" role is really a placeholder, to be defined, so Robert's suggestion is a good start.
13:13:29 <kmlussier> IIRC, there are several new features missing from docs/RELASE_NOTES.txt
13:13:57 <denials> kmlussier: for sure, and even though we theoretically update the release notes as we go, that doesn't necessarily happen
13:14:04 <Dyrcona> what I gather from rsoulliere's email is he's volunteering to write the release notes and add them to the documentation.
13:14:08 <denials> having someone focused on that role would be great
13:14:28 <kmlussier> agreed.
13:14:31 <denials> Dyrcona: well, no..."Does the release-notes-writer role basically take what is in the raw release
13:14:34 <denials> notes from the master file as added by developers"
13:15:02 <kmlussier> I was hoping to add some notes for some of the MassLNC-sponsored projects that haven't made it in yet. Just haven't made the time yet.
13:15:36 <denials> I'm hoping that devs continue to contribute to the release_notes.txt and that robert (or someone else, or lots of someone elses) refine and contribute to it too
13:15:44 <eeevil> kmlussier: I've been pushing some of htat in today, and for those, at least, I'll add entries to RELEASE_NOTES.txt
13:16:02 <eeevil> s/htat/that/
13:16:05 <Dyrcona> well, at any rate, i believe the status of this action item is incomplete, and should be forwarded to the agenda of the next meeting.
13:16:14 <bshum> Sounds good.
13:16:16 <kmlussier> eeevi: Yes, I was thinking of things that were released a few months back that aren't in RELEASE_NOTES.txt
13:16:18 * Dyrcona makes a motion.
13:16:31 <denials> wait. who has the action to actually do something with it between now and then?
13:16:47 <Dyrcona> "moodaepo (and others)"
13:16:54 <bshum> Only to reply.
13:16:59 <bshum> It doesn't mean doing anything real.
13:17:12 <Dyrcona> replying to his questions is something real.
13:17:20 <bshum> I think you updated the release file on the site last time denials
13:17:23 <denials> assuming moodaepo accepts that action
13:17:31 <denials> bshum: yep, I'm happy to do that
13:18:19 <Dyrcona> well, does someone want to take the action item?
13:18:20 <bshum> So perhaps the role isn't so much a "release-notes-writer" but a "DIG-member" to take docs and apply to official DIG.
13:18:38 <Dyrcona> bshum: sounds about right.
13:18:44 <bshum> And then there'd have to be something on the checklist about someone converting said docs into html for the website
13:19:27 * denials will take that
13:19:52 <denials> (the "converting docs into HTML") - unless we end up just linking to the DIG docs, which... makes sense
13:20:04 <bshum> Heh
13:20:25 <bshum> That does make sense.
13:20:42 <Dyrcona> If the docs are in ASCIIDoc, it shouldn't be too onerous.
13:21:02 <Dyrcona> I obviously can't answer rsoulliere's questions, since I apparently didn't understand them.
13:22:26 <denials> I'll take the action item to respond to rsoulliere with some idea
13:22:27 <denials> s
13:22:29 <bshum> Well, let's continue the conversation with DIG then and see how best to handle the situation.  In the meantime, continue with what we have in place already but update the checklist accordingly?
13:23:02 <bshum> #action denials to respond to rsoulliere with some ideas about DIG participation in release process.
13:23:04 <bshum> Thanks denials
13:23:23 <bshum> #action bshum to help update the release checklist page: http://evergreen-ils.org/dokuwiki/doku.php?id=dev:evergreen:release_checklist
13:23:41 <bshum> Okay, new business time.
13:23:46 <bshum> #topic Evergreen 2.2
13:24:40 <Dyrcona> I suggested 2.2 beta1 for next Monday.
13:24:51 <bshum> We tested the 2.1-2.2 upgrade SQL and made it through alright with a copy of our production DB.  Not sure if others got to try it out much?  mrpeters-isl, probably?
13:25:07 <bshum> I think jamesrf volunteered something on their end too
13:25:46 <bshum> Any thoughts or opinions on Dyrcona's suggestion --^
13:25:49 <mrpeters-isl> i've just been going 1 by 1 through the upgrade scripts...so, no
13:25:50 <jamesrf> we're going to be testing 2.0->2.1->2.2 at some point but we aren't there yet
13:26:21 * mrpeters-isl hates wasting 8 hours restoring a snapshot to test it
13:26:34 <Dyrcona> If we do beta1 on Monday, then that means this is the last week for new features.
13:26:41 <kmlussier> +1 to Monday beta
13:26:48 <denials> bshum: did you have to rip out the upgrade checks?
13:26:50 <bshum> New features :(
13:26:53 <tspindler> +1 Monday beta +1 Dyrcona
13:26:54 <eeevil> I'd vote for one extra week
13:26:55 <Dyrcona> Next week could turn the focus to testing, testing, testing.
13:27:11 <mrpeters-isl> if there are new features pending, 2 weeks would be good
13:27:19 <mrpeters-isl> rather than rushing them
13:27:20 * denials ran the 2.1-2.2 upgrade code just fine on a copy of our production database, after ripping out the upgrade checks
13:27:26 <eeevil> there are 66 outstanding pullrequest branches
13:27:29 <bshum> denials: I didn't actually, for the upgrade sql.  tsbere noted something in a reply on the mailing lists that helped with that.
13:27:30 <eeevil> and more coming soon
13:27:52 <Dyrcona> eeevil: are those all targeted at 2.2. beta1?
13:27:53 <denials> bshum: I found it jarring compared to previous upgrades
13:27:59 <bshum> denials: I'll see if I can dig it up, but I think he said to pass some variable for it.
13:28:01 <denials> more coming soon?
13:28:11 <eeevil> Dyrcona: most, I'd bet
13:28:18 <tsbere> For the upgrade script: If we want we can swap out the :eg_version for, say, the actual version number. I can make that part of the release building process, even.
13:28:24 <denials> bshum: Oh, I'm well aware of setting variables, I think it's not cool for the upgrade script though.
13:28:39 <bshum> denials: Ah, fair enough.  :)
13:28:41 <denials> e.g. fine for devs, not cool for normal sites
13:28:50 <Dyrcona> 29 bugs targeted at 2.2.0 beta1
13:28:51 * bshum is not a "normal site" anymore I guess
13:28:51 <eeevil> if I could get lauchpad to show more info for each I'd print them out and try to prioritize them
13:29:10 * denials thinks the unapi subobject thingy is high priority
13:29:52 <dbwells> Maybe we could set both a pull request deadline and an actual beta deadline.  Otherwise we might end up with a bunch of pull requests the day before the beta deadline, which would be a problem, obviously.
13:30:21 <mrpeters-isl> that sounds like a reasonable idea
13:30:49 <denials> Yeah. It's not like we'll ever stop getting pullrequests
13:30:53 <tsbere> Wednesday for non-critical pullrequests, say? (I don't want to say "this bug breaking the entire system can't be pullrequested because we passed the deadline" and all)
13:31:04 <denials> bugs are different from features
13:31:28 <bshum> So maybe a pullrequest deadline of say... this Friday for new features?
13:31:58 <bshum> And then we spend this time and next prioritizing, testing, and bringing in all new features before beta1
13:31:58 <denials> even then, just because you slap a pullrequest together, I'd say there's no reason it should go in if it hasn't been properly tested
13:32:18 <eeevil> perhaps we should make a catch-all Evergreen.NEXT target, to point branches at that we won't be getting into 2.2
13:32:27 <denials> and there's no reason to hold up the release
13:32:35 <eeevil> because you can't see things that simply aren't series or milestone targeted
13:32:41 <eeevil> which is really annoying
13:33:03 <denials> right. target for 2.2 right now, if you don't get interested eyes testing it out, it could get bumped to 2.next
13:33:04 <Dyrcona> if you want it in a release, target the branch at a milestone.
13:33:24 <Dyrcona> but, we'll discuss that next. :)
13:33:29 <denials> sounds good :)
13:33:31 <bshum> Heh
13:33:52 <bshum> Okay, so we're straying into our next topic, but before we get there, how about let's set some dates for the notes?
13:34:19 * eeevil hates the new LP bug list, btw. "sort by package/project/series" but you can't actually SEE THE SERIES
13:34:40 * denials just uses advanced search
13:34:40 <Dyrcona> well, beta 1 for Monday is on the table, and eeevil would like another week, so that would be the Monday after.
13:34:55 <bshum> That'd be April 2nd then.
13:35:09 * Dyrcona was about to check the date.
13:35:19 <dbwells> I'd support either either Friday or Monday as the last day to target new features at 2.2, then plan on cutting the beta a week after that.
13:36:00 * tsbere supports cutting Beta 1 whenever. Just point him at a date.
13:36:36 <denials> sounds fine to me
13:36:46 <bshum> I think we seem to be leaning towards April 2 for beta1 date, but we just now need to decide on new feature cutoff point.
13:37:11 <denials> Monday would give weekend developers an extra couple of days to code their little hearts out
13:37:28 <bshum> Monday sounds reasonable.
13:37:51 <Dyrcona> I can live with that, thought I think tspindler and kmlussier might have objections.
13:37:51 <bshum> So
13:38:17 <tspindler> Dyrcona: i think that would work, just knowing there is a deadline is helpful
13:38:30 <kmlussier> No objections from me.
13:38:47 <bshum> #info By March 26, have new features setup as LP pullrequests for final review/testing.  This will lead to cutting Evergreen 2.2 beta1 on April 2.
13:38:56 <dbwells> eeevil: you asked for an extra week, does this plan meet that need?
13:41:03 <bshum> Oops, will wait for eeevil before we really decide then.
13:42:20 <denials> Maybe we should just cut beta1 right now.
13:42:41 * Dyrcona already pushed the date on launchpad.
13:42:56 <eeevil> dbwells: it does moreso than cutting off pullrequests on this Weds
13:42:56 <bshum> Heh
13:43:06 * denials worries about last-minute push doing the usual damage to stability in master that we've always run into in last releases
13:44:08 <denials> Also, it kind of sucks for branches that have had pullrequests attached for months to continue to get ignored while last-minute new development gets jammed in
13:44:11 <Dyrcona> so, it sounds like the issue is settled: pull requests targeted at beta 1 through the 26th, then beta 1 on the 2nd.
13:44:23 * denials thinks tsbere still has a few of those long-lived branches hanging around
13:44:51 <Dyrcona> I hesitate to sign off on those.
13:45:06 <Dyrcona> I know tsbere won't commit on just my sign off and his, either.
13:45:13 <tsbere> denials: https://bugs.launchpad.net/evergreen/+bug/893645 is one of the more important ones, IMO.
13:45:13 <pinesol_green> Launchpad bug 893645 in Evergreen "Auditor tables don't store user and workstation" (affected: 1, heat: 6) [Wishlist,New]
13:45:31 * denials will assign himself to that one again
13:46:06 <Dyrcona> we can discuss that in the next topic, and it sounds like we might be there already.
13:46:09 <bshum> Okay then.
13:46:22 <bshum> #topic Bug tracking
13:46:23 <denials> oh yeah, pcrud changes, that's why I shyed away before :/
13:46:29 * bshum turns it over to Dyrcona
13:46:58 <Dyrcona> We've just had a discussion about targeting but I thought we should continue that.
13:47:16 <Dyrcona> Plus, I want to clear up what we should be doing with "fix released" on Launchpad.
13:47:38 <Dyrcona> I've been changing bugs to fix released status when the milestones they are targeted at are released.
13:48:09 <Dyrcona> Other developers have suggested here in IRC that we should hold off doing that until the final dot release is made.
13:48:48 <Dyrcona> I'd like to sort that out so I know what to do with bugs when milestones are released, etc.
13:49:50 <Dyrcona> so which timeline do you all prefer for marking things "fix released?"
13:50:04 <denials> Dyrcona: My concern over "Fix Released" prior to the final dot release is that a site that wants the fix will want to apply something that we think should be stable
13:50:20 <denials> and I was worried that alphas, etc, don't meet that mark
13:52:18 <Dyrcona> ok. good point.
13:52:21 <bshum> So we'd have to setup a 2.2.0 target far out in the future.  And then reassign bugs at that target every time we release an alpha?  And leave them in a state of "fix committed" till then?
13:52:27 <mrpeters-isl> so, should i go back and target my pullrequests at 2.2 beta?
13:52:53 <Dyrcona> bshum: not necessarily.
13:53:07 <denials> "Fix committed" seems appropriate. Not sure whether they would need to be retargeted.
13:53:16 <Dyrcona> we could set up a 2.2.0 target, but wouldn't have to retarget the previous bugs.
13:53:52 <bshum> Ah okay, I think I get it then
13:53:53 <denials> If you do want to retarget, there's a Python API that could automate the process methinks, rather than forcing someone to get RSI via clicking a thousand times
13:54:13 * Dyrcona has been meaning to look at the Python API.
13:54:32 * denials needs to split for another meeting - sorry folks
13:54:43 <Dyrcona> bye, denials.
13:54:45 <denials> I'm sure you're actually relieved :)
13:54:47 <mrpeters-isl> does something like this -- https://bugs.launchpad.net/evergreen/+bug/954474 need to have a release target?
13:54:47 <pinesol_green> Launchpad bug 954474 in Evergreen "Staff client: add a back-to-results button" (affected: 1, heat: 6) [Undecided,Fix committed]
13:55:10 <Dyrcona> mrpeters-isl: no, but it helps.
13:55:31 <Dyrcona> so, i'll wait until the release to "fix released" any more bugs.
13:55:32 <mrpeters-isl> well, since it's already gone to master, is it just a matter of opinion whether or not it goes to beta 1?
13:55:48 <Dyrcona> no, since it has already gone to master it will be in beta 1.
13:56:00 <mrpeters-isl> ok, so ill go ahead and target it then
13:56:04 <Dyrcona> ok.
13:56:18 <bshum> Okay, so
13:56:50 <bshum> #info Leave bugs at "fix committed" until a stable release is actually released for any given development series.
13:57:26 <Dyrcona> I think I'll go through and target any fix committed bugs without a series.
13:57:33 <bshum> Dyrcona++
13:57:47 * bshum prepares for another wave of LP emails...
13:58:02 <Dyrcona> we should have a discussion about targeting at series, too, but I think we have more agreement there.
13:58:28 <Dyrcona> it can probably wait.
13:59:59 <bshum> Okay.
14:00:19 <bshum> Well, we can probably skip the GSoC update, other than to say, yay we're in and we have lots to do there.
14:00:32 <bshum> denials++ gmcharlt++
14:00:58 <bshum> Anything else for today?
14:02:25 <bshum> Alright folks
14:02:47 <mrpeters-isl> bshum++ for leading
14:02:47 <bshum> Well thanks for attending this meeting.
14:02:57 <bshum> We'll talk about setting the next meeting in a bit, but I'm thinking that we could do a pullrequest meeting next week instead of a full dev meeting
14:03:02 <bshum> And save it for the week after beta1
14:03:06 <bshum> Ooh, action items then
14:03:20 <bshum> #action tsbere to cut 2.2 Beta1 on April 2
14:03:58 <bshum> I think that's it for now.
14:03:59 <bshum> #endmeeting