Meeting on January 12, 2009
Agenda
- Attendance
- Announce agenda
- Approve December 29, 2008 Meeting Notes. Ask for review and address any problems seen in the notes.
- Should we remove the hidden sandbox from subversion? (discussion and vote)
- Should we remove the enhancement JIRA issue type? (discussion and vote)
- Design discussion for OPTICKS-418
- Open questions
- Summary and closing
Notes
Attendance
- tclarke
- raevans
- dsulgrov
- mconsidi
- kstreith
- tjohnson
Summary
The previous meeting notes were approved. There was discussion regarding the removal of the private sandboxes from the Opticks subversion repository. The primary motivation is to ensure all code checked into the repository has ITAR release approval allowing us to enable the commits@opticks.ballforge.netemail list. Branches which are approved for release but did not go into a rollup will be moved to a location similar to the sandbox but only for approved, long-term branch development. Developers wishing to do private development can use a distributed VCS program to create a local branch on their machine. An example using svk was mentioned. Other options are git and mercurial. One developer (tjohnson) is unique in that most of his new development occurs in private branches before being approved. He has one such branch currently awaiting release approval.
There was brief discussion about removing the enhancement JIRA type. A few downsides were presented but no major benefits. There seemed to be a consensus that there is ambiguity in the current types and something should be done to help with classification. This will be discussed offline and at the next IRC meeting.
A few design possibilities were presented for OPTICKS-418. No attendees voiced opinions on the design. A summary will be sent to dev@opticks.ballforge.net for additional feedback.
Decisions
- "Should we deprecate the private sandboxes in subversion? This would be for a trial period and would finalize when the 4.2.4 rollup occurs." (6 present, 6 yea, 0 nea, 0 abstentions) motion passed
- This is a trial. If there are problems during the trial, the question will be revisited. The trial will end when the Opticks v4.2.4 rollup begins.
- This trial will begin once OPTICKS-409 has been approved for export.
- The technical implementation will be decided upon offline and a summary posted to dev@opticks.ballforge.net before the trial begins.
- "Should we remove the enhancement JIRA issue type?" (6 present, 0 yea, 6 nea, 0 abstentions) motion does not pass
Logs
| 14:08:35 | tclarke | kstreith: you stable now? |
| 14:08:39 | tclarke | we were waiting for you |
| 14:09:00 | tclarke | ok, lets get started with attendance |
| 14:09:01 | tclarke | here |
| 14:09:08 | raevans | here |
| 14:09:09 | dsulgrov | here |
| 14:09:13 | mconsidi | here |
| 14:10:28 | tclarke | ok, we'll get started..kstreith can jump in when he gets a good connection |
| 14:10:33 | tclarke | here's the agenda |
| 14:10:35 | tclarke | # Attendance |
| 14:10:35 | tclarke | # Announce agenda |
| 14:10:35 | tclarke | # |
| 14:10:35 | tclarke | Approve December 29, 2008 meeting notes. Ask for review and address any problems seen in the notes. |
| 14:10:35 | tclarke | # Should we remove the hidden sandbox from subversion? (discussion and vote) |
| 14:10:36 | tclarke | # Should we remove the enhancement JIRA issue type? (discussion and vote) |
| 14:10:38 | tclarke | # |
| 14:10:40 | tclarke | Design discussion for OPTICKS-418 |
| 14:10:42 | tclarke | # Open questions |
| 14:10:44 | tclarke | # Summary and closing |
| 14:10:49 | tclarke | lets start with last meetings notes |
| 14:10:50 | tclarke | https://opticks.balldayton.com/cometwiki/29Dec2008 |
| 14:10:53 | tclarke | any problems? |
| 14:11:55 | *** | kstreith2 (kstreith2!i=4ada5f12@gateway/web/ajax/mibbit.com/x-297f93fd6ed70a60) has joined #opticks |
| 14:12:06 | tclarke | kstreith, we are just reviewing the previous meeting notes |
| 14:12:24 | *** | mode: +o kstreith on #opticks by ChanServ |
| 14:12:34 | kstreith | here for attendance purposes |
| 14:12:40 | tclarke | here |
| 14:12:46 | tclarke | 's the agenda link for kstreith |
| 14:12:47 | tclarke | https://opticks.balldayton.com/cometwiki/12Jan2009 |
| 14:13:01 | tclarke | ok, previous meeting notes are approved |
| 14:13:17 | tclarke | lets move onto business...we've got a couple of items from last month |
| 14:13:32 | tclarke | the first deals with the removal of the private sandboxes from subversion |
| 14:14:04 | tclarke | specifically, should we get rid of them ensuring all active code in the repo has itar approval |
| 14:14:12 | tclarke | thoughts? |
| 14:14:50 | tclarke | the fallback mentioned from last month was to use svk, git, or mercurial for local branches or to maintain private changes in a local working copy |
| 14:15:28 | kstreith | i think we should remove private sandboxes |
| 14:16:07 | kstreith | and yes, require itar approval for all code in our Subversion repo |
| 14:16:25 | tclarke | I agree....we had a couple of reasons to add the private workspaces |
| 14:16:41 | tclarke | 1) to have a place to work on changes before obtaining approval |
| 14:16:56 | tclarke | 2) to provide an area for non-core developers to work on branches outside of /branches |
| 14:17:15 | tclarke | I think both of requirements can be met with one of the alternate methods proposed |
| 14:17:26 | *** | kstreith2 (kstreith2!i=4ada5f12@gateway/web/ajax/mibbit.com/x-8992cfc9b56c5f2e) has joined #opticks |
| 14:17:27 | dsulgrov | would this allow for a commits mailing list? |
| 14:17:43 | tclarke | yes...I believe that's the primary driver for this proposal |
| 14:17:59 | *** | mode: +o kstreith on #opticks by ChanServ |
| 14:18:11 | kstreith | yes, it would allow for a commits mailing list |
| 14:18:15 | dsulgrov | and what would happen during a release if a branch was not ready for integration> |
| 14:18:27 | kstreith | and simplify repo management |
| 14:18:43 | kstreith | it would be moved to a public sandbox area |
| 14:18:49 | tclarke | we would still lock down /sandbox so that historical branches are private...but they would not affect a commits mailing list if /sanbox was made r/o to core developers |
| 14:18:53 | kstreith | since the branch would have already had itar approval |
| 14:19:31 | dsulgrov | how would the public sandbox work? |
| 14:19:45 | tclarke | yes to the public sandbox, but I think we would want to name it differently...something like /incomplete to indicate that this has a more narrow focus from /sanbox |
| 14:19:51 | kstreith | more like our current branches |
| 14:20:01 | kstreith | meaning if you had received itar approval for a CR |
| 14:20:08 | kstreith | but knew it wouldn't be implemented in time |
| 14:20:14 | kstreith | you could create it over there |
| 14:20:25 | dsulgrov | would that be the only contents of the public sandbox? |
| 14:20:33 | kstreith | agree with tclarke that it should have a better name than /sandbox |
| 14:20:43 | kstreith | yes, only those things with itar approval |
| 14:20:46 | dsulgrov | developers would not be able to create new branches on their own? |
| 14:20:51 | tclarke | yes...only approved branches which don't belong in /branches for some reason |
| 14:21:16 | kstreith | dsulgrov, from a procedural point of view, yes |
| 14:21:23 | tclarke | dsulgrov: much like /branches we would not enforce it from svn (since that's difficult) but procedure would enforce it |
| 14:21:26 | kstreith | from a technical permission point of view, they could |
| 14:21:50 | tclarke | developers would still be the only onces with any r/w access to the repo |
| 14:21:50 | tclarke | onces=ones |
| 14:22:31 | tclarke | it's unfortunate that tjohnson is not here...I was reviewing the previous meeting notes and he had some concern |
| 14:23:01 | tclarke | he frequently uses /sandbox for private branches and was going to look at svk, etc. to see how well it would work for him |
| 14:23:13 | kstreith | true |
| 14:23:45 | tclarke | kstreith and I did an informal test with git, mercurial, and svk and had no technical problems doing this....there's a little bit of a learning curve but it's not too steep for people already familiar with subversion |
| 14:24:41 | kstreith | yeah, it's not too bad |
| 14:24:53 | tclarke | any other concerns or comments? |
| 14:24:54 | kstreith | there are quite a few resources out on the internet that explain how to do it |
| 14:25:06 | *** | tjohnson (tjohnson!i=0cbc9d81@gateway/web/ajax/mibbit.com/x-20494a7150963217) has joined #opticks |
| 14:25:13 | tclarke | yes and we could write a quick tutorial for opticks use |
| 14:25:34 | kstreith | agree |
| 14:25:37 | tclarke | tjohnson: we are revisiting the idea of removing the private sandboxes from subversion |
| 14:25:43 | tclarke | so we can re-enable the commits mailing list |
| 14:25:57 | tjohnson | So I was told. |
| 14:26:15 | tclarke | we had ended discussion a few weeks ago and you had some concern regarding the creation of private branches on a local machine as an alternative |
| 14:27:07 | tjohnson | It certainly would be an inconvenience to me. |
| 14:27:21 | tclarke | if you did not get a chance to try this, I can give a very brief summary of the procedure using svk |
| 14:27:39 | tjohnson | However, I can see the benefit of re-enabling the commits mailing list. |
| 14:27:43 | tclarke | part of this needs to happen using the command line with svk (git and mercurial have guis) |
| 14:28:10 | tclarke | basically: svk mirror https://opticks.ballforge.net/sv/opticks/trunk/future //mirror/opticks/future |
| 14:28:18 | tclarke | this creates a new mirror...it's a one time command |
| 14:28:29 | tclarke | you update the mirror with: svk sync -all |
| 14:28:52 | tclarke | you create a local branch with: svk cp //mirror/opticks/future //branches/opticks/future/MyBranch |
| 14:29:11 | tclarke | you can then either use svn co //branches/opticks/future/MyBranch c:\MyBranch |
| 14:29:47 | tclarke | or since svk uses svn for the underlying repo, you can point Tortoise to file:///c:/depot/branches/opticks/future/MyBranch |
| 14:29:51 | tclarke | and work with tortoise |
| 14:30:12 | tclarke | you can generate a patch when you are ready to create a real branch |
| 14:30:21 | tclarke | and apply to your checked out working copy |
| 14:30:35 | tclarke | svk is the most straightforward for subversion users |
| 14:31:05 | tclarke | there are benefits to git and mercurial which add value to local branch work but they have a little bit steeper learning curve |
| 14:31:07 | tclarke | . |
| 14:32:21 | kstreith | i'd also like to point out that tjohnson is in a unique situtation |
| 14:32:37 | kstreith | in that 90% of what he submits starts out as a private branch |
| 14:32:50 | kstreith | this isn't the case for the rest of the committers |
| 14:33:07 | kstreith | and for any new contributors, they would have to submit .patch files to us |
| 14:33:24 | kstreith | for some time before we granted them permission to create private sandboxes, if we were to keep private sandboxes around |
| 14:33:24 | tclarke | here's what I propose: |
| 14:33:47 | kstreith | so it's highly likely new contributors would use git, mercial, svk or a local working copy when creating their .patch files |
| 14:34:14 | kstreith | done. |
| 14:34:49 | tclarke | we vote today to see if we would like to try removing /sandbox (as with all votes at these meetings, this is a recomendation and non-binding, the final decision rests with the core commiters...but these decisions will likely be followed) |
| 14:35:11 | tclarke | if we vote to remove the private sandbox...we have a trial period...perhaps up until 4.2.4 |
| 14:35:29 | tclarke | if everything works well for everyone, we finalize the removal of /sandbox |
| 14:35:58 | tclarke | we can re-enable the commit mailing list while the trial happens but if we revert, we can always disable it again, and make /sandbox r/w as it is now |
| 14:35:59 | tclarke | . |
| 14:36:13 | tjohnson | FYI, I have an active sandbox branch for OPTICKS-409 currently. |
| 14:36:47 | tclarke | we can either wait until it gets ITAR approval or use it as a trial branch |
| 14:36:56 | tclarke | depends on the current timeline for that branch |
| 14:37:01 | tjohnson | If 409 could get CCB approved, I could create the real branch and merge my sandbox branch into it and delete the sandbox branch. |
| 14:37:31 | tclarke | dsulgrov: do you know the status of that issue? |
| 14:37:41 | dsulgrov | still waiting for approval |
| 14:37:51 | tclarke | but it's on the current request list? |
| 14:37:55 | dsulgrov | yes |
| 14:38:11 | tclarke | ok, we can probably wait until that is moved to /branches then start the trial? |
| 14:40:34 | tclarke | The question we are voting on is: "Should we deprecate the private sandboxes in subversion? This would be for a trial period and would finalize when the 4.2.4 rollup occurs." Indicate +1/-1/0 Anyone not voting after the alloted time will be assumed to vote 0. Issue needs +3 to pass. |
| 14:41:17 | kstreith | +1 |
| 14:41:18 | tclarke | +1 |
| 14:41:20 | tjohnson | +1 |
| 14:41:28 | mconsidi | +1 |
| 14:41:32 | raevans | +1 |
| 14:43:01 | dsulgrov | +1 |
| 14:43:06 | tclarke | ok, motion passes |
| 14:43:26 | tclarke | we'll begin the trial when tjohnson's branch is approved and moved into /branches |
| 14:43:39 | tclarke | we'll work the technical details and post a summary to the dev@opticks mailing list |
| 14:43:58 | tclarke | including what to do with other branches currently in /sandbox (leave them or delete them) |
| 14:44:14 | tclarke | the other issue was one that came up a few meetings ago as well.. |
| 14:44:32 | tclarke | it was an off the wall idea but I think there's mostly been an agreement on the mailing list |
| 14:44:44 | tclarke | let's leave a short time for discussion anyway |
| 14:44:59 | tclarke | should we remove the enhancement JIRA type and make enhancements into features |
| 14:45:27 | tclarke | the question came up since enhancements and features both need itar approval and one of the initial reasons for a distinction |
| 14:45:39 | tclarke | was to get automatic approval on minor enhancements |
| 14:46:02 | tclarke | I believe there is still value to enhancement as there's a more compact workflow for minor enhancements which can save time |
| 14:46:05 | tjohnson | A downside is the workflow is more onerous for features. |
| 14:47:00 | tclarke | there's also a potential contractual distinction for paying customers...there are other ways to represent this distinction but the JIRA issue type can be a good rule of thumb distinction |
| 14:47:18 | tclarke | are there other major arguments for or against this question? |
| 14:47:30 | tclarke | if not, I move we vote on the issue now and move on |
| 14:47:31 | tclarke | . |
| 14:47:34 | dsulgrov | not that I am suggesting this, but it almost seems like there should be two kinds of enhancements - one that allows for design and review, and one that does not |
| 14:47:56 | kstreith | it's clear to me something should be done to ease some of the confusion surrounding bug, enhancement, new feature |
| 14:48:03 | kstreith | i'm not sure what the solution is though |
| 14:48:16 | kstreith | and i'm not sure removing enhancement is the best answer |
| 14:48:22 | tclarke | I agree there is the possibility of more types of issues but I think feature/enhancement is a good way of handling this without too many issue types |
| 14:48:30 | tjohnson | Opticks 415 is a case in point (template not saving paper color). |
| 14:48:51 | kstreith | i'm for leaving it alone for now |
| 14:48:59 | kstreith | and gathering some more data points on the problem |
| 14:49:16 | tclarke | tjohnson: I agree in principal with what you are saying (in short, it's a bug based on the original design criteria) |
| 14:49:45 | tclarke | I think in the case of 415, that's tough to show since we have no design documentation for the original feature...but in the future this will not be the case |
| 14:50:35 | tclarke | I think we've had enough discussion for the vote to remove the enhancement type...it seems to jira types problem may need more discussion offline but I think we have enough for the question on the agenda |
| 14:50:41 | tclarke | going once |
| 14:50:46 | kstreith | part of the problem with 415 is that the selection criteria for bug, new feature, enhancement |
| 14:50:59 | kstreith | requires knowing the code changes |
| 14:51:12 | kstreith | so a user reporting a bug can't always bin it correctly |
| 14:51:34 | kstreith | so that's at least one of the problems with the current model |
| 14:52:05 | kstreith | i'm done |
| 14:52:25 | kstreith | we can proceed with a vote |
| 14:52:54 | tclarke | ok, the question is: "Should we remove the enhancement JIRA issue type?" +1/-1/0 no vote=0 |
| 14:52:55 | tclarke | -1 |
| 14:53:03 | kstreith | -1 |
| 14:53:05 | dsulgrov | -1 |
| 14:53:40 | raevans | -1 |
| 14:53:43 | tjohnson | -1 |
| 14:53:48 | mconsidi | -1 |
| 14:53:54 | tclarke | ok, issue fails |
| 14:54:08 | tjohnson | It sounds like we agree there needs to be a change, but we don't know what that change is yet. |
| 14:54:13 | tclarke | agreed |
| 14:54:26 | tclarke | let's discuss some more offline and revisit at the next meeting |
| 14:55:15 | tclarke | I can post a followup to the email list to start some discussion (it will be separate from the original 415 discussion to try and get some more participants) |
| 14:55:31 | tclarke | final item on the agenda...opticks-418 |
| 14:55:36 | tclarke | there was some discussion earlier |
| 14:55:49 | tclarke | this has to do with an XML file format for exporting DataElement metadata |
| 14:56:12 | tclarke | we have an XML serialization of a DynamicObject that's basically a hierarchical key-value serialization |
| 14:56:24 | tclarke | the problem is that the types (and associated value ranges) are not well defined |
| 14:56:37 | tclarke | they are currently defined in TypeConverter.cpp and StringUtilities.cpp |
| 14:57:19 | tclarke | There's no way for a plug-in custom type to reside in the metadata but that's not necessarily by design and could be remedied so we way want to consider types which are defined outside the core |
| 14:57:22 | kstreith | tclarke, can you also present the usage scenario for this new file format |
| 14:57:50 | tclarke | this would be designed to export RasterElement metadata to a file format which can be read by an external script |
| 14:58:10 | tclarke | it would be used to populate product templates such as work docs and html pages |
| 14:58:58 | tclarke | we have the option of keeping the current behaviour the same and adding documentation pointing the plug-in developer to the two cpp files (or aduplicating this info elsewhere) |
| 14:59:34 | tclarke | this would essentially "fix" the types to a certain release of opticks...they would likely be stable for many versions but could change with any release |
| 14:59:51 | tclarke | there would be no build in way to document plug-in specific types |
| 14:59:57 | tclarke | another option: |
| 15:00:42 | tclarke | take the current types and distill them into a document, add a type version number, and ensure that the current serialization implementation does not arbitrarily change the types between releases |
| 15:01:25 | tclarke | this would "fix" the types to a specific version which can be updated as changes occur |
| 15:01:25 | tclarke | the third option: |
| 15:01:29 | tclarke | define types using an OID, URI, or other "namespaced" type name |
| 15:01:44 | tclarke | allow plug-in developers to register a prefix |
| 15:01:58 | tclarke | document the registered prefixes as well as core-defined types in a document |
| 15:02:29 | tclarke | since these would be OIDs (or equiv) they would not be allow to change...if you needed to change the values in a certain data type, you'd define a new type which would replace the old |
| 15:03:08 | tclarke | this "add-only" system should negate the need for an explicit version number on the type list and allow from some definition of external types (at least a reference to who owns the type) |
| 15:03:36 | tclarke | in either case, the XML serialization would be versioned with the opticks xsd as it is now, these options would only "fix" the type names |
| 15:03:38 | tclarke | . |
| 15:09:28 | tclarke | thoughts? |
| 15:12:23 | tclarke | ok...kstreith had some comments earlier but is staying quiet in the interest of time...I'll post a summary message to dev@opticks and he can reply to that |
| 15:12:29 | tclarke | any other questions for today? |
| 15:13:20 | tclarke | going |
| 15:13:23 | kstreith | not from me |
| 15:13:31 | tclarke | and done |
| 15:13:41 | tclarke | as usual, I'll post a link to the notes |
| 15:13:52 | tclarke | and the next meeting's agenda will be available later today |
| 15:14:00 | tclarke | the meeting is over...have a good day |