Re: How about a quick 1.1.1?

[Donald Woods]

I like the idea, but think we need more discussion on it -

How long would we do 1.1.x releases - until 1.2 is released?




  - Could prereq version updates be made in 1.1.x?
  - Schema/plan changes would not be allowed in 1.1.x, right?

  - Would we run CTS to verify nothing has been broken?


-Donald


Dain Sundstrom wrote:

We would require each committer to update trunk as fixes were applied to 1.1.x, right? What criteria would be used to determine what could go into a 1.1.x vs. what should only go into trunk? - Configuration plans would be locked down (no splitting/renaming contents of configs\)?

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-1849    Blocker    Attribute Manager broken WRT Reference
GERONIMO-1860    Blocker    Tests of optional ConfigID components

GERONIMO-2049    Blocker    Jetty HTTPS edit shows no keystores in list


* Ship Unstable build

* Run CTS Testing

* Let bake a few days for testing

* Release 1.1





If you have some cycles all help is appreciated.

Cheers,

Matt

Aaron Mulder wrote:

GERONIMO-1492 Blocker Many "org/apache/geronimo" configIds still live in source tree 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-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 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.

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 <[EMAIL PROTECTED]> 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.


so far.  The release is going out this week or next.


working release is.

Matt

Aaron Mulder wrote:

> 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

> extend the critical path by another 3+ months.
>
> Thanks,
>    Aaron
>
> On 5/22/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote:
>> I agree that they are necessary.  Let's put them in 1.2.  1.1 is
>> almost out the door and adding new

>> 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

>> > file load), and it has significant benefits (new JMS  providers or

>> > to be hardcoded into the Geronimo distribution).
>> >
>> > Thanks,
>> >    Aaron
>> >
>> > On 5/22/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote:

>> >> 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

>> >> > - add a missing Geronimo security provider to console  security
>> realms

>> was
>> >> > down and deletes files if they are undeployed some other way
>> >> >

>> >>
>> >> Yes, there are several.
>> >>

>> >> Codehaus comes up soon :)
>> >>
>> >> >
>> >> > Thanks,
>> >> >    Aaron
>> >> >
>> >> >
>> >> >
>> >>
>> >
>> >
>> >
>>
>
>
>

-1 on new features unless the other issues are addressed. I've been overly flexible on the release Thanks for your concern for the plugins but as release manager that is not my priority. A stable > 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, > taking things out of the critical path, whereas deferring to 1.2 will >> features at this point is very late in the game. We're currently 30 >> > 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 >> > security providers can be added at runtime via plugins and do not need >> >> Based on the list below I think 1,2 and 3 are new function and 4 is a >> >> > - fix console security realms to accept new providers at runtime >> >> > - fix hot deploy dir so it notices files updated while the server >> >> > There are also AFAIK a number of not-yet-applied patches to review. >> >> I'm testing some performance related code. I'm waiting and hoping

smime.p7s
Description: S/MIME Cryptographic Signature