This is going to be a bit long, so please bear with me. It's important. I am supportive of a maintenance release to Exhibit 2.2.0 (what is currently deployed) where long standing bugs get fixed, libraries updated, etc., for those who feel they can't make a switch to 3.0 just yet. But this proposed alpha changes semantics and adds features. It is essentially a fork release. And forking releases sucks: parallel and divergent lines of development get very hard to reconcile, and they split focus and energy.
Even so, I'd be happy to take a look at a diff for between June and now to see what fixes could be incorporated into Exhibit 3.0. But I'm not going to take in changes to the configuration language or other material that almost certainly does not belong in the core of Exhibit at all. Your involvement with Exhibit at the research level is incredibly valuable, don't get me wrong there; I think it could be amazing to have a constant flow into the Exhibit community of fresh ideas emanating from your research group. At the same time, how that's been done to date is at direct odds with one of the cornerstones of making an open source project successful: gatekeeping for who can get commit access to the core trunk. When any of your students can get in to satisfy your group's requirements but others from the wider community need to actively demonstrate participation and core competency to receive the same, the overall quality of the project is rather more harmed than improved, and the community gets unhelpful signals about how exactly they're involved. Code that's been generated for research is almost never the same as code that's been tested and engineered for production, for many good reasons - but the difference is there nonetheless. Still, I do believe these competing interests both deserve their place in the project, and I think they can be reconciled. One of the reasons we moved to GitHub was to provide a better social model for working on Exhibit. With GitHub, everybody is working on their own personal fork for development, even the gatekeepers. It becomes the gatekeepers job to merge in any changes as submitted by contributors. This way, anybody can participate - subject to review. The best contributors then become gatekeepers themselves. Within this model, your students get the opportunity to both simply work on code and use it as a proving ground for promotion to gatekeeper, if that's at all their interest. Ideally, Exhibit 3.0 also makes it easier to write code for Exhibit without touching its core. I'm sure it could use some refinement with experience, but given that that's the direction we're moving in, your students could then write extensions to pursue their ideas, and your group serve them up as a sort of Exhibit research lab to the community, the best features and implementations being adopted into Exhibit over time. This release you propose conflates what is useful in a maintenance release with what your group's most recent research focus has been. I do not believe the two should be joined together in one release. The interim between the prior release and the next shows how little of a release process we currently have in place as a community, so I suppose it feels like fair game to just take individual initiative. There's a release proposal to the community coming up soon to address just that point. Nobody is going to force you to stop. But please don't issue a fork release. On 2012-01-24 23:21 , David Karger wrote: > This is to announce an alpha release of an update to the Exhibit 2 > codebase, one that I hope will eventually become Exhibit version 2.3. As > Exhibit 3 matures we aim to shift our developments efforts there, but > for the time being the greater maturity of E2 makes it a better testbed > for these updates. This release fixes a number of bugs and also offers > additional functionality; we'd like to see how that functionality gets > used in order to understand what is important to incorporate into E3. > > These changes are all live on > http://trunk.simile-widgets.org/exhibit/api, so all you need to do to > try them is link to that API instead of api.simile-widgets.org . Please > do so, and provide feedback on what is working and what isn't. > > Major changes include: > > * support for new import data formats including xml and html tables > * exhibit data can be embedded directly in html documents > * map view upgraded to use google maps v3 (gmaps key no longer required) > * map view renders icons locally (using canvas) instead of using painter > service > * a new extension supporting wysiwyg inline editing of data displayed in > any exhibit > > There are also several bug fixes. Details of these and other changes > can be found at http://people.csail.mit.edu/karger/Exhibit/alpha.html > -- You received this message because you are subscribed to the Google Groups "SIMILE Widgets" group. To post to this group, send email to simile-widgets@googlegroups.com. To unsubscribe from this group, send email to simile-widgets+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/simile-widgets?hl=en.
