Move to electron-builder

[develar]

Would you like to move it to electron-builder repo, under directory examples?

[develar]

But... separate repo is better because in this case it can be easily cloned.

[develar]

@iffy I suggest to transfer repo to electron-userland org, so, it will be easily discoverable and under the same org for consistency and "official" status.

@stefanjudis please allow transfer request when will be requested (I am member of org and not owner and have to ask you). @malept please do not block as always ;)

[malept]

I'm not going to block it as long as it's clear that there's a maintainer for the repo. The Electron Userland org is not meant to be a dumping ground for related repositories.

[iffy]

@develar would you be maintaining it? I'm happy to have you maintain it and happy to have it live in the userland org.

[develar]

@iffy it will be part of docs and, so, somehow maintained.

[iffy]

@develar k, here it comes! :)

[iffy]

@develar I don't have permission to send it, so do you need to request it?

[develar]

@stefanjudis I cannot invite @iffy to electron-builder org as a member, because I am not an owner. Could you please invite?

[stefanjudis]

You mean electron-userland org? (by the way can we ask for proper rights for you at some point? :D )

[develar]

@stefanjudis Yes, I mean electron-userland.

by the way can we ask for proper rights for you at some point?

Yeah... I am the only member who doesn't have owner rights :)

[stefanjudis]

Haha, ja let's try to change that. :D

@malept would it be alright, when I'd give @develar owner rights?

I mean, I'm not actively developing electron-builder anymore (and have owner rights) and @develar does an amazing job with the project. The flow right now is, that he always has to ask me to add/configure/... something, which is not really comfortable for us.

What do you think of that?

[develar]

@malept Friendly ping :)

[malept]

I'll write a reply this weekend.

[iffy]

@develar btw, I'm fine if you want to create a new repo electron-userland/electron-updater-example that's not a GitHub copy of this repo, but just a git copy (i.e. clone this repo, create electron-userland/electron-updater-example, push).

Let me know when you do and I'll delete this repo.

[develar]

@stefanjudis I think you can give owner rights. In any case right now I can push to any repo. If someone will be against — team can be created to restrict my access level. Since all members currently are owners — I don't see any security risks or policy violation.

[malept]

@develar Sorry about not writing the response this weekend, I was busy.

I have been hesitant to give admin rights for a couple of reasons:

1. Adding org-level permissions to services - in the case of the most recent ask, I have no idea what the implications of adding OpenCollective is, what permissions they're looking for, or what they can access. I looked for a couple minutes on their website and didn't find anything. I would expect that an ask for this includes exactly what data it's trying to read/use.
2. Lately, I've been wondering what the point of having electron-builder be in the electron-userland org is these days. Just yesterday I was helping someone out and they were confused that electron-builder does not use Electron Packager at all, and that "the same people" were not working on it. I just took a look at builder's package.json and there are currently zero Electron tool dependencies that come from upstream - they are all forked. This is obviously your right to do so - this is open source, after all - but if you're asking to have elevated permissions in the org, I feel like you should figure out how to work with the community to unfork, or at least provide a list of differences between upstream and your fork so users can make informed decisions about the tools that they use and their dependencies.

[develar]

