Meeting on December 15, 2008
Agenda
- Attendance
- Announce agenda
- Approve December 1, 2008 Meeting Notes meeting notes. Ask for review and address any problems seen in the notes.
- Discuss hosting a Google Summer of Code intern for the summer of 2009. Ideas on the Google Summer of Code page.
- Discuss removal of subversion sandboxes and reinstatement of commit emails
- Should all new features be discussed on the email list? (discussion and vote)
- Open questions
- Summary and closing
Notes
Attendance
- rforehan
- raevans
- kstreith
- mconsidi
- tclarke
- dsulgrov
- tjognson
- goffena
- gmartin_cn
Summary
The previous meeting minutes were reviewed and approved.
Opticks participation in the 2009 Google Summer of Code was discussed. Those present seemed to think this was a good idea. There was some concern about ensuring we understand all the steps and resources required. An information decision was make to brainstorm ideas and seek further details when the official announcement was made in March.
There was discussion on removing the hidden sandbox in subversion. Details on the reasons for the sandbox were presented as well as alternative solutions to these requirements. A vote will be held at the next regularly scheduled meeting to decide if the sandbox should be removed. tclarke will send an email to dev@opticks.ballforge.net with information on the alternatives so that users of the sandbox can evaluate them.
Much discussion was had about the new features discussion thread. Three main questions were discussed and a forth related question was presented.
- Should core developers push info about new feature development to an email list?
- What is the definition of new feature?
- What method should be used to push this information (automatic or manual)?
There was a vote on the first two questions. The results are below. The second question did not receive a quorum and a special meeting will be scheduled to finalize discussion. It will be on Wednesday [December 17, 2008|../display/opticksChat/2008/12/17/December+17%2C+2008+Meeting+Notes] at 2:00pm EST.
The final question raised, with discussion on the next regularly scheduled meeting is if the enhancement JIRA issue type is still necessary and if not, should it be removed?
Decisions
- Should core developers push info about new feature development (defn of new feature will be the second vote) to an email list? (9 attending, 8 yea, 0 nea, 1 abstention)
- Should we require discussion solicitation for all issues which will go into the trunk? (A -1 will indicate only Features require discussions) (9 attending, 1 yea, 3 nea, 5 abstentions) There was not a quorum so the issue has been tabled.
Logs
| *** | Opened channel log for #opticks at 12/15/2008 2:00:27 PM | |
| 14:00 | tclarke | logging is now enabled |
| 14:00 | rforehan | Here |
| 14:00 | raevans | here |
| 14:00 | kstreith | Here |
| 14:00 | mconsidi | Here |
| 14:00 | tclarke | here |
| 14:00 | dsulgrov | Here |
| 14:00 | tjohnson | Here |
| 14:00 | goffena | here |
| 14:01 | tclarke | todays agenda |
| 14:01 | tclarke | # Attendance |
| 14:01 | tclarke | # Announce agenda |
| 14:01 | tclarke | # |
| 14:01 | tclarke | Approve December 1, 2008 meeting notes. Ask for review and address any problems seen in the notes. |
| 14:01 | tclarke | # |
| 14:01 | tclarke | Discuss hosting a Google Summer of Code intern for the summer of 2009. Ideas on the SummerOfCode2009 page. |
| 14:01 | tclarke | # Discuss removal of subversion sandboxes and reinstatement of commit emails |
| 14:01 | tclarke | # Should all new features be discussed on the email list? (discussion and vote) |
| 14:01 | tclarke | # Open questions |
| 14:01 | tclarke | # Summary and closing |
| 14:01 | tclarke | anyone have problems with https://opticks.balldayton.com/cometwiki/1Dec2008 ? |
| 14:01 | gmartin_cn | here (sorry, a bit late) |
| 14:02 | tclarke | ok, last meeting's minutes are approved |
| 14:02 | tclarke | our first real item has to do with the 2009 Google summer of code |
| 14:02 | tclarke | for those who are not familiar, Google sponsors a number of interns for the summer |
| 14:02 | tclarke | they are tasked with working on open source projects |
| 14:03 | tclarke | sponsors provide ideas, mentoring, etc. |
| 14:03 | kstreith | http://code.google.com/soc/2008/ for details on last years event |
| 14:03 | tclarke | google pays the interns a stipend and sponsors get a small stipend so there is not direct cost if opticks sponsors a student |
| 14:04 | tclarke | we did not apply in 2008 as we did not feel opticks development resources were in place for a 3 month intern to get up to speed and do something useful |
| 14:04 | tclarke | I feel we are just about ready for something like this and can be ready for summer 2009 |
| 14:04 | tclarke | thoughts? |
| 14:05 | tclarke | we would also need to come up with some project ideas for a student |
| 14:05 | gmartin_cn | From a community standpoint, is part of the goal to get Google to see how Opticks might fit into their Google Earth/Maps product space? |
| 14:05 | tclarke | so consider this a brainstorming session as well |
| 14:05 | tclarke | the goal from Google's standpoint is simply to get students working open source |
| 14:06 | kstreith | the goal from our standpoint is to get new contributors |
| 14:06 | tclarke | they also use it indirectly to search for talent |
| 14:06 | tclarke | our goal is as kstreith mentioned |
| 14:06 | kstreith | the actual task isn't all that important to either google or us |
| 14:06 | gmartin_cn | Right, but they usually also have an ulterior motive, and it never hurts to get a company like Google looking at how Opticks can possibly fit into their plans |
| 14:08 | tclarke | I think their main secondary goal is to find new employees but there's always a chance they find a product that interests them |
| 14:08 | tclarke | if google gets interested in Opticks because of this, it's good for us but I'm not going to count on it |
| 14:08 | gmartin_cn | In tougher economic times, even companies like Google look for some possible fit with their interests... the days of 'community goodwill' only are limited... not saying that is necessarily the case here, just that we need to think of this in terms of how we can best put Opticks in front of more influential people... and target groups like the academic space (who usually follows Google's lead) |
| 14:09 | gmartin_cn | I'm not against more contributors, just looking to balance the contributor aspect with using Google to grow the outward community for Opticks |
| 14:09 | kstreith | sounds like gmartin_cn is behind the idea |
| 14:09 | kstreith | what do others think? |
| 14:10 | rforehan | What's not to like - "free" labor and more exposure. What are the downsides? |
| 14:10 | tclarke | the downsides: |
| 14:10 | kstreith | not really any |
| 14:10 | gmartin_cn | Well, except for coming up with appropriate tasks.. |
| 14:10 | tclarke | we need to provide a mentor which taps some resources, but minimal |
| 14:11 | gmartin_cn | Something that is self-contained enough to be done in 3 months |
| 14:11 | tclarke | if we don't have our act together, we can generate bad press |
| 14:11 | gmartin_cn | tclarke: exactly.. |
| 14:11 | tclarke | I see that as the main reason we skipped it this past summer |
| 14:11 | kstreith | true enough |
| 14:12 | rforehan | So we need a well-scoped task that can be completed in less than 3 months. |
| 14:12 | gmartin_cn | Keep something else in mind - the current contribution model (as necessitated by your legal folks) could cause Google some angst... |
| 14:12 | tclarke | I think we are much better positioned now...especially if the task is to create a plug-in with a specific function and doesn't require much or any core moficiations |
| 14:12 | kstreith | plus we didn't start thinking about it until too late |
| 14:12 | kstreith | the application occurs in early March |
| 14:12 | tclarke | google does not require the sponsors to use the contributed code |
| 14:12 | kstreith | so we still have the month of January and Feb to come up with the ideas that students would work on |
| 14:12 | tclarke | so I don't think they will get too bent out of shape about that |
| 14:13 | dsulgrov | has anyone identified the things that need to happen before it would begin? |
| 14:13 | gmartin_cn | tclarke: Sure, but bad press could follow (not to mention the intern feeling like they couldn't 'contribute' something if it doesn't get used) |
| 14:14 | tclarke | gmartic_cn: I agree to a degree...we would plan on using the code...my point is that if it took us some time to integrate with the main trunk I don't think it would be too much of a problem...especially if the intern had a way of distributing unofficially |
| 14:14 | tclarke | via COAN, for example |
| 14:15 | tclarke | dsulgrov: we have not generated an extensive list |
| 14:15 | tclarke | some info we don't have yet and won't until the applications open up |
| 14:15 | rforehan | Haven't we had summer interns before? Any lessions learned that would apply here? |
| 14:15 | kstreith | my thought is that we should put together a list of ideas that some could work on in 3 months or less |
| 14:15 | tclarke | but we need ideas and a mentor...as well as Ball approval if the mentor is a Ball employee |
| 14:15 | gmartin_cn | tclarke: Sure - COAN would work.. |
| 14:15 | kstreith | that way we have small ideas that any new contributor could take on |
| 14:16 | tclarke | I've set up a wiki page for some ideas |
| 14:16 | tclarke | https://opticks.balldayton.com/cometwiki/SummerOfCode2009 |
| 14:16 | kstreith | and it also helps us if we decide to apply for summer of code |
| 14:16 | kstreith | my point i guess, is that generating a list of ideas at this point doesn't really have a downside |
| 14:16 | tclarke | it's currently editable by people with accounts on the wiki only...it'll move to the front facing wiki once kstreith gets it set up (in progress) |
| 14:16 | kstreith | even if we decide at a later point to skip this year's summer of code |
| 14:17 | tclarke | as an aside (only partly open source applicable), Ball provides summer interns and such a list could double as an idea list for a Ball intern if necessary |
| 14:18 | tclarke | or for other community members looking to get more involved and are looking for ideas |
| 14:18 | tjohnson | It sounds like we have little to lose, so we should proceed with looking further into it and making preparations |
| 14:19 | tclarke | I agree |
| 14:19 | tclarke | anything more to say? |
| 14:19 | tclarke | if not, let's move on |
| 14:19 | tclarke | ok, next item |
| 14:19 | tclarke | removal of subversion sandboxes and reinstatement of commit emails |
| 14:20 | tclarke | we've had the /sandbox portion of subversion for a while |
| 14:20 | tclarke | it's restricted to core committers and is intended for a few things: |
| 14:20 | kstreith | by restricted he means only visible to core committers |
| 14:20 | tclarke | development of long term branches that will span multiple releases |
| 14:21 | tclarke | development of branches by ball personal which have not received ITAR release approval |
| 14:21 | tclarke | with the possible extension to non-ball personal....this has not happened yet |
| 14:21 | tclarke | and storage of branches from /branches which were not included in a rollup |
| 14:22 | tclarke | the first couple of scenarios can be met either by working entirely in a working copy (no intermediate checkins until includion in a release) |
| 14:22 | tclarke | or by using a distributed VCS to create a local branch...this works with SVK, Mercurial, and Git (probably with others, but these are the systems we have tested) |
| 14:23 | tclarke | the third item (moving from /branches) would need to be addressed some other way |
| 14:23 | kstreith | by we he means tclarke and kstreith |
| 14:23 | tclarke | if we got rid of the sandbox, we could re-enable the commit email list |
| 14:23 | tclarke | which sends an email whenever there is a commit to the repo |
| 14:24 | tclarke | it also simplifies the permission scheme in subversion |
| 14:24 | tclarke | thoughts? |
| 14:24 | kstreith | tclarke is suggesting that we no longer have a "hidden" sandbox |
| 14:24 | kstreith | and that if we still want one, it should be "public" just the same as trunk or branches |
| 14:25 | mconsidi | I'm ok with that. |
| 14:25 | dsulgrov | how much do the current committers use the sandbox? |
| 14:26 | rforehan | I've been using the sandbox for IR&D development - I need to move that code before the box goes public. |
| 14:26 | tjohnson | I make moderate use of it |
| 14:26 | kstreith | rforehan: we wouldn't make the existing sandbox public |
| 14:26 | tclarke | as a follow up, could current uses be moved to a public sandbox or local branches? |
| 14:26 | kstreith | we would just stop using it and svn delete it from the HEAD revision |
| 14:27 | tjohnson | For instance I have a current branch in it with upgrades to the Subject/Observer code |
| 14:27 | kstreith | it would remain in the repo for historical purposes and would remain hidden |
| 14:27 | tclarke | we would set /sanbox to read-only for core committers and r/w for admin only |
| 14:27 | tclarke | and eventually delete it from the current subversion version |
| 14:28 | tjohnson | the primary purpose of it was to allow branches to be worked on before getting Ball ITAR approval |
| 14:28 | tclarke | correct |
| 14:28 | tjohnson | is this no longer an issue - i.e. is Ball sufficiently responsive? |
| 14:28 | tclarke | correct |
| 14:28 | tclarke | but this does not happen very often |
| 14:29 | kstreith | and as tclarke stated, you can leave the changes on your local computer, i.e. your working copy |
| 14:29 | tclarke | these days, we don't move to implementing until there's itar approval except in a few rare cases |
| 14:29 | dsulgrov | does the benefit of having the sandbox outweigh the benefit of having a commit mailing list? |
| 14:29 | tclarke | when there's a day or two delay, most of us start work in a working copy and just don't commit until there's approcal |
| 14:29 | kstreith | or you can use a distributed version control system to interface with subversion and still work it on your computer while maintaining version history just on your local computer |
| 14:30 | tjohnson | I have never used a distributed VCS, so I don't know what's involved |
| 14:30 | tclarke | dsulgrov: that's part of it...the commit email list is just part of the problem...it also restricts who can admin the server from collabnet's end...we could possibly relax that in the future w/o a restricted area |
| 14:30 | tclarke | svk is pretty easy to use |
| 14:31 | tclarke | you run a couple of commands to create a mirror |
| 14:31 | rforehan | Are you looking at just the open source repo? |
| 14:31 | tclarke | the creation of a branch, checkout, etc. commands are the same as subversion |
| 14:31 | kstreith | rforehan: yes |
| 14:31 | tclarke | in fact, svk usees subversion for storing the mirror so you can point Tortoise at the local repo |
| 14:31 | tclarke | and just use svk for updating the mirror |
| 14:32 | kstreith | we can defer a decision until next IRC meeting |
| 14:32 | tclarke | yes |
| 14:32 | kstreith | i just think trevor wanted to get the ball rolling in this meeting |
| 14:32 | tclarke | this is just to get people thinking about it and start a discussion |
| 14:32 | kstreith | and get people thinking about the problem |
| 14:32 | tjohnson | I'll try to give SVK a look before then |
| 14:32 | tjohnson | It sounds like there is no schedule driver on this |
| 14:32 | tclarke | let's stop discussion now...I'll post a summary to dev@opticks along with a little info on options |
| 14:33 | tclarke | we'll make a descision at the next meeting or even one after that if people need more time |
| 14:33 | tclarke | anything further? |
| 14:33 | kstreith | tjohnson: correct, there is no pressing schedule driver on this issue |
| 14:34 | tclarke | ok, let's move on...I'll take an action item to post more info on git, mercurial, and svk to the mailing list |
| 14:34 | tclarke | the next item is a discussion and vote...so this is the last chance to mark attendance if you have not already done so |
| 14:34 | tclarke | any late arrivals? |
| 14:35 | tclarke | ok, this is a follow up to the last meeting's discussion about new features |
| 14:35 | tclarke | to summarize, should new features (and their api/functionality changes) always be discussed on dev@opticks or should we assume people ready JIRA and only discuss when further information is needed |
| 14:35 | tclarke | before we resume discussion |
| 14:36 | tclarke | I'll try and summarize the points on both sides |
| 14:36 | tclarke | discussion of all features on the mailing list can take extra time and drives up traffic on the email list possibly causing poeple to ignore the list more often |
| 14:37 | tclarke | not everyone is on IRC all the time and does not always check JIRA (mailing list acts as a "push" of information) |
| 14:37 | tclarke | I'll remind people that JIRA has RSS feed support so you can subscribe to specific filters and issues and you can add yourself to a watch list for issues |
| 14:37 | tclarke | which sends an email whenever that issue changes |
| 14:38 | tclarke | both of which generate data pushes (RSS is technically a pull but most readers automatically poll at regular intervals) |
| 14:38 | tclarke | the downside to inadequate discussion are obvious I believe |
| 14:38 | tclarke | lets open up to further discussion |
| 14:39 | kstreith | ok, i think we should push all discussion of new features to the mailing list |
| 14:39 | kstreith | here's why |
| 14:39 | gmartin_cn | Open Source communities (like the linux kernel) rely on open and transparent communications - generally the most expedient is the email list - some folks still won't use RSS (even though that is a better method, IMHO)... but discussion has to happen somewhere like an email list.. - maybe short announcements on the mailing list |
| 14:39 | tjohnson | Last week there were only 11 messages on the mailing list - that doesn't seem like enough to drive people away |
| 14:40 | kstreith | during 4.3.X development is the time when committers will be the most open to suggestions by others |
| 14:40 | kstreith | because we know if somebody says, you shouldn't have called this method that name |
| 14:40 | kstreith | we might listen and change it during a code review |
| 14:41 | kstreith | but we won't change it after 4.3.0 went into binary lockdown |
| 14:41 | kstreith | regardless of the right the reasons might be |
| 14:41 | kstreith | so, if we're opening to listening to feedback now |
| 14:41 | kstreith | we should be as "open" as possible |
| 14:42 | tclarke | here's my biggest concern with always posting: |
| 14:42 | kstreith | and I think the mailing list meets that criteria better than JIRA or RSS feeds |
| 14:42 | tclarke | it may discourage developers from duplicating/summarizing in the JIRA issue which is the problem location for design decisions, etc. |
| 14:42 | tclarke | I have a technical question for kstreith |
| 14:42 | kstreith | go ahead |
| 14:43 | tclarke | can JIRA be easily configured to email dev@opticks when new features more into certain states? (design review, code review, CCB review, etc?) |
| 14:43 | tclarke | obviously it would be for open issues (OPTICKS-????) only |
| 14:43 | tclarke | not OPTICKSPRIVATE |
| 14:44 | kstreith | possibly, with a little configuration |
| 14:44 | rforehan | tclarke: can't the e-mail thread be attached to the JIRA issue to maintain a log of discussions? |
| 14:44 | kstreith | tclarke: i think putting the information in JIRA is just a discipline thing |
| 14:44 | tclarke | I'd suggest that we try and set it up to automatically send emails to the mailing list which should automate these mailings |
| 14:45 | tclarke | it also encourages people to look at the actual JIRA issue since the email is coming from JIRA |
| 14:45 | kstreith | rforehan: that would be possible as well |
| 14:45 | tclarke | the developer can then summary or attach as necessary |
| 14:45 | tclarke | to document reasoning |
| 14:45 | tclarke | thoughts? |
| 14:45 | kstreith | tclarke: the e-mails that come from JIRA won't have useful reply to's set |
| 14:46 | kstreith | so that may confuse more than it helps |
| 14:46 | tclarke | the email list serv |
| 14:46 | tclarke | will automatically change that |
| 14:46 | tclarke | to dev@opticks |
| 14:46 | dsulgrov | what's the primary purpose for sending info to the dev mailing list? |
| 14:46 | tclarke | to encourage review by non-core developers |
| 14:46 | dsulgrov | is it for information purposes or to invoke discussion on the issue? |
| 14:47 | tclarke | so they can feedback about the design |
| 14:47 | kstreith | what I stated earlier, "to get as much feedback from others as pssible" |
| 14:47 | gmartin_cn | dsulgrov: Should be both |
| 14:47 | dsulgrov | it seems like this has the potential to lengthen development time for any given issue |
| 14:47 | kstreith | let me attempt to summarize dsulgrov's concern |
| 14:48 | tclarke | yes...but not getting feeback can length long term maintainance |
| 14:48 | tclarke | lengthen that is |
| 14:48 | kstreith | his concern is that people will keep adding feedback without any realization of the time/effort they adding onto to finishing the task |
| 14:48 | tclarke | this is why I suggested automatic emails at points in the process where peer review occurs since this causes a delay anyway |
| 14:49 | kstreith | i think peer review is too late |
| 14:49 | tclarke | design review |
| 14:49 | tclarke | and peer review |
| 14:49 | rforehan | Object is to insure mod's meet needs and not to micromanage how code is written, right? |
| 14:49 | tclarke | there are 2 peer review stages |
| 14:49 | kstreith | my answer to dsulgrov is always, "meritocracy" |
| 14:49 | kstreith | http://www.merriam-webster.com/dictionary/meritocracy |
| 14:49 | gmartin_cn | dsulgov: It comes down to this - if you guys want to run this project as an Open Source effort, you have to put up with some perceived 'inefficiencies' introduced by the transparency brought on by the Open Source methodology - usually it is up to the group of core committers to 'moderate' the amount of discussion and make a decision at some point - think 'benevolent dictator' like the Linus Torvalds on the kernel list. |
| 14:50 | gmartin_cn | And meritocracy as kstreith points out... |
| 14:50 | kstreith | exactly, at some point we are allowed to say, we're writing the code, thanks for the input, here is the decision i'm making and i'm now moving forward |
| 14:50 | gmartin_cn | But even in the most perfect of communities, sometimes the leaders have to put a stake in the ground and move on |
| 14:51 | gmartin_cn | But that doesn't mean that healthy and open discussion shouldn't happen.. |
| 14:51 | kstreith | precisely |
| 14:51 | tjohnson | Having been at the nexus of one such discussion (the animation toolbar upgrades discussion), I can attest to the fact that discussing it on the dev list certainly added to the time before code was being written, but the result was much, much better for it. The animation toolbar was a source of constant complaint and the upgrades silenced that almost completely. The feedback was essential. |
| 14:51 | gmartin_cn | yup... |
| 14:51 | kstreith | and i will agree that for what is percieved to be really simple 1 line changes |
| 14:52 | tclarke | remember, there are 3 types of issues we track....bugs, enhancements (minor extensions/features) and full blown features |
| 14:52 | tclarke | we need to clarify which we are talking about if we decide to always post to the list |
| 14:52 | kstreith | we can simply post to the mailing as informational |
| 14:53 | kstreith | and wait until someone else turns it into a discussion |
| 14:53 | kstreith | not every feature needs to be posted to the mailing as a question on how to proceed, only the complicated stuff needs to be presented that |
| 14:53 | gmartin_cn | kstreith: That's generally how it works in the rest of the OSS world |
| 14:53 | gmartin_cn | Correct |
| 14:53 | tclarke | I don't think is a question of whether we should solicit discussion on some issues...the question is if the developer should decide which need discussion on the mailing list and which are trivial |
| 14:54 | gmartin_cn | yes, exactly |
| 14:54 | tclarke | my problem is with automatically posting all issues |
| 14:54 | kstreith | i say the core developer cannot make that distinction |
| 14:54 | kstreith | so everything should go out |
| 14:54 | tclarke | not with posting issues that the developer feels need discussion |
| 14:54 | kstreith | by, everything I really do mean everything |
| 14:54 | tclarke | I think that posting everything when only 10% will have discussion is a problem |
| 14:55 | kstreith | the reason i say the core developer can't make the distiction, is because they don't have thousands of lines of plug-in developer code at their desk |
| 14:55 | tclarke | because it causes people to ignore most of the mailings |
| 14:55 | tclarke | there's too much noise |
| 14:55 | goffena | at what point do you start seeking input via the mailing list? |
| 14:55 | gmartin_cn | If if gets to be too much email, the possibility always exists that you do 'sub-communities' of interest... |
| 14:55 | tclarke | we've seen this sort of behavior in the past |
| 14:55 | tclarke | were people tune out new threads |
| 14:55 | kstreith | which is why I would argue that we can batch together stuff that is simple into 1 e-mail instead of 15 e-mails |
| 14:55 | goffena | have you already discussed on irc with core developers and a few definite stakeholders from the development community? |
| 14:55 | tclarke | because they don't want to take the time to review something they won't likely care about |
| 14:56 | kstreith | so I'd rather not have JIRA auto send e-mails |
| 14:56 | tclarke | I'd prefer to have that decision made by community members who actually care enough to review everything |
| 14:56 | tclarke | which is why I'd rather have them visit or RSS JIRA |
| 14:56 | kstreith | goffena: we don't have a good rule of thumb at the moment, that's what this discussion is trying to get at |
| 14:56 | tclarke | so we don't alienate the casual email list users |
| 14:57 | tclarke | or even have a bot auto-post changes to IRC |
| 14:57 | kstreith | ok, to be clear i'm only suggesting we do this type of posting during heavy new feature development, i.e. something like 4.3.X |
| 14:58 | tclarke | but that's a filter |
| 14:58 | gmartin_cn | Is there a possibility you might split the dev list into 'core' and 'plugin'? Would that help alleviate some of the perceived 'noise? |
| 14:58 | kstreith | if we are in bug fix mode, i'm ok with the other model, which says go check jira and we'll only post if it's really important and interesting |
| 14:58 | tclarke | what about trivial bug fixes that happen during that time...you wouldn't post about the same fix during 4.3.1 then? |
| 14:58 | tjohnson | E-mail is ubiquitous. IRC and RSS are not. The e-mail is your broadcast. |
| 14:58 | tclarke | you're now setting the filter you indicated you didn't want to set |
| 14:58 | tclarke | there are still interface changes, etc. in the "off" times, they just preserve binary compat |
| 14:59 | tclarke | I think the real problem seems to be the scope of dev@opticks |
| 14:59 | tclarke | is it there to encourage questions, etc. from plug-in developers? |
| 14:59 | tclarke | or to facilitate core development |
| 15:00 | kstreith | keep going, i'm interested |
| 15:00 | tclarke | we've been using it for both, but I'm not convinced that's what it should be |
| 15:00 | tjohnson | why is this an either/or? |
| 15:00 | kstreith | we have been using it for both |
| 15:00 | gmartin_cn | Good point tclarke.. I'm interested too... (since I suggested a split along some lines) |
| 15:00 | tclarke | since the "causual" plug-in developers will be turned off by core development discussion (including discussion of all new features) |
| 15:00 | kstreith | and my thought has always been that we would split it once traffic levels dictated it |
| 15:01 | tclarke | and core and plug-in developers who are more invested would care about the "chaff" |
| 15:01 | tclarke | I was suggesting making the split via email/RSS |
| 15:01 | kstreith | ok |
| 15:01 | tclarke | but perhaps two emal lists would better serve |
| 15:01 | kstreith | i will say that even if we split the list into two, for this cycle in particular, i would push to move the traffic onto the plug-in dev oriented on |
| 15:02 | tclarke | I'd love all people on dev@opticks to read these designs (as individual posts or digests) |
| 15:02 | gmartin_cn | Have there actually been complaints about the signal to noise ratio, or is that just a perceived issue? |
| 15:02 | tclarke | but a lot of developers don't even read the release notes |
| 15:02 | kstreith | because i'm trying to engage our current plug-in devs to become interested |
| 15:02 | tclarke | how can you expect them not to tune out all that stuff they will likely see as not interesting |
| 15:02 | tclarke | gmartin_cn: not direct complaints |
| 15:02 | kstreith | gmartin_cn: i have not heard of complaints, can't speak for others |
| 15:03 | tclarke | I have talked to developers about issues posted to the mailing list |
| 15:03 | tjohnson | are you expecting a vast increase in the level of traffic? The last three weeks were 11, 29 and 9 e-mails respectively on the dev list. |
| 15:03 | tclarke | and they have told me.."Oh, I stopped paying attention to that" |
| 15:03 | tclarke | tjohnson: it's not so much the absolute volume, it's the s/n |
| 15:04 | tclarke | I realize it's kind of stupid to not read a half dozen or so emails a week, but people do it |
| 15:04 | kstreith | alright, let |
| 15:04 | tclarke | maybe the solution is to chalk those people up as hopeless when it comes to reading emails |
| 15:04 | tjohnson | perhaps we could do something to better mark the threads of discussion? |
| 15:05 | tclarke | that was part of what I was hoping to get out of JIRA auto-emails |
| 15:05 | kstreith | my suggestion is we title all 4.3.X messages as such |
| 15:06 | kstreith | i think part of the problem is that core committers don't think we will get any feedback |
| 15:06 | kstreith | but that's NOT a reason to not engage others |
| 15:06 | kstreith | you'll never get feedback if you don't create an environment for feedback |
| 15:07 | kstreith | ya know, "build it and they will come" |
| 15:07 | tclarke | ok, sounds like we need a couple of votes |
| 15:07 | tclarke | first: should we push info about all features |
| 15:07 | tclarke | second: what is the delimiter re: when to stop...is it a dev line delimiter? or a JIRA issue type delimiter |
| 15:08 | kstreith | plus there is benefit to posting and people just reading, but not responding |
| 15:08 | tclarke | third: what method should we use to push (automatic JIRA email, manual emails, or digest emails?) |
| 15:08 | kstreith | now they are aware and can plan ahead for their plug-in development |
| 15:08 | kstreith | and they might start to get excited about the next release before it even comes out |
| 15:08 | tclarke | do those should like the main questions we are trying to answer? |
| 15:09 | rforehan | What's the scope? every chance in code, enhancements, added features, etc? |
| 15:09 | rforehan | chance->change |
| 15:09 | kstreith | i'd like to get more dicussion from others before we push for a vote |
| 15:09 | tclarke | that's question the second |
| 15:10 | tclarke | I'm suggesting we have the first vote...depending on the outcome, we may not need further discussion |
| 15:10 | tclarke | unless people feel the second two questions will strongly impact their vote for the first |
| 15:11 | kstreith | ok, let's vote on the first question |
| 15:11 | kstreith | just to see where everyone is |
| 15:11 | tclarke | the vote is: "Should core developers push info about new feature development (defn of new feature will be the second vote) to an email list?" |
| 15:11 | tclarke | please vote +1/-1 or present |
| 15:12 | kstreith | +1 |
| 15:12 | tclarke | +1 |
| 15:12 | raevans | +1 |
| 15:12 | tjohnson | +1 |
| 15:12 | gmartin_cn | +0 (present) |
| 15:12 | mconsidi | +1 |
| 15:12 | goffena | +1 |
| 15:12 | rforehan | +1 |
| 15:12 | tclarke | ok, that's enough to procede |
| 15:12 | dsulgrov | +1 |
| 15:12 | tclarke | now, what does feature mean.... |
| 15:13 | tclarke | all JIRA issues? just certain types (feature, enhancement, bug)? Just certain times in the dev cycle? |
| 15:13 | tclarke | this is for required/automatic postings |
| 15:13 | tclarke | you can always manually post about any jira issue |
| 15:14 | tclarke | I think only features should be required but at anytime in development...the other two have a very focused nature |
| 15:14 | tclarke | any perceived problems are already being discussed by developers on those two types |
| 15:14 | kstreith | i think for this 2 month dev cycle, it should be everything |
| 15:14 | tclarke | I think that would cut down the s/n and push only the major impact issues |
| 15:14 | kstreith | an 2 month experiment, we'll call it |
| 15:15 | tjohnson | "Major" is in the eye of the beholder. I would suggest all enhancements and new features. |
| 15:15 | kstreith | and after that, we should talk about the benefits of that approach and what we should do after that |
| 15:15 | tclarke | I would argue that anything needing that much design feedback should be a feature |
| 15:15 | tclarke | if it's an enhancement and has that much impact, it's mis-classified |
| 15:15 | dsulgrov | wait |
| 15:15 | dsulgrov | are we talking about only issues that need design feedback? |
| 15:16 | tclarke | I'm talking about anything marked as "Feature" in JIRA |
| 15:16 | dsulgrov | there are a number of enhancements that do not require design feedback (e.g. OPTICKS-294) |
| 15:16 | tclarke | kstreith is talking about any change made to the core |
| 15:16 | kstreith | alright, let's get to concerte examples |
| 15:16 | rforehan | "Major" is a relative term - look at how long some posts are just on the location or caption of a GUI button. |
| 15:16 | kstreith | tclarke: correct |
| 15:16 | kstreith | we might want to change the name of an enum because it conflicts with Hdf |
| 15:16 | tclarke | if we will require that much design and feedback on all issues, we should get rid of the Enhancement category |
| 15:17 | kstreith | that seems easy, no need to talk to anyone about that |
| 15:17 | kstreith | except that we pick a name that conflicts with another plug-in dev that they use 1000 places |
| 15:17 | kstreith | oops |
| 15:17 | tclarke | I say we can only go so far |
| 15:17 | kstreith | that's my point, we can't know what is "major" |
| 15:17 | tclarke | we should be namespacing but we are not...but plug-in devs should also be namespacing |
| 15:17 | kstreith | but that seems simple, so put it an single e-mail that mentions 10 other things |
| 15:18 | tclarke | we can only account for our own past design mistakes, not theirs |
| 15:18 | tclarke | I think that's even worse than individual emails |
| 15:18 | kstreith | except maybe the conflict isn't in their code |
| 15:18 | tclarke | people are even more likely to miss it |
| 15:18 | kstreith | maybe it's in a external module they are using |
| 15:18 | tclarke | ok, so our design should add a namespace |
| 15:18 | kstreith | so on and so on |
| 15:19 | kstreith | i'm just asking that we try this approach for this dev cycle and this cycle only |
| 15:19 | tclarke | if we are not able to /allowed to make a decision on the "size" of the feature, we should not have enhancements |
| 15:19 | kstreith | after that we can hold a lessons learned on the mailing list |
| 15:19 | kstreith | and see what everyone thinks |
| 15:19 | tclarke | which is ok if we decide that, but lets remove the option |
| 15:20 | kstreith | tclarke: as time moves forward, i've been thinking the same thing |
| 15:20 | tclarke | also, your earlier response re: only making this mandatory during trunk/future dev (although you may have changed your mind by now) |
| 15:21 | tclarke | is that we can't limit it to just that time by your argument that we don't know when the impact is high |
| 15:21 | kstreith | ok, i've simplified my request |
| 15:21 | kstreith | if it goes into trunk/future can we always talk about it on the mailing list, until we create trunk/4.3.0? |
| 15:22 | kstreith | after that, we'll talk about the whole experiment in another IRC meeting |
| 15:22 | kstreith | and decide whether it was good, bad, etc. |
| 15:22 | dsulgrov | including bugs? |
| 15:22 | kstreith | correct |
| 15:22 | kstreith | if the code gets commited to trunk/future, then talk about it on the mailing list |
| 15:23 | tclarke | no...if you want to always talk about it, it should be always not just during future...that doesn't mean we can't re-evaluate later but the rule should always hold until repealed |
| 15:23 | tclarke | if you want to set the revist to 4.3.1 timeline, that's fine |
| 15:23 | tclarke | the difference is how we think about what is imporant |
| 15:23 | tclarke | looks like we've got two main methods of deciding what to post: Every issue, only issues marked as Feature (both carry the possibility that Enhancement goes away as a type) |
| 15:24 | tclarke | I would like to conduct the vote on that question if everyone thinks they have enough information |
| 15:24 | dsulgrov | I am not in favor of removing Enhancement issues |
| 15:25 | tclarke | that's a separate question |
| 15:25 | tclarke | we can discuss the possibility of removing it later |
| 15:25 | kstreith | yeah, that's a discussion for next IRC meeting |
| 15:25 | kstreith | if you want to talk about that is |
| 15:26 | tclarke | the vote is: "Should we require discussion solicitation for all issues which will go into the trunk?" +1/-1/present A -1 will indicate only Features require discussions with the Enahncement question to follow at another meeting |
| 15:26 | tclarke | -1 |
| 15:26 | dsulgrov | I think we are trying to come to a resolution too fast because this has implications on how development occurs |
| 15:26 | *** | goffena (i=0cbc9d81@gateway/web/ajax/mibbit.com/x-11951dec07d2ed75) has quit IRC [Read error: 104 (Connection reset by peer)] |
| 15:27 | tclarke | then vote present |
| 15:27 | tclarke | if there's not a quorum the question will be tabled |
| 15:27 | kstreith | +1, but I don't think that suprises anyone |
| 15:27 | raevans | -1 |
| 15:27 | tjohnson | present |
| 15:27 | rforehan | present |
| 15:27 | dsulgrov | -1 |
| 15:27 | mconsidi | present |
| 15:28 | tclarke | I think we are missing two votes...they will be abstentions if left blank |
| 15:28 | kstreith | correct, missing goffena and gmartin_cn |
| 15:28 | tclarke | looks like goffena dropped |
| 15:29 | gmartin_cn | +0 |
| 15:29 | gmartin_cn | Sorry.. |
| 15:29 | tclarke | I'll wait a minute for him to return |
| 15:29 | tclarke | so far it looks like there's no quorum |
| 15:29 | tclarke | ok, I'll assume goffena is not returning right now and his vote will be a +0 |
| 15:30 | tclarke | there's not a quorum so we'll put this off for the next meeting...reply to the meeting minutes email with offline discussion |
| 15:30 | tclarke | or we can continue during the open discussion period if poeple want to continue now |
| 15:30 | tclarke | I don't want to drag on too long though |
| 15:31 | tclarke | ok...are there any other topics for discussion this week? |
| 15:31 | tclarke | ok, I'll put together the meeting minutes including the action item I have picked up |
| 15:32 | tclarke | we have decided to post all new "features" for discussion to the mailing list |
| 15:32 | tclarke | since we have not clarified the meaning, I'd suggest we including any new trunk/future discussions at least until the next meeting |
| 15:32 | *** | tjohnson (i=0cbc9d81@gateway/web/ajax/mibbit.com/x-c6b6c46ad705d946) has quit IRC ["http://www.mibbit.com ajax IRC Client"] |
| 15:32 | tclarke | we won't vote on that, I'll assume silence is agreement |
| 15:33 | dsulgrov | please clarify your statement |
| 15:33 | tclarke | any new development in trunk/future (new branches) between now and the next meeting should be brought up on the mailing list until we can hold a vote about relaxing this requirement |
| 15:35 | tclarke | do we want to schedule a special meeting later this week just to discuss/vote on this issue? |
| 15:35 | tclarke | or are we ok waiting two weeks? |
| 15:36 | tclarke | I don't want to push this meeting out any further but I also don't want to miss any discussion if the vote decides to discuss everything |
| 15:36 | tclarke | since we havn't voted on the second question, the above would be a suggestion to core developers |
| 15:37 | kstreith | if we don't have consensus, we might want to add a meeting in order to get consensus |
| 15:37 | tclarke | ok, I'll schedule something later this week |
| 15:37 | kstreith | i'd rather not have this hanging out there for 2 weeks |
| 15:37 | tclarke | any suggestions on times? |
| 15:38 | tclarke | how about wed afternoon...2:00 EST |
| 15:38 | tclarke | that gives us a couple of days to digest |
| 15:38 | tclarke | and we'll vote again just on this issue |
| 15:38 | kstreith | sounds good for me |
| 15:38 | tclarke | until then, things will continue as they have been |
| 15:39 | tclarke | ok...meeting will close in 1 minute |
| 15:39 | tclarke | ok, meeting is closed |
| *** | Closed channel log for #opticks at 12/15/2008 3:39:53 PM |