Re: [ide-dev] Development Process was Re: Why we dropped Eclipse in favo

["Konstantin Komissarchik" <konstantin.komissarchik@xxxxxxxxxx>]

Miles,

I think you are being rather cynical in how you are interpreting the
committer/contributor relationship. It isn't necessary to assume contributor
inferiority bias to have a compelling reason for reviewing changes from
contributors who have occasional engagement with the project and passing on
reviews for committers who have consistent engagement. When I review
contributions, the number one concern is that the change fits in with the
overall project architecture. The type of mistakes that even a first rate
developer would make when they lack sufficient time with the codebase.

None of the above should be used to justify not allocating sufficient time
for reviewing and merging contributor patches. 

- Konstantin


-----Original Message-----
From: ide-dev-bounces@xxxxxxxxxxx [mailto:ide-dev-bounces@xxxxxxxxxxx] On
Behalf Of Miles Parker
Sent: Tuesday, September 24, 2013 4:25 PM
To: Discussions about the IDE; eclipse-dev@xxxxxxxxxxx
Subject: Re: [ide-dev] Development Process was Re: Why we dropped Eclipse in
favour of IntelliJ | Java Code Geeks

Now, I will move this back to eclipse dev because I think this is an
important discussion for all projects. And Konstantin, please don't think
that argumentative stuff below is aimed at you.. You've just given me the
excuse to rant a bit about something I've felt like saying for quite a while
now. :)

"This is making an assumption that all changes are reviewed, which doesn't
> hold universally. I know that some projects operate that way, but many 
> only review contributor changes."

I was reading you to mean that "only review contributor changes" *but don't
review non-contributors* (whatever that would have meant), but what you
meant was "not all committer changes are reviewed". I know my assumption is
wrong, but I guess I was thinking that projects would be migrating away from
not reviewing committer changes. Because that is the only sensible and fair
thing to do, even if we don't all realize it yet.. :)

> If you are saying that you are troubled that not everyone is using 
> Gerrit or reviewing all changes, then that's a completely separate 
> development process discussion that will just derail this thread. It 
> would be sufficient to recognize that all projects do not use the same
development process.

It won't derail the thread, it was the entire point of this thread! :D How
we handle process of committers and reviews is critical to how well we
handle the innovation challenges that Eclipse is facing right now. And we're
doing it wrong a lot of time. Every Eclipse project could improve radically
in terms of how we respond to "outsiders" contributions.

If we see Gerrit as a neat new tool to prevent outside contributors from
wrecking our (perceived good) quality  -- some kind of gateway -- then
that's an *abuse* of Gerrit. The unmistakeable message is "we think your
code probably stinks, and we know that our code never does." It means that
we aren't even willing to play by the same set of rules. We'd all like to
think that this is all in the service of protecting the quality of our
precious toolsets, but it's not. To assume that because we've been working
on a project for a long-time that somehow we're not going to make the same
kind of mistakes that other seasoned developers would is simply arrogant.
Sure you have to learn the idioms and the APIs, etc.. and it can be a PITA
to work w/ someone who isn't familiar w/ them, and yes, I understand that
it's a real problem to have to deal with contributions that just aren't up
to snuff or that don't fit in with development priorities or that create new
maintenance burdens for the  project -- but if we aren't willing to put
effort into that, what exactly is it that makes us a community?

We keep talking about having to have a level of trust to allow anyone to get
anywhere near our code, but we never think about the trust that *we* have to
create for users that their contributions will actually get somewhere. I'm
sorry, but I think it's time to say it -- we have a culture of arrogance at
Eclipse. It's almost like some kind of primitive guild system we've built
ourselves. Like working at a law firm or something -- "we jumped through
these hoops, now it's your turn." The process becomes its own reward.

So to bring it back to the question at hand, why would a company want to
invest in that effort knowing that there is a good chance that their
contributions would be ignored? IMO, we need to level the playing field and
evolve toward having all projects commit to having the resources to do
reviews of outside work just as we expect them to do bug triage, release
train maintenance, etc.. and above all to follow the same basic review
process, committer or not.

-Miles

On 2013-09-24, at 2:50 PM, Konstantin Komissarchik
<konstantin.komissarchik@xxxxxxxxxx> wrote:

