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

[Miles Parker <miles.parker@xxxxxxxxxxx>]

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