R1/Beta2/StatusMeeting-2020-04-12: #haiku-beta2.freenode.log

Session Start: Sun Apr 12 17:03:05 2020
Session Ident: #haiku-beta2
03[17:03] * Now talking in #haiku-beta2
03[17:03] * Topic is 'Meeting room.'
03[17:03] * Set by waddlesplash!sid58358@gateway/web/irccloud.com/x-fmwtoxigzukxjaby on Sat Apr 11 00:07:04 2020

OPENING

01[20:58] <@nielx> I will repeat the query (for those who joined later)
01[20:58] <@nielx> https://dev.haiku-os.org/query?status=assigned&status=in-progress&status=new&status=reopened&milestone=R1%2Fbeta2&groupdesc=1&group=priority&col=id&col=summary&col=owner&col=type&col=priority&col=component&col=version&order=priority
01[20:59] <@nielx> So hello everybody. Thank you all for coming. The goal for today's meeting is to determine how far we  are from starting the R1 beta 2 release train
01[20:59] <@nielx> It would be best to look at the blockers we have for beta 2 and work from there

#14805 Remove struct size hacks in net80211

[21:00] <@waddlesplash> so, the first blocker is the "struct size hacks", which is actually just a "we need to change this after closing ABI compatibility window"
01[21:00] <@nielx> So looking at the timeline, when would that be?
[21:00] <@waddlesplash> and PulkoMandy already posted that on Gerrit; so that doesn't need to take any time at all right now :)
01[21:01] <@nielx> if we take the planning you put on https://dev.haiku-os.org/wiki/R1/Beta2/Timeline?
[21:01] <@waddlesplash> it would be on or just before the "3 May: branch r1beta2!" item
[21:01] <@waddlesplash> or, actually, if we don't mind "breaking" beta1 repositories a little early, we can do that right now
01[21:01] <@nielx> is the equivalent work for wpa_supplicant also ready to go?
[21:01] <@waddlesplash> (this won't break existing beta1 installs, it will just make furtuer updates to beta1 impossible.)
[21:02] <@PulkoMandy> yes, I think we should start doing it, so we can see if the new wpa_supplicant works
[21:02] <@waddlesplash> they were; however, that leads to another item
[21:02] <@waddlesplash> I did make the necessary wpa_s changes, and actually a lot more fixes to wpa_s that make it a lot more stable; but since then OpenSSL 1.1 came out and now we have switched to it
[21:02] <@waddlesplash> so, I need to merge a new version of wpa_s
[21:03] <@waddlesplash> I was planning to do this locally today. But, indeed, since this is now 1.5 years of wpa_s release we do not have, it's probably better to do that now, so it can be tested more between now and the release.
[21:03] <@waddlesplash> *do that now = break master vs b1 and ship the new wpa_s
01[21:03] <@nielx> right
01[21:03] <@nielx> sounds better to break master now then
[21:03] <@PulkoMandy> mh
[21:03] <AGMS> How is Beta1 to Beta2 update done?  Install over it or pkgman update?
[21:04] <@PulkoMandy> we need to make sure we have an upgrade path from beta1 to beta2, that may mean doing last minute updates to beta1
[21:04] <@waddlesplash> OK. I can do that just after the meeting, transition buildmaster, and ship the new wpa_s update.
01[21:04] <@nielx> PulkoMandy: how so?
[21:04] <@waddlesplash> PulkoMandy: no, cocobean tested a full-sync from b1 to nightly about 2 weeks ago and it went well
[21:04] <@PulkoMandy> AGMS: pkgman update. That was the whole point of pkgman
[21:04] <@waddlesplash> he first tried a "pkgman update" which indeed broke things; but a "full-sync" worked just fine
01[21:04] <@nielx> I can put a call on the user forum to get that tested
[21:04] <@waddlesplash> nielx: that=?
[21:04] <@PulkoMandy> nielx: if we found that the update didn't go well and you first need an up to date beta1 with some fixes before moving to beta2
01[21:04] <@nielx> upgrade beta 1 tob beta 2
[21:04] <@waddlesplash> oh, no, it's been tested; there was even a ticket
[21:05] <@waddlesplash> PulkoMandy: we don't, a straight upgrade works just fine
[21:05] <@PulkoMandy> yes, if it's been tested, we should be fine
01[21:05] <@nielx> there ishttps://dev.haiku-os.org/ticket/15808
[21:05] <@PulkoMandy> unless the extra changes we do now risk breaking something. But I think we have only wpa_supplicant planned, which is likely ok
[21:06] <@waddlesplash> for reference: https://dev.haiku-os.org/ticket/15684#comment:6
[21:06] <@waddlesplash> nielx: ^
01[21:06] <@nielx> ok. so to summarize: in the coming week the patch will be pushed. 
01[21:06] <@nielx> After that wpa_supplicant will be fixed/updated
01[21:06] <@nielx> there may be some breakage in the build
[21:06] <@PulkoMandy> yes, or rather "at the same time" because that's the problem here, we need to do both for things to work
01[21:06] <@nielx> right
[21:06] <@waddlesplash> it is worth noting here that a new wpa_s is "just" another HaikuPorts package
01[21:07] <@nielx> but don't you first need the buildbot to be updated?
[21:07] <@waddlesplash> however, we have not done a full build package set update, and of course that will be done too somewhere in here
01[21:07] <@nielx> is there some circular thing here?
[21:07] <@PulkoMandy> we can build the package outside of buildbots I think
[21:07] <@waddlesplash> nielx: no, I'd cut mmlr's buildmaster over after the patch was pushed
01[21:07] <@nielx> ok, and I am guessing that buildmaster is not on wifi :-)
[21:07] <@waddlesplash> that is, update the set of packages buildmaster builds haikuports against; currently it's on r1/beta1
[21:08] <@waddlesplash> no, actually the set of packages is independent of the host system due to haikuporter chroots
01[21:08] <@nielx> ah, got you
[21:08] <mmlr> yup, seeding new initial packages should be enough
[21:08] <@waddlesplash> as log as syscall ABI stays the same, we can and do change what version buildmaster uses
[21:08] <@waddlesplash> I've done this multiple times already
[21:08] <@waddlesplash> (mostly from beta1 to a newer beta1, but still)
[21:09] <mmlr> we do that anyway, the buildboots are on nightlies
01[21:09] <@nielx> ok, I will update my comment on the ticket then 
[21:09] <@waddlesplash> anyway, so as I was saying, we have not update the "build packages" set in a while
01[21:09] <@nielx> in any case, this one looks like it will be solved in time (barring the unexpected)
[21:10] <@waddlesplash> this is the set of packages that Haiku is built against; and updating wpa_s in the shipped releases involves updating this
[21:10] <@PulkoMandy> yes

