Minetest logo

IRC log for #minetest-dev, 2013-12-30

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

Time Nick Message
00:00 EvergreenTree joined #minetest-dev
00:14 blaaaaargh joined #minetest-dev
00:14 Miner_48er joined #minetest-dev
00:18 blaaaaargh joined #minetest-dev
00:25 Miner_48er joined #minetest-dev
00:35 john_minetest left #minetest-dev
00:51 Miner_48er joined #minetest-dev
02:03 sapier left #minetest-dev
02:40 OWNSyouAll joined #minetest-dev
03:03 kaeza joined #minetest-dev
03:03 VanessaE fwiw:  kizeren and I are now using sapier's fork, server_improvement branch for testing.  Thus far, the on-join lag with non-cURL clients seems to have been fixed, and server CPU load during the initial non-cURL media fetch is much improved.
03:04 VanessaE ( https://github.com/sapier/min​etest/tree/server_improvement )
03:04 VanessaE this makes a total of 6 servers that are using this branch.  only been testing for a couple of hours yet, so too early to say if it's good enough for general audiences.  Just a heads-up.
03:23 us_0gb joined #minetest-dev
04:06 VanessaE joined #minetest-dev
04:06 OldCoder joined #minetest-dev
04:08 ShadowNinja kahrl: Does this look good? http://ix.io/9zo
05:38 NakedFury joined #minetest-dev
05:44 smoke_fumus joined #minetest-dev
06:59 mrtux joined #minetest-dev
07:13 darkrose joined #minetest-dev
07:13 darkrose joined #minetest-dev
07:13 kahrl ShadowNinja: I think key should be a signed integer type
07:14 kahrl how (in)efficient is repeatedly calling std::vector::reisze?
07:14 kahrl resize*
07:14 kahrl other than that it looks good to me
07:15 kahrl maybe for consistency change the Server* srv to Server *srv while you're at it :)
07:16 kahrl sapier: #1070 seems good, you can merge it if you want
07:16 ShadowBot https://github.com/minetest/minetest/issues/1070
07:17 * kahrl brbs
08:46 VanessaE joined #minetest-dev
10:13 proller joined #minetest-dev
10:46 blaaaaargh joined #minetest-dev
10:53 NakedFury joined #minetest-dev
10:54 iqualfragile joined #minetest-dev
11:12 Evolykane joined #minetest-dev
11:41 VargaD_ joined #minetest-dev
12:00 werwerwer joined #minetest-dev
12:03 robmyers__ joined #minetest-dev
12:05 mrtux joined #minetest-dev
12:06 us{0gb joined #minetest-dev
12:07 VanessaE Is there some logical reason why there is no simple, basic /kick command?
12:07 VanessaE for minetest servers I mean
12:08 VanessaE it seems like the equivalent of killing a fly with a bazooka to have to /ban and then immediately /unban just to boot someone from the server
12:08 us{0gb joined #minetest-dev
12:14 ImQ009 joined #minetest-dev
12:32 blaaaaargh joined #minetest-dev
12:35 elmux joined #minetest-dev
12:37 elmux Is there any possibility for entitys to have a inventory ?
12:41 celeron55 they do
12:43 celeron55 umm wait... do they
12:43 celeron55 yes they do
12:43 celeron55 ObjectRef:get_inventory()
12:46 celeron55 IIRC there could be some issues in getting those to be shown in inventory views; feel free to report bugs
12:50 elmux thx
13:00 Jordach joined #minetest-dev
13:44 Evolykane joined #minetest-dev
13:45 Jordach joined #minetest-dev
14:07 werwerwer_ joined #minetest-dev
14:50 daswort joined #minetest-dev
15:03 zat joined #minetest-dev
15:04 Zeitgeist_ joined #minetest-dev
15:04 Zeitgeist_ joined #minetest-dev
15:22 Weedy_lappy joined #minetest-dev
15:30 proller joined #minetest-dev
15:32 kaeza joined #minetest-dev
15:35 Jordach joined #minetest-dev
15:38 ShadowNinja std::vector::resize should be pretty fast, unfortunately this will cause double-initializations, with the advantage that it will assume empty slots are empty itemstacks.  I thought about using a signed type, must have not done that.
15:43 nore joined #minetest-dev
15:47 Weedy joined #minetest-dev
15:56 jojoa1997 joined #minetest-dev
16:03 PilzAdam joined #minetest-dev
16:14 EvergreenTree joined #minetest-dev
16:14 EvergreenTree joined #minetest-dev
16:16 EvergreenTree joined #minetest-dev
16:32 Calinou joined #minetest-dev
16:59 hmmmm joined #minetest-dev
17:11 ShadowNinja Should be ready now: http://ix.io/9A6 I'll push it soon if nobody objects.
17:12 ShadowNinja And I guess we're not in a feature freeze now, so http://ix.io/9A7 can be considered. (I'll make it into a PR soon)
17:23 ShadowNinja And http://ix.io/9A9 is an alternative to #1074 that has the server create the world directory rather than having the RollbackManager handle that.
17:23 ShadowBot https://github.com/minetest/minetest/issues/1074
17:25 ShadowNinja (Which begs the question, where was it ceated before?)
17:31 ShadowNinja Hmmm, maybe just move createRollbackManager after initializeWorld. (Both of which are global and should probably be renamed)
17:37 artur99 joined #minetest-dev
17:37 artur99 ,,(seen OldCoder)
17:37 ShadowBot artur99: I haven't seen OldCoder.
17:39 ShadowNinja I moved the RollbackManager and BanManager after initializeWorld: http://ix.io/9Ac
17:40 werwerwer joined #minetest-dev
17:42 nore https://github.com/minetest/minetest/commi​t/4e5760a5416cbca6945b1b4484cbd96bea7b250c <-- oops, that shouldn't have been done
17:42 nore I should fix it again
17:42 robmyers__ joined #minetest-dev
17:43 nore ShadowNinja, okay for reverting it? (I tested again really this time, and it is incorrect)
17:46 AllegedlyDead joined #minetest-dev
17:47 ShadowNinja nore: So the first way was correct?
17:47 nore yep... I must have made wrong tests the first time
17:48 nore this time, I made a little script (you click on colored faces of a node...)
17:48 Evolykane joined #minetest-dev
17:48 nore maybe I should add that script somewhere, and let it be used to generate those tables
17:51 VanessaE suddenly, a week later:  <nore>  Um, ShadowNinja I need to revert that revert.  the original patch was right after all....
17:51 nore ... I can give you the script if you want
17:51 VanessaE ;)
17:55 ShadowNinja Seems OK to me then, although I haven't noticed any issues either way...
18:02 rubenwardy joined #minetest-dev
18:09 ImQ009 joined #minetest-dev
18:10 IceCraft joined #minetest-dev
18:15 ShadowNinja Does this seem good? https://github.com/freeminer/freeminer/comm​it/75e5895afaec95c530d68847a058aac5338e3c81
18:16 Evolykane joined #minetest-dev
18:17 PilzAdam ShadowNinja, if it does what I think then its good, I dont know cmake very well, though
18:17 EvergreenTree joined #minetest-dev
18:17 ShadowNinja It seems OGLES got linked into the Arch build, which broke it.  ^ should fix that.
18:18 ShadowNinja PilzAdam: Can you check my other changes?
18:19 PilzAdam what does the first one (http://ix.io/9A6) do?
18:21 ShadowNinja PilzAdam: Tables in Lua are not necessarily in order, so that could load a table in the order [2] = ItemStack("air"), [1] = ItemStack("ignore") and resilt in InveltoryList("air", "ignore") rather than "ignore", "air".
18:22 ShadowNinja result* InventoryList*
18:23 PilzAdam did that happen in the past?
18:23 ShadowNinja So meta:set_list("main", meta:get_list("main")) could shuffle the inventory, though in practice it usually doesn't.
18:24 ShadowNinja I heven't heard of that, but Lua doesn't guarantee the order.  It's basically the C++ equivilant of s/pairs/ipairs/
18:25 PilzAdam what happens if I pass a table that has strings as keys to it?
18:27 ShadowNinja luaL_checkinteger will throw a Lua error.  (Something like "Invalid string argument for set_list, expected integer")
18:28 diemartin joined #minetest-dev
18:28 PilzAdam has it thrown errors previously, too?
18:31 ShadowNinja It ignored the keys previously. ({["test"]=ItemStack(), [minetest.register_node]=ItemStack()} was vaild)
18:31 ShadowNinja read_item handles bad ItemStacks in both cases.
18:32 PilzAdam well, you shouldnt change that behaviour
18:33 ShadowNinja What?  We should support string keys in InventoryLists?  Should strings be randomly inserted in the list?
18:33 PilzAdam no, it should just ignore it
18:34 ShadowNinja It's obviously an error, it shouldn't be simply ignored.
18:41 celeron55 it should throw an error
18:41 celeron55 i don't understand PilzAdam at all in this
18:42 celeron55 it was obviously not designed to not throw an error
18:42 ShadowNinja Alright, push it?
18:43 PilzAdam dont be suprised if mods will stop working suddenly
18:44 ShadowNinja If they do then they were very glitchy before due to random inventories.
18:50 ShadowNinja So, I guess I'll push it soon...  Unless someone has something more to say.
18:54 AllegedlyDead joined #minetest-dev
19:03 ShadowNinja Next: http://ix.io/9Ac PilzAdam, celeron55: ^
19:03 ShadowNinja s/^/</
19:04 sapier joined #minetest-dev
19:10 ShadowNinja I only found that one commit from Freeminer that looked good in the first few pages.
19:10 ShadowNinja sapier: What do you think about ^? (See logs)
19:14 sapier the opengles commit?
19:19 VargaD hi sapier
19:25 Evolykane joined #minetest-dev
19:28 PilzAdam ShadowNinja, its good if it works
19:28 sapier SUCCESS ... tcp client joining for the first time :-)
19:31 thexyz sapier: is the source available anywhere?
19:32 sapier I'm about to push it ... expect it to crash not work for everything be unpolished, print a lots of error/debug messages ;-)
19:33 sapier it's bleading edge ... really bleading, it's crashing 100% reproducable on disconnect right now :-=
19:34 sapier https://github.com/sapier/minet​est/tree/tcp_connection_support
19:34 sapier I guess I should push the wireshark file too wait a moment
19:35 sapier don't expect the wireshark support to be perfect too, I don't have any idea how to write those addons it's just doing something that did help me ;-)
19:36 sapier ok all pushed
19:38 sapier wow downloading media is way better then even my fixed udp protocol and that was way better then last core implementation
19:41 proller and better than enet?
19:42 PilzAdam sapier, downloading from the Minetest server, I assume?
19:42 sapier non curl yes
19:42 proller and better than http?
19:43 sapier no idea you can have try if your interested
19:43 proller why not embed small http server into MT?
19:43 proller except NIH
19:44 ShadowNinja Because we don't need a HTTP server.
19:44 proller but neex complex buggy BLOAT protocol?
19:44 proller need
19:44 sapier why do you always want to embedd thousands of non required features and think this is more efficient?
19:45 Miner_48er joined #minetest-dev
19:45 proller tcp also not required here
19:45 sapier even minetest protocol itself is neither broken nor complex nore buggy only thing beeing broken WAS implementation
19:45 proller you can get 6mbps only by tuning current connection
19:45 sapier and the most critical bug was even simple just noone even dared to check
19:46 VargaD but HTTP is faster than TCP :D (one of my coworker said that)
19:46 thexyz yeeah, not broken, just slow as hell
19:46 proller facepalm.jpg
19:46 sapier lots of slowness wasn't result of protocol but implementation too
19:47 proller and stupid defaults
19:47 sapier does anyone want to to tell risk of enet becomming orphaned is anywhere near risk of tcp getting orphaned? :-)
19:48 sapier tcp is os part, no need for additional libs, no bugfixing nothing
19:48 VargaD embedding a http server isn't that bad idea
19:48 sapier embedding a http server is useless as hell
19:48 proller if you cant fix current, why you think you can make good tcp?
19:49 proller tcp more useless useless
19:49 sapier you're wrong about it I fixed current ;-P
19:49 thexyz does it work?
19:49 thexyz last time I tried it enet still was faster
19:49 thexyz so let's just add TCP on top! because TCP is reliability (what we need), it can't be bad!
19:49 sapier yes most likely enet will ever be as it doesn't have to stick to some limitations of old protocol
19:50 thexyz even though we have TCP-over-UDP implementation which sucks we'll just add TCP and everything will be better!
19:50 thexyz also we get compatibility no one actually cares about but we love compatibility, right?
19:50 sapier no I didn't implement tcp on udp
19:50 thexyz I mean, what could go wrong
19:50 sapier don't mix up things
19:51 thexyz and then if it still is not fast enough let's just add more stuff to it
19:51 thexyz I mean, stuff that can't be bad
19:51 thexyz whoa, do you mean we don't have tcp-over-udp here?
19:51 thexyz how should I call it then?
19:52 sapier we have as much tcp-over-udp as enet has
19:52 thexyz indeed
19:52 thexyz there's one difference
19:52 proller maybe implenent SMB for sharing files and map parts?
19:52 VargaD some things won't need resend -> udp, some things need to be reliable but we don't carfe about latency -> tcp
19:52 thexyz our implementation sucks, enet doesn't
19:52 thexyz anyway, it'll be fun to compare so keep working on it
19:52 sapier yes but WHY the hell use ANY tcp-over-udp variant if we don't have to do crap like that ? ;-P
19:53 thexyz sure just use both
19:53 proller sapier, kahrl fix better crashes
19:53 thexyz udp for non-reliable and tcp for reliable
19:53 thexyz such design
19:53 sapier use right tool for right thing design
19:53 proller linux sometimes crashes too on shutdown
19:54 sapier do you really believe enet can compete to tcp as of reliability/support/proofensess ?
19:54 thexyz meanwhile, wtf
19:54 proller use two tools where one is enough - bad design
19:54 thexyz cyrillic input doesn't work for me anymore
19:54 sapier of course, you use a butcher knife for your steak because you don't want to make your steak knife dirty :-)
19:55 sapier because using two tools is inefficient ;-)
19:55 thexyz to me it looks like you're doing this stuff because you find it fun
19:55 celeron55 just make something that works perfectly and nobody will have anything to complain about
19:55 celeron55 simple 8)
19:55 sapier there's nothing that will ever work perfect celeron55 ;-)
19:55 thexyz and it's fun to you right now, you don't care much about whether it'll be fun for you to support, say, the next year
19:55 thexyz (that's how I see it, at least)
19:56 celeron55 (enet has it's issues including lack of ipv6 so nothing is perfect to begin with; this is an open-ended issue as long as nothing is in the upstream repo)
19:56 sapier and you don't care about beeing fun to replace orphaned enet in a year or so
19:56 thexyz sure
19:56 thexyz a library which is 9 years old
19:56 celeron55 its*
19:56 thexyz will be deprecated the next year
19:56 khonkhortisan joined #minetest-dev
19:56 sapier as tcp will be deprecated next year ;-)
19:56 thexyz adding ipv6 to it for sure is a harder task that implementing another protocol support
19:56 thexyz I really don't understand it
19:57 thexyz if that's your only argument
19:57 sapier there is NO OTHER PROTOCOL
19:57 sapier protocol is TCP
19:57 celeron55 this is really pretty stupid; making all these solutions work simultaneously is a lot of effort for the sake of being able to compare them (nothing but one of them will be used in the end anyway)
19:57 thexyz well, there's UDP and you're adding TCP so you're adding a protocol, no?
19:57 sapier yes celeron
19:58 thexyz stupid indeed
19:58 proller sapier, use 2 ports for one application - BAD
19:58 celeron55 but i don't want to dictate; i want to believe that people will make sane choices themselves
19:58 sapier an enet isn't adding 2 new protocolsß
19:58 celeron55 so please do sane choices, ok?
19:58 thexyz anyway, it seems that MT is going with UDP/TCP and FM with enet
19:58 VargaD one port just use both TCP and UDP
19:58 thexyz also by not just dropping the compatibility you won't be able to do fun things like key-value protocol
19:58 proller enet+messagepack
19:58 sapier this discussion is far from technical celeron there most likely wont be a sane choice
19:58 proller VargaD, it 2 rules in firewall
19:58 celeron55 if FM goes with enet, then MT using something else is probably not a good idea because the projects can't support each other
19:58 sapier so 2 new protocols + 1 new packet format
19:59 proller you must forwart 2 ports via router, etc
19:59 thexyz brb, bisecting
19:59 celeron55 altough people like to hate the other project, in the long run nothing is worse than having two implementation of the same thing
19:59 VargaD you can do hole punching with UDP, and not with TCP
20:00 VargaD it would be nice to merge the two project, or at least maintain compatibility
20:00 sapier both protocols have pro and cons ... depends on situation of usage
20:00 proller supporting 2 protocols harder in 2 times for admins
20:00 sapier none of you even dared to read enet code so don't tell me about supporting
20:01 proller also ipv6 - it not stopper, who use ipv6 for MT (except one my server?)
20:01 sapier lack of ipv6 support is a show stopper in long run
20:01 thexyz I didn't read Linux kernel source code either yet I use it
20:01 celeron55 proller: there have been people making issues about ipv6-related things, so those i guess
20:01 thexyz I didn't read Irrlicht code
20:01 thexyz I don't think there's a problem
20:02 sapier so you compare reading 10 pages to reading 10million pages ? :-)
20:02 thexyz and yeah, I'm not saying that enet is as solid as Linux kernel; just that it's probably better than what you can come up with
20:03 proller celeron55, ipv6 is must-to-have thing, but actually NOW it only for geeks and 1-3% lucky users with good providers
20:03 sapier I don't want to tell all the issues about enet again, it's not the proofen project you try to make it
20:03 sapier and no comparison to tcp
20:03 sapier it's not bad either I don't wanna tell that
20:04 thexyz sure thing
20:04 thexyz you're not willing to break protocol (for messagepack)
20:04 thexyz got it
20:05 sapier but yet you're breaking compatibility for what? for slightly better performance? for having right and adding something new? for having chance to breake protocol format too?
20:06 sapier I don't see a pressing need for doing all those things, tell me where you see it
20:07 thexyz for messagepack
20:08 thexyz for the ability to extend the protocol
20:08 thexyz in a sane way
20:10 sapier and messagepack is the one and only sane way?
20:11 sapier guess we need to add a messagepack lib too?
20:11 VargaD bson?
20:11 thexyz proller told me it was the fastest one
20:11 sapier so another piece of code we don't know how to maintain?
20:12 thexyz wow! it really is pointless to talk to you; do you think it's better to reimplement everything than to depend on external libraries?
20:12 thexyz this is really a weird case of NIH
20:12 proller sapier, why your bots.. not working?
20:13 sapier no it isn't there's no need to use external libraries for most simple things
20:13 thexyz ah sure thing
20:13 thexyz let's write our own serializer then
20:13 thexyz anyway, since it's not going to happen why talk about it? it really is pointless
20:13 sapier why don't you replace main server loop by external lib? there are gamelibs out there too
20:13 VargaD sapier: do we really need an own serializer?
20:14 thexyz sapier: can you point me at some?
20:14 proller main server loop is terrible singleplayer thing.
20:14 sapier varga we already have 3 serializers last one was added by ShadowNinja
20:14 VargaD wow
20:14 VargaD thats a lot, we should use only one :)
20:15 proller json!
20:15 sapier yes that's why I was against adding the last one
20:15 VargaD what is the last one?
20:16 sapier the first two are at least functional different the last one is a 1:1 feature identical replacement ... exept for proller he get's shiny eyes on seeing it as it's serializing to his beloved json format ;-P
20:16 thexyz 22a59b3912ff5e7bb1516faa06f1841545a8117c is the first bad commit
20:16 thexyz commit 22a59b3912ff5e7bb1516faa06f1841545a8117c
20:16 thexyz Author: sapier <Sapier at GMX dot net>
20:16 sapier what's that commit about?
20:16 Evolykane joined #minetest-dev
20:16 sapier and what's the bug
20:16 thexyz fix windows i18n blah blah ugly blah microsoft?
20:17 thexyz can't input cyrillic on linux
20:17 sapier broken cyrillic? fix your os
20:17 sapier set language correctly
20:17 sapier set correct codepage
20:17 thexyz how?
20:17 proller wat&
20:17 sapier what's your LANG and LANGUAGE?
20:18 sapier btw that was added ages ago why do discover it now?
20:18 thexyz https://gist.github.com/xyzz/895b992​c8d640bb00b5c/raw/ba4095fee5b90a0a7d​6eada413e82f4098866c34/gistfile1.txt
20:18 thexyz well because I discovered it now
20:18 sapier of course you can't enter cyrilic with setting to US  ;-)
20:19 thexyz reaaaally?
20:19 thexyz why does every other app work then?
20:19 sapier maybe because of more sane in app code not doing conversion hundreds of times?
20:19 VargaD hungarian characters also don't work
20:19 sapier if you don't convert noone will realize broken charset
20:20 thexyz maybe because it's UTF-8 and it shouldn't matter?
20:20 thexyz anyway
20:20 thexyz what should I set it to for it to work?
20:20 sapier check if input really is utf8
20:20 sapier I assume ru_RU.UTF-8 should work
20:20 VargaD probably it is my fault...
20:21 thexyz sapier: I set export LANG=ru_RU.UTF-8; export LANGUAGE=ru; export LC_ALL=ru_RU.UTF-8
20:21 thexyz sapier: still doesn't work
20:21 thexyz plz fix
20:22 Calinou joined #minetest-dev
20:24 sapier no I won't touch that i18n thing anymore I'm done with it whenever you fix something you break something else
20:25 sapier the one beeing in there is best I can do, guess that one needs a more i18n skilled person
20:25 thexyz fine
20:25 sapier but I know for sure cyrillic is working as I did test it
20:25 thexyz break everything, don't care to fix it
20:26 thexyz adding setlocale(LC_ALL, "") to main.cpp apparently fixes it
20:26 sapier do you have gettext enabled?
20:26 thexyz hm, no
20:26 sapier for you ... but most likely will break on windows
20:26 VargaD I got _ characters instead of öüóúőűáé
20:27 VargaD LC_ALL=hu_HU.UTF-8
20:27 sapier there are about 100 combinations to check if you change anything in locales and charset
20:27 thexyz okay, building it with gettext apparently fixes it; still strange
20:27 thexyz since gettext isn't enabled by default
20:27 VargaD building with gettext wupport isn't default?
20:27 sapier not strange I did do the localization fixes with gettext enabled so I may have missed that one
20:28 thexyz anyway, it's fine this way then
20:29 sapier it's almost impossible to test any i18n build variant thexyz if you found a bug in non gettext variant check the other variants and merge it
20:29 VargaD oh it isn't :(
20:29 thexyz don't care anymore since it works
20:29 sapier especially windows build variants are ugly
20:30 VargaD thanks thexyz that solved to problem, it was my fault after all...
20:34 celeron55 well shit
20:34 VanessaE not here.
20:34 VanessaE it stinks and draws flies.
20:34 celeron55 but shit is here
20:35 sapier can't we dropp i18n support and stick to english with utf8? ;-)
20:35 sapier gettext is our own best example for something we should've invented ourselfs ;-)
20:35 thexyz yeah sure
20:36 celeron55 how the fuck can all these things be so difficult to handle and choose
20:36 VanessaE celeron55: because NIH
20:36 VargaD shouldn't gettext and freetype used by default?
20:36 VargaD as least we should mention them in build docs...
20:36 celeron55 what i
20:36 sapier both are quite tricky on windows
20:37 celeron55 what i'm seeing now is that sapier is pretty much alone with his stuff
20:37 thexyz VargaD: yeah they should
20:37 VanessaE celeron55: not entirely.
20:37 VargaD how many people build minetest on windows?
20:37 celeron55 is this what others are seeing?
20:37 VanessaE kizeren and I have been testing his fork on our servers.
20:37 thexyz VargaD: we usually don't care about it
20:37 VargaD the windows build on forums has freetype and gettext support
20:37 sapier seems everytime I improve something I get responsible for the remaining bugs too ;-)
20:38 thexyz well I said this didn't matter since there's a way to make it work
20:38 VanessaE (at least for his work on the UDP/TCP stuff aka media_FUBAR)
20:38 thexyz so I'm not blaming anyone
20:38 nore about those locales things, btw: was the "Local install" button fixed?
20:38 thexyz and I'm sure others don't either
20:39 VanessaE VargaD: I've taken something of an odd liking to the new shadowed text even over my own font, though I think I'd prefer it to be double-shadowed, so maybe even I could suggest freetype enabled by default.  gettext, I have no opinion on.
20:39 ShadowNinja nore: Nope, it's been ignored so far.
20:40 thexyz there's no reason not to enable gettext
20:40 VargaD nearly all the linux distributions has gettext by default and you can't even remove it
20:41 celeron55 is there nobody else in here who thinks separating freeminer and minetest even on the network level is probably a really bad idea and should be avoided?
20:41 celeron55 seriously; this will affect so many things in the future that nobody should be even thinking anything else until there is a proper plan
20:41 VanessaE celeron55: it is a bad idea, absolutely.  the two projects need to remain cross-compatible imho.
20:41 thexyz that's only bad for FM
20:41 celeron55 i don
20:42 celeron55 i don't really care for any particular project as i can't foresee which (or whether both) will ultimately succeed
20:42 VanessaE at least to the point where one can connect to the other, even if one can't necessarily run code meant for the other.
20:43 VargaD thexyz: it is bad for both projects
20:43 celeron55 client compatibility is quite a large goal if actual development is going to be made and things aren't just left to rot
20:43 celeron55 so we either choose to have it or not
20:43 sapier1 joined #minetest-dev
20:44 celeron55 thexyz: will FM use sapier's implementation if it goes into minetest?
20:45 celeron55 (of course assuming it actually works well)
20:45 thexyz we plan to switch to key-value protocol, so no
20:45 thexyz I mean, it'll be incompatible anyway
20:45 celeron55 so FM isn't going to be client-compatible in any case?
20:45 celeron55 what if i want that same key-value protocol in minetest?
20:46 thexyz well if you're breaking compatibility anyway then why not add enet?
20:46 sapier1 we'd have to either merge all of freeminer (including the broken history) or extract the necessary fixes on our own
20:46 celeron55 i'm not the one yearning for backwards compatibility
20:46 celeron55 it seems to be sapier's personal thing
20:47 sapier1 thexyz already told he's not gonna provide pulls for minetest
20:47 sapier1 And don't expect me to do it ;-P
20:47 thexyz yeah and since adding KV would take a lot of time then we'll be in sync for quite some time
20:48 VargaD hey we need to work together
20:48 celeron55 it would be insane to leave such positive development out of minetest (as compared to proller's weather stuff and whatever that was *actually* controversial)
20:48 thexyz well that's only how you're seeing it
20:48 celeron55 i know i'm biased
20:49 thexyz I'm sure sapier1, for example, sees both weather and kv protocol as ugly useless things or something
20:49 sapier1 I think the way the weather improvements have been done are controversial too ... not talking about the feature itself
20:49 celeron55 thexyz: and is there anyone else?
20:50 sapier1 If I didn start a new project kv would be my choice too but this isn't situation
20:50 VanessaE we have a new problem with backward compatibility though
20:50 VanessaE this damn buildcraft is exploding
20:50 VanessaE users are coming out of the woodwork
20:51 thexyz no worries we've already submitted a few dmca requests
20:51 VanessaE I don't mean like that
20:51 celeron55 i think the only real way to combat it is to build a competing program
20:51 VanessaE I mean,m do we break compatibility with it, which is basically 0.4.8-stable?
20:51 celeron55 and if nobody does it, then whatever; fail for that part
20:51 celeron55 VanessaE: of course
20:52 VanessaE mmmh
20:52 celeron55 they'll update to the new one in no time anyway; why wouldn't they
20:52 thexyz true
20:52 sapier1 celeron55 for what reason? I'm all in if someone manages to persuade me with some real benefits
20:52 thexyz they're illegal though
20:53 sapier1 to me all of this seems like the other "json is better then xml" thingy
20:53 celeron55 sapier1: there are no real benefits other than short-sighted compatiiblity in your way, so you can't demand much of those
20:53 VanessaE celeron55: for the same reason that their current source release is already 2 months old - some combination of lack of time, stubbornness, and perhaps a bit of laziness
20:54 thexyz anyway, my point is: if we decide to break compatibility then we should go with enet; if we go with sapier's solution then we shouldn't break compatibility in some other way
20:54 thexyz *any other way
20:54 sapier so why the hell have I been punched that often to keep compatibility at each single lua fix?
20:54 sapier no matter how insane that was
20:54 thexyz because his tcp/udp stuff is good for exactly that reason — compatibility with current clients
20:54 celeron55 i'm with thexyz; it just makes sense to break compatibility now that not much else is happening so that there is a good base for new stuff in the future
20:55 thexyz sapier: I don't know, was that me who punched you?
20:55 sapier so we switch to a protocol not beeing evaluated not beeing any standard not beeing driven by any community?
20:56 thexyz the only problem is that we probably won't find anyone willing to do kv
20:56 proller but kv transfer needed for future evolution..
20:56 sapier you want it thexyz you do i
20:56 sapier t
20:56 celeron55 but really, this is partly an organizational solution too; if minetest and freeminer have dual efforts here, the community overally loses
20:56 thexyz sapier: sure thing
20:56 sapier the community already lost due to lack of decision
20:56 sapier face it
20:56 thexyz sapier: and how exactly your stuff is better in that way?
20:56 celeron55 sapier: why are you developing then?
20:57 thexyz not beeing evaluated not beeing any standard not beeing driven by any community?
20:57 sapier because tcp/udp was yesterdays decison to do it
20:57 thexyz I'm talking about UDP part
20:57 sapier I will not do a third implementation for sure
20:57 celeron55 this project exists for the community, and if it fails in something, it doesn't mean it couldn't find a way to recover
20:57 proller but i think keep kv and old format possible, in cost of ugly dual code
20:57 VanessaE sapier: didn't you tell them?
20:58 sapier you can do what you want kv or not that's not related to protocol at all
20:59 celeron55 sapier: it's not my fault that it's so hard to see where the progress is going as everyone is just ignoring everyone else
20:59 thexyz but it is
20:59 thexyz if we break compatibility anyway then why not add enet? since it's better
20:59 celeron55 sapier: (and you don't have to do a third implementation)
20:59 sapier it's hard to see celeron55???? you're kidding, I told multiple times I'm working on tcp support he last days
20:59 sapier it's been even thexyz who made me realize decision was to do tcp/udp ....
21:00 sapier guess he did say that expecting not getting any working tcp implementation at all
21:00 celeron55 sapier: i know what you're doing, but i didn't hear about these further protocol rework plans of thexyz & co
21:00 sapier packet format != protocol
21:00 thexyz sapier: I said that because you asked what the decision was
21:00 celeron55 same thing, different level
21:01 sapier no if you don't mess up layers you can transfere any packet format with a protocol
21:01 sapier -e
21:01 thexyz celeron55: those are just plans that could be delayed for undefined amount of time due to no free time
21:02 djdduty joined #minetest-dev
21:02 thexyz sapier: yeah but if you do kv protocol then you don't want to support the old one too
21:02 celeron55 thexyz: in that case there isn't really any basis for any decision
21:03 sapier guys I want a decision NOW udp fixes lack final polishing (which requires quite some time) and tcp lacks final stage of development I will not spend any additional time if decision to use enet no matter how much issues are left is already done
21:04 sapier and no i wont do kv that's your whish if you want it do it yourself
21:06 celeron55 so how are we supposed to make any decisions when we don't know when anyone is going to code anything
21:06 celeron55 i guess we could just write a roadmap and expect people to follow it slowly but surely
21:06 sapier I said what I'm doing
21:06 sapier and I said what I'm not gonna do
21:07 sapier I don't blame anyone for the time I spent on udp fixes as I did those for educational purposes
21:07 celeron55 can you say why you would rather spend your time effectively re-implementing enet but not in making a key-value packet format?
21:07 celeron55 that seems insane to me
21:07 sapier because I see no actual benefit in switching the packet format
21:07 sapier explain it to me
21:08 celeron55 but it has obvious benefits; currently the packet formats are very messy to keep backwards-compatible and newbie developers break them all the time and everyone has to stress that
21:08 sapier it's basicaly reqriting server and client ... much more effort then udp and tcp together
21:08 celeron55 i don't believe so
21:08 sapier have a look at it
21:09 celeron55 it should be pretty straight-forward once the basic things are set up
21:09 sapier it's a lot of typwrtiting testing fixing
21:09 sapier for what?
21:09 celeron55 thexyz: your words?
21:11 celeron55 i don't want to force this with my personal opinions and hate it if no other sane person describe their view
21:11 celeron55 proller?
21:11 celeron55 kahrl? hmmmm? whoever; don't hide now
21:12 celeron55 there obviously are alternative things to do too
21:12 celeron55 like some more feature-like things
21:13 celeron55 and whatever rework (locking?, whatever else)
21:13 sapier of course comparing mt packet format to kv on green meadow I'd choose kv too ... but right now it's just a lot of work for some diffuse possible benefit in some distant future I'm not even sure it's gonna be real
21:14 celeron55 it of course goes deeper than that; the same format would be used for the deeper data structures that are included in the packets, and maybe something on disk too
21:15 sapier I don't even know what needs to be touched, usually I see a lot of things and I'm called to be pessimistic for this .... but most time it's even more then I see
21:15 Gethiox joined #minetest-dev
21:16 sapier and btw I'm for dropping UDP support in mid to long range too
21:16 celeron55 all this could of course be just a big bad idea, which is why i really would appreciate input of others than us few who are already pissed off by this being so undecidable
21:16 sapier UDP reliable
21:20 sapier https://github.com/minetest/minetest/pull/1054
21:20 sapier hmmmm do you want to do a release the next days?
21:22 celeron55 minetest seriously lacks developer time at the moment; it's kind of impossible to avoid the problems caused by that
21:22 celeron55 this is a large project and getting a lot of "bang for the buck" for the time of a single developer is practically impossible
21:22 sapier minetest lacks of management time not developer time that's what drove proller away and causes the current issues too
21:23 sapier or management structure
21:23 celeron55 it may be the deeper problem
21:23 celeron55 the immediate problem is that though
21:23 celeron55 you're free to suggest management structure
21:24 sapier I tried this as much as others did without noticable effect
21:24 VargaD sapier: move updates don't need to be teransmitted on package lost
21:25 celeron55 proller had some "drive" to his doings, but his ways of doing things weren't approved by many, so proller was lost
21:25 sapier by now we haven't found any way to decide on a common path if different parts of community drive minetest to different directions
21:25 person22 joined #minetest-dev
21:25 sapier and proller did join at a time where amost nothing was decided
21:25 jin_xi joined #minetest-dev
21:26 sapier move updates are transmitted unreliable
21:26 person22 left #minetest-dev
21:26 celeron55 i think we ultimately lack people who simultaneously have understanding of development and either play the game or know about game development
21:26 VargaD you said you would like to drop UDP
21:27 sapier I corrected this to UDP reliable vargaD ;-)
21:27 VargaD oh sorry, I understand
21:27 person22 joined #minetest-dev
21:27 VargaD you are right (again)
21:27 celeron55 we or i could search the community for people that are potentially like that and try to "recruit" them for the reward of getting minetest to progress
21:27 sapier that'd be the perfect person celeron55 but I don't thing we'll find someone doing it this way
21:28 celeron55 i don't think we have a chance of getting people from outside of the community to do things like that
21:28 sapier maybe we could try something like linux kernel is doing subsystem responsibilities
21:28 person22 left #minetest-dev
21:28 VargaD that is a good idea
21:28 celeron55 that has been suggested by me many times before, but i have no clue how to start it
21:29 celeron55 hmmmm agreed to it too
21:29 sapier I assume defining subsystems would be first step ;-)
21:29 sapier e.g. script api, mapgen, server, networking, client
21:29 sapier graphics
21:30 sapier maybe split script api to ingame/menu
21:30 celeron55 could work
21:30 VargaD and we also need someone like Linus
21:30 VargaD do the decision when the maintainers have conflict
21:30 sapier that one would've to be celeron55 but I assume we don't get fsf to pay him anytime soon ;-)
21:31 VargaD :)
21:31 VargaD Can have have a better release schedule also?
21:31 sapier and another thing, reliable strict merge rules
21:31 sapier e.g. you need two agreements to merge a pull
21:31 VargaD with this management it is totally easier to do proper release management
21:32 celeron55 well i could try, but i don't have a lot of time so i would just be a way to connect the trust of people; i want to use time to progress my other projects
21:32 sapier and those agreements have to be done as github comments
21:32 sapier this way you don't have to interpret if some saying is a agreement or not
21:32 VanessaE bbl
21:33 VargaD celeron55: it is OK as long as minetest subsystem maintainers accepts your decisions
21:33 celeron55 but frankly there aren't really alternatives to me, because hmmmm and kahrl are just as busy too
21:34 celeron55 and thexyz and whoever other long-timer like that
21:36 sapier I'd like to use the key value things too celeron55, at least if they're provided in a way we don't have as much work as doing it by our own ... last time I was told "merge freeminer"
21:36 celeron55 well i'll say i'm ready to try; how do we choose subsystem maintainers?
21:37 sapier I'd first try volonteers?
21:37 sapier rba might be interested in graphics
21:38 sapier maybe shadow is interested in scriptapi?
21:38 sapier formspecs may be as big as beeing a own subsystem
21:38 celeron55 i will direct my decisions based on the idea written by me in "the" blog post, unless the community clearly points out a problem in it - this is what the supposed-to-be maintainers can expect
21:39 PilzAdam will we have 1 maintainer per subsystem, or more?
21:39 celeron55 one that i trust; it's how it works
21:40 celeron55 i also will have to trust the one to choose a second one wisely if needed
21:40 celeron55 this brings up a problem in graphics, because i don't trust rba to make good graphical design decisions (coding-wise it's fine)
21:41 sapier make visible changes to be agreeable by at least two core maintainers?
21:41 sapier this would affect formspec and menu changes too
21:43 sapier we don't need that rule as there still need to agree two core devs ... guess that's gonna be equivalent
21:43 celeron55 i see an issue in this actually
21:44 celeron55 sapier: i think if there is a division of responsibility, then the one responsible is free to choose how many agreements he wants
21:44 sapier someone (guess you) needs to define some basic development directions ... e.g. keep compatibility, enforce usage of external libs, keep windows build ... in best case those directions don't request opposit things :-)
21:44 Miner_48er joined #minetest-dev
21:45 sapier (s)he's still free to want more
21:45 celeron55 of course it's probably reasonable to ask someone other too usually, but there is no need for strict rules
21:45 sapier demanding to at least two agreements is just a minimum requirement
21:45 celeron55 why would you demand that?
21:46 celeron55 currently that is in place mostly to make sure that someone who actually knows about the thing in question sees it
21:46 sapier yes, it's gonna make work for maintainers more easy too
21:47 celeron55 in a subsystem responsibility scheme, the one who sees it is the one who knows it, and thus is the one who can decide
21:47 sapier he's the one who can decide not to merge it of course
21:48 sapier 100 agreements without maintainer agreement are worth nothing
21:49 VargaD can we define precisly the subsystems?
21:49 sapier I'd see dual agreement a minimum standard but if you want to do it in another way I'll accept it too. I just tell my opinion
21:50 sapier right now the only real subsystem is scriptapo
21:50 sapier -o+i
21:50 Evolykane joined #minetest-dev
21:51 sapier connection.cpp/.h have a quite defined interface too so this could be done without major changes too
21:51 celeron55 so.... server, networking, scriptapi, mapgen, client, graphics
21:51 celeron55 do we even have enough volunteers for these?
21:51 sapier I'd give it a try
21:52 celeron55 sapier: i'd leave it fuzzy for now; the precise limits will take shape as actual work is done
21:52 PilzAdam https://github.com/minetest/minetes​t/blob/master/src/porting.cpp#L344 the function in this assert() is not called in release builds, which leads to broken paths in osx builds (http://irc.minetest.ru/min​etest/2013-12-30#i_3522670)
21:52 sapier thinking about server/client this may be even better to be a single subsys
21:52 sapier but that's what a discussion is for
21:53 sapier PilzAdam: I know I made this mistake too :-) but that one isn't mine
21:53 VargaD proller, thexyz what do you think?
21:56 celeron55 so... what will immediately happen if this organization takes place is that basically a single person will have the authority to decide the networking thing
21:56 celeron55 (oh, and of course a single person can be responsible for multiple subsystems, if that person has more time than others)
21:58 sapier of course, but that means that one is repsonsible for those decisions too
21:58 celeron55 yes
21:59 ShadowNinja Me, kahr|, and sapi3r probably knw most about ScriptApi; hmmm -> mapgen; hmmm, sapi3r, xyz -> protocol...
21:59 celeron55 no, not many people for a single thing; there needs to be a main person always
22:00 celeron55 that is the basis of straightforward decision making
22:00 sapier but you know key value and networking would be in different subsystems on proposed subsystem structure?
22:00 celeron55 yes, i just was thinking about that
22:00 sapier as packet format is primary server/client thingy
22:00 celeron55 it's not really an issue; those two responsibles will have to decide how to do it
22:01 thexyz ShadowNinja: why would you think I know anything about the protocol? I'd say proller does
22:01 celeron55 and they will then ejoy the results of whatever they decided 8)
22:01 celeron55 enjoy*
22:01 ShadowNinja thexyz: Because you wrote a enet patch.
22:01 sapier do we need any rules about commit quality?
22:02 ShadowNinja Yes, of course.
22:02 sapier e.g. a commit comment telling what the commit is supposed to do?
22:02 celeron55 we don't change commit quality rules
22:02 celeron55 but they won't be checked by everybody
22:03 sapier ok so it's up to you to clap those maintainers fingers not keeping the rules
22:05 celeron55 (obviously anyone can)
22:05 celeron55 (informally)
22:06 celeron55 hmm, we should assign a documentation responsible too
22:06 sapier *smile* guess that one will be very hard to find
22:06 celeron55 well 8) there are that kinds of people around sometimes
22:07 celeron55 it's not a full-time task anyway
22:07 celeron55 (as if anything is)
22:07 Miner_48er joined #minetest-dev
22:10 celeron55 how about on-disk formats?
22:11 celeron55 if one responsibilty is server/client, then that doesn't go there
22:11 celeron55 let's say server-other is for stuff like that
22:12 celeron55 (includes configuration and whatever)
22:14 celeron55 hmm, this is a tad too vague
22:16 sapier isn't on disk format part of map/mapgen?
22:16 celeron55 imo not at all
22:17 sapier I don't know much about it that subsys is one of those things I haven't done anything by now
22:17 celeron55 i'll try to make a sane proposal of subsystems
22:18 celeron55 PilzAdam: are you able to point out a part in minetest the development of which you would like to be responsible of?
22:18 celeron55 same goes for others; sapier?
22:20 celeron55 of course responsibility doesn't mean at all that you need to code that thing; but you need to be ready to at least accept/decline stuff related to it
22:20 sapier right now I know most about networking. Scriptapi is kind of completed right now and shadows knowledge is more fresh than mine. I guess I could do most usefull work on server/client right now (fixing the environmental locks).
22:21 sapier but I guess I'll open up some conflicts on server rework too :-)
22:23 celeron55 hmm, we need to get used to switching these sometimes tooo i guess
22:23 PilzAdam hmmmmmm
22:23 sapier right now I don't think you have a way to make everyone happy
22:24 PilzAdam Im mostly interested in "game logic"; i.e. node/time properties and behaviour, player movement, and other stuff that is directly visible to the players
22:25 PilzAdam s/time/item/
22:25 sapier e.g. if thexyz is responsible for networking and I am for server I guess enet will be added (by some time) but kv wont be added soon
22:25 sapier as my primary focus would be removing as much locking as possible and packet format isn't an issue for this
22:27 celeron55 i'm going to put thexyz on build system
22:27 PilzAdam my "goal" with it would be to make it as generic as possible, to give the Lua games more possibilities
22:27 sapier I fully support that goal
22:28 sapier btw I might even switch to enet instead of tcp ... but not in that incompatible way proller and thexyz suggested
22:29 PilzAdam and Id like to help whoever gets the API
22:30 sapier guess I'm gonna have some improvements for lua too ;-)
22:30 celeron55 is there anyone in here who would like to work on *sound*? i think someone was talking about it
22:31 celeron55 (of course wish to work on something isn't equal to ability to judge it, but it's a starting point)
22:31 ShadowNinja These assignments should be noted on the dev wiki.
22:31 celeron55 hmm, taoki
22:32 PilzAdam eh, dont mix minetest_game with engine now
22:32 sapier as well as the files that make that subsystem :)
22:33 celeron55 PilzAdam: yeah, it isn't worth a subsystem; just trying to figure out what things i bundle together
22:33 PilzAdam I would count the sound triggers in the engine to "game logic"
22:34 celeron55 https://gist.github.com/celeron55/8189279
22:34 celeron55 current draft
22:35 sapier what's meant with dedicated?
22:36 celeron55 the dedicated way of running the server (as opposed to with the client)
22:37 sapier isn't that hard to split?
22:37 celeron55 it's currently quite tightly squeezed together with the client startup though
22:37 celeron55 hmm let's see
22:37 celeron55 server/config/dedicated -> startup/config?
22:37 sapier guess we need to do some adjustments once we got some experience with it
22:38 celeron55 i'm going with startup/config for that
22:39 celeron55 PilzAdam's thing doesn't really fit in any of this stuff; it's more like a theme than a certain part of minetest
22:40 celeron55 and this has to be done with physical parts
22:40 sapier if this is anything at all it's server
22:40 sapier but builtin and scriptapi match equaly
22:45 testman42 joined #minetest-dev
22:46 celeron55 a vast majority of the startup/config code seems to be still directly from my hands
22:47 sapier yes i guess last one to touch this was me on adding the lua startmenu
22:47 sapier at least client part
22:47 celeron55 i guess i can take the responsibility of that for now
22:47 NakedFury joined #minetest-dev
22:47 celeron55 so wtf about client/audiovisuals
22:49 celeron55 i think rba's work there is too controversial
22:50 celeron55 and i don't think he'd care about that responsibility anyway
22:50 sapier I'm not sure about it most time ppl just don't want to try it ;-) or don't really care about it
22:51 celeron55 i can assign it to myself and try to get rid of it as soon as someone suitable can take it
22:52 celeron55 by doing that this kind of reflects the current development situation i guess
22:53 sapier true
22:53 celeron55 as these are supposed to subsystems, a good reality test should be that whether they could possibly be eventually located in their own subdirectories
22:54 sapier but it's a starting point if we keep on pushing this direction we may succeed
22:54 celeron55 and indeed these could
22:55 sapier but for now it doesn't seem a common accepted direction PilzAdam seems to be at least not against it thexyz and proller don't say anything bout it ... sfan5 ShadowNinja and hmmmm don't tell anything (by now) too
22:57 celeron55 yeah, let's let people comment on it (https://gist.github.com/celeron55/8189279)
22:58 iqualfragile_ joined #minetest-dev
22:58 celeron55 the way this would (should, could) work in practice is that the person marked for the subsystem is allowed to push/merge stuff related to that subsystem into upstream
22:59 celeron55 and... not really other rules
22:59 celeron55 usage of common sense should make the rest of it
23:00 celeron55 (including following the applicable rules/practices we have now)
23:01 celeron55 the way this changes the decision making is that there is almost always a person to blame for a hanging pull request, unlike now when it's everyone's = nobody's responsibility
23:01 celeron55 (the most radical thing in it, i mean)
23:02 sapier we all know you never can see every sideeffect
23:04 sapier and if some maintainer requests another core dev to agree to a commit I'd assume it to be rude if all others refuse to check fixes (at least if they are checkable)
23:04 PilzAdam many pull requests touch multiple subsystems
23:04 sapier PilzAdam: this will improve by time
23:05 celeron55 PilzAdam: in those cases it's simple (altough not as efficient): each of the maintainers must agree on it (and sort it out between themselves)
23:05 PilzAdam sapier, "improve"?
23:05 sapier in best case subsystems have defined interfaces ... of course this ain't possible everywhere but for most things it is
23:05 PilzAdam celeron55, in this case there is not a single person to blame if the pull request hangs forever
23:06 celeron55 PilzAdam: yeah, but there's 2 or 3 instead of the full core team
23:06 sapier if someone is responsible the one might be more motivated to do it too ;-)
23:06 PilzAdam sapier, if I want to add a new node property, it will touch api, server (for sending it), client (for handling it) and maybe graphics too
23:07 sapier yes but I guess in practice noone will refuse changes like that ... at least if you don't add a 100mb property ;-)
23:08 celeron55 we'll see if that works or not; if not, i guess we can figure out something
23:08 sapier I guess if not it's just gonna be same as now ;-)
23:08 thexyz okay, I'm fine with doing buildcrap
23:09 thexyz this involves stuff like enabling freetype by default or so, right?
23:09 thexyz and making sure this shit builds where it should
23:09 celeron55 yes
23:10 celeron55 all the cmake files are yours
23:10 celeron55 i put you there because you do some windows builds sometimes 8)
23:10 thexyz alright
23:13 celeron55 aand then the one part of this idea is that there is a... ehm, let's call it Linus; so there is a Linus (lol) who comes officially into play only if two subsystem maintainers can't make a decision on something that affects both of them (of course there are "unofficial" discussions all the time between any people, eg. this channel just like now)
23:16 celeron55 we could have a free vote of who people would trust in that position
23:16 celeron55 because there could very well be someone else than me
23:19 celeron55 what if we had a subsystem maintainer for democracy? 8)
23:20 celeron55 duties would involve knowing what the actual players and modders want
23:21 celeron55 and being able to get that information when any core dev asks for it
23:21 celeron55 or, well, subsystem maintainer, or really any contributor
23:22 sapier subsystem decision_making? ;-)
23:23 celeron55 no; decision making is distributed
23:24 celeron55 or not really, but as far as the organization would go, it is
23:29 VargaD can we have a defined relase schedule/plan also?
23:30 sapier I assume that'd be best to be in build subsystem?
23:34 sapier #1067
23:34 sapier #1068
23:34 sapier #1054
23:34 ShadowBot https://github.com/minetest/minetest/issues/1067
23:34 ShadowBot https://github.com/minetest/minetest/issues/1068
23:34 sapier #1076
23:34 ShadowBot https://github.com/minetest/minetest/issues/1054
23:34 ShadowBot https://github.com/minetest/minetest/issues/1076
23:34 VargaD so thexyz: what do you think about a defined release schedule?
23:34 sapier plz review and comment those (maybe start with first 3 ones) ;-)
23:42 celeron55 no, that's not thexyz's problem
23:43 sapier guess we need to have someone to decide uppon that too
23:43 celeron55 it could be it's own thing with a responsible person
23:43 celeron55 ...if somebody is willing to
23:44 celeron55 it practically has been hmmmm for a long time, and before that it was me for forever
23:44 sapier that one needs to have the authority to make maintainers merge bugfixes only during feature freeze phase
23:45 sapier hmm maybe that issue might settle on its own once a maintainer got clapped for merging a broken feature within feature freeze
23:50 Zeitgeist_ joined #minetest-dev
23:57 celeron55 everyone knows each other; it's not like we suddenly became some kind of wild animals
23:58 celeron55 as long as people know it's a feature freeze, that's what they do
23:59 sapier left #minetest-dev
23:59 sapier joined #minetest-dev

| Channels | #minetest-dev index | Today | | Google Search | Plaintext