geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Davanum Srinivas" <dava...@gmail.com>
Subject Re: How about a quick 1.1.1?
Date Tue, 23 May 2006 19:32:46 GMT
+1 from me.

On 5/23/06, Matt Hogstrom <matt@hogstrom.org> wrote:
> +1000
>
> Dain Sundstrom wrote:
> > How about we fix the actual show stoppers (only some of these blockers
> > are show stoppers) and ship what we got?  Then we just do a dot release
> > every few weeks as any additional things are fixed.  I think having more
> > regular (short) releases will be positive for the community and will
> > help to reduce our tendency to polish.  I know we all want to put out
> > the best software but there is a point at which this desire starts to
> > hurt us.
> >
> > -dain
> >
> > On May 23, 2006, at 9:33 AM, Matt Hogstrom wrote:
> >
> >> All,
> >>
> >> Here is what I would like to define as our closing set for 1.1
> >>
> >> * Restoration of Codehaus repos to get OEJB and TranQL up and running.
> >> * Complete testing of current performance fixes and commit them.
> >> * Close out SNAPSHOTs to final releases (depends partially on the above)
> >> * Complete the following JIRAs
> >>
> >> Key    Priority    Summary
> >> GERONIMO-1492    Blocker    Many "org/apache/geronimo" configIds still
> >> live in source tree
> >> GERONIMO-1849    Blocker    Attribute Manager broken WRT Reference
> >> GERONIMO-1860    Blocker    Tests of optional ConfigID components
> >> GERONIMO-1924    Blocker    Need to register the tomcat jndi url
> >> handler somehow
> >> GERONIMO-1960    Blocker    Bad GBean reference isn't caught during
> >> deployment
> >> GERONIMO-2006    Blocker    Deploying an application with an incorrect
> >> deployment plan results in non-functional admin console panel
> >> GERONIMO-2038    Blocker    assemblies\minimal-tomcat-server fails on
> >> windows due to file path length
> >> GERONIMO-2042    Blocker    ConfigurationAwareReference needs Serial
> >> Version UID
> >> GERONIMO-2049    Blocker    Jetty HTTPS edit shows no keystores in list
> >> GERONIMO-2050    Blocker    Unlocking a trust store still prompts for
> >> private key selection/password
> >> GERONIMO-2051    Blocker    Console Jetty HTTPS connector has wrong
> >> trust store help text
> >> GERONIMO-2052    Blocker    Dynamically added keystores never appear
> >> as unlocked
> >>
> >> * Ship Unstable build
> >>
> >> * Run CTS Testing
> >>
> >> * Let bake a few days for testing
> >>
> >> * Release 1.1
> >>
> >> This is how I'd like to finish this release.  Many of the above
> >> defects are assigned to Aaron. Aaron, if you can keep the ones you
> >> think you can handle over the next few days and unassign the rest.
> >> Everyone else can grab a JIRA or two and get them fixed and closed
> >> aggressively we can get this completed.
> >>
> >> Our original target for this release was April 28 and we're about a
> >> month behind.  I would very much like to ship this by next Wednesday
> >> (May 31) but perhaps Friday is more realistic.
> >>
> >> If you have some cycles all help is appreciated.
> >>
> >> Cheers,
> >>
> >> Matt
> >>
> >> Aaron Mulder wrote:
> >>> OK.  I'm well aware that I've assigned a large number of 1.1 issues to
> >>> myself.  Is there someone else I should assign them to?  And do you
> >>> have a list of the "other issues" that you feel need to be addressed
> >>> for the 1.1 release?
> >>> Thanks,
> >>>    Aaron
> >>> On 5/23/06, Matt Hogstrom <matt@hogstrom.org> wrote:
> >>>> I appreciate your concerns but as you noted there are a number of
> >>>> other bug fixes and blockers that
> >>>> *you* moved into the 1.1 stream that need to be addressed.  Null
> >>>> pointer exceptions, etc.  If we
> >>>> were in better shape on the usability front I would agree with you.
> >>>> There are so many of those I
> >>>> think focusing on fixing what we know is broken is the priority.
> >>>>
> >>>> -1 on new features unless the other issues are addressed.  I've been
> >>>> overly flexible on the release
> >>>> so far.  The release is going out this week or next.
> >>>>
> >>>> Thanks for your concern for the plugins but as release manager that
> >>>> is not my priority.  A stable
> >>>> working release is.
> >>>>
> >>>> Matt
> >>>>
> >>>> Aaron Mulder wrote:
> >>>> > I don't agree.  1.1 is not yet out the door, and if anything, it
> >>>> looks
> >>>> > like 1.2 will take longer than anticipated.  Minor changes,
> >>>> necessary,
> >>>> > I vote 1.1.  Remember, this change takes pressure off since we'll
be
> >>>> > able to release more features as plugins.  I'm strongly in favor
of
> >>>> > taking things out of the critical path, whereas deferring to 1.2
will
> >>>> > extend the critical path by another 3+ months.
> >>>> >
> >>>> > Thanks,
> >>>> >    Aaron
> >>>> >
> >>>> > On 5/22/06, Matt Hogstrom <matt@hogstrom.org> wrote:
> >>>> >> I agree that they are necessary.  Let's put them in 1.2.  1.1
is
> >>>> >> almost out the door and adding new
> >>>> >> features at this point is very late in the game.  We're currently
30
> >>>> >> days past our original date and
> >>>> >> almost 5 months past the 1.0 release.
> >>>> >>
> >>>> >> Please defer these till 1.2.
> >>>> >>
> >>>> >> Matt
> >>>> >>
> >>>> >> Aaron Mulder wrote:
> >>>> >> > We can call them what we want, but I think all the features
are
> >>>> >> > necessary, in particular in order to support plugins.
 The
