Eye-rolling: hence my "yeah, I know". It's not as bad as it sounds: many of those 1400 lines are spent to explain and motivate each rule.
We describe the standard as aspirational and as an evolving document. We're hoping to get an autoformat tool in place to handle automagically as many of the rules as possible. We come clean that the current code base doesn't follow all the rules religiously, so there's flexibility, but we're still trying to move towards improving the code base. I'm going to keep the discussion issue open even after the standard is committed. If pedantism becomes a problem for contributions then obviously we'll have to respond to that. I'll keep the CQ going as you've recommended. Thanks for the advice! Mark Stoodley 8200 Warden Avenue Senior Software Developer Markham, L6G 1C7 IBM Runtime Technologies Canada Phone: +1-905-413-5831 e-mail: [email protected] We cannot solve our problems with the same thinking we used when we created them - Albert Einstein From: Wayne Beaton <[email protected]> To: [email protected] Date: 2016/03/24 12:51 PM Subject: Re: [incubation] clarification request for when CQs are needed Sent by: [email protected] If your committer has pulled together content from sources that existed before the project was created, then it sounds like a CQ is in order. I believe that I am duty bound to roll my eyes at the notion of 1,400 lines of coding style guidelines. How high are you making the bar for contribution? Wayne On 24/03/16 12:47 PM, Mark Stoodley wrote: Thanks, Gunnar and Wayne for the quick responses! No poke at Markdown...it was a poke at the notion to have >1000 lines of coding style guidelines (it's actually about 1400 lines worth :) ). Personally, I'd have to imagine coding style guidelines as "anticipated content". Although, technically, many of the coding style guidelines were written before the project was initiated, one of our project committers did some clean up and formatted as markdown. We do have a GitHub issue opened to discuss the contribution. I still feel like I've talked my way halfway between withdrawing and keeping the CQ :) . Mark Stoodley 8200 Warden Avenue Senior Software Developer Markham, L6G 1C7 IBM Runtime Technologies Canada Phone: +1-905-413-5831 e-mail: [email protected] We cannot solve our problems with the same thinking we used when we created them - Albert Einstein From: Wayne Beaton <[email protected]> To: [email protected] Date: 2016/03/24 12:36 PM Subject: Re: [incubation] clarification request for when CQs are needed Sent by: [email protected] Hi Mark. Content authored by a project committer falls under Figure #1 of the IP Due Diligence Process [1] which covers: Written 100% by Submitting Committer or Committer on same Project under the supervision of the PMC The real question, I think, is how do we define "under the supervision of the PMC". If the content was authored after the individual became a committer, provides functionality that is within the scope of the project, has been developed in an open and transparent manner, and the PMC could otherwise reasonably expect this sort of content to arrive, then you're good. If you already have a bug open to track and discuss the contribution, you have a slam-dunk. A counter example might be some content that you've pulled out of an old archive that existed before the project was created, or if the committer disappeared for a month and arrived back with a huge contribution that nobody expected. Assuming that this content was authored after the developer gained committer status, my assessment is that you don't need a CQ. Does this help? What's with the poke at Markdown? Did Markdown stop being cool? Did I miss a memo? Wayne [1] https://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf On 24/03/16 12:21 PM, Mark Stoodley wrote: If a project committer makes a significant (say > 1000 lines of code) contribution and the contribution is "new" content (by which I mean a completely new file or piece of content; not modifications to existing content in the project), does that necessarily count as an "initial contribution" under the IP process? The specific example we've got is the contribution of our coding standard, which is more than 1000 lines (yeah, I know) of markdown. Up until this point, we did not have a documented coding standard, so technically it's "new content" but I have to admit, I felt kind of silly opening a CQ for it (which I did anyway under the guise of "better safe than sorry" : see https://dev.eclipse.org/ipzilla/show_bug.cgi?id=11134if you're really interested). It was contributed by a project committer so doesn't directly fall under the "> 1000 lines" rule for non committers. Do we need a CQ for such content? Later on, one of our committers will be contributing several hundred thousand lines of Just In Time compiler code. That code, I will obviously treat as "initial contribution", but looking for some guidance on where the threshold is for this kind of thing and how pedantic I should be about it. Mark Stoodley 8200 Warden Avenue Senior Software Developer Markham, L6G 1C7 IBM Runtime Technologies Canada Phone: +1-905-413-5831 e-mail: [email protected] We cannot solve our problems with the same thinking we used when we created them - Albert Einstein _______________________________________________ incubation mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/incubation -- Wayne Beaton @waynebeaton The Eclipse Foundation _______________________________________________ incubation mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/incubation _______________________________________________ incubation mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/incubation -- Wayne Beaton @waynebeaton The Eclipse Foundation _______________________________________________ incubation mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/incubation
_______________________________________________ incubation mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/incubation
