Glasgow - community? specs? other issues?

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Eelco Hillenius wrote:
>> I understand that there are some specific circumstances in this case,
>> but in general I believe this sort of criteria is why we get
>> complaints that it's impossible to "innovate" at Apache any more.  We
>> require all the grunt work of innovation to occur outside of Apache.

Well, the criticism I've seen was essentially, incubator folk make one
specific objection, committee 'huddles' to come up with the "right answer"
and keep presenting it through one person.  That's not the way ASF projects
operate.  So the effort was rightly criticized - although we don't really
expect everything to flow in an 'asf way' quite so early in the process.

Some folks have expressed concerns about community, etc; things I don't
think are so important entering the incubator - they are mandatory before
the effort would graduate, of course :)

>> The issues of an open specification is one thing.  But aren't "proven
>> an actual community" and "work the standard 'apache way'" graduation
>> requirements, not entry requirements?

Yes.  My concerns relate to the specification.  Some others voted -1 for
some other reasons that don't concern me nearly as much.

But some of the specs issues really have got to be worked out before one
peep of specs related suggestions pollute the minds of the developers in
their dev@ list.  I think I've finally clarified these sufficiently, please
correct me if I'm wrong.

And as far as the openness of the spec itself - this is, too, an issue.
I will continue voting -1 until we really determine that - unlike JCP -
we can have a no-NDA scenario with respect to TCKs etc.  And that,
unlike Oasis, the implementation is covered by the grants, not strictly
the spec.  And, ideally, that IP grants under the ASL will cover those
participating in the spec from future problems; that the spec itself will
not be entirely corp-based; and worse yet, that horridly offensive
language is modified in the project proposal/charter.

Yes - I totally understand that the contributors are coming at this from
an entirely corporate perspective, and I'm really not 'dissing' that.
One of the projects I mentor, stdcxx, started the same way.  I'm only
pointing out that we need to put the right foot forward before voting
this project up and in.  Missteps are expected and excusable :)

Finding a home before the collation of the willing says "hey!
here's a project!" would have been one alternative.  Spelling out where
they plan to land would be another viable alternative.  Leaving this in
limbo leaves some of us understandably wary.

Tweaking the language to sound less corporate, but leaving the ASF and
new project vulnerable to corporate dictatates is no more palatable than
the current language :)  I know your mentor totally understands what I
mean, so I don't doubt this can be corrected, through discussion -here-
on this list, the name question resolved, and the incubation accepted
unanimously.

You really had some great things to add, and I totally agree with you
we should consider adding those qualifications - after we are done
pondering the incubation of this new project.

Oh - and you replied on the primary vote thread - we really need to
focus the s/n ratio for the counters to track the outcome :)

Yours,

Bill


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

Re: Glasgow - community? specs? other issues?

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Eelco Hillenius wrote:
> [...]
> I did not write that actually. I'm sorry I hijacked the VOTE thread.
> It's one of the (hopefully) few things to get used to over at Apache,
> as at Wicket we aren't that formal about it.

First, I generally agreed with this (which was what you said in an earlier
post... my reply was

>Some folks have expressed concerns about community, etc; things I don't
>think are so important entering the incubator - they are mandatory before
>the effort would graduate, of course  :)

I think the rest of this post quotes your post of 0300gmt so I haven't
read it again - as I say I think they are good thoughts to be thunk after
we resolve immediate issues at hand, for incoming future projects.

But the hijaak comment wasn't directed at you - it's a bad habit here.  At
20+ posts a day, some days easily 50 posts, using decent message subjects
would be very productive.

I'm still waiting for any feedback on "specs?", but community doesn't seem
to be an insurmountable obstacle.


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

Re: Glasgow - community? specs? other issues?

[Eelco Hillenius <ee...@gmail.com>]

On 8/4/06, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> Eelco Hillenius wrote:
> >> I understand that there are some specific circumstances in this case,
> >> but in general I believe this sort of criteria is why we get
> >> complaints that it's impossible to "innovate" at Apache any more.  We
> >> require all the grunt work of innovation to occur outside of Apache.

I did not write that actually. I'm sorry I hijacked the VOTE thread.
It's one of the (hopefully) few things to get used to over at Apache,
as at Wicket we aren't that formal about it.

Here is the blurp that attracted my attention, followed by my thoughts:

