Re: [VOTE] Graduate Apache Shindig as an Apache Top Level Project

2010-01-14 Thread Kevin Brown
+1

On Jan 14, 2010 3:42 AM, "Vincent Siveton"  wrote:

Hi,

Thanks for the positive feedback on the proposal to graduate Shindig
as a TLP [1].

I would like to start an official vote to recommend the graduation of
Apache Shindig as a Top Level Project to the Board.
To that end I have prepared the resolution for the Board below to be
presented for consideration at the upcoming Board meeting.

Community graduation vote thread:
http://shindig-dev.markmail.org/message/c47amdxjtntkjij5

Please cast your vote:
[ ] +1 to recommend Shindig's graduation
[ ] 0 don't care
[ ] -1 no, don't recommend yet, because ...

The vote will be open for 72 hours.

Cheers,

Vincent

[1] http://apache.markmail.org/message/qvpyymihv6gyh5a7

--- Begin Proposed Board Resolution ---

WHEREAS, the Board of Directors deems it to be in the best interests of the
Foundation and consistent with the Foundation's purpose to establish a
Project
Management Committee, charged with the creation and maintenance of
open-source
software related to the implementation of an OpenSocial container and
OpenSocial API specifications, for distribution at no charge to the public.

NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC),
to
be known as the "Apache Shindig PMC", is hereby established pursuant to
Bylaws
of the Foundation; and be it further

RESOLVED, that the Apache Shindig Project be and hereby is responsible for
the
creation and maintenance of software related to the OpenSocial API
specifications, based on software licensed to the Foundation; and be it
further

RESOLVED, that the office of "Vice President, Apache Shindig" be and hereby
is created, the person holding such office to serve at the direction of the
Board of Directors as the chair of Apache Shindig, and to have primary
responsibility for management of the projects within the scope of
responsibility
of the Apache Shindig PMC; and be it further

RESOLVED, that the persons listed immediately below be and hereby are
appointed
to serve as the initial members of the Apache Shindig PMC:

* Ian Boston (ieb at apache dot org)
* Kevin Brown (etnu at apache dot org)
* Chris Chabot(chabotc at apache dot org)
* Chico Charlesworth (chico at apache dot org)
* Cassie Doll (doll at apache dot org)
* Evan Gilbert (evan at apache dot org)
* John Hjelmstad (johnh at apache dot org)
* Paul Lindner (lindner at apache dot org)
* Daniel Peterson (dpeterson at apache dot org)
* Louis Ryan (lryan at apache dot org)
* Henning Schmiedehausen (henning at apache dot org)
* Vincent Siveton (vsiveton at apache dot org)
* Upayavira (upayavira at apache dot org)
* Adam Winer (awiner at apache dot org)

NOW, THEREFORE, BE IT FURTHER RESOLVED, that Paul Lindner be appointed to
the
office of Vice President, Apache Shindig, to serve in accordance with and
subject to the direction of the Board of Directors and the Bylaws of the
Foundation until death, resignation, retirement, removal or
disqualification, or
until a successor is appointed; and be it further

RESOLVED, that Apache Shindig be and hereby is tasked with the migration
and rationalization of the Apache Incubator Shindig podling; and be it
further

RESOLVED, that all responsibilities pertaining to the Apache Incubator
Shindig podling encumbered upon the Apache Incubator PMC are hereafter
discharged.

--- End Proposed Board Resolution ---

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


Re: Proposal for Wookie a W3C Widget/Google Wave widget engine

2009-07-06 Thread Kevin Brown
On Mon, Jul 6, 2009 at 11:46 AM, Ross Gardler  wrote:

