Well, can we have a separate vote for what to do with the web
console? I thought it was ready (or nearly so) and I don't want to hold
up the contribution for some of the unrelated items on your list.
(break)
As for your list, are you saying that a vote for new code going to
the incubator must necessarily be cast as a "we don't need a policy" vote
for 1 (since "it's a tool we already have now - we can always do that")?
I don't think that's entirely reasonable. A policy of sending donations
to the incubator is still a policy. Whatever, I guess I'm OK voting
against policy.
Also, I thought we were going to try to avoid votes on things that
haven't been discussed. Where did the metrics for accepting a committer
topic come from?
Aaron
On Tue, 12 Jul 2005, Geir Magnusson Jr. wrote:
> Lets start a new thread tomorrow, finish discussion since I suspect
> that all that will say their peace have done so, and work out a vote?
>
> I suspect we need to decide :
>
> 1) do we need to have any policy?
>
> 2) If so, decide the
>
> a) general committer acceptance policy/guidelines to define some
> sensible, fair, transparent metrics for accepting a committer
> such as
> - how long a person must commit patches
> - how long participate on the mailing lists
>
> b) general code acceptance policy (what we have been discussing here)
> where the options include
> - bring into SVN, grant committer status to some # of people
> - bring into SVN, grant restricted status to some # of people
> - bring into SVN, follow a) above for people
> - none of the above
>
> I think that "bring to incubator" is not in scope for this vote, as
> it's a tool we already have now - we can always do that and decide to
> sponsor or just participate, but at the end of that process, then the
> code contribution b) rules should apply.
>
> geir
>
>
> On Jul 12, 2005, at 7:50 PM, Aaron Mulder wrote:
>
> > Well, I was going to start a new thread, but it seems Alan doesn't
> > like that, so...
> >
> > Would it be accurate to say that the options on the table for
> > donated code are:
> >
> > 1) Bring (project X) to geronimo, grant full commit status to (some
> > number
> > of people) who have worked with the code before
> >
> > 2) Bring project X to geronimo, put in a clearly separate SVN area,
> > grant restricted commit status (via ACL or explicit direction) to some
> > number of people who have worked with the code before
> >
> > 3) Bring project X to the incubator, mix outside people and
> > potentially
> > Geronimo people to form a new project team
> >
> > It's clear that there's a variety of opinions as to which of these
> > is preferable, and potentially which is most preferable for the web
> > console vs the ORB.
> >
> > Aaron
> >
> > On Tue, 12 Jul 2005, David Blevins wrote:
> >
> >> On Tue, Jul 12, 2005 at 07:17:44PM -0400, Davanum Srinivas wrote:
> >>
> >>> It's a judgement call i guess. i have not been on the calls. If you
> >>> guys feel that it can support its own eco-system. then thats fine.
> >>>
> >>>
> >>
> >> I don't know yet, myself. But certainly one cannot deny there are
> >> more CORBA specs than Web Services specs (for a while anyway); not
> >> exactly the same deal as a web console.
> >>
> >> -David
> >>
> >>
> >>> On 7/12/05, David Blevins <[EMAIL PROTECTED]> wrote:
> >>>
> >>>> On Tue, Jul 12, 2005 at 06:58:20PM -0400, Davanum Srinivas wrote:
> >>>>
> >>>>> It's just that the piece of code we are talking about in both
> >>>>> cases,
> >>>>> seem un-usable w/o geronimo.
> >>>>>
> >>>>
> >>>> Is that really true? We are talking about a compliant ORB
> >>>> aren't we?
> >>>>
> >>>> -David
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Davanum Srinivas -http://blogs.cocoondev.org/dims/
> >>>
> >>
> >>
> >
> >
>
> --
> Geir Magnusson Jr +1-203-665-6437
> [EMAIL PROTECTED]
>
>
>
