00:06:13 | | Quit mudd1 (Ping timeout: 276 seconds) |
00:08:00 | | Quit benedikt93 (Quit: Bye ;)) |
00:10:50 | | Quit {phoenix} (Remote host closed the connection) |
00:25:55 | | Quit Slasheri (Ping timeout: 264 seconds) |
00:28:22 | | Join Slasheri [0] (miipekk@rockbox/developer/Slasheri) |
00:34:06 | | Quit liar (Ping timeout: 258 seconds) |
00:37:18 | | Join Strife89 [0] (~Strife89@207-144-19-39.cstel.net) |
00:50:19 | TheLemonMan | i tried writing my own i2c implementation but it keeps getting always 1 as ack |
00:56:01 | | Quit sideral (Quit: Leaving.) |
01:00 |
01:00:47 | | Join simonlnu_ [0] (N43Azqz5Rm@unaffiliated/simonrvn) |
01:01:48 | | Quit simonlnu (Ping timeout: 240 seconds) |
01:01:52 | | Nick simonlnu_ is now known as simonlnu (N43Azqz5Rm@unaffiliated/simonrvn) |
01:03:06 | *** | Saving seen data "./dancer.seen" |
01:06:34 | | Quit Zarggg (Quit: Rebooting client...) |
01:06:56 | | Join Zarggg [0] (~zarggg@24.229.139.169.res-cmts.sm.ptd.net) |
01:10:06 | | Join Rob2222 [0] (~Miranda@p5DE4BC2D.dip.t-dialin.net) |
01:22:44 | | Join evilnick [0] (~evilnick@host217-44-128-244.range217-44.btcentralplus.com) |
01:22:44 | | Quit evilnick (Changing host) |
01:22:44 | | Join evilnick [0] (~evilnick@rockbox/staff/evilnick) |
01:37:22 | | Quit Strife89 (Quit: Leaving) |
02:00 |
02:01:25 | | Quit RogRar (Quit: Leaving) |
02:04:39 | | Quit TheLemonMan (Quit: Ex-Chat) |
02:06:41 | | Quit evilnick (Remote host closed the connection) |
02:15:49 | | Quit GeekShadow (Quit: The cake is a lie !) |
02:25:02 | | Quit GermanMushroom (Quit: Ik ga weg) |
02:30:17 | pamaury | ah, i2c working \o/ |
02:31:43 | | Quit pamaury_ (Remote host closed the connection) |
02:31:44 | | Quit pamaury (Read error: Connection reset by peer) |
02:39:05 | | Join Strife89 [0] (~Strife89@207-144-19-39.cstel.net) |
02:44:28 | | Quit Llorean (Ping timeout: 246 seconds) |
02:52:21 | | Join ntkm [0] (~taku@bmdk6131.bmobile.ne.jp) |
02:59:14 | | Join Llorean [0] (~DarkkOne@99-68-45-56.lightspeed.hstntx.sbcglobal.net) |
03:00 |
03:01:01 | | Quit keyb_gr (Ping timeout: 240 seconds) |
03:03:07 | *** | Saving seen data "./dancer.seen" |
03:03:08 | | Quit ntkm (Read error: Connection reset by peer) |
03:03:21 | | Quit CaptainKewl (Ping timeout: 240 seconds) |
03:03:56 | | Join ntkm [0] (~taku@bmdk6131.bmobile.ne.jp) |
03:19:40 | | Quit ntkm (Quit: ntkm) |
03:30:39 | | Quit bthomson (Quit: WeeChat 0.3.3-dev) |
03:34:17 | | Join bthomson [0] (~bthomson@c-68-33-5-232.hsd1.va.comcast.net) |
03:35:26 | | Quit bthomson (Client Quit) |
03:38:13 | | Join bthomson [0] (~bthomson@c-68-33-5-232.hsd1.va.comcast.net) |
04:00 |
04:04:11 | | Join mshathlonxp [0] (~athlonmpp@5ad7b04f.bb.sky.com) |
04:46:34 | | Quit amiconn (Disconnected by services) |
04:46:35 | | Join amiconn_ [0] (quassel@rockbox/developer/amiconn) |
04:46:53 | | Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) |
04:47:37 | | Quit pixelma (Disconnected by services) |
04:47:39 | | Join pixelma_ [0] (quassel@rockbox/staff/pixelma) |
04:47:41 | | Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) |
05:00 |
05:00:19 | | Quit TheSeven (Disconnected by services) |
05:00:33 | | Join [7] [0] (~TheSeven@rockbox/developer/TheSeven) |
05:03:10 | *** | Saving seen data "./dancer.seen" |
05:19:31 | | Quit Strife89 (Quit: Shutting down for the night.) |
05:23:36 | | Join [Saint] [0] (~st.lasciv@119.224.72.2) |
05:24:18 | | Join leif [0] (~leif@208.93.178.54) |
05:25:51 | | Quit [Saint] (Client Quit) |
05:27:57 | | Join [Saint] [0] (~st.lasciv@119.224.72.2) |
05:33:41 | | Join Rob2223 [0] (~Miranda@p4FFF29C2.dip.t-dialin.net) |
05:33:42 | | Quit ps-auxw (Ping timeout: 250 seconds) |
05:35:03 | | Quit leif (Quit: Leaving) |
05:35:48 | | Join ps-auxw [0] (~arneb@p4FF7F813.dip.t-dialin.net) |
05:37:43 | | Quit Rob2222 (Ping timeout: 258 seconds) |
05:45:50 | | Join antil33t [0] (~antil33t@124-197-33-15.callplus.net.nz) |
05:53:25 | | Join jackwade [0] (~jackwade@host-135-15-3-96.midco.net) |
05:56:28 | | Quit Llorean (Changing host) |
05:56:28 | | Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) |
05:56:36 | jackwade | I've had an issue with my Sansa Fuze V1 where it will randomly unmount from my OS. This wasn't an issue for the longest time on 3.7.1. It started happening with 3.8+ and is still occurring with 3.9. I did find a forum post on it a while back, but I can't seem to locate that again. I manually installed 3.7.1 and the issue came up again. This is not a problem on the original firmware from Sansa. Anyone have any suggestions on this? |
06:00 |
06:09:16 | [Saint] | So, you're saying it didn't used to happen with 3.7.1...but now it does? |
06:10:34 | jackwade | Yeah, which boggled my mind. Seems to happen only when transferred a large number of files (like several hundred music files for example). I believe I've experienced it at one point or another in Ubuntu 10.04, Debian 6, and Fedora 14. Could be something with my OS, may not happen in Windows. |
06:10:54 | [Saint] | That seems to point to your OS. |
06:11:05 | [Saint] | Nothing's changed with 3.7.1 |
06:11:15 | [Saint] | (that's quite literally impossible) |
06:11:40 | jackwade | Guess I'll review some system logs. Thanks for your assistance. |
06:16:57 | | Part jackwade |
06:26:55 | | Quit mshathlonxp () |
06:53:08 | | Join Horscht [0] (~Horscht@xbmc/user/horscht) |
06:56:05 | | Quit Horschti (Ping timeout: 240 seconds) |
07:00 |
07:03:14 | *** | Saving seen data "./dancer.seen" |
07:08:00 | | Join Darkknight512 [0] (~Darkknigh@CPE00212968356c-CM00186845dd46.cpe.net.cable.rogers.com) |
07:26:28 | | Join aetherian [0] (~aetherian@adsl-75-30-186-91.dsl.pltn13.sbcglobal.net) |
07:45:50 | | Join mshathlonxp [0] (~athlonmpp@5ad7b04f.bb.sky.com) |
08:00 |
08:02:11 | | Quit Llorean (Read error: Connection reset by peer) |
08:05:33 | | Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) |
08:11:19 | | Quit simonlnu (Read error: Connection reset by peer) |
08:12:40 | | Quit mystica555_ (Ping timeout: 240 seconds) |
08:14:52 | | Join ntkm [0] (~taku@bmdk6143.bmobile.ne.jp) |
08:15:10 | | Join robin0800 [0] (~robin0800@149.254.218.236) |
08:20:24 | | Join simonlnu [0] (IyQZMyLXdQ@unaffiliated/simonrvn) |
08:20:25 | | Quit ntkm (Quit: ntkm) |
08:43:05 | | Quit Zambezi (Changing host) |
08:43:05 | | Join Zambezi [0] (Zulu@unaffiliated/zambezi) |
08:47:16 | | Join stoffel [0] (~quassel@p57B4A584.dip.t-dialin.net) |
08:52:09 | | Join sideral [0] (~sideral@rockbox/developer/sideral) |
08:54:30 | | Quit aetherian (Read error: Connection reset by peer) |
09:00 |
09:03:18 | *** | Saving seen data "./dancer.seen" |
09:18:00 | | Quit robin0800 (Read error: Connection timed out) |
09:18:44 | | Join robin0800 [0] (~robin0800@genld-224-236.t-mobile.co.uk) |
09:29:01 | | Quit utanapischti (Quit: WeeChat 0.3.2) |
09:29:28 | | Join utanapischti [0] (~username@p4FF2D2AD.dip.t-dialin.net) |
09:48:18 | | Join esperegu [0] (~quassel@145.116.15.244) |
09:49:18 | | Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) |
09:50:03 | | Quit [Saint] (Quit: Imagination is for turbo-nerds who can't handle how kick-butt reality is. I'm a kick-butt reality master! I would rather die, than be imaginative. I mean that.) |
09:50:29 | | Quit robin0800 (Read error: Connection timed out) |
09:52:00 | | Join [Saint] [0] (~Saint]@119.224.72.2) |
10:00 |
10:06:23 | | Join robin0800 [0] (~robin0800@149.254.60.34) |
10:15:37 | | Quit stripwax (Quit: http://miranda-im.org) |
10:20:46 | | Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) |
10:46:58 | | Quit Unhelpful (Ping timeout: 255 seconds) |
10:49:40 | | Quit stripwax (Quit: http://miranda-im.org) |
11:00 |
11:03:21 | *** | Saving seen data "./dancer.seen" |
11:11:13 | | Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) |
11:49:06 | [Saint] | Anyone I pinged about it end up giving that RaaA theme a go? |
11:49:26 | [Saint] | ...I'm pondering last minute fixes, or just throwing it out to the wolves, so to speak. |
11:51:40 | | Quit jae (Ping timeout: 240 seconds) |
11:55:26 | | Quit robin0800 (Quit: Leaving) |
11:56:08 | | Join robin0800 [0] (~robin0800@149.254.61.162) |
12:00 |
12:03:49 | | Join jae [0] (~jae@dedicated.jaerhard.com) |
12:06:24 | | Quit jae (Read error: Operation timed out) |
12:12:56 | | Quit liar (Ping timeout: 258 seconds) |
12:13:10 | | Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) |
12:13:20 | | Quit robin0800 (Read error: Connection timed out) |
12:13:44 | | Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) |
12:14:10 | | Join robin0800 [0] (~robin0800@149.254.61.162) |
12:15:23 | | Join jae [0] (~jae@dedicated.jaerhard.com) |
12:20:22 | | Join pamaury [0] (~quassel@vit94-1-82-67-248-70.fbx.proxad.net) |
12:20:23 | | Quit pamaury (Changing host) |
12:20:23 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
12:26:01 | | Quit [Saint] (Remote host closed the connection) |
12:27:17 | | Join [Saint] [0] (~st.lasciv@119.224.72.2) |
12:28:49 | | Quit stoffel (Read error: Operation timed out) |
12:31:15 | | Quit antil33t () |
12:43:53 | | Quit robin0800 (Read error: Connection timed out) |
12:44:47 | | Join robin0800 [0] (~robin0800@149.254.60.162) |
12:58:33 | | Quit mshathlonxp () |
13:00 |
13:01:08 | | Join stoffel [0] (~quassel@p57B4A584.dip.t-dialin.net) |
13:03:23 | *** | Saving seen data "./dancer.seen" |
13:04:40 | | Quit bieber (Ping timeout: 255 seconds) |
13:04:58 | | Join bieber [0] (~quassel@162-78.97-97.tampabay.res.rr.com) |
13:07:44 | | Join GermanMushroom [0] (~c@s5146db6a.adsl.wanadoo.nl) |
13:20:39 | | Quit bieber (Ping timeout: 260 seconds) |
13:23:19 | | Quit GermanMushroom (Quit: Ik ga weg) |
13:23:22 | | Join bieber [0] (~quassel@162-78.97-97.tampabay.res.rr.com) |
13:23:29 | | Join GermanMushroom [0] (~c@s5146db6a.adsl.wanadoo.nl) |
13:24:31 | | Quit bzed (Remote host closed the connection) |
13:24:54 | | Quit robin0800 (Read error: Connection timed out) |
13:26:56 | | Join robin0800 [0] (~robin0800@149.254.61.162) |
13:27:47 | | Join bzed [0] (~bzed@devel.recluse.de) |
13:31:38 | | Join fyre^OS [0] (~nnscript@cpe-24-90-84-81.nyc.res.rr.com) |
13:35:16 | | Quit fyrestorm (Ping timeout: 276 seconds) |
13:39:11 | | Quit bieber (Ping timeout: 240 seconds) |
13:39:39 | | Join bieber [0] (~quassel@162-78.97-97.tampabay.res.rr.com) |
14:00 |
14:01:58 | | Quit stoffel (Ping timeout: 240 seconds) |
14:10:49 | | Join n1s [0] (~quassel@rockbox/developer/n1s) |
14:18:37 | | Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) |
14:20:48 | | Join evilnick [0] (~evilnick@rockbox/staff/evilnick) |
14:25:41 | | Quit user890104 () |
14:27:36 | | Quit bieber (Ping timeout: 252 seconds) |
14:28:00 | | Join bieber [0] (~quassel@162-78.97-97.tampabay.res.rr.com) |
14:37:10 | | Quit bieber (Ping timeout: 240 seconds) |
14:37:45 | | Join bieber [0] (~quassel@162-78.97-97.tampabay.res.rr.com) |
14:38:00 | soap | are there any AA fonts in the font pack? I don't see any labeled as such. |
14:38:52 | | Quit robin0800 (Read error: Connection timed out) |
14:39:49 | | Join robin0800 [0] (~robin0800@149.254.61.162) |
14:40:37 | [Saint] | soap: No, there's not. |
14:40:43 | soap | Or is gbl08ma's font pack the only (outside [Saint]'s droid pack) ones distributed? |
14:41:26 | [Saint] | I didn't even know gbl08ma's pack myself, and I wouldn't call mine "distributed". |
14:41:34 | [Saint] | just a few people happen to have it ;) |
14:42:50 | soap | you link it in the forums. |
14:44:01 | [Saint] | Ah, so I do. The link may or may not still be active though, depends how much attention it gets. I don't put any permanent links on the forums. |
14:44:10 | [Saint] | they all die after 30 days if there's no activity. |
14:44:38 | soap | what font do you use on the nano, [Saint] ? |
14:45:08 | soap | the AA fonts appear a bit too defocused on such a small low-density screen from what little I've played with DroidSans. |
14:45:15 | [Saint] | I use a anti-alised Myriad clone. |
14:45:42 | [Saint] | (closest I ever found to the Apple OF) |
14:45:51 | soap | link? |
14:49:51 | [Saint] | http://www.datafilehost.com/download-92632e74.html <−− Link to the whole theme, easy enough to pull the fonts out though. There's 16 & 20 (iirc) pt fonts in there, but it's really the same font with two different ascent/descent levels to space the lines more "OF-esque" |
14:51:49 | | Quit robin0800 (Ping timeout: 250 seconds) |
14:52:58 | soap | thank you. |
14:53:41 | soap | In other news I'm seeing the "error accessing playlist control file" error for the first time in years on my Nano. I see while browsing the menus a few seconds after ejecting my Nano 1G. |
14:54:00 | soap | Not seeing any relevant hits in the forums. |
14:54:32 | [Saint] | Hmmmm....odd, I just updated the builds on all my devices a few hours ago and did my usual "does everything I care about work" tests, and all seems fine here. |
14:54:36 | | Join stoffel [0] (~quassel@p57B4A584.dip.t-dialin.net) |
14:54:40 | [Saint] | I'll chime in if I do see that, though. |
15:00 |
15:03:27 | *** | Saving seen data "./dancer.seen" |
15:04:20 | | Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) |
15:10:58 | | Join robin0800 [0] (~robin0800@genld-217-248.t-mobile.co.uk) |
15:18:57 | | Quit evilnick (Quit: Leaving) |
15:30:10 | | Join FoH [0] (~foh@adsl-98-71-68-244.bhm.bellsouth.net) |
15:32:28 | | Quit FoolOnHill (Ping timeout: 276 seconds) |
15:34:28 | | Join user890104 [0] (~Venci@212.233.243.54) |
15:38:02 | | Quit bieber (Read error: Connection reset by peer) |
15:40:55 | | Join bieber [0] (~quassel@162-78.97-97.tampabay.res.rr.com) |
15:41:04 | | Quit user890104 () |
15:46:22 | | Quit stoffel (Ping timeout: 246 seconds) |
15:47:43 | | Quit bieber (Ping timeout: 250 seconds) |
15:48:35 | | Join bieber [0] (~quassel@162-78.97-97.tampabay.res.rr.com) |
15:50:55 | JdGordon | kugel: with buflib,how safe is loading *stuff* into a handle from disk going to be? |
15:51:22 | JdGordon | i.e loading a jpeg into a handle... will we be able to lock the buffer to make sure no movement happens temporarily? |
15:54:31 | AlexP | We should put some aa fonts into the font pack, but I guess that means generating them at build time |
15:54:42 | AlexP | As IIRC we store the bdf in svn |
15:55:34 | | Join crwl [0] (~crwlll@dsl-jklbrasgw1-ffb9c300-103.dhcp.inet.fi) |
15:55:43 | | Join Slackware [0] (~Venci@212.233.243.54) |
15:56:07 | | Nick Slackware is now known as user890104 (~Venci@212.233.243.54) |
15:57:50 | gevaerts | JdGordon: there's a callback you can register with the allocation, and that callback can refuse the move |
15:58:33 | JdGordon | ok cool |
15:58:40 | gevaerts | Well, something like that anyway |
15:58:48 | gevaerts | I can't remember the exact details |
15:58:58 | JdGordon | I'm pretty sure i can move all the big allocations out of a static buffer as long as loading stuff from disk into a handle is safe |
15:59:02 | JdGordon | i.e images |
16:00 |
16:00:25 | JdGordon | anyone got the link to [Saint]'s cabbie theme? |
16:00:29 | JdGordon | i cant find it in the logs |
16:03:04 | * | Torne pushes 216388 objects onto gerrit :) |
16:03:19 | JdGordon | ah, found t :) |
16:03:26 | pamaury | see ya next week Torne :) |
16:03:48 | Torne | it's only 130odd meg, it's not that bad :) |
16:04:28 | AlexP | Torne: What is the status? All pretty much ready, just need to sort out things like hosting, build server, script integration etc. with el Swedos? |
16:04:37 | Torne | AlexP: pretty much. |
16:04:47 | pamaury | I still didn't try gerrit :) |
16:04:48 | Torne | I am pushing the mirror to gerrit now |
16:04:50 | AlexP | Righto |
16:04:54 | Torne | it'll be read-only |
16:04:58 | | Join hobby16 [0] (~ubuntu@157.186.193.77.rev.sfr.net) |
16:05:00 | Torne | no changes, no reviews, no nothing |
16:05:10 | pamaury | why isn't the website showing the commits ? |
16:05:12 | Torne | in case of needing to blow it away :) |
16:05:19 | Torne | pamaury: hm? |
16:05:46 | pamaury | the main page doesn't show the commit list |
16:05:53 | Torne | main page of what? |
16:06:01 | pamaury | rockbox.org !! |
16:06:04 | Torne | Oh. |
16:06:05 | Torne | Er |
16:06:15 | Torne | sorry, i thought you were talking abotu gerrit :) |
16:06:18 | Torne | i don't know ;) |
16:06:33 | Torne | svn server is reachable just fine |
16:07:22 | pamaury | yes but the main page doesn't show anything |
16:07:32 | gevaerts | kugel: according to proposed-api.h shrink_callback() can return BUFLIB_CB_CANNOT_SHRINK, but move_callback() is only allowed to return BUFLIB_CB_OK. This seems to mean that it's only possible to disable moving by not providing the callback at all. That's a bit annoying for the case JdGordon just mentioned (allocation can't move because of pending IO for some of the time, but can be moved at any other time) |
16:07:35 | pamaury | and http://www.rockbox.org/recent.shtml#svn is stuck at r30107 |
16:09:09 | JdGordon | kugel: gevaerts: I would have expected a simple lock to outright dissalow any allocation movement for a small amount of time, of course requiring that no allocations happen while the lock is held |
16:09:43 | JdGordon | I want to make sure no yields will cause dangerous pointers while im waiting for i/o to load into a preallocated bufffer |
16:11:03 | | Quit robin0800 (Ping timeout: 244 seconds) |
16:11:41 | | Join robin0800 [0] (~robin0800@genld-217-248.t-mobile.co.uk) |
16:12:33 | gevaerts | JdGordon: a global lock seems a bit dangerous to me |
16:13:13 | gevaerts | Just locking the allocation you're using for IO should be enough, and allowing this callback to say no would achieve that |
16:13:18 | JdGordon | how is it different to a brokem callback? |
16:13:42 | JdGordon | ok, even a local lock would be fine |
16:13:55 | JdGordon | I dont see why the extra hassle of a callback is required |
16:13:56 | gevaerts | Not that sort of dangerous. I'm more thinking of things like priority inversion issues |
16:14:16 | JdGordon | buflib_lock(handle); buflib_unlock(handle) |
16:14:25 | gevaerts | That would work |
16:14:44 | JdGordon | setting up a callback just for this seems like pointless overengineering |
16:16:04 | gevaerts | It depends. I don't know how many users will use the callback as things stand now |
16:16:45 | gevaerts | But extra locking functions aren't expensive either, so it probably makes sense to add those to the API anyway |
16:19:32 | | Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel) |
16:20:00 | JdGordon | then I'd worry about api bloat and confusiont here |
16:20:10 | gevaerts | Why? |
16:20:21 | JdGordon | two ways to do the same thing |
16:20:23 | kugelp | JdGordon, gevaerts: there's only a lock if you grab the entire buffer |
16:20:41 | | Join mystica555_ [0] (~Mike@71-208-221-175.hlrn.qwest.net) |
16:21:16 | gevaerts | JdGordon: right, so the callback would stay the way it is now |
16:22:31 | | Quit mystica555 (Ping timeout: 276 seconds) |
16:25:03 | JdGordon | kugelp: finer locking is going to be needed or it limits buflibs usefulness alot |
16:25:16 | JdGordon | unless you want to load images to a temp buffer then memmove it into the handle? |
16:26:30 | kugelp | gevaerts: I actually had the idea of letting teh callback say to not move right now, but it then didn't seem needed and prone to deadlocks |
16:26:43 | | Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel) |
16:28:10 | kugel | locking single handles can create holes so I'm not a fan of that |
16:28:22 | JdGordon | temp locking |
16:28:24 | gevaerts | So how would you handle this case? |
16:29:34 | gevaerts | The alternative to temporarily locking the handle seems to be to not allow it to move at all... |
16:29:58 | | Join user890104_ [0] (~Venci@95.43.115.233) |
16:30:07 | | Quit user890104 (Ping timeout: 246 seconds) |
16:30:52 | gevaerts | Whether you implement locking using lock/unlock or refusing a move is purely a syntactic difference I think. It doesn't change anything to when you can move what |
16:31:19 | | Join user890104 [0] (~Venci@212.233.243.54) |
16:31:41 | Torne | OK, there are now four new projects on gerrit: rockbox, www, themesite and translate |
16:31:48 | Torne | rockbox is pushed, the other three are uploading now |
16:31:53 | Torne | They should contain everything that's in svn |
16:32:02 | Torne | they are *not* automatically being updated at present |
16:32:03 | JdGordon | can we split langs out of apps/? |
16:32:05 | Torne | but they are up to date right now |
16:32:25 | Torne | JdGordon: in future, possibly; let's please not do that right now :) |
16:32:34 | JdGordon | hehe ok |
16:32:59 | Torne | they're read only but you should be able to clone them and fiddle |
16:33:13 | kugel | in the move callback you can do while(!done) yield(). but that only works if the compaction is caused by a different thread |
16:33:16 | | Join mystica555 [0] (~mike@71-208-221-175.hlrn.qwest.net) |
16:33:20 | Torne | git ls-remote will show you the full list of refs on the repos, also, if you want to see which ones exist but don't get cloned automatically |
16:33:48 | gevaerts | kugel: that seems dangerous |
16:33:55 | JdGordon | *inasnely* dangerous |
16:34:02 | | Quit user890104_ (Ping timeout: 240 seconds) |
16:34:28 | gevaerts | I'd rather specify that the move callback isn't allowed to do that sort of thing |
16:34:40 | kugel | doing anything else in the callback to disallow movement will make the allocation fail |
16:34:51 | | Join user890104_ [0] (~Venci@213.226.63.147) |
16:34:59 | gevaerts | kugel: you can handle non-movable allocations, right? |
16:35:10 | kugel | yes |
16:35:33 | kugel | specifying NULL for the move callback will make it unmoveable |
16:35:53 | | Quit user890104 (Ping timeout: 258 seconds) |
16:35:55 | gevaerts | Then does adding the lock/unlock functions and adding a flag really change things for the compaction bits? |
16:36:04 | kugel | but I wished that only the actually audio buffer is unmoveable |
16:36:51 | gevaerts | Well, you can't yielding IO to an actual movable buffer... |
16:36:59 | kugel | perhaps I didn't understand the use case yet |
16:37:13 | gevaerts | The usecase is read() :) |
16:37:17 | JdGordon | woah.... kugel, my use case isnt for when a new allocation is being handled... im talking about once a handle is fully allocated and i want to load a jpeg into it. either the jpeg loading code needs to know about handles, or the buffer needs to keep that handle static *temporairly*... no other alocations should be happening then |
16:38:27 | Torne | ok, all pushed :) |
16:40:32 | gevaerts | kugel: how do you handle things like loading the dircache dump from disk? |
16:40:45 | gevaerts | Or loading the database into RAM |
16:43:22 | | Quit Guinness (Ping timeout: 255 seconds) |
16:43:58 | kugel | not at all yet :) |
16:44:05 | kugel | I mean, I didn't enable compaction yet |
16:44:12 | gevaerts | Well yes |
16:44:33 | gevaerts | What's the plan for that? :) |
16:45:31 | kugel | well, perhaps we need a buflib_lock(), but what to do about allocations that can happen in the meantime? |
16:45:40 | kugel | failure or waiting for unlock? |
16:46:19 | gevaerts | Depends. Depending on which buffer is locked, you might be able to do some compaction |
16:46:33 | gevaerts | Otherwise, waiting should work |
16:46:42 | JdGordon | grrr... this isnt about compaction per-se |
16:47:21 | kugel | movement can only be caused by compaction, which can only be caused by a new allocation |
16:48:00 | kugel | gevaerts: "some compaction" means holes? |
16:48:15 | JdGordon | that can't be guarenteed forever |
16:48:18 | gevaerts | yes |
16:48:31 | kugel | buflib doesn't deal with holes very well (because in its current form it's impossible to have holes) |
16:48:37 | | Quit robin0800 (Read error: Connection reset by peer) |
16:48:50 | gevaerts | It will likely clean up the holes at the next compaction |
16:48:51 | kugel | I'd like to stay that way |
16:49:00 | | Join robin0800 [0] (~robin0800@genld-218-248.t-mobile.co.uk) |
16:49:03 | gevaerts | The locks we're talking about aren't meant to be held very often |
16:49:36 | kugel | I added smarts to it for unmoveable buffers so in my working tree it can create holes |
16:50:15 | gevaerts | When do you plan to do compaction? On allocation, or on deallocation? |
16:50:23 | kugel | on allocation |
16:50:30 | gevaerts | Then you'll have holes anyway |
16:50:36 | kugel | that's how it works currently |
16:50:48 | gevaerts | So I don't see the problem really |
16:51:34 | JdGordon | I'm also not talking about unmovable handles. just that some handles will need to not move while they are being setup |
16:52:46 | AlexP | Can anyone tell me what I'm missing here (build failing): http://pastie.org/2158635 Perl was updated on my system a few days ago which I guess is the issue |
16:55:30 | kugel | gevaerts: I would like to avoid locks because I fear they get over-used because it's convinient |
16:55:57 | gevaerts | kugel: that's all very nice, but you still haven't said what you'll do instead :) |
16:56:03 | | Join robin0800_ [0] (~robin0800@genld-218-248.t-mobile.co.uk) |
16:57:56 | kugel | JdGordon: unmoveable is easy, specify NULL for the move callback |
16:58:07 | JdGordon | thats not what im asking about though |
16:58:08 | | Quit robin0800 (Ping timeout: 252 seconds) |
16:58:11 | kugel | if it's temporarily it'll be handled by later compaction |
16:59:36 | | Join Guinness [0] (Slayer@c-68-55-111-159.hsd1.va.comcast.net) |
16:59:48 | JdGordon | last try before i go to bed... we need a way to guarentee that a pre-allocated handles pointer will not change for a small amount of time - regardless of whatever else the buffer is doing - while we do I/O |
16:59:58 | JdGordon | afterwards the handle is free to move |
16:59:58 | kugel | so you want unmoveable in the beginning, but later make them moveable? |
17:00 |
17:00:18 | gevaerts | kugel: not just at the beginning I think. You want to write some buffers too near shutdown |
17:00:39 | gevaerts | Like the font cache |
17:00:42 | kugel | we can put that into the move callback, but that could make allocations fail |
17:01:19 | JdGordon | fail with EBUFFERBUSY |
17:01:24 | JdGordon | instead of EBUFFERFULL |
17:01:36 | gevaerts | Using a trivial compactor implementation, yes. Later on a smarter compactor could fix that |
17:01:42 | kugel | isn't EAGAIN for that already? :) |
17:02:49 | gevaerts | And I much prefer this to a situation where buflib isn't usable for anything that does IO, which is just about everything that uses large buffers |
17:03:15 | kugel | so yea, that should be easy to implement (and as I said, I already had that shortly when I thought about the API) |
17:03:28 | *** | Saving seen data "./dancer.seen" |
17:04:10 | kugel | with knowledge about threads buflib could wait for the unlock instead of failing |
17:04:14 | JdGordon | err... wait a seccy... we need to register a callback for every handle allocation we allow to move? |
17:04:32 | gevaerts | kugel: that would be easy to do if you have lock/unlock functions |
17:04:41 | kugel | JdGordon: no, there's a default callback |
17:07:50 | | Quit [Saint] (Ping timeout: 252 seconds) |
17:13:34 | kugel | gevaerts: I meant without those functions |
17:13:53 | kugel | just record the thread id with the allocation |
17:14:45 | gevaerts | You really prefer that sort of restriction over locking functions? |
17:14:56 | kugel | what restriction? |
17:15:30 | gevaerts | You then have to do the allocation from the same thread as using the memory |
17:16:07 | kugel | hmm, I didn't think it was a restriction, but perhaps it is |
17:16:42 | | Quit user890104_ () |
17:17:11 | gevaerts | I'd say it violates the principle of least surprise you want in APIs |
17:17:16 | kugel | but I would rather not create a convinient way to block out compaction entirely :\ |
17:18:07 | kugel | but I also must say that I prefered discussion about the API when I specifically asked for it |
17:18:10 | gevaerts | I think not having lock functions will make it more likely to introduce interesting bugs due to people working around it in an incorrect way |
17:18:14 | kugel | not a month later |
17:18:23 | gevaerts | Oh, I don't disagree there |
17:18:46 | CIA-14 | New commit by pamaury (r30120): imx233/fuze+: replace software i2c by hardware i2c, make some code more correct, reduce code size of lcd init sequences |
17:19:41 | gevaerts | It's less than ideal, and it may well cause extra work, but now that we know about the problem it would be a bad idea not to solve it properly |
17:20:41 | kugel | pamaury: didn't you say on the devcon that you're happy with the sw i2c and dislike all the different implementations? |
17:21:03 | pamaury | yes until I discover that it didn't do clock stretching |
17:21:22 | kugel | i think you forgot to add the file |
17:21:25 | pamaury | so I did my owm implementation using the hardware |
17:21:48 | kugel | so we have 2 more now, wodz also made one |
17:22:10 | CIA-14 | New commit by pamaury (r30121): imx233: add missing i2c file |
17:22:49 | | Quit Darkknight512 (Ping timeout: 240 seconds) |
17:22:56 | CIA-14 | r30120 build result: All green |
17:24:15 | kugel | gevaerts: perhaps, instead of lock/unlock, a function to set the callbacks? the result should be the same |
17:25:02 | | Quit ender` (Read error: Connection reset by peer) |
17:25:37 | | Join ender` [0] (krneki@foo.eternallybored.org) |
17:25:44 | kugel | but without two ways of making a handle unmovable and no new metadata |
17:26:15 | gevaerts | kugel: I tend to see locking functions as easier to use correctly |
17:26:22 | | Quit simabeis (Read error: Operation timed out) |
17:26:50 | | Quit kkit|sh (Read error: Operation timed out) |
17:27:00 | CIA-14 | r30121 build result: All green |
17:27:29 | kugel | gevaerts: how? |
17:27:59 | kugel | lock vs set_cbs(no_move_cbs) and unlock vs set_cbs(move_cbs) |
17:28:28 | kugel | (un)lock(handle) even |
17:28:59 | gevaerts | kugel: assuming the default callback, those are indeed rather similar, but code that has a real callback basically has to reimplement locking functions |
17:29:23 | kugel | no, no_move_cbs will contain NULL |
17:29:33 | | Join kkit|sh [0] (~kkit@li135-248.members.linode.com) |
17:29:33 | kugel | and I rather have it less convinient to do locking, indeed |
17:29:45 | gevaerts | ah, right |
17:29:56 | | Quit preglow (Ping timeout: 258 seconds) |
17:30:06 | gevaerts | Also, lock/unlock functions allow you to get the thread id realiably |
17:30:20 | | Join simabeis [0] (~simabeis@lobmenschen.de) |
17:30:21 | | Join preglow [0] (thomj@tvilling2.pvv.ntnu.no) |
17:31:37 | kugel | not really, as they're interchangable |
17:31:39 | gevaerts | And I'm really worried that trying to make locking non-obvious to avoid extraneous locking will lead to missing needed locks |
17:32:11 | kugel | in fact, I would probably implement the lock by setting a NULL move callback |
17:32:30 | kugel | but doing it internally is harder because the original needs to be stashed somewhere |
17:32:31 | gevaerts | They're not. Calling buflib_lock() implies a contract that you're going to call buflib_unlock() at some point |
17:32:59 | gevaerts | While setting a callback does no such thing |
17:33:35 | kugel | there doesn't need to be such a contract |
17:34:13 | kugel | you can alloc with no_move_cbs and allow move later with move_cbs |
17:34:39 | kugel | i.e. you don't have an explicit lock call |
17:34:40 | gevaerts | Yes, and then you can set no_move_cbs again |
17:34:48 | gevaerts | And then leave it that way |
17:35:28 | kugel | yea, why not |
17:35:46 | gevaerts | And then you can't wait anymore in an allocation |
17:36:01 | kugel | so we don't wait, it |
17:36:13 | kugel | it's potentially troublesome anyway |
17:36:45 | gevaerts | All that for the very doubtful "advantage" of trying to hide the fact that you can lock a buffer... |
17:37:06 | * | gevaerts still doesn't see *any* advantage in not having lock/unlock functions, while he does see some disadvantages |
17:38:00 | kugel | what I propose is already implemented, basically |
17:38:43 | gevaerts | Those locking functions are ten lines of code |
17:39:25 | kugel | I see on advantage in the locking functions, but I see that they make it easy to over use locking |
17:39:44 | kugel | no* |
17:40:00 | kugel | locking and setting a no_move_cbs is the same thing |
17:40:42 | gevaerts | Except that you make it (possibly a lot) harder to change the implementation later on |
17:41:09 | gevaerts | And I really don't see why avoiding some subobtimal code trumps avoiding actual bugs |
17:43:10 | * | kugel doesn't see actual bugs :) |
17:43:13 | gevaerts | A missing lock will lead to an unreproducible crash |
17:43:27 | gevaerts | And your design is meant to encourage those |
17:43:43 | kugel | why do you think that? |
17:44:55 | gevaerts | Making sure people don't lock too often by making it non-obvious that one *can* lock directly implies that |
17:46:59 | kugel | well, it would be documented that this can be used to lock |
17:47:47 | kugel | yes, it would be less obvious, but not hidden for someone seeking for locking |
17:49:13 | * | gevaerts thinks that he and kugel have somewhat opposite views on this, so he thinks it would be useful if other people also said something... |
17:50:32 | * | pamaury didn't follow and think the mailing list is better for that |
17:51:51 | * | kugel isn't going to discuss this to death and would go with lock/unlock if it's really prefered |
18:00 |
18:16:17 | n1s | i think lock/unlock is more obvious than changing the callbacks |
18:19:54 | | Quit balintx (Ping timeout: 260 seconds) |
18:23:25 | | Join kugel_ [0] (~kugel@rockbox/developer/kugel) |
18:24:10 | | Quit kugel (Read error: Operation timed out) |
18:25:21 | | Join MethoS- [0] (~clemens@134.102.106.250) |
18:26:17 | | Join balintx [0] (~quassel@szerver1.gulyasp-koll.sulinet.hu) |
18:26:18 | | Join mudd1 [0] (~cmertes@a253-10.24online.fi) |
18:34:11 | | Quit robin0800_ (Ping timeout: 258 seconds) |
18:39:43 | | Quit balintx (Ping timeout: 264 seconds) |
18:40:26 | | Quit jae (Ping timeout: 252 seconds) |
18:44:58 | | Join stoffel [0] (~quassel@p57B4A584.dip.t-dialin.net) |
18:45:12 | | Nick kugel_ is now known as kugel (~kugel@rockbox/developer/kugel) |
18:46:11 | kugel | n1s: yes, undoubtedly :) |
18:46:40 | | Join balintx [0] (~quassel@szerver1.gulyasp-koll.sulinet.hu) |
18:47:27 | | Join jae [0] (~jae@dedicated.jaerhard.com) |
18:47:59 | | Join Strife89 [0] (~Strife89@207-144-19-39.cstel.net) |
19:00 |
19:03:30 | *** | Saving seen data "./dancer.seen" |
19:03:35 | | Join keyb_gr [0] (~chatzilla@p4FF05AE7.dip.t-dialin.net) |
19:03:49 | | Quit bluebrother (Disconnected by services) |
19:03:51 | | Join bluebroth3r [0] (~dom@rockbox/developer/bluebrother) |
19:10:31 | | Quit hobby16 (Ping timeout: 250 seconds) |
19:23:35 | | Join keyb_gr_ [0] (~chatzilla@p4FF04B15.dip.t-dialin.net) |
19:24:56 | | Quit keyb_gr (Ping timeout: 258 seconds) |
19:25:01 | | Nick keyb_gr_ is now known as keyb_gr (~chatzilla@p4FF04B15.dip.t-dialin.net) |
19:31:01 | | Quit stoffel (Remote host closed the connection) |
19:42:36 | | Join T44 [0] (~Topy44@f048017039.adsl.alicedsl.de) |
19:42:43 | | Join Thra11 [0] (~thrall@84.93.181.188) |
19:59:31 | | Quit Strife89 (Quit: Heading out) |
20:00 |
20:06:36 | | Quit GermanMushroom (Read error: Connection reset by peer) |
20:13:28 | | Join guymann_ [0] (~charles@66-159-173-254.adsl.snet.net) |
20:14:18 | | Quit guymann (Ping timeout: 240 seconds) |
20:41:45 | rasher | AlexP: Llorean |
20:42:00 | rasher | OVER HERE |
20:42:08 | AlexP | watcha |
20:42:13 | rasher | Why would we close up flyspray in favour of the mailing list? Makes no sense to me |
20:42:24 | AlexP | One moment |
20:42:30 | rasher | One convenient method, closed in favour of a massively inconvenient one |
20:42:33 | Llorean | It seems like needlessly closing a channel for people to contribute. |
20:43:14 | Llorean | Basically, "let's make it more inconvenient for people who don't want to use git right now" |
20:43:42 | AlexP | In your opinion |
20:43:43 | gevaerts | How are we doing that? |
20:44:03 | AlexP | Plenty of people (in fact the majority since it was passed) find the mailing list more convenient |
20:44:09 | gevaerts | The point is to close a way for people to have their patches ignored |
20:44:17 | | Join user890104 [0] (~Venci@6bez10.info) |
20:44:50 | rasher | What are you talking about |
20:44:51 | AlexP | I'm not too bothered personally, so am not the best person to put forward the arguments |
20:45:05 | Llorean | AlexP: If it's more convenient, why has less than 5% of total patches come from it? |
20:45:17 | rasher | Plenty of patches from flyspray get committed |
20:45:22 | AlexP | Llorean: Because we point people at flyspray |
20:45:28 | rasher | and it's not like we'll suddenly be better at committing patches |
20:45:30 | gevaerts | Flyspray creates the expectation that people will deal with patches, which in many cases doesn't happen |
20:45:39 | AlexP | But a significant feeling was that flyspray is pointless and just lets patches rot, and the turn around would be better via a mailing list |
20:45:45 | AlexP | As I say, I don't care |
20:45:49 | Llorean | gevaerts: And they'll be just as ignored on the mailing list, with the exception of now it's also harder to find old patches. |
20:45:50 | AlexP | I'll ignore both :) |
20:46:03 | rasher | gevaerts: So what, we just end up opening another way for people to get their patches ignored |
20:46:07 | Llorean | On flyspray at least it's sortable, searchable, and has a UI |
20:46:11 | rasher | *AND* make it harder to follow up and search for them |
20:46:19 | rasher | What the hell is the point of that |
20:46:22 | Llorean | If we had a UI for the ML that let people search for threads with patches attached, etc, my opinion would be different. |
20:46:25 | Llorean | It's the UI that's the issue. |
20:46:34 | AlexP | rasher: And no, it was decided at devcon isn't a good reason at all (or any reason). However seeing as all we ever do is argue and nobody can ever reach consensus, one of its roles it to take decisions |
20:46:55 | Llorean | Both will be ignored, but when you *don't* want to ignore things, it's easier to find on Flyspray (especially if you weren't already subscribed to the list) |
20:46:57 | * | rasher disagrees |
20:47:22 | gevaerts | rasher: so we shouldn't have decisions? |
20:47:25 | rasher | Rockbox should be run by the developers. Not the developers with cash and opportunity to go to devcon |
20:47:26 | Llorean | AlexP: If their role is to make decisions, their role is to also clearly express those decisions to us afterward in a way that explains the full reasoning. |
20:47:30 | AlexP | I suggest that given that a couple of the proponents of the mailing list were B4gder and Zagor who aren't here, that if you would like you should take this to the mailing list |
20:47:39 | AlexP | Llorean: yes, this is true |
20:47:47 | rasher | gevaerts: Not what I said. |
20:47:51 | AlexP | rasher: OK, send it to the RSB |
20:47:52 | Llorean | This clearly wasn't done about this issue, or we'd have a place you could point us to reference. |
20:48:03 | AlexP | Llorean: Yes, true |
20:48:15 | gevaerts | rasher: so how *do* we take decisions? |
20:48:22 | AlexP | gevaerts: We don't, we argue |
20:48:31 | Llorean | Maybe the RSB should come up with how decisions should be made at DevCon. It is a little unfair that money means decision making power. |
20:48:33 | rasher | Well apparently by seeing who will pay to get to take them |
20:48:51 | AlexP | Don't be silly |
20:48:58 | Llorean | Perhaps devcon pounds out both sides to determine what the issue *is* then at the end sends out a survey mail to committers / devs so we can have a proper vote on things. |
20:49:10 | rasher | AlexP: well it's what's happening |
20:49:13 | AlexP | There is also the option to be online during devcon |
20:49:20 | AlexP | I realise this isn't always possible either |
20:49:22 | Llorean | AlexP: That's not a real, good option. |
20:49:28 | AlexP | But you can never get everyone together |
20:49:35 | Llorean | During devcon people watching online miss a good portion of what goes on |
20:49:38 | AlexP | So, take it to the RSB |
20:49:41 | rasher | AlexP: sure we can. On the ML |
20:49:45 | Llorean | mic pickups can't pick up everything, or isn't even on for a while. |
20:49:51 | AlexP | rasher: That never gets anywhere |
20:50:01 | AlexP | At some point you have to take a decision |
20:50:08 | rasher | Right, so we're back at the people with the money take the decisions |
20:50:16 | gevaerts | rasher: the mailing list was going to be my example of how we *don't* take decisions |
20:50:40 | Llorean | rasher: Just as a point, not just the money but proximity to the location chosen since the financial burden steepens alot the further you are away. |
20:50:56 | AlexP | In fact, I'll take it to the RSB |
20:51:01 | Llorean | But I don't think it should be discussed on the ML necessarily, at least not the way we normally do. |
20:51:04 | AlexP | I'll send them an email, they can decide |
20:51:25 | Llorean | Discussion could happen at DevCon, where it's 'easier', then put it to a vote with a record of the arguments for both sides and what has been hammered out. |
20:51:26 | rasher | CC the -dev ml |
20:51:28 | rasher | please |
20:51:49 | AlexP | er, that isn't necessarily part of the RSB |
20:51:53 | AlexP | it depends what I ask |
20:51:59 | gevaerts | Llorean: what if there is a consensus at devcon? Who's going to present the opposing side's case? |
20:52:02 | AlexP | But should be fine here |
20:52:11 | | Join Topy [0] (~Topy44@f048017039.adsl.alicedsl.de) |
20:52:36 | rasher | gevaerts: as if that's going to happen |
20:52:45 | AlexP | gevaerts: Would you prefer two emails for the two issues? One if devcon can take decisions and two on the mailing list vs flyspray? |
20:52:46 | Llorean | gevaerts: If there's a unanimous consensus at devcon, the issue probably wouldn't have made it to *needing* discussion at devcon |
20:53:06 | Llorean | gevaerts: If it wasted time at devcon when everyone already agreed on it, that's poor management of the limited time you guys have to go over things. |
20:53:21 | gevaerts | rasher: as if what is going to happen? |
20:53:29 | AlexP | Time is "wasted" discussing the issues to decide that everyone agrees |
20:53:39 | rasher | gevaerts: consensus on a contentious issue |
20:53:51 | AlexP | It has on plenty in the past at devcon |
20:54:01 | gevaerts | rasher: you've never seen devcon results? |
20:54:21 | AlexP | Loads of previously contentious issues have been decided at devcon |
20:54:21 | * | gevaerts doesn't see the point of discussing things with alternate universe inhabitants |
20:54:30 | Llorean | If everyone actually agrees, but they didn't initially, that means both sides *did* get discussed and can be presented. |
20:54:46 | | Quit Topy (Read error: Connection reset by peer) |
20:54:46 | rasher | I guess I wouldn't know, as one of the plebs |
20:54:51 | n1s | i tink it's quite natural that the people parttaking in the discussions at a devcon can make decisions |
20:54:52 | Llorean | If the issue was contentious, you present the ideas that caused people to object about it, and the way they were addressed. |
20:54:56 | gevaerts | Llorean: it also means several people now believe that their previous arguments are invalid |
20:55:20 | Llorean | gevaerts: Maybe not invalid. Usually you address them by finding a solution. But if they are invalid, you can give the reasons why they were found to be invalid so that readers can make up their own minds. |
20:55:39 | n1s | but this is always the case with our "discussions", people miss them and jump in after weeks have passed |
20:55:41 | Llorean | Just because the people at devcon found out they were invalid doesn't mean other people won't think they *are* valid until they hear/see similar reasoning |
20:55:49 | | Quit T44 (Ping timeout: 255 seconds) |
20:56:16 | Llorean | n1s: In the case of devcon though, if they're going to be changing fundamental things like the patch submission process I think they have a responsibility to make it well known *why* they're doing it, rather than just saying "as a group we decided to" |
20:56:35 | rasher | Rather than "This is what we decided", it should be "Here's what we think we should do. Here's why, here's the opposing views. What should we actually do?" |
20:56:39 | Llorean | In the case of discussions on the mailing list, you can just point people back at it. When a large portion of it was live, someone needs to step up and make it clear. |
20:56:54 | AlexP | rasher: That doesn't work |
20:57:24 | Llorean | I think devcon could easily come up with a proposed solution that becomes *the* solution if we as a group spend too long being indecisive. |
20:57:29 | rasher | AlexP: Great arguments |
20:57:35 | kugel | what, why call the RSB for the flyspray thing? |
20:57:45 | AlexP | kugel: see above |
20:57:56 | kugel | the entire RSB was at the devcon, we know what the RSB thinks |
20:58:09 | n1s | Llorean: sure, but afaiu it was not decided then but rather they decided that we should *try* gerrit which we have done for weeks now, and if we go that way which now seems very likely since noone has objected very strongly afaik the patch tracker gets quite redundant |
20:58:33 | rasher | n1s: it's not redundant at all |
20:58:55 | rasher | gerrit sets the bar a lot higher for contributors |
20:59:06 | n1s | and there has been length discussions about the patch tracker in here after that |
20:59:27 | gevaerts | rasher: gerrit is *NOT* a requirement for contributors! |
20:59:51 | rasher | gevaerts: only if you live in a world where the ML is a useful Flyspray replacement |
20:59:52 | kugel | n1s: right, we discussed it here as well |
20:59:54 | Llorean | gevaerts: Gerrit is a requirement for contributors who want their patches indexed in something easily searchable, which was something all contributors can currently do. |
21:00 |
21:00:12 | kugel | Llorean: that's the point |
21:00:21 | kugel | we don't want the convinience of a patch tracker anymore |
21:00:23 | Llorean | kugel: THe point is to force people to us git? |
21:00:27 | gevaerts | Llorean: patches aren't meant to be indexed and searchable. They're meant to be developed until they're ready, and then committed |
21:00:31 | kugel | because that's what makes patches rot |
21:00:37 | n1s | rasher: i think flyspray is aweful and that a ML indeed is nicer |
21:00:45 | n1s | awful even |
21:00:57 | kugel | we want to prod people to actively work on the patches in order to not get forgotten |
21:01:04 | rasher | There's no way to find patches which have been posted to the ML |
21:01:09 | Llorean | gevaerts: Some of our patches rotted for one or two years before new blood found them, picked them up, and finished them off. Do you think that's likely to happen, at all, with the ML? |
21:01:21 | rasher | What Llorean said. |
21:01:23 | kugel | rasher: exactly, so they need to be posted again, until they are committed |
21:01:26 | n1s | rasher: the point is that the patches should either get commited fairly quickly or dropped |
21:01:31 | Llorean | It's not bad if they rot for a while. It's bad if they're *forgotten* |
21:01:33 | rasher | kugel: GOOD GOD that's retarded |
21:01:54 | AlexP | keep it civil |
21:01:55 | kugel | we don'T want to host patches anymore which don't make it in because people don't work on them |
21:02:04 | Llorean | n1s: If that happened we wouldn't have AA fonts. Or album art. Or a host of other features. |
21:02:06 | n1s | you can't think the current system is working well |
21:02:14 | rasher | So we just want to cut out the contributors who don't write perfect patches |
21:02:15 | rasher | gotcha |
21:02:17 | Llorean | We'd have dropped them early on because they rotted for a while |
21:02:29 | AlexP | yeah, exactly that /sarcasm |
21:02:34 | | Join Stummi [0] (~Stummi@rockbox/developer/Stummi) |
21:02:35 | rasher | AlexP: oh stuff it |
21:02:39 | kugel | rasher: no, we want to review the patches more conviniently and tell people what to do |
21:02:41 | AlexP | indeed |
21:02:55 | kugel | flyspray is a nice place to *host* |
21:03:05 | Llorean | Is there some reason we can't *tell* people patches are likely to rot on flyspray, rather than just shutting it down? |
21:03:06 | kugel | patches, but a horrible place to *review* them |
21:03:08 | rasher | kugel: and those who can't or won't do gerrit can go rot in hell |
21:03:19 | AlexP | mailing list |
21:03:20 | n1s | Llorean: perhaps, or knowing that this was the situation, perhaps the original posters would have worked more towards inclusion |
21:03:25 | gevaerts | rasher: if we say yes, will that make you happy? |
21:03:28 | rasher | aka post them to the ML where they will be forgotten even faster and more efficiently |
21:03:31 | *** | Saving seen data "./dancer.seen" |
21:03:34 | AlexP | ... |
21:03:40 | | Join T44 [0] (~Topy44@f048017039.adsl.alicedsl.de) |
21:03:42 | kugel | rasher: if you think about it, gerrit doesn't really raise the bar compared to flypray |
21:03:47 | Llorean | Why not hook flyspray into the mailing list? |
21:03:47 | kugel | both require registration |
21:03:52 | rasher | kugel: if you actually think about it, it does |
21:03:53 | Llorean | Every patch submission, every comment gets an email |
21:04:03 | Llorean | Then you get your constant spam AND you get the ability to search and index them |
21:04:03 | kugel | rasher: really? I didn't see you trying gerrit |
21:04:15 | rasher | so? |
21:04:24 | Llorean | Or is "the best of both worlds" really worse somehow? |
21:04:33 | rasher | Well, the decision has clearly been made by the money people, no sense discussing it. |
21:04:36 | | Part rasher |
21:04:59 | Llorean | I get an email when a task I'm watching is posted to. Wouldn't that work for the ML as well? |
21:04:59 | kugel | Llorean: flysprays emails are not threaded... |
21:05:08 | Llorean | kugel: So fix that. |
21:05:20 | kugel | huh? |
21:05:28 | kugel | flyspray isn'T even threaded, how can the emails be? |
21:05:45 | Llorean | Flyrspray is "threaded" by FS# |
21:05:51 | kugel | but not the comments |
21:06:15 | Llorean | Neither is the forum, but you can quote who you're replying to |
21:06:25 | gevaerts | Flyspray is a good place to ask how to use patches, so that's what people use it for |
21:06:42 | kugel | we've always made decisions at the devcon, why is that a problem just now? |
21:06:56 | n1s | because people disagreed with the decision |
21:07:07 | Llorean | Because people didn't even know about the decision. |
21:07:25 | Llorean | I saw no mention of "throw out flyspray" when I read about what's decided. I may have overlooked, if someone would like to point me to it. |
21:07:26 | kugel | I'm sure the decision is documented somewhere? |
21:08:13 | n1s | Llorean: but as i said, and afaiu the decision was to throw out patches on fs IF we go with gerrit |
21:08:31 | kugel | anyway, as I said, flyspray is good to host patches, not to get them committed in a reasonable time, that's why we drop it as we don't want that anymore |
21:08:47 | Llorean | n1s: So then I'll happily read the reasoning for that, if someone can point me to it. |
21:09:09 | Llorean | kugel: Even people who pester on the ML don't get their patches looked at that well. You've complained about that exact thing yourself in the past. |
21:09:14 | kugel | n1s: well, actually to drop flyspray and go with the ML was before even discussing the git change |
21:09:40 | n1s | kugel: ah |
21:09:58 | kugel | Llorean: we can reopen flyspray if the ML fails, but right now I'm more hopeful that the ML is better than FS |
21:10:23 | kugel | simply because FS doesn't work at all |
21:10:48 | n1s | i just remembered that i came to the opinon that if we went with gerrit we shouldn't have patches in fs as it would just be too spread out before i knew that was the plan |
21:11:26 | Llorean | kugel: FS doesn't work at all because devs can't be assed to get involved. What makes the ML get them more involved? They'll just ignore them. |
21:11:29 | n1s | plenty of other *big* projects use ml's for patch submission quite effectively |
21:11:39 | gevaerts | Originally the Swedes wanted to drop flyspray for patches and move to the mailing list, and Torne wanted a patch review system |
21:11:45 | kugel | gerrit is so much nicer to review patches and tell specifically what we don't like, even on a per-line basis |
21:11:53 | Llorean | This isn't about FS vs Gerrit |
21:11:57 | Llorean | It's about FS vs the mailing list. |
21:12:00 | Llorean | It's "what to do with patches" |
21:12:19 | kugel | Llorean: right, but people posting to FS think we are responsible to look at the patches, which is not true |
21:12:28 | Llorean | And you aren't responsible on the ML either |
21:12:29 | AlexP | Llorean: Disregarding the issue of ml vs fs, you are completely right about the communication |
21:12:32 | kugel | but that's why the patches rot |
21:12:49 | n1s | we can't really fix the devs :) |
21:12:52 | Llorean | AlexP: Yeah, that's the part that actually bothers me. |
21:13:04 | Llorean | n1s: So why are you trying to by moving to the ML and saying it'll improve things? |
21:13:05 | kugel | n1s: and we don't try to |
21:13:14 | gevaerts | Llorean: wild thinking here, but what if we had an automated email to gerrit submission system? |
21:13:19 | kugel | well, we try by making review with gerrit easier :) |
21:13:34 | Llorean | gevaerts: I'm happy as long as there's a way to make sure patches don't get lost. Currently searching the mail archive rather sucks. |
21:13:43 | n1s | Llorean: if we can make things easier hopefully more devs will eview patches |
21:13:50 | Llorean | n1s: The ML doesn't really make things easier. |
21:13:54 | kugel | but by going to the ML we try to make clear patches aren't our responsibility |
21:13:58 | n1s | and that is your opinion |
21:14:00 | kugel | but the authors |
21:14:20 | Llorean | kugel: And this wasn't obvious to so many of us, how's it obvious to the submitters? |
21:14:36 | gevaerts | Llorean: there are two answers to that: one is that a lot of people at devcon had the opposite goal, i.e. have patches get lost if they don't get committted, and the other is that gerrit won't lose patches |
21:14:37 | Llorean | And how's it better than say, a disclaimer page when submitting a patch that makes that point explicit instead? |
21:14:54 | Llorean | gevaerts: Yeah, if the ML patches automatically ended up on gerrit, I'd probably be fine with things. |
21:15:03 | AlexP | Llorean: You should know from forum experience that people never read that sort of stuff :) |
21:15:13 | Llorean | gevaerts: I have one real goal: Don't lose patches of non-git submitters. |
21:15:30 | kugel | we specifically want patches to get lost if nobody is interested enough |
21:15:37 | kugel | the ML is good for that |
21:15:38 | Llorean | AlexP: Yeah, but it's better to have it as a policy rather than having people making assumptions and saying "we assumed you know" rather than "we told you" |
21:15:39 | gevaerts | Llorean: I'm not sure if that's even a practical idea at this point though |
21:15:53 | AlexP | Llorean: agreed :) |
21:15:57 | Llorean | gevaerts: It'd work fine if FS were left up, but actively discouraged. |
21:16:24 | Llorean | Considering how many patches sit 6+ months before inclusion, is it better to intentionally throw them out, or hope someone new picks them up? |
21:16:37 | * | mystica555 will make an entirely naieve question as i am not a dev nor even a contributor: does the mailinglist vs flyspray discussion remove a bug tracker as well? |
21:16:37 | kugel | the former |
21:16:51 | kugel | because it'll force the author to do something about it |
21:16:53 | Llorean | kugel: Then why don't you delete a LOT more old patches of flyspray during cleanup weeks? |
21:17:07 | gevaerts | mystica555: no. We |
21:17:11 | Llorean | mystica555: We keep the bug portion |
21:17:16 | kugel | I closed some 30odd patches at the devcon |
21:17:18 | gevaerts | mystica555: no. We're reasonably happy with FS as a bug tracker |
21:17:23 | Llorean | gevaerts: Can you attach a patch to a bug that fixes it, or are we disallowing that too? |
21:17:43 | mystica555 | ok. i was about to berate this decision to go to mailinglist entirely as i've dealt with email before as the *sole* way to track issues from start to finish and dear god i wanted to pull my hair out |
21:17:45 | Llorean | kugel: That's a trivial amount considering the total. Shouldn't everything over 3 or 4 months just be closed automatically to mimic the losing effect? |
21:18:12 | kugel | Llorean: FS can't do that |
21:18:17 | Llorean | kugel: You can. |
21:18:19 | kugel | gerrit can |
21:18:43 | gevaerts | Llorean: I don't know if we discussed that, but I personally think that that's fine, although I think that if it's attached by someone who uses gerrit it should possibly be avoided |
21:18:49 | Llorean | kugel: You said you closed 30. Why didn't you close more? |
21:19:00 | kugel | because it's a boring and lenghty task |
21:19:07 | Llorean | gevaerts: So how do you link patches in gerrit to bugs in flyspray? |
21:19:15 | mystica555 | y'all can go on with your petty bickering :) just wanted to make sure you werent entirely shooting yourselves in the foot. |
21:19:31 | Llorean | gevaerts: What if someone finds a bug *and* wants to submit the patch in a single go? They have to reply to themselves? |
21:20:02 | kugel | Llorean: they push the patch to gerrit including the bug description |
21:20:05 | AlexP | mystica555: Saying things like that really doesn't help make the "bickering" any less petty |
21:20:35 | Llorean | kugel: Again with the "force them to use git." This is my other objection - in the past we had a vc-angostic form of submission |
21:20:40 | mystica555 | AlexP: i've noticed a few occasions where too many people yell and yell and yell x 60 messages worth in a single subject matter on the list and i just look and say 'dear god why do you have to argue so much' |
21:20:52 | gevaerts | Llorean: I'm assuming there's a way to push a patch to gerrit and get it back somehow as a unified diff from some url, which can be linked to from flyspray |
21:21:05 | Llorean | gevaerts: Is there a way to push unified diffs to gerrit then? |
21:21:16 | kugel | Llorean: the ML can take any patch form |
21:21:17 | Llorean | That would more or less solve the problem. |
21:21:26 | Llorean | kugel: And is a *terrible* bug tracker. |
21:21:35 | gevaerts | Llorean: that would be this hypothetical mailing interface :) |
21:21:39 | AlexP | mystica555: And I agree - my point was only saying things like "entirely shooting yourselves in the foot" makes it clear what you think but in a slightly inflammatory way :) |
21:21:53 | | Join TheLemonMan [0] (~lem0n@ppp-82-4.26-151.libero.it) |
21:21:54 | n1s | Llorean: we already get patch submissions with "fix foo" |
21:22:27 | AlexP | Llorean: It isn't a bug tracker - in that case it'd be a patch to fix xxx |
21:22:28 | Llorean | n1s: So bad ones justify removing the possibility of good ones? |
21:22:40 | gevaerts | Llorean: what I meant though was that if a non-regular finds a patch that fixes a bug, it would be silly to ignore a patch just because it's attached to the bug on FS. If a regular (committer or regular patch submitter) does that, I see no reason to not push it to gerrit directly |
21:22:45 | Llorean | AlexP: But if it's the wrong patch, or the wrong fix, it becomes a bug with a candidate patch to fix it. |
21:22:46 | mystica555 | i'm not one to let my feelings be hidden. i think removing any form of tracking of an issue/bug/patch should be avoided, but as i don't develop, instead only having a customer service background, well, i *require* tracking of issues in an easily sortable/assignable manner |
21:23:24 | Llorean | gevaerts: We do get regulars with "I've come up with this fix, but I'm not too familiar with the code's intent so can someone review" patches |
21:23:50 | Llorean | gevaerts: It'd be nice to have those directly attached to the bug task |
21:23:55 | Llorean | Even if someone else opened the bug |
21:24:01 | AlexP | mystica555: Right, and any (well, nearly) opinion is valid - I was just pointing out (and making an unnecessary scape goat of you), that inflammatory language should be avoided. Of course I'm just as guilty of this as anyone else :) |
21:24:19 | AlexP | Llorean: And the patch is worked on in whatever place it is |
21:24:20 | mystica555 | and figure anyone removing this would ge detrimental. (my one job where the ONLY tracker was a shared gmail account where the customer problems came to, while they let a perfectly good relationship management and issue tracker software just sit and rot) |
21:24:30 | n1s | Llorean: i don't see fixes without bug reports as bad so i don't know why we would need to have a bug task for a fix if you already have the fix |
21:24:45 | gevaerts | Llorean: does it make much difference if a patch is attached to flyspray, or there's a gerrit url in a flyspray comment that leads to the same patch? |
21:24:53 | AlexP | Llorean: But as I say, I don't actually care about flyspray vs mailing list personally |
21:24:55 | Llorean | gevaerts: Nope |
21:25:17 | gevaerts | mystica555: I don't think anyone ever argued that we should have no dedicated bug tracker |
21:25:19 | Llorean | gevaerts: That's fine. But it seems a rather gray area when you start saying "some patches only" |
21:25:49 | Llorean | I just don't believe removing flyspray will make significant headway toward solving the problem it sounds like you're trying to solve. |
21:25:52 | mystica555 | gevaerts: thus why i asked whether it was going out the door too. i didn't know any history until i reread todays discussion here |
21:26:23 | Llorean | gevaerts: Though I'm not certain I'm clear on what *all* the problems it's trying to solve are, because I don't have a clear summary of the discussion from DevCon. ;) |
21:26:51 | gevaerts | Llorean: you know what devcons are like. *Nobody* has a clear summary :) |
21:26:54 | Llorean | I have this feeling it's going to turn out all the points I argued against were minor points in favor (they seem minor reasons to close it down) and there was some other significant reason I didn't even know about. |
21:27:34 | | Join paulk [0] (~paulk@lib33-1-82-233-88-171.fbx.proxad.net) |
21:27:42 | gevaerts | That reminds me actually. I should edit my recordings... |
21:27:52 | Llorean | It's also somewhat petty sounding. "We want to make non-git contributor's patches get lost if they don't stick around and stay active, but git ones can just leave them up on gerrit however they like." |
21:28:23 | AlexP | Llorean: I just don't remember I'm afraid as I wasn't a proponent of one side or the other - I just listened to the arguments and made a decision then and there |
21:28:55 | AlexP | I would have thought the aim should be to close things on gerrit too |
21:29:06 | Llorean | AlexP: I just don't follow the reasoning. If gerrit weren't involved, it might make more sense. But with gerrit as just "a new places for patch to rot" removing the ability for them to rot elsewhere seems... odd. |
21:29:28 | Llorean | Which is why I want a proper summary, it feels like I *must* be missing some salient fact. |
21:29:32 | AlexP | Llorean: Well, I guess a don't have loads of places for that to happen could be argued |
21:29:57 | Llorean | Yeah, but Flyspray + Gerrit is as many places as Flyspray + ML |
21:30:14 | kugel | well, we want to try anyway |
21:30:17 | AlexP | yes, but fewer than flyspray + gerrit + ml :) |
21:30:31 | kugel | that was re "I just don't believe removing flyspray will make significant headway toward solving the problem it sounds like you're trying to solve. |
21:30:35 | Llorean | AlexP: We get like, 1.5 submissions via the ML per year. It may technically be a place, but... |
21:30:51 | AlexP | Llorean: Yes, because we tell everyone to use flyspray |
21:31:09 | Llorean | Yeah, and we could tell everyone to use gerrit unless they have to use flyspray (for whatever reason) |
21:31:16 | AlexP | Llorean: But anyway, my main argument in this argument was that devcon for decision making is a good and necessary thing, even if in no way perfect |
21:31:35 | AlexP | The ml vs fs doesn't bother me :) |
21:31:49 | | Quit Thra11 (Ping timeout: 260 seconds) |
21:32:11 | Llorean | AlexP: I agree with that. I'd just like the decisions made to be explicitly presented, including reasoning, at the end of devcon or within a set period afterward, and the possibility of a committers vote (or RSB ruling, or some other 'final' process) on contentious ones given the semi-exclusive nature of devcon |
21:32:42 | gevaerts | I'm not convinced that devcon for decision making is a *good* thing (the arguments against that are reasonably strong), but I do believe it's the best we have |
21:32:48 | AlexP | Llorean: Yes, that would be good where possible |
21:33:01 | AlexP | gevaerts: Yes, that's what I meant |
21:33:14 | n1s | yeah we are pretty bad at consensuses |
21:33:32 | gevaerts | Yes, next time we need to apppoint a secretary |
21:33:43 | gevaerts | With fewer ps obviously |
21:33:49 | AlexP | I'd love us to be able to do it more inclusively, but the only place decisions are ever taken are at devcon |
21:34:14 | AlexP | If someone came up with a better system that actually worked, then great :) |
21:34:58 | gevaerts | devcon also only half works because we tend to forget about communicating properly |
21:35:16 | Llorean | I still like "let devcon hammer out where the lines are drawn in the sand, then let the devs vote afterward." Devcon doesn't necessarily have to argue both sides, just figure out what the questions are. Then let us argue both sides on the ML for a month before calling a final vote on whichever the issues for the year are. |
21:35:57 | Llorean | Devcon's job would be deciding if it was an issue that needs deciding in the vote, or just something we can quibble about normally like we always do and work out ourselves. |
21:36:31 | AlexP | god, a month of arguments like this would be awful :) |
21:36:49 | AlexP | We tend to decide what needs arguing about by someone putting it on the agenda |
21:36:50 | Llorean | Restrict it to the ML, and then ignore it if you don't care about the issue. Hell, restrict it to one ML thread per question on the survey. |
21:36:54 | Llorean | So you can just ignore things wholesale. |
21:37:09 | AlexP | If it didn't need arguing about, it wouldn't get brought up :) |
21:37:26 | Llorean | AlexP: Yeah, but needing arguing about is different from needing an explicit all-hands vote. |
21:37:46 | AlexP | Llorean: Trouble is it can be quite difficult to know |
21:38:33 | | Join Thra11 [0] (~thrall@51.16.113.87.dyn.plus.net) |
21:38:34 | Llorean | True. That's why we give the job to those of you who can afford to go on fancy trips to meet up with your programmer pals. Make you pay for having that option. :-P |
21:38:41 | AlexP | heh :) |
21:39:15 | Llorean | Really though, improvements in the decision making process would be nice, but I think it's in the "good enough not to suck" range as it is. Clear communication is, as I've said, my hangup |
21:39:40 | * | gevaerts agrees |
21:39:50 | AlexP | yep |
21:44:39 | Llorean | Then we'd actually at least now what we're arguing about. ;) |
21:44:53 | AlexP | Would that help? :P |
21:45:25 | Llorean | Define "help" |
21:45:57 | Llorean | If *I* saw the points I wanted to make had already been made, I at least wouldn't be trying to change the opinions of people who'd been there with them. |
21:46:37 | Llorean | And like I said, the reasoning for closing FS seems really trivial to me, so I feel like I'm missing something. It'd be good to know the whole scope so I could understand what the actual issue is that needs it shut down. |
21:46:51 | Llorean | If it's just "because we don't like it" there's not much to be done. |
21:47:27 | Llorean | It won't 'help' in the sense of decreasing argument, I imagine. |
21:48:49 | gevaerts | Llorean: I won't have time today, but I should have some recordings of the discussion to copy off some DAPs. Remind me again if I forget... |
21:49:08 | Llorean | Okay |
21:49:15 | Llorean | Assuming I remember too. :) |
21:49:50 | gevaerts | No decent microphones probably, but I distributed DAPs around the room |
21:50:01 | Llorean | Should be good enough for voice. |
21:51:19 | * | kugel thinks we have more people together at the devcon than we'll ever get on the ML so it's the best place to make decisions |
21:52:49 | kugel | and we historically failed to make decisions on the ml |
21:54:30 | Llorean | There's a difference between asking people "make a decision" and giving people a couple explicit options and saying "vote" |
21:54:49 | Llorean | It's a compromise between asking them to make the whole decision, and making the decision for them. |
21:56:07 | * | gevaerts bets that "further discussion" will win most votes |
21:56:08 | AlexP | Llorean: This is true, but I think even if the options were presented there would be people saying the options were wrong and arguing for others |
21:56:11 | Llorean | Plus, if there's really more people at devcon then allowing the ML to join in the vote shouldn't change the outcome. ;) |
21:56:22 | Llorean | gevaerts: That should never be an option. |
21:56:57 | gevaerts | Llorean: knowing us, I tend to agree |
21:57:01 | Llorean | AlexP: True, but it's still better than making the choice without giving them an explicit opportunity to input. And for those who feel none of the options are ideal, "no change" is likely to be one. |
21:57:58 | AlexP | yeah |
21:58:16 | Llorean | It's not a perfect option, but compromises rarely are. I just think it *might* be better. |
21:58:38 | AlexP | we could always give it a go :) |
22:00 |
22:00:02 | Llorean | At the very least, we should have some sort of RSB decision on what DevCon can do, and what they must do (re: communication, etc) which should probably be preceded by suggestions from the masses to try to avoid overlooking things (even if it means argument again) |
22:00:21 | Llorean | Then, once that's worked out, you can work out *how* they do it. |
22:01:44 | gevaerts | Llorean: given that this isn't really what the RSB was originally meant to do, it might be a good idea to explicitely propose this now, and have the *next* RSB decide |
22:02:03 | gevaerts | That way people know what they're voting for in the RSB vote |
22:02:17 | AlexP | The next one will be soon, right? |
22:02:59 | | Join petur [0] (~petur@rockbox/developer/petur) |
22:03:25 | gevaerts | Well, September in theory, although that's only because we accidentally extended some terms a bit. I'd say that if there's a good reason, there's no serious objection to starting the RSB voting process within the next few weeks |
22:03:39 | AlexP | Well, whenever is fine :) |
22:04:00 | AlexP | I was just trying to remember when the last one was |
22:04:13 | gevaerts | The first one was July, the last one was September |
22:04:25 | AlexP | ah, I must have been remembering the first one |
22:06:14 | Llorean | gevaerts: That makes a lot of sense. |
22:08:51 | paulk | hi! does someone owns a philips gogear device? I have a GoGear Opus but it shows errors at startup and refuses to boot the (non-free) system. I have an access to the device's partitions but I don't know what I should recreate and how. Can I find some help here? |
22:14:54 | | Quit n1s (Remote host closed the connection) |
22:15:47 | Torne | ok i just read all that scrollback and i feel I should point out: we are switching to git to host our source, and we haven't had source tarballs in a long time |
22:15:52 | Torne | so *anyone who wants to contribute* has to use git |
22:16:03 | Torne | because you can't get the source code anywhere else |
22:16:34 | Torne | actually creating a gerrit account takes no longer than creating an FS account |
22:16:49 | Torne | and once you have the gerrit account and a git clone, that's it: you can contribute patches to gerrit, as easily as creating a diff |
22:21:05 | Llorean | Torne: So why do we need ML for patches at all then? Why not "no submissions except through gerrit?" |
22:22:00 | Torne | i don't think we do |
22:22:21 | Torne | nobody except me had actually *used* gerrit at the point this was being discussed |
22:22:29 | Torne | they didn't know the exact steps involved |
22:22:39 | Torne | this is why we have the demo :) |
22:23:31 | Llorean | If we're dropping all patch submission entirely, and only using gerrit, that's fine by me |
22:23:43 | Llorean | My objection is to dropping Flyspray for the ML for diffs. |
22:24:30 | Torne | i don't think there is any reason to actively refuse patches being sent to the mailing list, but I don't anticipate anyone actually really wanting to do that |
22:25:14 | Torne | once you create an account the process to submit a patch is "git commit -a; git push origin HEAD:refs/for/master" |
22:25:16 | Llorean | I don't see any problem with refusing them if we don't want them. |
22:25:27 | Torne | versus "git diff" to get the diff of your changes |
22:25:38 | B4gder | why would we forbid patches on the mailing list? |
22:25:47 | Torne | (which you then have to email/upload to FS) |
22:26:22 | Llorean | B4gder: Unless the patch is 100% complete, it'd be better to just send them on to gerrit so it can begin developing a history |
22:26:37 | B4gder | sure, that may be a better way |
22:26:52 | B4gder | but posting on the mailing list is a long lived tradition in open source |
22:27:07 | B4gder | (and one that I personally like) |
22:27:18 | Torne | nobody chooses to do it now, though, so i doubt a significant number of people would choose to do it then either |
22:27:24 | * | Torne shrugs |
22:27:28 | B4gder | right |
22:28:16 | kugel | well, as I understand it we go from "please use flyspray" to "use the ML or, preferably, gerrit" |
22:32:45 | pixelma | I'm definitely not a money person, thanks... and I also wasn't very convinced that mails with added patches are a better way than flyspray and am not really convinced yet. I could see the point of "people will have to be more active on their side to get something committed" but I'm still not sure that'll work here :\ |
22:33:44 | Torne | i don't think anyone is suggesting we advise *anyone* to send patches to the list.. just that we don't automatically refuse them to cover the possibility that someone isn't able/willing to use the nice way :) |
22:35:28 | pixelma | I understood the Swedes that they wanted patches on the ml, the gerrit suggestion came later |
22:36:14 | B4gder | yes, and we all said "let's try it out" |
22:36:52 | B4gder | a primary idea is to reject or comment patches earlier |
22:37:08 | B4gder | to not accept crap, but bounce them off earlier to have the submitter do the leg work |
22:37:45 | B4gder | as the current way of work encourages a "dump it with the dev team and let them work on it" |
22:38:42 | soap | What is wrong with patches rotting? I can't smell a stink or see any flys. If 1 in 10,000 patches gets reincarnated from rot in FS doesn't that justify FS's existence? What is the /harm/ in leaving FS up? |
22:39:21 | B4gder | accepting new patches in FS is not useful imho |
22:39:25 | paulk | what's the utility to flash philips Gogear SA52xxx devices? |
22:39:35 | Llorean | soap: Quite a few of our features rotted for a while on FS until someone had time or interest. I feel like they'd get lost otherwise. |
22:40:22 | B4gder | Llorean: or perhaps if we'd rejected them at once because they weren't good enough, the user could've worked on improving them and actually gotten the feature in faster... |
22:40:27 | Llorean | But I'm okay with going wholly to gerrit. I just don't like the ML as an actual submission method if we're not going to keep FS around. I think "post it somewhere so we don't lose it" should be an option if we're going to accept patches/diffs. |
22:40:53 | Llorean | B4gder: There's no way to know whether that would've happened, or they would've just left them, like they did, and it never got seen again. |
22:41:00 | Llorean | You can't really guess on that sort of thing |
22:41:20 | B4gder | correct, but we can also take for granted that my scenario has happened more than once |
22:42:35 | | Quit petur (Quit: here today, gone tomorrow) |
22:42:45 | Llorean | What makes it more likely someone on the ML will encourage people to keep working than someone on FS? If devs aren't interested in commenting on patches / pushing contributors to do more work now, why will they become so? |
22:42:48 | pixelma | all... the majority said so. Another outcome could be that less and less people contribute - I find patches in mails quite hmm unhandy. I guess git could compensate for that though... still, I am not convinces |
22:43:14 | B4gder | Llorean: the key is who's driving the development further, not the tool itself |
22:43:34 | Torne | the tool is kinda independant from our attitude and communication here |
22:43:37 | Torne | well, and policy |
22:44:09 | Torne | as far as i'm concerned switching from FS to Gerrit as a tool is just taking advantage of a nicer workflow made possible by our use of git |
22:44:19 | soap | so we talking a new -patch ML or throwing this all in -dev wholesale? |
22:44:44 | Torne | what we choose to tell people about their responsibilities as contributors, how we handle patches that are not ready to commit, etc are indepedant of that.. |
22:44:53 | B4gder | soap: we're talking about using gerrit |
22:45:26 | B4gder | the mail list stuff is much more how *I* view and like things to happen rather than the majority |
22:45:32 | soap | so no FS patches, no ML patches, gerrit period? |
22:45:44 | B4gder | gerrit is the new FS |
22:46:04 | B4gder | we didn't do them on the mail list before, and we won't particularly change that now |
22:46:20 | soap | then this tempest is over...? |
22:46:37 | Llorean | soap: Strongly discouraging patches to the ML but accepting them when necessary. Earlier it was presented as if we were going to present the ML as an option for submission, which is what I objected to, but Torne has summarized it in a clearer way to me. |
22:47:09 | Torne | it probably is possible to have patch submission to gerrit by email, btw |
22:47:23 | Torne | but don't be expecting me to implement that right away ;) |
22:47:28 | Llorean | The tempest was over it being presented as if we'd have two channels. Gerrit + ML. When really the goal is one channel. |
22:47:34 | soap | Ok, I grok the scrollback now. Thanks. |
22:47:40 | AlexP | Llorean: I thought we were, so if not that was my mistake |
22:47:53 | soap | And SVN gets shuttered in favor of git when? |
22:47:56 | Llorean | It seemed pointless to close down Flyspray in favor of Mailing List. The argument didn't really involve Gerrit. |
22:48:03 | Torne | soap: that was independantly decided beforehand :) |
22:48:05 | Llorean | Or at least *my* argument didn't. |
22:48:26 | Torne | soap: continuing to have git mirrored from svn removes the ability to usefully work on branches |
22:48:35 | kugel | well, I understood that we don't discourage the ML anymore as much as we do now |
22:48:53 | AlexP | kugel: me too |
22:48:59 | AlexP | As it is is a viable channel |
22:49:00 | soap | Torne, right. Forgive me as I've been deep out of town for almost a quarter now. |
22:49:04 | pixelma | I thought gerrit was outside the original discussion as well, though of course it can play a role |
22:49:04 | Torne | soap: sure. |
22:49:06 | soap | Is SVN already shuttered? |
22:49:08 | Torne | soap: no |
22:49:16 | soap | But it will be? |
22:49:17 | Torne | I haven't yet moved gerrit onto our real infrastructure |
22:49:18 | kugel | and that it's not simply s/flyspray/gerrit/ |
22:49:34 | AlexP | kugel: This too was my impression |
22:49:38 | Llorean | soap: The other tempest was about devcon not clearly communicating the decisions made (and the reasoning behind them) to those of us who couldn't attend. |
22:49:40 | AlexP | But I don't actually mind |
22:49:46 | Torne | soap: yes, at some point we will kill svn and change things like th ebuild system to pull from git |
22:49:51 | kugel | perhaps it was a bit confusing because we decided pro-ml before we discussed the whole git and gerrit stuff |
22:50:00 | Torne | (not the current git mirror, a better conversion I have now done :) |
22:50:05 | AlexP | kugel: yes, probably |
22:51:28 | soap | so can _I_ go ahead and spend this time at home switching myself over to git w/o worry that it will change out from under me later on? |
22:51:47 | Torne | soap: Don't do it right now |
22:52:07 | Torne | The current git mirror (the one we've had a while) is not what we will be using |
22:52:26 | Torne | and the converted repo i ahve up on gerrit is not being updated from svn automatically |
22:52:42 | Torne | so if you aren't already using git then now is not a good time to start (at least not for actual rockbox development) |
22:53:04 | Torne | you might want to try out using git and gerrit on the sandbox repository, though |
22:53:12 | soap | It is likely going to take me a while to learn git. I'm slow. |
22:53:18 | | Join darndude [0] (~bcc034c5@giant.haxx.se) |
22:53:27 | Torne | see http://www.rockbox.org/wiki/GerritDemoGuide |
22:53:31 | soap | but thank you all for the clarification. |
22:54:19 | darndude | some1 knows anything bout running RB on a 6G iPod? |
22:55:47 | Torne | soap: sure. You can start using it on the sandbox repo now, though |
22:55:58 | Torne | including both committing directly and submitting stuff for review to gerrit |
22:56:03 | Torne | and reviewing stuff |
22:56:11 | Torne | it just isn't the rockbox code ;) |
22:56:16 | Torne | well, it's a small chunk of it with no history |
22:56:26 | Torne | and a bunch of silly textfiles people have created :) |
22:59:43 | | Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) |
23:00 |
23:03:34 | *** | Saving seen data "./dancer.seen" |
23:05:28 | darndude | any1 some help for me? |
23:10:43 | | Quit esperegu (Read error: Connection reset by peer) |
23:11:37 | pixelma | darndude: not many know about the Ipod 6G port I think, but asking a more specific question may help too |
23:22:14 | darndude | it isnt really specific, it just freezes too often and needs a hardreset. i don't want it to play doom, but to play my music and charging without freezing |
23:23:55 | AlexP | yeah, it has the status it does for a reason unfortunately |
23:25:07 | | Quit darndude (Quit: CGI:IRC (EOF)) |
23:27:22 | | Quit benedikt93 (Quit: Bye ;)) |
23:27:27 | sideral | Llorean, rasher: I wholly agree with you re: closing FS for patches & not archiving old stuff in an indexed / searchable fashion, which I believe gerrit cannot replace completely (it has no indexing / tagging). |
23:27:41 | sideral | I'm also concerned about us discouraging (or making impossible) hosting for unfinished stuff −− I prefer central hosting over patches scattered over all the interwebs. |
23:27:56 | sideral | I've registered my wishes before, here: http://www.rockbox.org/irc/log-20110615#10:53:05 −− I see no need to discuss this once again right now. :) |
23:30:36 | | Part Pikel |
23:34:08 | | Quit Stummi (Quit: Bye!) |
23:39:35 | | Join leavittx [0] (~leavittx@cl-534.mbx-01.si.sixxs.net) |
23:41:57 | | Quit ender` (Quit: It's all fun and games until someone loses an eye. Then it's fun and games you can't see.) |
23:43:44 | | Quit paulk (Quit: Ex-Chat) |
23:54:30 | | Quit Llorean (Read error: Connection reset by peer) |
23:58:22 | | Quit Zarggg (Quit: Rebooting client...) |