Date: Dynamically augment skeleton #703
Conversation
|
Marat Dyatko seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account. |
Rework of `getBestMatchPattern` algorithm - properly handle close parts of sekletons, i.e. `L` and `M` - better distance calculating Call to `getBestMatchPattern` before splitting skeleton to date and time parts Add a lot of test cases to `expandPattern` function. Fixes globalizejs#271
rxaviers
force-pushed
the
fix-271
branch
3 times, most recently
from
a4e2a42 to
e2a424e
Compare
|
This should not have been merged without new CLA signatures. The jQuery Foundation CLA is no longer valid so new signatures are needed. If the bot says a signature is needed, it is because the system does not have a signature for them. @Strate and @vectart will need to sign or these changes need to be backed out. |
|
Is this valid for all old PRs? For example #639? |
|
Yes. The PR must have a valid signature at the time it is merged which means they need to sign the new CLA |
|
I just signed a new CLA |
This is absolutely not true. @kborchers You've already made such a mess of the CLA process, please don't make it even worse with this nonsense. |
|
Thank you for your input Scott. As per legal's advice, all contributions to JS Foundation projects must be licensed via the latest version of the JS Foundation CLA and may not be made under the jQuery Foundation CLA. No project should be accepting contributions unless the CLA Assistant has marked them as valid meaning the contributor(s) have signed the latest JS Foundation CLA. |
|
So when are you starting the arduous process of gathering new signatures for every project again? I'm guessing you're not, so none of this would matter anyway. I'm only slightly surprised that legal is giving you such crazy advice. I'm also only slightly surprised that you would have accepted that as a reasonable outcome. |
|
@kborchers to be honest, it's not obviously clear to me why old PRs that have valid CLA signature under the jQuery CLA (which was all we had by that time) needs a re-signature using the new JF CLA. Also almost all of globalize code is under the old CLA. Would we need to ask everyone to re-sign it under the new CLA? This is a little confusing to me. Note that both commits included here that brings Marat Dyatko and Strate names come from old PRs and haven't been touched. They are here only for matter of rebase and the fact I created this new "merger" PR. |
|
Can we get legal to revisit this and provide us clarification please? Thanks |
|
As I stated, we need signatures for new contributions which is anything being merged since the new CLA and new CLA system were put in place. Ignoring the checks and merging PRs without new signatures, even if you believe there are old signatures that should work, defeats the purpose of the system and its ability to accurately track signatures. There is no need to get new signatures for old contributions because those licenses transfered from jQuery Foundation to JS Foundation when it was created. I have requested that legal review this entire conversation and let me know if anything I have said is incorrect. |
Who cares if it defeats the purpose of the system? That's just red tape and serves no practical purpose for contributions that are already known by real people to be perfectly valid. It's super annoying that you care more about a broken system (yes, losing hundreds of valid signatures is broken) than reality. |
|
@kborchers please did you get a response from legal? |
|
As @kborchers said, he asked me to review this thread and respond here to try and clarify. Briefly, as part of the transition from the jQuery Foundation to the JS Foundation, the CLA was updated in important ways, including changes made to default provisions, changes made to bring it in line with the Foundation's new IP Policy, and incorporation of that policy. These changes were designed so that code that is licensed under the prior CLA remains legally compatible. That is, the updates to the CLA, and the need to get signatures for new contributions and newly merged code, does not legally invalidate prior CLAs or require that all previously contributed code be re-licensed. However, in so much as important legal changes were made to the CLA, all additions of code to a project from the date the updated CLA was implemented must be made under the updated CLA. I understand that that has caused some confusion and additional work where the pull request was submitted but not merged prior to the updated CLA taking effect. For our purposes though, the important date is the merge date, since that's when code actually becomes a part of a project, and we need to be sure that everything that is added to a project after the implementation date of the updated CLA is done under that updated CLA. Hopefully this clarifies things for everyone, but if there are any remaining questions please let me know. |
Why does the merge date matter? Every version of the CLA has always been effective forever into the future and the past. So the only dates that really matter are the dates the CLAs are signed. Anyone having signed under one of the prior CLAs can have any future contribution merged under the conditions of that CLA. |
|
The issue is not that prior CLAs have become ineffective, it's that the Foundation has updated the CLA, those updates are legally important, and therefore the Foundation needs those updates to be legally applicable to all additions of code from the date of the transition to the JS Foundation forward. In order for those updates to be legally applicable, contributors must sign the updated CLA. In order to make sure no code is contributed without being subject to the updated CLA, the contributor must sign the updated CLA before the code is merged. |
|
Please explain at least one legally important update that applies here. |
|
@StevenAyr please could you also clarify the definition of "code is merged"? Thanks. PS: Note this topic is important to us. It isn't much about this PR in particular, whose committers have already re-signed the CLA (although the red cross is still displayed above). One of the reasons it's important is due to the open PRs we have. |
|
@rxaviers The reason @vectart is marked as invalid is because the email in the commit is not associated with the GH account. GitHub even shows an issue when you look at the commit. I'm not sure why @Strate is marked invalid, I'll have to dig into that one a bit more. |
|
@rxaviers I certainly appreciate that this is a process issue that you'll see come up multiple times and that you need clear guidance on, so no problem at all. Merging means approving a pull request and accepting a contributor’s code into a JS Foundation project. Alternatively, if someone has commit privileges, they’ll need to have signed the updated CLA prior to making a direct commit to a repo. |
|
Burn JS Foundation burn |
|
Still waiting for at least one legally important update that applies here. |
|
@StevenAyr, please could you reply @scottgonzalez, I think his question is pertinent and will help us have a better understanding of the process. Thanks |
|
@scottgonzalez @rxaviers Among other changes, the updated CLA gives the Foundation the ability to re-license contributions under Apache 2.0. This is significant because Apache 2.0 provides for a patent license that MIT does not. |
|
Can you be more specific about which part of the CLA grants that right? I don't see anything that would indicate that the foundation gets special privilege for relicensing or that the contributor is granting a patent license. As far as I can tell, for this (and many other projects), the new CLA is still only granting rights under the terms of the MIT license (and CC0 for sample code). |
|
"You understand and agree that the JS Foundation projects and your Contributions are public and that a record of the Contributions (including all metadata and personal information you submit with them) is maintained indefinitely and may be redistributed consistent with the JS Foundation’s policies and the requirements of the Apache v2.0 license where they are relevant." (Emphasis added) |
|
So does "where they are relevant" not mean anything? It doesn't matter what license the projects use, the foundation always gets permission to relicense under Apache 2? Have any of the project maintainers been made aware of this? Honestly, the wording of the new CLA is ridiculously confusing compared to the old CLA. |
|
Let me add my own emphasis to the same sentence: "You understand and agree that the JS Foundation projects and your Contributions are public and that a record of the Contributions (including all metadata and personal information you submit with them) is maintained indefinitely and may be redistributed consistent with the JS Foundation’s policies and the requirements of the Apache v2.0 license where they are relevant." The redistribution in section b seems to be talking about the record (all metadata and personal information), not about the contributions themselves. This is the interpretation I had when I first read the CLA, though I interpreted it to even be more restricted than that because of the "where they are relevant" clause. I assumed this meant that the redistribution requirements for Apache 2 were only relevant when Apache 2 actually applied. I'd also like to know how the patent licensing is helpful at all if the contributor isn't granting any rights related to patents. Even if the new CLA does accomplish what you're saying, you'd need to get signatures from all past contributors to take advantage of any new permissions. The foundation has definitely not done this and as far as I know isn't attempting to do so. |
|
@StevenAyr thank you for replying @scottgonzalez questions. @kborchers please do you have any updates about @Strate and @vectart signatures? |
|
I still have unanswered questions about section b and why it matters if contributors sign the new CLA. Without 100% coverage of contributions under the new CLA, the foundation can't take advantage of any new rights anyway. |
|
It's been another month and I still have unanswered questions. Providing legal services is one of the very few things the foundation does and so far that has been pretty poor. The CLA changed with no project discussion, all previous signatures were effectively thrown away, and we can't get answers to the questions we have about the changes. I guess that's par for the course with the foundation though. |
|
@kborchers please do you have any updates about @Strate and @vectart signatures? 1.3.0 should be released. Thanks |
|
@rxaviers i am still not 100% sure why those are not marked as signed as I see signatures in the database for both handles. My guess is that the issue is due to incorrect emails and also the bug I mentioned where it only checks the primary email address on a GH account. This change is fine to include in your release and I will continue looking into the issue. |
Excellent, ok thanks |
|
Yet another month with no response. The foundation's claim to care about its projects lacks any substance. It's been nothing but executive orders, complete lack of transparency, and a total loss of money to support projects. How does the foundation think this is acceptable behavior? |
This is #604 continued... It will eventually fix #271 and close #462...