You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by Joe Schaefer <jo...@yahoo.com> on 2010/08/12 21:16:42 UTC
time for a reboot?
It has come to my attention that this project has
made no effort to maintain its list of PPMC members.
A best-effort was made by Gavin McDonald to construct
that list from the subscriber base to thrift-private@
which may be found here:
http://incubator.apache.org/projects/thrift
This project remains at a crossroads, and my personal
graduation vote based on the current trajectory would
not be favorable.
Apache projects are not cathedrals, they are bazaars.
The committers on the project are facilitators, not
gatekeepers. Every person who has ever submitted a patch
to either jira or this mailing list should be encouraged by
the existing devs to become a committer on this project,
but that never happens here. Instead people fork,
like what happened with c-thrift. That is not goodness
from an Apache standpoint; it would be far better to
create a sandbox in the subversion tree for experimentation
by community members.
Trunk should be treated as Commit-then-Review. It is
a-ok to break it, and anyone running trunk in production
better be prepared to deal with the fallout of that
decision.
Look, cassandra came into Apache a year or so after
thrift did, and they have already graduated. Part of
the reason why they have been successful where thrift
has not is because the Facebook devs there were not
allowed to place downward pressure on the community
the way they have here. The sooner this community
starts routing around them, the more likely this
project has a chance of real success at Apache.
I have asked for special permission from my colleagues
in the Incubator to experiment with processes designed
to get out of your way in as far as it is possible,
so there can be no excuses as to why Thrift is not
succeeding except for the fact that the devs have
not done an adequate job of growing the community.
I expect that permission to be granted very soon,
and would like those committers on this project
who still care about it to take advantage of this
special opportunity before it's too late. So far
Bryan is the only person I would trust to make an
IPMC member or serve as Chair for this project
should it pursue graduation, but if others start
showing more active interest I am more than happy
to consider them.
Re: time for a reboot?
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: David Reiss <dr...@facebook.com>
> To: thrift-dev@incubator.apache.org
> Cc: Joe Schaefer <jo...@yahoo.com>
> Sent: Thu, August 12, 2010 4:38:02 PM
> Subject: Re: time for a reboot?
>
> > 1) Facebook submitted the code grant over a year after
> > the code was checked into svn.
> I'm pretty sure this is incorrect. The documents submitted by Facebook
> were lost *twice* by Apache, as well as several of the ICLAs submitted
> by non-Facebook contributors.
Wasn't aware of that. In any case our document processing has improved
over time, so it's less likely that something like that could happen now.
> > It was only after arm-twisting by both me and Upayavira that Todd
> > Lipcon was offered commit in order to deal with the issues and cut a
> > release.
> Todd specifically told us that he did not care about getting commit
> access.
>
> > Todd seems to have lost interest in further work here.
> This is because Todd changed jobs, and his new employer does not use
> Thrift.
>
> > 2) When Upayavira or I or anyone else ask questions about
> > the project and its future here, Facebook devs always
> > speak on behalf of the devs instead of encouraging input
> > from others.
> Well, I can just speak for myself, but I respond to these emails because
> I'm trying to be helpful. It sounds like it would be more helpful for
> me to encourage others to respond instead, so I'll be doing this from
> now on. Sorry for the misunderstanding.
As someone recently told me, community building is more art than
science. Encouraging participation from others is important if
the project is going to grow its developer base.
>
> > 3) Instant releases are counter to Apache's goals for code
> > management and distribution policies. As dev tools they
> > are tolerable, but when end-users are told to use those
> > instead of true releases they are not.
> I'm not sure if I've never told an end-user to use an instant release
> instead of a true release. If I have, I'm pretty sure it was before 0.2
> was released. The instant releases are just there so people who want to
> use trunk but not install autoconf and friends can do so. No one has
> ever told me that maintaining this page is harming Thrift, but I'd be
> more than happy to shut it down if that is the case.
As I said as a dev tool it's ok. Just be careful not to promote them
to people in the user community.
> > While I haven't seen commits being vetoed, I also haven't seen commits
> > get discussed post-commit, which means the review is happening prior
> > to commit instead of post commit. That should be addressed by the
> > community
> When we started the project, we were told that we were free to choose
> between a "review-then-commit" or "commit-then-review" model, and we
> (which includes non-Facebook contributors) chose the former. If this is
> no longer considered good practice, I suppose we could switch models.
Ok. While it *is* something we leave up to the projects, it is not
aligned with best practice here to follow review-then-commit for
trunk. It tends to stife experimentation too much, especially if
the only branching activity is for releases.
Re: time for a reboot?
Posted by David Reiss <dr...@facebook.com>.
> Todd has not recently changed employment. He continues to work at
> Cloudera.
Right. His contributions to Thrift were primarily on behalf of his previous
employer, Aimee Street.
--David
Re: time for a reboot?
Posted by David Reiss <dr...@facebook.com>.
> Just today someone complained about a bug report taking over 1 year to be addressed.
That was a new feature, not a bug. A lot of the "over 800 issues" have been.
Re: time for a reboot?
Posted by Bryan Duxbury <br...@rapleaf.com>.
I understand what Todd is saying about stability and the cost of change, and
it's something that Rapleaf has encountered, too. However, I think stability
should be an *end goal*, not necessarily our current goal. I think we should
be aiming to make all the traumatic changes that we might need before we hit
1.0, and then proceed with greater caution. If this means that we should
change our processes to get out of the way of those who wish to make
exploratory changes now, then I'm for that.
On Thu, Aug 12, 2010 at 10:06 PM, Joe Schaefer <jo...@yahoo.com>wrote:
> ----- Original Message ----
>
> > From: Todd Lipcon <to...@cloudera.com>
> > To: thrift-dev@incubator.apache.org
> > Sent: Fri, August 13, 2010 12:57:52 AM
> > Subject: Re: time for a reboot?
> >
> > On Thu, Aug 12, 2010 at 7:20 PM, Joe Schaefer <joe_schaefer@yahoo.com
> >wrote:
> >
> > > I both respect and agree with your remarks. With respect to the
> delay
> > > between considering someone for committership and actually becoming
> one,
> > > it's true that it is a process that spans several days if not weeks.
> > > However
> > > we really aren't looking for drive-thru committers, we want people who
> > > will show sustained dedication to the project, spanning several months
> > > if not years (iow Todd's committership here so far hasn't been
> something
> > > I'd consider a success). Remember it's community over code at Apache.
> > >
> > >
> > In my defense, when I was nominated for being a committer, I did say
> that my
> > plan was to help with the 0.2 release and then likely step back. As I
> think
> > is the case for every person who works on Thrift, Thrift is not a
> primary
> > responsibility. It seems your stance above indicates that the only
> > "successful" committers are those who spend substantial time on the
> project
> > every week - this seems counter to your earlier point that the bar for
> > committership is too high.
> >
> > As a central piece of infrastructure, Thrift *should* be a slow moving
> > project. It would make me very nervous if it released more than a couple
> > times a year! As a random datapoint, I've heard from within Google that
> the
> > move from Protocol Buffers v1 to v2 was an incredibly disruptive change
> that
> > took more than a year to do throughout the organization. At a much
> smaller
> > scale, I've seen the upgrade from Thrift 0.1 to 0.2 burn about a
> man-week of
> > development time internally due to changes in the generated Java code --
> so
> > you can see that releases with breaking changes have a large cost and
> hence
> > the team is reasonably cautious about any changes that might cause them.
> >
> > The Apache mantra is "community over code", and in this case, the
> community
> > is voting that they want the code to not evolve rapidly. It's a stable
> piece
> > of infrastructure and should be treated as such. Perhaps those who have
> been
> > working on some more experimental changes would like to weigh in here if
> > they feel like their contributions have been unfairly treated?
>
> AFAICT the changelogs for the last 2 releases do not bear out your
> suggestion that Thrift is an incredibly stable project. Neither
> does the fact that over 800 issues have been filed against this
> codebase since it's been brought here. Just today someone complained
> about a bug report taking over 1 year to be addressed. The fact is
> that there is plenty of work to go around and only 2-3 people actually
> doing it. That is the reason it is a slow-moving project IMO. Unlike
> cassandra people are STILL running thrift in production with local mods
> instead of using straight releases. Reading the email stream today alone
> tells a rather different story than you appear to believe is true.
>
>
>
>
Re: time for a reboot?
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Todd Lipcon <to...@cloudera.com>
> To: thrift-dev@incubator.apache.org
> Sent: Fri, August 13, 2010 12:57:52 AM
> Subject: Re: time for a reboot?
>
> On Thu, Aug 12, 2010 at 7:20 PM, Joe Schaefer <jo...@yahoo.com>wrote:
>
> > I both respect and agree with your remarks. With respect to the delay
> > between considering someone for committership and actually becoming one,
> > it's true that it is a process that spans several days if not weeks.
> > However
> > we really aren't looking for drive-thru committers, we want people who
> > will show sustained dedication to the project, spanning several months
> > if not years (iow Todd's committership here so far hasn't been something
> > I'd consider a success). Remember it's community over code at Apache.
> >
> >
> In my defense, when I was nominated for being a committer, I did say that my
> plan was to help with the 0.2 release and then likely step back. As I think
> is the case for every person who works on Thrift, Thrift is not a primary
> responsibility. It seems your stance above indicates that the only
> "successful" committers are those who spend substantial time on the project
> every week - this seems counter to your earlier point that the bar for
> committership is too high.
>
> As a central piece of infrastructure, Thrift *should* be a slow moving
> project. It would make me very nervous if it released more than a couple
> times a year! As a random datapoint, I've heard from within Google that the
> move from Protocol Buffers v1 to v2 was an incredibly disruptive change that
> took more than a year to do throughout the organization. At a much smaller
> scale, I've seen the upgrade from Thrift 0.1 to 0.2 burn about a man-week of
> development time internally due to changes in the generated Java code -- so
> you can see that releases with breaking changes have a large cost and hence
> the team is reasonably cautious about any changes that might cause them.
>
> The Apache mantra is "community over code", and in this case, the community
> is voting that they want the code to not evolve rapidly. It's a stable piece
> of infrastructure and should be treated as such. Perhaps those who have been
> working on some more experimental changes would like to weigh in here if
> they feel like their contributions have been unfairly treated?
AFAICT the changelogs for the last 2 releases do not bear out your
suggestion that Thrift is an incredibly stable project. Neither
does the fact that over 800 issues have been filed against this
codebase since it's been brought here. Just today someone complained
about a bug report taking over 1 year to be addressed. The fact is
that there is plenty of work to go around and only 2-3 people actually
doing it. That is the reason it is a slow-moving project IMO. Unlike
cassandra people are STILL running thrift in production with local mods
instead of using straight releases. Reading the email stream today alone
tells a rather different story than you appear to believe is true.
Re: time for a reboot?
Posted by Todd Lipcon <to...@cloudera.com>.
On Thu, Aug 12, 2010 at 7:20 PM, Joe Schaefer <jo...@yahoo.com>wrote:
> I both respect and agree with your remarks. With respect to the delay
> between considering someone for committership and actually becoming one,
> it's true that it is a process that spans several days if not weeks.
> However
> we really aren't looking for drive-thru committers, we want people who
> will show sustained dedication to the project, spanning several months
> if not years (iow Todd's committership here so far hasn't been something
> I'd consider a success). Remember it's community over code at Apache.
>
>
In my defense, when I was nominated for being a committer, I did say that my
plan was to help with the 0.2 release and then likely step back. As I think
is the case for every person who works on Thrift, Thrift is not a primary
responsibility. It seems your stance above indicates that the only
"successful" committers are those who spend substantial time on the project
every week - this seems counter to your earlier point that the bar for
committership is too high.
As a central piece of infrastructure, Thrift *should* be a slow moving
project. It would make me very nervous if it released more than a couple
times a year! As a random datapoint, I've heard from within Google that the
move from Protocol Buffers v1 to v2 was an incredibly disruptive change that
took more than a year to do throughout the organization. At a much smaller
scale, I've seen the upgrade from Thrift 0.1 to 0.2 burn about a man-week of
development time internally due to changes in the generated Java code -- so
you can see that releases with breaking changes have a large cost and hence
the team is reasonably cautious about any changes that might cause them.
The Apache mantra is "community over code", and in this case, the community
is voting that they want the code to not evolve rapidly. It's a stable piece
of infrastructure and should be treated as such. Perhaps those who have been
working on some more experimental changes would like to weigh in here if
they feel like their contributions have been unfairly treated?
-Todd
--
Todd Lipcon
Software Engineer, Cloudera
Re: time for a reboot?
Posted by Bryan Duxbury <br...@rapleaf.com>.
Some patches are quite large; would it really make sense to send that much
content via email to an entire list?
On Thu, Aug 12, 2010 at 9:24 PM, David Reiss <dr...@facebook.com> wrote:
> Is it possible to configure JIRA to include patch content in notification
> emails?
>
> On 08/12/2010 09:13 PM, Joe Schaefer wrote:
> >
> >
> >
> >
> > ----- Original Message ----
> >> From: David Dabbs <dm...@gmail.com>
> >> To: thrift-dev@incubator.apache.org
> >> Sent: Thu, August 12, 2010 11:32:58 PM
> >> Subject: RE: time for a reboot?
> >>
> >>>> sometimes that cuts against having multiple people involved.
> >>> Do you have a sense for why that is?
> >>> I think switching to the mailing list for code reviews would
> >>> be a pain, and I'd rather fix whatever problem prevents
> >>> people from contributing to JIRA discussions
> >>> (or switch to a real code review tool) than just toss it.
> >>
> >>
> >>
> >> If you are using JIRA, oss license I presume, then why not also use
> >> Atlassian's Cruicible?
> >
> > Some projects at Apache do use Crucible with some success, but the
> > problem I'm driving at is based on the fact that patches attached
> > to jira don't get looked at by more than a handful of people, whereas
> > patches sent to the thrift-dev@ list are at least seen by every
> subscriber.
> > Open source is a very lazy development system, where the more stuff you
> > put between the code and a person's eyeballs the less likely they'll
> > actually bother.
> >
> > Email as the main communication vehicle for open source development
> > has survived largely because it puts the patches right there in
> > everyone's inbox. Even very lazy people don't mind skimming commit
> > messages for interesting content ;-). That's why some projects
> > at Apache don't keep the commit messages on a seperate list from the
> > development list.
> >
> >
> >
>
Re: time for a reboot?
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: David Reiss <dr...@facebook.com>
> To: thrift-dev@incubator.apache.org
> Sent: Fri, August 13, 2010 12:24:27 AM
> Subject: Re: time for a reboot?
>
> Is it possible to configure JIRA to include patch content in notification
>emails?
That would be a good question to address to infrastructure@apache.org.
The short answer is that I'm not aware of any way to do that, but
others might.
Re: time for a reboot?
Posted by David Reiss <dr...@facebook.com>.
Is it possible to configure JIRA to include patch content in notification emails?
On 08/12/2010 09:13 PM, Joe Schaefer wrote:
>
>
>
>
> ----- Original Message ----
>> From: David Dabbs <dm...@gmail.com>
>> To: thrift-dev@incubator.apache.org
>> Sent: Thu, August 12, 2010 11:32:58 PM
>> Subject: RE: time for a reboot?
>>
>>>> sometimes that cuts against having multiple people involved.
>>> Do you have a sense for why that is?
>>> I think switching to the mailing list for code reviews would
>>> be a pain, and I'd rather fix whatever problem prevents
>>> people from contributing to JIRA discussions
>>> (or switch to a real code review tool) than just toss it.
>>
>>
>>
>> If you are using JIRA, oss license I presume, then why not also use
>> Atlassian's Cruicible?
>
> Some projects at Apache do use Crucible with some success, but the
> problem I'm driving at is based on the fact that patches attached
> to jira don't get looked at by more than a handful of people, whereas
> patches sent to the thrift-dev@ list are at least seen by every subscriber.
> Open source is a very lazy development system, where the more stuff you
> put between the code and a person's eyeballs the less likely they'll
> actually bother.
>
> Email as the main communication vehicle for open source development
> has survived largely because it puts the patches right there in
> everyone's inbox. Even very lazy people don't mind skimming commit
> messages for interesting content ;-). That's why some projects
> at Apache don't keep the commit messages on a seperate list from the
> development list.
>
>
>
Re: time for a reboot?
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: David Dabbs <dm...@gmail.com>
> To: thrift-dev@incubator.apache.org
> Sent: Thu, August 12, 2010 11:32:58 PM
> Subject: RE: time for a reboot?
>
> > > sometimes that cuts against having multiple people involved.
> > Do you have a sense for why that is?
> > I think switching to the mailing list for code reviews would
> > be a pain, and I'd rather fix whatever problem prevents
> > people from contributing to JIRA discussions
> > (or switch to a real code review tool) than just toss it.
>
>
>
> If you are using JIRA, oss license I presume, then why not also use
> Atlassian's Cruicible?
Some projects at Apache do use Crucible with some success, but the
problem I'm driving at is based on the fact that patches attached
to jira don't get looked at by more than a handful of people, whereas
patches sent to the thrift-dev@ list are at least seen by every subscriber.
Open source is a very lazy development system, where the more stuff you
put between the code and a person's eyeballs the less likely they'll
actually bother.
Email as the main communication vehicle for open source development
has survived largely because it puts the patches right there in
everyone's inbox. Even very lazy people don't mind skimming commit
messages for interesting content ;-). That's why some projects
at Apache don't keep the commit messages on a seperate list from the
development list.
RE: time for a reboot?
Posted by David Dabbs <dm...@gmail.com>.
> > sometimes that cuts against having multiple people involved.
> Do you have a sense for why that is?
> I think switching to the mailing list for code reviews would
> be a pain, and I'd rather fix whatever problem prevents
> people from contributing to JIRA discussions
> (or switch to a real code review tool) than just toss it.
If you are using JIRA, oss license I presume, then why not also use
Atlassian's Cruicible?
It too is available for open source projects/not-for-profits and integrates
with Jira.
http://www.atlassian.com/software/crucible/
Best,
David
Re: time for a reboot?
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: David Reiss <dr...@facebook.com>
> To: thrift-dev@incubator.apache.org
> Sent: Thu, August 12, 2010 11:07:13 PM
> Subject: Re: time for a reboot?
>
> > While it's convenient to keep discussion and issue all happening in
> > jira,
> I certainly agree with that.
>
> > sometimes that cuts against having multiple people involved.
> Do you have a sense for why that is? I think switching to the mailing list
>for
> code reviews would be a pain, and I'd rather fix whatever problem prevents
>people
> from contributing to JIRA discussions (or switch to a real code review tool)
> than just toss it.
Well I'm not suggesting you toss JIRA discussions, but once the
assignee decides to commit the patch perhaps that person should
follow-up to the commit message on the dev list to ask folks to
review it for correctness, potential for improvement, etc.
Soliciting reviews is a nice idea I've seen done well in the
Subversion project.
A reviewboard instance is in the works at Apache so perhaps that
will help as well, but anything that gets people here to discuss
the thrift code is a good thing. The idea is to slowly attract
comments from non-committers to get their opinions and gradually
increase their interest in development. Building a community
takes time and effort, it doesn't just happen because the project
is at Apache.
Re: time for a reboot?
Posted by David Reiss <dr...@facebook.com>.
> While it's convenient to keep discussion and issue all happening in
> jira,
I certainly agree with that.
> sometimes that cuts against having multiple people involved.
Do you have a sense for why that is? I think switching to the mailing list for
code reviews would be a pain, and I'd rather fix whatever problem prevents people
from contributing to JIRA discussions (or switch to a real code review tool)
than just toss it.
--David
On 08/12/2010 05:11 PM, Joe Schaefer wrote:
> ----- Original Message ----
>
>> From: Bryan Duxbury <br...@rapleaf.com>
>> To: thrift-dev@incubator.apache.org
>> Sent: Thu, August 12, 2010 7:53:59 PM
>> Subject: Re: time for a reboot?
>>
>> OK, then I think that we've been talking past each other the whole time,
>> since we've never had a policy anywhere near as rigorous as Apache's R-T-C.
>> It's more like, someone *should* review before it's committed, at the very
>> least the person who's doing the committing.
>
> Yes that is C-T-R you've been doing here all along in thrift, just the
> R part isn't happening consistently. What I'd like to see more examples
> of, with respect to the commit stream, is evidence of work being done in
> svn, instead of doing all the "prep" work in jira. Yes by all means
> don't commit stuff that breaks the build or fails the tests (to your knowledge),
> but a little evolutionary hacking would be a welcome change.
>
> Another observation: Apache's mailing list infra is underused in thrift
> with respect to collective code reviews and discussions: it all seems
> to take place in jira between the issue assignee and the reporter.
> While it's convenient to keep discussion and issue all happening in
> jira, sometimes that cuts against having multiple people involved.
> Not a major complaint, but something that could be worked on at some
> point.
>
>
>
Re: time for a reboot?
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Bryan Duxbury <br...@rapleaf.com>
> To: thrift-dev@incubator.apache.org
> Sent: Thu, August 12, 2010 7:53:59 PM
> Subject: Re: time for a reboot?
>
> OK, then I think that we've been talking past each other the whole time,
> since we've never had a policy anywhere near as rigorous as Apache's R-T-C.
> It's more like, someone *should* review before it's committed, at the very
> least the person who's doing the committing.
Yes that is C-T-R you've been doing here all along in thrift, just the
R part isn't happening consistently. What I'd like to see more examples
of, with respect to the commit stream, is evidence of work being done in
svn, instead of doing all the "prep" work in jira. Yes by all means
don't commit stuff that breaks the build or fails the tests (to your knowledge),
but a little evolutionary hacking would be a welcome change.
Another observation: Apache's mailing list infra is underused in thrift
with respect to collective code reviews and discussions: it all seems
to take place in jira between the issue assignee and the reporter.
While it's convenient to keep discussion and issue all happening in
jira, sometimes that cuts against having multiple people involved.
Not a major complaint, but something that could be worked on at some
point.
Re: time for a reboot?
Posted by Bryan Duxbury <br...@rapleaf.com>.
OK, then I think that we've been talking past each other the whole time,
since we've never had a policy anywhere near as rigorous as Apache's R-T-C.
It's more like, someone *should* review before it's committed, at the very
least the person who's doing the committing.
On Thu, Aug 12, 2010 at 4:42 PM, Joe Schaefer <jo...@yahoo.com>wrote:
> ----- Original Message ----
>
> > From: Bryan Duxbury <br...@rapleaf.com>
> > To: thrift-dev@incubator.apache.org
> > Sent: Thu, August 12, 2010 7:35:56 PM
> > Subject: Re: time for a reboot?
> >
> > On Thu, Aug 12, 2010 at 4:20 PM, Joe Schaefer <joe_schaefer@yahoo.com
> >wrote:
> >
> > > Note also that ANYONE can provide that review,
> > > it's not an activity limited to current committers only.
> > >
> >
> > Yes! This is what I'm trying to convey to people all the time. I'll
> commit
> > anything reviewed positively, but someone has to review it.
>
> Good. You do realize tho that when Apache people talk about
> review-then-commit, they are referring to a more formal process
> where 3 +1's from committers are required to commit any patch.
> What you are actually looking for in the above statement amounts
> to a commit-then-review policy with a basic sanity check prior to
> the commit. In C-T-R the review by fellow committers is lazy:
> it is assumed to have taken place on each commits, and if a committer
> detects an issue with a commit they will comment/vote on the
> commit message.
>
>
>
>
Re: time for a reboot?
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Bryan Duxbury <br...@rapleaf.com>
> To: thrift-dev@incubator.apache.org
> Sent: Thu, August 12, 2010 7:35:56 PM
> Subject: Re: time for a reboot?
>
> On Thu, Aug 12, 2010 at 4:20 PM, Joe Schaefer <jo...@yahoo.com>wrote:
>
> > Note also that ANYONE can provide that review,
> > it's not an activity limited to current committers only.
> >
>
> Yes! This is what I'm trying to convey to people all the time. I'll commit
> anything reviewed positively, but someone has to review it.
Good. You do realize tho that when Apache people talk about
review-then-commit, they are referring to a more formal process
where 3 +1's from committers are required to commit any patch.
What you are actually looking for in the above statement amounts
to a commit-then-review policy with a basic sanity check prior to
the commit. In C-T-R the review by fellow committers is lazy:
it is assumed to have taken place on each commits, and if a committer
detects an issue with a commit they will comment/vote on the
commit message.
Re: time for a reboot?
Posted by Bryan Duxbury <br...@rapleaf.com>.
On Thu, Aug 12, 2010 at 4:20 PM, Joe Schaefer <jo...@yahoo.com>wrote:
> Note also that ANYONE can provide that review,
> it's not an activity limited to current committers only.
>
Yes! This is what I'm trying to convey to people all the time. I'll commit
anything reviewed positively, but someone has to review it.
Re: time for a reboot?
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Joe Schaefer <jo...@yahoo.com>
> To: thrift-dev@incubator.apache.org
> Sent: Thu, August 12, 2010 7:20:58 PM
> Subject: Re: time for a reboot?
>
> ----- Original Message ----
>
> > From: Bryan Duxbury <br...@rapleaf.com>
> > To: thrift-dev@incubator.apache.org
> > Sent: Thu, August 12, 2010 7:10:03 PM
> > Subject: Re: time for a reboot?
> >
> > I think that the problem with commit-then-review would be the same problem
> > I'm currently experiencing with our existing review-then-commit: nobody is
> > doing any reviews!
> >
> > In general, I like the review-then-commit because it keeps us from just
> > breaking stuff all over the place. I don't really buy the idea that "trunk
> > is for experimentation". A lot of the traffic that comes in is bug
reports,
> > to which I don't think it makes sense to just commit whatever someone
> > provides - we want to actually *reduce* bugs, after all. For the things
>that
> > are really experimental, I think we already do a reasonable job of getting
> > them committed in as they are partially completed. I would be happy to
>start
> > giving people more leeway to experiment in branches in the official SVN,
if
> > that would improve the situation.
> >
> > I understand that some people have been frustrated by the difficulty of
> > contributing for a variety of reasons, but I don't think that means that
we
> > should just leave the door wide open in a way that would compromise code
> > quality. I can assure you that if the only time breakages are discovered
is
> > when I'm rolling a release candidate, then releases will stop.
> >
> > What would make me incredibly happy is if I saw more comments from users
> > that contained positive or negative reviews on patches. If there's
>apparent
> > consensus on a patch, then I'm happy to commit it, but when I'm reviewing
> > tickets that have nothing but a patch and a six-word comment from the
> > contributor, particularly if it's not a language I use regularly, I feel
> > like my hands are tied.
> >
> > I agree that we should be trying to recruit more committers. I'd be fine
> > with Thrift lowering the bar as to what we consider "enough" to offer
> > committership, but I don't really think that everyone who might be offered
> > the rights would actually want them or follow through on the
> > responsibilities. There's also a lot of overhead, including a fair amount
>of
> > latency, involved in becoming a committer. I don't think that a casual
> > contributor is really going to want to fill out paper forms and then wait
> > two weeks before they can commit. It just doesn't improve their experience
> > sufficiently.
>
> I both respect and agree with your remarks. With respect to the delay
> between considering someone for committership and actually becoming one,
> it's true that it is a process that spans several days if not weeks. However
> we really aren't looking for drive-thru committers, we want people who
> will show sustained dedication to the project, spanning several months
> if not years (iow Todd's committership here so far hasn't been something
> I'd consider a success). Remember it's community over code at Apache.
>
> And review matters, absolutely right. Whether it's before the commit
> or after, it really is an essential component that cannot continue
> to be ignored. Note also that ANYONE can provide that review,
> it's not an activity limited to current committers only.
Is thrift setup for CI? Does it use either of Apache's hudson or buildbot
automated builds? Perhaps setting something like that up for trunk would
alleviate some of the concerns for code breakage due to an errant commit.
Re: time for a reboot?
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Bryan Duxbury <br...@rapleaf.com>
> To: thrift-dev@incubator.apache.org
> Sent: Thu, August 12, 2010 7:10:03 PM
> Subject: Re: time for a reboot?
>
> I think that the problem with commit-then-review would be the same problem
> I'm currently experiencing with our existing review-then-commit: nobody is
> doing any reviews!
>
> In general, I like the review-then-commit because it keeps us from just
> breaking stuff all over the place. I don't really buy the idea that "trunk
> is for experimentation". A lot of the traffic that comes in is bug reports,
> to which I don't think it makes sense to just commit whatever someone
> provides - we want to actually *reduce* bugs, after all. For the things that
> are really experimental, I think we already do a reasonable job of getting
> them committed in as they are partially completed. I would be happy to start
> giving people more leeway to experiment in branches in the official SVN, if
> that would improve the situation.
>
> I understand that some people have been frustrated by the difficulty of
> contributing for a variety of reasons, but I don't think that means that we
> should just leave the door wide open in a way that would compromise code
> quality. I can assure you that if the only time breakages are discovered is
> when I'm rolling a release candidate, then releases will stop.
>
> What would make me incredibly happy is if I saw more comments from users
> that contained positive or negative reviews on patches. If there's apparent
> consensus on a patch, then I'm happy to commit it, but when I'm reviewing
> tickets that have nothing but a patch and a six-word comment from the
> contributor, particularly if it's not a language I use regularly, I feel
> like my hands are tied.
>
> I agree that we should be trying to recruit more committers. I'd be fine
> with Thrift lowering the bar as to what we consider "enough" to offer
> committership, but I don't really think that everyone who might be offered
> the rights would actually want them or follow through on the
> responsibilities. There's also a lot of overhead, including a fair amount of
> latency, involved in becoming a committer. I don't think that a casual
> contributor is really going to want to fill out paper forms and then wait
> two weeks before they can commit. It just doesn't improve their experience
> sufficiently.
I both respect and agree with your remarks. With respect to the delay
between considering someone for committership and actually becoming one,
it's true that it is a process that spans several days if not weeks. However
we really aren't looking for drive-thru committers, we want people who
will show sustained dedication to the project, spanning several months
if not years (iow Todd's committership here so far hasn't been something
I'd consider a success). Remember it's community over code at Apache.
And review matters, absolutely right. Whether it's before the commit
or after, it really is an essential component that cannot continue
to be ignored. Note also that ANYONE can provide that review,
it's not an activity limited to current committers only.
Re: time for a reboot?
Posted by ro...@bufferoverflow.ch.
commit-then-review vs. review-then-commit ... what about continuous
integration?
I'm sure Apache provides infrastructure to setup something like
CruiseControl or maven.
automated build and test can just happen after a commit, no manual
testing anymore!
by the way,
Thrift is a *great* piece of software and I'm sure that many companies
will prefer
Apache Thrift over Google Protocol Buffers, just as I have evaluated
for my employer.
Roger
Zitat von Bryan Duxbury <br...@rapleaf.com>:
> I think that the problem with commit-then-review would be the same problem
> I'm currently experiencing with our existing review-then-commit: nobody is
> doing any reviews!
>
> In general, I like the review-then-commit because it keeps us from just
> breaking stuff all over the place. I don't really buy the idea that "trunk
> is for experimentation". A lot of the traffic that comes in is bug reports,
> to which I don't think it makes sense to just commit whatever someone
> provides - we want to actually *reduce* bugs, after all. For the things that
> are really experimental, I think we already do a reasonable job of getting
> them committed in as they are partially completed. I would be happy to start
> giving people more leeway to experiment in branches in the official SVN, if
> that would improve the situation.
>
> I understand that some people have been frustrated by the difficulty of
> contributing for a variety of reasons, but I don't think that means that we
> should just leave the door wide open in a way that would compromise code
> quality. I can assure you that if the only time breakages are discovered is
> when I'm rolling a release candidate, then releases will stop.
>
> What would make me incredibly happy is if I saw more comments from users
> that contained positive or negative reviews on patches. If there's apparent
> consensus on a patch, then I'm happy to commit it, but when I'm reviewing
> tickets that have nothing but a patch and a six-word comment from the
> contributor, particularly if it's not a language I use regularly, I feel
> like my hands are tied.
>
> I agree that we should be trying to recruit more committers. I'd be fine
> with Thrift lowering the bar as to what we consider "enough" to offer
> committership, but I don't really think that everyone who might be offered
> the rights would actually want them or follow through on the
> responsibilities. There's also a lot of overhead, including a fair amount of
> latency, involved in becoming a committer. I don't think that a casual
> contributor is really going to want to fill out paper forms and then wait
> two weeks before they can commit. It just doesn't improve their experience
> sufficiently.
>
> On Thu, Aug 12, 2010 at 3:19 PM, Davanum Srinivas <da...@gmail.com> wrote:
>
>> Todd,
>>
>> Would opening trunk to Commit-Then-Review and maintaining branches
>> using Review-Then-Commit help? That would involve folks using stable
>> branches in production...
>>
>> -- dims
>>
>>
>> On Thu, Aug 12, 2010 at 6:14 PM, Joe Schaefer <jo...@yahoo.com>
>> wrote:
>> > ----- Original Message ----
>> >
>> >> From: Todd Lipcon <to...@cloudera.com>
>> >> To: thrift-dev@incubator.apache.org
>> >> Sent: Thu, August 12, 2010 6:01:19 PM
>> >> Subject: Re: time for a reboot?
>> >
>> >> Hey look, a thread about me!
>> >>
>> >> The majority of my contributions were at my previous job, but I did get
>> >> committership and do the 0.2 release after joining Cloudera as Doug
>> said.
>> >> Cloudera does use Thrift internally, so having a stable release out was
>> >> important for us.
>> >>
>> >> I haven't been as involved in further releases because frankly, Thrift
>> does
>> >> what it's supposed to do and does a good job of it. What the ASF seems
>> to
>> >> see as a stagnating project seems to me to just be a mature one -
>> Thrift has
>> >> a single purpose, achieves it effectively, and does a good job for lots
>> and
>> >> lots of people including both my former and current employers. The
>> major
>> >> issues I've run into (and seen coworkers run into) have had to do with
>> the
>> >> release packaging and build, which we've improved a bit, and will
>> improve on
>> >> the distribution side of things as people like Debian start packaging
>> the
>> >> bits.
>> >
>> > My concern is more that Thrift has become a 1-man show over the past
>> > year than that there is stagnation here. Jira tickets get filed, commits
>> > happen, and eventually releases happen, but that's all being done by the
>> > heroism of Bryan. Apache projects are collaborative in nature, and
>> > usually committers care enough about one another not to let one person
>> > carry the project along all by themselves. If there isn't sufficient
>> > interest amongst the current committers to participate in development,
>> > perhaps we should be recruiting from those filing patches in Jira.
>> >
>> > With respect to commit-then-review, httpd has had that as its policy
>> since
>> > the very beginning, and it manages to produce consistently stable
>> releases.
>> > Ditto for the subversion project. Hadoop is certainly not the model of
>> > Apache-style version-control tree management that others should aspire
>> to,
>> > FWIW. There are serious internal concerns about the overall health of
>> the
>> > hadoop development ecosystem as it continues to evolve towards a 1.0
>> release.
>> >
>> >
>> >
>> >
>>
>>
>>
>> --
>> Davanum Srinivas :: http://davanum.wordpress.com
>>
>
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
Re: time for a reboot?
Posted by Bryan Duxbury <br...@rapleaf.com>.
I think that the problem with commit-then-review would be the same problem
I'm currently experiencing with our existing review-then-commit: nobody is
doing any reviews!
In general, I like the review-then-commit because it keeps us from just
breaking stuff all over the place. I don't really buy the idea that "trunk
is for experimentation". A lot of the traffic that comes in is bug reports,
to which I don't think it makes sense to just commit whatever someone
provides - we want to actually *reduce* bugs, after all. For the things that
are really experimental, I think we already do a reasonable job of getting
them committed in as they are partially completed. I would be happy to start
giving people more leeway to experiment in branches in the official SVN, if
that would improve the situation.
I understand that some people have been frustrated by the difficulty of
contributing for a variety of reasons, but I don't think that means that we
should just leave the door wide open in a way that would compromise code
quality. I can assure you that if the only time breakages are discovered is
when I'm rolling a release candidate, then releases will stop.
What would make me incredibly happy is if I saw more comments from users
that contained positive or negative reviews on patches. If there's apparent
consensus on a patch, then I'm happy to commit it, but when I'm reviewing
tickets that have nothing but a patch and a six-word comment from the
contributor, particularly if it's not a language I use regularly, I feel
like my hands are tied.
I agree that we should be trying to recruit more committers. I'd be fine
with Thrift lowering the bar as to what we consider "enough" to offer
committership, but I don't really think that everyone who might be offered
the rights would actually want them or follow through on the
responsibilities. There's also a lot of overhead, including a fair amount of
latency, involved in becoming a committer. I don't think that a casual
contributor is really going to want to fill out paper forms and then wait
two weeks before they can commit. It just doesn't improve their experience
sufficiently.
On Thu, Aug 12, 2010 at 3:19 PM, Davanum Srinivas <da...@gmail.com> wrote:
> Todd,
>
> Would opening trunk to Commit-Then-Review and maintaining branches
> using Review-Then-Commit help? That would involve folks using stable
> branches in production...
>
> -- dims
>
>
> On Thu, Aug 12, 2010 at 6:14 PM, Joe Schaefer <jo...@yahoo.com>
> wrote:
> > ----- Original Message ----
> >
> >> From: Todd Lipcon <to...@cloudera.com>
> >> To: thrift-dev@incubator.apache.org
> >> Sent: Thu, August 12, 2010 6:01:19 PM
> >> Subject: Re: time for a reboot?
> >
> >> Hey look, a thread about me!
> >>
> >> The majority of my contributions were at my previous job, but I did get
> >> committership and do the 0.2 release after joining Cloudera as Doug
> said.
> >> Cloudera does use Thrift internally, so having a stable release out was
> >> important for us.
> >>
> >> I haven't been as involved in further releases because frankly, Thrift
> does
> >> what it's supposed to do and does a good job of it. What the ASF seems
> to
> >> see as a stagnating project seems to me to just be a mature one -
> Thrift has
> >> a single purpose, achieves it effectively, and does a good job for lots
> and
> >> lots of people including both my former and current employers. The
> major
> >> issues I've run into (and seen coworkers run into) have had to do with
> the
> >> release packaging and build, which we've improved a bit, and will
> improve on
> >> the distribution side of things as people like Debian start packaging
> the
> >> bits.
> >
> > My concern is more that Thrift has become a 1-man show over the past
> > year than that there is stagnation here. Jira tickets get filed, commits
> > happen, and eventually releases happen, but that's all being done by the
> > heroism of Bryan. Apache projects are collaborative in nature, and
> > usually committers care enough about one another not to let one person
> > carry the project along all by themselves. If there isn't sufficient
> > interest amongst the current committers to participate in development,
> > perhaps we should be recruiting from those filing patches in Jira.
> >
> > With respect to commit-then-review, httpd has had that as its policy
> since
> > the very beginning, and it manages to produce consistently stable
> releases.
> > Ditto for the subversion project. Hadoop is certainly not the model of
> > Apache-style version-control tree management that others should aspire
> to,
> > FWIW. There are serious internal concerns about the overall health of
> the
> > hadoop development ecosystem as it continues to evolve towards a 1.0
> release.
> >
> >
> >
> >
>
>
>
> --
> Davanum Srinivas :: http://davanum.wordpress.com
>
Re: time for a reboot?
Posted by Todd Lipcon <to...@cloudera.com>.
On Thu, Aug 12, 2010 at 6:19 PM, Davanum Srinivas <da...@gmail.com> wrote:
> Todd,
>
> Would opening trunk to Commit-Then-Review and maintaining branches
> using Review-Then-Commit help? That would involve folks using stable
> branches in production...
>
>
Perhaps my perception is just skewed from my experience in closed source as
well as other open-source projects, but it's always been the opposite in my
experience. "Experimental" work would happen in branches, with "commit as
you go", and then if the experimental branch is proven to be worthy, it is
reviewed and merged into trunk. Thus trunk stays reasonably stable, which
makes it easier to cut releases without major stabilization work.
-Todd
>
>
> On Thu, Aug 12, 2010 at 6:14 PM, Joe Schaefer <jo...@yahoo.com>
> wrote:
> > ----- Original Message ----
> >
> >> From: Todd Lipcon <to...@cloudera.com>
> >> To: thrift-dev@incubator.apache.org
> >> Sent: Thu, August 12, 2010 6:01:19 PM
> >> Subject: Re: time for a reboot?
> >
> >> Hey look, a thread about me!
> >>
> >> The majority of my contributions were at my previous job, but I did get
> >> committership and do the 0.2 release after joining Cloudera as Doug
> said.
> >> Cloudera does use Thrift internally, so having a stable release out was
> >> important for us.
> >>
> >> I haven't been as involved in further releases because frankly, Thrift
> does
> >> what it's supposed to do and does a good job of it. What the ASF seems
> to
> >> see as a stagnating project seems to me to just be a mature one -
> Thrift has
> >> a single purpose, achieves it effectively, and does a good job for lots
> and
> >> lots of people including both my former and current employers. The
> major
> >> issues I've run into (and seen coworkers run into) have had to do with
> the
> >> release packaging and build, which we've improved a bit, and will
> improve on
> >> the distribution side of things as people like Debian start packaging
> the
> >> bits.
> >
> > My concern is more that Thrift has become a 1-man show over the past
> > year than that there is stagnation here. Jira tickets get filed, commits
> > happen, and eventually releases happen, but that's all being done by the
> > heroism of Bryan. Apache projects are collaborative in nature, and
> > usually committers care enough about one another not to let one person
> > carry the project along all by themselves. If there isn't sufficient
> > interest amongst the current committers to participate in development,
> > perhaps we should be recruiting from those filing patches in Jira.
> >
> > With respect to commit-then-review, httpd has had that as its policy
> since
> > the very beginning, and it manages to produce consistently stable
> releases.
> > Ditto for the subversion project. Hadoop is certainly not the model of
> > Apache-style version-control tree management that others should aspire
> to,
> > FWIW. There are serious internal concerns about the overall health of
> the
> > hadoop development ecosystem as it continues to evolve towards a 1.0
> release.
> >
> >
> >
> >
>
>
>
> --
> Davanum Srinivas :: http://davanum.wordpress.com
>
--
Todd Lipcon
Software Engineer, Cloudera
Re: time for a reboot?
Posted by Davanum Srinivas <da...@gmail.com>.
Todd,
Would opening trunk to Commit-Then-Review and maintaining branches
using Review-Then-Commit help? That would involve folks using stable
branches in production...
-- dims
On Thu, Aug 12, 2010 at 6:14 PM, Joe Schaefer <jo...@yahoo.com> wrote:
> ----- Original Message ----
>
>> From: Todd Lipcon <to...@cloudera.com>
>> To: thrift-dev@incubator.apache.org
>> Sent: Thu, August 12, 2010 6:01:19 PM
>> Subject: Re: time for a reboot?
>
>> Hey look, a thread about me!
>>
>> The majority of my contributions were at my previous job, but I did get
>> committership and do the 0.2 release after joining Cloudera as Doug said.
>> Cloudera does use Thrift internally, so having a stable release out was
>> important for us.
>>
>> I haven't been as involved in further releases because frankly, Thrift does
>> what it's supposed to do and does a good job of it. What the ASF seems to
>> see as a stagnating project seems to me to just be a mature one - Thrift has
>> a single purpose, achieves it effectively, and does a good job for lots and
>> lots of people including both my former and current employers. The major
>> issues I've run into (and seen coworkers run into) have had to do with the
>> release packaging and build, which we've improved a bit, and will improve on
>> the distribution side of things as people like Debian start packaging the
>> bits.
>
> My concern is more that Thrift has become a 1-man show over the past
> year than that there is stagnation here. Jira tickets get filed, commits
> happen, and eventually releases happen, but that's all being done by the
> heroism of Bryan. Apache projects are collaborative in nature, and
> usually committers care enough about one another not to let one person
> carry the project along all by themselves. If there isn't sufficient
> interest amongst the current committers to participate in development,
> perhaps we should be recruiting from those filing patches in Jira.
>
> With respect to commit-then-review, httpd has had that as its policy since
> the very beginning, and it manages to produce consistently stable releases.
> Ditto for the subversion project. Hadoop is certainly not the model of
> Apache-style version-control tree management that others should aspire to,
> FWIW. There are serious internal concerns about the overall health of the
> hadoop development ecosystem as it continues to evolve towards a 1.0 release.
>
>
>
>
--
Davanum Srinivas :: http://davanum.wordpress.com
Re: time for a reboot?
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Todd Lipcon <to...@cloudera.com>
> To: thrift-dev@incubator.apache.org
> Sent: Thu, August 12, 2010 6:01:19 PM
> Subject: Re: time for a reboot?
> Hey look, a thread about me!
>
> The majority of my contributions were at my previous job, but I did get
> committership and do the 0.2 release after joining Cloudera as Doug said.
> Cloudera does use Thrift internally, so having a stable release out was
> important for us.
>
> I haven't been as involved in further releases because frankly, Thrift does
> what it's supposed to do and does a good job of it. What the ASF seems to
> see as a stagnating project seems to me to just be a mature one - Thrift has
> a single purpose, achieves it effectively, and does a good job for lots and
> lots of people including both my former and current employers. The major
> issues I've run into (and seen coworkers run into) have had to do with the
> release packaging and build, which we've improved a bit, and will improve on
> the distribution side of things as people like Debian start packaging the
> bits.
My concern is more that Thrift has become a 1-man show over the past
year than that there is stagnation here. Jira tickets get filed, commits
happen, and eventually releases happen, but that's all being done by the
heroism of Bryan. Apache projects are collaborative in nature, and
usually committers care enough about one another not to let one person
carry the project along all by themselves. If there isn't sufficient
interest amongst the current committers to participate in development,
perhaps we should be recruiting from those filing patches in Jira.
With respect to commit-then-review, httpd has had that as its policy since
the very beginning, and it manages to produce consistently stable releases.
Ditto for the subversion project. Hadoop is certainly not the model of
Apache-style version-control tree management that others should aspire to,
FWIW. There are serious internal concerns about the overall health of the
hadoop development ecosystem as it continues to evolve towards a 1.0 release.
Re: time for a reboot?
Posted by Todd Lipcon <to...@cloudera.com>.
On Thu, Aug 12, 2010 at 4:50 PM, Doug Cutting <cu...@apache.org> wrote:
> On 08/12/2010 01:38 PM, David Reiss wrote:
>
>> Todd specifically told us that he did not care about getting commit
>> access.
>>
>
> The first proposal of Todd as committer I find was by Esteve Fernandez on
> 24 December 2008, to which you responded:
>
> "I don't think that is necessary. As long as a committer can check in
> patches that are approved, I don't know of any reason that the primary
> reviewer needs to be a committer."
>
> Todd then said:
>
> "While I'm flattered to be nominated, I'll agree with David here --
> especially given the git-friendly workflow here, I've never had any issues
> getting patches in on the Erlang bindings or elsewhere."
>
> "Necessary" is not the same as "deserved" nor "cared about".
>
>
> Todd seems to have lost interest in further work here.
>>>
>> This is because Todd changed jobs, and his new employer does not use
>> Thrift.
>>
>
> Todd has not recently changed employment. He continues to work at
> Cloudera.
>
> Hey look, a thread about me!
The majority of my contributions were at my previous job, but I did get
committership and do the 0.2 release after joining Cloudera as Doug said.
Cloudera does use Thrift internally, so having a stable release out was
important for us.
I haven't been as involved in further releases because frankly, Thrift does
what it's supposed to do and does a good job of it. What the ASF seems to
see as a stagnating project seems to me to just be a mature one - Thrift has
a single purpose, achieves it effectively, and does a good job for lots and
lots of people including both my former and current employers. The major
issues I've run into (and seen coworkers run into) have had to do with the
release packaging and build, which we've improved a bit, and will improve on
the distribution side of things as people like Debian start packaging the
bits.
I don't have the data offhand, but I remember looking at some point last
year at the release velocity for similarly mature projects and found that
Thrift's is not out of the ordinary. For example, APR seems to have released
pretty infrequently in recent years, and most of the releases have had just
a couple of commits worth of changes. The actual commit velocity to Thrift
was much higher, last I looked. Although Thrift is young in the incubator,
it's important to realize that it was already a mature project when it
entered -- in fact it was a mature second-generation project, having grown
out of a previous system internal to Facebook. So lots of experimentation is
something that the community doesn't want to see happening in trunk - it's
hard to experiment on an infrastructure project in ways that won't break
APIs or wire protocols, and those are the two things that are most important
about the project.
On a side note, I am big -1 on commit-then-review. I've been told it's the
"apache way", but none of the Apache projects I've worked on (Hadoop,
Thrift, Cassandra) have been operated like that, nor have any of the
internal infrastructure projects I've worked on at any company larger than
10 engineers. It may make sense in certain projects, but in general it seems
unsafe, and I wouldn't really trust most code bases developed in this
fashion.
Thanks
-Todd
--
Todd Lipcon
Software Engineer, Cloudera
Re: time for a reboot?
Posted by Doug Cutting <cu...@apache.org>.
On 08/12/2010 01:38 PM, David Reiss wrote:
> Todd specifically told us that he did not care about getting commit
> access.
The first proposal of Todd as committer I find was by Esteve Fernandez
on 24 December 2008, to which you responded:
"I don't think that is necessary. As long as a committer can check in
patches that are approved, I don't know of any reason that the primary
reviewer needs to be a committer."
Todd then said:
"While I'm flattered to be nominated, I'll agree with David here --
especially given the git-friendly workflow here, I've never had any
issues getting patches in on the Erlang bindings or elsewhere."
"Necessary" is not the same as "deserved" nor "cared about".
>> Todd seems to have lost interest in further work here.
> This is because Todd changed jobs, and his new employer does not use
> Thrift.
Todd has not recently changed employment. He continues to work at Cloudera.
Doug
Re: time for a reboot?
Posted by David Reiss <dr...@facebook.com>.
> 1) Facebook submitted the code grant over a year after
> the code was checked into svn.
I'm pretty sure this is incorrect. The documents submitted by Facebook
were lost *twice* by Apache, as well as several of the ICLAs submitted
by non-Facebook contributors.
> It was only after arm-twisting by both me and Upayavira that Todd
> Lipcon was offered commit in order to deal with the issues and cut a
> release.
Todd specifically told us that he did not care about getting commit
access.
> Todd seems to have lost interest in further work here.
This is because Todd changed jobs, and his new employer does not use
Thrift.
> 2) When Upayavira or I or anyone else ask questions about
> the project and its future here, Facebook devs always
> speak on behalf of the devs instead of encouraging input
> from others.
Well, I can just speak for myself, but I respond to these emails because
I'm trying to be helpful. It sounds like it would be more helpful for
me to encourage others to respond instead, so I'll be doing this from
now on. Sorry for the misunderstanding.
> 3) Instant releases are counter to Apache's goals for code
> management and distribution policies. As dev tools they
> are tolerable, but when end-users are told to use those
> instead of true releases they are not.
I'm not sure if I've never told an end-user to use an instant release
instead of a true release. If I have, I'm pretty sure it was before 0.2
was released. The instant releases are just there so people who want to
use trunk but not install autoconf and friends can do so. No one has
ever told me that maintaining this page is harming Thrift, but I'd be
more than happy to shut it down if that is the case.
> While I haven't seen commits being vetoed, I also haven't seen commits
> get discussed post-commit, which means the review is happening prior
> to commit instead of post commit. That should be addressed by the
> community
When we started the project, we were told that we were free to choose
between a "review-then-commit" or "commit-then-review" model, and we
(which includes non-Facebook contributors) chose the former. If this is
no longer considered good practice, I suppose we could switch models.
--David
On 08/12/2010 01:26 PM, Joe Schaefer wrote:
>
>
>
>
> ----- Original Message ----
>> From: David Reiss <dr...@facebook.com>
>> To: thrift-dev@incubator.apache.org
>> Sent: Thu, August 12, 2010 4:09:58 PM
>> Subject: Re: time for a reboot?
>>
>> Can you be more specific about what you consider
>> "downward pressure"?
>
> 1) Facebook submitted the code grant over a year after
> the code was checked into svn. As it turns out Facebook
> had done a poor job of managing the intellectual assets
> therein, and did little to help me chase down people with
> interests in the codebase. When suggestions were made
> by me as to what tasks needed to be carried out by the
> current committers to deal with the situation, nothing
> was done. It was only after arm-twisting by both me
> and Upayavira that Todd Lipcon was offered commit in
> order to deal with the issues and cut a release. Nobody
> has been considered for commit by this project since
> then, and Todd seems to have lost interest in further
> work here.
>
> The community had no idea why it took so long for thrift
> to cut a release, but the fact is that 90% of the delay
> was caused by Facebook. Apache simply had to clean up
> the mess, despite being blamed for the delay by others.
>
> 2) When Upayavira or I or anyone else ask questions about
> the project and its future here, Facebook devs always
> speak on behalf of the devs instead of encouraging input
> from others. The answers we get amount to the bare minimum
> required not to shut the project down, and it is a shame
> that other devs are not encouraged to speak for themselves
> or their own interests in the project.
>
> 3) Instant releases are counter to Apache's goals for code
> management and distribution policies. As dev tools they
> are tolerable, but when end-users are told to use those
> instead of true releases they are not.
>
> 4) Running trunk in production is poor practice and puts
> too much pressure on other committers to maintain stability
> in trunk. While I haven't seen commits being vetoed,
> I also haven't seen commits get discussed post-commit,
> which means the review is happening prior to commit instead
> of post commit. That should be addressed by the community
> by doing more experimentation in trunk, and once the project
> hits 1.0 it should cut a stable branch and backport trunk
> work to it. For examples on best practice for managing
> subversion trees have a look at the httpd or subversion
> project.
>
> I could go on, but that should be a sufficient start.
>
>>
>> On 08/12/2010 12:16 PM, Joe Schaefer wrote:
>>> It has come to my attention that this project has
>>> made no effort to maintain its list of PPMC members.
>>> A best-effort was made by Gavin McDonald to construct
>>> that list from the subscriber base to thrift-private@
>>> which may be found here:
>>>
>>> http://incubator.apache.org/projects/thrift
>>>
>>> This project remains at a crossroads, and my personal
>>> graduation vote based on the current trajectory would
>>> not be favorable.
>>>
>>> Apache projects are not cathedrals, they are bazaars.
>>> The committers on the project are facilitators, not
>>> gatekeepers. Every person who has ever submitted a patch
>>> to either jira or this mailing list should be encouraged by
>>> the existing devs to become a committer on this project,
>>> but that never happens here. Instead people fork,
>>> like what happened with c-thrift. That is not goodness
>>> from an Apache standpoint; it would be far better to
>>> create a sandbox in the subversion tree for experimentation
>>> by community members.
>>>
>>> Trunk should be treated as Commit-then-Review. It is
>>> a-ok to break it, and anyone running trunk in production
>>> better be prepared to deal with the fallout of that
>>> decision.
>>>
>>> Look, cassandra came into Apache a year or so after
>>> thrift did, and they have already graduated. Part of
>>> the reason why they have been successful where thrift
>>> has not is because the Facebook devs there were not
>>> allowed to place downward pressure on the community
>>> the way they have here. The sooner this community
>>> starts routing around them, the more likely this
>>> project has a chance of real success at Apache.
>>>
>>> I have asked for special permission from my colleagues
>>> in the Incubator to experiment with processes designed
>>> to get out of your way in as far as it is possible,
>>> so there can be no excuses as to why Thrift is not
>>> succeeding except for the fact that the devs have
>>> not done an adequate job of growing the community.
>>> I expect that permission to be granted very soon,
>>> and would like those committers on this project
>>> who still care about it to take advantage of this
>>> special opportunity before it's too late. So far
>>> Bryan is the only person I would trust to make an
>>> IPMC member or serve as Chair for this project
>>> should it pursue graduation, but if others start
>>> showing more active interest I am more than happy
>>> to consider them.
>>>
>>>
>>>
>>
>
>
>
Re: time for a reboot?
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: David Reiss <dr...@facebook.com>
> To: thrift-dev@incubator.apache.org
> Sent: Thu, August 12, 2010 4:09:58 PM
> Subject: Re: time for a reboot?
>
> Can you be more specific about what you consider
> "downward pressure"?
1) Facebook submitted the code grant over a year after
the code was checked into svn. As it turns out Facebook
had done a poor job of managing the intellectual assets
therein, and did little to help me chase down people with
interests in the codebase. When suggestions were made
by me as to what tasks needed to be carried out by the
current committers to deal with the situation, nothing
was done. It was only after arm-twisting by both me
and Upayavira that Todd Lipcon was offered commit in
order to deal with the issues and cut a release. Nobody
has been considered for commit by this project since
then, and Todd seems to have lost interest in further
work here.
The community had no idea why it took so long for thrift
to cut a release, but the fact is that 90% of the delay
was caused by Facebook. Apache simply had to clean up
the mess, despite being blamed for the delay by others.
2) When Upayavira or I or anyone else ask questions about
the project and its future here, Facebook devs always
speak on behalf of the devs instead of encouraging input
from others. The answers we get amount to the bare minimum
required not to shut the project down, and it is a shame
that other devs are not encouraged to speak for themselves
or their own interests in the project.
3) Instant releases are counter to Apache's goals for code
management and distribution policies. As dev tools they
are tolerable, but when end-users are told to use those
instead of true releases they are not.
4) Running trunk in production is poor practice and puts
too much pressure on other committers to maintain stability
in trunk. While I haven't seen commits being vetoed,
I also haven't seen commits get discussed post-commit,
which means the review is happening prior to commit instead
of post commit. That should be addressed by the community
by doing more experimentation in trunk, and once the project
hits 1.0 it should cut a stable branch and backport trunk
work to it. For examples on best practice for managing
subversion trees have a look at the httpd or subversion
project.
I could go on, but that should be a sufficient start.
>
> On 08/12/2010 12:16 PM, Joe Schaefer wrote:
> > It has come to my attention that this project has
> > made no effort to maintain its list of PPMC members.
> > A best-effort was made by Gavin McDonald to construct
> > that list from the subscriber base to thrift-private@
> > which may be found here:
> >
> > http://incubator.apache.org/projects/thrift
> >
> > This project remains at a crossroads, and my personal
> > graduation vote based on the current trajectory would
> > not be favorable.
> >
> > Apache projects are not cathedrals, they are bazaars.
> > The committers on the project are facilitators, not
> > gatekeepers. Every person who has ever submitted a patch
> > to either jira or this mailing list should be encouraged by
> > the existing devs to become a committer on this project,
> > but that never happens here. Instead people fork,
> > like what happened with c-thrift. That is not goodness
> > from an Apache standpoint; it would be far better to
> > create a sandbox in the subversion tree for experimentation
> > by community members.
> >
> > Trunk should be treated as Commit-then-Review. It is
> > a-ok to break it, and anyone running trunk in production
> > better be prepared to deal with the fallout of that
> > decision.
> >
> > Look, cassandra came into Apache a year or so after
> > thrift did, and they have already graduated. Part of
> > the reason why they have been successful where thrift
> > has not is because the Facebook devs there were not
> > allowed to place downward pressure on the community
> > the way they have here. The sooner this community
> > starts routing around them, the more likely this
> > project has a chance of real success at Apache.
> >
> > I have asked for special permission from my colleagues
> > in the Incubator to experiment with processes designed
> > to get out of your way in as far as it is possible,
> > so there can be no excuses as to why Thrift is not
> > succeeding except for the fact that the devs have
> > not done an adequate job of growing the community.
> > I expect that permission to be granted very soon,
> > and would like those committers on this project
> > who still care about it to take advantage of this
> > special opportunity before it's too late. So far
> > Bryan is the only person I would trust to make an
> > IPMC member or serve as Chair for this project
> > should it pursue graduation, but if others start
> > showing more active interest I am more than happy
> > to consider them.
> >
> >
> >
>
Re: time for a reboot?
Posted by David Reiss <dr...@facebook.com>.
Can you be more specific about what you consider "downward pressure"?
--David
On 08/12/2010 12:16 PM, Joe Schaefer wrote:
> It has come to my attention that this project has
> made no effort to maintain its list of PPMC members.
> A best-effort was made by Gavin McDonald to construct
> that list from the subscriber base to thrift-private@
> which may be found here:
>
> http://incubator.apache.org/projects/thrift
>
> This project remains at a crossroads, and my personal
> graduation vote based on the current trajectory would
> not be favorable.
>
> Apache projects are not cathedrals, they are bazaars.
> The committers on the project are facilitators, not
> gatekeepers. Every person who has ever submitted a patch
> to either jira or this mailing list should be encouraged by
> the existing devs to become a committer on this project,
> but that never happens here. Instead people fork,
> like what happened with c-thrift. That is not goodness
> from an Apache standpoint; it would be far better to
> create a sandbox in the subversion tree for experimentation
> by community members.
>
> Trunk should be treated as Commit-then-Review. It is
> a-ok to break it, and anyone running trunk in production
> better be prepared to deal with the fallout of that
> decision.
>
> Look, cassandra came into Apache a year or so after
> thrift did, and they have already graduated. Part of
> the reason why they have been successful where thrift
> has not is because the Facebook devs there were not
> allowed to place downward pressure on the community
> the way they have here. The sooner this community
> starts routing around them, the more likely this
> project has a chance of real success at Apache.
>
> I have asked for special permission from my colleagues
> in the Incubator to experiment with processes designed
> to get out of your way in as far as it is possible,
> so there can be no excuses as to why Thrift is not
> succeeding except for the fact that the devs have
> not done an adequate job of growing the community.
> I expect that permission to be granted very soon,
> and would like those committers on this project
> who still care about it to take advantage of this
> special opportunity before it's too late. So far
> Bryan is the only person I would trust to make an
> IPMC member or serve as Chair for this project
> should it pursue graduation, but if others start
> showing more active interest I am more than happy
> to consider them.
>
>
>
Re: time for a reboot?
Posted by uncle mantis <un...@gmail.com>.
Get a Mac.
Sorry, i just had to contribute somehow :)
Regards,
Michael
On Fri, Aug 13, 2010 at 8:16 AM, James King <Ja...@dell.com> wrote:
> I'm not a committer on the project, but here's my two cents.
>
> There is a fine balance between opening the flood gates and having a
> potentially constantly broken trunk, and having a trunk where folks know
> that once they have run a sufficient test suite that they have not
> broken things. There is no such comprehensive test suite in Thrift
> today, and given the cross-platform, cross-language nature of the
> project it will take a good amount of time and energy to make that
> happen. In fact, a comprehensive build of the project requires at least
> a linux and a windows machine, since you cannot create the C# runtime
> and test it on anything else. Moving to something like cmake for
> cross-platform make management would also be a good idea.
>
> Once such a test suite is in place, it would make much more sense to
> allow global commits then. Until that time, some controls are needed,
> and whomever is committing something does need to make sure they have
> not broken something by actually running all the various tests that
> exist.
>
> I submitted a major architecture update into Jira this week for two-way
> communication, multiple services on a connection, multiple outstanding
> requests on either end, and tight certificate based authentication to
> the C# runtime and compiler. Moving those concepts into other languages
> is also a task, but again requires a good testing framework to build on.
> So that's the theme of my message; beef up the test suite (and perhaps
> the build suite) so we all have better verification of changes. This
> opens up the door to the other things that have been discussed.
>
> Thanks,
>
> Jim
>
>
Re: time for a reboot?
Posted by Michael Greene <mi...@gmail.com>.
The C# runtime builds and runs on Linux and OS X just fine, and I have used it on both.
Michael
On Aug 13, 2010, at 9:16 AM, "James King" <Ja...@Dell.com> wrote:
> I'm not a committer on the project, but here's my two cents.
>
> There is a fine balance between opening the flood gates and having a
> potentially constantly broken trunk, and having a trunk where folks know
> that once they have run a sufficient test suite that they have not
> broken things. There is no such comprehensive test suite in Thrift
> today, and given the cross-platform, cross-language nature of the
> project it will take a good amount of time and energy to make that
> happen. In fact, a comprehensive build of the project requires at least
> a linux and a windows machine, since you cannot create the C# runtime
> and test it on anything else. Moving to something like cmake for
> cross-platform make management would also be a good idea.
>
> Once such a test suite is in place, it would make much more sense to
> allow global commits then. Until that time, some controls are needed,
> and whomever is committing something does need to make sure they have
> not broken something by actually running all the various tests that
> exist.
>
> I submitted a major architecture update into Jira this week for two-way
> communication, multiple services on a connection, multiple outstanding
> requests on either end, and tight certificate based authentication to
> the C# runtime and compiler. Moving those concepts into other languages
> is also a task, but again requires a good testing framework to build on.
> So that's the theme of my message; beef up the test suite (and perhaps
> the build suite) so we all have better verification of changes. This
> opens up the door to the other things that have been discussed.
>
> Thanks,
>
> Jim
>
Re: time for a reboot?
Posted by Bryan Duxbury <br...@rapleaf.com>.
I agree with this. Big +1 to making the test suite more comprehensive.
On Fri, Aug 13, 2010 at 6:16 AM, James King <Ja...@dell.com> wrote:
> I'm not a committer on the project, but here's my two cents.
>
> There is a fine balance between opening the flood gates and having a
> potentially constantly broken trunk, and having a trunk where folks know
> that once they have run a sufficient test suite that they have not
> broken things. There is no such comprehensive test suite in Thrift
> today, and given the cross-platform, cross-language nature of the
> project it will take a good amount of time and energy to make that
> happen. In fact, a comprehensive build of the project requires at least
> a linux and a windows machine, since you cannot create the C# runtime
> and test it on anything else. Moving to something like cmake for
> cross-platform make management would also be a good idea.
>
> Once such a test suite is in place, it would make much more sense to
> allow global commits then. Until that time, some controls are needed,
> and whomever is committing something does need to make sure they have
> not broken something by actually running all the various tests that
> exist.
>
> I submitted a major architecture update into Jira this week for two-way
> communication, multiple services on a connection, multiple outstanding
> requests on either end, and tight certificate based authentication to
> the C# runtime and compiler. Moving those concepts into other languages
> is also a task, but again requires a good testing framework to build on.
> So that's the theme of my message; beef up the test suite (and perhaps
> the build suite) so we all have better verification of changes. This
> opens up the door to the other things that have been discussed.
>
> Thanks,
>
> Jim
>
>
Re: time for a reboot?
Posted by uncle mantis <un...@gmail.com>.
I want to appologize about the Mac comment. I thought that this was a
different e-mail list when I wrote =(
Regards,
Michael
On Fri, Aug 13, 2010 at 11:11 AM, Rajesh Malepati <ch...@gmail.com>wrote:
> On Fri, Aug 13, 2010 at 6:46 PM, James King <Ja...@dell.com> wrote:
> > I'm not a committer on the project, but here's my two cents.
> >
> > There is a fine balance between opening the flood gates and having a
> > potentially constantly broken trunk, and having a trunk where folks know
> > that once they have run a sufficient test suite that they have not
> > broken things. There is no such comprehensive test suite in Thrift
> > today, and given the cross-platform, cross-language nature of the
> > project it will take a good amount of time and energy to make that
> > happen. In fact, a comprehensive build of the project requires at least
> > a linux and a windows machine, since you cannot create the C# runtime
> > and test it on anything else. Moving to something like cmake for
> > cross-platform make management would also be a good idea.
> >
>
> +1 on cmake. I currently use it for some of my projects. A LOT easier
> to use than the GNU Autotools.
>
Re: time for a reboot?
Posted by Rajesh Malepati <ch...@gmail.com>.
On Fri, Aug 13, 2010 at 6:46 PM, James King <Ja...@dell.com> wrote:
> I'm not a committer on the project, but here's my two cents.
>
> There is a fine balance between opening the flood gates and having a
> potentially constantly broken trunk, and having a trunk where folks know
> that once they have run a sufficient test suite that they have not
> broken things. There is no such comprehensive test suite in Thrift
> today, and given the cross-platform, cross-language nature of the
> project it will take a good amount of time and energy to make that
> happen. In fact, a comprehensive build of the project requires at least
> a linux and a windows machine, since you cannot create the C# runtime
> and test it on anything else. Moving to something like cmake for
> cross-platform make management would also be a good idea.
>
+1 on cmake. I currently use it for some of my projects. A LOT easier
to use than the GNU Autotools.
RE: time for a reboot?
Posted by James King <Ja...@Dell.com>.
I'm not a committer on the project, but here's my two cents.
There is a fine balance between opening the flood gates and having a
potentially constantly broken trunk, and having a trunk where folks know
that once they have run a sufficient test suite that they have not
broken things. There is no such comprehensive test suite in Thrift
today, and given the cross-platform, cross-language nature of the
project it will take a good amount of time and energy to make that
happen. In fact, a comprehensive build of the project requires at least
a linux and a windows machine, since you cannot create the C# runtime
and test it on anything else. Moving to something like cmake for
cross-platform make management would also be a good idea.
Once such a test suite is in place, it would make much more sense to
allow global commits then. Until that time, some controls are needed,
and whomever is committing something does need to make sure they have
not broken something by actually running all the various tests that
exist.
I submitted a major architecture update into Jira this week for two-way
communication, multiple services on a connection, multiple outstanding
requests on either end, and tight certificate based authentication to
the C# runtime and compiler. Moving those concepts into other languages
is also a task, but again requires a good testing framework to build on.
So that's the theme of my message; beef up the test suite (and perhaps
the build suite) so we all have better verification of changes. This
opens up the door to the other things that have been discussed.
Thanks,
Jim
Re: time for a reboot?
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Michael Lum <mi...@openx.org>
> To: thrift-dev@incubator.apache.org
> Cc: Joe Schaefer <jo...@yahoo.com>
> Sent: Thu, August 12, 2010 5:09:39 PM
> Subject: Re: time for a reboot?
>
> I still intend to submit a patch implementing thrift-c-glib,
> and then maintaining it, but have been doing the work on
> github to clean it up. It doesn't really matter to me where
> I do the work. We're just after a pure C, leak-free code
> generated interface to Thrift, and continuing the previous
> work that had been contributed seemed like the right way
> to get it.
Right, this is the sort of activity a healthy Apache project
would encourage you to do in the Apache svn repo for thrift.
Hoarding the commit bit isn't what we should be encouraging
from the thrift committers.
> Commercially speaking, Thrift is a key component of our
> service architecture, so we have a vested interest in its
> stability. We pretty much internally version our own thrift
> releases internally by taking stable-ish trunk revisions,
> forking, patching and versioning, and then building packages
> (rpms and debs) for the engineers to use here. We used to do
> that with Cassandra, but now we are able to use the release
> versions. For selfish reasons, I would be glad to offer our
> developers' time to make Thrift builds and releases easier and
> more convenient, although as you may have seen from our
> patch submissions, we'd probably keep obstinately pushing to get
> the source build to work on stock CentOS 5 (see the autoconf
> 2.59 JIRA tickets).
Would love to see you be able to rely on thrift releases as
much as you currently do for cassandra; absolutely this is
great feedback.
Re: time for a reboot?
Posted by Michael Lum <mi...@openx.org>.
I still intend to submit a patch implementing thrift-c-glib, and then
maintaining it, but have been doing the work on github to clean it up.
It doesn't really matter to me where I do the work. We're just after a
pure C, leak-free code generated interface to Thrift, and continuing the
previous work that had been contributed seemed like the right way to get it.
Commercially speaking, Thrift is a key component of our service
architecture, so we have a vested interest in its stability. We pretty
much internally version our own thrift releases internally by taking
stable-ish trunk revisions, forking, patching and versioning, and then
building packages (rpms and debs) for the engineers to use here. We
used to do that with Cassandra, but now we are able to use the release
versions. For selfish reasons, I would be glad to offer our developers'
time to make Thrift builds and releases easier and more convenient,
although as you may have seen from our patch submissions, we'd probably
keep obstinately pushing to get the source build to work on stock CentOS
5 (see the autoconf 2.59 JIRA tickets).
On 8/12/2010 12:16 PM, Joe Schaefer wrote:
> It has come to my attention that this project has
> made no effort to maintain its list of PPMC members.
> A best-effort was made by Gavin McDonald to construct
> that list from the subscriber base to thrift-private@
> which may be found here:
>
> http://incubator.apache.org/projects/thrift
>
> This project remains at a crossroads, and my personal
> graduation vote based on the current trajectory would
> not be favorable.
>
> Apache projects are not cathedrals, they are bazaars.
> The committers on the project are facilitators, not
> gatekeepers. Every person who has ever submitted a patch
> to either jira or this mailing list should be encouraged by
> the existing devs to become a committer on this project,
> but that never happens here. Instead people fork,
> like what happened with c-thrift. That is not goodness
> from an Apache standpoint; it would be far better to
> create a sandbox in the subversion tree for experimentation
> by community members.
>
> Trunk should be treated as Commit-then-Review. It is
> a-ok to break it, and anyone running trunk in production
> better be prepared to deal with the fallout of that
> decision.
>
> Look, cassandra came into Apache a year or so after
> thrift did, and they have already graduated. Part of
> the reason why they have been successful where thrift
> has not is because the Facebook devs there were not
> allowed to place downward pressure on the community
> the way they have here. The sooner this community
> starts routing around them, the more likely this
> project has a chance of real success at Apache.
>
> I have asked for special permission from my colleagues
> in the Incubator to experiment with processes designed
> to get out of your way in as far as it is possible,
> so there can be no excuses as to why Thrift is not
> succeeding except for the fact that the devs have
> not done an adequate job of growing the community.
> I expect that permission to be granted very soon,
> and would like those committers on this project
> who still care about it to take advantage of this
> special opportunity before it's too late. So far
> Bryan is the only person I would trust to make an
> IPMC member or serve as Chair for this project
> should it pursue graduation, but if others start
> showing more active interest I am more than happy
> to consider them.
>
>
>