| Time |
Nick |
Message |
| 00:04 |
|
diemartin joined #minetest-dev |
| 01:33 |
|
kaeza joined #minetest-dev |
| 01:48 |
|
diemartin joined #minetest-dev |
| 01:55 |
|
blaaaaargh joined #minetest-dev |
| 02:14 |
|
Zeno` joined #minetest-dev |
| 02:15 |
|
kaeza joined #minetest-dev |
| 02:17 |
* Zeno` |
slaps kaeza with a large trout. |
| 02:18 |
kaeza |
ow |
| 02:18 |
kaeza |
sorry about frequent reconnects; stupid mobile network decides to time out every 15 mins |
| 02:19 |
Zeno` |
Maybe it's sleepy |
| 02:26 |
|
diemartin joined #minetest-dev |
| 02:41 |
|
kaeza joined #minetest-dev |
| 02:46 |
|
kaeza left #minetest-dev |
| 02:52 |
|
RealBadAngel joined #minetest-dev |
| 02:53 |
* RealBadAngel |
yawns |
| 02:53 |
RealBadAngel |
whats up folks? |
| 02:54 |
VanessaE |
hi |
| 02:54 |
RealBadAngel |
VanessaE, hi, i managed to fix texture glitches with parallax |
| 02:55 |
VanessaE |
told you :) |
| 02:55 |
VanessaE |
tape the edges together :) |
| 02:55 |
RealBadAngel |
i did |
| 02:55 |
RealBadAngel |
but mods will have to tell the shaders if they are using non tiling texture |
| 02:58 |
RealBadAngel |
https://imgrush.com/QnUp3FBFt1qF.png |
| 02:58 |
VanessaE |
I saw it |
| 02:59 |
RealBadAngel |
and? |
| 02:59 |
VanessaE |
looks good |
| 03:00 |
VanessaE |
except there's this one little glitch ... right...there. |
| 03:00 |
* VanessaE |
points at a random spot along a random edge ;) |
| 03:00 |
RealBadAngel |
dont even try ;) |
| 03:01 |
RealBadAngel |
i got rid with it of enable and disable images |
| 03:02 |
VanessaE |
how's that work? |
| 03:03 |
RealBadAngel |
wrote a neat piece of code that generates textures with flags on the fly |
| 03:03 |
RealBadAngel |
http://pastie.org/10274997 |
| 03:04 |
RealBadAngel |
atm it only sets one flag, but makes adding new ones trivial |
| 03:08 |
RealBadAngel |
and tape n glue code: http://pastie.org/10275002 |
| 03:09 |
VanessaE |
brb |
| 03:10 |
RealBadAngel |
first of all it offsets texture with maximal parallax value, depending on the angle which makes glitch less visible |
| 03:10 |
RealBadAngel |
then freezes 1% of the texture near the edges |
| 03:11 |
RealBadAngel |
above code is for case the texture is tileable on x, but non tileable on y, like dirt with grass |
| 03:13 |
Zeno` |
__shaderFlagsTexture1 is a valid string? |
| 03:13 |
RealBadAngel |
for the code to work, nodedefs will have to set tile properties |
| 03:13 |
RealBadAngel |
Zeno`, ofc it is |
| 03:14 |
Zeno` |
I mean... hmm, how to put it |
| 03:14 |
RealBadAngel |
put where? |
| 03:14 |
Zeno` |
If another flag was added what would it look like? |
| 03:14 |
Zeno` |
I mean I'm not sure how to phrase my question :) |
| 03:14 |
RealBadAngel |
__shaderFlagsTexture1011101101 for example |
| 03:14 |
Zeno` |
ah ok |
| 03:14 |
Zeno` |
cool |
| 03:15 |
RealBadAngel |
ofc having 8 flags passed will require 256 textures |
| 03:15 |
RealBadAngel |
but thats not that costly |
| 03:16 |
RealBadAngel |
8 flags case will require 1kb of memory for the textures |
| 03:18 |
RealBadAngel |
not that much, and im able to pass whatever flags i do need per tile, without further shaders instancing |
| 03:18 |
Zeno` |
Oh each is a texture. I get it now |
| 03:19 |
RealBadAngel |
http://pastie.org/10275012 |
| 03:19 |
RealBadAngel |
this is what i do with it inside shader |
| 03:20 |
Zeno` |
yep, I understand now. Makes more sense when seen in context |
| 03:21 |
RealBadAngel |
adding next flag will be just setting and reading pixel at pos (1, 0) |
| 03:22 |
VanessaE |
have you tested this with Havel et al. yet? |
| 03:22 |
RealBadAngel |
didnt have to, normalmaps are 256x |
| 03:23 |
VanessaE |
er Haven* |
| 03:24 |
RealBadAngel |
if you will take a closer look you will see that pixels in the row next to edge (i mean "pixel" sized from 16x16 originals) is slightly bigger than those one in the middle |
| 03:24 |
RealBadAngel |
geometry of bump for it is not deformed |
| 03:27 |
RealBadAngel |
but to notice you would need to walk around and pick an angle |
| 03:28 |
RealBadAngel |
propably best seen when lookin at texture with an zero angle |
| 03:32 |
RealBadAngel |
next thing is how we will define tiling in nodedefs |
| 03:34 |
RealBadAngel |
seamless will be propably default value, so such nodes will remain unaffected |
| 03:34 |
RealBadAngel |
but dirt with grass for example, |
| 03:37 |
RealBadAngel |
http://pastie.org/10275029 |
| 03:49 |
RealBadAngel |
bbl |
| 03:49 |
VanessaE |
freeze |
| 03:50 |
VanessaE |
you can't go nowhere :) |
| 03:58 |
Zeno` |
I'm Ma Baker! |
| 04:01 |
|
sloantothebone_ joined #minetest-dev |
| 04:02 |
|
prozacgod joined #minetest-dev |
| 04:54 |
|
kaeza joined #minetest-dev |
| 04:57 |
|
jin_xi joined #minetest-dev |
| 05:13 |
|
nore joined #minetest-dev |
| 05:52 |
|
Hunterz joined #minetest-dev |
| 06:07 |
|
RealBadAngel joined #minetest-dev |
| 06:09 |
|
OldCoder joined #minetest-dev |
| 06:30 |
|
Calinou joined #minetest-dev |
| 06:46 |
|
AnotherBrick joined #minetest-dev |
| 07:28 |
|
diemartin joined #minetest-dev |
| 07:35 |
|
johnnyjoy joined #minetest-dev |
| 07:36 |
|
werwerwer joined #minetest-dev |
| 07:48 |
|
asl97 joined #minetest-dev |
| 08:00 |
|
Yepoleb_ joined #minetest-dev |
| 08:26 |
|
Krock joined #minetest-dev |
| 08:45 |
|
Darcidride joined #minetest-dev |
| 08:52 |
|
blaze joined #minetest-dev |
| 08:56 |
|
Amaz joined #minetest-dev |
| 10:19 |
|
Taoki joined #minetest-dev |
| 11:12 |
|
diemartin joined #minetest-dev |
| 11:58 |
|
RealBadAngel joined #minetest-dev |
| 12:08 |
|
julienrat joined #minetest-dev |
| 12:21 |
|
proller joined #minetest-dev |
| 12:27 |
|
msantana joined #minetest-dev |
| 12:43 |
|
julienrat left #minetest-dev |
| 12:45 |
|
SopaXT joined #minetest-dev |
| 13:14 |
|
sloantothebone joined #minetest-dev |
| 13:20 |
|
est31 joined #minetest-dev |
| 13:24 |
|
Darcidride joined #minetest-dev |
| 13:27 |
|
julienrat joined #minetest-dev |
| 13:33 |
est31 |
here it is #2889 |
| 13:33 |
ShadowBot |
https://github.com/minetest/minetest/issues/2889 -- Client: better m_proto_ver initialisation by est31 |
| 13:33 |
est31 |
the only point where that value is actually read is "Client::sendChangePassword", where a check with < or > 25 is done |
| 13:34 |
est31 |
and I think you are not abled to change your password on just test server because of this bug |
| 13:35 |
est31 |
the other point is src/guiFormSpecMenu.cpp |
| 13:35 |
est31 |
to check whether we are abled to send a movesomewhere inventory action |
| 13:35 |
est31 |
(in proto < 25 that didnt exist) |
| 13:36 |
est31 |
it even didnt exist for a long time with protocol 25, but I didn't want to bump the protocol just because of that |
| 13:45 |
est31 |
kahrl, can you look at it now? storm should have reached you too by now, with cooler air :) |
| 13:49 |
est31 |
btw, hmmm won, I wont push anything to master anymore |
| 13:50 |
est31 |
I will create dozens upon dozens of pull requests instead |
| 13:50 |
est31 |
going the formal way |
| 13:50 |
est31 |
master will be a dead branch |
| 13:50 |
est31 |
but I dont give a fuck anymore |
| 13:57 |
|
Robert_Zenz joined #minetest-dev |
| 13:58 |
|
jin_xi joined #minetest-dev |
| 14:53 |
|
hmmmm joined #minetest-dev |
| 15:26 |
RealBadAngel |
est, hmmmm have you seen my proposal> |
| 15:26 |
RealBadAngel |
? |
| 15:29 |
RealBadAngel |
whatever, i know its a masterpiece |
| 15:37 |
|
giacomo986 joined #minetest-dev |
| 15:45 |
|
julienrat left #minetest-dev |
| 15:57 |
|
OldCoder joined #minetest-dev |
| 16:02 |
|
CraigyDavi joined #minetest-dev |
| 16:02 |
|
proller joined #minetest-dev |
| 16:08 |
|
ElectronLibre joined #minetest-dev |
| 16:10 |
|
Amaz left #minetest-dev |
| 16:13 |
|
proller joined #minetest-dev |
| 16:15 |
|
Lunatrius joined #minetest-dev |
| 16:37 |
|
AnotherBrick joined #minetest-dev |
| 17:06 |
Tesseract |
Fine if I push this to master?: http://ix.io/jwa/diff |
| 17:07 |
Tesseract |
(GetValue is unsafe because the value can change between the two calls, resulting in a long wait) |
| 17:08 |
Tesseract |
It seems the semaphore's just used as a "something's ready" variable instead of a resource counter. |
| 17:10 |
Tesseract |
And MinimapUpdateQueue is just a MutexedQueue it seems... |
| 17:11 |
Tesseract |
This is not how semaphores are supposed to be used. |
| 17:13 |
|
est31 joined #minetest-dev |
| 17:13 |
est31 |
"And MinimapUpdateQueue is just a MutexedQueue it seems..." |
| 17:13 |
est31 |
yes ^ |
| 17:13 |
est31 |
also true to your "variable" thing |
| 17:13 |
est31 |
comment* |
| 17:14 |
est31 |
I'd have used a binary semaphore if we had one |
| 17:14 |
Tesseract |
JEvent |
| 17:14 |
est31 |
but I don't see, how can it be dangerous? |
| 17:14 |
Tesseract |
Moment. |
| 17:14 |
est31 |
JEvent is just a thin wrapper around the normal semaphore, and doesnt do that emptying |
| 17:15 |
est31 |
so if you call deferupdate() twice, it will need two wait() calls to get "blocking" again |
| 17:15 |
est31 |
perhaps it uses a "real" event on windows though |
| 17:16 |
Tesseract |
est31: http://pastebin.ubuntu.com/11831810/ |
| 17:16 |
est31 |
there is only one thread accessing that |
| 17:17 |
Tesseract |
Also, GetValue is *VERY* slow and hacky on OSX (the other reason I removed it) |
| 17:17 |
est31 |
minimap update thread |
| 17:17 |
est31 |
you can remove the whole while loop, its not needed |
| 17:17 |
est31 |
its only there to spare multiple traversions through doUpdate() |
| 17:18 |
Tesseract |
est31: Yes, Event isn't quite right on Linux, but it should be fixed rather than another hack used. |
| 17:18 |
est31 |
if we called deferUpdate before |
| 17:18 |
Tesseract |
The semaphore should be a counter of the units that need to be processed. |
| 17:18 |
est31 |
Tesseract, I havent looked at how it was done on mac or win (isnt there only a posix implementation, linux and mac unified?), only linux |
| 17:18 |
est31 |
no |
| 17:19 |
est31 |
thats wrong |
| 17:19 |
Tesseract |
Why? |
| 17:19 |
est31 |
what if you call to stop the thread? |
| 17:19 |
est31 |
then it either waits until a new element comes in |
| 17:19 |
est31 |
or you will have to raise the semaphore counter |
| 17:20 |
est31 |
which is wrong when you look at it the "element counter" way |
| 17:20 |
Tesseract |
"action counter" then, with a stop action. |
| 17:20 |
est31 |
also, minimapupdate thread does some other business too, not just the queue stuff |
| 17:21 |
est31 |
deferUpdate gets called when you change minimap modes for example |
| 17:22 |
Tesseract |
Just push a "change mode" event to the queue. |
| 17:22 |
est31 |
a stop action should be served right now |
| 17:22 |
est31 |
shouldnt be hidden in a queue |
| 17:22 |
est31 |
just like change of mode |
| 17:22 |
Tesseract |
Then push to the front of the queue. |
| 17:23 |
est31 |
its no queue then anymore |
| 17:23 |
Tesseract |
deque then. |
| 17:23 |
Tesseract |
It would be nice if we could make this lock-free with the semaphore though. |
| 17:23 |
est31 |
? |
| 17:24 |
Tesseract |
The current method uses a locked queue. |
| 17:25 |
est31 |
yes, you wont get rid of that |
| 17:27 |
est31 |
I think we even have a queue with a semaphore somewhere |
| 17:27 |
est31 |
still uses a lock |
| 17:28 |
est31 |
what if two threads want to put something into the queue? |
| 17:28 |
est31 |
same time |
| 17:29 |
est31 |
so, I agree, you can replace the queues with mutexed queue |
| 17:30 |
est31 |
for mesh and for minimap threads |
| 17:30 |
est31 |
also, you can use JEvent |
| 17:30 |
Tesseract |
est31: You make sure that the actual insertion is atomic. |
| 17:31 |
est31 |
Tesseract, and by what? by using a lock. |
| 17:31 |
est31 |
I dont know how I would implement a thread safe insertion routine elsehow |
| 17:31 |
Tesseract |
est31: 1-word loads/stores are atomic on most architectures. |
| 17:32 |
est31 |
also, you said before you want to put stuff at the front too. |
| 17:32 |
Tesseract |
Yes, that part will make it a lot harder. |
| 17:32 |
est31 |
Tesseract, which data structure do you want to use? std::deque? is that one thread safe for insertions? |
| 17:34 |
Tesseract |
deque will definitely need a lock. We'd need a custom data structure. |
| 17:34 |
est31 |
I dont see a benefit in forcing *everything*, even stop events into the queue. |
| 17:34 |
Tesseract |
The lock probably isn't a big issue though. |
| 17:34 |
est31 |
whats wrong about updatethread? |
| 17:35 |
Tesseract |
For now I'll just fix that loop and maybe switch to MutexedQueue. |
| 17:35 |
Calinou |
maybe you want a fade effect |
| 17:36 |
est31 |
Tesseract, I dont see any need to fix here. |
| 17:36 |
est31 |
its more a cleanup |
| 17:37 |
est31 |
the only case that loop can be dangerous is how hmmmm said it, when the production is so fast even that while loop can't empty the semaphore fast enough |
| 17:37 |
Tesseract |
est31: The MutexedQueue thing, yes. |
| 17:37 |
est31 |
yes that should be fixed probably |
| 17:37 |
Tesseract |
Unless you have 2+ consumers. |
| 17:38 |
Tesseract |
Although that may or may not be possible. |
| 17:38 |
est31 |
yes, but right now we only have one. Its called UpdateThread not updateThreads |
| 17:38 |
Tesseract |
Regardless, we won't be able to keep it with my threading fixup. |
| 17:38 |
est31 |
why? |
| 17:42 |
est31 |
Ah I see you removed the count getter |
| 17:42 |
est31 |
well, then make it wait(0) instead |
| 17:43 |
Tesseract |
est31: Just look at how GetValue was implemented on Windows and OSX. On OSX it was actually a global counter for all semaphores! |
| 17:43 |
est31 |
eww |
| 17:44 |
est31 |
thats a reason I accept |
| 17:49 |
|
MinetestForFun joined #minetest-dev |
| 17:50 |
est31 |
also, feel free to fix jevent, and use that then |
| 17:50 |
* est31 |
is still wondering how Tesseract wants to make an atomic queue insert. |
| 17:51 |
est31 |
I mean there are different steps here: |
| 17:51 |
est31 |
1. update the "last element" pointer of the queue |
| 17:51 |
Tesseract |
est31: Search for "lock-free queue". |
| 17:51 |
est31 |
err no |
| 17:52 |
est31 |
0. store the "last element" pointer of the queue |
| 17:52 |
est31 |
then 1. |
| 17:52 |
est31 |
then 2. add your new "last element" to the "next" pointer of your stored "last element" |
| 17:53 |
est31 |
if you do 2. before 0, you get in trouble |
| 17:53 |
est31 |
if you do it this way, you get in trouble too |
| 18:01 |
est31 |
confirmed, some dude on the internet actually claims to have found a way. I have to read it later |
| 18:01 |
est31 |
well some dude on the internet can claim alot of stuff |
| 18:02 |
est31 |
it has to be read and understood in order to be confirmed |
| 18:02 |
est31 |
which happens "later" |
| 18:02 |
est31 |
cye |
| 18:02 |
est31 |
cya* |
| 18:14 |
|
Wuzzy joined #minetest-dev |
| 18:48 |
|
proller joined #minetest-dev |
| 20:13 |
|
Amaz joined #minetest-dev |
| 20:24 |
|
selat joined #minetest-dev |
| 20:49 |
|
paramat joined #minetest-dev |
| 20:51 |
|
est31 joined #minetest-dev |
| 20:51 |
paramat |
hi hmmmm, please could you review this later? #2890 |
| 20:51 |
ShadowBot |
https://github.com/minetest/minetest/issues/2890 -- Mgv7: Auto-set lowest mountain generation level by paramat |
| 20:52 |
hmmmm |
yea i'll take look |
| 20:52 |
hmmmm |
busy atm |
| 20:52 |
hmmmm |
sorry |
| 20:53 |
est31 |
so hmmmm we finally want to the second server |
| 20:53 |
est31 |
err |
| 20:54 |
est31 |
what I wanted to say was "so hmmmm we finally want to remove rule 1" |
| 20:55 |
est31 |
I mean paramat lives without rule 1 very fine too |
| 20:55 |
est31 |
he even does PRs. |
| 20:57 |
hmmmm |
rule 1? |
| 21:00 |
|
JZTech101 joined #minetest-dev |
| 21:11 |
paramat |
no problem hmmmmm |
| 21:20 |
paramat |
commit rules i guess. erm, i possibly might be a sort-of second mapgen maintainer, and am the maintainer for mgv7 and the current biome API. so yes i sometimes commit alone |
| 21:43 |
|
est31 joined #minetest-dev |
| 21:52 |
|
kaeza joined #minetest-dev |
| 22:02 |
|
err404 joined #minetest-dev |
| 22:14 |
|
paramat left #minetest-dev |
| 22:47 |
|
diemartin joined #minetest-dev |
| 22:48 |
hmmmm |
est31: i would have to argue that many of paramats commits fall under a trivial exception |
| 22:48 |
hmmmm |
they're usually just adjusting a parameter or something - adjusting mapgen parameters might make new maps look a tad uglier, but they're not going to blow up the entire engine |
| 22:49 |
hmmmm |
he's definitely allowed to take control of the artistic direction for mapgen v5 and v7 - i am not actively working on v7 and v5 was his to begin with |
| 22:49 |
est31 |
I didnt knew paramat uses the first rule too, I have used him as example that you can live without it |
| 22:50 |
est31 |
(wrongly) |
| 22:50 |
hmmmm |
i don't know the rules by their numbers |
| 22:50 |
est31 |
"trivial rule" |
| 22:50 |
hmmmm |
i just know what most people agree to at some point |
| 22:50 |
hmmmm |
the trivial exception, you mean |
| 22:50 |
est31 |
yes |
| 22:51 |
hmmmm |
it's not so much a rule as it is an allowance to not totally bring engine development to a halt |
| 22:51 |
est31 |
at least you admit |
| 22:51 |
hmmmm |
and I'm not liking it as of recently because trivial needs to be better defined |
| 22:51 |
hmmmm |
it's being used as an excuse rather than respected |
| 22:52 |
est31 |
even if you commit something seemingly trivial, it can blow up |
| 22:54 |
est31 |
the problem with PRs is, that they usually don't get merged even the same day. |
| 22:55 |
est31 |
some of them stay open for months, even if they do fall under the triviality rule |
| 22:55 |
hmmmm |
we're working on clearing it out |
| 22:56 |
hmmmm |
we'll do another PR clear-out session tomorrow maybe |
| 22:57 |
est31 |
do you want to remove the "trivial" rule? |
| 22:57 |
hmmmm |
i'd like to define it better |
| 22:58 |
hmmmm |
ugh |
| 22:59 |
hmmmm |
it would be so nice to write a lint-like tool to detect if changes are non-trivial or not |
| 22:59 |
est31 |
? |
| 22:59 |
hmmmm |
well I can tell you which changes are trivial |
| 22:59 |
hmmmm |
- changing a comment |
| 22:59 |
hmmmm |
- changing code style |
| 22:59 |
hmmmm |
- renaming variables |
| 22:59 |
hmmmm |
- changing numeric variables of noise parameters |
| 23:00 |
hmmmm |
what else.. |
| 23:00 |
est31 |
for example, do you think that this was trivial: https://github.com/minetest/minetest/commit/96989e0a6aa3ab069b5aeeab44a6280d6d51364a |
| 23:00 |
hmmmm |
- changing constant strings |
| 23:00 |
hmmmm |
that are meant for display |
| 23:00 |
est31 |
what about #2889 is that trivial? |
| 23:00 |
hmmmm |
yes, i would consider that trivial |
| 23:00 |
ShadowBot |
https://github.com/minetest/minetest/issues/2889 -- Client: better m_proto_ver initialisation by est31 |
| 23:01 |
hmmmm |
that one, no |
| 23:01 |
hmmmm |
absolutely not |
| 23:01 |
est31 |
you know where that variable is used? |
| 23:01 |
hmmmm |
doesn't matter! |
| 23:01 |
est31 |
yes its touching the network |
| 23:01 |
hmmmm |
such a change could have dire effects |
| 23:01 |
est31 |
but you shouldnt be scared of it |
| 23:01 |
hmmmm |
well it's not trivial |
| 23:01 |
est31 |
its used at two places |
| 23:02 |
hmmmm |
i wouldn't know that it's harmless unless I looked deeper into the code |
| 23:02 |
hmmmm |
i.e. not trivial |
| 23:02 |
est31 |
I wouldn't know that for mapgen parameter changes either |
| 23:03 |
est31 |
changing a siggle number can mean everything is stone now |
| 23:03 |
est31 |
single* |
| 23:03 |
hmmmm |
so, true |
| 23:03 |
hmmmm |
maybe, then... |
| 23:04 |
hmmmm |
any changes that modify the functionality are non-trivial, unless you're a subject matter expert in that part of the code |
| 23:04 |
est31 |
^ |
| 23:04 |
|
werwerwer joined #minetest-dev |
| 23:04 |
hmmmm |
then, it's possible that changes to the functionality may possibly be considered trivial |
| 23:08 |
|
Niebieski joined #minetest-dev |
| 23:08 |
est31 |
perhaps we can adopt a multi-branch development model http://mozilla.github.io/process-releases/draft/development_specifics/ |
| 23:08 |
|
cvtsx1 joined #minetest-dev |
| 23:09 |
est31 |
they bind "pushing features" to the lower branches to releases, we dont have to |
| 23:09 |
est31 |
also they have multiple branches, we can only have two |
| 23:09 |
est31 |
"unstable" and master |
| 23:10 |
est31 |
one branch where we can merge PRs to, and non-trivial smaller fixes |
| 23:10 |
est31 |
still can be tested by people |
| 23:10 |
hmmmm |
call me cynical, but wouldn't that just encourage everybody to move to the unstable version |
| 23:10 |
est31 |
another branch which is more stable, stuff only gets merged when its stable |
| 23:11 |
est31 |
well they know then what they are into |
| 23:12 |
est31 |
this wouldn't make creating bugs not a "how could you?" every time. bugs happen, you have to fix them, not be too frightened to make changes because you want to avoid every bug. |
| 23:12 |
est31 |
-not |
| 23:13 |
hmmmm |
alright |
| 23:13 |
hmmmm |
we could try it |
| 23:13 |
hmmmm |
anyway i'm more afraid of people shit-committing poor quality code |
| 23:13 |
hmmmm |
it might work but it's extremely sloppy |
| 23:13 |
hmmmm |
and because it's committed, people think it's done, and that's that |
| 23:14 |
est31 |
if its shitty code, we dont push it "lower" |
| 23:14 |
hmmmm |
but it might interfere with others' commits |
| 23:14 |
|
kaeza joined #minetest-dev |
| 23:15 |
est31 |
most times this isnt the case, but you are right, we have to find a good way to deal with this |
| 23:15 |
hmmmm |
like... |
| 23:15 |
hmmmm |
keep each new feature in its own branch? |
| 23:15 |
hmmmm |
8) |
| 23:15 |
hmmmm |
like we already do? |
| 23:16 |
est31 |
its hard for people to test it |
| 23:16 |
est31 |
my approach would make more PRs open to testing |
| 23:16 |
est31 |
from people |
| 23:17 |
est31 |
we have few devs to review code, but lots of folks who like trying new stuff, buggy or not |
| 23:18 |
hmmmm |
well |
| 23:18 |
hmmmm |
we'll try it out i guess |
| 23:18 |
est31 |
take cheapie's bug for example |
| 23:19 |
est31 |
#2815 |
| 23:19 |
ShadowBot |
https://github.com/minetest/minetest/issues/2815 -- Texture corruption |
| 23:19 |
cheapie |
Ah, that one... |
| 23:19 |
est31 |
it took one day after it got reported |
| 23:19 |
cheapie |
The one that is supposedly "by design". |
| 23:21 |
est31 |
it was #2810 |
| 23:21 |
ShadowBot |
https://github.com/minetest/minetest/issues/2810 -- Remove textures vertical offset. Fix for area enabling parallax. by RealBadAngel |
| 23:22 |
est31 |
a fix I think for the earlier parallax mapping changes |
| 23:23 |
est31 |
also take my utf changes |
| 23:23 |
est31 |
in the start, they created alot of regressions |
| 23:23 |
est31 |
I had to examine them one by one |
| 23:24 |
est31 |
there are still many open |
| 23:24 |
est31 |
its a change where its hard to oversee everything |
| 23:25 |
hmmmm |
so why does it have to be pushed before it's ready is what i'm wondering |
| 23:26 |
est31 |
well if its hard to review, you will need to test instead |
| 23:26 |
est31 |
its hard to replicate all possible combinations |
| 23:27 |
est31 |
and sometimes you even discover unrelated bugs, that now get exposed more |
| 23:27 |
|
diemartin joined #minetest-dev |
| 23:28 |
hmmmm |
well alright then |
| 23:29 |
hmmmm |
I just don't want this super unstable branch to become a cesspool where people dump their poop |
| 23:29 |
hmmmm |
there needs to be some standard of quality there |
| 23:29 |
est31 |
agreed |
| 23:31 |
est31 |
what would be a good method in your opinion? one dev to agree on it? one dev regardless whether proposed by themselves or sb else? its still less than three like for PRs submitted by devs |
| 23:32 |
hmmmm |
not three, just two people /other/ than yourself |
| 23:32 |
hmmmm |
having your own vote count is quite deceptive |
| 23:33 |
est31 |
it works for politicians |
| 23:33 |
est31 |
;) |
| 23:48 |
|
blaaaaargh joined #minetest-dev |
