Occasional contributors and "complicated" rules

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Occasional contributors and "complicated" rules

Jonah Graham
Hello Platform devs,

I want to solicit some input and experience from you to apply to CDT.

CDT roughly follows the Eclipse Platform versioning rules. This leads to contributors who only occasionally contribute having more difficult time than I think they should have. This increases the perception that contributing to CDT is hard. (e.g. trivial fixes that pass all tests, still fails build)

How does the platform team deal with this? Do you require new contributors to learn all the rules such as incrementing service segments and require the contributor to fix it? Or does an experienced committer simply make a comment to educate and then the committer completes the housekeeping fix themselves? 

Up until now I have generally taken the approach of requiring the contributor to do this housekeeping, but it feels unwelcoming.

Thank you for any input on how you have handled this in the past, or if you have any official policy on this.

Jonah


~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com

_______________________________________________
platform-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
Reply | Threaded
Open this post in threaded view
|

Re: Occasional contributors and "complicated" rules

Lars Vogel-2
Hi Jonah,

I tend to update the versions on behalf of the new contributor. Once a person starts to contribute more, I try to explain the version rules.

Best regards, Lars

Jonah Graham <[hidden email]> schrieb am Sa., 13. Juni 2020, 16:21:
Hello Platform devs,

I want to solicit some input and experience from you to apply to CDT.

CDT roughly follows the Eclipse Platform versioning rules. This leads to contributors who only occasionally contribute having more difficult time than I think they should have. This increases the perception that contributing to CDT is hard. (e.g. trivial fixes that pass all tests, still fails build)

How does the platform team deal with this? Do you require new contributors to learn all the rules such as incrementing service segments and require the contributor to fix it? Or does an experienced committer simply make a comment to educate and then the committer completes the housekeeping fix themselves? 

Up until now I have generally taken the approach of requiring the contributor to do this housekeeping, but it feels unwelcoming.

Thank you for any input on how you have handled this in the past, or if you have any official policy on this.

Jonah


~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com
_______________________________________________
platform-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev

_______________________________________________
platform-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
Reply | Threaded
Open this post in threaded view
|

Re: Occasional contributors and "complicated" rules

Daniel Megert
I agree. Plus we use the 'compare-version-with-baseline' Tycho plug-in that fails the Gerrit Jenkins build tf the version is not updated when required. For details see Bug 522223.

Dani



From:        Lars Vogel <[hidden email]>
To:        "Eclipse platform general developers list." <[hidden email]>
Date:        13.06.2020 17:17
Subject:        [EXTERNAL] Re: [platform-dev] Occasional contributors and "complicated" rules
Sent by:        [hidden email]




Hi Jonah,

I tend to update the versions on behalf of the new contributor. Once a person starts to contribute more, I try to explain the version rules.

Best regards, Lars

Jonah Graham <[hidden email]> schrieb am Sa., 13. Juni 2020, 16:21:
Hello Platform devs,

I want to solicit some input and experience from you to apply to CDT.

CDT roughly follows the Eclipse Platform versioning rules. This leads to contributors who only occasionally contribute having more difficult time than I think they should have. This increases the perception that contributing to CDT is hard. (e.g. trivial fixes that pass all tests, still fails build)

How does the platform team deal with this? Do you require new contributors to learn all the rules such as incrementing service segments and require the contributor to fix it? Or does an experienced committer simply make a comment to educate and then the committer completes the housekeeping fix themselves? 

Up until now I have generally taken the approach of requiring the contributor to do this housekeeping, but it feels unwelcoming.

Thank you for any input on how you have handled this in the past, or if you have any official policy on this.

Jonah


~~~
Jonah Graham
Kichwa Coders

www.kichwacoders.com

_______________________________________________
platform-dev mailing list

[hidden email]
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev_______________________________________________
platform-dev mailing list
[hidden email]
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev



_______________________________________________
platform-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
Reply | Threaded
Open this post in threaded view
|

Re: Occasional contributors and "complicated" rules

Ed Merks-2

Dani,

Often when I make a contribution it takes me several tries to get the versions correct.  E.g., this from yesterday:

  https://git.eclipse.org/r/#/c/164844/

Of course one knows (after a while) that something needs to be incremented in general, but one needs to check, has the MANIFEST.MF already been incremented, not just blindly do it.  If there is a pom.xml, of course its version has to match.   I'm not sure if the API tools in the IDE complain when x.y.z has to become x.(y+1).0 but it certainly doesn't tell you when x.y.z has to become x.y.(z+100).  It would save time if that check would/could be done in the IDE.  Perhaps it's an expensive check to run constantly/incrementally, but a manual "check bundle API versions" that checked for the same thing that fails after a very long wait in Gerrit would make that easier.

Regards,
Ed

On 14.06.2020 18:30, Daniel Megert wrote:
I agree. Plus we use the 'compare-version-with-baseline' Tycho plug-in that fails the Gerrit Jenkins build tf the version is not updated when required. For details see Bug 522223.

Dani



