incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@opendirective.com>
Subject Re: Anyone care to talk to ComDev? (was Re: Time to vote the chair?)
Date Sat, 04 Feb 2012 17:03:22 GMT
Chris, seriously, take a break. You are not hearing what I'm trying to  say
and therefore not answering my concerns, directly at least.

For an example see where you use the word failure in this reply - that word
has no bearing on anything I have said, yet you directly attribute it to
me.

I've made up my mind about how I feel about this proposal. In general I
like it. I have some concerns that I will express in a summary document
that I'll share with ComDev. At this point b I'm not sure if my concerns
are misplaced our not.

Thanks for taking the time to try and understand my issues. Enjoy the rest
of your weekend.

Sent from my mobile device, please forgive errors and brevity.
On Feb 4, 2012 3:57 PM, "Mattmann, Chris A (388J)" <
chris.a.mattmann@jpl.nasa.gov> wrote:

> Hi Ross,
>
> On Feb 4, 2012, at 2:36 AM, Ross Gardler wrote:
>
> > Sent from my mobile device, please forgive errors and brevity.
> > On Feb 4, 2012 3:41 AM, "Mattmann, Chris A (388J)" <
> > chris.a.mattmann@jpl.nasa.gov> wrote:
> >> [...snip...]
> >>> Who fixes it?
> >>
> >> The project's PMC. And if not, the project's VP. And if not that, the
> > board,
> >> or the membership. Just like the current way it works for existing TLPs.
> >
> > if l the "membership" what is the channel used and who is responsible for
> > ensuring that channel works?
>
> The same channel that exists today for normal projects. The board is
> elected by the membership. If the board doesn't fix the problem for the
> project, and the membership is unpleased, the members elect a new
> board that will fix it. Or they won't.
>
> >
> >>
> >>> Who is maintaining the standards with respect to IP
> >>> management?
> >>
> >> How much work is there maintaing them? What's left to do?
> >
> > I mean in individual projects, not in defining policy. Even in the
> poddling
> > that I've felt would benefit from this proposal the RM has learned by his
> > mistakes. Some of which were caught by IPMC review when an additional
> vote
> > was needed.
>
> Sure, and in my proposal it'll be caught by review of having 3 ASF members
> on the project; by actually signing up strong ASF members (or "mentors")
> to the project (as Benson said) who care about that stuff (release review,
> etc.), and by having
> a VP for the project. Or by the board. Or by the legal committee.
>
> If you think about it, I'm simply proposing to use what's there, and to
> move more towards the existing foundation resources, than to pretend
> that the IPMC was the only place that we could get this information from.
> A lot of the passionate legal folks or release review folks in the IPMC
> (ant, Sam, etc.) are also members of the legal committee, and/or lurk
> there. A lot of the release passionate folks (Joe S., myself etc.) also
> lurk in other
> places that will see releases happening (infra@, etc.). It's not putting
> extra
> burden on them to ask them to flag what they see, or provide advice.
> They're
> doing that already.
>
> > Who provides these cross-checks?
>
> See above.
>
> >
> > You asked if a project couldn't muster the binding votes on a release,
> > what's it doing on the incubator. This project couldn't, but it is still
> > graduating. Ironically when I suggested bringing the RM into the IPMC to
> > help other podlings trying to find votes Bill, who supports this proposal
> > said yes, but required that the RM must refrain from voting on his own
> > releases. That position seems to conflict with this proposal and I'm
> > unclear what the difference is.
>
> I can't speak for Bill, but I can say that Bill "gets" what I am saying
>  (and so do quite a few others).  Bill is just keeping up with the threads
> right now, and doing a great job.
>
> You'll note I supported giving your RM his VOTE, and in my proposal
> you wouldn't have had problems mustering any binding VOTEs. You'd
> have had them already like any other project management committee.
>
> >
> >>
> >> Arguably, legal and the Legal Committee have a hand in this, no?
> >> I'm not sure it was entirely managed by the IPMC before.
> >
> > Again, I agree the IPMC has not always worked, but it has not always
> failed
> > either.
>
> Stop calling it a failure. I *never* called it a failure. I called it a
> success.
> Even things that are a "success" end.
>
> >
> > Are legal@ going to do reviews when necessary? If not who is?
>
> Of course they are. They do it now for existing projects, that come
> to them and ask (Sam's famous phrase). And even before that, the ASF
> members who
> are on the project committee (and even the non members) need
> to do a bit of reading, and try and help out there as much as possible.
> Signing up to be a PMC member on an incoming project means
> investing the time to help out in some way. The member doesn't have to be
> all
> knowing or be the super star champion. That's why the trust is
> distributed amongst the members of the PMC just like any PMC,
> is funneled through the chair of the committee, and is acted or
> reacted upon by the board, and why the board is elected by
> the membership.
>
> Cheers,
> Chris
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Chris Mattmann, Ph.D.
> Senior Computer Scientist
> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> Office: 171-266B, Mailstop: 171-246
> Email: chris.a.mattmann@nasa.gov
> WWW:   http://sunset.usc.edu/~mattmann/
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Adjunct Assistant Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message