[kepler-dev] Bug and release procedure

[Christopher Brooks]

> Hi Chad, Christopher,
> 
> Am I correct in concluding that, for now, all development on the  
> Kepler RELEASE-BRANCH-1-0-0 should be done against the rel-7-0-beta-2  
> branch of ptII?

Yep, that's my view.

> Also, is rel-7-0-beta-2 currently moving or has it been finalized?   
> In other words, do we all need to periodically update our local  
> copies of rel-7-0-beta-2?

rel-7-0-beta-2 is moving.  I would update periodically.

I'm fixing minor problems in preparation for the release. 
- version numbers from 7.0.beta to 7.0.1
- Inserted pdfs from design doc
- Fixed problem with shorts in Expression language: ceil(1s) was
  failing
- Wireless Triangulation actor needed updating
- Don't prompt for a file name when the model name has spaces
- Removed files not shipping in 7.0.1
- Updates to GT
- Updates to backtracking

I think you would want many of these changes.  I'm fixing
bugs, not adding features.

I think rel-7-0-beta-2 will stop moving sometime
this week or next.

_C

> 
> Thanks,
> 
> Tim
> 
> On Apr 2, 2008, at 10:35 AM, Chad Berkley wrote:
> 
> > Hey Christopher,
> >
> > I just sent out an email with a bunch of info.  I'll answer your
> > questions that I didn't answer below.
> >
> > Christopher Brooks wrote:
> >> Sorry if this has been covered, but I have a couple of procedural
> >> questions:
> >>
> >> 1) What is the procedure for closing bugs?  On some projects,
> >> a developer fixes the bug and then assigns the bug to QA, who
> >> then verifies that the bug is fixed.  Are we doing this or
> >> are developers closing bugs?  Either way works for me.
> >
> > If the dev is reasonably sure that the bug is fixed, just close  
> > it.  If
> > you want a 2nd opinion, please ask for one.
> >
> >>
> >> 2) Is KEPLER_1_0_0_RC1 the release branch?
> >> I know there is an open bug to create a release branch, is this it?
> >
> > RELEASE-BRANCH-1-0-0
> >
> >>
> >> 3) What is the procedure for getting changes into the release branch?
> >> I'm fine with having only a few people checking things into the
> >> release branch.
> >
> > I'm encouraging anyone who's working on a bug targeted at 1.0.0 to  
> > check
> > in to the branch only.  Regular development work that will not go into
> > the release should be checked into the head.  In general, I'll be
> > monitoring the check-ins and making sure they meet the criteria for
> > branch checkins.
> >
> >>
> >> For example, I need
> >> kepler/configs/ptolemy/configs/kepler/configuration.xml
> >> updated in the release branch because it excludes CCodeGenerator
> >> from the classes that for which we search.
> >>
> >> Should we assign bugs that require changes in the release branch
> >> to someone in particular?
> >>
> >>
> >> Another change is that we should ship
> >> org/ecoinformatics/util/DBConnection-JDK1.6-Java
> >> which is a version of
> >> org/ecoinformatics/util/DBConnection.java
> >> that works with Java1.6.
> >>
> >> To use this do:
> >>
> >> cp org/ecoinformatics/util/DBConnection-JDK1.6-Java org/ 
> >> ecoinformatics/util/DBConnection.java
> >>
> >>
> >> 4) My plan is to ship Ptolemy II using the ptII rel-7-0-beta-2.
> >> I'm fairly close to being ready to ship.
> >
> > Great, let me know when it's done so I can start getting it into the
> > installer.
> >
> >>
> >> We could ship Kepler 1.0 with this branch or create another branch.
> >
> > As long as this one is stable and works with all of kepler's  
> > functions,
> > we can use it.  I don't really see a need for another one.
> >
> > chad
> > _______________________________________________
> > Kepler-dev mailing list
> > Kepler-dev at ecoinformatics.org
> > http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/ 
> > kepler-dev