On Fri, Dec 1, 2017 at 6:56 PM, Gilles <gil...@harfang.homelinux.org> wrote:
> Hello Amey.
Hi Gilles,
>
>
> On Thu, 30 Nov 2017 23:45:45 +0530, Amey Jadiye wrote:
>
>> Pardon me for pulling this thread up again, I havent read anything about
>> "Commons Geometry" since long
>>
>
> Thanks for your renewed interest.
>
> (or may be I missed any other disscussion? ).
>>
>
> Probably not.
>
> is someone working on this ?
>>
>
> It would be a surprise.
>
> what is the final decision ?
>>
>
> There hasn't been any progress towards a decision.
>
I'm not sure if "Lazy Consensus" works in these matters ? better take help
of it, its fast and easy.
> There isn't even a consensus on one of the central tenets of
> Apache ("Those who do the work..."): how sad/strange (?).
>
> I'm having good
>> amount of time to spend on this now, appreciate If someone direct me to
>> correct disscussion thread
>>
>
> IIRC, the one below is where we left off...
>
> I think I can help here.
>>
>
> Thanks for the offer!
>
> It took me half hour to read all old mails but dont see final verdict,
>> though I was in favour with Maven modules but after reading all again I
>> think Gilles approch is more practicle here and If no one is working I can
>> submit something to review.
>>
>
> IMHO, the priority would be to review the status of "Numbers"
> (i.e. what is preventing a first release?).
>
Ok, If commons number is priority let me check that first, I will chime in
here after that release.
last numbers release I see on 22/4/17, and total open jiras are 18, what
are min expectation here ?
I will open another thread If want advise., let this thread alive for
o.a.c.geometry.
Regards,
Amey
> Best regards,
> Gilles
>
>
>
> Regards,
>> Amey
>>
>> On Wed, Sep 13, 2017 at 4:44 AM, Gilles <gil...@harfang.homelinux.org>
>> wrote:
>>
>> On Tue, 12 Sep 2017 13:07:24 +0200, Jochen Wiedmann wrote:
>>>
>>> On Sat, Sep 2, 2017 at 12:50 AM, Gilles <gil...@harfang.homelinux.org>
>>>> wrote:
>>>>
>>>> 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.
>>>>> It is very "maintainer(s)-unfriendly" because of the quite
>>>>> different subject matters that coexist in CM.
>>>>>
>>>>>
>>>> I wouldn't count that rule "*all* modules must be released" as a mantra:
>>>>
>>>>
>>> I found the idea attractive, but Stian (link to older discussion
>>> in a previous post) advised that maven would not easily "support"
>>> it.
>>>
>>> Has that changed since the discussion took place (10 months ago)?
>>>
>>> a) In case of an emergency release (fixing a CVE, for example), I'd
>>>
>>>> clearly consider pushing out the module as more important than waiting
>>>> for a full release. (Of course, one must be careful to maintain
>>>> compatibility when pushing out just a module, but that goes without
>>>> saying.)
>>>> b) I'd like to hear others experiences on that topic (maybe VFS).
>>>> Anyways, my personal experiences with Rat are clear: Releasing *all*
>>>> together is causing nothing but pain, and tends to defer releases
>>>> indefinitely. OTOH, releasing a submodule can be done at all times,
>>>> and without overly much preparation.
>>>>
>>>> In conclusion, I'd definitely support the release of a single
>>>> submodule, if the need would arise.
>>>>
>>>>
>>> How can one reconcile what you say here with what was said in
>>> that old thread?
>>>
>>> Would the PMC accept that a component contains independent modules
>>> (where "independent" means that each module can have its own version
>>> number, irrespective of the component's version)?
>>>
>>> Arguably (cf. thread referred to above), a "Commons" component
>>> should be simple enough that multiple versions are not necessary.
>>> [Chorus:] This is not the case with "Commons Math", hence separate
>>> components for independent contents (such as "Geometry", "RNG",
>>> "Numbers" and "SigProc") is the simplest solution.
>>>
>>> Gilles
>>>
>>> Jochen
>>>
>>>>
>>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
--
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