>> Hmm..I'm not sure we really make a hard distinction between
"contributors"
> 
>> and "non-contributors" I'm not even sure how you would formalize that. 
> 
> The distinction between a committer and a contributor is well defined. 
> Those are the only roles that I referenced.
> 
>> But it is a bit troubling to hear that some review submissions aren't 
>> actually even reviewed.
> 
> If you are saying that you are troubled that not everyone is using 
> Gerrit or reviewing all changes, then that's a completely separate 
> development process discussion that will just derail this thread. It 
> would be sufficient to recognize that all projects do not use the same
development process.
> 
>> So you're not saying "part-time" vs. "full-time" as in 40 hours of 
>> work, but as in long-term commitment? I think having a requirement 
>> that for example a committer actually be employed to do the work that 
>> they're doing would not be fair, but I don't think that's what you're
suggesting.
> 
> No, I don't use "full-time" to mean 40 hours of work on the project, 
> but rather consistent and meaningful engagement. What that means in 
> detail will differ from project to project. For instance, there is a 
> contributor on Sapphire with many high quality patches to his name, 
> but a track record of sporadic engagement. A flurry of activity, then
silence for many months.
> That doesn't instill confidence that he will keep sufficiently up to 
> date with the project for his contributions to be trusted without 
> further review, so no commit rights and a longer path to getting
contributions merged.
> 
>> [snip] I was going on the assumption that people were used to 
>> reviewing
> other
>> people's work *w/in* a project. That's how we do it at Mylyn.
> 
> A bad assumption. I would venture to guess that most projects don't 
> operate this way and more to the point, unless something changed 
> recently, the core projects under discussion in this thread certainly
don't operate this way.
> 
> - Konstantin
> 
> 
> 
> -----Original Message-----
> From: ide-dev-bounces@xxxxxxxxxxx [mailto:ide-dev-bounces@xxxxxxxxxxx] 
> On Behalf Of Miles Parker
> Sent: Tuesday, September 24, 2013 2:19 PM
> To: Discussions about the IDE
> Subject: Re: [ide-dev] Development Process was Re: Why we dropped 
> Eclipse in favour of IntelliJ | Java Code Geeks
> 
> 
> This discussion is interesting. I'm almost tempted to put it back over 
> on eclipse-dev, but I guess I won't confuse thigns further. :D
> 
> On 2013-09-24, at 1:47 PM, Konstantin Komissarchik 
> <konstantin.komissarchik@xxxxxxxxxx> wrote:
>> 
>> This is making an assumption that all changes are reviewed, which 
>> doesn't hold universally. I know that some projects operate that way, 
>> but many only review contributor changes. Once a committer has earned 
>> access, they are allowed to merge changes without prior review.
> 
> Hmm..I'm not sure we really make a hard distinction between "contributors"
> and "non-contributors" I'm not even sure how you would formalize that. 
> But it is a bit troubling to hear that some review submissions aren't 
> actually even reviewed.
> 
>> 
>> The part-time vs full-time distinction comes into play when it comes 
>> to earning commit rights. Most projects use dual criteria for
>> committers: (a)
> 
> So you're not saying "part-time" vs. "full-time" as in 40 hours of 
> work, but as in long-term commitment? I think having a requirement 
> that for example a committer actually be employed to do the work that 
> they're doing would not be fair, but I don't think that's what you're
suggesting.
> 
>> sufficient volume of high-quality work, and (b) consistent 
>> involvement over a certain span of time. The reason that you have (b) 
>> is that you cannot trust a committer that checks out for six months 
>> at a time to keep tabs on project development and be able to continue 
>> to make safe changes. Their contributions are still welcome, but need to
be reviewed.
>> My original point is that if you fund a developer to focus on say 
>> Platform and JDT, there shouldn't be a problem in achieving 
>> consistency of involvement that many projects are looking for. That 
>> gets you commit rights and the quicker path for merging changes.
> 
> I think all changes should be reviewed! To me, this is the big sea 
> change that Gerrit represents. As I said in a tongue-in-cheek blog -- 
> "That's because -- when implemented fully and correctly -- Gerrit 
> makes it every bit as annoying for Committers to get code in as it is 
> for Contributors." :D
> (http://milesparker.blogspot.ca/2013/01/adopting-gerrit.html)
> 
> But I'm glad you mentioned that, because I guess I was going on the 
> assumption that people were used to reviewing other people's work 
> *w/in* a project. That's how we do it at Mylyn. I wouldn't really 
> think of merging code unless I got a +1 from at least one other 
> committer, or it was something really trivial. (But maybe that's just 
> based on my commit track-record. :P And as we all know, the dumbest 
> mistakes usually involve "that one line of code with a simple error".) 
> When people are used to reviewing other people's code as part of their 
> day to day work effort that's a very different thing from asking 
> someone to do a task (reviewing) that is totally divergent from the normal
development process.
> 
> So personally, I think all projects should be moving to universal review.
> That might seem like imposing more work, but it improves code quality 
> and often improves community as well. So I think this points to a real 
> opportunity to for projects to look at their own processes and find 
> ways to make them more open and democratic.
> 
> -Miles
> 
> 
>> 
>> - Konstantin
>> 
>> 
>> -----Original Message-----
>> From: ide-dev-bounces@xxxxxxxxxxx 
>> [mailto:ide-dev-bounces@xxxxxxxxxxx]
>> On Behalf Of Miles Parker
>> Sent: Tuesday, September 24, 2013 1:25 PM
>> To: Discussions about the IDE
>> Subject: [ide-dev] Development Process was Re: Why we dropped Eclipse 
>> in favour of IntelliJ | Java Code Geeks
>> 
>> 
>> Mickael , You're right, length of time for reviews and overall EDP 
>> friction is a _big_ issue. That isn't going to get fixed by somehow 
>> giving developers a special guarantee or review status. For all the 
>> reasons you mentioned and more, that would be a violation of Eclipse 
>> principles -- not to mention impossible to manage. You should be 
>> offended by this if you saw it happening! (And believe me, there 
>> aren't necessarily special favours just because you're an employee of 
>> a firm associated w/ a project. To the contrary. :) Though member 
>> agreements do help with the "paper"work and
>> process.) So, I think tying performance on feature objectives to fast 
>> turn-around on reviews is wrong. The catch-22 is you cannot run a 
>> business where your deliverables are hostage to a process you don't 
>> have control over.
>> 
>> So what to do? You of course try to get it merged during the period 
>> of performance, but you *don't* guarantee it. Delivery is the work 
>> that has been done, not that it has been reviewed and merged. That is 
>> a difficult thing to wrap one's head around, but it comes down to 
>> trust between the contracting developers and the sponsor, and that 
>> can only
> develop over time.
>> You need to establish strong long-term relationships between 
>> companies willing to sponsor specific development efforts and those 
>> able to execute on them.
>> 
>> WRT Developer vs. Review time, you need both, but in my experience 
>> you aren't going to get corporate sponsors to support reviews. You
>> *should* get them to include reviews as a kind of overhead. But time 
>> for reviews has to already be built in to the project somehow. This 
>> is a chicken-and-egg thing , and so I can see the attraction of the 
>> idea of having the foundation pay for reviews, but I don't really see 
>> how to make that work. So *before* expecting sponsorship on a 
>> particular project you need to ensure that the current committers are 
>> committed (no pun intended) to reviewing outside contributions, to 
>> have a track record of openness, and to have a clear path to 
>> committer status in a reasonable amount of time *if that's the 
>> appropriate thing, and it doesn't always have to be*. The first part 
>> is the hard one -- Reviews take up a lot of time, and so it's a hard 
>> ask to have someone drop their priorities in order to look at code 
>> that they're uncertain about and that could be motiva  ted on a 
>> different set of priorities. And note that committers are already 
>> having to do a lot of work like build management, bug triage, etc., 
>> etc. that isn't all that sexy so this just further reduces that 
>> bandwidth for doing cool stuff. It's not a small ask. :) Bottom line 
>> is the one thing we *can't* do is just say "here Stephan (to pick on the
JDT team :)), here's some more code for you.
> Can you review it next week so I can get paid?" Another Catch-22.
>> 
>> Practically, I think it means that the organizations that are 
>> currently deeply supportive of the project in question also be in on 
>> the discussion about the work as early in the cycle as possible and 
>> that some way is found to support current committers. I suspect that, 
>> ironically, it is easier to do for a project like Mylyn with a small 
>> company taking the leadership role, and where we see the importance 
>> of the overall investment, and a large one like IBM that doesn't see 
>> a connection between community building and the outcome and wouldn't 
>> have a way to handle sponsorship even it it were offered. (And who 
>> would offer it?) So I think part of the issue the JDT issue is 
>> actually
> structural.
>> 
>> But, while I would never say that this is easy to manage (it can be 
>> really painful at times), it *is* possible, and the potential rewards 
>> are
> worth it.
>> Gunnar and I -- and probably many others on this list -- here have 
>> experience with this and would be happy to share whatever we can 
>> about making these relationships work. It isn't always easy, but it 
>> can be really rewarding both for the sponsor seeing actual progress 
>> on things they care about, and developers being able to work on stuff 
>> that they know
> matters.
>> 
>> Konstantin WRT to part time vs. full-time committers, again, I don't 
>> honestly think it really matters all that much -- or it shouldn't and 
>> if it does we should work to fix it. With Gerrit, it is much more of 
>> an equal playing field. That might not be quite true in platform yet, 
>> but with Mylyn at least the process is really a difference of degree 
>> rather than kind these days. e.g. it might take a bit longer and 
>> reviewers might be a little (heh) more painstaking on the review but 
>> the overall process for commiters and non-committers is fundamentally 
>> the same. Really! :D
>> 
>> cheers,
>> 
>> Miles
>> 
>> On 2013-09-23, at 8:53 AM, Mickael Istria <mistria@xxxxxxxxxx> wrote:
>>> 
>>> The current issue with the contribution model, especially for 
>>> platform, is
>> that there is no guarantee that even by doing the work, a feature 
>> will get reviewed, approved or merged in time. Without this 
>> guarantee, one can
> see
>> contributing as a potential waste and     will be reluctant to start a
>> contribution work. I don't think companies wish to pay developers to 
>> do work they can do by themselves. What they wish is more ability to 
>> make things happen.
>>> 
>>> I don't get why paying someone working for the Foundation would help 
>>> in
>> getting stuff done in Eclipse faster than contributing code directly. 
>> It would appear to me that if we go for a "let's pay the Foundation for a
>> feature" mode, it means that this developer will     need to have
> super-fast
>> reviews of his patches and a very quick feedback/merge loop in order 
>> to honor the contracts. But why would someone in particular have that 
>> privilege of fast review? In a community, any contributor should 
>> start with the same status based on merit, independently of its 
>> employer or contract. If someone gets hired by organization X (may it 
>> be the Foundation or something else) and gets its Gerrit patch 
>> reviewed before mine just because of his employer, I would find it 
>> almost
> insulting.
>>> There is progress on that side with Gerrit and so on, but it's still 
>>> a
>> long time to wait for an answer. I understand that current committers 
>> on Platform have many things to do and that they're doing there best 
>> to find time to review, it's not a personal accusation.
>>> 
>>> 
>>> So overall, those 3 points lead to the idea that what is needed 
>>> isn't more
>> developers, or a paid developer to do some things, but rather more 
>> reviewers that will shorten feedback loop and speed up the heartbeat 
>> of the project. I may be wrong, I think that's what Linux has been 
>> paid for at the Linux
>> Foundation: now writing code, but reviewing it.
>>> But it's easier said than done: let's say the Foundation goes for 
>>> hiring a
>> reviewer for Platform, or JDT; there are concretely a very few people 
>> able to handle that task. Would anyone want to take this role?
>>> --
>> 
>> 
>> On 2013-09-23, at 9:02 AM, Konstantin Komissarchik 
>> <konstantin.komissarchik@xxxxxxxxxx> wrote:
>> 
>>> The assumption behind having Eclipse Foundation hire developers is 
>>> that
>> they would concentrate on a handful of core projects and as the 
>> result of this full time focus rapidly earn the committer rights 
>> through the usual process. The dynamic for part-time contributors is
quite different.
>> 
>> 
>> Miles T. Parker | Tasktop Labs | Tasktop Technologies
>> skype: milestravisparker  | web: http://tasktop.com  | blog:
>> http://milesparker.blogspot.com
>> 
>> Committer: Eclipse Mylyn Reviews, R4E, Virgo
>> Lead: Eclipse Mylyn MFT, AMP
>> 
>> Are you passionate about innovation and excellence and interested in 
>> joining our team? Tasktop, voted one of the Best Companies to Work 
>> for in British Columbia, is hiring!
>> 
>> _______________________________________________
>> ide-dev mailing list
>> ide-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/ide-dev
>> 
>> _______________________________________________
>> ide-dev mailing list
>> ide-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/ide-dev
> 
> _______________________________________________
> ide-dev mailing list
> ide-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/ide-dev
> 
> _______________________________________________
> ide-dev mailing list
> ide-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/ide-dev

_______________________________________________
ide-dev mailing list
ide-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ide-dev