Re: minor bump to cordova-lib
first what? A hotfix On Jun 9, 2014 6:33 PM, "Andrew Grieve" wrote: > Marvin's email came across to me as respectful. > Brian and Joe - your responses came across as disrespectful to me. Slow > claps and sarcasm should probably be avoided in email. > > This issue has been covered at length, and the a very clear conclusion was > made that unless policies change, anything published to npm that is > intended for users outside of the project must first land on dist/. > > > On Mon, Jun 9, 2014 at 6:38 PM, Brian LeRoux wrote: > > > Blind copy paste of URLs and blanket repeat emails are not helping > either. > > We can and do VOTE on artifacts. > > > > (And, FTR, I'm perfectly fine with the ceremony but I'd prefer we cast > > votes as tags like we used to. A topic for the board and members to > debate > > to be sure.) > > > > Your earlier emails demonstrate well how little you understand of the > > project. I'd recommend *actually* building Cordova *then* providing > advice > > about how to improve it and our release process. Seriously: it would > help. > > On Mon, Jun 9, 2014 at 2:18 PM, Brian LeRoux wrote: > > > /me slow clap > > > > Brian, I realize that you are deeply opposed to voting on releases, and I > > understand and respect your arguments. Were Cordova an independent > > project, I > > would not come to the community proposing that release voting be adopted. > > > > However, Cordova is at Apache and the policies are what they are. You're > > welcome to make the case that the org should change, but to be honest I > > doubt > > such a change is achievable in the near term. The policy has deep roots > -- > > a > > good chunk of the Foundation's legal structure is built in its service. > > And > > so I would argue that avoiding quixotic conflicts with the Board is in > the > > best interest of most Cordova stakeholders. > > > > In the meantime, the question is how to make the best of things within > > existing constraints. For the record, there's nothing stopping Cordova > > from releasing on a fixed cadence. > > > > Marvin Humphrey > > >
Re: minor bump to cordova-lib
Marvin's email came across to me as respectful. Brian and Joe - your responses came across as disrespectful to me. Slow claps and sarcasm should probably be avoided in email. This issue has been covered at length, and the a very clear conclusion was made that unless policies change, anything published to npm that is intended for users outside of the project must first land on dist/. On Mon, Jun 9, 2014 at 6:38 PM, Brian LeRoux wrote: > Blind copy paste of URLs and blanket repeat emails are not helping either. > We can and do VOTE on artifacts. > > (And, FTR, I'm perfectly fine with the ceremony but I'd prefer we cast > votes as tags like we used to. A topic for the board and members to debate > to be sure.) > > Your earlier emails demonstrate well how little you understand of the > project. I'd recommend *actually* building Cordova *then* providing advice > about how to improve it and our release process. Seriously: it would help. > On Mon, Jun 9, 2014 at 2:18 PM, Brian LeRoux wrote: > > /me slow clap > > Brian, I realize that you are deeply opposed to voting on releases, and I > understand and respect your arguments. Were Cordova an independent > project, I > would not come to the community proposing that release voting be adopted. > > However, Cordova is at Apache and the policies are what they are. You're > welcome to make the case that the org should change, but to be honest I > doubt > such a change is achievable in the near term. The policy has deep roots -- > a > good chunk of the Foundation's legal structure is built in its service. > And > so I would argue that avoiding quixotic conflicts with the Board is in the > best interest of most Cordova stakeholders. > > In the meantime, the question is how to make the best of things within > existing constraints. For the record, there's nothing stopping Cordova > from releasing on a fixed cadence. > > Marvin Humphrey >
Re: minor bump to cordova-lib
Blind copy paste of URLs and blanket repeat emails are not helping either. We can and do VOTE on artifacts. (And, FTR, I'm perfectly fine with the ceremony but I'd prefer we cast votes as tags like we used to. A topic for the board and members to debate to be sure.) Your earlier emails demonstrate well how little you understand of the project. I'd recommend *actually* building Cordova *then* providing advice about how to improve it and our release process. Seriously: it would help. On Mon, Jun 9, 2014 at 2:18 PM, Brian LeRoux wrote: > /me slow clap Brian, I realize that you are deeply opposed to voting on releases, and I understand and respect your arguments. Were Cordova an independent project, I would not come to the community proposing that release voting be adopted. However, Cordova is at Apache and the policies are what they are. You're welcome to make the case that the org should change, but to be honest I doubt such a change is achievable in the near term. The policy has deep roots -- a good chunk of the Foundation's legal structure is built in its service. And so I would argue that avoiding quixotic conflicts with the Board is in the best interest of most Cordova stakeholders. In the meantime, the question is how to make the best of things within existing constraints. For the record, there's nothing stopping Cordova from releasing on a fixed cadence. Marvin Humphrey
Re: minor bump to cordova-lib
On Mon, Jun 9, 2014 at 2:18 PM, Brian LeRoux wrote: > /me slow clap Brian, I realize that you are deeply opposed to voting on releases, and I understand and respect your arguments. Were Cordova an independent project, I would not come to the community proposing that release voting be adopted. However, Cordova is at Apache and the policies are what they are. You're welcome to make the case that the org should change, but to be honest I doubt such a change is achievable in the near term. The policy has deep roots -- a good chunk of the Foundation's legal structure is built in its service. And so I would argue that avoiding quixotic conflicts with the Board is in the best interest of most Cordova stakeholders. In the meantime, the question is how to make the best of things within existing constraints. For the record, there's nothing stopping Cordova from releasing on a fixed cadence. Marvin Humphrey
Re: minor bump to cordova-lib
And this is why we rarely release anything anymore. On Mon, Jun 9, 2014 at 2:18 PM, Brian LeRoux wrote: > /me slow clap > > > On Mon, Jun 9, 2014 at 1:57 PM, Marvin Humphrey > wrote: > >> On Mon, Jun 9, 2014 at 1:35 PM, Brian LeRoux wrote: >> > My understanding is that a VOTE was for ./dist and that anything npm is >> the >> > domain of the person publishing. >> >> Here's the policy: >> >> http://www.apache.org/dev/release#what >> >> What Is A Release? >> >> Releases are, by definition, anything that is published beyond the group >> that owns it. In our case, that means any publication outside the group >> of >> people on the product dev list. If the general public is being >> instructed to >> download a package, then that package has been released. Each PMC must >> obey >> the ASF requirements on approving any release. [...] >> >> So it's not that packages published to npm (or any other downstream >> distribution channel) don't require a VOTE, it's that npm packages should >> also >> be published to dist (and require a VOTE). >> >> Marvin Humphrey >>
Re: minor bump to cordova-lib
/me slow clap On Mon, Jun 9, 2014 at 1:57 PM, Marvin Humphrey wrote: > On Mon, Jun 9, 2014 at 1:35 PM, Brian LeRoux wrote: > > My understanding is that a VOTE was for ./dist and that anything npm is > the > > domain of the person publishing. > > Here's the policy: > > http://www.apache.org/dev/release#what > > What Is A Release? > > Releases are, by definition, anything that is published beyond the group > that owns it. In our case, that means any publication outside the group > of > people on the product dev list. If the general public is being > instructed to > download a package, then that package has been released. Each PMC must > obey > the ASF requirements on approving any release. [...] > > So it's not that packages published to npm (or any other downstream > distribution channel) don't require a VOTE, it's that npm packages should > also > be published to dist (and require a VOTE). > > Marvin Humphrey >
Re: minor bump to cordova-lib
On Mon, Jun 9, 2014 at 1:35 PM, Brian LeRoux wrote: > My understanding is that a VOTE was for ./dist and that anything npm is the > domain of the person publishing. Here's the policy: http://www.apache.org/dev/release#what What Is A Release? Releases are, by definition, anything that is published beyond the group that owns it. In our case, that means any publication outside the group of people on the product dev list. If the general public is being instructed to download a package, then that package has been released. Each PMC must obey the ASF requirements on approving any release. [...] So it's not that packages published to npm (or any other downstream distribution channel) don't require a VOTE, it's that npm packages should also be published to dist (and require a VOTE). Marvin Humphrey
Re: minor bump to cordova-lib
My understanding is that a VOTE was for ./dist and that anything npm is the domain of the person publishing. On Mon, Jun 9, 2014 at 1:27 PM, Steven Gill wrote: > Going to have to do a vote to release to npm. > > > On Mon, Jun 9, 2014 at 1:22 PM, Lorin Beer wrote: > > > good. lord. > > > > On Mon, Jun 9, 2014 at 1:04 PM, Michal Mocny > wrote: > > > We all wish! > > > > > > > > > On Mon, Jun 9, 2014 at 4:00 PM, Lorin Beer > wrote: > > > > > >> Michal: the root package.json is being removed. I do want to perform > > >> an npm publish with a patch version increment, so downstream projects > > >> can reference include by npm registry and not git url. That would > > >> constitute a 'release' of some sort. My understanding was that bug > > >> patches of this sort could be pushed out with minimum fuss. > > >> > > >> > > >> On Mon, Jun 9, 2014 at 12:56 PM, Michal Mocny > > wrote: > > >> > In particular, I thought the root of the repo wasn't supposed to be > a > > >> node > > >> > package, but a bucket for multiple node packages. (ie, should not > be > > a > > >> > package.json at the root). > > >> > > > >> > We don't vote on commits (though its nice to ask for review for big > > hairy > > >> > patches like this one, so thanks for that). > > >> > > > >> > -Michal > > >> > > > >> > > > >> > On Mon, Jun 9, 2014 at 3:01 PM, Andrew Grieve > > > >> wrote: > > >> > > > >> >> I think all releases require votes. Only difference is that for > > urgent > > >> >> releases we can have a shorter vote period. > > >> >> > > >> >> Looking at your commit - there's now two package.json files with > the > > >> same > > >> >> name. I don't think that's allowed by npm. > > >> >> > > >> >> Your goal was to make configparser its own package right? Doesn't > it > > >> need > > >> >> its own package.json file to be its own package? > > >> >> > > >> >> > > >> >> On Mon, Jun 9, 2014 at 2:50 PM, Lorin Beer > > >> wrote: > > >> >> > > >> >> > Minor bump to cordova-lib to expose a broken out package. > > >> >> > > > >> >> > history: > > >> >> > > > >> >> > > >> > > > https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=shortlog;h=refs/heads/configparser_module > > >> >> > > > >> >> > squashed commit to master: > > >> >> > > > >> >> > > > >> >> > > >> > > > https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=commit;h=3623a84eb391f41c5a32ddc67eea89512c4ba654 > > >> >> > > > >> >> > > > >> >> > This does not change any functionality of the modules, just the > way > > >> >> > they are wired up. It also provides an additional package.json > > file to > > >> >> > better expose the cordova-lib submodules. > > >> >> > > > >> >> > > > >> >> > I think that qualifies as a patch, and should not require a > release > > >> vote. > > >> >> > > > >> >> > I will hold off on npm publish for some feedback > > >> >> > > > >> >> > - Lorin > > >> >> > > > >> >> > > >> > > >
Re: minor bump to cordova-lib
Going to have to do a vote to release to npm. On Mon, Jun 9, 2014 at 1:22 PM, Lorin Beer wrote: > good. lord. > > On Mon, Jun 9, 2014 at 1:04 PM, Michal Mocny wrote: > > We all wish! > > > > > > On Mon, Jun 9, 2014 at 4:00 PM, Lorin Beer wrote: > > > >> Michal: the root package.json is being removed. I do want to perform > >> an npm publish with a patch version increment, so downstream projects > >> can reference include by npm registry and not git url. That would > >> constitute a 'release' of some sort. My understanding was that bug > >> patches of this sort could be pushed out with minimum fuss. > >> > >> > >> On Mon, Jun 9, 2014 at 12:56 PM, Michal Mocny > wrote: > >> > In particular, I thought the root of the repo wasn't supposed to be a > >> node > >> > package, but a bucket for multiple node packages. (ie, should not be > a > >> > package.json at the root). > >> > > >> > We don't vote on commits (though its nice to ask for review for big > hairy > >> > patches like this one, so thanks for that). > >> > > >> > -Michal > >> > > >> > > >> > On Mon, Jun 9, 2014 at 3:01 PM, Andrew Grieve > >> wrote: > >> > > >> >> I think all releases require votes. Only difference is that for > urgent > >> >> releases we can have a shorter vote period. > >> >> > >> >> Looking at your commit - there's now two package.json files with the > >> same > >> >> name. I don't think that's allowed by npm. > >> >> > >> >> Your goal was to make configparser its own package right? Doesn't it > >> need > >> >> its own package.json file to be its own package? > >> >> > >> >> > >> >> On Mon, Jun 9, 2014 at 2:50 PM, Lorin Beer > >> wrote: > >> >> > >> >> > Minor bump to cordova-lib to expose a broken out package. > >> >> > > >> >> > history: > >> >> > > >> >> > >> > https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=shortlog;h=refs/heads/configparser_module > >> >> > > >> >> > squashed commit to master: > >> >> > > >> >> > > >> >> > >> > https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=commit;h=3623a84eb391f41c5a32ddc67eea89512c4ba654 > >> >> > > >> >> > > >> >> > This does not change any functionality of the modules, just the way > >> >> > they are wired up. It also provides an additional package.json > file to > >> >> > better expose the cordova-lib submodules. > >> >> > > >> >> > > >> >> > I think that qualifies as a patch, and should not require a release > >> vote. > >> >> > > >> >> > I will hold off on npm publish for some feedback > >> >> > > >> >> > - Lorin > >> >> > > >> >> > >> >
Re: minor bump to cordova-lib
good. lord. On Mon, Jun 9, 2014 at 1:04 PM, Michal Mocny wrote: > We all wish! > > > On Mon, Jun 9, 2014 at 4:00 PM, Lorin Beer wrote: > >> Michal: the root package.json is being removed. I do want to perform >> an npm publish with a patch version increment, so downstream projects >> can reference include by npm registry and not git url. That would >> constitute a 'release' of some sort. My understanding was that bug >> patches of this sort could be pushed out with minimum fuss. >> >> >> On Mon, Jun 9, 2014 at 12:56 PM, Michal Mocny wrote: >> > In particular, I thought the root of the repo wasn't supposed to be a >> node >> > package, but a bucket for multiple node packages. (ie, should not be a >> > package.json at the root). >> > >> > We don't vote on commits (though its nice to ask for review for big hairy >> > patches like this one, so thanks for that). >> > >> > -Michal >> > >> > >> > On Mon, Jun 9, 2014 at 3:01 PM, Andrew Grieve >> wrote: >> > >> >> I think all releases require votes. Only difference is that for urgent >> >> releases we can have a shorter vote period. >> >> >> >> Looking at your commit - there's now two package.json files with the >> same >> >> name. I don't think that's allowed by npm. >> >> >> >> Your goal was to make configparser its own package right? Doesn't it >> need >> >> its own package.json file to be its own package? >> >> >> >> >> >> On Mon, Jun 9, 2014 at 2:50 PM, Lorin Beer >> wrote: >> >> >> >> > Minor bump to cordova-lib to expose a broken out package. >> >> > >> >> > history: >> >> > >> >> >> https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=shortlog;h=refs/heads/configparser_module >> >> > >> >> > squashed commit to master: >> >> > >> >> > >> >> >> https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=commit;h=3623a84eb391f41c5a32ddc67eea89512c4ba654 >> >> > >> >> > >> >> > This does not change any functionality of the modules, just the way >> >> > they are wired up. It also provides an additional package.json file to >> >> > better expose the cordova-lib submodules. >> >> > >> >> > >> >> > I think that qualifies as a patch, and should not require a release >> vote. >> >> > >> >> > I will hold off on npm publish for some feedback >> >> > >> >> > - Lorin >> >> > >> >> >>
Re: minor bump to cordova-lib
We all wish! On Mon, Jun 9, 2014 at 4:00 PM, Lorin Beer wrote: > Michal: the root package.json is being removed. I do want to perform > an npm publish with a patch version increment, so downstream projects > can reference include by npm registry and not git url. That would > constitute a 'release' of some sort. My understanding was that bug > patches of this sort could be pushed out with minimum fuss. > > > On Mon, Jun 9, 2014 at 12:56 PM, Michal Mocny wrote: > > In particular, I thought the root of the repo wasn't supposed to be a > node > > package, but a bucket for multiple node packages. (ie, should not be a > > package.json at the root). > > > > We don't vote on commits (though its nice to ask for review for big hairy > > patches like this one, so thanks for that). > > > > -Michal > > > > > > On Mon, Jun 9, 2014 at 3:01 PM, Andrew Grieve > wrote: > > > >> I think all releases require votes. Only difference is that for urgent > >> releases we can have a shorter vote period. > >> > >> Looking at your commit - there's now two package.json files with the > same > >> name. I don't think that's allowed by npm. > >> > >> Your goal was to make configparser its own package right? Doesn't it > need > >> its own package.json file to be its own package? > >> > >> > >> On Mon, Jun 9, 2014 at 2:50 PM, Lorin Beer > wrote: > >> > >> > Minor bump to cordova-lib to expose a broken out package. > >> > > >> > history: > >> > > >> > https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=shortlog;h=refs/heads/configparser_module > >> > > >> > squashed commit to master: > >> > > >> > > >> > https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=commit;h=3623a84eb391f41c5a32ddc67eea89512c4ba654 > >> > > >> > > >> > This does not change any functionality of the modules, just the way > >> > they are wired up. It also provides an additional package.json file to > >> > better expose the cordova-lib submodules. > >> > > >> > > >> > I think that qualifies as a patch, and should not require a release > vote. > >> > > >> > I will hold off on npm publish for some feedback > >> > > >> > - Lorin > >> > > >> >
Re: minor bump to cordova-lib
Michal: the root package.json is being removed. I do want to perform an npm publish with a patch version increment, so downstream projects can reference include by npm registry and not git url. That would constitute a 'release' of some sort. My understanding was that bug patches of this sort could be pushed out with minimum fuss. On Mon, Jun 9, 2014 at 12:56 PM, Michal Mocny wrote: > In particular, I thought the root of the repo wasn't supposed to be a node > package, but a bucket for multiple node packages. (ie, should not be a > package.json at the root). > > We don't vote on commits (though its nice to ask for review for big hairy > patches like this one, so thanks for that). > > -Michal > > > On Mon, Jun 9, 2014 at 3:01 PM, Andrew Grieve wrote: > >> I think all releases require votes. Only difference is that for urgent >> releases we can have a shorter vote period. >> >> Looking at your commit - there's now two package.json files with the same >> name. I don't think that's allowed by npm. >> >> Your goal was to make configparser its own package right? Doesn't it need >> its own package.json file to be its own package? >> >> >> On Mon, Jun 9, 2014 at 2:50 PM, Lorin Beer wrote: >> >> > Minor bump to cordova-lib to expose a broken out package. >> > >> > history: >> > >> https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=shortlog;h=refs/heads/configparser_module >> > >> > squashed commit to master: >> > >> > >> https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=commit;h=3623a84eb391f41c5a32ddc67eea89512c4ba654 >> > >> > >> > This does not change any functionality of the modules, just the way >> > they are wired up. It also provides an additional package.json file to >> > better expose the cordova-lib submodules. >> > >> > >> > I think that qualifies as a patch, and should not require a release vote. >> > >> > I will hold off on npm publish for some feedback >> > >> > - Lorin >> > >>
Re: minor bump to cordova-lib
In particular, I thought the root of the repo wasn't supposed to be a node package, but a bucket for multiple node packages. (ie, should not be a package.json at the root). We don't vote on commits (though its nice to ask for review for big hairy patches like this one, so thanks for that). -Michal On Mon, Jun 9, 2014 at 3:01 PM, Andrew Grieve wrote: > I think all releases require votes. Only difference is that for urgent > releases we can have a shorter vote period. > > Looking at your commit - there's now two package.json files with the same > name. I don't think that's allowed by npm. > > Your goal was to make configparser its own package right? Doesn't it need > its own package.json file to be its own package? > > > On Mon, Jun 9, 2014 at 2:50 PM, Lorin Beer wrote: > > > Minor bump to cordova-lib to expose a broken out package. > > > > history: > > > https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=shortlog;h=refs/heads/configparser_module > > > > squashed commit to master: > > > > > https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=commit;h=3623a84eb391f41c5a32ddc67eea89512c4ba654 > > > > > > This does not change any functionality of the modules, just the way > > they are wired up. It also provides an additional package.json file to > > better expose the cordova-lib submodules. > > > > > > I think that qualifies as a patch, and should not require a release vote. > > > > I will hold off on npm publish for some feedback > > > > - Lorin > > >
Re: minor bump to cordova-lib
looking into the duplicate package.json issue thanks for catching the package.json issue, the duplicate is a mistaken inclusion the end goal is that configparser is it's own package, yes. Included the wrong package.json file On Mon, Jun 9, 2014 at 12:01 PM, Andrew Grieve wrote: > I think all releases require votes. Only difference is that for urgent > releases we can have a shorter vote period. > > Looking at your commit - there's now two package.json files with the same > name. I don't think that's allowed by npm. > > Your goal was to make configparser its own package right? Doesn't it need > its own package.json file to be its own package? > > > On Mon, Jun 9, 2014 at 2:50 PM, Lorin Beer wrote: > >> Minor bump to cordova-lib to expose a broken out package. >> >> history: >> https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=shortlog;h=refs/heads/configparser_module >> >> squashed commit to master: >> >> https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=commit;h=3623a84eb391f41c5a32ddc67eea89512c4ba654 >> >> >> This does not change any functionality of the modules, just the way >> they are wired up. It also provides an additional package.json file to >> better expose the cordova-lib submodules. >> >> >> I think that qualifies as a patch, and should not require a release vote. >> >> I will hold off on npm publish for some feedback >> >> - Lorin >>
Re: minor bump to cordova-lib
I think all releases require votes. Only difference is that for urgent releases we can have a shorter vote period. Looking at your commit - there's now two package.json files with the same name. I don't think that's allowed by npm. Your goal was to make configparser its own package right? Doesn't it need its own package.json file to be its own package? On Mon, Jun 9, 2014 at 2:50 PM, Lorin Beer wrote: > Minor bump to cordova-lib to expose a broken out package. > > history: > https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=shortlog;h=refs/heads/configparser_module > > squashed commit to master: > > https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=commit;h=3623a84eb391f41c5a32ddc67eea89512c4ba654 > > > This does not change any functionality of the modules, just the way > they are wired up. It also provides an additional package.json file to > better expose the cordova-lib submodules. > > > I think that qualifies as a patch, and should not require a release vote. > > I will hold off on npm publish for some feedback > > - Lorin >
minor bump to cordova-lib
Minor bump to cordova-lib to expose a broken out package. history: https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=shortlog;h=refs/heads/configparser_module squashed commit to master: https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;a=commit;h=3623a84eb391f41c5a32ddc67eea89512c4ba654 This does not change any functionality of the modules, just the way they are wired up. It also provides an additional package.json file to better expose the cordova-lib submodules. I think that qualifies as a patch, and should not require a release vote. I will hold off on npm publish for some feedback - Lorin