@malept The only useful electron tools for electron-builder are electron-osx-sign and electron-download. And tools are used (and I am contributing to both projects, e.g. https://github.com/electron-userland/electron-download/pull/40 and see my name in the https://github.com/electron-userland/electron-osx-sign#collaborators). Other modules (except electron-packager) are not related to build electron app. So, I don't understand your question.

Also, Electron Userland is not only for you and electron-packager — this org for "Third party community maintained electron modules". And electron-builder currently has 70 contributors vs 50 (electron-packager). So, you cannot blame me that electron-builder maintained only by me.

Adding org-level permissions to services

As far I see it was clear in the request (read-only access was requested to usernames).

[malept]

@develar I never said anything about number of contributors. Nor did I say that the org is only for Electron Packager. Please do not put words in my mouth.

You might be sometimes contributing to upstream, but the pattern that I and several other Electron community members have been seeing is the following:

1. You contribute a PR to a module. Sometimes it gets merged, sometimes it doesn't.
2. For whatever reason, you decide to use your own fork of the module.
3. In some cases, you decide to completely rewrite the feature for electron-builder and drop the forked module.

As I've stated earlier, this is absolutely fine from a technical perspective, because this is open source. However, from a community perspective, it causes animosity. It would make me and other contributors more comfortable if you explained why you're using forks and/or deciding that community modules aren't the right fit for builder.

[develar]

why you're using forks and/or deciding that community modules aren't the right fit for builder.

that community modules aren't the right fit for builder.

The only not used tool is electron-packager. Not "modules", but "module". And is not used because electron-builder version has a lot of features. Implementing it as part of electron-packager will be not easy because it will be total rewrite. It will took a lot of time to argue you to use promise/babel or typescript. Wasting time. Since in any case I don't need to fix something, but implement it from a scratch, it was much more easy just implement it as part of electron-builder. Because it doesn't matter for end user. User just want to build electron app.

[malept]

I care less about Packager and more about the forks of asar, electron-osx-sign, and electron-download. This is not about ego, this is about maintaining a healthy community ecosystem.

Is this really just about the code architecture of all of these modules?

[anaisbetts]

You might be sometimes contributing to upstream, but the pattern that I and several other Electron community members have been seeing is the following:

To be honest, this resonates with me quite strongly as the Squirrel.Windows maintainer. Thanks for writing this up @malept and I appreciate your professionalism in this Hard Conversation.

This behavior is also unfortunate because I am now on the receiving end for bug reports - users don't know that they're using a fork of Squirrel.Windows, and so they report issues to me. Later, after a back-and-forth, they finally casually mention, "Oh, I'm using electron-builder". If the fork wasn't there, we would be working together on fixing bugs instead of doing 2x the work.

[develar]

electron-osx-sign

https://github.com/electron-userland/electron-osx-sign/issues/125#issuecomment-273500629

All changes were merged currently (except one internal option specially for electron-builder). I often contribute to electron-osx-sign and is not easy to change module id. Also, I need to test my PR on beta users (next tag) and CI servers.

asar

Nothing changed except removing deprecated dependency (https://github.com/electron/asar/pull/61). Again — sometimes I need to change something urgently and is not easy to change module id — e.g. https://github.com/electron/asar/issues/78.

electron-download

was forked as result of https://github.com/electron-userland/electron-download/pull/40 Again — don't want to change module id since I soon will send PR to download temp files to a cache directory instead of temp.

As of electron-winstaller — @paulcbetts is aware why (PR was rejected and discussed) and also aware that all common fixes were merged into Squirrel.Windows https://github.com/Squirrel/Squirrel.Windows/pulls?utf8=✓&q=is%3Apr%20is%3Aclosed%20author%3Adevelar

[develar]

@paulcbetts I am not aware of any bugs that was caused due to my fork. If you mean semver issue — it was not a bug in my fork, it was result of rcedit call (file version, not in the Squirrel.Windows code). Also, in any case it was caused by Squirrel.Windows runtime (not changed in my fork).

Later, after a back-and-forth, they finally casually mention, "Oh, I'm using electron-builder". If the fork wasn't there, we would be working together on fixing bugs instead of doing 2x the work.

All bugs (I know only about one (and it is not electron-builder fork bug) —https://github.com/electron-userland/electron-builder/issues/1101), as far I know, in the runtime. And runtime is the same. if you have examples — please provide.

[develar]

@malept Ping.

[develar]

@stefanjudis Could you please just add @iffy as a member to electron-userland org?

[malept]

@develar I have a proposal:

The electron-userland org was never meant as a dumping ground for Electron-related projects. Originally it was just a bunch of self-contained tools/modules for Electron projects maintained by a couple of people. Now it's gotten to be a bit more than that. Electron Forge is moving out of the electron-userland org and into its own, partly because there's too much resource contention, particularly with Travis CI workers. (Each open source org/user gets 5 (or less depending on availability) workers in parallel.) This is particularly problematic when there are multiple Electron Packager PRs being worked on. (I'm trying to speed up the tests but this is offtopic.) Additionally, there are currently three repositories for Forge and a fourth on the way, so it makes a whole lot more sense. This also allows us to split up our -templates monorepo so we can better release and manage issues.

This is a long-winded way to say that my suggestion is to create an electron-builder org and move the repos there.

[develar]

@malept Thanks for info. BTW, we have managed to run all electron-builder tests in 8 minutes using CircleCI (run across all 4 workers, Travis runs only macOS tests (10 minutes)).

electron-builder uses monorepo, as babel, so, I would stay in the electorn-userland org.

[stefanjudis]

Then let's do this? @develar

[develar]

Then let's do this

Move to electron-builder org? I don't like it and prefer to stay in the electorn-userland org.

• electron-builder uses monorepo, as babel, packages will be not converted to repositories.
• electron-updater is not tight to electron-builder and can be used standalone.
• Org description "Third party community maintained electron modules" doesn't contradicts to current situation.

[develar]

• electron-osx-sign is also part of electron-buider (and in the same time part of any other build tool for electron). Don't like the idea to create org per tool.