Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: local policy)
Date: Fri, 29 Jul 2011 13:02:38 +0200
From: Gilles Sadowski <gilles@harfang.homelinux.org>
To: dev@commons.apache.org
Subject: Re: [math] Re: Release managing a major version [and Lang 3.0 post
 mortem]
Message-ID: <20110729110238.GR2590@dusk.harfang.homelinux.org>
Mail-Followup-To: dev@commons.apache.org
References: 
 <CAPVuaYuO=XhY8dKishu-aAeiP+GOWbxGCNNrSe+TUvYbBVQCUw@mail.gmail.com>
 <4E325D08.7050907@free.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <4E325D08.7050907@free.fr>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-DCC-scarlet.be-Metrics: sif 20001; Body=1 Fuz1=1 Fuz2=1
X-Virus-Scanned: clamav-milter 0.97.1-exp at sif
X-Virus-Status: Clean
X-Virus-Checked: Checked by ClamAV on apache.org

Hello.

> Hey guys, I guess we should have a thorough look at this process
> for our own 3.0 release.
> 
> We are clearly late and we have a huge pile of unsorted issues. Many
> people open more and more requests while we try to solve them, as
> can be seen from Jira activity in the last few months.
> 
> People start asking for 3.0 on the lists, and in fact many people
> asked me also off-list (and I guess this also happened to other
> developers).
> 
> What do you think ?

> Are we ready to stabilize ?

IMHO, no. 
For example, whole new packages have been added too recently to consider
that they are stable. Also old ones have been either modified back and forth
(e.g. moving exception classes) or should/could be renamed in order to
better reflect their purpose or contents (e.g. "optimization.general").

But that should not prevent a release! :-)

> Can we schedule
> issues for 3.0, 3.x or 4.0 ?

My preference is to resolve satisfactorily (or temporarily) older issues
first (e.g. the exceptions issue, of course...).
Then, outstanding bugs (e.g. in "RegulaFalsiSolver") should have top
priority.
The sorting based on "patch/no patch" proposed in the quoted mail is a good
idea.

> Can we solve issue faster than they are
> opened ?

;-)

Regards,
Gilles

> 
> Le 29/07/2011 00:06, Henri Yandell a �crit :
> >Or:
> >
> >"The Sisyphean task of shoving a large number of bytes up a big hill
> >while everyone else tries to add, remove and tweak said bytes".
> >
> >= Step 1: Identify the issues.
> >
> >Hopefully you are lucky and issues are accumulated in a JIRA, Bugzilla
> >or other issue tracker (here on JIRA as its our most common one). If
> >so - bonza. If not, then do your best to drive them to a single
> >location.
> >
> >* Look in your code for TODO items that are bigger than minuscule
> >notes and move them to JIRA.
> >* Add the taglist plugin (if in Maven) so you can still point to the
> >minuscule items. Configure it.
> >* Look for any documentation or text files with todo items. Drive them to JIRA.
> >
> >= Step 2: Triage the issues.
> >
> >Any "Unscheduled" issue is grounds for triage. Triage involves moving
> >an issue, possibly via conversation, to the following items:
> >
> >* Your current release target. Let's say 2.0.
> >* Subsequent release targets. In this case, 2.x.
> >* WONTFIX - ie) cast them back.
> >
> >Use common sense - an issue _only_ affecting the 1.x branch should
> >have its own maintenance triage process. Other resolutions are fine
> >(Duplicate, Invalid, Can't Reproduce etc).
> >
> >= Step 3: Start focusing on issues.
> >
> >Initially it's fine to leave a huge clump of issues in 2.0. You're
> >casting wildly around, random work is happening and it's unlikely that
> >anything will be in 2.x. This is the new-development state. Lots of
> >discussion around APIs and scope of the project.
> >
> >Your task is to keep things moving. Get things into the 2.0 list, plod
> >along working on just enough to keep the flywheel of interest going.
> >
> >= Step 4: Recognize when it's time to start focusing on the finish
> >
> >At some point you'll realize that the discussion is getting focused on
> >smaller details and not large issues. You'll also get users asking
> >when the release is coming. It's time to start winnowing down on the
> >remaining issues.
> >
> >Primarily this means moving issues from 2.0 to 2.x. Do this for issues
> >that won't require a major version change later on. Minor bugs and
> >features that lack patches are good examples. Indicate that you're
> >moving them due to the lack of a patch - "Moving to 2.x as no patch".
> >
> >It might mean making a 3.0 and moving issues there if they are a)
> >going to mean a major version release and b) there's no end in sight.
> >Obviously try to avoid that, but for wishlist items this is quite
> >likely. The reality is that if someone had the energy to implement the
> >wish, it would have happened.
> >
> >By doing this you should have a tight list of issues to be worked on.
> >All very believable if the time is but applied. You might have some
> >major issues for which a solution is not apparent, but you can't
> >imagine releasing without a fix for.
> >
> >= Step 5: Start driving for the finish
> >
> >Focus on your 2.0 list. Keep pushing things to 2.x as much as possible
> >(unless a patch is available of course) and drive conversation to the
> >mailing list in a priority order (where priority is severity of bug
> >and the resolve-risk - ie) not having a solution).
> >
> >Begin with your blocking issue with no solution. Get people talking
> >about it on the list. Don't be afraid to throw out half-arsed ideas.
> >Don't be afraid to nudge privately. Then start focusing on the
> >(hopefully) short list of other items.
> >
> >Start to discuss the possibility of release. Consider a beta, it'll
> >allow you to release without all the items fixed, but will start to
> >drive people to think and believe in a release. It'll also test the
> >release mechanics.
> >
> >Be increasingly defensive about new features or over-polishing.
> >
> >= Step 6: Release, sweet release
> >
> >Achieve goal. Conquer world etc.
> >
> >-------
> >
> >All of this is based on how Lang went (by and large). It does imply
> >that Lang went well; which it didn't imo. We took too long to accept
> >we should start a new major version [ie) JDK 5 is out, but it's not
> >standard so we won't even start]. We also treated it like a major
> >release, putting lots of features and bugfixes in as well as the non
> >backwards compatibile changes. Ideally we would have two versions, a
> >2.x branch and a 3.0 that launches quickly, and both have the same
> >bugfixes and features added to them.
> >
> >Niall did a great job of backporting from 3.0 to 2.5 and then to 2.6.
> >That covered up a problem which shouldn't have existed, ie) changes
> >should have gone into both. The problem there, which largely requires
> >sweat and elbow grease to surmount is that backwards incompatible
> >changes are more likely to lead to source control merge conflicts [a
> >wild claim, but one that feels likely to my gut]. Ideally you would
> >auto-sync the changes to 2.x over to the 3.0 branch, but that means
> >being able to migrate them. The package name change is easy, but
> >generics would make that pretty hard.
> >
> >What does this mean - it means we need to be working on 4.0 now (Java
> >7 compatible) while still developing the 3.x (Java 5 compatible)
> >branch. I think this should be easier to do; a search and replace on
> >'lang3' to 'lang4' and then attempt to auto-commit.
> >
> >Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org