zeke
03:20
I’m the one who turned that protection on. We had a few trigger happy merges in the past, but as long as we’re educating maintainers to get impartial reviews, we should be fine without it.
Wednesday, May 9th
tvst
03:28
I'm a new member and don't know how things worked in that past, but in principle I prefer forcing all merges to go through code reviews first
And it doesn't quite matter who reviews, so long as it's a maintainer, of course
groundwater
03:40
It’s a bit confusing, but
Restrict who can push doesn’t exempt people from review. It means that, even after your code is reviewed, you cannot push merge unless you’re on the special list.
So the permission we’re thinking of changing isn’t about reviews, it’s about after code is reviewed by a
CODEOWNER can you merge it, or should admins/special-group be the only ones allowed to merge?
ckerr
03:53
IMO the workflow in e/e is working alright despite having a much higher volume than libcc
If we want to equalize the permissions, I would copy from e/e to libcc, not the other way around
groundwater
04:03
@ckerr given that, @nornagon couldn’t merge a PR without making him an admin. Something should probably change in e/e if we want to go that route.
ckerr
04:03
That said, I think it's kind of academic as the overlap between reviwers and releases is pretty much 1-1. If there is consensus on other approaches I wouldn't block on it.
@groundwater do all releasers have admin rights? I'm reading the screenshots wrt just having a predefined group of who has merge permissions
(edited)
ckerr
04:12
If we are using "can release" as a proxy for "can merge" s.t. anyone who wants to merge PRs also picks up release privs with it, then that's a problem
I'd go for separate groups for 1. code owners, 2. mergers, 3. releasers, and people get added to the groups per maintainer consensus
(edited)
The reason I slightly prefer this is it's good to have that flexibility if you ever need it. The reason it's only a slight preference is right now the owners and mergers teams would be pretty much identical
(edited)
Possible use case, say we rope Kevin in to review a change to some of his code that he understands best, but he's no longer active and maybe that review is more advisory than definitive
(Apologies to Kevin who wouldn't try to merge something on his own in that situation. Just demonstrating that reviewing isn't by definition equivalent to merging)
Wow that was a wall of text. shuts up
(edited)
groundwater
04:27
@ckerr right now, only admins can merge
Not saying we can’t change that, but that’s the situation.
If we get ride of
Restrict who can push then anyone can merge after approval. If we want another model, we’d have to create new teams.
ckerr
04:32
We could create a team
mergers, add all releasers to it, use that for the Restrict
Sorry if this is an obvious question from the team name, but what else can
releasers do?
groundwater
04:38
Releasers is an admin group for e/e so they can do anything.
ckerr
04:39
Ok
Then I'm leaning even more to the three-team choice
sofianguy
05:24
@ckerr I thought you were PTO today
groundwater
05:29
DEMERIT
nornagon
05:55
Wait... so can ChromeOS run Electron apps now?? https://www.theverge.com/circuitbreaker/2018/5/8/17318340/chrome-os-update-new-features-linux-apps-google-io-2018
groundwater
05:57
I think they can run inside docker
They’ve been working on Wayland a lot, and it was prob to get it working w/ containers.
paulcbetts
06:04
RIP macOS
groundwater
06:08
I agree that if they can pull this off, MacOS/iOS just lost a huge lead
marshallofsound
06:56
I don't want to unlock electron master to ~200 people, we locked it down in response to trigger happy merges and in the spirit of making master safer / more controlled. IMO it's been working fine
nornagon
06:59
@marshallofsound just … don’t approve PRs you don’t want merged?
marshallofsound
07:28
@nornagon Required reviewers are still this weird area that almost so what we want, but not quite. For instance most prs are just blocked on the catch all reviewers group. This means that pretty much anyone can review that PR and if we unblock master, merge it.
I still haven't seen an actual example of our current process not working and until that happens and we have a discussion about how to handle it, I don't want to make master less-safe. Currently I'm extremely happy knowing things in master were only possibly put there by ~10 people.
I still haven't seen an actual example of our current process not working and until that happens and we have a discussion about how to handle it, I don't want to make master less-safe. Currently I'm extremely happy knowing things in master were only possibly put there by ~10 people.
ckerr
08:28
Only change I would make to e/e rn is to make a
mergers team, copy all the releasers members to it, and use that going forward. This would fix the "anyone who can merge, can do anything" wart.
(edited)
But that's minor. On the whole I agree with @marshallofsound that it ain't broke
zeke
08:42
> make a
Branch protection is the only purpose of the existing
mergers team, copy all the releasers members to itBranch protection is the only purpose of the existing
releasers team. We can rename it to mergers if that makes it more clear.
zeke
08:47
In the spirit of eventual automated semantic releases, I’d be happy to drop the “releaser” role entirely.
Thursday, May 10th
Electron Maintainers
00:55
Event starting in 5 minutes:
Electron Maintainers
02:25
Event starting in 5 minutes:
Friday, May 11th
ckerr
01:07
about the discussion a couple days ago about how PRs get merged in e/e and e/libcc
The way I read it was the idea of opening up merge permissions to all comers was voted down, but that giving people admin permissions in order to merge was overkill, so a different
mergers group would be a nice balance between those two extremes
This was my own opinion. I think @marshallofsound was agreeing with all of the above, and @groundwater and @codebytere gave some agreement emojis but didn't weigh in verbally
But maybe I misread anyone's opinion, so I thought I'd float the idea out there for anyone to veto before I make this change
If nobody's opposed, I'll make a
mergers team for this and populate it with everyone currently on releasers
Electron Maintainers
01:25
Event starting in 5 minutes:
groundwater
01:27
Should we move this
Does anyone go?
codebytere
01:27
i can actually go today but idk if others can?
groundwater
01:28
okay let’s keep it
zeke
02:26
I normally attend. It’s usually a quiet unstructured meeting, but I’d be in favor of keeping it alive.
nitish
02:39
What was this : about?
(edited)
Event starting in 5 minutes:
jkleinsc
03:00
@nitish I think @zeke said it was talking to NodeSource about using N|Solid on the electronjs.org website
nitish
03:02
Ahh! Interesting.. Thanks! ::
Electron Maintainers
12:55
Event starting in 5 minutes:
Saturday, May 12th
Electron Maintainers
01:55
Event starting in 5 minutes:
Monday, May 14th
sofianguy
23:59
I won't be at today's meeting.
Last week: - No partner company bugs reported. - VS Code plans to upgrade to 2.0.0 next month. - Google Hangouts will upgrade to 2.0.0 soon, maybe this week, and cannot disclose how many users. This week: - Are we going to release version 2.1 soon? and 3.0.0?
jkleinsc
23:59
Weekly standup notes: https://hackmd.io/UnaUXRzcQVCNSVxiqOnhww?edit
Tuesday, May 15th
Lukas Reschke
05:05
@Lukas Reschke has joined the channel
miniak
06:47
I've found a bug in the documentation (https://github.com/electron/electron/pull/12922), leading to incorrectly generated electron.d.ts, can you please have a look?
(edited)
Electron Maintainers
15:54
Event starting in 5 minutes:
alexeykuzmin
20:51
> Currently I’m extremely happy knowing things in master were only possibly put there by ~10 people.
Do the same rules apply for release branches?
If they don’t then they probably should. Can someone with access to repo settings check it please?
Do the same rules apply for release branches?
If they don’t then they probably should. Can someone with access to repo settings check it please?
marshallofsound
20:58
off the top of my head we enforce the same policy on release branches
can check shortly
marshallofsound
21:27
@alexeykuzmin
1-3-x through to 2-0-x are marked as protected branches
alexeykuzmin
21:29
@marshallofsound
https://github.com/electron/electron/pull/12926 was merged without green builds and required approvals. Is it because it came from a fork?
https://github.com/electron/electron/pull/12926 was merged without green builds and required approvals. Is it because it came from a fork?
Backport of #12922
See that PR for details.
See that PR for details.
marshallofsound
21:31
@alexeykuzmin the branches are flagged as protected, but not restricting who can push to them
lemme fix that
It was just
2-0-x missing those settings, every other release branch is alg
alexeykuzmin
21:39
@marshallofsound thank you!
Electron Maintainers
23:55
Event starting in 5 minutes:
Wednesday, May 16th
groundwater
02:24
There have been some discussions with the electron team but there are additional factors that mean this likely require the electron team to do work as well.
The main issue I believe is that electron uses different versions of V8 than what may have been used with Node.js (if I remember correctly to match the version of chrome used), and therefore the implementation of the N-API methods that are exported might have to be tweaked for a version of V8 that was never shipped with Node.
Not quite sure why it would be Windows only though.
Probably best to loop in @groundwater into the discussion to get the full picture.
The main issue I believe is that electron uses different versions of V8 than what may have been used with Node.js (if I remember correctly to match the version of chrome used), and therefore the implementation of the N-API methods that are exported might have to be tweaked for a version of V8 that was never shipped with Node.
Not quite sure why it would be Windows only though.
Probably best to loop in @groundwater into the discussion to get the full picture.
got pinged on this, but haven’t digested the issue yet
zeke
05:03
Current status: dusting off the broken i18n build to make way for new electron versions on the website. The cause: rogue Hebrew translations across language boundaries. — luckily the proofreader community has put out the fires and I just have to do some git merge conflict resolution.
javan
05:11
@javan has joined the channel
javan
05:43
Thursday, May 17th
jkleinsc
03:46
1.7.15, 1.8.7, and 2.0.1 have now been released with important security updates: https://github.com/electron/electron/releases. As always we encourage you to upgrade to the latest version to stay on top of security updates.
(edited)
nitish
05:33
@nitish uploaded a file: Untitled and commented: I’m getting a browserify error when trying to build tag v2.0.0 locally. electron master build works. Am I missing something?
zeke
05:37
Achievement Unlocked: Three releases of Electron went out in one day, the homepage and docs are displaying the latest versions across all 25 languages, and I didn’t have to touch anything!
Also 1,310 translated strings in nine languages in the last 20 hours. CI can’t even keep up.
(edited)
jkleinsc
05:40
@nitish I ran into that as well
We really need to add a package-lock.json
Actually, I ran into it on the 1-7-x branch
@nitish was that when running script/bootstrap?
nitish
05:44
Yes, when running bootstrap.
Actually, in the update part of bootstrap. So running update manually also gave the same error.
jkleinsc
05:46
Were you building from the actual v2.0.0 tag or just the 2-0-x branch?
nitish
05:48
From the tag
jkleinsc
05:54
@nitish I think this commit fixed the issue in the 2-0-x branch: https://github.com/electron/electron/commit/d0bbf3fb3c856b8e29aab5c36a13233ec1d9da3d#diff-689fbc6686e4a33fc655de3dfb30075e
nitish
06:12
Interesting.. I’ll try the 2-0-x branch first. Thanks! :
nitish
07:26
2-0-x branch build worked. But, I don’t understand why the other v2.0.0-beta.x builds and the v2.0.0 build fails locally, but succeeded for release. Any thoughts?
Just curious what’s different. (edited)
Just curious what’s different. (edited)
jkleinsc
08:09
@nitish it was due to an npm dependency, I think specifically
readable-stream which is a subdependency of browserify. The latest is 2.3.6 which seems to cause this issue. But I have another local directory with 2.3.5 installed and that one doesn’t throw this error.
Friday, May 18th
Electron Maintainers
12:55
Event starting in 5 minutes:
marshallofsound
13:41
Woops missed that one ^^ meeting ran considerably overtime
codebytere
23:26
i thought it was 12 bc my brain has not yet remembered I’m not EST
apologies
Saturday, May 19th
sofianguy
00:53
I thought that meeting time was going to change after @codebytere moves to PST
codebytere
00:53
i think it is?
i updated my time slots in the google sheet