Meeting on February 9, 2009

Agenda

1. Attendance
2. Announce agenda
3. Approve January 26, 2009 Meeting Notes. Ask for review and address any problems seen in the notes.
4. Follow up to removal of private sandboxes.
5. Talk about the 4.2.5 release schedule.
6. Wizard builder design.
7. Geoanalysis/idl/python/spectral/aspam distribution.
8. Open questions
9. Summary and closing

Notes

Attendance

• rforehan
• tclarke
• raevans
• dsulgrov
• kstreith
• goffena
• gwelch
• tjohnson
• joverhol

Summary

The previous meeting minutes were approved.

The removal of private sandboxes has progressed and /sandbox should be treated as read-only. It will remain read-only during the trial period and will be removed afterwards. Subversion history will continue to be available. There is a short howto on using svk for local branches. It is available at PrivateBranches.

The 4.2.5 release schedule was discussed. Code lockdown will occur on 27Feb2009, rc1 will be available 6Mar2009, and final delivery will be on 31Mar2009.

The wizard builder design discussion and the distribution discussion were reversed. The distribution question was not fully answered but most involved agree that we would either:

1. Maintain one open source repository for the core and all core developer extensions. There would be one rollup, one set of version numbers, and one JIRA project with multiple components.
2. Maintain one repository with associated version number and JIRA project for the core. Core developer extensions would all go in a second repository with associated version number and JIRA project. Rollups would occur separately and the extensions would be built against an SDK. If a particular extension was deemed large enough, it would get its own repository, version number, and JIRA project.

The discussion was tabled due to time constraints. tclarke will make a post to dev@opticks.ballforge.net to continue discussion in that forum.

The new wizard builder was discussed. The issue is in feature analysis so the core developers are soliciting concerns, important features, etc. for the wizard builder. goffena gave a list of behaviors he would like to see. dsulgrov will use the discussion while evaluating and later, designing the new wizard builder.

Decisions

Logs