> >>>> advantage
> >>>> >> > of adding the first two features is that they let us take
a lot of
> >>>> >> > other features *out* of the critical path, and release
them as
> >>>> plugins
> >>>> >> > (also letting us support non-ASL licensed providers).
> >>>> Basically, the
> >>>> >> > idea is to replace a properties file with a GBean, since
you can't
> >>>> >> > effectively add to a properties file at plugin installation
> >>>> time, but
> >>>> >> > you can certainly add GBeans.  Bottom line, it's a small
impact
> >>>> change
> >>>> >> > (console only, change the lookup logic that's already
> >>>> encapsulated in
> >>>> >> > a helper class to do a GBean interface query instead of
a
> >>>> properties
> >>>> >> > file load), and it has significant benefits (new JMS providers
or
> >>>> >> > security providers can be added at runtime via plugins
and do
> >>>> not need
> >>>> >> > to be hardcoded into the Geronimo distribution).
> >>>> >> >
> >>>> >> > Thanks,
> >>>> >> >    Aaron
> >>>> >> >
> >>>> >> > On 5/22/06, Matt Hogstrom <matt@hogstrom.org> wrote:
> >>>> >> >> Based on the list below I think 1,2 and 3 are new
function and
> >>>> 4 is a
> >>>> >> >> bug fix.
> >>>> >> >>
> >>>> >> >> Aaron Mulder wrote:
> >>>> >> >> > Here are the things that I still want to squeeze
into 1.1:
> >>>> >> >> > - fix console JMS to accept new providers at
runtime
> >>>> >> >> > - fix console security realms to accept new providers
at
> >>>> runtime
> >>>> >> >> > - add a missing Geronimo security provider to
console security
> >>>> >> realms
> >>>> >> >> > - fix hot deploy dir so it notices files updated
while the
> >>>> server
> >>>> >> was
> >>>> >> >> > down and deletes files if they are undeployed
some other way
> >>>> >> >> >
> >>>> >> >> > There are also AFAIK a number of not-yet-applied
patches to
> >>>> review.
> >>>> >> >>
> >>>> >> >> Yes, there are several.
> >>>> >> >>
> >>>> >> >> I'm testing some performance related code.  I'm waiting
and
> >>>> hoping
> >>>> >> >> Codehaus comes up soon :)
> >>>> >> >>
> >>>> >> >> >
> >>>> >> >> > Thanks,
> >>>> >> >> >    Aaron
> >>>> >> >> >
> >>>> >> >> >
> >>>> >> >> >
> >>>> >> >>
> >>>> >> >
> >>>> >> >
> >>>> >> >
> >>>> >>
> >>>> >
> >>>> >
> >>>> >
> >>>>
> >
> >
> >
> >
>


-- 
Davanum Srinivas : http://wso2.com/blogs/

Mime
View raw message