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

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

> 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

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. 

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)
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. 

- 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