I agree that in theory the processes should remain. But:

* there is no official list of such processes. I only know the ones I 
interacted with. (I remembered how hard I had to ask long ago to clarify how 
the release branching process works).

* they should be filtered anyhow based on Apache compatibility and/or replaced 
by existing Apache processes, plus

* these processes were not decided by the community at large, but were mostly 
an emanation of the core Sun/Oracle developer group. Which means that they are 
not necessarily a good fit for the new situation.

--emi

Pe 20 iun. 2017, la 12:03, Neil C Smith <[email protected]> a scris:

> 
>> On Tue, Jun 20, 2017 at 9:39 AM Emilian Bold <[email protected]> wrote:
>> I do. The previous API Review had some logic to it. I don't believe we
>> can do without it entirely.
> 
> Or at all!  I agree with much of what you suggest, but I'm interested to turn 
> that around - why do you believe things need to change now / what aspects are 
> not going to meet Apache compliance?
> 
> My point was that I don't see the point in changing processes that have 
> worked for the project for years right now, unless it's something where our 
> hand is forced.  Surely better to establish a regular review of processes 
> (quarterly, post-releases, ?) and then evolve things where need be?  IMO this 
> is the wrong time to be changing too much.
> 
> Best wishes,
> 
> Neil
> -- 
> Neil C Smith
> Artist & Technologist
> www.neilcsmith.net
> 
> Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org

Reply via email to