#15744 WonderBrush: artifacts when scrolling

[21:10] <@PulkoMandy> I think we can move to the other ticket?
01[21:10] <@nielx> https://dev.haiku-os.org/ticket/15744
01[21:10] <@nielx> let's move on
[21:10] <@waddlesplash> ok
01[21:10] <@nielx> So the status here is that I saw there may be a patch
[21:10] <@PulkoMandy> for this one, X512 has a proposed patch on Gerrit
01[21:10] <@nielx> and there is some discussion which one is the best solution
01[21:11] <@nielx> I could not determine whether X512 agreed with going for patchset 4
01[21:11] <@nielx> (https://review.haiku-os.org/c/haiku/+/2275)
[21:11] <@waddlesplash> right, so, what's happening here is that X512 submitted some rather nice "rendering glitch" fixes, but in the process broke BeOS compatibility slightly
[21:11] <@PulkoMandy> yes, it took some time for me to understand how this all fits, but now I think patchset 4 is correct
[21:11] <@waddlesplash> in his defense, the documentation indeed does not specify what behavior is, but that's not really an argument
[21:12] <@PulkoMandy> well, testing all BeOS apps is hard, we don't really have an usable testsuite nor a QA team
[21:12] <@waddlesplash> right, I'm still on the fence here about what we should do, to be honest
01[21:12] <@nielx> what is the name of that law that says that eventually someone will rely on any undocumented behaviour of your api
[21:12] <@PulkoMandy> anyway, the issues have been found, the patch has been uploaded, and then there has been some debate on what the best API would be
[21:12] <@waddlesplash> right
[21:12] <@PulkoMandy> the idea is to use patchset4, which makes no change needed for existing apps
[21:12] <@waddlesplash> I'm still not sure what the best API is either
[21:12] <@PulkoMandy> and requires setting a new view flag to enable the new feature
[21:12] <@waddlesplash> PulkoMandy: well, that's the thing; if WonderBrush is the only casualty here, I'd say we should fix WB and move on
[21:13] <@PulkoMandy> in terms of ABI that's simple to handle, and we keep maximum BeOS compatibility
[21:13] <@waddlesplash> this is why the last version of the patch is IMO nicer, as it's more logical
[21:13] <@waddlesplash> and we do keep BeOS compatibility in that, by applying the flag automatically the same as the new area flags
[21:13] <@waddlesplash> for Be ABI applications that is
[21:13] <@PulkoMandy> that wouldn't work for Wonderbrush, it's an Haiku app and has been built on Haiku
[21:14] <@waddlesplash> yes, so we add the flag to it
[21:14] <tqh> what would be best for future apps?
[21:14] <@PulkoMandy> I don't see the need to introduce a difference between BeOS and Haiku here
[21:14] <@waddlesplash> but we can also make the flag apply to Haiku < b2 apps
[21:14] <@waddlesplash> tqh: the question is what behavior should be when you have a view with a B_TRANSPARENT_COLOR background
[21:15] <@waddlesplash> i.e., does that mean views underneath it are drawn, or not?
[21:15] <@PulkoMandy> it doesn't really matter, one version of the patch introduces a B_TRANSPARENT_VIEW flag (with the new behavior), the other introduces a B_OPAQUE_VIEW flag to have the old behavior
[21:15] <@PulkoMandy> and then we need to force that flag on all apps relying on the old behavior
[21:15] <@waddlesplash> right, I've argued for B_OPAQUE_VIEW because: 1. otherwise we would have both B_TRANSPARENT_VIEW and "views with B_TRANSPARENT_COLOR backgrounds", which can get conceptually confusing
[21:16] <@PulkoMandy> and yes, the only difference is when the view color is set to B_TRANSPARENT_COLOR: should the underlying view be redrawn (new behavior), or not (old behavior which is BeOS compatible and documented in the be book)
[21:16] <@waddlesplash> is it documented in the book?
[21:16] <@PulkoMandy> yes
[21:16] <@PulkoMandy> the documentation to SetViewColor explicitly says that using B_TRANSPARENT_COLOR does not make the view transparent
[21:16] <@PulkoMandy> and also says that this is confusing
[21:17] <@waddlesplash> ah
[21:17] <@waddlesplash> that's unfortunate
[21:17] <@waddlesplash> ok, then I agree, patch set 4 is indeed better
[21:17] <@waddlesplash> I just wish we had a better name for the flag
[21:17] <@PulkoMandy> we could rename B_TRANSPARENT_COLOR to B_NO_COLOR or something
[21:17] <@PulkoMandy> or have an alias
[21:18] <@waddlesplash> well, elsewhere, B_TRANSPARENT_COLOR *is* transparent, i.e. in actual draw operations
[21:18] <@waddlesplash> (any color with a=0 is, but, this is an optimization)
[21:18] <@waddlesplash> so it's more of used incorrectly, not named incorrectly, so to speak
[21:18] <tqh> could we differ from BeOS for new apps?
[21:19] <@PulkoMandy> yes, but we can have another constant (with the same value but it doesn't matter) for this case
[21:19] <@waddlesplash> tqh: yes, that's the B_OPAQUE_VIEW proposal, as discussed above
[21:19] <@PulkoMandy> tqh: yes, but the BeOS behavior is also useful for other reasons (it avoids flickering in some cases)
[21:19] <@PulkoMandy> so we still need to allow it
06[21:19] * tqh nods
[21:20] <@PulkoMandy> with B_OPAQUE_VIEW that makes B_OPAQUE_VIEW + B_TRANSPARENT_COLOR a valid use case, which I think is not less confusing
01[21:20] <@nielx> ready to round off here? can someone summarize? I lost track in the middle
01[21:20] <@nielx> it looks like there are solutions
01[21:20] <@nielx> it is now down to picking the best one
[21:20] <@waddlesplash> nielx: there is also the "revert offending commits in beta branch" solution
[21:20] <@waddlesplash> not great, but may be the best for the moment
[21:21] <@waddlesplash> until we can decide how we want to name the bikeshed :p
01[21:21] <@nielx> Well, if we follow your time proposal we still have a few weeks before we cut the beta
[21:21] <@waddlesplash> right
01[21:21] <@nielx> I'm sure we will be able to decide on red before that :-P
[21:21] <@waddlesplash> however, most of these are for testing, with RCs
01[21:21] <@nielx> correct
[21:21] <@waddlesplash> but since this change affected very few apps, that may be ok
[21:22] <@PulkoMandy> the other patches are correct and do indeed fix annoying bugs, I think, so I'd prefer to merge the change
[21:22] <@PulkoMandy> patchset 4 being the simpler version and less likely to affect anything
[21:22] <@waddlesplash> ok, so we can just call it B_TRANSPARENT_VIEW for now and rename it later
[21:22] <@waddlesplash> let's do it?
01[21:22] <@nielx> I'm all for it!
[21:22] <@PulkoMandy> and yes, we can rename the flag if someone thinks of a better name
01[21:22] <@nielx> again, we may leverage the discussion board as testers for the change
[21:23] <@waddlesplash> mh, how does one replace a newer patch set with an older one?
01[21:23] <@nielx> that's semantics :-) 

#14382 Package kit boot activation doesn't create users

01[21:23] <@nielx> shall we move on?
[21:23] <@waddlesplash> ok
01[21:23] <@nielx> https://dev.haiku-os.org/ticket/14382
01[21:23] <@nielx> so to some other issues
01[21:24] <@nielx> this one is about package management
01[21:24] <@nielx> wait
01[21:24] <@nielx> ah no, my query is correct
[21:24] <@waddlesplash> yes, so, this is a long standing issue that mostly affects sshd
[21:25] <@PulkoMandy> yes, it's about not activating packages on first boot
01[21:25] <@nielx> AGMS wanted to nominate that one for today
[21:25] <@waddlesplash> ah right, PulkoMandy did these patches, I'll let him explain
[21:25] <@PulkoMandy> I fixed parts of it, except the one that actually make things work
[21:25] <@waddlesplash> nielx: no, that was another one?
01[21:25] <@nielx> yes, sorry
01[21:25] <@nielx> I am confused, he did mention it :-)
01[21:25] <@nielx> PulkoMandy take it away
[21:25] <@PulkoMandy> so, the package kit relies on an "activated_packages" file to remember if it has run the package activation scripts
[21:26] <@PulkoMandy> but on a fresh install, the file is missing and package kit does nothing then
[21:26] <@PulkoMandy> it should instead activate all packages
[21:26] <@PulkoMandy> probably not that hard to fix, assuming it does not break anything else
[21:26] <AGMS> What happens if a package is activated twice?  Is that safe?
01[21:26] <@nielx> so what do we need to fix this? who has the knowledge of the area?
[21:27] <@PulkoMandy> AGMS: depends what the activation script does
[21:27] <@PulkoMandy> so, we assume it's not
[21:27] <@waddlesplash> yes, and this is a problem, actually
[21:28] <@waddlesplash> because it was until now safe to delete the administrative directory
[21:28] <@PulkoMandy> nielx: I'm reading my own comment on Trac, I tried to add the package activation at boot, and it didn't work, launch_daemon was not found (which is what happens when we fail to mount packages)
[21:28] <@PulkoMandy> waddlesplash: well it would still reactivate everything then
01[21:28] <@nielx> this is particularly a first launch issue, isn't it?
[21:28] <@PulkoMandy> not on boot, but next time you install or uninstall something
[21:28] <@waddlesplash> PulkoMandy: yes, but then it will re-run scripts
[21:28] <@waddlesplash> and it presently doesn't I think?
[21:28] <@PulkoMandy> it does
[21:28] <@waddlesplash> ah, ok
[21:28] <@PulkoMandy> just not on boot
[21:29] <AGMS> How about the idea for an empty transaction history file on a fresh install?
[21:29] <@waddlesplash> nielx: sshd needs a "ssh" user, which the package specifies to create, but since it's not activated the first time the user is not made
[21:29] <@waddlesplash> AGMS: as commented on Trac, that breaks booting
[21:29] <@waddlesplash> nobody has yet investigated why
[21:29] <@PulkoMandy> we could workaround this by adding the user in the install, if no other fix is found, I guess
01[21:30] <@nielx> Re waddlesplash/AGMS: do we know why it breaks booting?
[21:30] <@waddlesplash> nielx: read PulkoMandy's comment on trac...
[21:31] <@PulkoMandy> no, I didn't investigate further. Probably something wrong with my attempt to do the change
[21:31] <@PulkoMandy> maybe someone else will try it and it will work
01[21:31] <@nielx> Anybody in this room willing to pick it up?
01[21:32] <@nielx> I mean, I could say yes, but it probably goes beyond my abilities
[21:32] <AGMS> Well, I've half read over the package system, but not the package file system stuff.
01[21:32] <@nielx> It's a high priority issue
01[21:33] <@nielx> so not a blocker
01[21:33] <@nielx> and there might be a workaround
01[21:33] <@nielx> maybe start with the workaround (i.e. creating the user at install time) and work your way back from there?
[21:34] <AGMS> Race you?  Both of us tackle it as time permits.
[21:34] <AGMS> I'm just not sure I have the time.
01[21:34] <@nielx> ok, I'll help you out there

#14916 Audit all syscalls for permissions and access checks

01[21:34] <@nielx> Then I suggest we move on to another high priority issue: https://dev.haiku-os.org/ticket/14961
[21:35] <@PulkoMandy> waddlesplash: any plans for this one? or do we just go with what we have for beta2 and continue the work in beta3?
[21:35] <@waddlesplash> yes, we've lived with it thus far, it's annoying but we can work around it.
[21:35] <@waddlesplash> so, the syscalls audit probably should just be pushed back at this point
01[21:36] <@nielx> right, that might introduce some breakage
[21:36] <@waddlesplash> no, it won't, at least initially
[21:36] <@waddlesplash> largely because most of my changes are just "geteuid() == 0"
01[21:36] <@nielx> ah
[21:36] <@waddlesplash> at least, the ones for the system profiler and stuff like that are
01[21:37] <@nielx> in any case, it sounds like there are dangers to doing parts of this ticket now, so maybe just push to R1/beta 3
01[21:37] <@nielx> right?
[21:38] <@PulkoMandy> it's not even that high priority, as in, nothing is broken, and even with that fixed we can't really pretend Haiku is secure
[21:38] <@PulkoMandy> (even if it goes a long way towards that already)
[21:39] <@waddlesplash> there aren't dangers to doing any part of that ticket, until we have userland run as non root
01[21:39] <@nielx> and the IS_USER_ADDRESS part?
03[21:39] * dorje (~vision@cpe-65-27-104-0.new.res.rr.com) has joined #haiku-beta2
[21:39] <@waddlesplash> that one is the most critical, but it's "mostly" done
[21:39] <@waddlesplash> though I keep finding subtle but critical violations of it
01[21:40] <@nielx> right. I'll move the ticket over to beta 3 as is, we can discuss priority in the beta 3 meeting.
[21:40] <@waddlesplash> e.g. https://github.com/haiku/haiku/commit/91cc452e90f97c60f0dfa11cbfa4ca1d8d1d52cf
01[21:40] <@nielx> Let's move on to the next one
01[21:40] <@nielx> https://dev.haiku-os.org/ticket/1651
[21:40] <@waddlesplash> however, https://review.haiku-os.org/c/haiku/+/2376 is still outstanding as part of that and needs to be merged probably
[21:40] <@waddlesplash> though axel still hasn't replied

#1651 [BTextControl] When alignment is set to B_ALIGN_RIGHT, the text is not aligned to the right of the control

01[21:41] <@nielx> about #1651, this has been a request of jscipione
01[21:41] <@nielx> unless he has another nick here, he is not in the room
01[21:42] <@nielx> He wrote: There's one more tricky bug that I'd like to see fixed before R1 and
01[21:42] <@nielx> that is text controls not aligning text to the right.
01[21:42] <@nielx> https://dev.haiku-os.org/ticket/1651
01[21:42] <@nielx> The most shining example of this is DeskCalc which has been set to use
01[21:42] <@nielx> B_ALIGN_RIGHT since forever but still is aligning text to the left.
[21:42] <@PulkoMandy> no, he didn't join (he's online as Skipp_Haiku however)
[21:42] <@waddlesplash> nielx: he's Skipp_*
[21:42] <@waddlesplash> and he's in #haiku it apperars but not here
[21:42] <@PulkoMandy> yes, he said R1 and I agree with that; for beta2 it's probably not too important
01[21:43] <@nielx> I'll invite him here