> I understand that there are some specific circumstances in this case,
> but in general I believe this sort of criteria is why we get
> complaints that it's impossible to "innovate" at Apache any more.  We
> require all the grunt work of innovation to occur outside of Apache.
>
> The issues of an open specification is one thing.  But aren't "proven
> an actual community" and "work the standard 'apache way'" graduation
> requirements, not entry requirements?  If we expect something coming
> into the incubator to already have a fully functioning, health
> Apache-style community, then the only point of the Incubator is for
> handling licensing issues.

This is quite interesting...

Over at Wicket we have been operating 'the Apache way' from a very
early stage in the project (about two years). We have mail archives,
commit logs, releases, and history of letting new committers in to
prove all that if people are willing to spend an hour looking for it.
But we feel we have to prove ourselves all over again as the
incubation process expects it's podlings to prove themselves within
the confines of the incubation process.

The incubation process might benefit from having a categorization of
projects that want to enter. Such categorization basically answers:
* How old are these projects, how many committers, how large is the
community of developers and users?
* Has the project been working apache style for a certain time (the
time being a categorization in itself). If it has, there is no
question about prove - it'll be there as that is one of the key
factors of working the apache way (mailing lists, committers etc.)?

This categorization would then be the starting point for answering two
things that I think are currently missing in the whole incubation
process (please do tell me if I am wrong/ missed something):
* To what extend can information about the project's readiness be
gathered based on the (outside) history of the project, and how much
information needs to be gathered additionally during incubation? The
availability of such history could get some load of the backs of the
involved parties and might mean a shorter incubation time.
* What would be the proposed time estimate for the whole incubation?
Factor time currently seems to be non existent in the incubation
process. But 'it takes how long it takes' imo does not cut it. I
believe the incubation process would benefit from formalizing
timelines and milestones so that both parties keep focussed on making
progress. Having a schedule for incubation would also mean that
involved parties could use that schedule for any other plans they
might be making. For example, we (Wicket) would like to have our 2.0
version to be released at Apache, after (if) we're done with
incubation. There is currently no way to even remotely predict when
that might happen. This is inconvenient for our users, but also is a
problem as we are writing a book on that version and our publisher
*does* want to know when that book will be ready for publishing.
Having a code base that is release-ready but that's just waiting for
months for the incubation process to move on for some unknown time is
unacceptable to us. The kind of schedule I am thinking of would be
semi-binding. If we meet the requirements for the milestone in time,
we go on to the next stage, unless there is absolute consensus we
shouldn't based on something other that the milestone requirements. If
we don't meet the requirements in time, incubation may be terminated
for that reason alone.

I couldn't find any previous discussions on these topics, but if I
missed them, my apologies and please reply with an URL. Otherwise, I'd
be very interested to hear what others think of this. Also, I am not
specifically proposing anything concrete for Wicket's incubation at
this time; I wouldn't want to get in the way of our mentors :)

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

Re: Glasgow - community? specs? other issues?

[ro...@jpmorgan.com]

Let me try to address your concerns.

> And as far as the openness of the spec itself - this is, too, an issue.
> I will continue voting -1 until we really determine that - unlike JCP -
> we can have a no-NDA scenario with respect to TCKs etc.  And that,
> unlike Oasis, the implementation is covered by the grants, not strictly
> the spec.  And, ideally, that IP grants under the ASL will cover those
> participating in the spec from future problems; that the spec itself will
> not be entirely corp-based; and worse yet, that horridly offensive
> language is modified in the project proposal/charter.

There is no NDA with respect to TCKs. What made you think there was? In
fact, there is currently no TCK, which is something the AMQP group needs to
address and I am sure they will address. The AMQP group is only a few
months old and has many things to address.

I am not sure what you mean by "the implementation is covered by the
grants"? Are you referring to the TCK?

I am also not sure what you mean by "IP grants under the ASL will cover
those participating in the spec from future problems". Can you expand on
that please?

Anyone can join the specification group, you just have to demonstrate
merit. There is a legal issue that people need to get their employer to
sign a declaration that basically says they are not going to sue other
members of specification group. The reason for this is that most people
work under a contract that states that everything they produce belongs to
their employer - even if they do it in their own time. If an individual can
demonstrate that they do not work under such a contract then I am pretty
sure there would be no requirement for them to approach their employer.

I believe that the language you objected to in the proposal was simply
poorly worded rather than deliberately offensive and that it will be
modified.

Robert



This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates.

This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you.
 

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