Re: Better discussion forum?
Thanks Jesse, that "one rule" was not clear to me until just now. Any suggestions about how we should this clear to new contributors, new committers, and new Cordova developers in general? On Wed, Aug 1, 2018 at 1:22 AM Jesse wrote: > > We actually used to be a lot stricter with this, but I think the one rule > is, was, and for always should be "If it didn't happen on the list, it > didn't happen." > > When Cordova was being driven by larger entities, the > Adobe/IBM/Google/Intel/Microsoft years, we had tons of contentious > decisions as companies to some extent were also representing their own > interests in the library. In this era, everything had to be finalized on > the list. We would discuss elsewhere, collaborate where-ever, but the > decision always came back to the list, so everyone had a chance to be > involved. > > There are many other mediums which make collaboration flow better, and we > should continue to embrace them, just bring it back to the list as a > discuss thread here so there are no surprises. The list also serves as a > living record of every decision we have made over the years, and hopefully > will become a book someday, if not a movie ... > > > @purplecabbage > risingj.com > > On Tue, Jul 31, 2018 at 10:57 AM, Darryl Pogue wrote: > > > To expand on this a bit more, annoying as the mailing list might be, I > > think the project would be better for having a more active mailing > > list and not having discussions spread across lists and multiple > > GitHub repos and Slack and JIRA and various Google Docs. I'm > > definitely guilty of adding to that spread of information because it's > > convenient, but it does impose a bit of a barrier for participation. > > > > The idea is that all decisions have to happen on the mailing list, > > because this is the one place that all Cordova devs are supposed to be > > subscribed. This is the one place that everyone can watch to keep on > > top of what's happening in the project. > > > > We've been *terrible* at that over the years, and it's made it hard to > > provide feedback on changes because I didn't know they were happening. > > Roadmaps were discussed in face-to-face meetings or video calls and > > not brought back to the list for review, and it was hard to find out > > what was being worked on short of stumbling upon tasks in JIRA or > > watching peoples' personal GitHub forks. > > I don't say that to put blame on anyone, because they were doing what > > they'd always done and there wasn't (and isn't) a culture of bringing > > things back to the list. But I do say it because I think we can > > improve and I think it's worthwhile to try to use the list as the > > place for discussions so that there's a recorded history of decisions. > > > > I know plaintext email doesn't offer nearly as much in the way of > > formatting, so at the very least it would be good to send a link to > > proposal documents to the list, and ask for feedback to be posted in > > that thread. > > > > On Tue, Jul 31, 2018 at 10:32 AM Darryl Pogue wrote: > > > > > > Apache Software Foundation projects use mailing lists for communication. > > > It is The Apache Way. > > > > > > See http://apache.org/foundation/how-it-works.html#communication > > > > > > On Tue, Jul 31, 2018 at 10:10 AM Chris Brody > > wrote: > > > > > > > > I would really love to see a better discussion forum for ideas. I > > > > think the mail list is not so handy for forums with cross-referencing > > > > and cordova-discuss proved to be a failure. npm.community seems to > > > > have nailed it, though it may have been meant to solve another > > > > problem. Any comments? > > > > > > > > - > > > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > > - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: Time to mark major Cordova release & remove committed node_modules?
+1 If the repo does not support node 4 in the master branch, then the version should be a major bump. When it gets released, and what else makes it in is a separate discussion as I see it. @purplecabbage risingj.com On Tue, Jul 31, 2018 at 2:59 PM, Chris Brody wrote: > To clarify a few things: > > By "mark major Cordova release" I meant "mark major Cordova release > dev version", such as cordova-ios@5.0.0-dev, > cordova-windows@7.0.0-dev, etc. as I had said in a couple other > responses. I also confirmed in a couple other responses that I would > not make any actual major release yet. I hope I got this clear now, > please respond if not. > > My idea was that "minor" patch releases would be made from existing > patch release branches, e.g. 4.5.x for iOS, 6.0.x for Windows, etc. > etc. It should be straightforward to cherry-pick anything we need from > master as needed moving forward. > > A possible alternative would be to make new minor release branches > based off of master now. But I don't see much benefit of new minor > release branches at this point. For the upcoming patches I would > rather not include any more changes than necessary. And for subsequent > "minor" patch releases I think it would be less "busy work" to > continue with the existing patch release branches than make new minor > release branches. But I would appreciate feedback if anyone would like > to discuss a counterpoint here. > > Yes I am planning to make a new "minor" CLI patch release with latest > cordova-android, cordova-windows, and other platforms pinned, once I > publish the remaining platform patches and update other needed tools > packages. And it should be no problem to make additional CLI patch > releases with more platform "minor" patches if needed. (I think you > can start to see it takes so much @#$% time to update, test, review, > document, and publish every single patch release.) > > An additional point is that if someone publishes another > cordova-android@7.0.x patch with SDK & plugin problems solved within > the next few days I would be happy to include it in the coming CLI > patch release. > > I would appreciate a response if this addresses the concerns or not. > On Tue, Jul 31, 2018 at 5:27 PM julio cesar sanchez > wrote: > > > > I think the node deprecation is enough for a major bump, but we should > take > > this opportunity to make any other needed breaking change. > > > > But as next major releases will take time, not sure if we could do a last > > cli (minor) release with latest Cordova-Android and Cordova-windows > pinned. > > This will benefit services such as phonegap build that don’t allow to > > choose the platform version and use the pinned version instead (and > people > > who doesn’t know they can install newer versions), which is a blocker for > > people using push plugin as it requires Cordova-Android 7.1.0. > > > > > > > > > > El martes, 31 de julio de 2018, Jan Piotrowski > > escribió: > > > > > So this would e.g. bump cordova-windows master from 6.1.0-dev to > > > 7.0.0-dev, so it would be clear that the next release would most > > > probably be a major one, correct? > > > > > > Actual release of that version would only happen if there are enough > > > "real" changes that justify a major release anyway, right? > > > > > > -J > > > > > > 2018-07-31 22:37 GMT+02:00 : > > > > +1 > > > > > > > > Chris Brody schrieb am Di., 31. Juli 2018, > > > 21:23: > > > > > > > >> Exactly, thanks for the clarification. > > > >> On Tue, Jul 31, 2018 at 3:19 PM Darryl Pogue > > > wrote: > > > >> > > > > >> > +1 > > > >> > > > > >> > Just to be clear, we're proposing to bump to the next major -dev > > > >> > version, not actually making any major version releases yet, > correct? > > > >> > i.e., cordova-ios 4.6.0-dev -> cordova-ios 5.0.0-dev > > > >> > > > > >> > On Tue, Jul 31, 2018 at 12:14 PM Chris Brody < > chris.br...@gmail.com> > > > >> wrote: > > > >> > > > > > >> > > Now that we have dropped support for deprecated Node.js 4 in > master > > > >> > > branch of most repos, I think it is high time to do the > following: > > > >> > > * mark next major release version in the affected repos > > > >> > > * remove committed node_modules from the affected platform repos > > > >> > > > > > >> > > I would like to request feedback within the next 1-2 days in > case of > > > >> > > any objections. I would like to proceed with these items within > the > > > >> > > next week in case there are no major objections. > > > >> > > > > > >> > > > > > - > > > >> > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > > >> > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > >> > > > > > >> > > > > >> > > - > > > >> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > > >> > For additional commands, e-mail: dev-h...@cordova.apache.org > > > >> >
Re: Better discussion forum?
We actually used to be a lot stricter with this, but I think the one rule is, was, and for always should be "If it didn't happen on the list, it didn't happen." When Cordova was being driven by larger entities, the Adobe/IBM/Google/Intel/Microsoft years, we had tons of contentious decisions as companies to some extent were also representing their own interests in the library. In this era, everything had to be finalized on the list. We would discuss elsewhere, collaborate where-ever, but the decision always came back to the list, so everyone had a chance to be involved. There are many other mediums which make collaboration flow better, and we should continue to embrace them, just bring it back to the list as a discuss thread here so there are no surprises. The list also serves as a living record of every decision we have made over the years, and hopefully will become a book someday, if not a movie ... @purplecabbage risingj.com On Tue, Jul 31, 2018 at 10:57 AM, Darryl Pogue wrote: > To expand on this a bit more, annoying as the mailing list might be, I > think the project would be better for having a more active mailing > list and not having discussions spread across lists and multiple > GitHub repos and Slack and JIRA and various Google Docs. I'm > definitely guilty of adding to that spread of information because it's > convenient, but it does impose a bit of a barrier for participation. > > The idea is that all decisions have to happen on the mailing list, > because this is the one place that all Cordova devs are supposed to be > subscribed. This is the one place that everyone can watch to keep on > top of what's happening in the project. > > We've been *terrible* at that over the years, and it's made it hard to > provide feedback on changes because I didn't know they were happening. > Roadmaps were discussed in face-to-face meetings or video calls and > not brought back to the list for review, and it was hard to find out > what was being worked on short of stumbling upon tasks in JIRA or > watching peoples' personal GitHub forks. > I don't say that to put blame on anyone, because they were doing what > they'd always done and there wasn't (and isn't) a culture of bringing > things back to the list. But I do say it because I think we can > improve and I think it's worthwhile to try to use the list as the > place for discussions so that there's a recorded history of decisions. > > I know plaintext email doesn't offer nearly as much in the way of > formatting, so at the very least it would be good to send a link to > proposal documents to the list, and ask for feedback to be posted in > that thread. > > On Tue, Jul 31, 2018 at 10:32 AM Darryl Pogue wrote: > > > > Apache Software Foundation projects use mailing lists for communication. > > It is The Apache Way. > > > > See http://apache.org/foundation/how-it-works.html#communication > > > > On Tue, Jul 31, 2018 at 10:10 AM Chris Brody > wrote: > > > > > > I would really love to see a better discussion forum for ideas. I > > > think the mail list is not so handy for forums with cross-referencing > > > and cordova-discuss proved to be a failure. npm.community seems to > > > have nailed it, though it may have been meant to solve another > > > problem. Any comments? > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > >
Nightly build #806 for cordova has succeeded!
Nightly build #806 for cordova has succeeded! The latest nightly has been published and you can try it out with 'npm i -g cordova@nightly' For details check build console at https://builds.apache.org/job/cordova-nightly/806/consoleFull - Jenkins for Apache Cordova - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: Android maintainer lookup to merge cordova-plugin-statusbar PR
I have not personally worked with that plugin and have no extra time right now, hoping the right expert will take a look. @Adam please feel free to ping back as needed, I think maintainers are pretty overloaded. I should be able to take a look sometime next month if nobody else has handles it first. On Tue, Jul 31, 2018, 9:47 PM Adam Szmyd wrote: > Hello, > > We have PR opened for cordova-plugin-statusbar repo > (https://github.com/apache/cordova-plugin-statusbar/pull/99) and we need > one of maintainer with enough Android experience to check and merge it. > > -- > Best regards > Adam Szmyd > > > - > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > >
Re: Better discussion forum?
+1 On 7/31/2018 12:57 PM, Darryl Pogue wrote: To expand on this a bit more, annoying as the mailing list might be, I think the project would be better for having a more active mailing list and not having discussions spread across lists and multiple GitHub repos and Slack and JIRA and various Google Docs. I'm definitely guilty of adding to that spread of information because it's convenient, but it does impose a bit of a barrier for participation. The idea is that all decisions have to happen on the mailing list, because this is the one place that all Cordova devs are supposed to be subscribed. This is the one place that everyone can watch to keep on top of what's happening in the project. We've been *terrible* at that over the years, and it's made it hard to provide feedback on changes because I didn't know they were happening. Roadmaps were discussed in face-to-face meetings or video calls and not brought back to the list for review, and it was hard to find out what was being worked on short of stumbling upon tasks in JIRA or watching peoples' personal GitHub forks. I don't say that to put blame on anyone, because they were doing what they'd always done and there wasn't (and isn't) a culture of bringing things back to the list. But I do say it because I think we can improve and I think it's worthwhile to try to use the list as the place for discussions so that there's a recorded history of decisions. I know plaintext email doesn't offer nearly as much in the way of formatting, so at the very least it would be good to send a link to proposal documents to the list, and ask for feedback to be posted in that thread. On Tue, Jul 31, 2018 at 10:32 AM Darryl Pogue wrote: Apache Software Foundation projects use mailing lists for communication. It is The Apache Way. See http://apache.org/foundation/how-it-works.html#communication On Tue, Jul 31, 2018 at 10:10 AM Chris Brody wrote: I would really love to see a better discussion forum for ideas. I think the mail list is not so handy for forums with cross-referencing and cordova-discuss proved to be a failure. npm.community seems to have nailed it, though it may have been meant to solve another problem. Any comments? - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Android maintainer lookup to merge cordova-plugin-statusbar PR
Hello, We have PR opened for cordova-plugin-statusbar repo (https://github.com/apache/cordova-plugin-statusbar/pull/99) and we need one of maintainer with enough Android experience to check and merge it. -- Best regards Adam Szmyd - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: Time to mark major Cordova release & remove committed node_modules?
To clarify a few things: By "mark major Cordova release" I meant "mark major Cordova release dev version", such as cordova-ios@5.0.0-dev, cordova-windows@7.0.0-dev, etc. as I had said in a couple other responses. I also confirmed in a couple other responses that I would not make any actual major release yet. I hope I got this clear now, please respond if not. My idea was that "minor" patch releases would be made from existing patch release branches, e.g. 4.5.x for iOS, 6.0.x for Windows, etc. etc. It should be straightforward to cherry-pick anything we need from master as needed moving forward. A possible alternative would be to make new minor release branches based off of master now. But I don't see much benefit of new minor release branches at this point. For the upcoming patches I would rather not include any more changes than necessary. And for subsequent "minor" patch releases I think it would be less "busy work" to continue with the existing patch release branches than make new minor release branches. But I would appreciate feedback if anyone would like to discuss a counterpoint here. Yes I am planning to make a new "minor" CLI patch release with latest cordova-android, cordova-windows, and other platforms pinned, once I publish the remaining platform patches and update other needed tools packages. And it should be no problem to make additional CLI patch releases with more platform "minor" patches if needed. (I think you can start to see it takes so much @#$% time to update, test, review, document, and publish every single patch release.) An additional point is that if someone publishes another cordova-android@7.0.x patch with SDK & plugin problems solved within the next few days I would be happy to include it in the coming CLI patch release. I would appreciate a response if this addresses the concerns or not. On Tue, Jul 31, 2018 at 5:27 PM julio cesar sanchez wrote: > > I think the node deprecation is enough for a major bump, but we should take > this opportunity to make any other needed breaking change. > > But as next major releases will take time, not sure if we could do a last > cli (minor) release with latest Cordova-Android and Cordova-windows pinned. > This will benefit services such as phonegap build that don’t allow to > choose the platform version and use the pinned version instead (and people > who doesn’t know they can install newer versions), which is a blocker for > people using push plugin as it requires Cordova-Android 7.1.0. > > > > > El martes, 31 de julio de 2018, Jan Piotrowski > escribió: > > > So this would e.g. bump cordova-windows master from 6.1.0-dev to > > 7.0.0-dev, so it would be clear that the next release would most > > probably be a major one, correct? > > > > Actual release of that version would only happen if there are enough > > "real" changes that justify a major release anyway, right? > > > > -J > > > > 2018-07-31 22:37 GMT+02:00 : > > > +1 > > > > > > Chris Brody schrieb am Di., 31. Juli 2018, > > 21:23: > > > > > >> Exactly, thanks for the clarification. > > >> On Tue, Jul 31, 2018 at 3:19 PM Darryl Pogue > > wrote: > > >> > > > >> > +1 > > >> > > > >> > Just to be clear, we're proposing to bump to the next major -dev > > >> > version, not actually making any major version releases yet, correct? > > >> > i.e., cordova-ios 4.6.0-dev -> cordova-ios 5.0.0-dev > > >> > > > >> > On Tue, Jul 31, 2018 at 12:14 PM Chris Brody > > >> wrote: > > >> > > > > >> > > Now that we have dropped support for deprecated Node.js 4 in master > > >> > > branch of most repos, I think it is high time to do the following: > > >> > > * mark next major release version in the affected repos > > >> > > * remove committed node_modules from the affected platform repos > > >> > > > > >> > > I would like to request feedback within the next 1-2 days in case of > > >> > > any objections. I would like to proceed with these items within the > > >> > > next week in case there are no major objections. > > >> > > > > >> > > > > - > > >> > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > >> > > For additional commands, e-mail: dev-h...@cordova.apache.org > > >> > > > > >> > > > >> > - > > >> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > >> > For additional commands, e-mail: dev-h...@cordova.apache.org > > >> > > > >> > > >> - > > >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > >> For additional commands, e-mail: dev-h...@cordova.apache.org > > >> > > >> > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > > - To
Re: Time to mark major Cordova release & remove committed node_modules?
I think the node deprecation is enough for a major bump, but we should take this opportunity to make any other needed breaking change. But as next major releases will take time, not sure if we could do a last cli (minor) release with latest Cordova-Android and Cordova-windows pinned. This will benefit services such as phonegap build that don’t allow to choose the platform version and use the pinned version instead (and people who doesn’t know they can install newer versions), which is a blocker for people using push plugin as it requires Cordova-Android 7.1.0. El martes, 31 de julio de 2018, Jan Piotrowski escribió: > So this would e.g. bump cordova-windows master from 6.1.0-dev to > 7.0.0-dev, so it would be clear that the next release would most > probably be a major one, correct? > > Actual release of that version would only happen if there are enough > "real" changes that justify a major release anyway, right? > > -J > > 2018-07-31 22:37 GMT+02:00 : > > +1 > > > > Chris Brody schrieb am Di., 31. Juli 2018, > 21:23: > > > >> Exactly, thanks for the clarification. > >> On Tue, Jul 31, 2018 at 3:19 PM Darryl Pogue > wrote: > >> > > >> > +1 > >> > > >> > Just to be clear, we're proposing to bump to the next major -dev > >> > version, not actually making any major version releases yet, correct? > >> > i.e., cordova-ios 4.6.0-dev -> cordova-ios 5.0.0-dev > >> > > >> > On Tue, Jul 31, 2018 at 12:14 PM Chris Brody > >> wrote: > >> > > > >> > > Now that we have dropped support for deprecated Node.js 4 in master > >> > > branch of most repos, I think it is high time to do the following: > >> > > * mark next major release version in the affected repos > >> > > * remove committed node_modules from the affected platform repos > >> > > > >> > > I would like to request feedback within the next 1-2 days in case of > >> > > any objections. I would like to proceed with these items within the > >> > > next week in case there are no major objections. > >> > > > >> > > > - > >> > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > >> > > For additional commands, e-mail: dev-h...@cordova.apache.org > >> > > > >> > > >> > - > >> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > >> > For additional commands, e-mail: dev-h...@cordova.apache.org > >> > > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > >> For additional commands, e-mail: dev-h...@cordova.apache.org > >> > >> > > - > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > >
Re: Time to mark major Cordova release & remove committed node_modules?
On Tue, Jul 31, 2018 at 5:13 PM Jan Piotrowski wrote: > > So this would e.g. bump cordova-windows master from 6.1.0-dev to > 7.0.0-dev, so it would be clear that the next release would most > probably be a major one, correct? Yes > Actual release of that version would only happen if there are enough > "real" changes that justify a major release anyway, right? Yes - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: Time to mark major Cordova release & remove committed node_modules?
So this would e.g. bump cordova-windows master from 6.1.0-dev to 7.0.0-dev, so it would be clear that the next release would most probably be a major one, correct? Actual release of that version would only happen if there are enough "real" changes that justify a major release anyway, right? -J 2018-07-31 22:37 GMT+02:00 : > +1 > > Chris Brody schrieb am Di., 31. Juli 2018, 21:23: > >> Exactly, thanks for the clarification. >> On Tue, Jul 31, 2018 at 3:19 PM Darryl Pogue wrote: >> > >> > +1 >> > >> > Just to be clear, we're proposing to bump to the next major -dev >> > version, not actually making any major version releases yet, correct? >> > i.e., cordova-ios 4.6.0-dev -> cordova-ios 5.0.0-dev >> > >> > On Tue, Jul 31, 2018 at 12:14 PM Chris Brody >> wrote: >> > > >> > > Now that we have dropped support for deprecated Node.js 4 in master >> > > branch of most repos, I think it is high time to do the following: >> > > * mark next major release version in the affected repos >> > > * remove committed node_modules from the affected platform repos >> > > >> > > I would like to request feedback within the next 1-2 days in case of >> > > any objections. I would like to proceed with these items within the >> > > next week in case there are no major objections. >> > > >> > > - >> > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >> > > For additional commands, e-mail: dev-h...@cordova.apache.org >> > > >> > >> > - >> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >> > For additional commands, e-mail: dev-h...@cordova.apache.org >> > >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >> For additional commands, e-mail: dev-h...@cordova.apache.org >> >> - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: Time to mark major Cordova release & remove committed node_modules?
+1 Chris Brody schrieb am Di., 31. Juli 2018, 21:23: > Exactly, thanks for the clarification. > On Tue, Jul 31, 2018 at 3:19 PM Darryl Pogue wrote: > > > > +1 > > > > Just to be clear, we're proposing to bump to the next major -dev > > version, not actually making any major version releases yet, correct? > > i.e., cordova-ios 4.6.0-dev -> cordova-ios 5.0.0-dev > > > > On Tue, Jul 31, 2018 at 12:14 PM Chris Brody > wrote: > > > > > > Now that we have dropped support for deprecated Node.js 4 in master > > > branch of most repos, I think it is high time to do the following: > > > * mark next major release version in the affected repos > > > * remove committed node_modules from the affected platform repos > > > > > > I would like to request feedback within the next 1-2 days in case of > > > any objections. I would like to proceed with these items within the > > > next week in case there are no major objections. > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > >
Re: Time to mark major Cordova release & remove committed node_modules?
Exactly, thanks for the clarification. On Tue, Jul 31, 2018 at 3:19 PM Darryl Pogue wrote: > > +1 > > Just to be clear, we're proposing to bump to the next major -dev > version, not actually making any major version releases yet, correct? > i.e., cordova-ios 4.6.0-dev -> cordova-ios 5.0.0-dev > > On Tue, Jul 31, 2018 at 12:14 PM Chris Brody wrote: > > > > Now that we have dropped support for deprecated Node.js 4 in master > > branch of most repos, I think it is high time to do the following: > > * mark next major release version in the affected repos > > * remove committed node_modules from the affected platform repos > > > > I would like to request feedback within the next 1-2 days in case of > > any objections. I would like to proceed with these items within the > > next week in case there are no major objections. > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: Time to mark major Cordova release & remove committed node_modules?
+1 Just to be clear, we're proposing to bump to the next major -dev version, not actually making any major version releases yet, correct? i.e., cordova-ios 4.6.0-dev -> cordova-ios 5.0.0-dev On Tue, Jul 31, 2018 at 12:14 PM Chris Brody wrote: > > Now that we have dropped support for deprecated Node.js 4 in master > branch of most repos, I think it is high time to do the following: > * mark next major release version in the affected repos > * remove committed node_modules from the affected platform repos > > I would like to request feedback within the next 1-2 days in case of > any objections. I would like to proceed with these items within the > next week in case there are no major objections. > > - > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Time to mark major Cordova release & remove committed node_modules?
Now that we have dropped support for deprecated Node.js 4 in master branch of most repos, I think it is high time to do the following: * mark next major release version in the affected repos * remove committed node_modules from the affected platform repos I would like to request feedback within the next 1-2 days in case of any objections. I would like to proceed with these items within the next week in case there are no major objections. - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: Better discussion forum?
To expand on this a bit more, annoying as the mailing list might be, I think the project would be better for having a more active mailing list and not having discussions spread across lists and multiple GitHub repos and Slack and JIRA and various Google Docs. I'm definitely guilty of adding to that spread of information because it's convenient, but it does impose a bit of a barrier for participation. The idea is that all decisions have to happen on the mailing list, because this is the one place that all Cordova devs are supposed to be subscribed. This is the one place that everyone can watch to keep on top of what's happening in the project. We've been *terrible* at that over the years, and it's made it hard to provide feedback on changes because I didn't know they were happening. Roadmaps were discussed in face-to-face meetings or video calls and not brought back to the list for review, and it was hard to find out what was being worked on short of stumbling upon tasks in JIRA or watching peoples' personal GitHub forks. I don't say that to put blame on anyone, because they were doing what they'd always done and there wasn't (and isn't) a culture of bringing things back to the list. But I do say it because I think we can improve and I think it's worthwhile to try to use the list as the place for discussions so that there's a recorded history of decisions. I know plaintext email doesn't offer nearly as much in the way of formatting, so at the very least it would be good to send a link to proposal documents to the list, and ask for feedback to be posted in that thread. On Tue, Jul 31, 2018 at 10:32 AM Darryl Pogue wrote: > > Apache Software Foundation projects use mailing lists for communication. > It is The Apache Way. > > See http://apache.org/foundation/how-it-works.html#communication > > On Tue, Jul 31, 2018 at 10:10 AM Chris Brody wrote: > > > > I would really love to see a better discussion forum for ideas. I > > think the mail list is not so handy for forums with cross-referencing > > and cordova-discuss proved to be a failure. npm.community seems to > > have nailed it, though it may have been meant to solve another > > problem. Any comments? > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > For additional commands, e-mail: dev-h...@cordova.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: Better discussion forum?
Apache Software Foundation projects use mailing lists for communication. It is The Apache Way. See http://apache.org/foundation/how-it-works.html#communication On Tue, Jul 31, 2018 at 10:10 AM Chris Brody wrote: > > I would really love to see a better discussion forum for ideas. I > think the mail list is not so handy for forums with cross-referencing > and cordova-discuss proved to be a failure. npm.community seems to > have nailed it, though it may have been meant to solve another > problem. Any comments? > > - > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: Better discussion forum?
It's an Apache thing: > Apache projects use mailing lists to coordinate development of the software > and administration of the organization. Mailing lists also serve as a primary > support channel where users can help each other learn to use the software. https://apache.org/foundation/mailinglists.html 2018-07-31 19:10 GMT+02:00 Chris Brody : > I would really love to see a better discussion forum for ideas. I > think the mail list is not so handy for forums with cross-referencing > and cordova-discuss proved to be a failure. npm.community seems to > have nailed it, though it may have been meant to solve another > problem. Any comments? > > - > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Better discussion forum?
I would really love to see a better discussion forum for ideas. I think the mail list is not so handy for forums with cross-referencing and cordova-discuss proved to be a failure. npm.community seems to have nailed it, though it may have been meant to solve another problem. Any comments? - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: [DISCUSS] [JIRA -> GitHub Issues] The way forward
The npm forum solves a very different problem for npm - they had too much noise in Github issues because of the project's popularity. Too much popularity is not one of Cordova's problems ;) Many uses of cordova-discuss will be able to move to the individual project repositories issues, maybe we can even think about getting rid of it. Good thing to keep in mind after everything is migrated. The mailing list can be used much more to just point people to a specific issue (as I also did in my original mail here) where the actual discussion will happen. -J 2018-07-31 17:39 GMT+02:00 Chris Brody : > +1 (+100) for migrating away from JIRA issues > > npm took a different approach that I am starting to really like: using > npm.community (Discourse) with GitHub login for issues and discussions > > solves another major problem since I don't like mail list for > discussing issues and cordova-discuss has proven to be such an > unpopular repo > On Tue, Jul 31, 2018 at 10:54 AM Jan Piotrowski wrote: >> >> While our repositories are already fully on GitHub [1], our issues >> mainly still live in JIRA. We previously decided this should be >> changed [2] so issues live with code. >> >> We also did some first switches that were pretty successful: >> >> https://github.com/apache/cordova-docs/issues >> https://github.com/apache/cordova-windows/issues >> >> So I suggest we move forward with the rest. Here is a list of stuff to do: >> >> >> a) Enable GitHub issues on all repositories via INFRA ticket >> >> b) Define and update Contributor documentation: >> * Contributor guidelines >> - https://cordova.apache.org/contribute/contribute_guidelines.html >> - https://cordova.apache.org/contribute/ >> - https://cordova.apache.org/contribute/issues.html >> - https://github.com/apache/cordova-coho/search?l=Markdown=JIRA >> => https://github.com/apache/cordova-docs/issues/861 >> * Issue template(s) >> * Pull Request template(s) >> * Github labels / issue triaging documentation >> * Usage of GitHub merge functionality >> * READMEs of all repositories >> * Prepare all these changes as PRs that can merged when a) is taken care >> of. >> >> c) Define and document handling of security issues >> => https://github.com/apache/cordova-docs/issues/860 >> >> d) Define and execute issue migration from JIRA to GitHub >> e) Define and execute "disabling" of JIRA (if applies) >> >> Related: >> - Check if ICLA documentation is correct and fix if necessary >> >> >> Any input or objections? >> >> I expect d) and e) to require some more discussion and planning, but >> think it is ok to just leave this to be done later after everything >> else was taken care of. Agree? >> >> Did I miss any documents for b) that will have to be updated? >> >> >> Best regards, >> Jan >> >> >> PS: >> >> For future reference, the links I collected while researching the >> previous work done and current state: >> >> [1] Move repositories to Github / Gitbox for Apache Cordova: >> https://lists.apache.org/thread.html/af0ec86818674bd1a8c4a9372685a9ae8e6200c478ad8e859606f3a3@%3Cdev.cordova.apache.org%3E >> https://issues.apache.org/jira/browse/INFRA-14347 >> https://issues.apache.org/jira/browse/INFRA-14398 >> https://issues.apache.org/jira/browse/INFRA-14399 >> https://lists.apache.org/thread.html/23e927ad58441685a3fb3bbfe8e4d9f52369afa24e6e57f74b247d17@%3Cdev.cordova.apache.org%3E >> https://issues.apache.org/jira/browse/INFRA-14994 >> https://issues.apache.org/jira/browse/INFRA-14815 >> https://lists.apache.org/thread.html/649d83cd05ae7029327cd4734ca42282426c5564b291257da1b8b75e@%3Cdev.cordova.apache.org%3E >> >> [2] Migrate Jira issues over to Github: >> https://issues.apache.org/jira/browse/CB-13157 >> https://github.com/audreyso/cordova-discuss/blob/6bece4125d389036461e25036e51e0fdfd712567/proposals/GithubMigration.md >> https://github.com/apache/cordova-discuss/pull/75 >> https://lists.apache.org/thread.html/a992eaf62c8475a4576784ca3f9d8acc575220f0c53e6016bc4455e7@%3Cdev.cordova.apache.org%3E >> https://issues.apache.org/jira/browse/INFRA-16503 >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >> For additional commands, e-mail: dev-h...@cordova.apache.org >> > > - > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: [DISCUSS] [JIRA -> GitHub Issues] The way forward
+1 (+100) for migrating away from JIRA issues npm took a different approach that I am starting to really like: using npm.community (Discourse) with GitHub login for issues and discussions solves another major problem since I don't like mail list for discussing issues and cordova-discuss has proven to be such an unpopular repo On Tue, Jul 31, 2018 at 10:54 AM Jan Piotrowski wrote: > > While our repositories are already fully on GitHub [1], our issues > mainly still live in JIRA. We previously decided this should be > changed [2] so issues live with code. > > We also did some first switches that were pretty successful: > > https://github.com/apache/cordova-docs/issues > https://github.com/apache/cordova-windows/issues > > So I suggest we move forward with the rest. Here is a list of stuff to do: > > > a) Enable GitHub issues on all repositories via INFRA ticket > > b) Define and update Contributor documentation: > * Contributor guidelines > - https://cordova.apache.org/contribute/contribute_guidelines.html > - https://cordova.apache.org/contribute/ > - https://cordova.apache.org/contribute/issues.html > - https://github.com/apache/cordova-coho/search?l=Markdown=JIRA > => https://github.com/apache/cordova-docs/issues/861 > * Issue template(s) > * Pull Request template(s) > * Github labels / issue triaging documentation > * Usage of GitHub merge functionality > * READMEs of all repositories > * Prepare all these changes as PRs that can merged when a) is taken care of. > > c) Define and document handling of security issues > => https://github.com/apache/cordova-docs/issues/860 > > d) Define and execute issue migration from JIRA to GitHub > e) Define and execute "disabling" of JIRA (if applies) > > Related: > - Check if ICLA documentation is correct and fix if necessary > > > Any input or objections? > > I expect d) and e) to require some more discussion and planning, but > think it is ok to just leave this to be done later after everything > else was taken care of. Agree? > > Did I miss any documents for b) that will have to be updated? > > > Best regards, > Jan > > > PS: > > For future reference, the links I collected while researching the > previous work done and current state: > > [1] Move repositories to Github / Gitbox for Apache Cordova: > https://lists.apache.org/thread.html/af0ec86818674bd1a8c4a9372685a9ae8e6200c478ad8e859606f3a3@%3Cdev.cordova.apache.org%3E > https://issues.apache.org/jira/browse/INFRA-14347 > https://issues.apache.org/jira/browse/INFRA-14398 > https://issues.apache.org/jira/browse/INFRA-14399 > https://lists.apache.org/thread.html/23e927ad58441685a3fb3bbfe8e4d9f52369afa24e6e57f74b247d17@%3Cdev.cordova.apache.org%3E > https://issues.apache.org/jira/browse/INFRA-14994 > https://issues.apache.org/jira/browse/INFRA-14815 > https://lists.apache.org/thread.html/649d83cd05ae7029327cd4734ca42282426c5564b291257da1b8b75e@%3Cdev.cordova.apache.org%3E > > [2] Migrate Jira issues over to Github: > https://issues.apache.org/jira/browse/CB-13157 > https://github.com/audreyso/cordova-discuss/blob/6bece4125d389036461e25036e51e0fdfd712567/proposals/GithubMigration.md > https://github.com/apache/cordova-discuss/pull/75 > https://lists.apache.org/thread.html/a992eaf62c8475a4576784ca3f9d8acc575220f0c53e6016bc4455e7@%3Cdev.cordova.apache.org%3E > https://issues.apache.org/jira/browse/INFRA-16503 > > - > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
[DISCUSS] [JIRA -> GitHub Issues] The way forward
While our repositories are already fully on GitHub [1], our issues mainly still live in JIRA. We previously decided this should be changed [2] so issues live with code. We also did some first switches that were pretty successful: https://github.com/apache/cordova-docs/issues https://github.com/apache/cordova-windows/issues So I suggest we move forward with the rest. Here is a list of stuff to do: a) Enable GitHub issues on all repositories via INFRA ticket b) Define and update Contributor documentation: * Contributor guidelines - https://cordova.apache.org/contribute/contribute_guidelines.html - https://cordova.apache.org/contribute/ - https://cordova.apache.org/contribute/issues.html - https://github.com/apache/cordova-coho/search?l=Markdown=JIRA => https://github.com/apache/cordova-docs/issues/861 * Issue template(s) * Pull Request template(s) * Github labels / issue triaging documentation * Usage of GitHub merge functionality * READMEs of all repositories * Prepare all these changes as PRs that can merged when a) is taken care of. c) Define and document handling of security issues => https://github.com/apache/cordova-docs/issues/860 d) Define and execute issue migration from JIRA to GitHub e) Define and execute "disabling" of JIRA (if applies) Related: - Check if ICLA documentation is correct and fix if necessary Any input or objections? I expect d) and e) to require some more discussion and planning, but think it is ok to just leave this to be done later after everything else was taken care of. Agree? Did I miss any documents for b) that will have to be updated? Best regards, Jan PS: For future reference, the links I collected while researching the previous work done and current state: [1] Move repositories to Github / Gitbox for Apache Cordova: https://lists.apache.org/thread.html/af0ec86818674bd1a8c4a9372685a9ae8e6200c478ad8e859606f3a3@%3Cdev.cordova.apache.org%3E https://issues.apache.org/jira/browse/INFRA-14347 https://issues.apache.org/jira/browse/INFRA-14398 https://issues.apache.org/jira/browse/INFRA-14399 https://lists.apache.org/thread.html/23e927ad58441685a3fb3bbfe8e4d9f52369afa24e6e57f74b247d17@%3Cdev.cordova.apache.org%3E https://issues.apache.org/jira/browse/INFRA-14994 https://issues.apache.org/jira/browse/INFRA-14815 https://lists.apache.org/thread.html/649d83cd05ae7029327cd4734ca42282426c5564b291257da1b8b75e@%3Cdev.cordova.apache.org%3E [2] Migrate Jira issues over to Github: https://issues.apache.org/jira/browse/CB-13157 https://github.com/audreyso/cordova-discuss/blob/6bece4125d389036461e25036e51e0fdfd712567/proposals/GithubMigration.md https://github.com/apache/cordova-discuss/pull/75 https://lists.apache.org/thread.html/a992eaf62c8475a4576784ca3f9d8acc575220f0c53e6016bc4455e7@%3Cdev.cordova.apache.org%3E https://issues.apache.org/jira/browse/INFRA-16503 - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