#13427 Package Uninstall should run a Bash Script too

01[21:43] <@nielx> for now we will move on
01[21:43] <@nielx> https://dev.haiku-os.org/ticket/13427
01[21:43] <@nielx> per request of AGMS
[21:43] <AGMS> That's the one I was requesting,
[21:43] <AGMS> but on further thought (pkgman update for Beta1 to Beta2), it will have to be done at Beta2+1,
[21:44] <AGMS> since it bumps the minor version number of packages, and Beta1 doesn't like that.
[21:44] <@waddlesplash> correct
01[21:44] <@nielx> sounds like it will break a beta1->beta3 upgrade path
[21:44] <@waddlesplash> this one *would* break beta1->beta2 upgrade
[21:44] <@waddlesplash> correct
[21:44] <@PulkoMandy> yes, that's why this one had to be moved to after beta2
01[21:44] <@nielx> don't know whether that is necessarily bad
[21:44] <AGMS> Right, you'd have to do B1->B2->B3
[21:45] <@PulkoMandy> sorry about that delay, but we don't really have another way to go about this one
[21:45] <@waddlesplash> I think it's not; and it paves the way for us to be able to change the package format in subtle ways, so that's very good
[21:45] <AGMS> Anyway, the fix is in already for Haiku to handle minor version bumps, so B2 can read the new packages.
[21:45] <AGMS> And just skip unknown attributes.
[21:45] <@waddlesplash> right, so we can merge the change after branching beta 2, so we will have it on the nightlies
01[21:45] <@nielx> ok
[21:46] <@waddlesplash> OK, I changed the milestone.
[21:46] <AGMS> So, right after Beta2 is good?
01[21:46] <@nielx> right after the branch point
[21:46] <AGMS> Great!