14:00:07	tclarke	we'll begin the meeting in a couple of minutes
14:00:28	tclarke	please start looking at last meeting's minutes now so we don't spend too long checking these during the meeting
14:00:33	tclarke	https://opticks.balldayton.com/cometwiki/26Jan2009
14:04:06	tclarke	ok, let's get started
14:04:14	rforehan	Here
14:04:14	tclarke	attendence is first up
14:04:16	tclarke	here
14:04:18	raevans	here
14:04:25	dsulgrov	here
14:04:30	kstreith	here
14:04:50	***	gwelch (gwelch!i=0cbc9d81@gateway/web/ajax/mibbit.com/x-6c189d84186d6d52) has joined #opticks
14:04:59	goffena	here
14:06:34	gwelch	here
14:06:37	tclarke	# Attendance
14:06:37	tclarke	# Announce agenda
14:06:37	tclarke	#
14:06:37	tclarke	Approve January 26, 2009 meeting notes. Ask for review and address any problems seen in the notes.
14:06:37	tclarke	# Follow up to removal of private sandboxes.
14:06:38	tclarke	# Talk about the 4.2.5 release schedule.
14:06:40	tclarke	# Wizard builder design.
14:06:42	tclarke	# Geoanalysis/idl/python/spectral/aspam distribution.
14:06:44	tclarke	# Open questions
14:06:46	tclarke	# Summary and closing
14:06:48	tclarke	please review https://opticks.balldayton.com/cometwiki/26Jan2009
14:07:09	tclarke	I'll give everyone a minute or two to check for errors in the summary, etc.
14:09:53	tclarke	ok, let's consider them reviewed and excepted...if anyone finds errors later, we can always fix the notes at another time
14:10:08	tclarke	next topic is private sandboxes
14:10:24	tclarke	the private branch that was awaiting release approval has received it
14:10:50	tclarke	we may set /sandbox to read-only at anytime (we don't have an exact schedule) so don't create any new content there
14:10:55	***	mib_e0qbrg (mib_e0qbrg!i=0cbc9d81@gateway/web/ajax/mibbit.com/x-c455869ddcd48564) has joined #opticks
14:11:04	tclarke	I've written up a basic howto for creating private branches using svk
14:11:11	tclarke	it is here for now: https://opticks.balldayton.com/cometwiki/PrivateBranches
14:11:21	tclarke	I'll move it to confluence once kstreith has finished setting it up
14:11:40	tclarke	any other questions regarding private branches and the /sandbox/
14:11:41	tclarke	?
14:12:11	dsulgrov	will the current sandbox still be available read-only?
14:12:24	***	mib_e0qbrg has quit (Client Quit)
14:12:49	***	tjohnson (tjohnson!i=0cbc9d81@gateway/web/ajax/mibbit.com/x-39b4c111dc02e4ff) has joined #opticks
14:12:52	tclarke	for the time being we'll keep it at least read-only....once the trial period is over, we'll delete /sandbox but it will always be available in subversion history
14:13:06	tjohnson	here
14:13:49	tclarke	tjohnson: we were just pointing out that since your branch has been release approved, we are moving forward with removal of the sandbox...it will become read-only at some point (we don't have an exact schedule)
14:14:06	tclarke	the notes will have a link to a short howto on creating private branches with svk
14:14:24	tclarke	and how to access the branches with TortoiseSVN
14:14:35	tclarke	any further questions?
14:15:08	tjohnson	I noticed that the JIRA issue for my branch (OPTICKS-409) has been deferred.
14:15:26	tclarke	dsulgrov: was this a DO150 issue?
14:15:33	dsulgrov	yes
14:15:39	tclarke	we've run out of DO150 funding
14:15:49	tclarke	so all DO150 issues are deferred pending a follow on
14:16:36	tjohnson	Does this mean that 4.3.0 is on hold pending a follow-on?
14:16:37	***	joverhol (joverhol!i=0cbc9d81@gateway/web/ajax/mibbit.com/x-6f4b7d45000f7b1d) has joined #opticks
14:16:48	tclarke	4.3.0 is primarily DO166
14:16:49	joverhol	here
14:16:57	tclarke	so no....but there's not release date for 4.3.0 yet
14:17:02	tclarke	not=no
14:17:25	tjohnson	How do issues get transferred from 150 to 166?
14:17:35	tclarke	if it's an O&M issue, it does not
14:17:38	tjohnson	Perhaps this should be discussed off-line.
14:17:48	tclarke	unless it's needed for a new R+D feature
14:17:55	tclarke	we'll talk to you offline about the details
14:18:12	tclarke	ok, on to the next topic...4.2.5 release schedule
14:18:45	kstreith	alright, the major point of emphasis for 4.2.5 is OPTICKS-48, https://issues.ballforge.net/jira/browse/OPTICKS-48
14:18:59	kstreith	which is the addition of an integrated installer, specifically AEB
14:20:04	kstreith	another group is going to provide the resources to get 4.2.5 out the door, so specifically joverhol and tjohnson are setting the schedule
14:20:38	kstreith	so, joverhol, tjohnson what is the desired date for a final 4.2.5 release?
14:20:51	tclarke	typically, we need 1 month from code lock down to delivery of a release including testing and release candidates
14:21:18	tclarke	that will have intermediate RC releases as usual so plug-ins can build and test against it before the month is up
14:21:38	***	gwelch has quit (Remote closed the connection)
14:21:41	tclarke	the first RC is typically available 1 week after code lockdown
14:22:00	joverhol	Late April would be a good delivery date. We would like to integrate with our Increment 5 (dev ends Feb 28, delivery in May)
14:22:29	joverhol	I would like to have a developers release during our development phase to test with.
14:22:40	tclarke	late april meaning the last week? (delivery may 1) or delivery earlier than that?
14:22:44	***	gwelch (gwelch!i=0cbc9d81@gateway/web/ajax/mibbit.com/x-f43df0111b1ed40c) has joined #opticks
14:22:56	gwelch	here (again)
14:22:57	tclarke	there are daily trunk releases automatically generated
14:23:03	tclarke	would those work for developer releases?
14:23:54	tclarke	gwelch: joverhol mentioned a late april release as desirable
14:24:08	joverhol	trunk builds should work fine as long as we can test the installer functionality
14:24:33	tclarke	you will be able too...it just removes the overhead of a rollup and testing from a traditional developer's release
14:24:39	tjohnson	This means that a working beta of the installer capability would be needed fairly soon.
14:24:41	joverhol	Give me a minute on the dates, i'm looking through a briefing.
14:25:26	tclarke	we're estimating about 2 man weeks to get the installer finished but there would be intermediate functionality available for testing as soon as we merge up to the latest trunk
14:27:23	joverhol	increment 5 release is scheduled for 30 Apr, but it ultimately depends on how long UAT goes.
14:27:39	tclarke	most of the remaining development work on our end is for algorithm efficiency which shouldn't prevent you from writing against it
14:28:03	kstreith	so, do you want a final 4.2.5 release on 30 Apr or do you want it some time before that?
14:28:18	kstreith	by final, i mean "production release"
14:30:08	joverhol	It would have to be sooner since our test cycle begins 1 Mar and runs through 29 Apr. Does 31 Mar sound realistic to get out 4.2.5?
14:30:42	gwelch	that would mean locking the code 27 Feb
14:30:51	joverhol	Obviously we would need a developers release to start our testing on 1 Mar.
14:31:24	kstreith	if lockdown is 27Feb, then rc1 would be out by 6Mar at the latest
14:32:25	gwelch	joverhol - if you actually need rc1 by 1 Mar, we would need to lock the code by 20 Feb
14:32:37	tclarke	I think that's probably the tightest schedule we can do....as mentioned before, you can download a trunk installer with the functionality as soon as we merge up to the current trunk
14:32:41	gwelch	I'm not certain that's realistic
14:32:43	tclarke	so this week sometime if needed
14:34:19	joverhol	How many hours do you have remaining on the integration?
14:34:37	kstreith	joverhol, i agree with tclarke the tightest schedule we can do is to have 4.2.5rc1 by 6Mar and final 4.2.5 by 31 Mar
14:35:07	joverhol	kstreith, I think 6Mar and 31Mar are good.
14:35:59	tclarke	the merge up will not take long...a matter of hours
14:36:21	tclarke	so we could have a 95% functionality version for you in the next day or two if necessary
14:36:31	tclarke	then the remaining 5% over the next couple of weeks
14:37:06	tclarke	most of the 5% is efficiency and cleanup plus a couple of minor features we needed to add based on previous discussions with you
14:37:45	kstreith	either tclarke or I will post something to the dev mailing list later today describing this schedule for 4.2.5
14:37:58	gwelch	So, to recap, code lock = 27 Feb, rc1 = 6 Mar, and final delivery = 31 Mar
14:38:05	gwelch	is that correct?
14:38:15	tclarke	sounds like it
14:38:22	joverhol	i'm good with it.
14:38:23	kstreith	i agree
14:38:43	tclarke	ok, I'd like to reverse the order of the final two topics as gwelch may care about #7 on the list
14:38:48	tclarke	but not likely #6
14:39:03	tclarke	anything further on 4.2.5?
14:39:14	dsulgrov	yes...
14:39:18	tclarke	ok...go ahead
14:39:31	dsulgrov	4.2.5 will most likely contain the following issues:
14:39:35	dsulgrov	OPTICKS-48
14:39:47	dsulgrov	OPTICKS-456
14:40:21	tclarke	OPTICKS-48: Add an integrated installer to Opticks
14:40:21	dsulgrov	and another issue that has yet to be created regarding adding support to load certain kinds of NITF files
14:40:28	tclarke	OPTICKS-456: Integrate convolution filter, annotation image pallete, image flatten, and rotation plug-in capability into Opticks
14:40:59	joverhol	Is 4.2.5 still binary compatible?
14:41:02	tclarke	yes
14:41:07	kstreith	yes
14:41:14	tclarke	all third digit version changes are binary compat
14:41:18	kstreith	the version numbering scheme requires it be
14:42:31	tclarke	ready to move on?
14:42:47	tclarke	the next topic has to do with distribution of certain functionality
14:43:10	tclarke	there are plug-ins which are developed by the core team which don't necessarily belong in the core disctribution
14:43:20	***	joverhol has quit ("http://www.mibbit.com ajax IRC Client")
14:43:52	tclarke	examples being: geoanalysis (which will contain parts of spectral functionality), some of the plug-ins currently in COAN, and certain plug-ins which have external dependencies such as IDL
14:44:04	tclarke	we're not sure where to version control these, how to distribute, etc.
14:44:18	tclarke	thoughts?
14:45:02	kstreith	i think they need to be separate from opticks
14:45:11	kstreith	at least from a end-user distribution point of view
14:45:18	tclarke	I tend to agree
14:45:31	dsulgrov	I think they should have a different project on the ballforge site
14:45:35	kstreith	but i'm not sure if it's always worth creating a new Subversion repo and JIRA project for each project
14:45:41	tclarke	so different subversion and web presence
14:45:57	tclarke	should they have different jira projects as well?
14:46:10	rforehan	Are you referring to open-source code only?
14:46:12	tclarke	or simply different "components"
14:46:20	tclarke	in this forum...yes
14:46:21	kstreith	yes, open-source code only
14:46:46	tclarke	should there be separate roll-ups or should rollups be tied together?
14:46:54	***	dadkins (dadkins!n=kvirc@12.188.157.129) has joined #opticks
14:46:59	tjohnson	different installers?
14:47:10	tclarke	they would probably be different AEBs
14:47:16	tclarke	but that's also open for discussion
14:47:55	rforehan	What about testing?
14:48:05	tclarke	related to rollups is the question of version numbers
14:48:17	kstreith	rforehan, good question
14:48:23	tclarke	and that ties into JIRA
14:48:42	rforehan	Could they all be under COAN?
14:48:52	tclarke	COAN has other connotations
14:49:05	tclarke	it has no official tie in to Opticks or ball
14:49:14	tclarke	therefore we don't support it, roll it up, etc.
14:49:30	tclarke	it's a convenient place to share in progress, unofficial, etc. code
14:49:47	rforehan	Are all these "extras" paid for by customers?
14:49:50	tclarke	the hope being that some COAN plugins more to official support status but then would need to move repos
14:49:55	tclarke	no
14:50:19	kstreith	stuff in COAN is not paid for
14:50:23	tclarke	some things in there have been paid for under on gov't charging
14:50:29	tclarke	but most is free-time stuff
14:50:40	tclarke	on=non
14:50:45	kstreith	this other stuff we're talking about would be, GeoAnalysis (open-source Spectral), IDL Plug-In, etc.
14:51:05	tclarke	ASPAM has also been discussed under this category
14:51:14	rforehan	Could we have an "Add on" repo and JIRA section to handle this?
14:51:17	tclarke	i.e. moving it out of the "core"
14:51:37	kstreith	we don't want to stuff GeoAnalysis and for example an IDL Plug-In into every Opticks distribution
14:51:39	tclarke	that's one possibility....geoanalysis could be a second open source repo which is a catch all
14:51:47	kstreith	so where do we put it? that's the question
14:52:01	kstreith	i agree, a catch all repo is one option
14:52:02	rforehan	Ballforge?
14:52:22	kstreith	possibly, but do we create a project for each new thing?
14:52:27	tclarke	ballforge is the likely place but should each extension have a separate project?
14:52:33	tclarke	or one project for all?
14:52:43	tclarke	or on opticks.ballforge.net but in a different "trunk"
14:52:57	kstreith	if this is coming off muddled, it's because in my and tclarke's mind it currently is
14:53:04	rforehan	Lots of overhead if each is a separate project
14:53:14	tclarke	I like the idea of geoanalysis being a separate ballforge project and acting as a catch all for this extra stuff
14:53:32	tclarke	pieces might be in different AEBs but they'd be rolled up as one piece
14:53:48	tclarke	I'm not sure how to version number them to make it easy to handle in jira
14:54:02	tclarke	kstreith: what would be the best way to handle JIRA in your opinion?
14:55:04	kstreith	more projects means possibly more jira admin if each has it's permissions, issue types, etc.
14:55:15	rforehan	Can you have a group version for entire suite and individual version or each AEB?
14:55:30	rforehan	or->for
14:55:31	kstreith	if we require all the jira projects be set-up the same and share perms then either way is about the same level of effort
14:56:05	tjohnson	one options is a single jira project with a components field
14:56:10	tjohnson	options=option
14:56:22	rforehan	Or do a date in rollup version of AEB's
14:57:09	tclarke	can we track different version numbers for different components? or do we need a separate project for different version numbers?
14:57:12	rforehan	Won't the new AEB installations allow user to pick which AEB's in suite to load?
14:57:40	tclarke	an AEB extension is what we were previously calling a suite
14:58:11	rforehan	Ok, so are the individual components within the AEB selectable?
14:58:17	tclarke	no
14:58:33	tclarke	an AEB is a single, inseperable piece
14:58:39	kstreith	separate JIRA project for diff version numbers
14:58:59	rforehan	So if all the "add-ons" are in one AEB, there's no choice but everything?
14:59:11	tclarke	they would not be in one AEB
14:59:25	tclarke	they would be separate AEBs but possibly in one subversion repo, etc.
15:01:06	tclarke	I think a separate svn, jira, and ballforge project for each AEB is probably overkill
15:01:37	kstreith	at the outset i tend to agree
15:02:01	tclarke	I'd like a catch all and if a certain piece becomes big enough, we can always spawn another project for it
15:02:04	kstreith	but a particular part might be come popular enough to warrant being pulled up it's own top-level project
15:02:38	tclarke	I think I like separate rollups for the Core and for the "other stuff" as we will likely not be doing heavy development in both areas at the same time
15:03:00	rforehan	Sounds better than fragmenting into multiple repos, etc. at the start.
15:03:02	tclarke	but I think that would require a new version number and a new jira project
15:03:23	tclarke	with components for each extension (aeb) in the project
15:03:39	dsulgrov	I'm leaning towards one repo, one JIRA project with multiple components, and separate AEBs
15:03:50	tclarke	If we separate like that, I'd definately want to build against SDKs and not a core source checkout
15:04:03	tclarke	one repo for core and extensions?
15:04:10	dsulgrov	yes
15:04:22	kstreith	in general, yes
15:04:26	tclarke	so we'de have to roll up all at the same time?
15:05:00	dsulgrov	for now
15:05:04	kstreith	i think dsulgrov and I read that as one repo each for core and extensions, i.e. two repos total
15:05:27	tclarke	that's what I was trying to clarify
15:06:10	dsulgrov	I was thinking only one combined repo, but if it makes more sense for two repos, I would be ok with that
15:06:58	rforehan	Two JIRA projects, one for core and one for ectensions?
15:07:13	rforehan	ectensions->extensions
15:07:39	tclarke	rforehan: it sounds like there would be one jira project per svn repo...so if it's one project total, that's one jira project and one repo
15:07:52	tclarke	if core an extensions are split into two, there would be two jira projects
15:08:01	dsulgrov	I really like the thought of only having one JIRA project
15:08:15	tclarke	it sounds like the ideas are generally played out....let's post something to the mailing list for some final opinions
15:08:26	dsulgrov	it makes it really simple for people to submit issues
15:08:32	kstreith	yeah, but if the user installs separately
15:08:47	kstreith	are they expecting to report issues separately?
15:09:46	rforehan	Seems easier for user to have just one entry point into bug reporting.
15:11:08	rforehan	Could we add section to issue to report what extensions are loaded along with description of the bug?
15:11:39	dsulgrov	If we view extensions as port of Opticks, I don't think I would necessarily expect to report issues separately
15:11:48	dsulgrov	port = part
15:12:14	tclarke	that would mean that spectral (or at least the open part) would come with every release of opticks
15:12:14	dsulgrov	in my opinion the extensions simply allow users to customize their Opticks installation
15:12:47	kstreith	right, so that a base Opticks install wouldn't have any extensions
15:12:59	kstreith	and you as a user would then add them on
15:13:00	dsulgrov	that's my thought
15:13:12	tclarke	ok, in the interest of time, I think we need to table the rest of this discussion...feel free to continue after the meeting on irc or the mailing list (I'll make a post to start a mailing list discussion if we'd lile)
15:13:27	kstreith	and the download location for those extra extensions could tell you how to report bugs against them
15:13:30	dsulgrov	kind of like add-ons to Firefox
15:13:50	tclarke	the last scheduled topic for today is the wizard build redesign
15:13:54	tclarke	builder that is
15:14:03	kstreith	right, but not all add-on bug reports go to the Firefox bug reporting tool
15:14:20	kstreith	sorry for my interruption, i'm done now
15:14:26	tclarke	this is currently being pursued by dsulgrov so I'll let him start this off
15:14:38	dsulgrov	no, but some add-ons are officially supported
15:15:00	dsulgrov	.
15:15:27	dsulgrov	our current plan for 4.3.0 is to make some front-end upgrades to the wizard builder
15:15:48	dsulgrov	this includes creating a tree view containing all wizard items
15:15:58	dsulgrov	with drag-and-drop support to add the items to the wizard
15:16:43	dsulgrov	we are also looking at enabling panning and zooming support by converting the source to use the QGraphicsView classes
15:17:07	dsulgrov	and we would add some detailed documentation regarding creating and editing wizards
15:17:41	dsulgrov	there is also the possibility of adding a few small minor upgrades
15:17:57	dsulgrov	these issues are described in OPTICKS-455
15:18:25	dsulgrov	.
15:19:09	kstreith	to clarify we're only considering UI changes for 4.3.X
15:19:18	kstreith	does anyone have other ideas?
15:19:58	goffena	Wizard Value Item selection dialogs Type list should be in some sort of order.
15:20:18	goffena	1) Wizard Value Item selection dialogs Type list should be in some sort of order.
15:21:29	***	tclarke_ (tclarke!n=vircuser@12.188.157.129) has joined #opticks_
15:21:41	goffena	2) Some way of creating 90 degree bends in the connecting lines (might mean adding an "anchor" like node) (think i've been told this is a large change and possibly not feasable. hoping i remember ed wrong)
15:22:01	goffena	3) Zoom in and out, as you have already suggested
15:22:30	goffena	4) Wizard Builder Open and Save Dialogs are not consistent. One has user defined "bookmarks", whie the other doesn't.
15:22:34	***	tclarke has quit (Nick collision from services.)
15:23:07	goffena	5) Drag-and-drop of wizards into Wizard Builder
15:23:08	***	mode: +o tclarke on #opticks by ChanServ
15:24:31	goffena	6) Some sort of notice to user or message log that wizard items inputs/outputs no longer match what is available with a version of Opticks (when i upgrade to next version of Opticks, this could be happen, and would be useful to know what is not compatiable)
15:25:55	goffena	7) Probably beyond scope of what you are doing: User prompted branching. kstreit: think of the conditional logic used by SBIRS workbench when it used a python script.
15:26:15	kstreith	that's a back-end change
15:26:28	kstreith	so very doubtful it would make it in
15:26:39	dsulgrov	goffena: is this your preferred order?
15:27:40	goffena	8) My number one complaint was actually how tedius it was to add wizard items. One thought i had was allow clicking the enter key be the same as clicking the Ok button. What i wanted to do was use keyboard to shift up/down in the lists
15:27:41	goffena	...
15:28:06	goffena	use keys to quick jump through the list, and then press <Enter> to add the item.
15:28:24	tclarke	goffena: the treeview idea dsulgrov mentioned would help that
15:28:40	goffena	i think you tree view of available wizard items will probably overcome that quibble
15:28:41	tclarke	you'd have a "palette" of available wizard nodes, sorted to a degree
15:28:48	tclarke	and you'd drag and drop to add them
15:29:03	dsulgrov	multiple selection in the tree view would allow users to add items simultaneously
15:29:10	goffena	drag-and-drop to where i want them to be placed as well, i assume?
15:29:23	goffena	before, it was annoying how it auto positioned every wizard item
15:29:27	tclarke	I'm assuming that as well
15:29:39	goffena	i think the drag-and-drop will help alot
15:29:42	tclarke	with multiple items probably spaced out a bit
15:29:56	tclarke	any other big ticket features people would like?
15:30:13	kstreith	i think we should probably toss this out to the dev and users mailing list as well
15:30:20	dsulgrov	yes we could place the item at the drop location, but multiple items addd simultaneously would be at the same location
15:30:22	kstreith	just to see what other feedback we get
15:30:31	goffena	dsulgrov: other than 90 degree bends in connecting lines, that's the order i would like them addressed
15:30:38	tclarke	I agree...this was meant to be an initial dicussion forum with a more honed mailing list message
15:31:02	dsulgrov	so based on your numbering, what is your preferred order?
15:31:09	tclarke	dsulgrov: multiple items could space out centered on the drop location...such as when you dnd files in explorer onto the desktop
15:33:50	goffena	Now that i think this over again, here is my wishlist from most wanted to least wanted: 8, 6, 2, 1, 3, 4, 5, 7
15:34:14	goffena	I realize that some of these are outside of scope of changes to make, and some are just not possible, etc
15:34:35	tclarke	that's fine...it's our job to determine scope, etc
15:34:47	goffena	i think 8 is already being worked, possibly 1 is being worked as part of 8
15:35:42	tclarke	ok, if there are no further suggestions or concerns, let's move on
15:35:50	goffena	6 is mainly desirable to help a developer know what needs fixed in a wizard, when loading into a version of Opticks the wizard is incompatible with
15:35:59	goffena	one more?
15:36:02	tclarke	sure
15:36:14	tclarke	I'm not trying to cut you off...just want to move on when done
15:36:25	tclarke	let me know when you have finished
15:36:34	***	gwelch has quit ("http://www.mibbit.com ajax IRC Client")
15:36:38	goffena	from jira issue: "Add easier ways to connect items instead of clicking and dragging the middle mouse button or selecting items in the list widgets. "
15:37:00	tclarke	that is one issue that will be addressed somehow during these updates
15:37:10	goffena	i think it works reasonly well as is. THe problem is noone knows to use the middle button.
15:37:18	goffena	the panel approach is very painful.
15:37:38	dsulgrov	we were thinking of switching to a more context-sensitive left click to connect items
15:38:05	dsulgrov	left click in middle of item to move the item and left click on node to connect to another node
15:38:05	goffena	the middle mouse button works well, unless you have two wizard items which will not fit onto the same viewing screen, which you want to connect. Zoom out may help that aspect.
15:38:46	goffena	so two clicks connects one node to another node?
15:39:05	dsulgrov	no, just left-click drag-and-drop
15:40:02	goffena	that should work with zoom capabilities. At least users will know about it, as users don't tend to hit middle button very often.
15:40:12	goffena	tclarke: i'm done.
15:40:13	goffena	.
15:43:28	tclarke	ok let's move on
15:43:31	tclarke	any open discussion?
15:44:42	tclarke	ok
15:44:58	tclarke	lets close upo
15:45:13	tclarke	thanks for sticking around, I know this was a long dense meeting
15:45:25	tclarke	as usual, I'll write up meeting notes and post to the mailing list
15:45:29	tclarke	next meeting is in two weeks