Community
Participate
Working Groups
Section IV A. (1) of the Eclipse IP Policy [1] describes the record-keeping requirements for inbound contributions from non-committers. Currently for this record keeping we use a variety of workflows, including tracking this information in bugzilla comments, gerrit change entries, and/or CQ's in ipzilla. Correlating source changes back to this paperwork would be very difficult and I suspect in many cases we have gaps in our records that we would not be able to track down. One mechanism used by other open source projects for this kind of record-keeping is the Git Signed-Off-By flag [2]. This allows the record-keeping to be integrated directly into the source repository, making future access to that information trivial and easy to automate. Verification of the records could also be easily automated to ensure we have no gaps in our records. I am opening this bug to consider adopting Signed-Off-By for our contributor record keeping at Eclipse. One possible implementation path: - All contributors must have an Eclipse bugzilla account - When creating that account, users agrees that adding Signed-Off-By header to commits in Eclipse Git repositories implies agreement to something like the kernel.org "Certificate of Origin" (I wrote all the code myself, have the rights to contribute it to Eclipse, agree to terms of applicable licenses, etc). [1] http://www.eclipse.org/org/documents/Eclipse_IP_Policy.pdf [2] http://www.kernel.org/doc/Documentation/SubmittingPatches (section 12)
As discussed on http://wiki.eclipse.org/Architecture_Council/Meetings/June_14_2012 I like the idea of consolidating multiple sources of information. Putting a copy of the "3 statements" into a git commit comment makes most sense to me (ie wrote the code yourself, not referencing anything except EPL, right to contribute). The "signed-off-by" alone doesn't seem sufficient to me since it may not clear for contributors what they sign off on. Such an approach would need to be taken _together_ with an improved web interface that makes clear the "3 statements" when signing off.
(In reply to comment #1) > The "signed-off-by" alone doesn't seem sufficient to me since it may not clear > for contributors what they sign off on. Such an approach would need to be taken > _together_ with an improved web interface that makes clear the "3 statements" > when signing off. The natural evolution of this could be a feature added to JGit/EGit that automatically adds the three statements. The meaning of the statements would still be more explicit than the implied meaning of signed-off-by, but there's no guarantee that the contributor will understand the implication of a mindlessly- or automatically-appended statement regardless of its form. One thing that I like about signed-off-by is that it can be parsed very easily and consistently with regular expressions. Perhaps a combination of signed-off-by and the "three statements" in free-form text gets us there?
(In reply to comment #1) > The "signed-off-by" alone doesn't seem sufficient to me since it may not clear > for contributors what they sign off on. Such an approach would need to be taken > _together_ with an improved web interface that makes clear the "3 statements" > when signing off. I didn't mention in the call, but note in comment #0 the proposal is that we have a one-time contributor agreement that every contributor must agree to exactly once. Included in that would be an agreement that they understand the meaning of "Signed-off-by" in the context of Eclipse project repositories. Whether this is strong enough from a legal perspective I couldn't say, but it is already stronger than what other communities such as kernel.org do today. I would really like to reduce the overhead required by contributors for every single commit, so if there is a way we can document that understanding once I think it would be a big improvement.
(In reply to comment #3) > I didn't mention in the call, but note in comment #0 the proposal is that we > have a one-time contributor agreement that every contributor must agree to > exactly once. Included in that would be an agreement that they understand the > meaning of "Signed-off-by" in the context of Eclipse project repositories. > Whether this is strong enough from a legal perspective I couldn't say, but it > is already stronger than what other communities such as kernel.org do today. I > would really like to reduce the overhead required by contributors for every > single commit, so if there is a way we can document that understanding once I > think it would be a big improvement. yes, having to accept the meaning of Signed-off-by only once but consciously would be better than copying the three statements in an automated way which contributors will tend to ignore when they are copied by an automated process
*** Bug 382833 has been marked as a duplicate of this bug. ***
+1 for adding the legal blurbs to the small print. The "3 statements" are not too surprising, and they are also not the only interesting statements about the code (e.g. why doesn't the contributor have to tell that he tested the code and took reasonable efforts to ensure that it works as specified and does no harm?). May I ask why we need the "Signed-off-by" at all? Isn't the "Author" already all we need?
(In reply to comment #6) > May I ask why we need the "Signed-off-by" at all? Isn't the "Author" already > all we need? The author field tells you who created the commit, but it does not imply that they agree to submit the content to eclipse.org. Here is an example: - A non-committer forks an eclipse.org repository on github and makes some commits. This non-committer is marked as the author of the commits. - A committer, without asking, cherry-picks or merges that commit back into the eclipse.org repository. Now we have code in eclipse.org repository that we did not obtain the rights to distribute. Arguably under the EPL any changes or additions are automatically also EPL but not everything hosted at eclipse.org is EPL.
Ping. We need to remove crazy process overhead when accepting contributions. The solution is really simple: - As part of the bugzilla signup process, contributors agree that all their contributions to eclipse.org on all channels are legal and under EPL. - In Git and Gerrit, we track contributions via the Author field. - Done. (In reply to comment #7) Committers are responsible for what ends up in the repository, and this includes the Author part of a Git commit. > - A committer, without asking, cherry-picks or merges that commit back into the > eclipse.org repository. This would violate http://www.eclipse.org/legal/committerguidelines.php "How Content is Received". Since there are many other ways to make the same mistake, this argument does not constitute a necessity for any other mechanism than just using the Author field.
How shall we handle the need for knowing the contributor's employeer at the time the contribution was created and ensuring there is a signed consent form from that employeer in place? Of course the contributor's employeer can change over time, so an update-to-date signed agreement needs to be in place each time. It's not clear that we'd want the requirement for such agreements to be a barrier-to-entry for bugzilla so it seems we'd want some kind of "approved-for-EPL-contribution" flag associated with each bugzilla ID and perhaps when signing on, a conformation from the individual with an ID so approved, that their current employer is the same one as the one for which the current agreement is in place.
> [..] the contributor's employeer can change over time, [..] An interesting question, but this is also a point for the contributor agreement, and not something to bother committers. Also note that there's no fundamental difference between a patch and a Bugzilla comment that describes the bug or a code change -- and we don't have to ask commenters all the time whether their employer allows us to read a submitted comment, right?
I'm not sure if the previous comment is a suggestion to change the IP Policy. I believe the aim of this bugzilla is to arrive at a fast and effective mechanism for following the existing policy with the least possible overhead for both the committer and the contributor.
(In reply to comment #9) > How shall we handle the need for knowing the contributor's employeer at the > time the contribution was created and ensuring there is a signed consent form > from that employeer in place? There is no such requirement. We only require explicit employer consent for committers. There is implicit employer consent in the "three questions" (i.e. "have the rights to donate the content to Eclipse")
(In reply to comment #8) > The solution is really simple: > - As part of the bugzilla signup process, contributors agree that all their > contributions to eclipse.org on all channels are legal and under EPL. > - In Git and Gerrit, we track contributions via the Author field. > - Done. OK, could the legal team please confirm that the first point is already covered? I think it already is, see paragraph "For all other software, ..." in http://www.eclipse.org/legal/termsofuse.php Then we can just go with the author field and avoid data duplication.
(In reply to comment #13) > OK, could the legal team please confirm that the first point is already > covered? I think it already is, see paragraph "For all other software, ..." > in http://www.eclipse.org/legal/termsofuse.php > > Then we can just go with the author field and avoid data duplication. The other aspect is enforcing that we only accept contributions from people with bugzilla accounts. I think this is quite reasonable and this should already be the case. But through the Git metadata we could actually enforce this and ensure we have complete paperwork for all contributions. I believe today we scrape contributor information from Author field in Git without correlating that with a bugzilla account or any signed agreement about contributions (Wayne please correct me if wrong).
(In reply to comment #14) > I believe > today we scrape contributor information from Author field in Git without > correlating that with a bugzilla account or any signed agreement about > contributions (Wayne please correct me if wrong). Correct.
Can we finally close this bug and just use the Author field for contributor information? As I said in comment 13, the Eclipse terms already cover the "three questions", so we don't have to behave like a broken record player. The Signed-Off-By cited by comment 0 [2] is also not applicable in our case, since we have a simple one-step contribution process (contributor > committer).
(In reply to comment #16) > Can we finally close this bug and just use the Author field for contributor > information? I think we can probably use the Author field, but comment #14 is the most important part. There is no link today between Author field and a contributor agreement (the "three questions").
(In reply to comment #17) > (In reply to comment #16) > > Can we finally close this bug and just use the Author field for contributor > > information? Please be patient just a little bit longer. The EMO staff just met and talked about this a few days ago. We have a list of work items identified and we're committed to getting this done. At the moment the target date is Nov. 30.
Thanks for the updates.
> At the moment the target date is Nov. 30. Any new target date?
(In reply to comment #20) > Any new target date? I will be able to answer that question next Friday, February 22nd. The process of discussions at the IP Advisory Committee took a lot longer than I was hoping.
See also the Feb 2013 AC discussion: http://wiki.eclipse.org/Architecture_Council/Meetings/February_14_2013#New_Topics When using the git signed-off-by metadata, I'm wondering how that can be repaired if a potential contributor messed it up somehow and used a name or reference that can't be correlated with the respective bugzilla account and paperwork. Maybe a HOWTO for the contributor to repair it himself using git commandline ?
As explained before, the "Signed-Off-By:" tag doesn't carry any additional information, and should therefore NOT BE REQUIRED. (In reply to comment #22) > When using the git signed-off-by metadata, I'm wondering how that can be > repaired if a potential contributor messed it up somehow The Git source repo is not made for history rewriting. After-the-fact repairs are only performed for major issues. IP record tracking mistakes can be corrected with a follow-up commit (like other bad commits) or via external tools (iplog+ in Bugzilla).
(In reply to comment #23) > (In reply to comment #22) > > When using the git signed-off-by metadata, I'm wondering how that can be > > repaired if a potential contributor messed it up somehow > > The Git source repo is not made for history rewriting. After-the-fact > repairs are only performed for major issues. IP record tracking mistakes can > be corrected with a follow-up commit (like other bad commits) or via > external tools (iplog+ in Bugzilla). There will be no after the fact repairs because a hook will prevent such commits from ever being pushed to eclipse.org. Some kind of guide to help contributors understand what they need to do, and how to correct their commit if they got it wrong, would certainly be helpful. Especially considering not all contributors will be Git experts this is important.
(In reply to comment #23) > As explained before, the "Signed-Off-By:" tag doesn't carry any additional > information, and should therefore NOT BE REQUIRED. I disagree. It carries the additional information that the contributor has explicitly stated that they are making their contribution with full understanding of our rules regarding contribution. I'm curious to understand why you think it's unimportant. By my observation of other communities, it seems that signed-off-by and the concept of a "certificate of origin" go hand-in-hand. By requiring this extra (minor) step, we are essentially doing the same thing.
> I disagree. It carries the additional information that the contributor has > explicitly stated that they are making their contribution with full > understanding of our rules regarding contribution. This should already be confirmed during the signup process for a Bugzilla account, or when a contributor attaches a patch to Bugzilla or submits a patch via Gerrit. So this should already be confirmed for any commit that ends up in an eclipse.org repo where author != committer. The "Signed-Off-By" is just redundant in our situation, and however minor you think it is, Occam should take care of it [1]. Repeating comment #16: > The Signed-Off-By cited by comment 0 [2] is also not applicable in our case, > since we have a simple one-step contribution process (contributor > > committer). If you don't trust contributors, then make them do ping-pongs with the eclipse.org servers, but don't bother committers with it and don't pollute the repo. [1] http://en.wikipedia.org/wiki/Occam%27s_razor
(In reply to comment #23) > As explained before, the "Signed-Off-By:" tag doesn't carry any additional > information, and should therefore NOT BE REQUIRED. Markus, You may feel that signed-off-by is not useful, but there are lots of lawyers, managers, and adopters who disagree. Including some who are colleagues of yours :) To be completely blunt, getting this discussion through the IP Advisory Committee has taken months (quarters?) longer than I thought it would. There isn't a snowball's chance in hell that we are going to convince the lawyers that we don't need *any* indication of certificate of originality when we accept a contribution. I'm not exactly clear if you've read the current proposal[1] to do away with the three questions and implement contributor license agreements? I strongly believe that this approach is going to be a big win for reducing the committer work load involved in accepting contributions. If the cost of doing so is an extra line of text in our commit records, I humbly suggest that you happily accept that outcome. [1] http://dev.eclipse.org/mhonarc/lists/eclipse.org-architecture-council/pdfTFBLGJ8Tto.pdf
Yes, I read the proposal, and I fully agree with doing away with the three questions and implementing contributor license agreements. I don't care too much who believes what. I care about a lean process, and I expect justifications for process overheads. I still don't see a justification for Signed-off-by. "Embrace the “git way”" or "XY said" are not justifications. Can you give me cases in our process where the Signed-off-by tag has not the same id as the author? If not, then I would like to hear an other justification for the Signed-off-by tag. The certificate of originality is implied by the terms that contributors accepted. In the repository, it is reflected by the "author != committer" condition (for authors that were not committers at the AuthorDate time). To also be blunt: If the lawyers think that the Signed-off-by would influence the committing process, then I can assure you they are wrong: Committers would just install a plug-in or a .gitattributes that automatically adds the redundancy if author != committer.
Markus, what you are suggesting is that once someone has signed a CLA, all code that they author is implicitly assumed to be contributed to Eclipse. Say I am a contributor and I have signed a CLA. I also have other forks of projects from Eclipse that I do not want to contribute back. There is no way for me as the author to indicate agreement to contribute or not for any particular commit. This level of automatic implicit agreement for everything I author was not acceptable to the legal council that need to agree with these changes. This was the best we could do, and I'm sorry that in many cases there is some redundancy. In the end "I wrote the code", and "I agree to contribute" are not the same statement and we are not going to get agreement from the IP team that they are.
(In reply to comment #28) > To also be blunt: If the lawyers think that the Signed-off-by would > influence the committing process, then I can assure you they are wrong: > Committers would just install a plug-in or a .gitattributes that > automatically adds the redundancy if author != committer. Let me be equally blunt: it would be a violation of our IP process for a soon-to-be-former committer to insert a signed-off-by statement on behalf a contributor.
(In reply to comment #29) Thanks for these explanations. So, the Signed-off-by is meant to be a device for contributors to track their work in private forks? I.e. absence of Signed-off-by means they don't want to publish these changes to Eclipse (and hence they can't ship a product including them)? I don't care if they do that, but I don't see what this has to do with Eclipse. As we've seen in comment 7/8, all contributions that legally end up on Eclipse Foundation servers already have to imply Signed-off-by by the author. There is still not a single scenario where a committer could legally receive and commit a patch with a different author where the author hasn't agreed to the Eclipse terms. The difference between "I wrote the code" and "I agree to contribute" is that for the second, they have to submit the code to Eclipse. The Signed-off-by doesn't change anything. I'd still like someone from the IP team who defends the Signed-off-by to step up and present a single scenario where Signed-off-by makes a difference.
(In reply to comment #30) > Let me be equally blunt: it would be a violation of our IP process for a > soon-to-be-former committer to insert a signed-off-by statement on behalf a > contributor. For Gerrit changes, that's true. If we get a patch via Bugzilla, there's no other way than the committer inserting the Signed-off-by into the commit message. Is Signed-off-by just to screw committers and complicate the process, or is there anything else?
(In reply to comment #32) > For Gerrit changes, that's true. If we get a patch via Bugzilla, there's no > other way than the committer inserting the Signed-off-by into the commit > message. For contributions that come through Bugzilla, the old processes will still apply. > Is Signed-off-by just to screw committers and complicate the process, or is > there anything else? <sarcasm>That's _exactly_ what we were thinking.</sarcasm> Did you find the presentation materials in the AC meeting link: http://dev.eclipse.org/mhonarc/lists/eclipse.org-architecture-council/msg01868.html We believe that this makes everything _much_ easier. I'd like to understand how you feel that this screws committers and complicates the process.
(In reply to comment #33) > We believe that this makes everything _much_ easier. I agree, it makes it much simpler - thanks for that! The only remaining issue is the explanation, from a legal person/standpoint, why the additional signed-off-by is required for contributions that come via Eclipse Gerrit, where the author explicitly contributes. Some real life examples would help to understand it better.
(In reply to comment #33) > For contributions that come through Bugzilla, the old processes will still > apply. Sad to hear. > [..] > We believe that this makes everything _much_ easier. I'd like to understand > how you feel that this screws committers and complicates the process. Already answered in comment 28: > Yes, I read the proposal, and I fully agree with doing away with the three > questions and implementing contributor license agreements. The only part of the proposal I question is the unjustified Signed-off-by.
(In reply to comment #35) > The only part of the proposal I question is the unjustified Signed-off-by. Yes. Well. Your concerns are duly noted. The Board and the IP Advisory Committee both approved the combination of CLA and signed-off-by today. We can revisit this with them in a year or so, if it truly turns out that signed-off-by is a crushing burden on our committers. Next up is actually implementing all of the required changes. For those who are interested, I think the main discussions will be happening on bug 401236.
(In reply to comment #33) > (In reply to comment #32) > > > For Gerrit changes, that's true. If we get a patch via Bugzilla, there's no > > other way than the committer inserting the Signed-off-by into the commit > > message. > > For contributions that come through Bugzilla, the old processes will still > apply. Actually, I don't think that the old process will apply for contributions that come through Bugzilla. We will be moving to the CLA approach for *all* contributions. A user interface will be supplied which will allow committers to check if a given contributor has a CLA on file. (Likely keyed by email address.) So for a patch on Bugzilla, the committer will check whether there is a CLA on file for the contributor, rather than asking the 3 questions. If there is no CLA on file, the committer will have to ask the contributor to compete a CLA. We've had some preliminary discussions on whether it would be possible to provide decorators in Bugzilla so there are immediate visual clues as to whether a person is a committer, and/or has a CLA on file. Still investigating that idea at this time.
> if > it truly turns out that signed-off-by is a crushing burden on our committers. Depending on the implementation, it's probably not going to be a huge burden. But it pollutes the repos and gives a bad example in that even the Eclipse Foundation appears to be driven by anonymous lawyers that shy public discussion. Those who promoted the use of Signed-off-by and could not rationalize that decision should be ashamed of themselves. Anyway, let's get back to work.
(In reply to comment #38) > Depending on the implementation, it's probably not going to be a huge > burden. But it pollutes the repos and gives a bad example in that even the > Eclipse Foundation appears to be driven by anonymous lawyers that shy public > discussion. > > Those who promoted the use of Signed-off-by and could not rationalize that > decision should be ashamed of themselves. Anyway, let's get back to work. This has been publicly explained to you several times. There must be documentation that the contributor consented to contribute the change. A mechanism that relies only on implicit consent will not be accepted.
Here is a really good summary on the signed-off-by : http://stackoverflow.com/questions/1962094/what-is-the-sign-off-feature-in-git-for I understand that in case a lawsuit arises around some contribution, the poor fellow who put in the signed-off-by (be it manual or through some automated mechanism) is on the hook for proving that he authored the contribution in accordance the receiving organization's CLA (in contrast to authoring something just for fun, without my employer's consent for instance). Quite a burden on the submitter actually, and I hope that submitters will understand it... that will be a matter of keeping the CLA concise and understandable, ideally with the 3 questions right on top in an abstract of some sort. I assume that committers will still have the task of scanning inbound contributions for violation such as profanity (due diligence). My one remaining question though is also unanswered on the article cited above: without a PGP key, how can it be established that the signed-off-by is genuine ? For sure I don't want to be on the hook when somebody else entered my E-Mail address in a rogue signed-off-by record...
> how can it be established that the signed-off-by is genuine ? Exactly my point. And since the author field and the Signed-off-by are equivalent, the author field is already good enough as an explicit consent. Of course, this all assumes the committer fulfills his duties (doesn't forge data and doesn't receive contributions through illegal channels).
I think the signed-off-by makes sense for the Linux Kernel, where Patches are typically submitted via the LKML mailing list and in the E-Mail this looks really like a signature. For example: http://lkml.indiana.edu/hypermail/linux/kernel/1302.2/02568.html Looking at Eclipse.org, the thing that seems odd to me in the Workflow is that I'm adding my signoff locally (when committing into my local repo) and then I can push from my local repo with the signoff, or a committer pulls from my local or github repo thereby checking the signoff. In other words, we don't have control over the mechanisms how the signoff is added to the commit record. It would feel more logical to me, if the contributor had to push his contribution to some special "incoming" git repo and that repo has a trigger or web UI which brings up a dialog "Dear submitter, you've aggreed to the CLA before, do you sign off that this contribution is in accordance with the CLA ?" Essentially this "incoming git repo" sounds much like Gerrit. But it might also be an automated Web UI where the contributor can self-service pull requests. I enter the URL for the pull request to initiate, the web UI asks "do you sign off" ? and only if I click yes then it pulls. Does that make sense ?
(In reply to comment #42) > I think the signed-off-by makes sense for the Linux Kernel, where Patches > are typically submitted via the LKML mailing list and in the E-Mail this > looks really like a signature. For example: > > http://lkml.indiana.edu/hypermail/linux/kernel/1302.2/02568.html > > Looking at Eclipse.org, the thing that seems odd to me in the Workflow is > that I'm adding my signoff locally (when committing into my local repo) and > then I can push from my local repo with the signoff, or a committer pulls > from my local or github repo thereby checking the signoff. In other words, > we don't have control over the mechanisms how the signoff is added to the > commit record. > > It would feel more logical to me, if the contributor had to push his > contribution to some special "incoming" git repo and that repo has a trigger > or web UI which brings up a dialog "Dear submitter, you've aggreed to the > CLA before, do you sign off that this contribution is in accordance with the > CLA ?" > > Essentially this "incoming git repo" sounds much like Gerrit. But it might > also be an automated Web UI where the contributor can self-service pull > requests. I enter the URL for the pull request to initiate, the web UI asks > "do you sign off" ? and only if I click yes then it pulls. > > Does that make sense ? Actually Gerrit supports CLAs [1], if this is configured a new contributor has to first sign the CLA (through Gerrit workflow) and only then can push contributions for review. The timestamped CLA record is kept in Gerrit's database. Gerrit also provides a hook [2] which is called when a user signs a CLA record. [1] https://groups.google.com/d/msg/repo-discuss/GZwwFASNjBM/wE16UKNJedkJ [2] http://gerrit-documentation.googlecode.com/svn/Documentation/2.5.2/config-hooks.html#_cla_signed
> Actually Gerrit supports CLAs [1], if this is configured a new contributor > has to first sign the CLA (through Gerrit workflow) and only then can push > contributions for review. The timestamped CLA record is kept in Gerrit's > database. Gerrit also provides a hook [2] which is called when a user signs > a CLA record. > > [1] https://groups.google.com/d/msg/repo-discuss/GZwwFASNjBM/wE16UKNJedkJ > [2] > http://gerrit-documentation.googlecode.com/svn/Documentation/2.5.2/config- > hooks.html#_cla_signed Interesting. I did not know that. Given that not all projects use Gerrit, I doubt that this could be the total solution. But it looks like it may have some interesting potential to be part of the solution.
> Given that not all projects use Gerrit, I doubt that this could be the total > solution. It might be worth our while to make Gerrit part of the total solution. As I know it, Gerrit can be relatively transparent to those committers who do not wish to use it as a code review tool for everyday work. Furthermore, Gerrit has its own SSH engine, which removes the need for shell accounts (even restricted) on our servers, and provides SSH key management facilities, which we currently do not have. Having Gerrit manage the CLAs just seems like a good way to leverage existing tools instead of writing our own. Just a thought.
(In reply to comment #44) > > Actually Gerrit supports CLAs [1], if this is configured a new contributor > > has to first sign the CLA (through Gerrit workflow) and only then can push > > contributions for review. The timestamped CLA record is kept in Gerrit's > > database. Gerrit also provides a hook [2] which is called when a user signs > > a CLA record. > > > > [1] https://groups.google.com/d/msg/repo-discuss/GZwwFASNjBM/wE16UKNJedkJ > > [2] > > http://gerrit-documentation.googlecode.com/svn/Documentation/2.5.2/config- > > hooks.html#_cla_signed > > Interesting. I did not know that. The CLA support isn't yet properly documented that's why it's not widely known, will fix this.
(In reply to comment #45) > > Given that not all projects use Gerrit, I doubt that this could be the total > > solution. > > It might be worth our while to make Gerrit part of the total solution. As I > know it, Gerrit can be relatively transparent to those committers who do not > wish to use it as a code review tool for everyday work. yeah, that's just a matter of permission settings > Furthermore, Gerrit has its own SSH engine, which removes the need for shell > accounts (even restricted) on our servers, and provides SSH key management > facilities, which we currently do not have. > > Having Gerrit manage the CLAs just seems like a good way to leverage > existing tools instead of writing our own. +1, at SAP we host all Git repositories on Gerrit and this works pretty nicely. In the meantime it's also easy to customize approval workflows using prolog rules [1]. Since 2.5 more sophisticated extensions can be implemented as Gerrit plugins [2] and in 2.6 development there is good progress towards enabling UI plugins [3]. [1] http://gerrit-documentation.googlecode.com/svn/Documentation/2.5.2/prolog-cookbook.html [2] http://gerrit-documentation.googlecode.com/svn/Documentation/2.5.2/dev-plugins.html [3] https://groups.google.com/forum/?fromgroups=#!searchin/repo-discuss/ui$20plugin/repo-discuss/iPdMKNVJzcU/NwgBzJgqvqgJ
The Eclipse Foundation Certificate of Originality went live today. So to answer the question implicit in the title of this bug: YES we have adopted signed-off-by. Please start ensuring that all contributions are signed-by. Committers also need to verify that a contributor has a valid CLA on file. You can check by entering their email address into [1]. Future enhancements - such as providing decorators in Bugzilla for contributors with CLAs - are on the table. [1] projects.eclipse.org/user/cla/validate
Can someone who knows all the details post information on the all-committers mailing list? Inevitably questions will start being asked as soon as commits start bouncing.
(In reply to comment #49) > Can someone who knows all the details post information on the all-committers > mailing list? Inevitably questions will start being asked as soon as commits > start bouncing. Yes, I will. But for the record, commits won't start bouncing until the day after Kepler ships. (Thursday, June 27, 2013)
> The Eclipse Foundation Certificate of Originality went live today. So to > answer the question implicit in the title of this bug: YES we have adopted > signed-off-by. Please start ensuring that all contributions are signed-by. I think we can resolve this bug as FIXED?
(In reply to Denis Roy from comment #51) > > The Eclipse Foundation Certificate of Originality went live today. So to > > answer the question implicit in the title of this bug: YES we have adopted > > signed-off-by. Please start ensuring that all contributions are signed-by. > > I think we can resolve this bug as FIXED? +1
This is implemented.
