Community
Participate
Working Groups
We'll use this bug to track the release We require IP Team approval of the IP Log. We require PMC approval of the release and review materials. There's help regarding releases in the handbook. https://www.eclipse.org/projects/handbook/#release
The README says: -- The MRAA project is joining the Eclipse Foundation as an Eclipse IoT project. You can read more about this [here](https://projects.eclipse.org/proposals/eclipse-mraa). -- I'm hopeful that you agree that the tense should be changed :-) The "Contact Us" section should also point to the project's dev list (mraa-dev). The CONTRIBUTING file contains this line: -- If you'd rather not use github you are more than welcome to send git formatted patches to our mailing list mraa@lists.01.org which you can register for access on: https://lists.01.org/mailman/listinfo/mraa -- Please use the dev list. Strictly speaking, it is probably okay to accept a git formatted patch (with a signed-off-by footer by a contributor who has signed the ECA) via the project's dev list where the user will have agreed to terms of use, but not on some other list. The main wrinkle is that our ECA-checker scripts will probably try to stop you from merging the commit.
The IP Log is approved.
Created attachment 284476 [details] mraa v2.2.0 release candidate with update readme and contributing
(In reply to Wayne Beaton from comment #1) > The README says: > > -- > The MRAA project is joining the Eclipse Foundation as an Eclipse IoT project. > You can read more about this > [here](https://projects.eclipse.org/proposals/eclipse-mraa). > -- > > I'm hopeful that you agree that the tense should be changed :-) > > The "Contact Us" section should also point to the project's dev list > (mraa-dev). > > The CONTRIBUTING file contains this line: > > -- > If you'd rather not use github you are more than welcome to send git > formatted > patches to our mailing list mraa@lists.01.org which you can register for > access > on: https://lists.01.org/mailman/listinfo/mraa > -- > > Please use the dev list. Strictly speaking, it is probably okay to accept a > git formatted patch (with a signed-off-by footer by a contributor who has > signed the ECA) via the project's dev list where the user will have agreed > to terms of use, but not on some other list. The main wrinkle is that our > ECA-checker scripts will probably try to stop you from merging the commit. Hi Wayne, I have addressed your comments and decided to remove the mention to the mailing list from the CONTRIBUTING file. It is mentioned on the main readme as a way to contact us instead. The only approved way to contribute is via Github Pull Requests. Changes can be previewed here: https://github.com/Propanu/mraa/tree/swig-build-patches If this is approved I will go ahead and merge it upstream then mark the release. Thank you, Tudor
> If this is approved I will go ahead and merge it upstream then mark the > release. +1
I still require PMC approval. Send the the PMC a note via the top-level project’s PMC mailing list with a link to the release record. Note that the release record page has a handy link labeled Committer Tools › Send Email the PMC. I've set the review and release date to October 21/2020. I need PMC approval before I can declare success on that date. Note that the release review process is described in detail in the handbook [1]. Note also that, following a successful release review, the project may create as many releases as necessary for a full year. [1] https://www.eclipse.org/projects/handbook/#release-review
(In reply to Mihai T Panu from comment #3) > Created attachment 284476 [details] > mraa v2.2.0 > > release candidate with update readme and contributing There's no requirement to attach your project content to this bug. If you need a distribution channel for direct downloads, the Eclipse Foundation's download server is available to you (not required, but available if you need it).
I declare this review successful. Please continue with your release.
