<Begasus[m]>
hmm .. I'm not seeing any use for gzip in flex although it's dependency is in BUILD_PREREQUIRES ...
AndrevS has quit [Quit: umount /dev/irc]
KapiX has quit [Quit: KapiX]
<Begasus[m]>
bbl
nephele has joined #haiku
vdamewood has joined #haiku
<nephele>
Got a email from humdinger in the ml, answered with Haiku mail... all these sytems should be utf-8. Got back my response and all non-ascii characters are mangled :(
KapiX has joined #haiku
Anarchos has joined #haiku
<nephele>
on another note, do we have a tool to rescue gpt tables?
<nephele>
mine is damaged, I think. But there are two blocks. and the EFI does not use the backup one it seems, so it just thinks my drive is unbootable
mmu_man has joined #haiku
<PulkoMandy>
nephele: If Haiku still recognizes it as a gpt purtition table, just renaming one of the partitions on it (from Tracer renaming of a mounted disk) should rewrite it correctly
<PulkoMandy>
No dedicated tool for this, I think, but any partition edit in DriveSetup would also do it
<nephele>
PulkoMandy: seriously? Fixing the superblock is that easy? :D
<PulkoMandy>
Yes, why make it complicated? :)
<nephele>
Discoverability ;)
<nephele>
Would be nice if DriveSetup could then say "uhh somethings wrong here, want me to fix it?" :D
<PulkoMandy>
yes
<PulkoMandy>
Patches welcome :>
<nephele>
I really like Haiku for stuff like this
* Anarchos
reminds to PulkoMandy that when i send patch, waddle goes into a neverending remark storm
<nephele>
in linux it's always a 12 step thing, and in Haiku it's "you can just rename the drive on your desktop"
<PulkoMandy>
Anarchos: You are not alone :(
<nephele>
Thanks PulkoMandy, now to try and reboot my pc. Wish me luck it boots this time... (unrelated to Haiku)
<PulkoMandy>
For now I'm working on non-haiku things so I don't have to fight for years (literally) for every tiny change
<nephele>
Though, Haiku is the only OS that boots so...
<nephele>
PulkoMandy: one man project? :/
<waddlesplash>
Anarchos: PulkoMandy: I don't know what you want me to say here, your patch as-is breaks kernel args ABI in a backwards incomparable way, and at an absolute minimum we need to solve that before it can be merged...
<waddlesplash>
*incompatible
bjorkintosh has joined #haiku
<waddlesplash>
I don't have good ideas for how to fix that that aren't even larger and invasive, the kernel args system is just so fragile unfortunately :/
KapiX has quit [Quit: KapiX]
<waddlesplash>
changes that don't break ABI or API I am not so cautious about and usually merge quite rapidly, as can be pretty clearly seen
<nephele>
waddlesplash: It is *really* difficult lately to work with you in gerrit. I have lost motivation for many parts aswell. You still have a -2 on my changes to clean up controllook renderings for example, with unreasonable demands that everything should be done in one commit for example
<waddlesplash>
but right now part of the problem is that most regressions fall to me to get fixed even if I'm not the one who made the original change because others just don't have enough time, which is one of the reasons I'm more stringent than others in reviews
<nephele>
that's stupid.
<nephele>
We are allowed to break stuff in the nightlies
<nephele>
you can't block everything just because you might be one of the people who *could* fix it, it's not even your responsibility
<waddlesplash>
yes, we are, but there are so many instances where I'm the one who had to investigate and fix regressions caused by others after they went unfixed for quite a while
<waddlesplash>
the alternative is that I could just be revert-happy but I don't know that this would make others any happier
<nephele>
Doesn't matter, If it is *just* before a new beta release and it holds up the beta, then you can revert the change that introduced the regression.
<nephele>
But other than that, just let nightlies be broken a bit, and let people fix it in their own time
Aedil has quit [Quit: Restarting…]
<waddlesplash>
that doesn't work, people were threatening to switch back to beta5 instead of nightlies due to Tracker brokenness for example, so that simply had to be dealt with
<waddlesplash>
if everyone who uses nightlies switched back to beta5 we would be in a not good state, we need people to test nightlies
gouchi has joined #haiku
<waddlesplash>
nephele: if you mean https://review.haiku-os.org/c/haiku/+/8878 then I am the only one with a -2 but there are multiple other developers who had -1s or negative comments
<waddlesplash>
so I am not the only one who objects to that change
<x512[m]>
There are still no explain in commit message why do this.
<nephele>
I don't see any developers disagreeing with me waddlesplash, i talked with john scipone about this and he agreed on the direction
<nephele>
waddlesplash: no, it doesn't have to be dealt with. Let *users* switch to beta5
<nephele>
We are *NOT* a rolling release
<waddlesplash>
we both want *and need* people to be testing nightlies, we don't have the time to do a full QA cycle purely in release candidates
<waddlesplash>
so, that does not work
<nephele>
Uhh, we literally do that already
<waddlesplash>
if nightlies get sufficiently broken that people can't use them anymore, *and remain this way for weeks*, this is a problem
Aedil has joined #haiku
<waddlesplash>
no we do not. And if we did it would just make releases take even longer. Imagine if we had to fix all the inter-release regressions in a release period? That would multiply the time significantly
<nephele>
And sorry, If I am "not allowed" to break nightlies because you are afraid that people will be upset then fuck it. Might aswell search for another project that lets me actually develop the OS instead of blocking me continously
<nephele>
the whole rendering shit would already be done if you haden't blocked this for months based on "yeah this changes colors a bit"
<PulkoMandy>
waddlesplash: There is also double standards, for example big changes to glibc get merged without review
<PulkoMandy>
And yes, if it breaks too much things, reverting is fine. And breaking nightlies is fine because that's where we test things
<waddlesplash>
I left the big glibc changes up for over a week or two with no comments or objections
<waddlesplash>
and if those break, there's nobody to blame but me, and I don't mind if they get reverted
<waddlesplash>
and one of them did have to get reverted in the end
<PulkoMandy>
And you say the responsibility falls on you, but I think that is caused by the review standards making it nearly impossible for other people uo contribute
<PulkoMandy>
I have several changes stuck in review for several years and I'm not alone
<waddlesplash>
again, I am much more stringent about API/ABI-breaking changes than others, and unfortunately the areas nephele wants to work in are mostly that
<waddlesplash>
nephele: yes, I don't think the color changes are necessarily good ones? Independent of any code change, I mean
<waddlesplash>
as I have repeatedly said, if others disagree with me and I am in the minority after all, I will rescind my -2
<waddlesplash>
that goes for any change
<PulkoMandy>
I rarely see you do that
<waddlesplash>
because it rarely happens that a code review has anything besides one -2 from me and one +2 from anyone else
<PulkoMandy>
And how much of a minority do you need when there are maybe 2 people occasionally reviewing changes?
<nephele>
waddlesplash: colors are not part of the ABI or API
<waddlesplash>
no, but they are something everyone sees, so that's even more important than how the code works?
<nephele>
I don't care if you think the color changes are "good" I already explained that this is a changeset with many moving parts, forcing me to cram that into one commit is unreasonable
<nephele>
let me work like i want
<nephele>
everything is still up for review
<nephele>
And, at the end the colors will not change one bit
<waddlesplash>
if it's all going to get merged at once I don't care as much, the point is that even with all changes merged at once, it will still change colors no?
<nephele>
No
sure has quit [Ping timeout: 480 seconds]
<waddlesplash>
nephele: okay, well, if that's the case, I was not clear about that, and your commit message nowhere explains it
<waddlesplash>
it does not say "this changes color behavior but future commits will make things appear the same as before in the end"
<nephele>
Uhh, i spend hours in irc discussing this with you?
<waddlesplash>
PulkoMandy's recent BUrl change was two parts, I think that's fine, I've done similar things
<waddlesplash>
nephele: and as PulkoMandy himself has noted before, IRC is not meant to be permanent, if we don't write down the conclusions of discussions from here they'll get forgotten
<nephele>
and it's irrelevant, it's not yours to block such changes if you just dislike them. Of course the rendering changes. We have *two* set of colors right now, buttons that happen to be rendered like a control, and like a panel
<nephele>
afterwads those will all look the same
<PulkoMandy>
waddlesplash: For Anarchos change on boot drive id, none of the open comments even mention the api/abi change. That would be a valid problem maybe, but it isn't at all what you complained about in the code review
<nephele>
waddlesplash: yes exactly. So why do you think objecting to something on a code review makes sense based on something you did not critizise on the code review?
<nephele>
If you don't like color changes then -1 and ask for clarification
<nephele>
don't -2 my change
<nephele>
It's *very* clear that the primary purpose of that commit is not to change the colors slightly
<Anarchos>
PulkoMandy to be fair, it was someone else who complained about the ABI. But i am not skilled enought to change it, as i put all my change in kernel_platform_args...
<nephele>
waddlesplash: besides, if taking *hours* to explain this to you in irc is not enough. Why do you think it would be better with a non-realtime thing in irc?
<nephele>
in gerrit*
<waddlesplash>
PulkoMandy: 1. has a -1 from x512[m] (and seems to have been dealt with other ways by now) 2. is part of a WIP patch series anyway 3. my -2 as far as I can see is still valid and relevant, the commit message is wrong and that won't work 4. again WIP anyway
<waddlesplash>
nephele: Huh? Why would I not be allowed to block color changes if I dislike them? Again if I am the only one who dislikes them I will back away and let the change go through, but why would I *not* be allowed to veto color changes? There are other changes on Gerrit with -2s for color changes alone, including one to make window borders yellow (jscipione also -2ed that besides me)
nephele has quit [Quit: Vision[]: i've been blurred!]
<waddlesplash>
nephele: And the fact is, in BeOS buttons had a different color than panels. So on that standpoint they should use the control color...
<waddlesplash>
the problem is that our control color is the same as BeOS' but the button color we actually use isn't
<waddlesplash>
so I do agree and have agreed that there is something to fix here
<waddlesplash>
I just don't think it's making buttons use the panel color directly
nephele has joined #haiku
<waddlesplash>
meanwhile Gerrit is acting up and seems to keep restarting, so I can't manage to open Anarchos' change to review the discussion there
<waddlesplash>
I also need to step out the door in a few minutes here and won't be back for some hours
<nephele>
waddlesplash: I spend hours testing and developing that changeset to improve shit
<nephele>
I don't need your backwards justification months later on why you blocked it "I just don't think it's making buttons use the panel color directly"
<waddlesplash>
PulkoMandy: I just checked, the first open comment thread on Anarchos' change clearly states the ABI problem break from me in multiple comments including the second to last.
<nephele>
Don't block my reviews unless there is something seriously wrong with it technically
<PulkoMandy>
waddlesplash: Regarding the sparc change, maybe the change is wrong, but then it's easy to change back later. And without it the kernel is not booting so I don't see what the discussion can be. The hardware/firmware doesn't agree with how you want us to do things, and I won't change the hardware. So, how can I reply to that -2? Besides abandoning the sparc port?
<nephele>
Color changes are not clearly not the purpose of that change, and i explained this again and again and again
<nephele>
and you still have your -2 up
<PulkoMandy>
(Which is what I did, anyways, I have no space to install my t5120 server at home :D)
<waddlesplash>
PulkoMandy: I explained how: any change to where the kernel is located and its address space must also have a corresponding change to the underlying #defines and the user/kernel split
<PulkoMandy>
waddlesplash: Yes, but that can be done later
<waddlesplash>
then for now the solution would be to change the values to be 0s for userland
<waddlesplash>
so that it's clear userland has no address space assigned at all
<waddlesplash>
and can't use the standard 64-bit one other architectures like x86_64 and RISCV use
<nephele>
"nephele: Huh? Why would I not be allowed to block color changes if I dislike them? Again if I am the only one who dislikes them I will back away and let the change go through, but why would I *not* be allowed to veto color changes? "
<PulkoMandy>
That's the main problem here, you want each change to be perfect and not just better than what was there before. This results in very long review time for single patches and confusing discussions, I would prefer to make small changes one at a time
<nephele>
Precisely because of this, If you "back away" that means it wasn't a veto in the first place, but now i had to spend hours discussing this with you
<nephele>
use a -1 to express disagreement
<waddlesplash>
no, I don't want it to be perfect, I just want it to not *obviously break things*; and this change in particular makes the USER and KERNEL ranges totally overlap
<nephele>
uhh, pulkomandy just said it makes the kernel boot
<nephele>
how is that not an improvementß
<PulkoMandy>
waddlesplash: on sparc things do not work that way, the address spaces are separated at a different level (with address space ids) so that doesn't matter
<PulkoMandy>
You just use different instructions when you need to access userspace from the kernel
<waddlesplash>
PulkoMandy: it matters because right now the kernel has no way to distinguish those things any other way than checking pointer ranges. If we need to refactor that fine but at the moment we have no way of distinguishing between kernel or userspace pointers inside the kernel, so the IS_USER_ADDRESS mechanism won't work. And if the change makes it obviously not work then good, but it doesn't
<PulkoMandy>
So, if we ever get there on sparc, much more invasive changes will be needed. Which I can't get into yet because userland isn't running
<waddlesplash>
I replied with a comment noting that USER_BASE and USER_SIZE should just be changed to 0
<waddlesplash>
or 0 and 1 I suppose
<nephele>
"so the IS_USER_ADDRESS mechanism won't work"
<waddlesplash>
that will clear up my objection
<nephele>
waddlesplash: this is future work!
<nephele>
To be done in a future commit
<waddlesplash>
nephele: sure, but the thing is, right now with the way the change works, it LOOKS LIKE it will work
<nephele>
not something to block anything now
<waddlesplash>
I just want it to be made obvious that it won't work
<PulkoMandy>
So, how am I supposed to do this? Continue working on sparc without ever merging anything until I get it running, and submit the patches after that?
<waddlesplash>
no
<waddlesplash>
just make things that are broken and WIP obviously so
<nephele>
Just let PulkoMandy work on the sparc port and stop blocking changes
<waddlesplash>
the problem with our architecture ports is that "this is broken, I'll fix it later" doesn't get documented, and then people have to figure out what is broken from scratch
<PulkoMandy>
I think the entire sparc port is obviously broken...
<nephele>
the sparc port is broken, and it will be broken for the forseeable future
<waddlesplash>
but again, the thing that the commit breaks, *isn't noted*. Right now the change fixes one thing and breaks another but doesn't note anywhere at all that the other thing is broken
<nephele>
waddlesplash: well shit, if nobody can merge anything then it obviously will never get anywhere
<PulkoMandy>
And having patches not merged makes the situation worse
<PulkoMandy>
People try thing, find a bug, and it's "oh actually I fixed this two years ago but it's stuck in review"
<waddlesplash>
it isn't commented, it isn't mentioned in the commit message, and it isn't noted in source code
<nephele>
uhh, it's mentioned in the code review? Assuming you added this to the code review?
<nephele>
That's enough
<waddlesplash>
people don't look at code review when bisecting changes?
<nephele>
Sure I do
<waddlesplash>
they look at code comments, commit message
<nephele>
not my problem if you don't
<waddlesplash>
...
sure has joined #haiku
<waddlesplash>
I don't think gerrit comments should be saved for all time
<waddlesplash>
the commit gets merged, and anything relevant from the comments should be in the commit message at least
<nephele>
They should be, otherwise the "reviewed-on" message is pointless in the commit
<PulkoMandy>
nephele: That's not a good way to go about this. We need better documentation, and we can put some things in commits, but code review is not a good place for documenting things
<nephele>
figuring out how a commit got where it is is relevant
<waddlesplash>
PulkoMandy: well I just reviewed all your changes and those are the only ones where I -2d and nobody else also -2d. So, there may be things stuck in review, but it's not because I -2ed them
<nephele>
PulkoMandy: sure, still not a reason to block anything
<PulkoMandy>
Especially with all the drama going on in the comments there...
<nephele>
improving documentation is additional work
<nephele>
not something that has to block code reviews
<PulkoMandy>
waddlesplash: I did not make any personal attack against you. It's a more general problem, of which I'm also part of
<waddlesplash>
fair enough
<nephele>
also, a comment of "could you add #info to commit message?" In gerrit is *really* easily acomodated
<waddlesplash>
yes, I agree
<PulkoMandy>
nephele: "please add a comment or mention this in the commit message" is not blocking a review, it's a reasonaple comment
<PulkoMandy>
But it is not how that specific review was worded
<nephele>
Sure, if you think something will break, asking for that to be noted is reasonable
<nephele>
but not blocking the review based on something could break for a feature that is broken regardless
<waddlesplash>
look, my comment on PulkoMandy's SPARC change doesn't ask for anything in particular because I don't necessarily want to dictate how it should be fixed. There are any number of routes PulkoMandy could have chosen to deal with that. The one I just suggested and amended the change with a comment is one of them, but there are others, so my original remark just points out the problem with no suggested course of action
<waddlesplash>
if you want me to suggest courses of action more instead of just pointing out problems maybe I should do that
<PulkoMandy>
waddlesplash: So, the wider question is, can we lower the bar a bit for new contributors (even if it means we have to fix or revert things ourselves later), and maybe also for work-in-progress ports and other things that won't affect the nightlies
<nephele>
No, just don't block stuff if you disagree on technicalities. If you think something should be noted, or adressed later. Write that down, but don't block the change because something isn't adresses in that commit
<waddlesplash>
The problem is that oftentimes it seems like when courses of action are suggested then the debate becomes about why not to do them *and* whether the objection is a problem at all
<PulkoMandy>
In these cases I think the cooe is better unfinished and in main git than blocked in review forever
<nephele>
for example for my color stuff, ask for "if you change this then that rendering is different. do you plan to adress that? and if so how?" and then i can explain it
zardshard has left #haiku [#haiku]
<PulkoMandy>
In the past I have tried to adopt the patches and finish them myself, but that's a not of work if I do it for the hundreds of patches out there
zardshard has joined #haiku
<nephele>
and then we can merge the commit that improves the rendering (but does not adjust it everywhere) and i can work on it more. There is *for sure* stuff i will miss with something as complex as rendering, and tickets can then be opened that i can adress
<waddlesplash>
nephele: the change from PulkoMandy in question changes KERNEL address ranges but not the USER ones in the exact same file, and doesn't change the other things that use this code. So, at minimum ,we should have a comment or #warning here, because otherwise this will get forgotten for years until someone spends hours debugging why userland won't start properly, or something. I want to take 30 seconds now and save us hours of work
<waddlesplash>
later on, that's my point
<waddlesplash>
But instead of taking 30 seconds it seems this blows up into big arguments which isn't what I want
<nephele>
okay. Add a comment to please note that in the commit message
<nephele>
waddlesplash: it also blows up into arguments, not because of that specific review, but based on how other reviews went
zardshard has left #haiku [#haiku]
<PulkoMandy>
waddlesplash: And yes, having actionable things in code review (even if just as suggestions) would definitely help
zardshard has joined #haiku
<nephele>
There is severall people who have the idea in their head that they have unjustly gotten a -2 from you, regardless of wether you can justify all of them, this is a systemic problem. Not one of one instance. And it's also not anything you have to defend against. We just have to find a better way to work with each other, since the current way is frustrating for many participants
<waddlesplash>
alright, I can try to remember to always include those if I think of them, or even spend more time thinking to come up with them
<PulkoMandy>
Otherwise, it's confusing, a -2 and it's not clear what to change. And the second part is making sure the demands are not out of proportion [fixing a small bug should not require a huge refactoring, that can be done separately, instead of blocking the merge, create a ticket about it for example?)
<PulkoMandy>
nephele: Also keep in mind that waddlesplash does a lot of reviews so it's expected that a lot of -2 will come from him. Other reviewers may have done the same if they came first
<PulkoMandy>
And once someone has put a -2, adding more -2 on top of it would be bust rude :)
<waddlesplash>
nephele: I think many people here seem to take -2s from me much worse than -1s. Sometimes I take them to be "-1 but persistent until it's manually dropped". That's it. Very rarely do I mean them as "no version of this change should ever be merged." If there was a way to make a "sticky -1", or a way to block changes from being merged until I manually confirmed "yes this version addresses my objections" I would likely use it more
<waddlesplash>
often than -2 itself
<nephele>
Sure you can do that. you can adjust the gerrit rules for when a -1 is transfered
<PulkoMandy>
We can change gerrit config to make -1 sticky
<waddlesplash>
I don't think we want to do that. Having -1s not be transferred is good
<nephele>
the default just happens to be "you uploaded something else"
Anarchos has quit [Quit: Vision[]: i've been blurred!]
<waddlesplash>
I do want some way to have a vote that's negative but automatically cleared on new patchsets
<waddlesplash>
So -1 does have a use
<nephele>
Okay. but primarily they don't work well
<waddlesplash>
It's just that we need something that is 1. persistent and 2. blocks changes
<nephele>
maybe we should have a -3 ;)
<nephele>
it should not block changes neccesarily, that's the point
<waddlesplash>
maybe, but the thing is, I don't know where -3 would get used
<waddlesplash>
But maybe that's the point
<nephele>
I think we should trust each other to not block over objections
<nephele>
not to merge*
<waddlesplash>
having -3 and then it doesn't get used but exists, would still make it clear that a -2 isn't as strong an objection
<PulkoMandy>
waddlesplash: I think the non-stickyness is good. It helps to track if the latest version of a change was reviewedor not
<nephele>
but at the same time it's really annoying to have to ask people time and time again to remove a -2
<nephele>
because there is no way to remove it
<PulkoMandy>
So, what's the point of sticky? Do you not trust the other devs to check that your comments have been sufficiently addressed?
<nephele>
I don't trust drive-by commiters to do this, based on experience
<waddlesplash>
right, that's the thing
<nephele>
as in contributors, not holders of a commit bit
<waddlesplash>
well, I don't know, there are times when things get merged despite -1s
<nephele>
often comment changes also get marked as resolved without the issue beeing adressed
<nephele>
I trust commiters to resolve comment chains when the comments are properly adressed, but then again don't trust contributors to do this :)
<PulkoMandy>
nephele: Yes, but the person re-reviewing should pick that up
<nephele>
it's a bit of a 2 way system like this
<waddlesplash>
right, there are problems there too
<waddlesplash>
anyway, adding a -3 may be a good idea
<PulkoMandy>
And we more or less require someone to give a +2 and someone else to merge (which is already quite a lot, even at my workplace we don't do that)
<nephele>
and then i also *don't* want to add a -2 to contributors, especially new ones, because that feels very discouraging
<waddlesplash>
okay how about this
<waddlesplash>
-2: This must not be merged as-is
<waddlesplash>
-3: This should never be merged
<waddlesplash>
Right now -2 is "This shall not be merged"
<PulkoMandy>
I don't think the numbers are really the problem here
<waddlesplash>
no, but the text accompanies the numbers
<waddlesplash>
So I am suggesting to add -3 and change the text for -2
<waddlesplash>
Alternatively we can just change the text for -2 without adding -3
<PulkoMandy>
That's just the default comment, which hopefully people do not leave as-is when making reviews
<PulkoMandy>
But sure, we can change the default comment
<nephele>
as in -2 is sticky in "the concept can be OK but requires re-review for a new commit"
<PulkoMandy>
Not sure gerrit can have a -3 however
<waddlesplash>
PulkoMandy: no it's not just that. It shows up on every change if you hover over -2
<nephele>
PulkoMandy: no, that's the explanation text for the -2 stuff
<waddlesplash>
and in emails and other places
<PulkoMandy>
Ok, yes, the ui changed since I last looked carefully
<nephele>
I think gerrit is nice, but we really need to adjust it (or fork it) to make it work better for us... :)
<nephele>
or make our own
<PulkoMandy>
So yes, then we should make that more friendly
<waddlesplash>
let's amend the change and see if we can make jscipione happier
<PulkoMandy>
Ok les me adjust that one...
<waddlesplash>
so here's another thing, I would not mind if there is some way for -2s to be removed by someone *besides* the owner of the patchset
<waddlesplash>
that is, there's a way for some other reviewer to override a -2
<PulkoMandy>
Admins can do that I think
<PulkoMandy>
(At least I can)
<waddlesplash>
yes
<nephele>
I have no objections. Mind making a ML post waddlesplash?
<waddlesplash>
but at the moment admins don't do this without "serious reasons" or something
<nephele>
Then we can see that other devs are also fine with that
<PulkoMandy>
Yes, it's more a process/documentation thing than a technical one
<waddlesplash>
I could, but I think we should just introduce -3 or something and then make -2 able to be overridden
<waddlesplash>
So we don't need to get other devs to agree necessarily
<PulkoMandy>
I don't think gerrit allows more values
<waddlesplash>
though we do need to inform them
<nephele>
No, but we should get them to agree... the ML post should outline how we got here, and maybe have a bit of a discussion there on how we can improve our workflow
<nephele>
and that be one suggestion
<waddlesplash>
PulkoMandy: "
<waddlesplash>
Additional entries could be added to label.Code-Review.value to further extend the negative and positive range, but there is likely little value in doing so as this only expands the middle region.
<waddlesplash>
"
<waddlesplash>
from Gerrit docs
<nephele>
anyway, besides all that. waddlesplash can you unblock the appearence change and control background color?
<PulkoMandy>
What does "could" mean here?
<nephele>
funnily enough the appearence change has a valid comment from korli, but he didn't -2 ... :)
<waddlesplash>
nephele: The Appearance change deserves -2 to remain because of the copying code, as I noted
<waddlesplash>
I will remove that once the copied code is deleted
<PulkoMandy>
Is it "you can do it but it's useless" or "we considered it but we didn't make it possible because it's useless"?
<waddlesplash>
PulkoMandy: "By default a submit-requirement is created that requires at least one MAX vote on this label and no MIN votes to enable submission."
<nephele>
I assume the way gerrit does these things that it should be possible
<waddlesplash>
I think this means, we can configure a submit-requirement by which both the MIN (-3 in this example) and -2 as well block merging?
<waddlesplash>
instead of MIN (-2 at present) only
<nephele>
waddlesplash: I won't merge the patch without adressing that. It still should not have a -2
<PulkoMandy>
Yes, looks like custom submit requests is the thing
<nephele>
If i upload something new I am stuck waiting for your review while other developers could do a re-review just aswell
<PulkoMandy>
I'm not sure about the extra levels, I'd say this just makes things more confusing
<PulkoMandy>
nephele: As waddlesplash said, this is fine if we officially allow people to remove someone else's -2
<nephele>
yes, but currently I cannot
<nephele>
and semantically before we change this meaning (to make it clear this is OK) a -2 is still a dont't ever merge this
<PulkoMandy>
Then we move the fighting and frustration between existing contributors and away from the person who submitted the patch
<waddlesplash>
PulkoMandy: "For every configured label My-Name in the project, there is a corresponding permission removeLabel-My-Name with a range corresponding to the defined values. For these values, the users are permitted to remove other users' votes from a change."
<waddlesplash>
* -2 also blocks merging but has different text
<waddlesplash>
* anyone of Committers except change owner can remove -2
<PulkoMandy>
I don't see the point of -3
<PulkoMandy>
If the change is completely garbage, bust abandon it
<waddlesplash>
it would make clear that there is a vote "beyond -2", and that -2 is not the most serious possible vote
<nephele>
I can't abandon other peoples changes
<waddlesplash>
if -3 rarely or never gets used, that's fine
<waddlesplash>
it's still doing it's job
<nephele>
PulkoMandy: in the idea here a -3 is the "big bad weapon", so we make -2 more usefull, because it *isn't* a -3
<waddlesplash>
but maybe you are right and we should start with the second two changes for now
<PulkoMandy>
I think just changing the text for -2 is enough
<waddlesplash>
eh, I tend to agree with PulkoMandy here
<nephele>
Should we allow developers to abandon other peoples changes?
<waddlesplash>
if a -2 is really a "-3" in that the person adding it wants the change to never be merged, they should just say that
<PulkoMandy>
And people can be "big weapon" or encouraging in their review comments
<waddlesplash>
nephele: I can do that, but I guess it must be an admin function
<nephele>
for example the bc thing is stuck in review, because i didn't think it is a good idea. and Habbie said i could abandon it for him then, but i cannot do this
<PulkoMandy>
Don't blame the button values, spend some time being nice in review comments instead :)
<Habbie>
ah
<Habbie>
i don't care who abandons it; i just assumed somebody could :)
<nephele>
i changed my -2 to -1 so another dev could merge it over my objection, but now this is still in review
<nephele>
Habbie: well, you can ;)
<Habbie>
yes i can
<Habbie>
(i assume)
<nephele>
PulkoMandy: okay ;)
<PulkoMandy>
I'm trying to find how to change the permission for removing -2
<waddlesplash>
PulkoMandy: I think you add removeLabel-Code-Review to access "refs/heads/*"
<waddlesplash>
after the existing label-Code-Review entries for Contributors
<waddlesplash>
you may be able to add two entries, one for Contributors and the other for "Change Owner", to stop change owners from deleting -2 on their own changes
<waddlesplash>
I am not sure how you would refer to Change Owner here but Gerrit docs seem to indicate that it should be possible
<nephele>
you mean developers? or does gerrit call developers contributors?
<waddlesplash>
nephele: "Contributors" is the name of the group that we ourselves created in Gerrit to manage commit access
<waddlesplash>
it's just a group
<nephele>
oh, though the about box calls it maintainers, and everyone else contributors
<nephele>
waddlesplash: i was confused because the about box calls everyone without commit access contributors
<waddlesplash>
I suppose that is confusing indeed
<waddlesplash>
oh well, changing this in Gerrit now would be quite annoying
<PulkoMandy>
I trust contributors enough that they can remove -2 votes on their own changes
<waddlesplash>
I suppose that's also sensible enough
<PulkoMandy>
(Abuse of that will result in losing contributor status)
<waddlesplash>
at the moment, -2 removal in my head is "admin function, do not touch"
<nephele>
developers can also "just" push directly... so not a new level of trust really
<nephele>
waddlesplash: it would be good to get some people to review your libc changes in any case, even if that takes a bit longer... to remove a bit of the bus factor ;)
<waddlesplash>
well, before I started working on the glibc stuff, I think the "bus factor" was 0 as I didn't understand this stuff either
<nephele>
code review is great to learn about new areas by asking stupid questions on code review
<waddlesplash>
well, the changes were open for weeks, nobody stopped you from reviewing and asking stupid questions! :P
<waddlesplash>
for that matter, if you want to still ask questions, go ahead
<waddlesplash>
nephele: if you (or anyone else) wants to learn by asking questions about commits then they should absolutely do so. If it's you or another contributor maybe preface the questions with "asking to learn" or something to make clear you aren't really "belatedly reviewing", but by all means
<waddlesplash>
PulkoMandy: reviewed. But it also looks like there is a merge conflict that needs to be resolved here
<waddlesplash>
Rebase didn't help
<nephele>
I am a bit discouraged of reviewing your changes tbh. Too much the idea that it will be a pointless fight then. But sure, i can preface with asking to learn or something ;)
<waddlesplash>
well, as I have stated before, I don't think any fights I pick are pointless
<waddlesplash>
of course others are likely to disagree in many cases...
<waddlesplash>
but I mean it when I say I don't set out to be "disagreeable", I just care highly about quality
<PulkoMandy>
It should not be a fight
<nephele>
The thing is, not everything has to be perfect. sometimes stuff is merged that i don't like either. But if i have to fight you on everything you don't like this really does not help my motivation
<nephele>
If we go route A and you like it that is smooth sailing, but if i want to do it another way I have to fight about it, doesn't seem nice.
<nephele>
Quality on the commit level should not be as important as you make it out to be
<waddlesplash>
my goal, in general, is for my reviews to not just correct the code but also improve how we developers think about the code
<nephele>
it's very fine to have incremental improvements
<nephele>
that't fine, sure. And if you have suggestions they are very welcome. But it shouldn't always be a "this is wrong, do it this way -2" but a "Hmm, I would probably do it like this instead, I'm wondering why you choose this route"
<waddlesplash>
in other words I don't just reply thinking "here is how the code needs to be fixed", but I usually also have in mind that I want to explain my rationale enough so the other developer can see it, and see how I came to that conclusion, and in the ideal case, if I am correct, recognize that and adopt some of my suggestions in their thought processes and not just the code itself
<nephele>
sometimes two paths are really equivalent, and fighiting is extremely pointless aswel
<waddlesplash>
And I do the same when other people review my code
<waddlesplash>
or try to anyway
<nephele>
like some of the changes about replacing the depreacted FindInt stuff, where the original code did no error checking, so replacing it is pointless
<nephele>
but at the same time not replacing it is pointless too
<nephele>
so if someone wants to add the non-deprecated variants, okay fine. it may be pointless but there is no grounds to block it on
<nephele>
(you didn't block that, was just an example ;)
<nephele>
waddlesplash: anyhow, remove the -2 on the control colors please. Your comment was just "Why not just change BControl itself?" and that is not a reason to block it, just one other possible implementation path...
<nephele>
and different rendering will be adressed... in subsequent commits
<nephele>
assuming i can get my stupid computer to even boot
<waddlesplash>
nephele: 1. my -2 there means basically what I have iterated it means here, and 2. you don't have those commits uploaded yet, so my -2 stands: it should not be merged at a minimum till those other changes are present
<nephele>
I vehemently disagree
<PulkoMandy>
A thing we've been doing at work is clearly marking comments that are important and should be adressed, and other ones that are just suggestions for later or minor things
<nephele>
I don't want to work on a huge diff to master
<nephele>
Let me merge these, even if the renderign changes. if i can't break anything in the nightlies i can't get anything done
<nephele>
and sorry, but color changes are simply not a breaking change that will make the nightlies unusable for anyone, which was your argument before
<nephele>
(and as i said, these will be fixed later on)
<nephele>
PulkoMandy: in seperate comment threads?
<waddlesplash>
nephele: What is the value of merging this change and changing colors now? What advantage does it have? Why not just wait till the other changes are uploaded and merge them all at once?
<nephele>
Because I have 0 motivation to work on shit if you block it
<nephele>
and besides, i need these in the nightlies to have people test it
<nephele>
I assume there are many apps that hardcode wrong colors for controls, or the wrong color constant, and those only get exposed through testing
<PulkoMandy>
nephele: usually it's inline comments in the code, either with a clearly identifiable word ("optional:" or "nithicking:" or whatever) or just the wording ("would have been nice if...")
<nephele>
PulkoMandy: would be good to add, maybe you can write a post about how that works as a reference? (or is that basically it? :)
<PulkoMandy>
But also maybe consider writing a ticket with future improvements instead of a review comment when it gets too far from the original change's purpose
<waddlesplash>
nephele: The first part of your answer only tells me why I should remove -2, not why it should be merged. And I fail to see how this can be tested as-is for hardcoded colors, because if the later change will switch up color constants again, how will anyone figure out which apps did or didn't have hardcoded colors?
<waddlesplash>
So I don't think that justification makes sense
<PulkoMandy>
I thing Google core review guidelines have some explanation on this
<nephele>
uhh, you just compare the rendering? it's not hard
<nephele>
and yes, you should remove the -2. irrespective of wether you think this version should be merged. You don't have a good justification for it beeing there
<nephele>
I don't want to be forced to implement an arbitrary set of commits you think are "good enough" before i can get my stuff reviewed and merged
<nephele>
and i don't want to work on a huge diff to nightlies
<nephele>
besides, that commit *literallly* includes the change to the rendering AND the control look source color
<nephele>
so by itself this will not change the rendering
<waddlesplash>
so it does. I hadn't re-reviewed because you had been arguing back and forth with jscipione and I figured I would just wait until you both worked that out
<nephele>
which by the way, was one of those things i only added because you kept complaining about it. I still think this is pointless since we have color generation code, and i don't like having to change this *back* in the next version just so this is somehow consistent
<nephele>
uhh, john did not -2 my review. you did
<nephele>
because if i change this now, and want to change it back later, i forsee another big fight about it
<waddlesplash>
nephele: I am looking through the review comments and don't see where you say that the new version of the patchset keeps appearance as-is
<waddlesplash>
It appears to do that but I didn't notice because I was probably reading comments and not the code
<nephele>
It sais that. John sais it changes the rendering, and i disagreed with that statement
<nephele>
and again, it does not matter. even if it did change the rendering that is *no* justification to block this change
<nephele>
because of that stupid requirement there is this workaround in this commit for flat button styles. instead of going the *proper* way of adjusting the controllook api for this stuff
<nephele>
just remove the -2 and let me break the rendering, by structurally improving our code...
<waddlesplash>
the "workaround" seems like it may just be correct code anyway, and not a workaround? But I didn't review that API in detail
<nephele>
No, it's definetely a workaround, and will break as soon as the haikucontrollook rendering is fixed
<waddlesplash>
replied again, my -2 is now solely about the commit message
<nephele>
" but I didn't spend too much time thinking about that." good reason for a -2
<nephele>
Yeah. No. I'm not going to work on this at all
<waddlesplash>
nephele: that part isn't why I made a -2
<waddlesplash>
the first part is
<waddlesplash>
I thought that would be clear, but maybe I need to use something more specific like PulkoMandy was saying above, "optional: " or whatever
<nephele>
Oh, you agree on a vague statement about "something"? cool. cool. I'm not adding random thoughts about this stuff in the commit message
<nephele>
there are tickets for that
<waddlesplash>
Then reference the tickets?!
<nephele>
And that is literally why i told you that these changes are too big for one commit
<waddlesplash>
"Part of #...."
<waddlesplash>
Right now the commit message says NOTHING about any of that
<nephele>
So what?
<waddlesplash>
So, we try to have commit messages explain what is going on, and why, or at a minimum point to where those explanations are given?
<nephele>
No reason to block this
<waddlesplash>
a lack of explanation in a commit message for a change that alters things like this? Yes, that's a reason to block it
<nephele>
No, it's on you to explain what you think is unclear. The commit message sais what the commit does
<nephele>
And no. I don't care. I'm not going to work on this if you block it.
<waddlesplash>
commit messages aren't just for explaining what the commit does!!
<nephele>
Yes they are
<waddlesplash>
they're for explaining WHY do that
<waddlesplash>
"Fixes #xxxx" or "Part of ticket #xxxx" is often enough explanation, because the ticket has all the actual details
<nephele>
Oh? then why don't all your change glibc -> musl changes explain in detail why you think these should be done?
<waddlesplash>
they do?
<nephele>
Mostly not. Mostly they explain what
<waddlesplash>
if my explanation is incomplete, or doesn't make sense, then that's what reviews are for
<nephele>
And no, i don't need to justify my changes in a commit message, that is what code review is for
<waddlesplash>
nephele: PulkoMandy above disagreed with you I think
<waddlesplash>
and I disagree with you
<nephele>
and i don't see the need to explain *obvious* things. If they are not obvious it is on you to explain what you think is unclear
<PulkoMandy>
nephele: the commit message is the only thing that will be safely stored
<nephele>
controls use control rendering is pretty straightforward
<waddlesplash>
if we need to bring this to the mailing list and amend the Coding Guidelines in order to make clear what the expecations are here, then fine
<fancy2209[m]>
<waddlesplash> "and without changing anything in..." <- I applied y0nga's patches
<nephele>
if you think this is unclear then put into the review what you think is unclear or want explained
<nephele>
don't dump a "yeah this somehow could be better" on me
<PulkoMandy>
If we move out of gerrit someday for example. And generally Haiku has few documentation and comments, but the commit message make up for it
<nephele>
PulkoMandy: that's not my point. I've never explained commits like "Fix IK test <blah>" either. And this change sais in the topic line what it does. Nothing more, if something is unclear it has to be said *what* is unclear in the review
<nephele>
i can't work with some vague comments about *something* beeign explained. Why? what is unclear?
<waddlesplash>
nephele: there is still context and history to why controls don't use control rendering. Did BeOS do this? Why did Haiku do it this way? What does this patch leave undone, that will need to still be done in the future? Those are all questions that someone reading this patch will have (or at least I had them). So, the commit message should either give the answers directly, or indicate where they can be found. If that's "Part of
<waddlesplash>
#xxxx", then presumably that ticket will answer the questions. Maybe instead it's "See inline comments" because all the answers are in inline comments. But no matter what, the commit message really needs to explain or point to where the explanation is.
<nephele>
If you have questions then fucking write them on the review!! don't make me drag them out of you on irc
<waddlesplash>
if the problem was that you didn't know what specifically I was asking for then just say that
<nephele>
i did, severall times
<waddlesplash>
Your first reply to my comment was "I'm not doing this"...
<waddlesplash>
not "I don't know what you want explained"
<waddlesplash>
I will add another comment then
<nephele>
you added a vague comment about something beeing wrong. Not nice. There is nothing actionable in that message, and it is seriously annoying to continously get -2 for such things
<nephele>
And no, i'm not going to merge that version as is. I will rework it and remove the other stuff. And if you want I can make you an overview ticket
<nephele>
But I won't do that if you continously -2 my reviews
<nephele>
I'm not going to add BeOS history to it however. I don't care how BeOS did it. We have a BeOS control look, and it already does this by hardcoding panel colors. It's not related to how we do it
<waddlesplash>
nephele: I would think that there are literally hundreds of examples of how we write commit messages in Haiku, and a short comment noting that your change does not do what we expect should suffice. If you want specific suggestions for what that should be I am happy to give them, but I didn't say anything specific at first because it's just "the stuff we usually do"
<waddlesplash>
I write commit messages like this, PulkoMandy writes commit messages like this, etc.
<nephele>
I write commit messages "like this" aswell. I did not think there was anything unclear there.
<nephele>
If you disagree, explain why.
<waddlesplash>
nephele: and no, sorry, but you need to add BeOS history here. We still preserve BeOS ABI compatibility, and this changes things that BeOS ABI will see, so we need to be clear about how this is, or is not, related to that.
<PulkoMandy>
The abi compatibility for buttonecolors is already broken since the introduction of ui_color
<waddlesplash>
And if the answer is "we don't care about what BeOS did here and here's why", then *that should be part of the commit messages*
<nephele>
uhh, no. This does not change ABI compatibility. decorators are not a ABI thing. And the haikucontrollook rendering is a self-made problem
<nephele>
in fact decorators often crash the app_server because their ABI is not stable. we should improve that. But this isn't about that. And there have already been ABI breaking changes in this nightly release cycle concerning decorators
<waddlesplash>
Decorators are totally unrelated here, I agree
<waddlesplash>
but the ui_color() method will now return a different color. So the point is, do we care about that?
<waddlesplash>
I think PulkoMandy is correct, we don't care what BeOS did here, we already broke ABI there
dalme has joined #haiku
<nephele>
I don't think so, no. Because a) this is already broken in relation to whatever BeOS did and b) the other goal, allowing other decorators to be developed seems much more important to me
mmu_man has quit [Ping timeout: 480 seconds]
<waddlesplash>
if I was doing this change I would say that in the commit message ("The ... change already broke ABI vs. BeOS so this doesn't matter") but I suppose that's not strictly a requirement
<nephele>
We have the BeOS style decorator aswell though, and it bypasses this completely by hardcoding the panel color
<nephele>
so if you want the same rendering, it will give you this
<waddlesplash>
Anyway that is only one of the things I was wondering about
<waddlesplash>
There are other questions besides BeOS ABI
<nephele>
okay, add them to the code review, and if they are relevant to the commit and unclear I can explain them
<nephele>
To me this is not unclear. But I also can't see from the outside what is unclear for other people
<nephele>
waddlesplash: but regardless, I want to trim this commit down to a functional one. Then do the same thing for more commits. And I want this to break the rendering intermiddently.
<nephele>
Can I do that without you -2ing all my changes...?
<waddlesplash>
nephele: I copied my remarks above into a new comment
<waddlesplash>
of course you understand the change; you made it lol
<nephele>
Yes, but i also understand the context of what still needs to be done. I can understand that i need to communicate this better, but it's at the same time very frustrating to have to justify functional changes in isolation, even if the change itself makes sense...
<waddlesplash>
nephele: I don't know what you mean by "functional one". If the change as-is keeps button rendering as-is, at least on the default install, then my only remaining objection is the commit message. If you want to break it up into multiple commits and merge them one at a time, I suppose that's also fine
<nephele>
No, I mean. this does not acomplish the goal of what we need
<waddlesplash>
nephele: Well, I always try to justify functional changes in isolation?
<nephele>
this commit
<nephele>
There are severall more commits required
<nephele>
and having to have this one be "fully functional" means i have to revert parts of it in later commits
<waddlesplash>
Yes, and without having seen them, or at least a clear description of exactly what the changes entail, then I don't know what vote I will or won't give?
<nephele>
which makes it really hard to develop
<waddlesplash>
why is that hard? I do that sometimes
<waddlesplash>
"making a change now that will get reverted later" is something I have done when making changes like this
<nephele>
So basically: 1) Controllook rendering of buttons needs to be adjusted 2) control color changed 3) decorator ABI changed to pass panel color
<waddlesplash>
so I am not asking you to do anything that I myself haven't done
<nephele>
4) color generation code adjusted
<nephele>
5) default colors adjusted based on output of color generation code
<nephele>
waddlesplash: sure, but this is really difficult to work with. And I just don't want to. I can understand if you want to work like that, but it's not for me
<nephele>
and again, we are allowed to break nightlies. and this will change rendering slightly for severall commits
<nephele>
And no, the end result will not be the same rendering. because currently different controls render differently. But it will be the same everywhere, and the buttons will look the same if you pick the apropriate colors for it
<waddlesplash>
I don't understand what is "really difficult"
<waddlesplash>
it looks like you have about 10 lines of code and some comments added because of this?
<nephele>
Having to make each commit functional where they really aren't
<waddlesplash>
why is that hard to delete?
<waddlesplash>
nephele: okay, then the other option is, to make all the changes in a series, and not merge any till the set is complete
<nephele>
This is supposed to be one commit in a chain, this one should *only* change the controls to use control colors
<nephele>
No, it isn't
<nephele>
Just stop blocking my changes based on it changing the rendering
<waddlesplash>
you keep saying that, it doesn't convince me any more
<waddlesplash>
*than saying it the first time
<waddlesplash>
(i.e. it's not convincing)
<nephele>
if you can't agree to do that i will just not work on it.
<nephele>
I don't care if you are "convinced" or not. I can break the nightlies, that is in our social contract. If i can't do this i can't develop this stuff. And if you won't let me then i will simply not develop stuff for Haiku
<waddlesplash>
I don't get it. I asked you to not change the rendering. You changed the commit so that it doesn't change the rendering. I think the change is now basically fine and only needs a better commit message, and maybe a few minor tweaks to comment wording, to be merged
<waddlesplash>
But now you say you don't want to do it this way after you already did it...?
<nephele>
Yes, because of your nonsense requirements this commit took weeks instead of one or two days. I could have moved on and fixed the rest already
<waddlesplash>
well, I am sorry that I missed that you amended the change to address my original comment. That's partially on me
<nephele>
That's on you for wrongfully blocking it in the frist place
<waddlesplash>
I don't know what I can say here at this point. I don't think I was wrong to do that. We are allowed to break the nightlies if we need to, yes, but I didn't see any reason why we needed to, and your additions to the change make it so that nightlies are not broken, or at least, not nearly as broken as they would've been at first, in the interim
<nephele>
It literally does not matter if *you* think this is justified or not
<nephele>
you are not the arbitar of this
<waddlesplash>
I am a developer with a vote same as you, what makes my vote invalid?
<nephele>
You are allowed to break the nightlies. You are not allowed to block *everyone* based on this alone, untill they have justified themselves to you
gouchi has quit [Remote host closed the connection]
<nephele>
This commit will break the nightlies, i need this to work properly on this. Done. Now unblock the change, and don't block my future ones for colors
<waddlesplash>
I routinely offer to pick up the "extra work" I suggest is necessary, and I can make that offer here
<waddlesplash>
But it sounds like your objection is to having any code in the tree at all for this "workaround"
<nephele>
Think of it this way, would it be okay if i were to add -2 to *every* of your commits that might block something? untill you justified to me, in detail, why you think you really can't make the commit not break the nightlies?
<waddlesplash>
"might"?
<waddlesplash>
it DOES change things
<nephele>
The workaround is bad. And I have to remove it in the next commit. And you will add this insane requirements to my future commits
<waddlesplash>
nephele: Or, how about you think of it this way: Suppose I didn't have a -2, and instead let you merge the change, and then when I got annoyed at the broken button rendering, I made the workarounds myself and committed them directly
<nephele>
So, no. I don't want to work with way
<waddlesplash>
Would that make you happier?
<waddlesplash>
Because I can do that instead
<nephele>
not really. I would apreciate you would work with me instead of against me. If you need the nightlies to work for you, you can revert the change locally
<nephele>
or we can work with branches
<waddlesplash>
Okay and me arguing with you in the Gerrit replies *IS* how I am trying to work with you directly?
<waddlesplash>
So what do you want here? I can ignore your changes till they're merged, and then apply workarounds to make them not break stuff, or I can point out the problems in review and wait for the workarounds to get added
<nephele>
I don't want you to "fix" stuff intermiddently, because these changes are complex, and i need to work on them one at a time. It doesn't work if you undo my work
<waddlesplash>
I didn't say "revert" I said "workaround"
<waddlesplash>
and I'm sorry, but you *definitely* don't have any right to break stuff in the nightlies *and stop other people from fixing it*
<nephele>
Again, no. Then i have to constantly clean out your workarounds
<nephele>
You can't make every commit work on it's own waddlesplash
<nephele>
I make a commit A) this will fix a code flow, but break the rendering
<waddlesplash>
no, but I can make most every *push* work on its own
<nephele>
then i make commit B) this will fix a code flow, improve the rendering, and break it in another place
<nephele>
This is way too complex to fix in one commit
<nephele>
and i'm tired of you blocking shit based on this
<waddlesplash>
we can ask other developers to weigh in here, but if you change something user-visible, and I, who am also a user as well as a developer, am annoyed, and I apply a workaround so that the original rendering is restored until you complete future fixes, you can't say I am not "allowed" to do that
<nephele>
I'm not going to make every single commit a standalone perfect version
<nephele>
Sorry waddlesplash, but at some point, if you do that. you are simply running a one man show
<waddlesplash>
???
<waddlesplash>
okay, would you like me to create survey posts on the forums?
<nephele>
if i break stuff, in order to improve it in the future, you have to let me work on the fixes
<nephele>
wow. argument from mob mentality. That is sure to convince me
<waddlesplash>
I simply do not accept that I am in any way obliged to "leave things broken"
<waddlesplash>
we can ask other developers but I think this idea is frankly ridiculous
<nephele>
Either you get to block all my stuff, or you can revert it immidiently? wow. So basically I am banned from the project
<waddlesplash>
I did not say that
<waddlesplash>
I said that I would *apply workarounds*. And the workarounds you have already applied in the commit for this particular change. So there's nothing I even need to do for this one
<nephele>
waddlesplash, I think we should talk over some voice chat about this. We are clearly talking around each other
xet7 has joined #haiku
<waddlesplash>
that could be a good idea
<waddlesplash>
but I don't know how much we are talking around each other, it seems like we have some fundamental disagreement here, and I don't know that more dialogue will resolve that
<waddlesplash>
PulkoMandy may have a comment, but we may need to talk to other developers and amend project policies
<nephele>
I think you are missing the point i want to convey, or not seeing my point of contention
<nephele>
I don't want to ammend project policy
<waddlesplash>
nephele: You have a series of changes you want to make. This series of changes is best done as multiple commits. From before the first commit to after the last, the rendering of controls in the default Haiku control look with the default system colors will remain identical. However for intermediate changes it will change because of shifting around where colors are picked and what the color constants are. You want to work on this
<waddlesplash>
series of changes incrementally and merge it incrementally.
<waddlesplash>
That's my understanding of what your position is. The logical consequence of which is, that during the phase the changes are being made, control renderings WILL be visibly different (wrong)
<waddlesplash>
I think this simply does not make sense, that we should avoid breaking things on the nightlies temporarily if we can help it, and in this case we absolutely can help it. I am willing to do a bit of extra work so you have less in order to avoid breaking things in the middle, but you don't like that either. You also don't want to wait to merge them until the whole series is complete.
<PulkoMandy>
You want my comment? That means I need to gather emotional energy to read your heated discussion, again...
<nephele>
I send you a query waddlesplash
<nephele>
No, let me just talk with voice over waddlesplash
<waddlesplash>
PulkoMandy: Just read the last 3 minutes
<nephele>
reading that is pointless. we are clearly not understanding each other
<nephele>
and it's not an issue that is to be "weighed in"
<waddlesplash>
nephele: I think any one of those other options is a fine route to take including the ones that are more work for me, but you do not. You think that it is acceptable to break things during changes, in ways that anyone who uses nighlies will see, and that other developers can't, or shouldn't, change this
<nephele>
waddlesplash: i send you a querry
<waddlesplash>
nephele: Is my summary in any way wrong?
<waddlesplash>
I see it, but in all honesty I would greatly prefer to have this argument in public, not in private
<nephele>
I would not. Because this isn't an argument
<nephele>
and you don't have to make a fight out of everything
<waddlesplash>
Have I correctly summarized your position?
<nephele>
I'm not going to engage with that waddlesplash. My position is "stop -2ing all my changes"
<waddlesplash>
I don't -2 all your changes, this is quite clear
<PulkoMandy>
nephele: you will only find someone else to -2 or revert things if there is breakage
<nephele>
This is a circular argument, either I can have intermittend breakage, or i can't
<PulkoMandy>
So I'm not sure what your issue is here. Is your main point that having nightlies temporarily broken is ok? If so, how much broken is acceptable? If this is just about buttons having the wrong color, maybe it's ok
<PulkoMandy>
But can we talk about that instead of focusing on who voted -2?
<nephele>
My issue is with all my future changes, in this space, beeing treated like this one was.
<PulkoMandy>
If you want a clear rule, then yes, you can't have intermittent breakage if you know beforehand.
<PulkoMandy>
Intermittent breakage may happen accidentally in nightlies and things will either get quickly fixed, or reverted
<nephele>
That means I can't do any of these changes unless i do huge patchsets that change everything all at once
<waddlesplash>
PulkoMandy: I agree, and I think that if necessary we should make that official policy
<PulkoMandy>
If you intentionally merge things that are broken, people are going to put pressure on you to fix it quickly, or revert it. Which is why we have gerrit in the first place
<nephele>
that goes pretty much against your previous position of "if it improves things it's fine"
<waddlesplash>
nephele: No, you can do a series of patches?
<PulkoMandy>
nephele: breakage does not improve things
<waddlesplash>
both I and PulkoMandy have plenty of times pushed patches to Gerrit and added a -2 to our *own change* saying "don't merge, breaks X" and then later added the changes to fix X
<nephele>
I don't see how so PulkoMandy. The end rendering will be different in some cases, but i need this to be applied so people can test where this breaks in addition
<PulkoMandy>
hence my question which I have not seen an answer to: what exactly would be broken? Is it just about buttons having the wrong color?
<nephele>
Many changes in this serious would have buttons have a *slightly* wrong color on the light mode
<nephele>
Untill the last patch is then applied
<waddlesplash>
What value is there in intermittent testing where things break "in addition"?
<waddlesplash>
Why not just ask that after everything's merged?
<nephele>
because this makes it very clear where other apps are broken
<nephele>
because you can now test this in a straightforward way
<waddlesplash>
But *how are we supposed to know that* if the colors aren't finalized yet?
<waddlesplash>
If the system colors will be changed in the end, then what apps are or are not broken will change too
<nephele>
the finialized colors are a product of the code, not the other way around
<waddlesplash>
right, so, there's no way to determine what's broken or not until all the code changes are done?
<nephele>
you can change the control color in appearence to some wierd color to see which apps do not obey the color
<waddlesplash>
But that's already true now
<waddlesplash>
So what's the difference?
<nephele>
no, because conrols did not use the control color
<PulkoMandy>
Ok, so, the breakage is rather small, and may be ok. Next question: do we have ways to do this that cause less disruptions? And also, what is the balance of work here? It seems reviewing your changes by small pieces at a time is difficult because we don't get the "big picture"
<waddlesplash>
Okay. So right now everything's broken
<waddlesplash>
So what's the difference, again? Let's fix it all at once rather than breaking things one at a time
<waddlesplash>
PulkoMandy: +1
<PulkoMandy>
In that cae, submitting a complete patch series may make more sense for review. Or just say that the first patcheis part of a work-in-progress
<nephele>
I don't want to have to do everything on my own either, this is complex sure. But I don't want to have to fix every app in src/apps/ for example in the same commit, where others could do aswell
<PulkoMandy>
Also I note that madmax's bot provides test builds of every changes, that would be usable if you want other people to test it
<waddlesplash>
nephele: and I said that I'm happy to help work on such changes
<waddlesplash>
if you get to a point where it's just apps remaining to be fixed, and Interface Kit is totally complete, I certainly can help with that
<PulkoMandy>
in that case, is it possibne to fix the apps first, and merge the "core" changes later?
<waddlesplash>
probably not because the control color that we currently have set in the system is wrong
<nephele>
No, because that changes the rendering, and that's not allowed apparently
<nephele>
waddlesplash: okay. So should i give you a task, to "offload" that?
<nephele>
i'm not sure how to best work on a series on gerrit together
<waddlesplash>
sounds like a good time to learn!
<waddlesplash>
but yes, as PulkoMandy says, we have madmax's bots now for asking users to test random changes
<PulkoMandy>
You make multiple commits and push them for review together (I use git push HEAD:refs/for/master to push my patch series, basically push the latest commit in the series)
<nephele>
Okay. One task to unload would be, to remove the workaround that is annoing me in this patch. src/kits/interface/Button.cpp:157 and following. This uses some complex chain to determine which color to send to the controllook. This is wrong, instead the API of the controllook has to be changed so that the controllook gets both the panel and the control color and can decide on it's own what to use for rendering
<PulkoMandy>
They appear in gerrit as a "relation chain", and can be reviewed individually, and merged together or in parts
<nephele>
this is because the "flat" button renders as a panel color, but on Hover it will switch over to the control color
<PulkoMandy>
Then to change them you can use "git rebase -i origin/haiku" and use git interactive rebase to edit each commit
<waddlesplash>
nephele: mh, shouldn't a Flat button render nothing?
<waddlesplash>
or is that not possible
<waddlesplash>
I mean the whole idea is that a Flat button should have the same color as the parent view
<waddlesplash>
In which case we should not pass in the panel color, BControlLook should *itself* use view->Parent()->LowColor()
<waddlesplash>
because the parent low color may not be the panel color, maybe it's 00FF00 or whatever
<nephele>
Yes, if you want you can also change it that it gets only the control color and leaves the parent alone, or asks it to redraw
<waddlesplash>
that sounds like the more sane thing to do yes
<nephele>
I'm not sure how this interacts with the control look api, but feel free to investigate
<waddlesplash>
OK
<nephele>
i can't boot my computer. I have this stupid gpu
<fancy2209[m]>
is there a way to compile haiku's kernel with symbols so that kdl shows function names?
<fancy2209[m]>
I wanna see the bt
<fancy2209[m]>
s/bt/backtrace/
<PulkoMandy>
I think it is by default, but the powerpc disassembler may not know how to use them, or they may not be loaded this early in the boot process
lubo76kubuntu has quit [Remote host closed the connection]
<Habbie>
i've seen symbols (on x86_64) on a trace with 'vfs_mount_boot_file_system', just as a data point
<Habbie>
(that's four icons)
janking has quit [Quit: Vision[]: i've been blurred!]
<Habbie>
fancy2209[m]'s last trace looks a bit earlier
<fancy2209[m]>
yeah I am at 0 icons turned on
<Habbie>
kernel stack: 0x00000000 to 0x00000000
<Habbie>
this is interesting
<Habbie>
if true
<fancy2209[m]>
I got a full log from qemu thanks to nographic
<waddlesplash>
fancy2209[m]: you're too early in the boot to get stack trace methods with names
<fancy2209[m]>
<nephele> "that is, if nobody is around..." <- opening a ticket about a unfinished port that is not actively worked on felt wrong
AlienSoldier has joined #haiku
<nephele>
why? you are working on it right now?
<janking>
can anybody help me this? KERN: [net/realtekwifi/0] [54:af:97:c8:04:65] erp change: was 0x104, now 0x106
Aedil has quit [Quit: leaving]
AndrevS has quit [Quit: umount /dev/irc]
<nephele>
I uploaded a change to change the public decorator api, to remove two big things... if anyone is interested in that, feel free to review it :)
<fancy2209[m]>
<nephele> "why? you are working on it right..." <- yes, I am trying to debug it
<fancy2209[m]>
I am just trying to understand what's happening right now since I am not very Haiku knowledgeable
<fancy2209[m]>
<waddlesplash> "fancy2209: you're too early in..." <- i see, thans
<nephele>
fancy2209[m]: yes, but there is no problem with opening a ticket against the port. even if it is broken
tigerbrother has quit [Quit: Ping timeout (120 seconds)]
tigerbrother has joined #haiku
poopnugget142 has joined #haiku
HaikuUser3 has joined #haiku
<HaikuUser3>
Is there (or will there ever be) a port of Mini vMac for Haiku?
<nephele>
what is mini vMac? HaikuUser3
<HaikuUser3>
macintosh plus emulator
<HaikuUser3>
68k mac*
<nephele>
It doesn't look like there currently is a port
<HaikuUser3>
oh
<nephele>
Maybe It can be ported
<nephele>
one api they support is libsdl2, we have that available, so it would be an option
jmairboeck has quit [Quit: Konversation terminated!]
HaikuUser3 has quit [Quit: Vision[]: i've been blurred!]
<nephele>
if there will be a port depends on if someone has the time/motivation to do it, i think
<nephele>
in any case you can create a ticket at the haikuports repository on github, if you have a github account, and request it to be ported. or ask in the forum topic on our forums
<fancy2209[m]>
<nephele> "fancy2209: yes, but there is..." <- where should I open the ticket?
mmu_man has quit [Ping timeout: 480 seconds]
<nephele>
why do you keep quoting stuff so wierdly?
<Habbie>
nephele_jabberfr, that quoting is what the matrix-to-irc bridge does when somebody uses 'reply'
<fancy2209[m]>
<nephele> "why do you keep quoting stuff so..." <- Matrix replies bridged to IRC
<Habbie>
it might be better for us if you don't use the reply function
<Skipp_OSX>
arg
<fancy2209[m]>
> Habbie: it might be better for us if you don't use the reply function
<fancy2209[m]>
Prefer if I do it like this?
<fancy2209[m]>
* > Habbie: it might be better for us if you don't use the reply function\
<fancy2209[m]>
Prefer if I do it like this?
<fancy2209[m]>
* > Habbie: it might be better for us if you don't use the reply function
<fancy2209[m]>
Prefer if I do it like this?
<fancy2209[m]>
i was using reply just cause it's what i'm used to
coronavirus has quit []
<poopnugget142>
I have 2 questions. 1. Does haiku support multiple monitors? 2. This is more of a computer question but my computer only has 1 vga cable ouput is there anyway to hook up 2 monitors still or no?
<PulkoMandy>
Haiku has limited support for multiple monitors on a few videocards from the early 2000s, nothing current