incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Burrell Donkin <robertburrelldon...@gmail.com>
Subject Re: [VOTE] Accept Aries proposal for incubation
Date Thu, 17 Sep 2009 16:52:19 GMT
On Wed, Sep 16, 2009 at 7:25 PM, Leo Simons <mail@leosimons.com> wrote:
> On Wed, Sep 16, 2009 at 1:09 PM, Jim Jagielski <jim@jagunet.com> wrote:
>> On Sep 16, 2009, at 4:32 AM, Niall Pemberton wrote:
>>> On Tue, Sep 15, 2009 at 11:43 PM, Niclas Hedhman <niclas@hedhman.org> wrote:
>>>> On Tue, Sep 15, 2009 at 9:07 PM, Jim Jagielski <jim@jagunet.com> wrote:
>>>>> After much thought, I am voting -1 for 1 main reason.
>>>>>
>>>>> 1: From the get-go, this appears headed towards an umbrella project.
>>>>>  Too many ways to justify "yeah, this belongs here" and far too
>>>>>  few ways to justify "nope, this doesn't quite fit in". So
>>>>>  whether TLP or part of Felix (as was the discussion), this appears
>>>>>  too comprehensive.
>>>>
>>>> This comment surprised me enough to read this proposal again, and I
>>>> have to agree with Jim. On one hand, the proposal starts out to speak
>>>> of "current and future EEG specifications", but then becomes very blur
>>>> of what that really means. Components, not solutions, not a server,
>>>> not a framework, but "components" could as Jim points out mean
>>>> everything (or at least anything one can stick in a Bundle in OSGi
>>>> lingo).
>>>>
>>>> Does it warrants a -1? Yes, I think it does. But considering how many
>>>> PMC members are on the roster, I doubt it will stop anything.
>>>>
>>>> -1 from me, until I see a limitation in scope that is "describable"...
>>>> I like the intent, but not the formulation. Look at your current
>>>> plans, distill the essence and put that in the proposal.
>>>
>>> IMO this is more a graduation issue, rather than something that should
>>> prevent entry to the incubator - since thats when destination is
>>> decided. There are many possible outcomes from that - perhaps some
>>> parts will go to felix and others to a new TLP(s) - but I say lets see
>>> how it works out during graduation rather than shooting it down now.
>>
>> I agree that the rubber hits the road when graduation, and when there
>> is a resolution before the board to make this a TLP. However, my
>> thoughts are that without this concern front-and-center from the get-go,
>> the podling runs the risk of hitting this roadblock right at the end,
>> at which point who knows how much impact this may have on it... In other
>> words, if a podling umbrella attempts to graduate into a TLP umbrella, it
>> will likely be shot down. Do we really want to wait until the end to
>> address this once and for all?
>
> I understand and subscribe to the concern.

+1

this is an entry proposal, not one for graduation

> However,
>
> 1) it sounds like most of the Aries folk are aware of the need to
> balance this kind of thing out a bit
> 2) not all umbrellas are all bad (some projects with pretty broad
> scopes and many subprojects AND healthy communities AND good oversight
> include geronimo, maven, felix, hadoop, commons, and others)

+1

the umbrella concerns were about community and oversight, and not
software architecture

the key question is not whether apache should host modular components
(we do this already) but whether aries has a tight enough focus to
work as a community

> 3) I think the main issue is the sweeping statements in the proposal
> which is typical of java framework land, but in practice I suspect the
> actual project focus is pretty narrow, people just don't really know
> how to express that yet
> 4) given #3, I suspect that as the project matures its scope
> definition is easier so that we'll see a nice and specific board
> resolution eventually

+1

but this is going to be one of the major graduation issues and
shouldn't be left to the end

> So I'm personally rather optimistic that things will work out ok, and
> so here's my +1 to the proposal.

i'm +1 on the proposal

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message