pcplantdb

[Chad Knepp <pyg@galatea.org>]

Sounds good to me.

John Schinnerer writes:
 > Aloha,
 > 
 > Pecking away some more at roundup...
 > 
 > We need to be able to specify the build for a given bug.
 > I'm adding a build selection drop-down right now.  The list will be 
 > manually populated (by me) with new build identifiers as builds are 
 > released.
 > 
 > That means we need a system for naming our builds.  Maybe for 
 > formalizing them first...!
 > I leave this up to Chad and/or Rich, and anyone else who wants to chime in.

My preference (only vaguely attached) is to use an X.Y.Z scheme
(major.minor.build).  In my head we are working toward a 1.0.0
release, the current live version is 0.1.0, the current dev version is
0.1.5 or something, the next live version will be 0.2.0, and so on
until we are done and 1.0.0 becomes the live version.

I can do tagged releases from now on so that we can clearly reference
versions.

 > My chime in is...can we *please* get a cvs going somewhere for code?!?
 > That will help formalize builds/releases...yes?
 > Then we can use it for project docs as well.

Cvs is already setup on ibiblio.  I update the repository on ibiblio
about once a day when I'm working.  Anybody with an account on ibiblio
can checkout the latest from cvs with a 'cvs co eden' command.
Members of the piw group also have checkin permission.  The dataset
and sql updates is also in cvs under the name of 'eden_db'.

The docs could be included in the code repository or in a new and
seperate package.    

 > Anyhow...build designation ought to be consistent and easy to 
 > understand, and will be a text string in the DB.
 > I have control over the order of appearance in selection lists so it 
 > doesn't need to sort itself in correct order as a string.
 > 
 > Still pondering how to handle platform information.
 > Maybe just lumped in with the 'message' text (one field for description, 
 > steps to repro, actual & expected results....and maybe platform info too?).
 > 
 > Also - in general - there is a huge amount of flexibility in what/how 
 > tracker data is displayed.  Presentation choices are very cleanly 
 > separated from DB content (with so far only one glaring exception that I 
 > have dealt with OK afaik...:-o).
 > 
 > I keep thinking of more ways to tweak it...that will depend on what 
 > y'all want as users of it.
 > I am going to finish adding some of what I consider essential 
 > properties, and then point you all to it so we can start trial use.
 >  From there it can evolve some more as we start using it.
 > 
 > Layout and content of issue listings, issues, search form and so on are 
 > all templated (using TAL/METAL no less...yes, roundup can be installed 
 > as a zope product as well as a standalone app... :-) so as preferences 
 > emerge I can tweak those as desired independent of DB schema.
 > 
 > And, as mentioned, adding stuff to the schema (as I'm doing now) is 
 > pretty straighforward, at least for simple properties, and doesn't cause 
 > backward-compatibility issues.
 > New fields/lists just show up as empty/'no selection' in issues that 
 > pre-date their creation.
 > 
 > Probably no news tomorrow, will be in transit to visit relatives 
 > vacationing on Maui.  Taking my 'office' along though...
 > 
 > cheers,
 > John S.
 > 
 > -- 
 > 
 > John Schinnerer - MA, Whole Systems Design
 > ------------------------------------------
 > - Eco-Living -
 > Whole Systems Design Services
 > People - Place - Learning - Integration
 > john@eco-living.net
 > http://eco-living.net
 > _______________________________________________
 > pcplantdb mailing list
 > pcplantdb@lists.ibiblio.org
 > http://lists.ibiblio.org/mailman/listinfo/pcplantdb