[kepler-dev] Bug and release procedure
berkley at nceas.ucsb.edu
Wed Apr 2 10:35:48 PDT 2008
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
> 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?
> 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
> For example, I need
> 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
> which is a version of
> 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
> 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.
More information about the Kepler-dev