GlassFish - World's first Java EE 7 Application Server


GlassFish Server Open Source Edition 3.1.1

How do I determine if I should fix my bugs in 3.1.1?

The following types of issues are good candidates to be fixed

  • Bugs that prevent product certification with JDK 7.
  • Bugs that prevent product certification with JRockit.
  • Required changes to make GlassFish run on AIX.
  • Impact product security
  • Represent a CTS failure
  • Is a regression of functionality or performance available in a prior release
  • Introduces an incompatibility
  • Likely to generate a customer support call
  • An in-your-face issue that will touch the majority of users
  • Issues that are directly reported by community or have been created from forum data.
  • Release noted bugs from 3.1

I may have identified a potential bug that I think should be fixed in 3.1.1. How do I get an approval for the fix?

Please use the following process to request approval to work on a bug fix:

1. Add the "3_1_1-review" tag to the issue.
2. Provide justification on why we should consider this for 3.1.1?. Your write up(no particular format) must include the answers to the following questions.

  • Why fix this issue in 3.1.1?
  • Which is the targeted build of 3.1.1 for this fix?
  • Do regression tests exist for this issue?
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

3. Send mail to scatari@java.net

Email Template 
To: scatari@java.net
Subject: 3.1.1 Change Request

Component Name: XXXXX
Issue: https://github.com/javaee/glassfish/issues/NNNNN

4. I will take this to the approving team for review after removing the 3_1_1-review tag.
4.1 If it is approved the 3_1_1-approved tag will be added to the issue. The Fix Version/s will be changed to the appropriate milestone with an "Approved" comment added to the issue.
4.2 If it is rejected the 3_1_1-exclude tag will be added to the issue. If the deferred issue is a candidate for the next update release then the 3_1_1-next tag will be added.
4.3 The decision(approved/rejected) will be emailed to the issue owner.

Who gets to decide on what goes into 3.1.1?

It is a collective decision by many(Developers, QA, Perf, Sustaining and other teams). Please look through the bugs, and let us know if you would like to address anything for 3.1.1, we will mark them appropriately and track them.

We are also in the process of scrubbing the current open bugs and will contact you if we need fixes for specific issues, but
don't wait for us to ping you, if you have already identified your list of bugs.

NOTE: We will have formal bugswat meetings after our MS2(05/05/2011).

How much time I have to fix issues?

P1-P3 bugs are allowed until 05/05/2011.(MS2).
P1-P2 bugs are allowed until 05/17/2011.(MS3).

Only stopper bugs are allowed after 05/17/2011(MS3).

Complete build schedule .

Can I add a new product feature in 3.1.1?

3.1.1 is an update release to 3.1, No new features are allowed to be checked in.

Code changes related to porting GlassFish 3.1.1 on AIX need not be tracked as bugs till 05/17. After 05/17, all changes must have an associated bug id.

What is the check-in procedure?

3.1.1 SVN Branching details:http://wikis.sun.com/display/GlassFish/3.1.1+Branch+Info

Please get the changes reviewed by your peer,and other module leads if it spreads across your module.

  • If the fix applies to 3.2(Which we assume will be for most of the fixes), then please make sure that you check-in in both 3.2(Trunk) and 3.1.1 branch. In JIRA, you can mark them as fixed in both "3.1.1_bXX and 3.2_bXX" numbers. Please contact Rajiv Mordani(mode@java.net) if you have any questions related to 3.2.
  • If the fix does not apply to 3.2, then please add the keyword "3_2-na" to the bug. Though we assume that all the bugs fixed in 3.1.1 apply automatically to 3.2, there may be cases where this will not be true.

NOTE: All the check-in records(SVN messages for both Trunk and 3.1.1 branch) should be copied in the bug tracking system within the data for relevant bug(s). If we don't see a check-in message for trunk, then that bug should have 3_2-na in the keyword.

I checked in a fix in Trunk after 3.1 FCS but before 04/04. How do I pull in the changes to 3.1.1 code base?

The 3.1.1 branch was created on 04/04/2011 from the trunk so it already contains the fixes done on the trunk during this time period. Just make sure that your fix is marked as fix integrated with appropriate fix in version including build numbers.

I checked in a fix in the Trunk between 04/04 and 04/13(3.1.1 MS1). How do I pull in the changes to 3.1.1 code base?

Please make sure that you also check-in your bug fix to the 3.1.1 branch(after going through the approval process) if it applies and mark the fixed in version field with appropriate values.

I fixed a bug in 3.2, not sure if this has to go into 3.1.1, what do I do?

Please contact me(scatari@java.net) and I will get you the answer.

I am working on a customer escalation, How do I get the fix checked into 3.1.1 workspace?

Please work with Manoj Kumar Malhotra(manojmalhotra@java.net), so that we can track the fix as part of 3.1.1 release.

Useful 3.1.1 Links

Schedule
Overall