(I promoted this to a new thread since I'd prefer that the release announcement threads stay tightly focused.)
Hi Ted, In addition to David's comments, some further thoughts: * Thank you! for your willingness to contribute to the sw. * I just glanced at the Exhibit tree and suggest a couple of things. (Of course, comments on these ideas are solicited and appreciated.) 1) Please create a CHANGES.txt and RELEASE_NOTES.txt file in root of the Exhibit tree. Changes.txt -- all the changes that you make, with the svn rev numbers. You can usually get the rev number by adding 1 to the rev number that you see when you do your svn update prior to your svn commit. (And if it turns out that someone else snuck in with a Wiki change in the meantime, just fix the rev number in the change file and commit it again.) Release_notes are for more important changes. I add to it as I make the revs, then review it before making a release. You can see both files in the Timeline tree. Commit messages: Please start them with the name of the project in caps. Add in the contents of the appropriate parts of the Changes file. 2) I think a big issue for the widgets is to have their libraries served by a generally available system. David and I are both pursuing this, but in the meantime we don't have it. I think the problem is that a lot of users are comfortable with creating an html page in a cook-book style fashion, but are not as comfortable hosting the libraries for their own use. My point is that testing is important and we, as maintainers, should make it as easy as possible for people to test the new revs and releases. That's why I added the two zip files as part of the Timeline build process. It wasn't hard to do (see the Timeline build.xml file) and it means that now Timeline users don't need to worry about svn for doing a download. If you agree with the above, then you may want to add Exhibit zip files to its build process. 3) To keep things organized, I suggest that you create example files (especially to exercise your changes) and data sets, along with instructions so maintainers can have the opportunity to run a script and see that they haven't broken anything. For Timeline, I started this with the new http://simile-widgets.googlecode.com/svn/timeline/trunk/src/webapp/examples/test_example/test.html file 4) Anytime you're fixing a bug, please make a trail for it by adding it to the Issue tracker, and referencing the Issue number in your Change file. 5) Very few people read the developers list that receive the checkin messages. So anytime you'd like people to pick up a new version for testing, please send a note to the main list (this one). 6) Please also update the wiki as you change things in the sw. Very important since most people don't know how to read the source--and they shouldn't have to. Regards, Larry ---------- Forwarded message ---------- From: David Huynh <[EMAIL PROTECTED]> Date: Sep 25, 2:00 pm Subject: Timeline v 2.2.0 released To: SIMILE Widgets Ted, There's no formal process for contributing fixes and releasing yet, but some good practices should be followed. Before checking in a relatively small change or sending in a small patch, I'd recommend testing against the examples in the code base, with both bundle=true and bundle=false. Test on Firefox, IE, and Safari (and Chrome?) if you have Windows, or Firefox and Safari if Mac. If you check in and then something breaks as noted by someone else, try to fix it as quickly as possible. We don't have a testing framework yet, so by "test" I meant just trying to play with the exhibit or timeline examples and see if anything breaks. Checking in a series of small changes is better than checking in a huge change in one shot. If you can't break a huge change into small ones because the change is quite fundamental, I'd suggest emailing this list before checking in just to give everyone a heads-up, or a chance to object the change and discuss it. As for releasing new versions, I think that should be voted by the community. If you branch, say for experimenting with a research idea, then you can do whatever you want with that branch. But when you're thinking about merging it back onto the trunk, then consider it a huge change. I've been told that branching is usually not a good idea, because too often the branch diverges significantly from the trunk, and merging it back is really hard. Of course, these practices that I just mentioned are also up for discussion. David Edward Benson wrote: > Larry (and/or David H), > Is the preferred method of contributing fixes to just check them into > the head of the repo and announced what you have done? (Following the > commit message advice you sent out previously, of course) > Or is there some more formal process of checking into a branch or > submitting a patch, etc. > I have a performance enhancement that I'd like to check in for > Exhibit. It prevents re-calculating facet labels for collapsed list > facets (lazily doing the re-calc when they are uncollapsed instead). > Thanks! > ted --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "SIMILE Widgets" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/simile-widgets?hl=en -~----------~----~----~----~------~----~------~--~---
