Yes, I believe it's an important aspect of Eclipse that makes it stand
out as the best place to be if you want the broadest possible community
of adopters. Of course this benefit doesn't come without a cost and of
course that can be frustrating. In a specific case of a contribution
that consists of a relatively smaller changes to the framework/tool with
a relatively larger addition of test case(s), it would seem reasonable
to split the two, if it's important that the change to the
tools/framework show up as quickly as possible.
I certainly don't suggest gaming the system, though I do tend to point
out to the IP committee all the ways it can be gamed, and will be gamed
by developers who are frustrated and don't take the issue seriously. I
ask questions such as how long can a line be? One can fit quite a lot
on a line line and reformat it later. Also, why should a blank line
count for anything? Is a line with just a curly brace on it really
IP? And yes, of course I make them aware that contributions can be
split into smaller chunks...
Perhaps this specific review period overlapped with EclispeCon Europe
where we had the pleasure of spending personal time with the with the IP
staff...
On 19/11/2015 11:31 AM, Christian Campo wrote:
Wouldnt it be worth to hear what the IP Team has to say why this took so
long ? I see that Sharon appologized on the CQ that it took so long. That
made me believe that this was an exception.
Does every CQ with 1000 lines take so long ? What is the experience of
others about reviews with code contributions.
As I remember vaguely (and that might be incorrect) the IP team runs
automatic scans over the code, but I am not sure what else they do.
I for once believe the work of the IP Team is important and one of the
core values of the EF vs say Github and I take it serious.
Just my 2 cents
christian
Am 19.11.15, 11:22 schrieb "cross-project-issues-dev-boun...@eclipse.org
on behalf of Sievers, Jan" unter
<cross-project-issues-dev-boun...@eclipse.org on behalf of
jan.siev...@sap.com>:
If everybody tells me there are ways to dodge around that rule (and of
course I know there are), the question arises why do we have the rule in
the first place. Seems a little absurd to me.
the effort is not minimal if I have to artificially split up commits.
Or maybe you expect me to explain to contributors:
"look, we have this process but nobody takes it serious anyway. so please
split up your commit into several < 1000 LOC chunks" ?
Best Regards,
Jan
On 19/11/15 11:00, "cross-project-issues-dev-boun...@eclipse.org on
behalf of Ed Willink" <cross-project-issues-dev-boun...@eclipse.org on
behalf of e...@willink.me.uk> wrote:
Hi
Presumably you put tests in a separate plugin, so splitting off the
tests as a separate contribution gets you twice the limit with minimal
effort.
Perhaps a 10000 line limit might be appropriate for non-deliverable code
such as tests and build tools.
Regards
Ed Willink
On 19/11/2015 09:49, Sievers, Jan wrote:
Hi,
in the course of
https://bugs.eclipse.org/bugs/show_bug.cgi?id=477328
we had a contribution that slightly exceeded 1000 lines and thus
needed a CQ.
It took about one month to review it.
I am sure the legal team does its very best to keep up with the load,
so the following is in no way a criticism of the
people who actually do the legal review.
Rather take it as food for thought to whoever set up this rule.
IMHO the 1000 line rule is effectively setting the wrong incentives
for a thriving opensource project.
Here is why I think so:
The most diligent contributors add a lot of tests to their patch to
prove it works.
This is a good thing and we actively encourage contributors to
thoroughly test.
Test code can easily outweigh productive code being tested in terms of
LOC.
However this means the most diligent contributors, i.e. the ones you
want to attract, are more likely to hit the 1000 line limit.
Instead of thanking them for their hard work, we effectively punish
them with an extra month or more wait time before their patch can be
merged.
Apart from that, the 1000 line limit seems arbitrary to me because
technically you can split up any commit into any number
of smaller commits below the 1000 line limit.
Best Regards,
Jan
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe
>from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe
>from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
-------------------------------------------------------------
compeople AG
Untermainanlage 8
60329 Frankfurt/Main
fon: +49 (0) 69 / 27 22 18 0
fax: +49 (0) 69 / 27 22 18 22
web: www.compeople.de
Vorstand: Jürgen Wiesmaier
Aufsichtsratsvorsitzender: Christian Glanz
Sitz der Gesellschaft: Frankfurt/Main
Handelsregister Frankfurt HRB 56759
USt-IdNr. DE207665352
-------------------------------------------------------------
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