From:        Lars Vogel [hidden email]
To:        "Eclipse platform general developers list." [hidden email]
Date:        13.06.2020 17:17
Subject:        [EXTERNAL] Re: [platform-dev] Occasional contributors and "complicated" rules
Sent by:        [hidden email]




Hi Jonah,

I tend to update the versions on behalf of the new contributor. Once a person starts to contribute more, I try to explain the version rules.

Best regards, Lars

Jonah Graham <[hidden email]> schrieb am Sa., 13. Juni 2020, 16:21:
Hello Platform devs,

I want to solicit some input and experience from you to apply to CDT.

CDT roughly follows the Eclipse Platform versioning rules. This leads to contributors who only occasionally contribute having more difficult time than I think they should have. This increases the perception that contributing to CDT is hard. (e.g. trivial fixes that pass all tests, still fails build)

How does the platform team deal with this? Do you require new contributors to learn all the rules such as incrementing service segments and require the contributor to fix it? Or does an experienced committer simply make a comment to educate and then the committer completes the housekeeping fix themselves? 

Up until now I have generally taken the approach of requiring the contributor to do this housekeeping, but it feels unwelcoming.

Thank you for any input on how you have handled this in the past, or if you have any official policy on this.

Jonah


~~~
Jonah Graham
Kichwa Coders

www.kichwacoders.com

_______________________________________________
platform-dev mailing list

[hidden email]
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev_______________________________________________
platform-dev mailing list
[hidden email]
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev



_______________________________________________
platform-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev

_______________________________________________
platform-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
Reply | Threaded
Open this post in threaded view
|

Re: Occasional contributors and "complicated" rules

Daniel Megert
Hi Ed

It is supposed to report all version issues including the affected bundles, see https://bugs.eclipse.org/bugs/show_bug.cgi?id=559257#c4. If that's not the case, please open a new bug and post it here.

Regarding detecting this in the IDE, I thought I filed a bug in the past but couldn't find it right now. Please try too, and file a bug report if you can't find it too. It shouldn't be too hard to detect that the change(s) require a version increase.

Take care!
Dani



From:        Ed Merks <[hidden email]>
To:        [hidden email]
Date:        15.06.2020 06:56
Subject:        [EXTERNAL] Re: [platform-dev] Occasional contributors and "complicated" rules
Sent by:        [hidden email]




Dani,
Often when I make a contribution it takes me several tries to get the versions correct.  E.g., this from yesterday:
  https://git.eclipse.org/r/#/c/164844/
Of course one knows (after a while) that something needs to be incremented in general, but one needs to check, has the MANIFEST.MF already been incremented, not just blindly do it.  If there is a pom.xml, of course its version has to match.   I'm not sure if the API tools in the IDE complain when x.y.z has to become x.(y+1).0 but it certainly doesn't tell you when x.y.z has to become x.y.(z+100).  It would save time if that check would/could be done in the IDE.  Perhaps it's an expensive check to run constantly/incrementally, but a manual "check bundle API versions" that checked for the same thing that fails after a very long wait in Gerrit would make that easier.
Regards,
Ed

On 14.06.2020 18:30, Daniel Megert wrote:
I agree. Plus we use the 'compare-version-with-baseline' Tycho plug-in that fails the Gerrit Jenkins build tf the version is not updated when required. For details see Bug 522223.

Dani




From:        
Lars Vogel [hidden email]
To:        
"Eclipse platform general developers list." [hidden email]
Date:        
13.06.2020 17:17
Subject:        
[EXTERNAL] Re: [platform-dev] Occasional contributors and "complicated" rules
Sent by:        
[hidden email]




Hi Jonah,

I tend to update the versions on behalf of the new contributor. Once a person starts to contribute more, I try to explain the version rules.

Best regards, Lars

Jonah Graham <
[hidden email]> schrieb am Sa., 13. Juni 2020, 16:21:
Hello Platform devs,

I want to solicit some input and experience from you to apply to CDT.

CDT roughly follows the Eclipse Platform versioning rules. This leads to contributors who only occasionally contribute having more difficult time than I think they should have. This increases the perception that contributing to CDT is hard. (e.g. trivial fixes that pass all tests, still fails build)

How does the platform team deal with this? Do you require new contributors to learn all the rules such as incrementing service segments and require the contributor to fix it? Or does an experienced committer simply make a comment to educate and then the committer completes the housekeeping fix themselves? 

Up until now I have generally taken the approach of requiring the contributor to do this housekeeping, but it feels unwelcoming.

Thank you for any input on how you have handled this in the past, or if you have any official policy on this.

Jonah


~~~
Jonah Graham
Kichwa Coders

www.kichwacoders.com

_______________________________________________
platform-dev mailing list

[hidden email]
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev_______________________________________________
platform-dev mailing list

[hidden email]
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev




_______________________________________________
platform-dev mailing list
[hidden email]
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
_______________________________________________
platform-dev mailing list
[hidden email]
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev




_______________________________________________
platform-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev