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. electron/get#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

electron/osx-sign#125 (comment)

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 (electron/asar#61). Again — sometimes I need to change something urgently and is not easy to change module id — e.g. electron/asar#78.

electron-download

was forked as result of electron/get#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) —electron-userland/electron-builder#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.

[MarshallOfSound]

@develar I'd like to reiterate what @malept said I definitely feel it's better for everyone to separate concerns. The -builder and -forge ecosystems have both outgrown the CI limits imposed on -userland, regardless of how fast everyone's CI runs it is normally in the range of 10+ minutes on each agent, with the limits imposed on us this means that if everyone wants the agents you can be waiting hours or sometimes even till the next day for builds (depending on branches / third party PR's and everything). This is especially bad on the macOS travis queue.

The best move for everyone is to make -userland a collection of smaller projects once again (prebuilt, download, spellchecker, remote, etc.) and it should remain the original home of -packager (let's be real everything was built around it). And to move -forge to it's own organization and -builder to it's own organization as well.

This will show separation of concerns, stop -userland being a dumping ground for everything. Remove the need for mono-repoing on both fronts (forge and builder) and allow us all to make our own administrative decisions regarding what should and shouldn't be in or enabled for our given organization.

At the moment we are each trying to act as an independent group inside the -userland group and I think that's a strong indicator that we both have to take our concerns to our own org where we each have control. E.g. You work on the -builder things and we work on -packager/-forge/-download/-prebuilt things.

As a further point although the description of the org "third party community maintained modules" still fits -builder and everything else in this org it doesn't mean all third party maintained modules should live here.

The main points here are separation of concerns, CI agent consumption and ensuring that -userland doesn't become a "dumping ground".

I hope this makes sense :D

[develar]

the CI limits imposed on -userland

I don't think that this Travis limitation should be the main reason to create org per tool :) Maybe you can contact CircleCi to run macOS tests.

Remove the need for mono-repoing on both fronts

I like monorepo and not going to split electron-builder to repo-hell. I don't like idea to create org for 2 repositories (electron-updater can be used standalone).

E.g. You work on the -builder things and we work on -packager/-forge/-download/-prebuilt things.

I contribute not only to electron-builder, electron/get#47

doesn't become a "dumping ground".

Yes, if you are not going to use monorepo for -forge, it makes sense to create separate org. But if electron-builder in any case uses monorepo and electron-updater can be used standalone — no need to move it to a separate org. Also, electron-builder in any case related to forge and can build forge projects or electron-builder targets can be reused in the electron-forge (not yet released). We are all build tools for electron and current repo is not a "dumping ground" (we discuss moving this simple and related repo 45 days :)).

[malept]

I don't think that this Travis limitation should be the main reason to create org per tool :)

It would be exactly the same problem with AppVeyor, except you already use a different account there. There's clearly already precedent for electron-builder to have its own separate account.

My point is that you currently have two repos in userland (one of which is a git repo full of binaries...) and you want to add a third - that's a good point to start considering moving the project to its own org.

I don't actually care if you want to keep a monorepo for -builder, it was just a suggestion.

[develar]

you want to add a third - that's a good point to start considering moving the project to its own org

electron-updater can be used standalone (the same about electron-publish / electron-publisher-s3). That's the point why I don't want to move to a separate org. Will be no packages designed only for electron-builder — in this case it will be in the electron-builder repo.

[malept]

As long as electron-updater is in the same repo as electron-builder, people will assume that it requires -builder to run, no matter how many times you assert otherwise.

[develar]

people will assume that it requires -builder to run, no matter how many times you assert otherwise.

... but in the same time it will not make our org as dumping ground since actually it is not ;)

[stefanjudis]

@develar @malept @paulcbetts @MarshallOfSound

Hello everybody, I know this is a tough discussion here, but I really would love to find a solution for my own problem which is related to the discussion.

I started electron-builder initially and I was part of moving it into electron-userland. That's the reason why I have admin rights. I'm not active part of any development in one of the repos under electron-userland and don't plan to be in near future.

The situation is that every time @develar wants to change/add something, it proxies through me. Usually I'm not aware of changes or impact of the given request. I don't want to do this anymore. I think it makes sense to revoke my rights for that reason, now.

Right now we're stuck on

I have been hesitant to give admin rights (to @develar) for a couple of reasons:

and the discussion around moving electron-builder out of the org.

Maybe it makes sense to move the discussion to a hangout or anything?

[develar]

@malept you didn't answer to my answers to your "for a couple of reasons", probably it was some kind of answer :) actually, I don't need admin rights — you can just allow access for requested app (electron-userland/electron-builder#1433 (comment)). For record, it is the second request for past year and I don't see that we need different org to be able to have another set of allowed apps (read public data only).