Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next day

Seconds: Show Hide | Joins: Show Hide | View raw
Font: Serif Sans-Serif Monospace | Size: Small Medium Large

Click in the nick column to highlight everything a person has said.
The Logo icon identifies that the person is a core developer (has commit access).

#rockbox log for 2011-07-03

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:19TheLemonMani 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:17pamauryah, 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:36jackwadeI'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:34jackwadeYeah, 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:40jackwadeGuess 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:00soapare 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:43soapOr 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:50soapyou 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:38soapwhat font do you use on the nano, [Saint] ?
14:45:08soapthe 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:51soaplink?
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:58soapthank you.
14:53:41soapIn 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:00soapNot 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:55JdGordonkugel: with buflib,how safe is loading *stuff* into a handle from disk going to be?
15:51:22JdGordoni.e loading a jpeg into a handle... will we be able to lock the buffer to make sure no movement happens temporarily?
15:54:31AlexPWe should put some aa fonts into the font pack, but I guess that means generating them at build time
15:54:42AlexPAs 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:50gevaertsJdGordon: there's a callback you can register with the allocation, and that callback can refuse the move
15:58:33JdGordonok cool
15:58:40gevaertsWell, something like that anyway
15:58:48gevaertsI can't remember the exact details
15:58:58JdGordonI'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:02JdGordoni.e images
16:00
16:00:25JdGordonanyone got the link to [Saint]'s cabbie theme?
16:00:29JdGordoni cant find it in the logs
16:03:04*Torne pushes 216388 objects onto gerrit :)
16:03:19JdGordonah, found t :)
16:03:26pamaurysee ya next week Torne :)
16:03:48Torneit's only 130odd meg, it's not that bad :)
16:04:28AlexPTorne: 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:37TorneAlexP: pretty much.
16:04:47pamauryI still didn't try gerrit :)
16:04:48TorneI am pushing the mirror to gerrit now
16:04:50AlexPRighto
16:04:54Torneit'll be read-only
16:04:58 Join hobby16 [0] (~ubuntu@157.186.193.77.rev.sfr.net)
16:05:00Torneno changes, no reviews, no nothing
16:05:10pamaurywhy isn't the website showing the commits ?
16:05:12Tornein case of needing to blow it away :)
16:05:19Tornepamaury: hm?
16:05:46pamaurythe main page doesn't show the commit list
16:05:53Tornemain page of what?
16:06:01pamauryrockbox.org !!
16:06:04TorneOh.
16:06:05TorneEr
16:06:15Tornesorry, i thought you were talking abotu gerrit :)
16:06:18Tornei don't know ;)
16:06:33Tornesvn server is reachable just fine
16:07:22pamauryyes but the main page doesn't show anything
16:07:32gevaertskugel: 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:35pamauryand http://www.rockbox.org/recent.shtml#svn is stuck at r30107
16:09:09JdGordonkugel: 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:43JdGordonI 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:33gevaertsJdGordon: a global lock seems a bit dangerous to me
16:13:13gevaertsJust locking the allocation you're using for IO should be enough, and allowing this callback to say no would achieve that
16:13:18JdGordonhow is it different to a brokem callback?
16:13:42JdGordonok, even a local lock would be fine
16:13:55JdGordonI dont see why the extra hassle of a callback is required
16:13:56gevaertsNot that sort of dangerous. I'm more thinking of things like priority inversion issues
16:14:16JdGordonbuflib_lock(handle); buflib_unlock(handle)
16:14:25gevaertsThat would work
16:14:44JdGordonsetting up a callback just for this seems like pointless overengineering
16:16:04gevaertsIt depends. I don't know how many users will use the callback as things stand now
16:16:45gevaertsBut 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:00JdGordonthen I'd worry about api bloat and confusiont here
16:20:10gevaertsWhy?
16:20:21JdGordontwo ways to do the same thing
16:20:23kugelpJdGordon, 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:16gevaertsJdGordon: right, so the callback would stay the way it is now
16:22:31 Quit mystica555 (Ping timeout: 276 seconds)
16:25:03JdGordonkugelp: finer locking is going to be needed or it limits buflibs usefulness alot
16:25:16JdGordonunless you want to load images to a temp buffer then memmove it into the handle?
16:26:30kugelpgevaerts: 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:10kugellocking single handles can create holes so I'm not a fan of that
16:28:22JdGordontemp locking
16:28:24gevaertsSo how would you handle this case?
16:29:34gevaertsThe 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:52gevaertsWhether 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:41TorneOK, there are now four new projects on gerrit: rockbox, www, themesite and translate
16:31:48Tornerockbox is pushed, the other three are uploading now
16:31:53TorneThey should contain everything that's in svn
16:32:02Tornethey are *not* automatically being updated at present
16:32:03JdGordoncan we split langs out of apps/?
16:32:05Tornebut they are up to date right now
16:32:25TorneJdGordon: in future, possibly; let's please not do that right now :)
16:32:34JdGordonhehe ok
16:32:59Tornethey're read only but you should be able to clone them and fiddle
16:33:13kugelin 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:20Tornegit 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:48gevaertskugel: that seems dangerous
16:33:55JdGordon*inasnely* dangerous
16:34:02 Quit user890104_ (Ping timeout: 240 seconds)
16:34:28gevaertsI'd rather specify that the move callback isn't allowed to do that sort of thing
16:34:40kugeldoing 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:59gevaertskugel: you can handle non-movable allocations, right?
16:35:10kugelyes
16:35:33kugelspecifying NULL for the move callback will make it unmoveable
16:35:53 Quit user890104 (Ping timeout: 258 seconds)
16:35:55gevaertsThen does adding the lock/unlock functions and adding a flag really change things for the compaction bits?
16:36:04kugelbut I wished that only the actually audio buffer is unmoveable
16:36:51gevaertsWell, you can't yielding IO to an actual movable buffer...
16:36:59kugelperhaps I didn't understand the use case yet
16:37:13gevaertsThe usecase is read() :)
16:37:17JdGordonwoah.... 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:27Torneok, all pushed :)
16:40:32gevaertskugel: how do you handle things like loading the dircache dump from disk?
16:40:45gevaertsOr loading the database into RAM
16:43:22 Quit Guinness (Ping timeout: 255 seconds)
16:43:58kugelnot at all yet :)
16:44:05kugelI mean, I didn't enable compaction yet
16:44:12gevaertsWell yes
16:44:33gevaertsWhat's the plan for that? :)
16:45:31kugelwell, perhaps we need a buflib_lock(), but what to do about allocations that can happen in the meantime?
16:45:40kugelfailure or waiting for unlock?
16:46:19gevaertsDepends. Depending on which buffer is locked, you might be able to do some compaction
16:46:33gevaertsOtherwise, waiting should work
16:46:42JdGordongrrr... this isnt about compaction per-se
16:47:21kugelmovement can only be caused by compaction, which can only be caused by a new allocation
16:48:00kugelgevaerts: "some compaction" means holes?
16:48:15JdGordonthat can't be guarenteed forever
16:48:18gevaertsyes
16:48:31kugelbuflib 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:50gevaertsIt will likely clean up the holes at the next compaction
16:48:51kugelI'd like to stay that way
16:49:00 Join robin0800 [0] (~robin0800@genld-218-248.t-mobile.co.uk)
16:49:03gevaertsThe locks we're talking about aren't meant to be held very often
16:49:36kugelI added smarts to it for unmoveable buffers so in my working tree it can create holes
16:50:15gevaertsWhen do you plan to do compaction? On allocation, or on deallocation?
16:50:23kugelon allocation
16:50:30gevaertsThen you'll have holes anyway
16:50:36kugelthat's how it works currently
16:50:48gevaertsSo I don't see the problem really
16:51:34JdGordonI'm also not talking about unmovable handles. just that some handles will need to not move while they are being setup
16:52:46AlexPCan 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:30kugelgevaerts: I would like to avoid locks because I fear they get over-used because it's convinient
16:55:57gevaertskugel: 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:56kugelJdGordon: unmoveable is easy, specify NULL for the move callback
16:58:07JdGordonthats not what im asking about though
16:58:08 Quit robin0800 (Ping timeout: 252 seconds)
16:58:11kugelif 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:48JdGordonlast 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:58JdGordonafterwards the handle is free to move
16:59:58kugelso you want unmoveable in the beginning, but later make them moveable?
17:00
17:00:18gevaertskugel: not just at the beginning I think. You want to write some buffers too near shutdown
17:00:39gevaertsLike the font cache
17:00:42kugelwe can put that into the move callback, but that could make allocations fail
17:01:19JdGordonfail with EBUFFERBUSY
17:01:24JdGordoninstead of EBUFFERFULL
17:01:36gevaertsUsing a trivial compactor implementation, yes. Later on a smarter compactor could fix that
17:01:42kugelisn't EAGAIN for that already? :)
17:02:49gevaertsAnd 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:15kugelso 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:10kugelwith knowledge about threads buflib could wait for the unlock instead of failing
17:04:14JdGordonerr... wait a seccy... we need to register a callback for every handle allocation we allow to move?
17:04:32gevaertskugel: that would be easy to do if you have lock/unlock functions
17:04:41kugelJdGordon: no, there's a default callback
17:07:50 Quit [Saint] (Ping timeout: 252 seconds)
17:13:34kugelgevaerts: I meant without those functions
17:13:53kugeljust record the thread id with the allocation
17:14:45gevaertsYou really prefer that sort of restriction over locking functions?
17:14:56kugelwhat restriction?
17:15:30gevaertsYou then have to do the allocation from the same thread as using the memory
17:16:07kugelhmm, I didn't think it was a restriction, but perhaps it is
17:16:42 Quit user890104_ ()
17:17:11gevaertsI'd say it violates the principle of least surprise you want in APIs
17:17:16kugelbut I would rather not create a convinient way to block out compaction entirely :\
17:18:07kugelbut I also must say that I prefered discussion about the API when I specifically asked for it
17:18:10gevaertsI 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:14kugelnot a month later
17:18:23gevaertsOh, I don't disagree there
17:18:46CIA-14New 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:41gevaertsIt'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:41kugelpamaury: didn't you say on the devcon that you're happy with the sw i2c and dislike all the different implementations?
17:21:03pamauryyes until I discover that it didn't do clock stretching
17:21:22kugeli think you forgot to add the file
17:21:25pamauryso I did my owm implementation using the hardware
17:21:48kugelso we have 2 more now, wodz also made one
17:22:10CIA-14New commit by pamaury (r30121): imx233: add missing i2c file
17:22:49 Quit Darkknight512 (Ping timeout: 240 seconds)
17:22:56CIA-14r30120 build result: All green
17:24:15kugelgevaerts: 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:44kugelbut without two ways of making a handle unmovable and no new metadata
17:26:15gevaertskugel: 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:00CIA-14r30121 build result: All green
17:27:29kugelgevaerts: how?
17:27:59kugellock vs set_cbs(no_move_cbs) and unlock vs set_cbs(move_cbs)
17:28:28kugel(un)lock(handle) even
17:28:59gevaertskugel: assuming the default callback, those are indeed rather similar, but code that has a real callback basically has to reimplement locking functions
17:29:23kugelno, no_move_cbs will contain NULL
17:29:33 Join kkit|sh [0] (~kkit@li135-248.members.linode.com)
17:29:33kugeland I rather have it less convinient to do locking, indeed
17:29:45gevaertsah, right
17:29:56 Quit preglow (Ping timeout: 258 seconds)
17:30:06gevaertsAlso, 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:37kugelnot really, as they're interchangable
17:31:39gevaertsAnd I'm really worried that trying to make locking non-obvious to avoid extraneous locking will lead to missing needed locks
17:32:11kugelin fact, I would probably implement the lock by setting a NULL move callback
17:32:30kugelbut doing it internally is harder because the original needs to be stashed somewhere
17:32:31gevaertsThey're not. Calling buflib_lock() implies a contract that you're going to call buflib_unlock() at some point
17:32:59gevaertsWhile setting a callback does no such thing
17:33:35kugelthere doesn't need to be such a contract
17:34:13kugelyou can alloc with no_move_cbs and allow move later with move_cbs
17:34:39kugeli.e. you don't have an explicit lock call
17:34:40gevaertsYes, and then you can set no_move_cbs again
17:34:48gevaertsAnd then leave it that way
17:35:28kugelyea, why not
17:35:46gevaertsAnd then you can't wait anymore in an allocation
17:36:01kugelso we don't wait, it
17:36:13kugelit's potentially troublesome anyway
17:36:45gevaertsAll 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:00kugelwhat I propose is already implemented, basically
17:38:43gevaertsThose locking functions are ten lines of code
17:39:25kugelI see on advantage in the locking functions, but I see that they make it easy to over use locking
17:39:44kugelno*
17:40:00kugellocking and setting a no_move_cbs is the same thing
17:40:42gevaertsExcept that you make it (possibly a lot) harder to change the implementation later on
17:41:09gevaertsAnd 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:13gevaertsA missing lock will lead to an unreproducible crash
17:43:27gevaertsAnd your design is meant to encourage those
17:43:43kugelwhy do you think that?
17:44:55gevaertsMaking sure people don't lock too often by making it non-obvious that one *can* lock directly implies that
17:46:59kugelwell, it would be documented that this can be used to lock
17:47:47kugelyes, 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:17n1si 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:11kugeln1s: 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:45rasherAlexP: Llorean
20:42:00rasherOVER HERE
20:42:08AlexPwatcha
20:42:13rasherWhy would we close up flyspray in favour of the mailing list? Makes no sense to me
20:42:24AlexPOne moment
20:42:30rasherOne convenient method, closed in favour of a massively inconvenient one
20:42:33LloreanIt seems like needlessly closing a channel for people to contribute.
20:43:14LloreanBasically, "let's make it more inconvenient for people who don't want to use git right now"
20:43:42AlexPIn your opinion
20:43:43gevaertsHow are we doing that?
20:44:03AlexPPlenty of people (in fact the majority since it was passed) find the mailing list more convenient
20:44:09gevaertsThe point is to close a way for people to have their patches ignored
20:44:17 Join user890104 [0] (~Venci@6bez10.info)
20:44:50rasherWhat are you talking about
20:44:51AlexPI'm not too bothered personally, so am not the best person to put forward the arguments
20:45:05LloreanAlexP: If it's more convenient, why has less than 5% of total patches come from it?
20:45:17rasherPlenty of patches from flyspray get committed
20:45:22AlexPLlorean: Because we point people at flyspray
20:45:28rasherand it's not like we'll suddenly be better at committing patches
20:45:30gevaertsFlyspray creates the expectation that people will deal with patches, which in many cases doesn't happen
20:45:39AlexPBut 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:45AlexPAs I say, I don't care
20:45:49Lloreangevaerts: 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:50AlexPI'll ignore both :)
20:46:03rashergevaerts: So what, we just end up opening another way for people to get their patches ignored
20:46:07LloreanOn flyspray at least it's sortable, searchable, and has a UI
20:46:11rasher*AND* make it harder to follow up and search for them
20:46:19rasherWhat the hell is the point of that
20:46:22LloreanIf we had a UI for the ML that let people search for threads with patches attached, etc, my opinion would be different.
20:46:25LloreanIt's the UI that's the issue.
20:46:34AlexPrasher: 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:55LloreanBoth 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:22gevaertsrasher: so we shouldn't have decisions?
20:47:25rasherRockbox should be run by the developers. Not the developers with cash and opportunity to go to devcon
20:47:26LloreanAlexP: 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:30AlexPI 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:39AlexPLlorean: yes, this is true
20:47:47rashergevaerts: Not what I said.
20:47:51AlexPrasher: OK, send it to the RSB
20:47:52LloreanThis clearly wasn't done about this issue, or we'd have a place you could point us to reference.
20:48:03AlexPLlorean: Yes, true
20:48:15gevaertsrasher: so how *do* we take decisions?
20:48:22AlexPgevaerts: We don't, we argue
20:48:31LloreanMaybe 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:33rasherWell apparently by seeing who will pay to get to take them
20:48:51AlexPDon't be silly
20:48:58LloreanPerhaps 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:10rasherAlexP: well it's what's happening
20:49:13AlexPThere is also the option to be online during devcon
20:49:20AlexPI realise this isn't always possible either
20:49:22LloreanAlexP: That's not a real, good option.
20:49:28AlexPBut you can never get everyone together
20:49:35LloreanDuring devcon people watching online miss a good portion of what goes on
20:49:38AlexPSo, take it to the RSB
20:49:41rasherAlexP: sure we can. On the ML
20:49:45Lloreanmic pickups can't pick up everything, or isn't even on for a while.
20:49:51AlexPrasher: That never gets anywhere
20:50:01AlexPAt some point you have to take a decision
20:50:08rasherRight, so we're back at the people with the money take the decisions
20:50:16gevaertsrasher: the mailing list was going to be my example of how we *don't* take decisions
20:50:40Lloreanrasher: 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:56AlexPIn fact, I'll take it to the RSB
20:51:01LloreanBut I don't think it should be discussed on the ML necessarily, at least not the way we normally do.
20:51:04AlexPI'll send them an email, they can decide
20:51:25LloreanDiscussion 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:26rasherCC the -dev ml
20:51:28rasherplease
20:51:49AlexPer, that isn't necessarily part of the RSB
20:51:53AlexPit depends what I ask
20:51:59gevaertsLlorean: what if there is a consensus at devcon? Who's going to present the opposing side's case?
20:52:02AlexPBut should be fine here
20:52:11 Join Topy [0] (~Topy44@f048017039.adsl.alicedsl.de)
20:52:36rashergevaerts: as if that's going to happen
20:52:45AlexPgevaerts: 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:46Lloreangevaerts: If there's a unanimous consensus at devcon, the issue probably wouldn't have made it to *needing* discussion at devcon
20:53:06Lloreangevaerts: 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:21gevaertsrasher: as if what is going to happen?
20:53:29AlexPTime is "wasted" discussing the issues to decide that everyone agrees
20:53:39rashergevaerts: consensus on a contentious issue
20:53:51AlexPIt has on plenty in the past at devcon
20:54:01gevaertsrasher: you've never seen devcon results?
20:54:21AlexPLoads 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:30LloreanIf 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:46rasherI guess I wouldn't know, as one of the plebs
20:54:51n1si tink it's quite natural that the people parttaking in the discussions at a devcon can make decisions
20:54:52LloreanIf the issue was contentious, you present the ideas that caused people to object about it, and the way they were addressed.
20:54:56gevaertsLlorean: it also means several people now believe that their previous arguments are invalid
20:55:20Lloreangevaerts: 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:39n1sbut this is always the case with our "discussions", people miss them and jump in after weeks have passed
20:55:41LloreanJust 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:16Lloreann1s: 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:35rasherRather 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:39LloreanIn 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:54AlexPrasher: That doesn't work
20:57:24LloreanI 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:29rasherAlexP: Great arguments
20:57:35kugelwhat, why call the RSB for the flyspray thing?
20:57:45AlexPkugel: see above
20:57:56kugelthe entire RSB was at the devcon, we know what the RSB thinks
20:58:09n1sLlorean: 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:33rashern1s: it's not redundant at all
20:58:55rashergerrit sets the bar a lot higher for contributors
20:59:06n1sand there has been length discussions about the patch tracker in here after that
20:59:27gevaertsrasher: gerrit is *NOT* a requirement for contributors!
20:59:51rashergevaerts: only if you live in a world where the ML is a useful Flyspray replacement
20:59:52kugeln1s: right, we discussed it here as well
20:59:54Lloreangevaerts: 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:12kugelLlorean: that's the point
21:00:21kugelwe don't want the convinience of a patch tracker anymore
21:00:23Lloreankugel: THe point is to force people to us git?
21:00:27gevaertsLlorean: patches aren't meant to be indexed and searchable. They're meant to be developed until they're ready, and then committed
21:00:31kugelbecause that's what makes patches rot
21:00:37n1srasher: i think flyspray is aweful and that a ML indeed is nicer
21:00:45n1sawful even
21:00:57kugelwe want to prod people to actively work on the patches in order to not get forgotten
21:01:04rasherThere's no way to find patches which have been posted to the ML
21:01:09Lloreangevaerts: 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:21rasherWhat Llorean said.
21:01:23kugelrasher: exactly, so they need to be posted again, until they are committed
21:01:26n1srasher: the point is that the patches should either get commited fairly quickly or dropped
21:01:31LloreanIt's not bad if they rot for a while. It's bad if they're *forgotten*
21:01:33rasherkugel: GOOD GOD that's retarded
21:01:54AlexPkeep it civil
21:01:55kugelwe don'T want to host patches anymore which don't make it in because people don't work on them
21:02:04Lloreann1s: If that happened we wouldn't have AA fonts. Or album art. Or a host of other features.
21:02:06n1syou can't think the current system is working well
21:02:14rasherSo we just want to cut out the contributors who don't write perfect patches
21:02:15rashergotcha
21:02:17LloreanWe'd have dropped them early on because they rotted for a while
21:02:29AlexPyeah, exactly that /sarcasm
21:02:34 Join Stummi [0] (~Stummi@rockbox/developer/Stummi)
21:02:35rasherAlexP: oh stuff it
21:02:39kugelrasher: no, we want to review the patches more conviniently and tell people what to do
21:02:41AlexPindeed
21:02:55kugelflyspray is a nice place to *host*
21:03:05LloreanIs there some reason we can't *tell* people patches are likely to rot on flyspray, rather than just shutting it down?
21:03:06kugelpatches, but a horrible place to *review* them
21:03:08rasherkugel: and those who can't or won't do gerrit can go rot in hell
21:03:19AlexPmailing list
21:03:20n1sLlorean: perhaps, or knowing that this was the situation, perhaps the original posters would have worked more towards inclusion
21:03:25gevaertsrasher: if we say yes, will that make you happy?
21:03:28rasheraka 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:34AlexP...
21:03:40 Join T44 [0] (~Topy44@f048017039.adsl.alicedsl.de)
21:03:42kugelrasher: if you think about it, gerrit doesn't really raise the bar compared to flypray
21:03:47LloreanWhy not hook flyspray into the mailing list?
21:03:47kugelboth require registration
21:03:52rasherkugel: if you actually think about it, it does
21:03:53LloreanEvery patch submission, every comment gets an email
21:04:03LloreanThen you get your constant spam AND you get the ability to search and index them
21:04:03kugelrasher: really? I didn't see you trying gerrit
21:04:15rasherso?
21:04:24LloreanOr is "the best of both worlds" really worse somehow?
21:04:33rasherWell, the decision has clearly been made by the money people, no sense discussing it.
21:04:36 Part rasher
21:04:59LloreanI get an email when a task I'm watching is posted to. Wouldn't that work for the ML as well?
21:04:59kugelLlorean: flysprays emails are not threaded...
21:05:08Lloreankugel: So fix that.
21:05:20kugelhuh?
21:05:28kugelflyspray isn'T even threaded, how can the emails be?
21:05:45LloreanFlyrspray is "threaded" by FS#
21:05:51kugelbut not the comments
21:06:15LloreanNeither is the forum, but you can quote who you're replying to
21:06:25gevaertsFlyspray is a good place to ask how to use patches, so that's what people use it for
21:06:42kugelwe've always made decisions at the devcon, why is that a problem just now?
21:06:56n1sbecause people disagreed with the decision
21:07:07LloreanBecause people didn't even know about the decision.
21:07:25LloreanI 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:26kugelI'm sure the decision is documented somewhere?
21:08:13n1sLlorean: but as i said, and afaiu the decision was to throw out patches on fs IF we go with gerrit
21:08:31kugelanyway, 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:47Lloreann1s: So then I'll happily read the reasoning for that, if someone can point me to it.
21:09:09Lloreankugel: 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:14kugeln1s: well, actually to drop flyspray and go with the ML was before even discussing the git change
21:09:40n1skugel: ah
21:09:58kugelLlorean: we can reopen flyspray if the ML fails, but right now I'm more hopeful that the ML is better than FS
21:10:23kugelsimply because FS doesn't work at all
21:10:48n1si 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:26Lloreankugel: 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:29n1splenty of other *big* projects use ml's for patch submission quite effectively
21:11:39gevaertsOriginally the Swedes wanted to drop flyspray for patches and move to the mailing list, and Torne wanted a patch review system
21:11:45kugelgerrit is so much nicer to review patches and tell specifically what we don't like, even on a per-line basis
21:11:53LloreanThis isn't about FS vs Gerrit
21:11:57LloreanIt's about FS vs the mailing list.
21:12:00LloreanIt's "what to do with patches"
21:12:19kugelLlorean: right, but people posting to FS think we are responsible to look at the patches, which is not true
21:12:28LloreanAnd you aren't responsible on the ML either
21:12:29AlexPLlorean: Disregarding the issue of ml vs fs, you are completely right about the communication
21:12:32kugelbut that's why the patches rot
21:12:49n1swe can't really fix the devs :)
21:12:52LloreanAlexP: Yeah, that's the part that actually bothers me.
21:13:04Lloreann1s: So why are you trying to by moving to the ML and saying it'll improve things?
21:13:05kugeln1s: and we don't try to
21:13:14gevaertsLlorean: wild thinking here, but what if we had an automated email to gerrit submission system?
21:13:19kugelwell, we try by making review with gerrit easier :)
21:13:34Lloreangevaerts: 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:43n1sLlorean: if we can make things easier hopefully more devs will eview patches
21:13:50Lloreann1s: The ML doesn't really make things easier.
21:13:54kugelbut by going to the ML we try to make clear patches aren't our responsibility
21:13:58n1sand that is your opinion
21:14:00kugelbut the authors
21:14:20Lloreankugel: And this wasn't obvious to so many of us, how's it obvious to the submitters?
21:14:36gevaertsLlorean: 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:37LloreanAnd how's it better than say, a disclaimer page when submitting a patch that makes that point explicit instead?
21:14:54Lloreangevaerts: Yeah, if the ML patches automatically ended up on gerrit, I'd probably be fine with things.
21:15:03AlexPLlorean: You should know from forum experience that people never read that sort of stuff :)
21:15:13Lloreangevaerts: I have one real goal: Don't lose patches of non-git submitters.
21:15:30kugelwe specifically want patches to get lost if nobody is interested enough
21:15:37kugelthe ML is good for that
21:15:38LloreanAlexP: 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:39gevaertsLlorean: I'm not sure if that's even a practical idea at this point though
21:15:53AlexPLlorean: agreed :)
21:15:57Lloreangevaerts: It'd work fine if FS were left up, but actively discouraged.
21:16:24LloreanConsidering 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:37kugelthe former
21:16:51kugelbecause it'll force the author to do something about it
21:16:53Lloreankugel: Then why don't you delete a LOT more old patches of flyspray during cleanup weeks?
21:17:07gevaertsmystica555: no. We
21:17:11Lloreanmystica555: We keep the bug portion
21:17:16kugelI closed some 30odd patches at the devcon
21:17:18gevaertsmystica555: no. We're reasonably happy with FS as a bug tracker
21:17:23Lloreangevaerts: Can you attach a patch to a bug that fixes it, or are we disallowing that too?
21:17:43mystica555ok. 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:45Lloreankugel: 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:12kugelLlorean: FS can't do that
21:18:17Lloreankugel: You can.
21:18:19kugelgerrit can
21:18:43gevaertsLlorean: 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:49Lloreankugel: You said you closed 30. Why didn't you close more?
21:19:00kugelbecause it's a boring and lenghty task
21:19:07Lloreangevaerts: So how do you link patches in gerrit to bugs in flyspray?
21:19:15mystica555y'all can go on with your petty bickering :) just wanted to make sure you werent entirely shooting yourselves in the foot.
21:19:31Lloreangevaerts: What if someone finds a bug *and* wants to submit the patch in a single go? They have to reply to themselves?
21:20:02kugelLlorean: they push the patch to gerrit including the bug description
21:20:05AlexPmystica555: Saying things like that really doesn't help make the "bickering" any less petty
21:20:35Lloreankugel: 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:40mystica555AlexP: 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:52gevaertsLlorean: 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:05Lloreangevaerts: Is there a way to push unified diffs to gerrit then?
21:21:16kugelLlorean: the ML can take any patch form
21:21:17LloreanThat would more or less solve the problem.
21:21:26Lloreankugel: And is a *terrible* bug tracker.
21:21:35gevaertsLlorean: that would be this hypothetical mailing interface :)
21:21:39AlexPmystica555: 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:54n1sLlorean: we already get patch submissions with "fix foo"
21:22:27AlexPLlorean: It isn't a bug tracker - in that case it'd be a patch to fix xxx
21:22:28Lloreann1s: So bad ones justify removing the possibility of good ones?
21:22:40gevaertsLlorean: 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:45LloreanAlexP: But if it's the wrong patch, or the wrong fix, it becomes a bug with a candidate patch to fix it.
21:22:46mystica555i'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:24Lloreangevaerts: 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:50Lloreangevaerts: It'd be nice to have those directly attached to the bug task
21:23:55LloreanEven if someone else opened the bug
21:24:01AlexPmystica555: 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:19AlexPLlorean: And the patch is worked on in whatever place it is
21:24:20mystica555and 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:30n1sLlorean: 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:45gevaertsLlorean: 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:53AlexPLlorean: But as I say, I don't actually care about flyspray vs mailing list personally
21:24:55Lloreangevaerts: Nope
21:25:17gevaertsmystica555: I don't think anyone ever argued that we should have no dedicated bug tracker
21:25:19Lloreangevaerts: That's fine. But it seems a rather gray area when you start saying "some patches only"
21:25:49LloreanI just don't believe removing flyspray will make significant headway toward solving the problem it sounds like you're trying to solve.
21:25:52mystica555gevaerts: 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:23Lloreangevaerts: 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:51gevaertsLlorean: you know what devcons are like. *Nobody* has a clear summary :)
21:26:54LloreanI 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:42gevaertsThat reminds me actually. I should edit my recordings...
21:27:52LloreanIt'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:23AlexPLlorean: 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:55AlexPI would have thought the aim should be to close things on gerrit too
21:29:06LloreanAlexP: 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:28LloreanWhich is why I want a proper summary, it feels like I *must* be missing some salient fact.
21:29:32AlexPLlorean: Well, I guess a don't have loads of places for that to happen could be argued
21:29:57LloreanYeah, but Flyspray + Gerrit is as many places as Flyspray + ML
21:30:14kugelwell, we want to try anyway
21:30:17AlexPyes, but fewer than flyspray + gerrit + ml :)
21:30:31kugelthat 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:35LloreanAlexP: We get like, 1.5 submissions via the ML per year. It may technically be a place, but...
21:30:51AlexPLlorean: Yes, because we tell everyone to use flyspray
21:31:09LloreanYeah, and we could tell everyone to use gerrit unless they have to use flyspray (for whatever reason)
21:31:16AlexPLlorean: 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:35AlexPThe ml vs fs doesn't bother me :)
21:31:49 Quit Thra11 (Ping timeout: 260 seconds)
21:32:11LloreanAlexP: 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:42gevaertsI'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:48AlexPLlorean: Yes, that would be good where possible
21:33:01AlexPgevaerts: Yes, that's what I meant
21:33:14n1syeah we are pretty bad at consensuses
21:33:32gevaertsYes, next time we need to apppoint a secretary
21:33:43gevaertsWith fewer ps obviously
21:33:49AlexPI'd love us to be able to do it more inclusively, but the only place decisions are ever taken are at devcon
21:34:14AlexPIf someone came up with a better system that actually worked, then great :)
21:34:58gevaertsdevcon also only half works because we tend to forget about communicating properly
21:35:16LloreanI 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:57LloreanDevcon'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:31AlexPgod, a month of arguments like this would be awful :)
21:36:49AlexPWe tend to decide what needs arguing about by someone putting it on the agenda
21:36:50LloreanRestrict 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:54LloreanSo you can just ignore things wholesale.
21:37:09AlexPIf it didn't need arguing about, it wouldn't get brought up :)
21:37:26LloreanAlexP: Yeah, but needing arguing about is different from needing an explicit all-hands vote.
21:37:46AlexPLlorean: 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:34LloreanTrue. 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:41AlexPheh :)
21:39:15LloreanReally 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:50AlexPyep
21:44:39LloreanThen we'd actually at least now what we're arguing about. ;)
21:44:53AlexPWould that help? :P
21:45:25LloreanDefine "help"
21:45:57LloreanIf *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:37LloreanAnd 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:51LloreanIf it's just "because we don't like it" there's not much to be done.
21:47:27LloreanIt won't 'help' in the sense of decreasing argument, I imagine.
21:48:49gevaertsLlorean: 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:08LloreanOkay
21:49:15LloreanAssuming I remember too. :)
21:49:50gevaertsNo decent microphones probably, but I distributed DAPs around the room
21:50:01LloreanShould 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:49kugeland we historically failed to make decisions on the ml
21:54:30LloreanThere's a difference between asking people "make a decision" and giving people a couple explicit options and saying "vote"
21:54:49LloreanIt'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:08AlexPLlorean: 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:11LloreanPlus, if there's really more people at devcon then allowing the ML to join in the vote shouldn't change the outcome. ;)
21:56:22Lloreangevaerts: That should never be an option.
21:56:57gevaertsLlorean: knowing us, I tend to agree
21:57:01LloreanAlexP: 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:58AlexPyeah
21:58:16LloreanIt's not a perfect option, but compromises rarely are. I just think it *might* be better.
21:58:38AlexPwe could always give it a go :)
22:00
22:00:02LloreanAt 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:21LloreanThen, once that's worked out, you can work out *how* they do it.
22:01:44gevaertsLlorean: 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:03gevaertsThat way people know what they're voting for in the RSB vote
22:02:17AlexPThe next one will be soon, right?
22:02:59 Join petur [0] (~petur@rockbox/developer/petur)
22:03:25gevaertsWell, 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:39AlexPWell, whenever is fine :)
22:04:00AlexPI was just trying to remember when the last one was
22:04:13gevaertsThe first one was July, the last one was September
22:04:25AlexPah, I must have been remembering the first one
22:06:14Lloreangevaerts: That makes a lot of sense.
22:08:51paulkhi! 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:47Torneok 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:52Torneso *anyone who wants to contribute* has to use git
22:16:03Tornebecause you can't get the source code anywhere else
22:16:34Torneactually creating a gerrit account takes no longer than creating an FS account
22:16:49Torneand 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:05LloreanTorne: So why do we need ML for patches at all then? Why not "no submissions except through gerrit?"
22:22:00Tornei don't think we do
22:22:21Tornenobody except me had actually *used* gerrit at the point this was being discussed
22:22:29Tornethey didn't know the exact steps involved
22:22:39Tornethis is why we have the demo :)
22:23:31LloreanIf we're dropping all patch submission entirely, and only using gerrit, that's fine by me
22:23:43LloreanMy objection is to dropping Flyspray for the ML for diffs.
22:24:30Tornei 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:14Torneonce you create an account the process to submit a patch is "git commit -a; git push origin HEAD:refs/for/master"
22:25:16LloreanI don't see any problem with refusing them if we don't want them.
22:25:27Torneversus "git diff" to get the diff of your changes
22:25:38B4gderwhy would we forbid patches on the mailing list?
22:25:47Torne(which you then have to email/upload to FS)
22:26:22LloreanB4gder: 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:37B4gdersure, that may be a better way
22:26:52B4gderbut posting on the mailing list is a long lived tradition in open source
22:27:07B4gder(and one that I personally like)
22:27:18Tornenobody 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:28B4gderright
22:28:16kugelwell, as I understand it we go from "please use flyspray" to "use the ML or, preferably, gerrit"
22:32:45pixelmaI'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:44Tornei 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:28pixelmaI understood the Swedes that they wanted patches on the ml, the gerrit suggestion came later
22:36:14B4gderyes, and we all said "let's try it out"
22:36:52B4gdera primary idea is to reject or comment patches earlier
22:37:08B4gderto not accept crap, but bounce them off earlier to have the submitter do the leg work
22:37:45B4gderas the current way of work encourages a "dump it with the dev team and let them work on it"
22:38:42soapWhat 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:21B4gderaccepting new patches in FS is not useful imho
22:39:25paulkwhat's the utility to flash philips Gogear SA52xxx devices?
22:39:35Lloreansoap: 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:22B4gderLlorean: 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:27LloreanBut 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:53LloreanB4gder: 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:00LloreanYou can't really guess on that sort of thing
22:41:20B4gdercorrect, 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:45LloreanWhat 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:48pixelmaall... 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:14B4gderLlorean: the key is who's driving the development further, not the tool itself
22:43:34Tornethe tool is kinda independant from our attitude and communication here
22:43:37Tornewell, and policy
22:44:09Torneas 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:19soapso we talking a new -patch ML or throwing this all in -dev wholesale?
22:44:44Tornewhat 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:53B4gdersoap: we're talking about using gerrit
22:45:26B4gderthe mail list stuff is much more how *I* view and like things to happen rather than the majority
22:45:32soapso no FS patches, no ML patches, gerrit period?
22:45:44B4gdergerrit is the new FS
22:46:04B4gderwe didn't do them on the mail list before, and we won't particularly change that now
22:46:20soapthen this tempest is over...?
22:46:37Lloreansoap: 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:09Torneit probably is possible to have patch submission to gerrit by email, btw
22:47:23Tornebut don't be expecting me to implement that right away ;)
22:47:28LloreanThe tempest was over it being presented as if we'd have two channels. Gerrit + ML. When really the goal is one channel.
22:47:34soapOk, I grok the scrollback now. Thanks.
22:47:40AlexPLlorean: I thought we were, so if not that was my mistake
22:47:53soapAnd SVN gets shuttered in favor of git when?
22:47:56LloreanIt seemed pointless to close down Flyspray in favor of Mailing List. The argument didn't really involve Gerrit.
22:48:03Tornesoap: that was independantly decided beforehand :)
22:48:05LloreanOr at least *my* argument didn't.
22:48:26Tornesoap: continuing to have git mirrored from svn removes the ability to usefully work on branches
22:48:35kugelwell, I understood that we don't discourage the ML anymore as much as we do now
22:48:53AlexPkugel: me too
22:48:59AlexPAs it is is a viable channel
22:49:00soapTorne, right. Forgive me as I've been deep out of town for almost a quarter now.
22:49:04pixelmaI thought gerrit was outside the original discussion as well, though of course it can play a role
22:49:04Tornesoap: sure.
22:49:06soapIs SVN already shuttered?
22:49:08Tornesoap: no
22:49:16soapBut it will be?
22:49:17TorneI haven't yet moved gerrit onto our real infrastructure
22:49:18kugeland that it's not simply s/flyspray/gerrit/
22:49:34AlexPkugel: This too was my impression
22:49:38Lloreansoap: 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:40AlexPBut I don't actually mind
22:49:46Tornesoap: yes, at some point we will kill svn and change things like th ebuild system to pull from git
22:49:51kugelperhaps it was a bit confusing because we decided pro-ml before we discussed the whole git and gerrit stuff
22:50:00Torne(not the current git mirror, a better conversion I have now done :)
22:50:05AlexPkugel: yes, probably
22:51:28soapso 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:47Tornesoap: Don't do it right now
22:52:07TorneThe current git mirror (the one we've had a while) is not what we will be using
22:52:26Torneand the converted repo i ahve up on gerrit is not being updated from svn automatically
22:52:42Torneso 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:04Torneyou might want to try out using git and gerrit on the sandbox repository, though
22:53:12soapIt 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:27Tornesee http://www.rockbox.org/wiki/GerritDemoGuide
22:53:31soapbut thank you all for the clarification.
22:54:19darndudesome1 knows anything bout running RB on a 6G iPod?
22:55:47Tornesoap: sure. You can start using it on the sandbox repo now, though
22:55:58Torneincluding both committing directly and submitting stuff for review to gerrit
22:56:03Torneand reviewing stuff
22:56:11Torneit just isn't the rockbox code ;)
22:56:16Tornewell, it's a small chunk of it with no history
22:56:26Torneand 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:28darndudeany1 some help for me?
23:10:43 Quit esperegu (Read error: Connection reset by peer)
23:11:37pixelmadarndude: not many know about the Ipod 6G port I think, but asking a more specific question may help too
23:22:14darndudeit 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:55AlexPyeah, 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:27sideralLlorean, 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:41sideralI'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:56sideralI'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...)

Previous day | Next day