Hi.
On Mon, 4 Sep 2017 11:41:55 +0200, Emmanuel Bourg wrote:
Le 2/09/2017 à 00:50, Gilles a écrit :
Because of "Commons" rules, it is not "equivalent": There was
a long thread concluding that all modules must be released
_together_, and with the same top-level package name and version
number.
True, but I don't see this as an issue.
I see it as a fundamental one: Why should codes unrelated
by scope be artificially tied together by management rules
(such as design, supported language version, release schedule,
etc.)?[1]
I think that the unspecified problem(s) which you refer to
here are mostly alleviated with tools such as git and maven.
I mentioned the problems in a previous message in this thread.
Managing
the releases, the JIRA configurations, maintaining the sites... many
tasks can't be automated with tools, that's why I referred to the
multi-modules solution as "lightweight" compared to multiple
components.
That's how much our mileages vary; IMO, all those are mild
nuisances: the site is changed very rarely, JIRA configuration
is done once[2], but managing the releases becomes irremediably
difficult only when the scope of the component was not defined
correctly.[3]
Why do you "prefer" multi-module, independently of the subject
matters being talked about?
Please comment on my suggestion to create a single maven project
for the whole of "Commons". I'd agree that this suggestion is
ridiculous; yet some of you do the same proposal for "everything
math-related".
If you had been contributing to the math codes (plural), you
perhaps would have understood that it creates more management
problems than it solves.[4]
The former CM core team did not want to see nor even discuss
that aspect of development because there was a fairly strict
segregation between the various functionalities where each one
had a "master" (usually the initial contributor/committer) who
was informally weighing more when it came to modifying "his"
code.[5]
Again, I have to stress on what happened that led me to propose
a new "Commons RNG": obvious improvements to the CM code base
were outrightly rejected based on demonstrably false statements;
i.e. the objections were not technical but for the convenience
of one user.
Do you think that I enjoy contradicting you on these matters?
These discussions are a net loss of goodwill that would be
better used in creating useful codes.
My point is that I'm arguing on what has really happened, while
you still seem to deny that anything actually happened.
Again, please do what you want with modularizing CM and release
and support the code that will be the result.
My "strategic" (!) plan has been clearly stated:
1. "Commons Numbers",[6] then
2. "Commons Geometry", then
3. "Commons Math (legacy) v4.0
* modularized if people want to work on it, and
* without "unsupported" if allowed by the PMC
Does the majority of the PMC sees that proposal as a
constructive one?
Do some developers want to contribute time to implement
(parts of) that plan?
Do they want to implement another plan? What plan?
Without answering these simple questions, I think that we'd
keep going in circles.
Gilles
Emmanuel Bourg
[1] The rules are sensible once the scope has been determined
based on the desire of the implementing team, not the other
way around.
[2] And I never got the impression that we were creating too
much work for INFRA (how many new components per year do
we ask for?).
[3] As it has become of Common Math: the more it grew, the
more it was likely that not all contributors could agree
on a path forward, so that the majority "consensus" was on
staying put; which, in turn, put off contributors who
wanted to keep in sync with the language evolution.
[4] The fork is an actual proof of that.
[5] I don't deny that this can make sense since that person
is likely the most knowledgeable in that domain. But it
becomes a liability when the best design decisions are
_not_ the same for the different functionalities.
Modules are not an answer to this sort of problem.
[6] Followed by "Commons SigProc" (contributor's involvement
pending) since it depends on the "complex numbers".
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
