You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cassandra.apache.org by Matthieu Riou <ma...@offthelip.org> on 2009/11/03 17:20:21 UTC
Graduation?
Hi guys,
I'd be curious to hear others' opinions but I think Cassandra is close to be
ready for graduation (or at least preparing for it). You came a long way
since the original code dump and now you have both diversity and a vibrant
community. You have 3 successful official releases behind you, a larger
committer and PMC group and probably more committers to attract. It's not
been a painless process for sure but it's a good time to look back at what
you've accomplished.
So graduation, whad'ya say?
Matthieu
Re: Graduation?
Posted by Matthieu Riou <ma...@gmail.com>.
Take 10mn to read the following paragraph and the document after:
http://incubator.apache.org/incubation/Incubation_Policy.html#Graduating+from+the+Incubator
http://incubator.apache.org/guides/graduation.html
Then you'll have my take :) What people have been looking at mostly in the
past is diversity and releases. In both cases you seem fine, you have good
diversity with individuals from multiple companies and as I pointed, 3
releases behind your belt. So from a project standpoint I don't see any
roadblocks.
To make it happen, as you will be graduating to a top level project, you'll
need to draft a board resolution which is what the incubator PMC is going to
vote on. Once accepted by the incubator it gets pushed to the board and in
the great majority of cases gets accepted (I'm not aware of any refusal once
a proposal passed the incubator vote).
Most of the board resolution is semi-legalese boilerplate needed by any
respectful corporation :) The two parts that need attention are picking a
chair for the TLP who will be responsible for representing the project in
front (figuratively) of the board and coming up with the project charter
that will scope the PMC. Coming up with a good charter isn't too easy as
it's mostly subjective wording. To get started, look at others' projects
charters, you'll find a few links there:
http://incubator.apache.org/guides/graduation.html#tlp-resolution
You'll have to find a few sentences that define and scope the project well
while surviving the test of time. Then be ready to make a couple of
iterations, the idea is to propose it early on the incubator general mailing
list to get early feedback.
How does that sound?
Matthieu
On Tue, Nov 3, 2009 at 8:58 AM, Jonathan Ellis <jb...@gmail.com> wrote:
> I'd love to graduate.
>
> What do we need to do to make it happen?
>
> On Tue, Nov 3, 2009 at 10:20 AM, Matthieu Riou <ma...@offthelip.org>
> wrote:
> > Hi guys,
> >
> > I'd be curious to hear others' opinions but I think Cassandra is close to
> be
> > ready for graduation (or at least preparing for it). You came a long way
> > since the original code dump and now you have both diversity and a
> vibrant
> > community. You have 3 successful official releases behind you, a larger
> > committer and PMC group and probably more committers to attract. It's not
> > been a painless process for sure but it's a good time to look back at
> what
> > you've accomplished.
> >
> > So graduation, whad'ya say?
> >
> > Matthieu
> >
>
Re: Graduation?
Posted by Jonathan Ellis <jb...@gmail.com>.
I'd love to graduate.
What do we need to do to make it happen?
On Tue, Nov 3, 2009 at 10:20 AM, Matthieu Riou <ma...@offthelip.org> wrote:
> Hi guys,
>
> I'd be curious to hear others' opinions but I think Cassandra is close to be
> ready for graduation (or at least preparing for it). You came a long way
> since the original code dump and now you have both diversity and a vibrant
> community. You have 3 successful official releases behind you, a larger
> committer and PMC group and probably more committers to attract. It's not
> been a painless process for sure but it's a good time to look back at what
> you've accomplished.
>
> So graduation, whad'ya say?
>
> Matthieu
>
Re: Graduation?
Posted by Matthieu Riou <ma...@gmail.com>.
On Thu, Nov 19, 2009 at 11:17 AM, Eric Evans <ee...@rackspace.com> wrote:
> On Wed, 2009-11-18 at 22:26 +0000, ant elder wrote:
> > Looking at whats been said its quite evenly split with about half
> > saying RTC could be ok and half suggesting RTC should be frowned upon.
> > So what to do? Optimistically push on with graduation and hope people
> > don't vote against it due to this? Modify the current commit process
> > somehow?
>
> I didn't think that anyone was able to demonstrate an actual problem.
> There was plenty of discussion about why it's bad, past experiences,
> etc, but no one was able to point at something specific and say, "See,
> this right here is indicative of the shortcomings of your workflow".
>
> That being said, I don't think anyone in the "should be frowned upon"
> camp were swayed, and we have to do what the IPMC tells us to (if we
> want to graduate), so what choice do we have?
>
>
I haven't heard anyone say "I'll -1 Cassandra because they use RTC". There
were concerns and those who have them are free to keep on following the
project. On the other hand, I've heard other folks saying that Cassandra
seemed ready. So I'd say let's go for it.
Matthieu
> --
> Eric Evans
> eevans@rackspace.com
>
>
Re: Graduation?
Posted by Matthieu Riou <ma...@gmail.com>.
My take (and that's just my personal opinion) is that you should gear for
graduation as is and confront the shitstorm :) All arguments have been heard
and while there are good ones on both sides, nobody has convinced anyone.
The underlying idea that the IPMC could enforce a practice that's not
necessarily valid for a given project or at least has not been really proven
to be A Good Thing, even within Apache, is plain wrong if you ask me.
Worst case you get a -1 a can try again later. It happened before, it's
painful but not the end of the world either.
Matthieu
On Mon, Nov 23, 2009 at 9:04 AM, Eric Evans <ee...@rackspace.com> wrote:
> On Fri, 2009-11-20 at 13:09 +0000, ant elder wrote:
> > > That being said, I don't think anyone in the "should be frowned
> > > upon" camp were swayed, and we have to do what the IPMC tells us
> > > to (if we want to graduate), so what choice do we have?
> >
> > The IPMC doesn't like telling poddlings what to do, they like them to
> > work things out for themselves.
>
> I understand what you're saying, and I honestly believe that the
> structure put in place and the the people involved are well-meaning, but
> the simple fact of that matter is that the IPMC is in a position of
> power over this project.
>
> > The question was asked and people gave they views, and some sounded
> > like strongly held views. No one said they would -1 a graduation vote
> > but that may just be because thats not what the question on general@
> > asked. You could ask that specific question, or you could just hold a
> > graduation vote to see. Or you could first try to appease those not in
> > favour of RTC by trying to make some changes
>
> ... and say that we worked it out for ourselves? :)
>
> > - could CTR be tried for a while to see how it goes? Or try CTR for
> > just non-critical bits of code, or only for smaller changes? Maybe it
> > will work now, but if it doesn't you can at least then say look we
> > tried but it doesn't work for this project.
>
> We are using CTR for minor non-intrusive changes, build, scripts,
> documentation, etc.
>
> --
> Eric Evans
> eevans@rackspace.com
>
>
Re: Graduation?
Posted by Eric Evans <ee...@rackspace.com>.
On Fri, 2009-11-20 at 13:09 +0000, ant elder wrote:
> > That being said, I don't think anyone in the "should be frowned
> > upon" camp were swayed, and we have to do what the IPMC tells us
> > to (if we want to graduate), so what choice do we have?
>
> The IPMC doesn't like telling poddlings what to do, they like them to
> work things out for themselves.
I understand what you're saying, and I honestly believe that the
structure put in place and the the people involved are well-meaning, but
the simple fact of that matter is that the IPMC is in a position of
power over this project.
> The question was asked and people gave they views, and some sounded
> like strongly held views. No one said they would -1 a graduation vote
> but that may just be because thats not what the question on general@
> asked. You could ask that specific question, or you could just hold a
> graduation vote to see. Or you could first try to appease those not in
> favour of RTC by trying to make some changes
... and say that we worked it out for ourselves? :)
> - could CTR be tried for a while to see how it goes? Or try CTR for
> just non-critical bits of code, or only for smaller changes? Maybe it
> will work now, but if it doesn't you can at least then say look we
> tried but it doesn't work for this project.
We are using CTR for minor non-intrusive changes, build, scripts,
documentation, etc.
--
Eric Evans
eevans@rackspace.com
Re: Graduation?
Posted by ant elder <an...@gmail.com>.
On Thu, Nov 19, 2009 at 7:17 PM, Eric Evans <ee...@rackspace.com> wrote:
>
> That being said, I don't think anyone in the "should be frowned upon"
> camp were swayed, and we have to do what the IPMC tells us to (if we
> want to graduate), so what choice do we have?
>
The IPMC doesn't like telling poddlings what to do, they like them to
work things out for themselves. The question was asked and people gave
they views, and some sounded like strongly held views. No one said
they would -1 a graduation vote but that may just be because thats not
what the question on general@ asked. You could ask that specific
question, or you could just hold a graduation vote to see. Or you
could first try to appease those not in favour of RTC by trying to
make some changes - could CTR be tried for a while to see how it goes?
Or try CTR for just non-critical bits of code, or only for smaller
changes? Maybe it will work now, but if it doesn't you can at least
then say look we tried but it doesn't work for this project.
...ant
Re: Graduation?
Posted by Eric Evans <ee...@rackspace.com>.
On Wed, 2009-11-18 at 22:26 +0000, ant elder wrote:
> Looking at whats been said its quite evenly split with about half
> saying RTC could be ok and half suggesting RTC should be frowned upon.
> So what to do? Optimistically push on with graduation and hope people
> don't vote against it due to this? Modify the current commit process
> somehow?
I didn't think that anyone was able to demonstrate an actual problem.
There was plenty of discussion about why it's bad, past experiences,
etc, but no one was able to point at something specific and say, "See,
this right here is indicative of the shortcomings of your workflow".
That being said, I don't think anyone in the "should be frowned upon"
camp were swayed, and we have to do what the IPMC tells us to (if we
want to graduate), so what choice do we have?
--
Eric Evans
eevans@rackspace.com
Re: Graduation?
Posted by ant elder <an...@apache.org>.
On Thu, Nov 12, 2009 at 4:20 PM, Jonathan Ellis <jb...@gmail.com> wrote:
> On Thu, Nov 12, 2009 at 1:44 AM, ant elder <an...@gmail.com> wrote:
>> On Sat, Nov 7, 2009 at 8:26 PM, Eric Evans <ee...@rackspace.com> wrote:
>>> On Fri, 2009-11-06 at 11:21 +0000, ant elder wrote:
>>>>
>>>> Can someone explain how this RTC mode is actually working right now,
>>>> what is the process for reviewing, voting, and applying the changes?
>>>
>>> In a practice:
>>>
>>> 1. Folks attach patches to Jira issues, (committers too).
>>> 2. Someone (anyone really) gives it at least a once over and ...
>>> 2a. +1s the change
>>> 2b. provides feedback, (goto #1)
>>> 3. A committer commits the patch
>>>
>>
>> How do you get people to review and +1 the JIRAs, I never see dev list
>> posts asking for JIRA patches to be reviewed so how is that happening?
>>
>> Looking at the commit history its only two people doing 99% of the
>> commits, where are most of the patches coming from? If other
>> committers are submitting patches why is it only those two committing
>> them?
>
> (Looks like this discussion moved to incubator-general.)
>
Its been a while now and the discussion has died down, for those that
don't have it here's the link to that discussion thread:
http://apache.markmail.org/message/hsa4mgzgj2nylegy
Looking at whats been said its quite evenly split with about half
saying RTC could be ok and half suggesting RTC should be frowned upon.
So what to do? Optimistically push on with graduation and hope people
don't vote against it due to this? Modify the current commit process
somehow?
...ant
Re: Graduation?
Posted by Jonathan Ellis <jb...@gmail.com>.
On Thu, Nov 12, 2009 at 1:44 AM, ant elder <an...@gmail.com> wrote:
> On Sat, Nov 7, 2009 at 8:26 PM, Eric Evans <ee...@rackspace.com> wrote:
>> On Fri, 2009-11-06 at 11:21 +0000, ant elder wrote:
>>>
>>> Can someone explain how this RTC mode is actually working right now,
>>> what is the process for reviewing, voting, and applying the changes?
>>
>> In a practice:
>>
>> 1. Folks attach patches to Jira issues, (committers too).
>> 2. Someone (anyone really) gives it at least a once over and ...
>> 2a. +1s the change
>> 2b. provides feedback, (goto #1)
>> 3. A committer commits the patch
>>
>
> How do you get people to review and +1 the JIRAs, I never see dev list
> posts asking for JIRA patches to be reviewed so how is that happening?
>
> Looking at the commit history its only two people doing 99% of the
> commits, where are most of the patches coming from? If other
> committers are submitting patches why is it only those two committing
> them?
(Looks like this discussion moved to incubator-general.)
Re: Graduation?
Posted by ant elder <an...@gmail.com>.
On Sat, Nov 7, 2009 at 8:26 PM, Eric Evans <ee...@rackspace.com> wrote:
> On Fri, 2009-11-06 at 11:21 +0000, ant elder wrote:
>>
>> Can someone explain how this RTC mode is actually working right now,
>> what is the process for reviewing, voting, and applying the changes?
>
> In a practice:
>
> 1. Folks attach patches to Jira issues, (committers too).
> 2. Someone (anyone really) gives it at least a once over and ...
> 2a. +1s the change
> 2b. provides feedback, (goto #1)
> 3. A committer commits the patch
>
How do you get people to review and +1 the JIRAs, I never see dev list
posts asking for JIRA patches to be reviewed so how is that happening?
Looking at the commit history its only two people doing 99% of the
commits, where are most of the patches coming from? If other
committers are submitting patches why is it only those two committing
them?
...ant
Re: Graduation?
Posted by Eric Evans <ee...@rackspace.com>.
On Fri, 2009-11-06 at 11:21 +0000, ant elder wrote:
>
> Can someone explain how this RTC mode is actually working right now,
> what is the process for reviewing, voting, and applying the changes?
In a practice:
1. Folks attach patches to Jira issues, (committers too).
2. Someone (anyone really) gives it at least a once over and ...
2a. +1s the change
2b. provides feedback, (goto #1)
3. A committer commits the patch
Typically, when a change is controversial, invasive, or just touches a
particularly tricky part of the code-base, then more people take notice
and look it over with a greater degree of scrutiny; most of the time
though it's just a quick sanity check, making sure it builds,
passes/includes tests, etc.
We've pretty much pulled the trigger (often within minutes), after the
very first +1 and then rolled it back and/or fixed it if someone points
out a problem after the fact.
I'm personally not a big fan of RTC in general, but if I'm honest, it
has been working pretty well in practice thus far; there are other
aspects of our work-flow that offend my sensibilities worse than
this. :)
--
Eric Evans
eevans@rackspace.com
Re: Graduation?
Posted by Jonathan Ellis <jb...@gmail.com>.
Basically this: http://markmail.org/message/d45dmasuwnda25wd
On Fri, Nov 6, 2009 at 5:21 AM, ant elder <an...@gmail.com> wrote:
> On Thu, Nov 5, 2009 at 11:31 PM, Jonathan Ellis <jb...@gmail.com> wrote:
>> On Thu, Nov 5, 2009 at 5:23 PM, Eric Evans <ee...@rackspace.com> wrote:
>>> On Thu, 2009-11-05 at 17:04 -0600, Michael Greene wrote:
>>>> It was previously proposed that documentation be CTR. I would be in
>>>> favor of this, and extending it to include scripts, licensing, and
>>>> other project management materials.
>>>
>>> I would be in favor of relaxing the RTC "requirement" to be more of an
>>> "understanding", and letting common sense prevail (for as long as that
>>> doesn't prove to be a problem anyway :)).
>>
>> +1 for common sense.
>>
>
> Can someone explain how this RTC mode is actually working right now,
> what is the process for reviewing, voting, and applying the changes?
>
> ...ant
>
Re: Graduation?
Posted by ant elder <an...@gmail.com>.
On Thu, Nov 5, 2009 at 11:31 PM, Jonathan Ellis <jb...@gmail.com> wrote:
> On Thu, Nov 5, 2009 at 5:23 PM, Eric Evans <ee...@rackspace.com> wrote:
>> On Thu, 2009-11-05 at 17:04 -0600, Michael Greene wrote:
>>> It was previously proposed that documentation be CTR. I would be in
>>> favor of this, and extending it to include scripts, licensing, and
>>> other project management materials.
>>
>> I would be in favor of relaxing the RTC "requirement" to be more of an
>> "understanding", and letting common sense prevail (for as long as that
>> doesn't prove to be a problem anyway :)).
>
> +1 for common sense.
>
Can someone explain how this RTC mode is actually working right now,
what is the process for reviewing, voting, and applying the changes?
...ant
Re: Graduation?
Posted by Jonathan Ellis <jb...@gmail.com>.
On Thu, Nov 5, 2009 at 5:23 PM, Eric Evans <ee...@rackspace.com> wrote:
> On Thu, 2009-11-05 at 17:04 -0600, Michael Greene wrote:
>> It was previously proposed that documentation be CTR. I would be in
>> favor of this, and extending it to include scripts, licensing, and
>> other project management materials.
>
> I would be in favor of relaxing the RTC "requirement" to be more of an
> "understanding", and letting common sense prevail (for as long as that
> doesn't prove to be a problem anyway :)).
+1 for common sense.
Re: Graduation?
Posted by Eric Evans <ee...@rackspace.com>.
On Thu, 2009-11-05 at 17:04 -0600, Michael Greene wrote:
> It was previously proposed that documentation be CTR. I would be in
> favor of this, and extending it to include scripts, licensing, and
> other project management materials.
I would be in favor of relaxing the RTC "requirement" to be more of an
"understanding", and letting common sense prevail (for as long as that
doesn't prove to be a problem anyway :)).
Because yes, there is a big difference between wanting to have another
set of eyes on a huge re-factoring of a critical subsystem, and
correcting spelling errors in a README.
--
Eric Evans
eevans@rackspace.com
Re: Graduation?
Posted by Michael Greene <mi...@gmail.com>.
On Thu, Nov 5, 2009 at 4:53 PM, Jonathan Ellis <jb...@gmail.com> wrote:
> So I would argue that RTC is working for us, making sure reviews
> actually happen, while git makes it mostly stay out of our way. I
> _would_ be in favor of being less dogmatic about it
> (https://issues.apache.org/jira/browse/CASSANDRA-528 from earlier
> today is a fine example) but in general I prefer not fixing what ain't
> broke.
It was previously proposed that documentation be CTR. I would be in
favor of this, and extending it to include scripts, licensing, and
other project management materials.
Michael
Re: Graduation?
Posted by Johan Oskarsson <jo...@oskarsson.nu>.
+1 on RTC for the reasons mentioned below.
/Johan
Jonathan Ellis wrote:
> On Thu, Nov 5, 2009 at 3:29 PM, ant elder <an...@gmail.com> wrote:
>> I think it could be tough to get Cassandra through a graduation vote
>> on general@ while working with RTC. I know there are some other
>> projects that use RTC, but its usually only for stable or release
>> branches isn't it?
>>
>> Things seem to be going well these days, what are the issues with
>> trying CTR now for a while?
>
> So I've thought about this a lot since Paul's brief objection.
>
> Historically I have been a huge non-fan of RTC. It can slow things
> down significantly with the overhead of switching between patchsets in
> various stages of review.
>
> BUT.
>
> Git-svn makes that go away almost entirely. I am never blocking for
> code to be reviewed; I just go code something else in the meantime. I
> branch per-ticket so revisiting to incorporate feedback or commit is
> trivial. I don't feel like I am wasting time fighting the tools like
> I used to with svn. (Especially with
> http://github.com/eevans/git-jira-attacher/.) All the other
> committers have switched to git-svn as well.
>
> I do think there should be room for individual discretion here. If
> you have a trivial change, just commit it and be done. But in
> general, I think the extra care of RTC is usually worth it for us. I
> see reviews becoming a lot more perfunctory / not happening at all if
> we just commit first. (Just about all my experience has been in CTR
> projects, both closed and OSS. This isn't just a theoretical concern,
> DESPITE the best of intentions that "we'll do reviews, promise.")
>
> So I would argue that RTC is working for us, making sure reviews
> actually happen, while git makes it mostly stay out of our way. I
> _would_ be in favor of being less dogmatic about it
> (https://issues.apache.org/jira/browse/CASSANDRA-528 from earlier
> today is a fine example) but in general I prefer not fixing what ain't
> broke.
>
> -Jonathan
Re: Graduation?
Posted by Matthieu Riou <ma...@gmail.com>.
On Thu, Nov 5, 2009 at 5:44 PM, Ian Holsman <ia...@holsman.net> wrote:
> I don't think there is any policy or standard about RTC or CTR.
> different groups do different things, depending on the community.
> so I don't see this as a hang up for graduation.
>
>
Me neither, hence my question. What puzzles me is that it's mostly a
technical decision not really tied to a community health criteria, so a
priori unrelated to graduation. Or it's just a clever plan from Paul to see
what kind of discussion would arise from his objection :)
Matthieu
>
> On Nov 6, 2009, at 10:57 AM, Roland Dreier wrote:
>
> I do think there should be room for individual discretion here. If
>>> you have a trivial change, just commit it and be done. But in
>>> general, I think the extra care of RTC is usually worth it for us. I
>>> see reviews becoming a lot more perfunctory / not happening at all if
>>> we just commit first. (Just about all my experience has been in CTR
>>> projects, both closed and OSS. This isn't just a theoretical concern,
>>> DESPITE the best of intentions that "we'll do reviews, promise.")
>>>
>>
>> This gets to my central question, which I would be really happy to
>> have answered by a CTR proponent. How do you make sure that changes
>> *ever* get reviewed, since CTR seems to operate on lazy consensus ("if
>> you object to this change, speak up")? *everyone* would rather write
>> code rather than review someone else's changes, so it seems that the
>> quantity of changes going in is always going to exceed the amount of
>> review being done, leading to an ever-growing review backlog.
>>
>> I just don't see how CTR can scale to a big project. It might scale
>> to a big codebase, if each piece has only one or a few committers
>> touching it, but when a lot of people are all working on the same
>> stuff, I wonder how anything will get reviewed in time.
>>
>> (FWIW, my background is pretty much exclusively in RTC projects such
>> as the Linux kernel)
>>
>> - R.
>>
>
> --
> Ian Holsman
> Ian@Holsman.net
>
>
>
>
Re: Graduation?
Posted by Ian Holsman <ia...@holsman.net>.
I don't think there is any policy or standard about RTC or CTR.
different groups do different things, depending on the community.
so I don't see this as a hang up for graduation.
On Nov 6, 2009, at 10:57 AM, Roland Dreier wrote:
>> I do think there should be room for individual discretion here. If
>> you have a trivial change, just commit it and be done. But in
>> general, I think the extra care of RTC is usually worth it for us. I
>> see reviews becoming a lot more perfunctory / not happening at all if
>> we just commit first. (Just about all my experience has been in CTR
>> projects, both closed and OSS. This isn't just a theoretical
>> concern,
>> DESPITE the best of intentions that "we'll do reviews, promise.")
>
> This gets to my central question, which I would be really happy to
> have answered by a CTR proponent. How do you make sure that changes
> *ever* get reviewed, since CTR seems to operate on lazy consensus ("if
> you object to this change, speak up")? *everyone* would rather write
> code rather than review someone else's changes, so it seems that the
> quantity of changes going in is always going to exceed the amount of
> review being done, leading to an ever-growing review backlog.
>
> I just don't see how CTR can scale to a big project. It might scale
> to a big codebase, if each piece has only one or a few committers
> touching it, but when a lot of people are all working on the same
> stuff, I wonder how anything will get reviewed in time.
>
> (FWIW, my background is pretty much exclusively in RTC projects such
> as the Linux kernel)
>
> - R.
--
Ian Holsman
Ian@Holsman.net
Re: Graduation?
Posted by Bill de hOra <bi...@dehora.net>.
Roland Dreier wrote:
> > I do think there should be room for individual discretion here. If
> > you have a trivial change, just commit it and be done. But in
> > general, I think the extra care of RTC is usually worth it for us. I
> > see reviews becoming a lot more perfunctory / not happening at all if
> > we just commit first. (Just about all my experience has been in CTR
> > projects, both closed and OSS. This isn't just a theoretical concern,
> > DESPITE the best of intentions that "we'll do reviews, promise.")
>
> This gets to my central question, which I would be really happy to
> have answered by a CTR proponent. How do you make sure that changes
> *ever* get reviewed, since CTR seems to operate on lazy consensus ("if
> you object to this change, speak up")? *everyone* would rather write
> code rather than review someone else's changes, so it seems that the
> quantity of changes going in is always going to exceed the amount of
> review being done, leading to an ever-growing review backlog.
>
> I just don't see how CTR can scale to a big project. It might scale
> to a big codebase, if each piece has only one or a few committers
> touching it, but when a lot of people are all working on the same
> stuff, I wonder how anything will get reviewed in time.
>
> (FWIW, my background is pretty much exclusively in RTC projects such
> as the Linux kernel)
Looking at this codebase as a non-committer/fanboy, I think it needs RTC
for a while, in a way that has nothing to do with the vcs or policy
preferences.
- there are parts that are just not widely understood. If 10 people
outside FB understand how the failure detector works or what happens
after a crash, or cross-dc bootstrap, I'd be delighted. And it seems to
me that small code changes can impact global behavior. Cassandra really
pushes the state of the art.
- the code is hard to write tests over and is a monolith by my
standards. Basically, it's full of statics and that it isn't going to
get better anytime time soon if the style rules encourage things like
linebreaks as means to organize methods and the patch process is
optimized for the reviewer rather than code's structural health. [I'm
assuming that Cassandra will either modularise at some point the way
hadoop did, or simply collapse due to complexity.]
- the disk format, apis, and clients aren't stable. IMO any changes
around mem/sstables or the commitlog warrants review.
- there's no trust hierarchy a la the kernel (or hadoop) that weeds out
bozos, and people here haven't gravitated to a subsystem maintenance
model yet.
- CTR isn't obviously slowing things down at the moment (that could
change if Cassandra becomes a big project). It seems pretty active to me
compared to other "unsql" projects.
So given the above I would wait for a while and if that stops graduation
so be it.
My concerns with RTC are that it might stop people getting involved
and/or the checkin process bottlenecks on the committers. If either
happens that should be obvious.
Bill
Re: Graduation?
Posted by Roland Dreier <ro...@digitalvampire.org>.
> I do think there should be room for individual discretion here. If
> you have a trivial change, just commit it and be done. But in
> general, I think the extra care of RTC is usually worth it for us. I
> see reviews becoming a lot more perfunctory / not happening at all if
> we just commit first. (Just about all my experience has been in CTR
> projects, both closed and OSS. This isn't just a theoretical concern,
> DESPITE the best of intentions that "we'll do reviews, promise.")
This gets to my central question, which I would be really happy to
have answered by a CTR proponent. How do you make sure that changes
*ever* get reviewed, since CTR seems to operate on lazy consensus ("if
you object to this change, speak up")? *everyone* would rather write
code rather than review someone else's changes, so it seems that the
quantity of changes going in is always going to exceed the amount of
review being done, leading to an ever-growing review backlog.
I just don't see how CTR can scale to a big project. It might scale
to a big codebase, if each piece has only one or a few committers
touching it, but when a lot of people are all working on the same
stuff, I wonder how anything will get reviewed in time.
(FWIW, my background is pretty much exclusively in RTC projects such
as the Linux kernel)
- R.
Re: Graduation?
Posted by Jonathan Ellis <jb...@gmail.com>.
On Thu, Nov 5, 2009 at 3:29 PM, ant elder <an...@gmail.com> wrote:
> I think it could be tough to get Cassandra through a graduation vote
> on general@ while working with RTC. I know there are some other
> projects that use RTC, but its usually only for stable or release
> branches isn't it?
>
> Things seem to be going well these days, what are the issues with
> trying CTR now for a while?
So I've thought about this a lot since Paul's brief objection.
Historically I have been a huge non-fan of RTC. It can slow things
down significantly with the overhead of switching between patchsets in
various stages of review.
BUT.
Git-svn makes that go away almost entirely. I am never blocking for
code to be reviewed; I just go code something else in the meantime. I
branch per-ticket so revisiting to incorporate feedback or commit is
trivial. I don't feel like I am wasting time fighting the tools like
I used to with svn. (Especially with
http://github.com/eevans/git-jira-attacher/.) All the other
committers have switched to git-svn as well.
I do think there should be room for individual discretion here. If
you have a trivial change, just commit it and be done. But in
general, I think the extra care of RTC is usually worth it for us. I
see reviews becoming a lot more perfunctory / not happening at all if
we just commit first. (Just about all my experience has been in CTR
projects, both closed and OSS. This isn't just a theoretical concern,
DESPITE the best of intentions that "we'll do reviews, promise.")
So I would argue that RTC is working for us, making sure reviews
actually happen, while git makes it mostly stay out of our way. I
_would_ be in favor of being less dogmatic about it
(https://issues.apache.org/jira/browse/CASSANDRA-528 from earlier
today is a fine example) but in general I prefer not fixing what ain't
broke.
-Jonathan
Re: Graduation?
Posted by Todd Lipcon <to...@cloudera.com>.
On Thu, Nov 5, 2009 at 1:29 PM, ant elder <an...@gmail.com> wrote:
>
> I think it could be tough to get Cassandra through a graduation vote
> on general@ while working with RTC. I know there are some other
> projects that use RTC, but its usually only for stable or release
> branches isn't it?
>
Hadoop uses RTC for all trunk code. There are some "experimental work in
progress" branches that just commit, but there is a review before it's
merged into trunk.
>
> Things seem to be going well these days, what are the issues with
> trying CTR now for a while?
>
>
I'm -1 for CTR on a system as complicated as Cassandra - just makes me
nervous that stuff can be committed without a once-over.
-Todd
Re: Graduation?
Posted by ant elder <an...@gmail.com>.
On Thu, Nov 5, 2009 at 9:19 PM, Matthieu Riou <ma...@gmail.com> wrote:
> I'm still interested in the answer :)
>
> On Tue, Nov 3, 2009 at 1:28 PM, Matthieu Riou <ma...@gmail.com>wrote:
>
>>
>>
>> On Tue, Nov 3, 2009 at 11:23 AM, Paul Querna <pa...@querna.org> wrote:
>>
>>> On Tue, Nov 3, 2009 at 8:20 AM, Matthieu Riou <ma...@offthelip.org>
>>> wrote:
>>> > Hi guys,
>>> >
>>> > I'd be curious to hear others' opinions but I think Cassandra is close
>>> to be
>>> > ready for graduation (or at least preparing for it). You came a long way
>>> > since the original code dump and now you have both diversity and a
>>> vibrant
>>> > community. You have 3 successful official releases behind you, a larger
>>> > committer and PMC group and probably more committers to attract. It's
>>> not
>>> > been a painless process for sure but it's a good time to look back at
>>> what
>>> > you've accomplished.
>>> >
>>> > So graduation, whad'ya say?
>>>
>>> No, trunk is still RTC. Its wrong.
>>>
>>>
>> Can you maybe elaborate what you think is wrong with a poddling doing RTC?
>> AFAIK many TLPs are doing RTC as well.
>>
I think it could be tough to get Cassandra through a graduation vote
on general@ while working with RTC. I know there are some other
projects that use RTC, but its usually only for stable or release
branches isn't it?
Things seem to be going well these days, what are the issues with
trying CTR now for a while?
...ant
Re: Graduation?
Posted by Matthieu Riou <ma...@gmail.com>.
I'm still interested in the answer :)
On Tue, Nov 3, 2009 at 1:28 PM, Matthieu Riou <ma...@gmail.com>wrote:
>
>
> On Tue, Nov 3, 2009 at 11:23 AM, Paul Querna <pa...@querna.org> wrote:
>
>> On Tue, Nov 3, 2009 at 8:20 AM, Matthieu Riou <ma...@offthelip.org>
>> wrote:
>> > Hi guys,
>> >
>> > I'd be curious to hear others' opinions but I think Cassandra is close
>> to be
>> > ready for graduation (or at least preparing for it). You came a long way
>> > since the original code dump and now you have both diversity and a
>> vibrant
>> > community. You have 3 successful official releases behind you, a larger
>> > committer and PMC group and probably more committers to attract. It's
>> not
>> > been a painless process for sure but it's a good time to look back at
>> what
>> > you've accomplished.
>> >
>> > So graduation, whad'ya say?
>>
>> No, trunk is still RTC. Its wrong.
>>
>>
> Can you maybe elaborate what you think is wrong with a poddling doing RTC?
> AFAIK many TLPs are doing RTC as well.
>
> Matthieu
>
>
>
>> Thanks,
>>
>> Paul
>>
>
>
Re: Graduation?
Posted by Matthieu Riou <ma...@gmail.com>.
On Tue, Nov 3, 2009 at 11:23 AM, Paul Querna <pa...@querna.org> wrote:
> On Tue, Nov 3, 2009 at 8:20 AM, Matthieu Riou <ma...@offthelip.org>
> wrote:
> > Hi guys,
> >
> > I'd be curious to hear others' opinions but I think Cassandra is close to
> be
> > ready for graduation (or at least preparing for it). You came a long way
> > since the original code dump and now you have both diversity and a
> vibrant
> > community. You have 3 successful official releases behind you, a larger
> > committer and PMC group and probably more committers to attract. It's not
> > been a painless process for sure but it's a good time to look back at
> what
> > you've accomplished.
> >
> > So graduation, whad'ya say?
>
> No, trunk is still RTC. Its wrong.
>
>
Can you maybe elaborate what you think is wrong with a poddling doing RTC?
AFAIK many TLPs are doing RTC as well.
Matthieu
> Thanks,
>
> Paul
>
Re: Graduation?
Posted by Paul Querna <pa...@querna.org>.
On Tue, Nov 3, 2009 at 8:20 AM, Matthieu Riou <ma...@offthelip.org> wrote:
> Hi guys,
>
> I'd be curious to hear others' opinions but I think Cassandra is close to be
> ready for graduation (or at least preparing for it). You came a long way
> since the original code dump and now you have both diversity and a vibrant
> community. You have 3 successful official releases behind you, a larger
> committer and PMC group and probably more committers to attract. It's not
> been a painless process for sure but it's a good time to look back at what
> you've accomplished.
>
> So graduation, whad'ya say?
No, trunk is still RTC. Its wrong.
Thanks,
Paul