> 2009/7/6 Chris Chabot :
> > Hey guys,
> >
> > Great looking proposal!
> >
> > On Mon, Jul 6, 2009 at 1:53 PM, Ate Douma  wrote:
> >
> >>
> >> The Wookie proposal has my high interest, especially from the bridging
> POV
> >> between W3C Widgets and Google Gadgets.
> >
> >
> > It seems there's a few mixed terminologies here, so in interest of making
> > sure we're all talking about the same things I'll quickly go over the
> > different types of 'gadgets' that could potentially be supported by
> Wookie:
> >
> >
> >   - Google Gadgets, as described here:
> >   http://code.google.com/apis/gadgets/docs/spec.html This is a clasic
> >   gadget type model that doesn't have any social tools in it, think
> clasic
> >   iGoogle home page type gadgets.. this actually has the Google brand
> >   associated with it and because it's a product name it's called Gadgets
> (cap
> >   G). It's an interesting platform to support, but in general iGoogle is
> >   moving to OpenSocial gadgets instead (which is backward compatible).
> >
> >   - OpenSocial gadgets not a Google brand or product, instead both the
> >   specification process and the reference implementation (Apache Shindig
> >   (-incubating)) are community driven. In the beginning it started out
> with an
> >   iGoogle style API but has evolved to a completely different (much more
> >   elegant and powerful) platform that has a very large feature set, and
> >   focuses on social. Next to that there's the OpenSocial Foundation which
> has
> >   people from many social-interested companies and is a non-profit
> corporation
> >   created to sustain the free and open development of OpenSocial
> >   specifications. (more info at
> >   http://www.opensocial.org/page/opensocial-foundation-faq). The main
> entry
> >   point to find out about OpenSocial is http://www.opensocial.org/ and
> the
> >   Shindig reference implementation can be found at
> >   http://incubator.apache.org/shindig/
> >
> >   - There's mention of 'Wave gadgets', Google Wave uses the same gadgets
> >   javascript API, but adds a bit of functionality to it (as described at
> >   http://code.google.com/apis/wave/extensions/gadgets/reference.html),
> the
> >   added functionality is focused around the real time nature of Google
> Wave
> >   with functions for participants changes and data state changes.
> >
> > Now to support Google Gadgets and OpenSocial, the easiest way to
> accomplish
> > that would be to just completely pull in Apache Shindig (-incubating),
>
> Google Gadgets and OpenSocial support is indeed provided via Apache
> Shindig (See Rationale: "The Wookie engine can render widgets using
> alternative APIs by a feature extension mechanism (for example, it
> allows Widgets to also use the Google Wave Gadgets API), or by acting
> as a proxy. For example, it leverages Apache Shindig (Incubating) to
> render OpenSocial gadgets. "
>
>
> > OpenSocial does assume you have a social graph though (the activities and
> > app data part of OpenSocial are optional, though the platform is more
> > attractive if you offer those too), so you could either take Shindig's
> > approach and assume that the Wookie users will implement the social data
> > interface classes them selves and connect it up to their existing social
> > data, and/or you could include Social Site which provides that for you ..
> > with some clever crafting supporting both use-cases shouldn't be to bad
> > though.
>
> It is my (possibly incorrect) understanding that Wookie does not, at
> present, provide a social graph. I do not believe this to be within
> scope of Wookie, given the domain it was developed in (virtual
> learning environments (VLE)) I would imagine someone wanting the
> social graph would leverage the user data in the VLE. It would be
> great to see collaboration between Social Site and Wookie to provide
> an alternative means of providing a social graph, but bear in mind
> that the W3c Widget spec does not concern itself with social graphs.
> So I'm not sure whether this would be considered in scope or not.
> Perhaps one of the project team can comment.
>
> Of course, if someone wants to see this kind of enhancement there's
> nothing stopping the patches being supplied.
>
> > Google Wave Gadgets is a different beast entirely, they're basically just
> > the same gadgets as from OpenSocial, but without the real time Wave
> server
> > behind it that drives the real time data state changes it doesn't seem to
> > make a lot of sense to support it in a portal type project, and pulling
> in a
> > complete communications platform might be outside of Wookie's project
> scope.
>
> Google Wave is not as similar to Open Social as it may seem. Open
> Social gadgets are single user widgets. When you add a widget to your
> page you own it. A Wave gadget is not a single user widget. When
> someone adds it to a wave *all* users with access to that wave have
> access to it. There is no con

Re: maven-repository cont.

2008-05-30 Thread Kevin Brown
On Fri, May 30, 2008 at 5:53 AM, Brian E. Fox <[EMAIL PROTECTED]>
wrote:

> I personally think we have conflicting rules in the way we handle
> incubator releases.
>
>
>
> On the one hand, we require incubator releases to be in a separate
> repository... for whatever reason (they aren't part of Apache, they
> aren't stable enough, etc). On the other hand, we allow regular releases
> of apache artifacts into the central repository with dependencies on
> incubator artifacts.
>
>
>
> On many occasions, I've seen this cause people lots of confusion because
> they update to a new version of an existing artifact and suddenly their
> build fails to find a dependency. (because the new version is now using
> an incubating artifact)
>
>
>
> IMO, things going into the central repository must have their entire
> transitive hull available in the central repository. Therefore, we must
> draw one of two conclusions:
>
>
>
> 1.  Incubator releases go into Central
>
> 2.  Regular releases cannot use Incubator artifacts
>
>
>
> Since the whole point of the incubator releases is to get some people to
> use them and prove them out, I say 2 is not really an option. If the PMC
> of a given project tests out an incubator artifact and deems it good
> enough for a release, then that should be enough But let's make it
> easier for the users by having those dependencies available.


#2 would also present a big issue for any existing incubator project that
depends on another project. What happens if my project graduates by my
dependency does not? Should incubator projects not depend on other incubator
projects as well?


>
>
>
> --Brian
>
>
>
>