Meeting on August 10, 2009

Agenda

1. Attendance
2. Announce agenda
3. Approve July 13, 2009 Meeting Notes. Ask for review and address any problems seen in the notes.
4. Discuss simplified API.
   1. Vote on location of simplified API code.
5. Talk about the dependencies downloader on Linux and existing platforms.
6. Discuss methods of keeping branches open during a rollup.
7. Open Questions
8. Summary and closing

Notes

Attendance

• tclarke
• dsulgrov
• raevans
• gmartin_cn
• rgoffena
• kstreith

Summary

The simplified API location and naming were discussed. Most people would like it either in Opticks Extras or in the core. A proposal will be made and posted to the mailing list at a later date.

The dependencies downloader for Linux was discussed and input on design was solicited.

Proposals were made for changes to the rollup which will allow branches to be opened earlier. There were a couple of proposals but no clear consensus. This issue will be revisited at a later date, perhaps when a new code review tool is put in place.

Decisions

None. The proposed vote was postponed.

Logs

2009-08-10T11:08:21 <tclarke> attendence
2009-08-10T11:08:21 <tclarke> here
2009-08-10T11:08:24 <dsulgrov> here
2009-08-10T11:08:25 <raevans> here
2009-08-10T11:08:26 *** kstreith has joined #opticks
2009-08-10T11:08:26 *** ChanServ sets mode: +o kstreith
2009-08-10T11:08:26 <gmartin_cn> here
2009-08-10T11:08:33 <tclarke> 1. Attendance
2009-08-10T11:08:34 <tclarke> 2. Announce agenda
2009-08-10T11:08:34 <tclarke> 3. Approve July 13, 2009 Meeting Notes. Ask for review and address any problems seen in the notes.
2009-08-10T11:08:34 <tclarke> 4. Discuss simplified API.
2009-08-10T11:08:34 <tclarke> 1. Vote on location of simplified API code.
2009-08-10T11:08:34 <tclarke> 5. Talk about the dependencies downloader on Linux and existing platforms.
2009-08-10T11:08:35 <tclarke> 6. Discuss methods of keeping branches open during a rollup.
2009-08-10T11:08:36 <tclarke> 7. Open Questions
2009-08-10T11:08:36 <tclarke> 8. Summary and closing
2009-08-10T11:08:38 <kstreith> here
2009-08-10T11:08:39 <tclarke> last meeting notes are here https://wiki.ballforge.net/confluence/display/opticksChat/July+13%2C+2009+Meeting+Notes
2009-08-10T11:08:42 <tclarke> if there are problems, bring them up by the end of the meeting
2009-08-10T11:10:12 <tclarke> there's a project starting which will create a smaller Opticks API encompassing less of the app than the normal api
2009-08-10T11:10:17 <tclarke> it's geared to scripting language support for writing algorithms
2009-08-10T11:10:22 <tclarke> and is more data centric than the standard api
2009-08-10T11:10:38 <tclarke> the api methods and utilities will go into a library...the question is, where should this library live and what should it be called
2009-08-10T11:10:41 <tclarke> a couple of possibilities
2009-08-10T11:10:47 <tclarke> 1. In the extra's repo as a common static library
2009-08-10T11:10:51 <tclarke> 2. In the core next to PlugInUtilities, etc. as a static library
2009-08-10T11:10:56 <tclarke> 3. In an entirely different location
2009-08-10T11:12:12 <tclarke> 4. A copy in each scripting plug-in
2009-08-10T11:12:20 <tclarke> the name is also open....there are some possibilies
2009-08-10T11:12:30 <tclarke> SimpleApiLib, DataApiLib, etc.
2009-08-10T11:12:31 <tclarke> .
2009-08-10T11:12:56 <tclarke> thoughts?
2009-08-10T11:14:34 <kstreith> i'm ok with 2. for the location, provided we ensure the static library only compiles against public interfaces
2009-08-10T11:14:48 <gmartin_cn> What about calling it 'ScriptingApiLib'?
2009-08-10T11:14:48 <kstreith> i hate naming things, but SimpleApiLib seems an ok name
2009-08-10T11:15:14 <dsulgrov> if it is geared toward scripting, it seems like it would be appropriate to add it to Extras
2009-08-10T11:16:42 <tclarke> a couple of issue I have with extras
2009-08-10T11:16:51 <tclarke> extras is not just for scripting plug-ins and there is a scripting plug-in of sorts in the core (XML-RPC)
2009-08-10T11:17:06 <tclarke> I also like tieing it more strongly to the core for versioning and in binary compat reasons
2009-08-10T11:17:14 <tclarke> but I'm open to put it in extras if there are compelling reasons
2009-08-10T11:17:15 <tclarke> .
2009-08-10T11:19:34 <tclarke> other thoughts?
2009-08-10T11:21:09 <tclarke> do we want to take a straw pole on a name and location? or should I put this off and make a proposal to dev@opticks
2009-08-10T11:21:15 <kstreith> i'm open to either
2009-08-10T11:21:33 <tclarke> how about we skip the pole as I'd like to ask dadkins who is not here today...I'll post something to the mailing list and if anyone has issue, they are start a discussion
2009-08-10T11:23:09 <tclarke> ok, next topic....dependencies downloader
2009-08-10T11:23:21 <tclarke> I'm redesigning the dependency downloader
2009-08-10T11:23:30 <tclarke> as a first step, I'm planning on deploying a new solution on Linux as a test
2009-08-10T11:23:38 <tclarke> the solution I'm leaning towards has a few issues running on windows but I think I can overcome them
2009-08-10T11:23:41 <tclarke> a couple of questions
2009-08-10T11:23:50 <tclarke> we currently ship most dependencies except things like OpenGL libs
2009-08-10T11:23:55 <tclarke> should be continue to do so in a sandboxed environment
2009-08-10T11:25:20 <tclarke> or only ship dependencies we need to modify and rely on system libraries for the other dependencies (this might mean integrating into a system package manager)
2009-08-10T11:25:40 <tclarke> also, should we continue with separate subdirs for each dependency (originally, this was a way of separating and tracking individual dependencies) or should we have a sub-tree which mimics a standard system layout
2009-08-10T11:25:46 <tclarke> i.e. one include dir, one lib dir, etc. for all dependencies
2009-08-10T11:25:57 <tclarke> this approach would use the downloader/package manager to track which files belong to which dependencies
2009-08-10T11:25:58 <tclarke> .
2009-08-10T11:28:20 <dsulgrov> what do you mean by system libraries? does that include pre-built binaries offered on a third-party website?
2009-08-10T11:28:25 <kstreith> i think i prefer separate sub-dirs for each dependency
2009-08-10T11:29:52 <tclarke> libraries which are either present on a system already, or can be obtained use the system package management
2009-08-10T11:30:03 <kstreith> i prefer using the same versions of libraries on all systems
2009-08-10T11:30:03 <tclarke> it's more of a problem on windows since it doesn't have a good package system but there are some available
2009-08-10T11:30:08 <tclarke> it would use the same version
2009-08-10T11:30:10 <tclarke> but we wouldn't distribute it
2009-08-10T11:30:14 <kstreith> which i think tilts toward providing all dependencies, instead of deferring to the system ones
2009-08-10T11:30:21 <tclarke> we'd list the version and the developer would use the system package manager to grab the proper version
2009-08-10T11:30:37 <tclarke> the benefits to the system ones....less likely to have problems like we've run into with multiple version of libjpeg, less download time from out website
2009-08-10T11:32:21 <tclarke> I'll explain a reason I like the usr/include, usr/lib, usr/bin layout as a sub-tree for some cases
2009-08-10T11:32:38 <tclarke> if I base the new system on an existing package manager (opkg, dpkg, ipkg, etc.) and we use a standard layout, we can use third party builds of libraries but still integrate into our system
2009-08-10T11:34:23 <tclarke> I.E. explicitly mark a version we want of (say) libjpeg, but pull it from the pool of net servers which already have builds
2009-08-10T11:38:42 <tclarke> ok, next discussion
2009-08-10T11:38:47 <tclarke> kstreith wants to discuss keeping branches open during a rollup
2009-08-10T11:38:48 <tclarke> .
2009-08-10T11:39:01 <kstreith> i have heard some complaints from committers
2009-08-10T11:39:05 <kstreith> that branches stays closed for too long during rollups
2009-08-10T11:40:51 <tclarke> and there's also the need to re-branch if a branch continues into a new release
2009-08-10T11:40:52 <kstreith> thoughts? agreements?
2009-08-10T11:41:00 <tclarke> which is not traditionally a problem but becomes more of an inconvenience with merge tracking
2009-08-10T11:41:12 <tclarke> it would be nice if we didn't remove branches but tag the individual branches going into a rollup and deleted only those
2009-08-10T11:41:12 <tclarke> .
2009-08-10T11:41:28 <dsulgrov> it seems that since branches are based off of a 4.3.X trunk, that the branches would not need to be deleted when releasing 4.3.1rc1
2009-08-10T11:43:01 <dsulgrov> since we know the branches that comprise 4.3.1rc1, then we could simply tag only those branches in the release and leave the others untouched
2009-08-10T11:43:15 <kstreith> so, currently once a rollup starts, we prevent any changes to the branches/[VERSION] folder and then we move the entire contents into the /releases directory to tag it and then at the end of the rollup create a new /branches/[VERSION] folder to continue development on the next version
2009-08-10T11:43:25 <kstreith> this currently confuses issues, meaning that branches/4.3.X is used for the following:
2009-08-10T11:43:32 <kstreith> 4.3.1rc1 development, 4.3.2rc1 development, 4.3.3rc1 development, etc.
2009-08-10T11:43:39 <kstreith> the 4.3.1rc2, 4.3.1 development would live in branches/4.3.1
2009-08-10T11:43:46 <kstreith> and the 4.3.2rc2 and 4.3.2 development would live in branches/4.3.2
2009-08-10T11:43:47 <kstreith> that's the state today
2009-08-10T11:43:54 <kstreith> i think ok, with the following mod:
2009-08-10T11:45:28 <kstreith> branches/4.3.1rc1 for 4.3.1rc1 development, branches/4.3.1 for 4.3.1rc2 and 4.3.1 final development
2009-08-10T11:45:37 <kstreith> branches/4.3.2rc1 for 4.3.2rc1 development, branches/4.3.2 for 4.3.2rc1 and 4.3.2 final development
2009-08-10T11:45:47 <kstreith> this would allow development for rc1's to occur simulatenous and developers to target appropriately
2009-08-10T11:45:53 <tclarke> I think that's more than we need to do.....I see no reason we can't use the same branch structure as we are using now
2009-08-10T11:46:03 <kstreith> the problem we have today would persist only with rc2's and final releases, which is ok, because we do much more constrained development in those circumstances
2009-08-10T11:46:06 <tclarke> 4.3.X for the next release dev...then when the rollup happens, we continue working on active branches and creating new branches
2009-08-10T11:47:38 <tclarke> when we tag, we tag only the branches/4.3.X/ dirs which are complete (There's a list we generate from the trunk)
2009-08-10T11:47:52 <tclarke> another option would be to tag a branch when it is rolled into the trunk
2009-08-10T11:48:01 <tclarke> I.E. I merge OPTICKS-123 and then move the branch to tags
2009-08-10T11:48:08 <tclarke> I prefer the first tho...batch tagging them
2009-08-10T11:48:10 <kstreith> i like to maintain a clear separation because at rollup time I like to minimize the number of moving parts
2009-08-10T11:48:17 <kstreith> so I and the tech lead can be sure what we have is what we are supposed to have
2009-08-10T11:48:18 <tclarke> a script can be written to enumerate the merged branches from the trunk commit messages, and that batch can be moved
2009-08-10T11:48:25 <tclarke> it's still an instantaneous move which can be tracked and validated
2009-08-10T11:48:33 <kstreith> I think my proposed mod accomplishes that in a very simple way, with only a single change being made to the current mindset of our committers
2009-08-10T11:49:58 <tclarke> I think it complicates matters
2009-08-10T11:50:04 <tclarke> since looking at it now, I'm still trying to figure out what exactly you are proposing
2009-08-10T11:50:06 <tclarke> so it's not quite straightforward
2009-08-10T11:50:21 <kstreith> put your stuff into the version numbered branch that ends in "rc1" that is the version you'd like to see your stuff end up in
2009-08-10T11:50:23 <tclarke> the biggest thing I'd like to see is not opening branches sooner but maintaining the existing pool to prevent the need to pull changes up to a new trunk rev
2009-08-10T11:50:29 <tclarke> that doesn't accomplish my main goal
2009-08-10T11:50:29 <kstreith> unless you're fixing something for a rc2 or final, which is extremely rare, even today
2009-08-10T11:50:39 <tclarke> I want branches/4.3.X to be created once and exist for the entire lifespace of the 4.3.X line
2009-08-10T11:52:54 <tclarke> I'm against the proposed change...I'd prefer to leave things the way they are....it make more logical sense
2009-08-10T11:54:16 <tclarke> and I can work around it by avoiding subversion until I'm ready to get code reviewed (using svk or git for a local branch)
2009-08-10T11:54:19 <tclarke> but I'd rather stick with the one tool
2009-08-10T11:54:26 <kstreith> the purpose of the bullet item today on the agenda, was to start discussion in a place that we record people's opinions
2009-08-10T11:54:28 <kstreith> wasn't looking to make a decision today
2009-08-10T11:54:39 <tclarke> anyone else have opinions or ideas?
2009-08-10T11:54:43 <dsulgrov> I agree with tclarke... instead of moving all 4.3.X branches to releases and tagging them, only move a subset of 4.3.X branches
2009-08-10T11:55:02 <tclarke> for the same reasons? or do you have any other reasons to throw in the pot?
2009-08-10T11:55:10 <dsulgrov> most of the same reasons...
2009-08-10T11:56:25 <tclarke> ok....any other thoughts?
2009-08-10T11:56:35 <dsulgrov> I think what we have now works, and with just a minor change to the release process there could be a lot less inconvenience for the committers
2009-08-10T11:56:49 <tclarke> how about we revisit when we move to our new code review system (it's not finalized yet but we'll likely have a solution in the near future)
2009-08-10T11:56:57 <tclarke> if we drop peridexion when that occurs, it will likely affect this decision
2009-08-10T11:57:05 <tclarke> ok, if there's nothing more on this issue, lets move to open topics
2009-08-10T11:58:42 <tclarke> any further issues? I'll wait a few more moments
2009-08-10T11:59:25 <tclarke> ok, that's the meeting
2009-08-10T12:00:46 <tclarke> notes and the new agenda will be sent to the mailing list later