#14525 [Package Kit] some strings are not localized

01[21:46] <@nielx> So moving on
01[21:46] <@nielx> Here's me using the privilege of setting the agenda.
01[21:46] <@nielx> https://dev.haiku-os.org/ticket/14525
01[21:47] <@nielx> I have a patch for this. 
01[21:47] <@nielx> https://review.haiku-os.org/c/haiku/+/2329
01[21:47] <@nielx> I will try to do some more testing
[21:47] <@waddlesplash> yes, if you can add some catkeys and confirm it works, sounds good
01[21:48] <@nielx> ok, will try.
01[21:48] <@nielx> that's the last one.

Beta 2 Timeline & Release Coordinator & other points

01[21:48] <@nielx> waddlesplash made a proposal for a release schedule
01[21:49] <@nielx> https://dev.haiku-os.org/wiki/R1/Beta2/Timeline
01[21:49] <@nielx> any thoughts about this?
[21:49] <@waddlesplash> this is the same schedule we use for beta1, just transposed
01[21:49] <@nielx> My question is: who represents HaikuPorts?
[21:49] <@waddlesplash> I've given us 1 week's grace from the present before the timeline starts
[21:49] <@waddlesplash> me
[21:49] <AGMS> How well did Beta1 work?
[21:50] <@waddlesplash> AGMS: I think we missed the target date by 5 days due to EFI testing problems
[21:50] <@waddlesplash> so, 5 days out of a 1.5 month schedule is not bad at all
[21:50] <AGMS> Oh, which reminds me, anyone doing an EFI installer?  Making partitions and all that.
[21:50] <@waddlesplash> and this time, we have some EFI issues, but we can just revert those problems
01[21:50] <@nielx> agreed, once the beta 1 train left te station, it went
[21:50] <@waddlesplash> unfortunately no, we have no plans to resolve that atm
[21:51] <@PulkoMandy> we can schedule it for beta3 if there is a ticket, maybe
01[21:51] <@nielx> maybe something for the beta 3 candidate egg selection painting meeting
01[21:51] <@nielx> :-)
[21:51] <@waddlesplash> ok, one item from me:
[21:51] <@PulkoMandy> the timeline is same as usual, I think, and it worked in the previous releases
[21:51] <@waddlesplash> https://review.haiku-os.org/c/haiku/+/2376
[21:51] <@PulkoMandy> we can shift things if we find a problem in any case
[21:51] <@waddlesplash> axeld -2'd an earlier patch of this, but he's gone MIA...
[21:52] <tqh> I am working on cleaning up EFI bootloader so hope to have better things in a few days.
[21:52] <@waddlesplash> this fixes a potential regression I caused, so it should be merged
01[21:52] <@nielx> ok
01[21:52] <@nielx> could you make a ticket for it, to keep track of it?
[21:53] <@PulkoMandy> waddlesplash: yes, I had read that code and I don't feel comfortable with it because the code looks a bit confusing to me. Would be happy to have some unit tests for it so we can make sure all cases are properly covered
01[21:53] <@nielx> can be a blocker imo
[21:53] <@waddlesplash> well, it's already ready to go
[21:53] <tqh> efi installer would need a lot of work, so not for beta2
[21:53] <@PulkoMandy> otherwise I have to do that with pen and paper and it takes more time :)
[21:53] <@waddlesplash> it just needs someone to +2 it
[21:53] <@waddlesplash> PulkoMandy: read my comment
[21:53] <@waddlesplash> perhaps that should be in the commit message
[21:53] <@waddlesplash> though, the inline comments were enough to me IMO...
[21:53] <@PulkoMandy> well, sure, but I still need pen and paper to follow it
06[21:54] * @waddlesplash never uses pen and paper while coding
[21:54] <@waddlesplash> I think I'm an outlier in that, though
[21:54] <@PulkoMandy> so, just need to spare some time for that, I guess
[21:54] <@waddlesplash> I'll email axel again I suppose, and write a better commit message
01[21:54] <@nielx> waddlesplash: is it possible to write a test? 
[21:54] <@PulkoMandy> well, everyone has their ways. I also use a slinky and a rubik snake or whatever toys I have at hand :>
01[21:54] <@nielx> lol
[21:55] <@waddlesplash> nielx: for the first half yes, for the second half no
[21:55] <@waddlesplash> ultimately the logic is very simple, it just looks complex because of the diff
01[21:55] <@nielx> right
01[21:55] <@nielx> so ping axeld
[21:55] <@waddlesplash> ok
01[21:55] <@nielx> if it does not work out give a shout
[21:56] <@waddlesplash> lastly: I've "made" myself release coordinator again on the Beta2/Status page
01[21:56] <@nielx> right
[21:56] <@PulkoMandy> yes, it's not that complex. Just need to sit down and check everything is ok. Especially if Axel isn't around and I need to bypass his -2, I'd rather be sure of what I'm doing :)
[21:56] <@waddlesplash> anyone object, or really want to do it this time?
01[21:56] <@nielx> that was my next question :-)
[21:56] <@waddlesplash> otherwise, I am perfectly content with doing it again, I've got the time and energy
01[21:56] <@nielx> woot
01[21:56] <@nielx> go for it
[21:56] <@PulkoMandy> ok. We should try to have different people doing it from time to time however
[21:56] <AGMS> Yay!
01[21:57] <@nielx> I'll do beta 3
01[21:57] <@nielx> :-P
[21:57] <@PulkoMandy> so that it's not one single person who knows how to do releases
[21:57] <@waddlesplash> PulkoMandy: I mean, I was not even around as a contributor for alpha4
[21:57] <@waddlesplash> so it's not as if I learned by watching the previous RC do it :p
01[21:57] <@nielx> I could do beta 2
[21:57] <@waddlesplash> if anyone wants to be my "understudy" to make sure that the pages all read out correctly, be my guest
01[21:58] <@nielx> I'll help you out then
[21:58] <@waddlesplash> nielx: actually the one thing that you can "learn" is how to manipulate mmlr's buildmaster :)
[21:58] <@PulkoMandy> and I did alpha3 but that was quite some time ago
[21:58] <@waddlesplash> as I think he and I are the only two who have done any considerable amount of work with it
[21:59] <@waddlesplash> and it would be good to have another member of the sysadmin team be familiar
01[21:59] <@nielx> I'll dive into it
06[21:59] * @nielx is scared
01[21:59] <@nielx> do you want to inform the mailing list? do we need to call a formal vote for the decision and the scehdule? or is this a raise your voice if you have an objection type of thing?
[21:59] <@waddlesplash> no formal votes needed unless there are lots of objections
[21:59] <@waddlesplash> and there weren't last time, so just a "we are doing this, here's the schedule" should be enough
01[22:00] <@nielx> sounds good to me
[22:00] <@PulkoMandy> yes, the normal process is trying to reach concensus first, and raise a vote only if that fails
01[22:00] <@nielx> ok, I want to be mindful of everybody's time
[22:00] <@waddlesplash> nielx: ok, I will write myself in as RC and put you as "secondary" on status page
01[22:00] <@nielx> so any final thoughts before we close off?
[22:00] <@PulkoMandy> should we schedule the next meeting?
[22:01] <@waddlesplash> 2 May, which is a day before branch date?
01[22:01] <@nielx> sounds good
[22:01] <@waddlesplash> well, that's a Saturday
[22:01] <@waddlesplash> if we want to stick with Sundays then the 3rd
01[22:01] <@nielx> we could do the 3rd
[22:01] <@waddlesplash> I don't mind saturdays, either way
[22:01] <tqh> Btw, thx everyone for pushing this!
[22:01] <apl> I'd like to raise one ticket... https://dev.haiku-os.org/ticket/15209 -- I have a PR for this on the works and would like to get this completed before the B2 cut-off if possible.
[22:01] <@PulkoMandy> I don't have a strong reason for sundays either
01[22:01] <@nielx> under current conditions Saturday works for me too
[22:02] <@waddlesplash> ok, so the 2nd it is
01[22:02] <@nielx> apl: when can you submit the PR? 
[22:02] <@waddlesplash> nielx: will you send a notification like last time?
[22:02] <apl> PR is here; https://review.haiku-os.org/c/haiku/+/2467
01[22:02] <@nielx> I will
[22:03] <@PulkoMandy> apl: yes, I planned to look into it but the number of changed files in haikudepot changes is always putting me off a bit (I need to set some time aside to go over it)
[22:03] <apl> Yes I'm sorry about that; it's hard to make small changes with this area.
01[22:04] <@nielx> I've moved the ticket to the beta 2 milestone so that we will at least keep track of it
[22:04] <@PulkoMandy> usually I do these during my lunch breaks at work, but now I work from home and my schedule is a bit changed :)
[22:04] <@waddlesplash> apl: did you ever look into the HaikuDepot ticket about performance that Diver has?
[22:04] <apl> Which ticket is that one for the performance problem?
01[22:04] <@nielx> waddlesplash: I will send a notification mail about the review, you will write the proposal and request for consensus for the beta 2 schedule? 
[22:04] <@waddlesplash> nielx: if you have time after the meeting, want to take a look at the buildmaster cutover?
[22:05] <@waddlesplash> nielx: yes
01[22:05] <@nielx> https://dev.haiku-os.org/ticket/14675
01[22:05] <@nielx> waddlesplash: I can, Final Fantasy VII is still installing
[22:05] <@waddlesplash> LOL
[22:05] <@waddlesplash> apl: ^^
[22:06] <@waddlesplash> ok, so, let's see here
[22:07] <apl> @waddlesplash -- thanks; I am having a look at another usability issue then I can take a look at that, but it all has to be on top of the PR as it's covering a large number of files.
[22:07] <apl> (So I can't really lodge more PRs until that one is cleared)
01[22:07] <@nielx> good way to put pressure there :-P 
[22:07] <apl> Hehe... yer it's unfortunately been a series of these massive touch-everything PRs!
[22:08] <apl> (sorry)
[22:08] <@PulkoMandy> well, it happens :)
[22:08] <@PulkoMandy> I'll try to spare some time for review tomorrow or during the week
[22:09] <apl> Thanks.
01[22:09] <@nielx> apl: shall I make you the default owner for HaikuDepot tickets in Trac?
[22:09] <apl> Actually that probably makes sense at the moment.
[22:10] <@waddlesplash> nielx: ok, I've merged the net80211 change
01[22:10] <@nielx> apl: done, won't work retroactively though
01[22:11] <@nielx> waddlesplash: good, what do I do now
[22:21] <apl> Bye; thank you for the organising @nielx.
01[22:21] <@nielx> see you!