On Wed, 12 Oct 2016 19:18:50 +0200, Jörg Schaible wrote:
On Wed, 12 Oct 2016 16:57:03 +0200, Emmanuel Bourg wrote:
Le 12/10/2016 à 16:15, Gilles a écrit :
The 3.x line is obsolete.
No new feature or bug-fix should be introduced there.
I understand you don't want to invest time in maintaining the 3.x
and I respect that, but others might be interested. I don't think
pushing minor bug fixes to CM 3 will undermine CM 4.
Work on 3.X did undermine CM4.
[The problem here is that you want me to be synthetic, but you
seem to have no clue about the history, thereby forcing me to
recollect facts from the past, because you don't believe my
synthetic statement above.]
So, what you say in substance is that you'd rather _wait_ for
someone to come by who will want to work with you on 3.x, rather
than continue with people, here and now, a work (CM4) that
started more than 3 years ago.
No, that's not what Emmanuel said, that's what you have implied. Your
is still valid to extract parts of the code base into own smaller
components. Once that components are created, we can deprecate the
code in the CM3 code base and have a release. That's what we should
our existing users.
IIRC, many PMC members did not "like" the idea of having more
Even less so if those components are being extracted from Commons
The least "problematic" one, Commons RNG, barely collected the
number of required votes for a release.
Has that changed?
Shall we request git repositories for the candidate components
which I suggested back in May?
You made it very clear that you have no intention to put any
effort into CM3. Fine. And most of us will agree that CM4 is dead.
does not prevent any other committer from maintaining the CM3 line
applying bug fixes or small improvements as long as binary
There is no sufficient manpower to work on both (cf. the backlog
of issues). [There wasn't before, and the situation did not
improve after the fork.]
Obviously some work was done.
It will be a waste for everyone if we split the already scarce
resources to work on the two lines, of which the 3.x line will
always be a "sub-Hipparchus".
Noone wastes *your* time ;-)
Let me assure you that plenty of my time has been wasted.
First and foremost because I continued the maintenance of
CM4 for months.
Then because I had to argue for salvaging some CM4 codes
(rather than simply "do it" as Apache would have it).
Of course, you can say that its my fault, and it is; that
I should not have tried to convince people, and should
have left, like others did.
In some areas/packages, code in the CM4 is still the same as
in 3.x. And there is no one left in Commons that would want
to significantly modify those areas, for which I have no qualms
if you maintain them in 3.x.
In areas where major changes were introduced in the development
branch, my proposal is still that we try to split them off CM
(see rationale in my posts sent in May).
Commits should be done either in the 3.x line or in master, but
This depends on the fact what code base you intent to extract for a
component. Fixing code that exists in CM3 as well as in CM4 and that
target for a new component is IMHO completely valid as long as the
component does not yet exist. It is not clear in any case whether
intention is to extract the code from CM3 or CM4,
Sorry, but CM4 is obviously the up-to-date code. See the log.
It would make no sense to "extract" anything from CM3.
[It should be ensured indeed that all fixes are consistently
applied to either the component, or the legacy code.]
but after all it should
contain the bug fix.
That's why I asked for a constructive discussion on "legacy code"
(CM3-compatible) vs "new components" (extracted from CM master).
Can we agree on a list of legacy packages (maintained in 3.x),
and a list of actively modified ones (worked on in master, in
view of releasing them as independent tools)?
This list is obvious when all extracted code is marked as deprecated.
A circular argument: Some decision must be made to start working,
and to deprecate codes.
As far as CM code is concerned, PMC members, even those who do
not contribute, should either support the creation of new
components), or propose alternatives (e.g. volunteer to
actively maintain CM3).
An attitude that amounts to block whatever work is being done
(in the way of not voting a release) does not qualify as
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org