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).

Notice: Only Gecko based browsers prior to FF4 support the multipart/mixed "server push" method used by this log reader to auto-update. Since you do not appear to use such a browser, this page will simply show the current log, and not automatically update.

#rockbox log for 2011-09-28

00:01:22Viperfanghidden folder :P
00:03:13 Join ReimuHakurei [0] (~reimu@208.119.81.194)
00:06:11freddybI didn't hide it!
00:06:20 Quit ReimuHakurei (Remote host closed the connection)
00:07:22 Quit FlynDice (Remote host closed the connection)
00:22:01 Quit ender` (Quit: The trouble with quotes found on the Internet is that they often turn out to be unreliable.-- William Shakespeare)
00:22:33BiontI just don't get why my keeps breaking. What's wrong with it? http://pastebin.com/PESgciq9
00:23:49 Quit [Saint] (Ping timeout: 252 seconds)
00:24:04BiontAnyone who reads this: I'm trying to make my old theme work again that I once build for my D2. There's lots of stuff I need to catch up on, but I don't get what could be wrong with the specific part described in the link
00:27:03 Quit pamaury (Remote host closed the connection)
00:27:19 Quit freddyb (Quit: Leaving)
00:29:53 Quit liar (Remote host closed the connection)
00:32:32 Join Scromple [0] (~Simon@115-64-195-104.static.tpgi.com.au)
00:40:36 Join [Saint] [0] (~st.lasciv@203.184.50.187)
00:41:03 Quit ChickeNES (Quit: Computer has gone to sleep.)
00:41:53 Join ved2 [0] (~ved@2001:41d0:1:5914::2)
00:41:58 Part ved
00:50:01 Quit Strife89 (Quit: Vamoose!)
00:50:08 Join ChickeNES [0] (~ChickeNES@rouxbicon.rh.uchicago.edu)
00:50:31Biontand for the help I already got in here)
00:50:46Biontdamnit, it ate my msg again
00:51:44BiontI said I made a forum post with my problem. thanks in advance for the help there
01:00
01:01:02 Nick ved2 is now known as ved (~ved@2001:41d0:1:5914::2)
01:06:06 Quit ChickeNES (Quit: Computer has gone to sleep.)
01:09:53 Join ChickeNES [0] (~ChickeNES@rouxbicon.rh.uchicago.edu)
01:21:15 Quit Biont (Quit: CGI:IRC)
01:22:36***Saving seen data "./dancer.seen"
01:43:35 Quit [Saint] (Ping timeout: 260 seconds)
01:56:33 Join [Saint] [0] (~st.lasciv@203.184.50.187)
01:56:59 Join tjb0607 [0] (~quassel@208-100-128-206.bendbroadband.com)
01:58:50JdGordonbertik: well, its not like i wasnt trying to get more testers... which was ignored
01:59:12JdGordon[Saint]: Zagor: you could fake the volume popup in the lists with skinned lists if you really wanted it
01:59:35JdGordonbut generally it wouldnt work ecause we dont have proper viewport layering
02:00
02:00:41JdGordonand regarding auto-skin-resizing.... I wanted to have a script which would resize our source cabbie skins to the specifc size from maybe 4 or 5 source copies instead of 20
02:00:55JdGordonit cant really be done on target for a number of reasons
02:01:34JdGordonand the script ideas was basically rejected because the output would probably be too crap and need fixing manually anyway
02:08:53 Join marc [0] (~chatzilla@94-193-248-10.zone7.bethere.co.uk)
02:09:00 Nick marc is now known as marc2003 (~chatzilla@94-193-248-10.zone7.bethere.co.uk)
02:09:17 Quit [Saint] (Ping timeout: 244 seconds)
02:11:45marc2003hi guys, i have 2 amsv2 devices and they were both affected by the problems introduced with r30589. there was a task on flyspray but that has now been closed as fixed.
02:12:35marc2003my problem is that only 1 of my players now works. i have a clip+ which is working again but i also have a clip v2 which is exhibiting the old problem. should a new task be made or should someone here re-open the old one??
02:13:39marc2003the task was FS #12292
02:13:40fs-bluebothttp://www.rockbox.org/tracker/task/12292 3Sansa Clip+: Cannot boot since r30589 with real target (bugs, closed)
02:20:29 Join funman [0] (~fun@209-197-170-153.cpe.distributel.net)
02:20:56 Quit funman (Changing host)
02:20:56 Join funman [0] (~fun@rockbox/developer/funman)
02:46:02 Join Keripo [0] (~Keripo@eng227.wireless-resnet.upenn.edu)
02:52:24 Part marc2003
02:54:51 Quit ChickeNES (Quit: Computer has gone to sleep.)
03:00
03:02:51CIA-14New commit by 03jdgordon (r30614): fix FS #12295
03:04:42CIA-14r30614 build result: All green
03:09:40 Quit bluefoxx (Ping timeout: 255 seconds)
03:14:44 Join ChickeNES [0] (~ChickeNES@rouxbicon.rh.uchicago.edu)
03:15:46 Join bluefoxx [0] (fuzzylomba@S0106e0cb4e0a6d8a.vs.shawcable.net)
03:22:37***Saving seen data "./dancer.seen"
03:23:03 Join [Saint] [0] (~st.lasciv@203.184.50.187)
04:00
04:02:12 Quit tmzt (Ping timeout: 240 seconds)
04:04:26 Join tmzt [0] (~tmzt@adsl-69-208-14-69.dsl.akrnoh.ameritech.net)
04:19:21 Join tmzt_ [0] (~tmzt@adsl-69-208-11-149.dsl.akrnoh.ameritech.net)
04:23:00 Quit tmzt (Ping timeout: 260 seconds)
04:37:24 Quit amiconn (Disconnected by services)
04:37:25 Join amiconn_ [0] (quassel@rockbox/developer/amiconn)
04:37:25 Quit pixelma (Disconnected by services)
04:37:27 Join pixelma_ [0] (quassel@rockbox/staff/pixelma)
04:37:29 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma)
04:37:47 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn)
04:42:17 Quit [7] (Disconnected by services)
04:42:26 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven)
05:00
05:07:27 Join Topy [0] (~Topy44@f049178186.adsl.alicedsl.de)
05:11:11 Quit T44 (Ping timeout: 248 seconds)
05:11:41 Join ReimuHakurei [0] (~reimu@wireless.sit-co.net)
05:22:38***Saving seen data "./dancer.seen"
05:25:43 Quit mc2739 (Quit: leaving)
05:42:11 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739)
05:42:51 Quit ChickeNES (Quit: Computer has gone to sleep.)
05:46:03 Quit Horscht (Quit: Verlassend)
05:50:10 Quit simonlnu (Remote host closed the connection)
05:53:34 Join Rob2222 [0] (~Miranda@p4FFF0F7F.dip.t-dialin.net)
05:57:12 Quit Rob2223 (Ping timeout: 252 seconds)
05:57:35 Join Jak_o_Shadows [0] (~hayden@CPE-144-136-211-121.sa.bigpond.net.au)
06:00
06:02:37 Join Jak_o_Shadows1 [0] (~hayden@CPE-144-136-211-121.sa.bigpond.net.au)
06:03:24 Quit Jak_o_Shadows (Ping timeout: 240 seconds)
06:04:52 Join simonlnu [0] (a1uEnLmhma@unaffiliated/simonrvn)
06:28:00 Quit ReimuHakurei (Ping timeout: 255 seconds)
06:30:51 Join ReimuHakurei [0] (~reimu@wireless.sit-co.net)
06:47:09 Join kadoban [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net)
06:52:25 Join freddyb [0] (~freddybbb@216.8.239.112.etczone.com)
06:53:05 Quit freddyb (Client Quit)
06:58:15 Join ChickeNES [0] (~ChickeNES@rouxbicon.rh.uchicago.edu)
07:00
07:04:17 Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel)
07:10:44 Quit mshathlonxp ()
07:12:53 Quit funman (Quit: leaving)
07:16:03 Join T44 [0] (~Topy44@f049034078.adsl.alicedsl.de)
07:18:39 Quit Topy (Ping timeout: 248 seconds)
07:22:40***Saving seen data "./dancer.seen"
07:43:51 Join wodz [0] (~wodz@87-206-240-131.dynamic.chello.pl)
07:48:40 Quit tjb0607 (Read error: Connection reset by peer)
07:49:27 Quit wodz (Ping timeout: 255 seconds)
07:49:45 Join tjb0607 [0] (~quassel@208-100-128-206.bendbroadband.com)
07:50:25 Quit tjb0607 (Read error: Connection reset by peer)
07:51:01 Join tjb0607 [0] (~quassel@208-100-128-206.bendbroadband.com)
07:59:58 Quit tjb0607 (Read error: Connection reset by peer)
08:00
08:00:41 Quit ChickeNES (Quit: Computer has gone to sleep.)
08:01:21 Join tjb0607 [0] (~quassel@208-100-128-206.bendbroadband.com)
08:01:57 Join Jak_o_Shadows [0] (~hayden@CPE-144-136-211-121.sa.bigpond.net.au)
08:03:30 Quit Jak_o_Shadows1 (Ping timeout: 245 seconds)
08:08:37 Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel)
08:09:59 Quit powell14ski_ (Quit: powell14ski_)
08:10:01kugelpJdGordon: you had enough testers (my fs inbox wad full with messagesfrom that task) and they found many bugs. but in the end you got impatient...
08:18:44 Quit blind (Ping timeout: 252 seconds)
08:26:44 Join ender` [0] (~ender@foo.eternallybored.org)
08:28:00 Join Zagor [242] (~bjst@rockbox/developer/Zagor)
08:28:07 Join evilnick [0] (~evilnick@5e007ec9.bb.sky.com)
08:28:07 Quit evilnick (Changing host)
08:28:07 Join evilnick [0] (~evilnick@rockbox/staff/evilnick)
08:31:49 Join blind [0] (~blind@c-71-235-61-84.hsd1.ct.comcast.net)
08:35:13 Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel)
08:35:15 Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel)
08:36:26 Join B4gder [241] (~daniel@rockbox/developer/bagder)
08:39:23 Join wodz [0] (~wodz@87-206-240-131.dynamic.chello.pl)
08:40:08 Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel)
08:41:42 Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl)
08:41:42 Quit bertrik (Changing host)
08:41:42 Join bertrik [0] (~bertrik@rockbox/developer/bertrik)
08:51:22 Quit [Saint] (Ping timeout: 276 seconds)
08:59:52kugelJdGordon: if you're offline for a few days, then I too think the font commit should be reverted for now
09:00
09:01:27JdGordon1) every bug reported was fixed pre commit... 2) fix it yourself.. im so fucking close to just revoking my commit acces... you ersonally am the reason i have absolutly no fun here anymore
09:02:13kugelbertrik has still data aborts
09:02:26JdGordondid bertrik test while i was asking? no...
09:02:28kugelthe boot up crashes/freezes are apparently still not fixed
09:02:37 Join Jak_o_Shadows1 [0] (~hayden@CPE-144-136-211-121.sa.bigpond.net.au)
09:02:48kugelyou didn't really wait a long time.
09:04:08kugelyou should have, considering how many bugs were reported pre-commit. it was quite likely that more are to come
09:05:11 Quit Jak_o_Shadows (Ping timeout: 255 seconds)
09:06:21kugelanyway, I disagree we should have a possibly-not-even-booting rockbox any longer
09:13:43 Join webguest63 [0] (~4d6c62b0@www.haxx.se)
09:14:00JdGordonactually stuff it...
09:14:27JdGordonmy input is no longer deemed worthy of conciseration anynmore (and hasnt been for a while). the projects direction has been hijacked
09:14:35JdGordonim out... Zagor please disable my svn account
09:14:56kugelthat's not true
09:15:00JdGordonthis font issue is not the reason
09:15:13JdGordongood by
09:15:23kugel:\
09:15:28JdGordonI'll no longer be contriuting, feel free to cherry pick from my github account
09:16:21JdGordonthough the fact that its even suggested i should justify commits to code im the sole contirbuter is a pretty big final straw
09:17:46kugelbeing the sole contributor to one area doesn't make you immune to criticism
09:18:03JdGordonlike i said, its not that issue
09:18:39JdGordonwhoever moderates the commiters ml, please let that email through (it aparently doesnt like being bcced)
09:19:17JdGordonin the unlikely event of some serious project restructing happens i might come back, but i think most people woudltn care anyway
09:19:26JdGordonand now, afk for 3 days
09:19:35bertrikJdGordon, I'm not taking responsibility if you break something
09:19:48 Nick JdGordon is now known as jd|afk_til_sat (~jonno@rockbox/developer/JdGordon)
09:20:24kugelI'm sorry if it looked like your contribution is worthless. That wasn't my intention. They're very valuable
09:22:43***Saving seen data "./dancer.seen"
09:22:53 Quit Scromple (Quit: Leaving)
09:23:41 Join nick-p [0] (~nick@82-69-105-120.dsl.in-addr.zen.co.uk)
09:28:47 Quit bertrik (Ping timeout: 248 seconds)
09:29:21 Join petur [0] (~petur@rockbox/developer/petur)
09:36:13 Join God_Eater [0] (93722cd1@rockbox/staff/GodEater)
09:55:51 Quit webguest63 (Quit: CGI:IRC (EOF))
09:57:12 Quit wodz (Remote host closed the connection)
10:00
10:02:48 Join swilde [0] (~wilde@aktaia.intevation.org)
10:03:11 Join Jak_o_Shadows [0] (~hayden@CPE-144-136-211-121.sa.bigpond.net.au)
10:04:36 Quit Jak_o_Shadows1 (Ping timeout: 240 seconds)
10:15:38 Quit Llorean (Ping timeout: 260 seconds)
10:17:59 Join jordan` [0] (~gromit@posteauge.rsr.lip6.fr)
10:18:46 Join Llorean [0] (~DarkkOne@99-68-45-56.lightspeed.hstntx.sbcglobal.net)
10:24:25 Join pamaury [0] (81680b01@gateway/web/freenode/ip.129.104.11.1)
10:37:35 Quit GeekShadow (Ping timeout: 248 seconds)
10:38:45 Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl)
10:39:45 Join Jak_o_Shadows1 [0] (~hayden@CPE-144-136-211-121.sa.bigpond.net.au)
10:40:39 Quit Jak_o_Shadows (Ping timeout: 260 seconds)
10:41:51 Quit kadoban (Ping timeout: 248 seconds)
10:42:07 Join dfkt|n [0] (dfktn@chello062178002170.1.11.univie.teleweb.at)
10:42:07 Quit dfkt|n (Changing host)
10:42:08 Join dfkt|n [0] (dfktn@unaffiliated/dfkt)
10:49:26 Quit dfkt|n ()
10:50:50 Quit Keripo (Read error: Connection reset by peer)
10:53:33 Part nick-p ("Leaving")
10:54:22wodzJd withdrawal is rather said event :/
11:00
11:03:50 Join Jak_o_Shadows [0] (~hayden@CPE-144-136-211-121.sa.bigpond.net.au)
11:05:35 Quit Jak_o_Shadows1 (Ping timeout: 244 seconds)
11:09:20 Join GeekShadow [0] (~antoine@54.166.21.93.rev.sfr.net)
11:10:14 Quit mystica555 (Read error: Connection reset by peer)
11:10:15 Quit mystica555_ (Read error: Connection reset by peer)
11:11:34 Quit Jak_o_Shadows (Remote host closed the connection)
11:16:58 Quit GeekShadow (Ping timeout: 276 seconds)
11:17:37 Quit Llorean (Changing host)
11:17:37 Join Llorean [0] (~DarkkOne@rockbox/user/Llorean)
11:18:22 Join GeekShadow [0] (~antoine@77.166.21.93.rev.sfr.net)
11:19:16 Join mystica555_ [0] (~mike@71-211-199-174.hlrn.qwest.net)
11:22:22 Quit T44 (Ping timeout: 248 seconds)
11:22:47***Saving seen data "./dancer.seen"
11:26:51 Join mystica555 [0] (~Mike@71-211-199-174.hlrn.qwest.net)
11:38:23 Quit fs-bluebot (Ping timeout: 260 seconds)
11:38:44 Quit bluebrother^ (Ping timeout: 260 seconds)
11:39:37 Join fs-bluebot [0] (~fs-bluebo@g226070254.adsl.alicedsl.de)
11:40:02 Join bluebrother [0] (~dom@g226070254.adsl.alicedsl.de)
11:40:41 Quit bluebrother (Changing host)
11:40:41 Join bluebrother [0] (~dom@rockbox/developer/bluebrother)
11:47:24 Quit Bagder (Ping timeout: 240 seconds)
11:54:44 Join webguest99 [0] (~4d6c62b0@www.haxx.se)
11:57:03 Join n1s [0] (~quassel@rockbox/developer/n1s)
12:00
12:00:22 Join user829385 [0] (~aoeu@112.166.15.141)
12:00:55 Part user829385
12:30:48 Join Jerom [0] (~jerome@2a02:8420:215:f000:f66d:4ff:fe45:790f)
12:42:29 Quit wodz (Quit: Leaving)
12:43:41 Quit Jerom (Quit: Leaving.)
12:46:33 Join Jak_o_Shadows [0] (~hayden@CPE-144-136-211-121.sa.bigpond.net.au)
12:48:06 Quit Jak_o_Shadows (Remote host closed the connection)
13:00
13:20:19 Quit mamarley (Remote host closed the connection)
13:22:49***Saving seen data "./dancer.seen"
13:31:31 Part Zagor
13:32:11 Part LinusN
13:36:51God_Eatershould we clean up the "official" gerrit now, and bin most of the sandbox stuff that's there now?
13:37:08God_Eateror is it simply a 1-2-1 copy of what was on the VPS?
13:37:16God_Eaterand not really reflective of current svn?
13:48:53 Join matze` [0] (~pflaume@p5498A67E.dip.t-dialin.net)
13:55:59 Join XavierGr [0] (~xavier@rockbox/staff/XavierGr)
14:00
14:01:49 Join bluefoxx_ [0] (fuzzylomba@S0106e0cb4e0a6d8a.vs.shawcable.net)
14:04:01TorneGod_Eater: it's a copy of what's on the VPS
14:04:15TorneGod_Eater: The sandbox repo is as-is and we can clean it up at our leisure or leave it, either way
14:04:24Tornei am still manually replicating the real rockbox repos
14:04:43Tornehoping to get that happening automatically soon
14:04:46 Quit bluefoxx (Ping timeout: 255 seconds)
14:04:49God_Eaterah ok
14:04:51God_Eatercool
14:05:05Tornei wasn't going to delete the sandbox yet because people may not have tried, and also i think we need to play with policies a bit more
14:05:21God_Eaterthat makes sense
14:05:30Tornei've changed my mind about waht i think is a good policy
14:05:32Tornei thinik.
14:05:43Tornei think i've decided i don't like the current policy *or* the way everyone wanted
14:05:52Tornei'm leaning toward a third option :p
14:05:53kugelTorne: I thought you finished the conversion?
14:05:57God_Eaterwhich is? :)
14:06:02Tornekugel: hrm?
14:06:13Tornethe conversion doesn't finish until we stop making more changes to svn :)
14:06:24Torneit's up to date as of, er, last night
14:06:31Tornebut new changes keep happening! :)
14:06:42TorneGod_Eater: non-fastforward merges
14:07:00kugeldidn't you say you need to convert only once, and can then rebase after that?
14:07:06Tornekugel: what?
14:07:37Tornenot sure what rebasing has to do with anything
14:07:51kugellike, git svn rebase
14:07:53ukleinekkugel: if svn is converted up to say r10000 and you commit r10001 git doesn't know about r10001
14:08:06TorneOh. git svn rebase is irrelevant
14:08:11Tornethat only applies to repositories with local branches
14:08:19Tornethere is nothing to rebase in my intermediate repo
14:08:39Tornei just fetch from svn then push directly to gerritwith a refspec that remaps various names
14:08:55ukleinekkugel: the patch that svn knows as r10001 just needs to be applied to what git has for r10000
14:09:13Tornekugel: this is what i mean by conversion
14:09:19Tornesince this is just a continuation of the same process..
14:09:25Tornethat's how i went from r1, nothing has changed
14:09:31Torneit just happens in smaller increments now :)
14:10:06 Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl)
14:10:47TorneGod_Eater: i need to set up some examples or maybe just draw some example graphs to show the different policy choices that i'm considering
14:11:18God_Eatergraphs sounds like a good plan
14:11:20TorneGod_Eater: it's kinda complex because there's two semi-independant things to consider: what to encourage (or require) committers to do when pushing to master directly, and what Gerrit should do when *it* submits changes
14:11:28God_Eaterthey were effective at DevCon I thought
14:11:29TorneIdeally we want both of those to behave similarly :)
14:11:48God_Eaterabsolutely
14:11:48Tornegerrit has four ways to apply changes, all of which have upsides and downsides depending on your expectations/preferences
14:12:07Tornein terms of enforcing what committers directly push, though, there's only two choices: allow merges or don't
14:12:14Torneanything beyond that has to be enforced by convention
14:12:45kugelI thought we established to allow merges after enabling a setting
14:13:08Tornekugel: that's not really a solution to "what should we encourage people to do", though
14:13:16Tornethat still allows people to just do whatever
14:13:32Torneallowing merges (always or with some setting) leaves you with various options
14:13:44Torneand the "default" behaviour of git when you do that is, er,
14:13:50Tornenot something i'm particularly fond of
14:14:00Tornebecause it produces needlessly complicated history
14:14:19Tornebut i'v ebeen experimenting with various things and I think I'm much happier with non-fastforward merges
14:14:55Tornewhich produces, technically, *more* history, but it's in theory simpler :)
14:15:11Torneand you can choose to only look at the part of it that's linear without loss of information
14:15:24kugelyou don't like fast-forward merges?
14:15:35Tornei don't like fastforwarding to submit to trunk, no
14:15:46Torneit breaks the ability to see a linear history of changes
14:16:03Torneand, in gerrit's case, breaks the ability to mark commits with who reviewed/approved them
14:16:04kugelare those the ones which don't have the extraneous "merge bla" commit?
14:16:12TorneYes
14:16:43kugelcan one force a merge commit?
14:16:50Torne*You* can
14:16:52TorneI don't think the server can
14:16:57Tornegit merge −−no-ff
14:17:11Tornewell, it possibly can, i'm not sure.
14:17:33Tornethe advantage of forcing the merge commit is that if you start from HEAD and just follow the first parent of each commit..
14:17:41Torneyou see exacfly one (merge) commit for each submitted change
14:18:02Torneyou never see anyone's intermediate development states unless you go look for it
14:18:27kugelthis needs graphs or examples :)
14:18:42Tornehttp://blog.prelode.com/2011/04/history-cleanliness-in-git/ <- this explains somewhat
14:19:36Tornewell, ignore his explanation mostly
14:19:40Tornei don't agree with his opinions
14:19:44Tornebut his *diagrams* are useful :)
14:19:54Tornethe thing i object to is the history shown in the first diagram
14:20:03Tornebecause that's basically incomprehensible
14:20:14Torneto someone who just cares about what's been committed.
14:20:29Tornethe thing i am proposing here is the diagram for option 2, only merges on master
14:21:09Tornea number of projects work that way, including git itself
14:21:48 Nick soap is now known as soap_ (~soap@rockbox/staff/soap)
14:23:14Tornefor developers the only thing you have to do is "always merge from master using merge −−no-ff"
14:23:28Torneer, to/from master
14:23:35kugelonly merge to master sounds ok. what does it prevent? That I merge from someone who merged from a third?
14:23:36Torneer, just to :)
14:23:54TorneNo, you cna still do that kind of thing
14:23:58TorneIt doesn't *prevent* anything
14:24:11TorneYou can do exactly the same sequence of calls to "git merge" either way
14:24:21Torneit just happens that by default some of those calls may not generate a new commit
14:24:25*ukleinek thinks git.git doesn't have a "only merge on master" policy
14:24:46Tornepretty sure it does
14:25:09TorneOh, hm
14:25:11Tornemaybe not :/
14:25:12ukleinekTorne: maybe it looks like it in practice
14:25:34Tornesomeone elsewhere claimed it did, sorry
14:25:38TorneAnyway, yeah
14:25:48TorneThe basic point is... most of the time you will generate a merge commit
14:25:57kugelI don't think merges are going to be a problem either way unless we switch to the torvalds workflow
14:25:59Torneregardless.
14:26:08kugelmost of the time we'll push like svn commit
14:26:13Tornebecause *most* of the time you won't be up to date when you come to submit
14:26:25Tornekugel: this isn't about doing/not doing merges
14:26:42Tornein any case where you would've had to have *done* a merge, in the sense of actually checking it did the right thing, it's always going to be a merge anyway
14:26:48ukleinekif you don't like merges, there is always git log −−no-merges :-)
14:27:01Tornekugel: this is about what happens when you *don't* have to merge
14:27:07Tornebecause your development branch happens to be up to date
14:27:30kugelthen we can push straight away no?
14:27:43Tornekugel: That's what I'm trying to *prevent*
14:27:48Tornebecause tha makes an incomprehensible hisotry
14:27:56 Join LinusN [0] (~linus@giant.haxx.se)
14:28:10ukleinekgit works like so: http://repo.or.cz/w/alt-git.git/blob/HEAD:/Documentation/howto/maintain-git.txt
14:28:13Tornekugel: if you do that you end up with graphs that look like the first one shown
14:29:01ukleinekTorne: what is your problem with the first graph?
14:29:17kugelit looks better to me than the big second one
14:29:29kugelbut I see the difference is that master only contains merge commits
14:30:01Torneukleinek: the problem is that there is no line you can follow which has all the changes in order
14:30:34kugelwho's interested in the actual lines? :)
14:30:43Lalufuwell, if you're doing parallel development in multiple trees the concept of "changes in order" becomes somewhat moot.
14:30:59Tornekugel: anyone who ever has to work out whether a given change is in a given user-reported version or not
14:31:34TorneLalufu: no it doesn;'t
14:31:40Lalufugit branch −−contains
14:31:51TorneLalufu: that only answers the question in one direction
14:31:57Tornethat's really not useful
14:32:11TorneLalufu: Submitted changes are still in a perfectly linear sequence
14:32:25TorneEvery time someone moves master, that's one or more new submitted changes
14:32:32TorneThe buildbots build new builds based on that
14:32:38TorneEverything is perfectly linear and oredered
14:32:51TorneThe actual *commits* that make up those logical changes to the code are more complicated
14:33:28Tornebut from the point of view of "people watching master", which includes the bots and everyone who uses the builds produced by the bots, there is a perfectly obvious chronological order there
14:33:46ukleinekTorne: test -z $(git rev-list −−max-count=1 $userreportedversion..$givenchange)
14:34:02TorneThe problem with that first graph is that the obvious chronological order of what is in what build is *not visible* in the log
14:34:12TorneYou can't see the real order
14:34:39TorneThe chronological order of the *commits* is first, second, third, fourth, fifth, etc
14:34:51Tornebut the order of those changes entering the build is as shown in the other graphs, which is totally different
14:34:53ukleinekTorne: git log −−first-parent works if you have a single integrator (as Linus T. is for Linux)
14:35:11Torneukleinek: Yes, indeed
14:35:13TorneWe don't
14:35:15TorneSo, it won't
14:35:40TorneUsing git merge −−no-ff makes git log −−first-parent work *anyway*
14:35:42TorneThat's the entire point
14:35:55TorneThe log shown in "only merges on master" which is the short one is, exactly, git log −−first-parent
14:36:03ukleinekTorne: but only if you merge in the new changes and not upstream
14:36:28ukleinekthe latter seems to be the more obvious thing to do with rockbox' development model.
14:36:33Torneer, what?
14:36:35Torneno it doesn't
14:36:41 Join Zagor [242] (~bjst@rockbox/developer/Zagor)
14:37:00ukleinekI want to push, oh, master moved, git pull origin master, git push
14:37:37Tornealso, you are refererring to a development model that we *haven't written yet* :)
14:37:47Tornesince currently *nobody submits using git* since you can't
14:38:06Torneso what you mean is "what you would do in the absence of other instructions is not this"
14:38:10Tornewhich is besides the point
14:38:15Tornesince what i'm proposing here is that we, yaknow
14:38:23Tornewrite instructions to ensure the outcome we want
14:39:13LalufuTorne: I just replayed the first picture on http://blog.prelode.com/2011/04/history-cleanliness-in-git/
14:39:38Lalufuhttp://pastebin.com/iGm6pJzZ
14:39:52Lalufuthat's "git log" on master after the last merge.
14:39:59Lalufuwhat's the problem with that?
14:40:35TorneLalufu: THe problem is that's *not the order that they got applied to the tree in*
14:40:50Torneso it's bloody misleading
14:41:05ukleinekTorne: what is wrong?
14:41:18Torneukleinek: ok, so imagine this is our tree, and we have our buildbots as they are now
14:41:26Tornesuch that every time someone pushes to master, they kick off a new build and publish it
14:41:33Torneright?
14:42:09Tornesomeone downloads the build from 49dc336 and installs it on their player
14:42:18Tornethey use it and they find a bug
14:42:42Lalufuso you expect to see "initial, first, second, fifth, eighth, third, fourth, sixth, ninth, seventh"?
14:42:45Tornethat bug is fixed by c25ed26
14:42:58TorneNow, c25ed26 is displayed in the log *before* 49dc336
14:43:04Tornebut the bugfix is not in their build.
14:43:10TorneI struggle to see how this is good :)
14:43:15TorneLalufu: yes
14:43:23kugelhuh?
14:43:34Tornei expect to see changes in the order that they would be received by *another* user who is pulling from the central master branch frequently
14:43:36kugelhow can c2.. be displayed before 49..?
14:43:46LalufuNow I have to admin that I do not know what git actually does when I do a merge.
14:43:47kugelthey're ordered by date of commit, no?
14:43:51Tornekugel: yes
14:43:57Tornedate of commit, not date of being merged to master
14:44:08LalufuAre you sure that the commits from the branch are applied on top of the current state of master?
14:44:09Tornekugel: so if you develop something now and commit it
14:44:16Torneand then don't submit it to master for a year
14:44:21Torneit will show up in the log a year ago
14:44:27kugelyes
14:44:38kugelthat doesn't answer my quiestion
14:45:03TorneEr, by "before" i mean earlier in the log
14:45:12Tornethe log is in reverse time order so it's later in the actual output
14:45:15Torneif that's what you mean
14:45:27kugelyes
14:45:52kugelthe fix (c2..) after the buggy build (49...)
14:46:04kugelthat's alright isn't it?
14:46:07Tornekugel: No
14:46:09TorneLook at the log..
14:46:23Tornethe one Lalufu made, or the one in faux's blog post, they both show the same thing
14:46:31TorneOh
14:46:39TorneExcept lalufu made his own commits so the hashes are differnet :)
14:46:46Tornebut you can see that the order is the same as in faux's log display
14:47:02Tornesince they are named first/second/third/etc to be the order they display :)
14:47:28TorneOh, gah
14:47:36Torneand of course they're *also* different commits in the different pictures.
14:47:39TorneOkay, sorry
14:47:45Tornethe way i have explained this is inadvertently really unhelpful :)
14:48:33Lalufuin my example "first, second"... is the order I created the commits in
14:48:39TorneLalufu: yes, the same for his
14:48:45LalufuOK.
14:49:01Torneso the actual order they are available in builds is first, second, fifth, eigth, third, fourth, sixth, ninth, seventh.
14:49:15Tornethough builds would not exist for all of those as some are merged simultaneously
14:50:03*ukleinek reads backlog
14:50:20Torneyou would have builds containing (first), (second), (fifth), (eighth), (third, fourth, sixth), (ninth), (seventh)
14:50:23ukleinekTorne: I'm sure that out of order log can happen in the first image too
14:50:33Torne..huh?
14:50:38TorneThe first image *is* the one with the out of order log
14:51:01ukleinekif seventh was commited before sixth
14:51:25TorneThe entire point I am making is that the log is out of order here
14:51:30TorneThe first image there is showing that it's out of order
14:51:34Torneas does Lalufu's log
14:51:36Tornewhich is the same thing
14:51:50Tornejust without being −−oneline and whatever option makes it draw the nice branch asciiart
14:52:21Tornei froget :)
14:53:41ukleinekah, let me check the 'only merges on master image'
14:53:44 Join webguest85 [0] (~3b9c9e87@www.haxx.se)
14:53:45ukleinekgit log −−graph btw
14:54:04kugelTorne: I still don't understand how your scenario is possible
14:54:11ukleinekTorne: still applies there
14:54:16Torneukleinek: no it doesn't
14:54:23ukleinekTorne: if seventh was commited before sixth
14:54:37Tornethat makes no difference
14:54:44Torneyou get the exact same thing when you look at the first parents
14:54:58Tornekugel: it's not just possible, it's basically guaranteed :)
14:55:05ukleinekTorne: ??
14:55:47Torneukleinek: if your master branch contains only merges-to-master and you look at the log of the first parents of those merges then you never *see* the timestamps of the actual commits
14:55:56Tornetherefore changing the timestamps of the actual commits cannot possibly change the order displayed
14:57:02Tornekugel: the scenario is right there on that page, i can't see how you can fail to see it's possible
14:58:48kugelI ooked at the pastie when you explained it
14:59:21Tornelalufu's log?
14:59:35kugelyes
14:59:45kugelI don't see these commits on the page eitehr
14:59:47Torneassuming he did it right and it matches what's in the blog post then yes, that's out of order
15:00
15:00:04Torneit's in chronological order of commit, which is bascially guaranteed to be wrong in a DVCS
15:00:12Tornewell, wrong is a loaded term
15:00:21kugelit's not how changes went into master
15:00:24TorneIs basically guaranteed not to be the order in which those changes appeared to someone else watching the master branch
15:00:27TorneYeah.
15:00:39kugelbut it still shoudnt show a fix before a buggy state
15:00:51Tornethen you misunderstand how git works entirely
15:00:55Tornebecause it trivially can do that
15:01:03kugelTorne: can you please tell me what commits you mean?
15:01:37TorneOK, so using the commit messages instead because yes, sorry, the commit hashes i referred to earlier were from one of the images and thus not useful
15:01:41kugelI don't see c2.. or 49.. in either log
15:01:51TorneRight, the commits i'm referring to are from the merges-on-master image
15:01:55ukleinekTorne: but with −−first-parent you don't see the commits at all, only the merges
15:01:58Tornebecause that's place it's easiest to pull examples for
15:02:04Torneukleinek: Yes. That's the point.
15:02:15Tornekugel: so let's assume the bug existed from the start
15:02:21Tornekugel: the bug gets fixed by "third on devel"
15:02:37Tornea user downloads a build which is compiled from "eighth on maser"
15:02:46TorneThis build does not include the fix.
15:03:28*kugel doesn't see "third on devel"
15:03:35ukleinekkugel: thrid
15:03:39ukleinekthird
15:03:44Tornekugel: what are you looking at exactly then?
15:03:46Tornebecause i see it
15:03:47Lalufukugel: line 55 in my paste
15:03:47 Quit webguest85 (Quit: CGI:IRC (EOF))
15:03:51kugelhttp://blog.prelode.com/2011/04/history-cleanliness-in-git/
15:03:54Tornekugel: ARGH
15:04:01Torneyuou just said you were looking at Lalufu's pastebin
15:04:05Torneso i explained it by reference to that
15:04:16kugelI switched to the images when you said your commits are there
15:04:22Tornehe has not copied the names of the commimts exactly
15:04:29TorneThe number is the only part that matters
15:04:36Torne1/2/3/45/6/7/8/9. right?
15:04:37 Quit antil33t (Remote host closed the connection)
15:04:51Tornebecause that way i can stop misspelling eighth
15:04:53Torne:)
15:04:58kugelok, back to Lalufu's log
15:05:00kugel.
15:05:03 Join antil33t [0] (~antil33t@203-100-223-143.callplus.net.nz)
15:05:04TorneLook at either, doesn't matter.
15:05:21kugelit does matter to understand what you're saying, apparently :)
15:05:21TorneBug exists from start. Commit 3 fixes it. Build based on commit 8 does not include fix.
15:05:29ukleinek8 includes 3
15:05:30TorneIt doesn't if I just say the numbers.
15:05:32TorneNo it doesn't
15:05:49ukleinekit comes into master when 5 is merged
15:06:00kugelif it doesnt include the fix it doesn't show it in the log
15:06:01TorneNo it doesn't
15:06:07LalufuI see what he means.
15:06:18Tornekugel: it does show it in the log *if you look at the log at a point after the point where the fix *was* merged*
15:06:21Lalufuif we are at 8, before the merge, and do a build, the fix is not in it.
15:06:30Torneif you look at the log for HEAD, after all these commmits are madde
15:06:31Lalufuafter the merge it _looks_ as if the fix was in before 8
15:06:39TorneYes! Exactly :)
15:06:46kugelokay
15:06:50kugelI understand now
15:06:50ukleinekTorne: 8 includes 3
15:06:54Torneukleinek: You are still wrong
15:07:11Torneukleinek: The fact that you are able to get this wrong is a point in my favour: if the log wasn't so confusing you won't make this mistake
15:07:17Torne:)
15:07:43TorneThe log for 8 will look like: 8, 5, 2, 1, initial
15:07:47Tornebecause that's all that's included in it
15:07:52ukleinekTorne: I look at the blog, 8's parent is merge5, merge5's 2nd parent is 5, 5's parent is 4, 4's parent is 3
15:08:00Torne5 is NOT A MERGE
15:08:07Torne5 is a plain commit to the master branch
15:08:16LalufuTorne: but if you do a "git log af2789595a3c6516d2a55677e3a3aff49baaa8f5" (which is the commit of 8) you see that 3 is not in
15:08:32TorneLalufu: sure, i'm not saying it's impossible to figure out the answer, there are lots of ways to work it out
15:08:33Lalufuyou have to look at the log of the build, not some log after that
15:08:37TorneI am complaining about the fact that you have to actually think about it
15:08:44Tornerather than it being entirely obvious and linear as they are now with svn
15:09:03LalufuThat was kind of the point of my remark earlier.
15:09:03ukleinekTorne: yeah, git log −−first-parent 8 doesn't show 3, but the change that 3 did is included in 8
15:09:20Torneukleinek: No it isn't
15:09:20Lalufuboth forms have their merit, I do not see one as being more "right" than the other
15:09:25Torneukleinek: Seriously, you are *still* wrong
15:09:35Torneukleinek: Everyone else agrees :)
15:09:36Lalufuukleinek: really, it is not.
15:09:49Lalufuthe branch that contains 3 is merged _after_ 8
15:09:53Torneand again, the fact that you are still wrong here means that I am right and this *is* confusing :)
15:10:04Lalufuso a build from master directly after 8 is committed does not contain 3
15:10:51TorneLalufu: no, i don't think they both have their merits
15:11:15TorneFrom the point of view of someone trying to *read history* and work out what has happened (ignoring the actual developer effort) the ideal situation is a flat history
15:11:35Lalufuand what do you want that history to show?
15:11:39Tornebecause that's subject to no ambiguity or misinterpretation
15:11:42Lalufuthe state of the tree at every commit?
15:11:46TorneBut, an actual flat history is a huge pain for *developers*
15:11:49Lalufuor the order in which the commits were applied?
15:11:54Tornebecause it requires that you rebase all changes before committing, and forbid merging
15:11:55ukleinekthe fact that you all get it wrong proves the confusion even more :-)
15:12:05LalufuI'm not sure that's the same thing for GIT.
15:12:35ukleinekLalufu: 3 comes in in 3bf6e08
15:12:37TorneSo, I'm proposing something that lets you have the illusion of a flat history when you want to look at it in those terms, but does not require developers to rewrite their history while developing
15:12:44ukleinek(in the blog image)
15:12:52TorneThe process of submitting is *different* in this system
15:12:56Tornebut it's not any extra work
15:13:24Torneunlike rebasing which can be a nightmare :)
15:13:24ukleinek3bf6e08 merges in 5 which contains 3
15:14:20Torneukleinek: haha
15:14:34TorneOkay, ukleinek is confused because faux's images don't acctually reflect the same history :)
15:14:38TorneI hadn't checked
15:15:12Torneukleinek: we are referring to the original, ugly sequence of commits in his first image, which is the same as what Lalufu's pastebin contains
15:15:28TorneUnfortunately yes, when recreating that history using different merging strategies he has gotten it wrong
15:15:34Torneand hasn't actually shown the same thing :(
15:15:39TorneI have never looked that closely before :)
15:16:08LalufuTorne: so you want "git log −−topo-order"?
15:16:24TorneLalufu: That's closer, but still not ideal
15:16:30ukleinekTorne: maybe it's just the first parent isn't always left?! /me checks
15:16:46Torneukleinek: the first parent is not always the same *brnach*, in general
15:16:48Torneis why.
15:17:01Tornethe first parent is only always the same branch if you enforce that you only merge to master :)
15:17:20*ukleinek rereads backlog while looking at the first blog image
15:17:22Tornewithout imposing restrictions on how people work there is no consistency between orders of parents
15:17:27Torneso −−first-parent is meaningless
15:18:17 Quit wodz (Quit: Leaving)
15:18:43TorneLalufu: −−topo-order is in the right order, but still filled with lots of noise
15:18:50Lalufulike the merge-commits?
15:18:55ukleinekyeah, so we can agree that 8 doesn't include 3 though it might have a later commit date
15:19:03TorneLalufu: it includes uninteresting intermediate states of development
15:19:12TorneLalufu: well, this example is too simple to show the noise.
15:19:19Tornein this example there is not any
15:19:25 Quit TBCOOL (Quit: maintenance.)
15:19:30TorneAll the merges in this example *are* significant, not noise
15:19:37Tornebeause in this example they all represent places where master changed
15:19:40Torneand thus you can't ignore them
15:19:49Lalufuin this case the merge commits are emtpy
15:19:52ukleinekTorne: that works as long as users pick only commits from the branch everything is merged in
15:19:53Torneyes
15:20:02TorneHowever, in real development, every merge you do *from* master *to* your development branch is noise
15:20:12Lalufuwhy?
15:20:13TorneYou need to do that, in order to catch yourself up
15:20:19TorneBut nobody else needs to read it, in almost all cases
15:20:25ukleinekTorne: so don't do it then
15:20:27Lalufuif you merge back, the commits will not be duplicated
15:20:35TorneLalufu: huh?
15:20:38Tornethis isn't about duplication
15:20:40Lalufuukleinek: you need to merge from the master from time to time
15:20:44Tornethis is about the merge commit itself being noise
15:21:03Torneexample:
15:21:11Torne1) i make a development branch based on master
15:21:13*ukleinek laughs at Torne who wants to sell doing many more merge commits
15:21:15Torne2) i write some commits
15:21:24Torne3) i need to catch up from master, so i merge master into my branch
15:21:30Torne4) i write some more commits
15:21:42Torne5) i am done, i merge my branch back to master (by whatever method, doesn't matter)
15:21:56ukleinekif that is all a single series, don't catch up in the middle
15:21:58TorneSomeone who now looks at the full commit log has *no reason to care* about the merge commit i made in 3
15:22:05ukleinekif it's not, dont base 4 on top of 2
15:22:08Torneit is useless noise.
15:22:22Torneukleinek: you don't appear to understand how long lived feature branches work
15:22:38Torneukleinek: I agree that generally it's nicer to avoid doing it
15:22:43Torneeither by just not updating, or by rebasing instead of merging
15:22:53***Saving seen data "./dancer.seen"
15:22:56TorneBut if you have a development branch that is goingt o live a long time, and is going to conflict somewhat with changes on master
15:22:59Torneyou have no choice.
15:23:06TorneNever catching up on something that's long lived is hopeless
15:23:18Torneand trying to rebase a complicated change against a moving target is very very awkward
15:23:41Tornesince your earlier commits may no longer apply against the current master
15:24:47ukleinekTorne: just adapt at the end
15:24:49Torneukleinek: the point of doing merge-to-master with nonfastforward is that when looking at history you can use −−first-parent almost all the time
15:24:53LalufuAnd git is very helpful in managing these things.
15:24:59Tornewhich takes away *all* this intermediate state
15:25:04Torneand just hides it
15:25:08Torneukleinek: Er
15:25:18Torneukleinek: you mean flatten your entire development and apply as a single patch? :)
15:25:22Torneor what
15:25:41ukleinekno, do conflict resolution at merge time (well I admit that can be hard)
15:25:51Torneer
15:25:57Torneyou don't appear to be talking about the same thing
15:26:00ukleinekbut yeah, git merge −−squash is possible, too
15:26:13Torneyou mean never catch up and just wait until the end, right?
15:26:24Tornethat's useless if you *care about changes that are happening in master while you work on it *
15:26:45Tornecherrypicking changes from master is even worse :)
15:26:53ukleinekyeah
15:27:32Torneukleinek: okay, so you have radically departing opinions on how to do this from just about everyone else :)
15:27:41Tornewhich is, yaknow, interesting and all
15:27:53ukleinekTorne: agreed
15:28:10Tornebut it doesn't really help me reach a compromise that preserves the properties ia m interested in while not being a huge inconvenience for peopel who expect to be able to use git with normal branching and merging
15:28:19TorneI personally quite like flattening changes and rebasing in almost all cases
15:28:26TorneI do this most of the time for the git repos I work with :)
15:28:41Tornebut it was very clear last time we discussed workflows that most people are not willing to do that
15:28:46Torneat least, not all the time
15:30:18ukleinekTorne: I think that if you want a pretty history (in the sense that your patches are small and self-contained, not about having or not having ugly merges) you have to rebase your private devel tree.
15:30:36*B4gder agrees with ukleinek
15:31:31TorneB4gder: this was my initial propsal :)
15:31:39Tornehence why the sandbox repo currently refuses pushing merges.
15:32:02Tornebut virtually every existing git user here disagrees
15:32:11B4gderwell, as I'm not that involved in the development these days I won't make things more complicated by voicing strong opinions on either approach
15:32:45 Quit XavierGr ()
15:32:49Torneukleinek: Do you really not see that following the only-merges-on-master policy achieves the same ends as rebasing, though?
15:33:40TorneIf you forbid merges entirely and require that everyone rebase and squash before committing, you get a history which is a linear sequence where each one is a single logical *change*, regardless of how it was originally developed
15:34:06TorneIf you require that *all* commits to master are merges to master, you get, if you use −−first-parent, a history which is a linear sequence where each one is a single logical *change*, regardless of how it was originally developed :)
15:34:13TorneBut the original history is still there if someone looks
15:34:15ukleinekTorne: I don't see the benefit at forcing that, imho Linux is just fine
15:34:57Torneforcing which?
15:35:03ukleinekbut of course you need patch hygiene
15:35:14ukleinekTorne: that merge-to-main-branch thing
15:35:22Tornebut aren't you arguing for the former?
15:35:29Tornewhich, as i'm trying to point out, achieves the same effect
15:35:57ukleinekTorne: I'm happy with the first image on http://blog.prelode.com/2011/04/history-cleanliness-in-git/
15:36:03Torneukleinek: er
15:36:14Tornethen why are you now talking abotu rebasing and so on?
15:36:33TorneThat situation woudl never arise if people rebased and did clean patches
15:36:37ukleinekTorne: and consider "2. Only merges on master" as artifical without real gain
15:36:47Torneyou're not making any sense
15:37:06Torneyou are arguing for things that produce one result, while saying another result is fine :)
15:37:21ukleinekTorne: because the "merge as needed" workflow only works nicely if your commits are at least halfway sane
15:37:38*pamaury naively suggests that it's not too late to chose another tool than git :)
15:37:40ukleinekso during developent of a series you might have to rebase
15:38:19ukleinek... or accept a intermediate merge in the history
15:39:18Torneukleinek: okay, that's clearer
15:39:34ukleinekif you have commits like "convert first arch", "convert 2nd arch", "oh, I broke arch3 when converting arch1, fixit" you don't want the "merge as needed" workflow
15:39:38Tornewhat you're saying if i understand correctly is that you expect people will mostly just rebase and keep stuff tidy
15:39:50Torneand they'll only put up with doing merges in awkward situations that aren't going to work otherwise
15:39:55ukleinekbut actually you don't want these patches in the "always merge" workflow either
15:39:57Torneand thus history will be pretty much ok as is
15:39:58Torneright?
15:40:39Torneor am i still misinterpreting?
15:40:49ukleinekyeah, maybe replace "expect" by "require"
15:41:19TorneOK, sure, require int he sense that we complain at people if they don't
15:41:21ukleinekin fact, only merge clean stuff. If people did it with or without rebasing doesn't matter much
15:41:25Torne(since you can't *enforce* it)
15:41:55TorneOK, so the problem witht aht in my mind is that I don't think people *will* work like that willingly
15:42:28Tornewhen people started trying the sandbox and found they couldn't push merges they were very concerned that their workflow normally includs doing merges just whenever.
15:43:08ukleinekTorne: you can enforce it with the linux-workflow. That is, with a person having the integrator role who is only merging the good stuff
15:43:11TorneEven if we write such guidelines I don't think people will adhere to them
15:43:27TorneYou can, yes
15:43:30God_Eaterhahahaha
15:43:32TorneBut *we* can't
15:43:36TorneWe have no such person
15:43:39God_Eaterno-one is stupid enough to volunteer for that role here
15:43:42 Quit pamaury (Quit: Page closed)
15:43:44TorneNobody would want tod o it
15:43:48Torneand even if they did many people would object
15:44:02 Join dfkt|n [0] (~dfkt@unaffiliated/dfkt)
15:44:02TorneNow, see
15:44:09 Join pamaury [0] (81680b01@rockbox/developer/pamaury)
15:44:10TorneOne thing is that "gerrit" can, in theory, be this person :)
15:44:24God_Eatergerrit == Mr. Someone ;)
15:44:30ukleinekoh, but then you have to expect more social problems when switching to git
15:44:39TorneEntirely aside from the actual code review, the thing about gerrit is that when you submit by hitting the button in gerrit, *it* does the submit
15:44:44Torneand thus it is being a single integrator
15:44:50TorneANd gerrit can do that in a variety of ways
15:45:10Tornedepending how it's configured.
15:45:18ukleinekAFAICT git exposes much better what was done than svn and if you don't agree that A is the integrator you might want to critisize his commits, too
15:45:49God_Eatercommits get criticised quite a lot here already :)
15:45:59Tornebut, for that to actually be policy requires that people always go through gerrit and forbidding direct pushes
15:46:05Tornewhich currently doesn't seem to be approved-of
15:46:24ukleinekTorne: then only give the good commiters commit access :-)
15:46:43Torneukleinek: ther eare two kinds of "good committers" here in your idea, though
15:46:46God_Eaterthat's what we do already
15:46:48Tornethere are "people who write good code"
15:47:01Torneand there are "people who take care to ensure their git commit history is tidy and doesn't include lots of noise"
15:47:08TorneThese are not necessarily all the same people :)
15:47:29Tornecurrently we only select based on the "good code" criteria :)
15:48:22Torneunless you do not care at all what history looks like, there is a difference between "I approve of the diff between master and some-guys-branch" and "i approve of merging some-guys-branch into master"
15:48:28God_Eaterit may be that those two groups don't intersect at all
15:48:33Tornethe former only requires that the code be sound
15:48:48Tornethe latter also requires that people ahve fgollowed some kind of DVCS best-practise :)
15:49:35Tornewe have never had to care about the latter before because there basically is no way to screw this up in svn
15:49:43Tornesince you *have* to "rebase" before committing
15:50:32ukleinekTorne: the problem about not-so-nice-commits is that they break bisection
15:50:37TorneYes, absolutely
15:50:54TorneBut, I should note, having a policy of always merging to master solves that problem
15:50:59ukleinekTorne: and if your users can be educated to try bisection this is a big pro
15:51:02Tornesince in that case there is a nice linear sequence for bisect to go through
15:51:22Torne:)
15:51:45ukleinekTorne: git bisect doesn't work with your always-merge history
15:51:54Torneyes it does
15:54:07n1sukleinek: nothing prevents users from nisecting with svn but hardly any of them do
15:54:28Torneukleinek: git rev-list −−bisect −−first-parent works perfectly in the always-merge history
15:55:37 Part LinusN
15:56:03Torneukleinek: anyway, this is not going anywhere
15:56:11Torneukleinek: i really do like what you suggest, if that wasn't clear
15:56:22TorneI am strongly in favour of encouraging people to rebase and avoid merging where possible
15:56:40Tornesince most of the time there is no particular reason to complicate stuff with merges and it's equally trivial to rebase
15:57:14Torneand that was one suggestion I had last time: forbidding merge commits to be uplaoded by default, but allowing people in a certain ACL group to do it
15:57:24Tornewhich might well be a group you can add yourself to, i.e. making it opt-in
15:57:36ukleinekTorne: I'm ok with stopping the discussion. (One reason is I have to leave now)
15:57:37Torneas long as you promise to try and Do The Right THing according to some guidelines
15:57:49Tornebut, I am concerned that this is not going to get a lot of buy-in
15:57:58Torneand that people would actually just keep doing what they are used to
15:58:16kugelwhich is reasonable :)
15:58:27Torneso, i was suggesting this as an alternative that lets people work in a varity of ways but as long as they *submit* in a certain way, it still produces an intelligible result
15:58:50Torneer, by "this" i mean merging-to-master
15:58:51 Quit webguest99 (Quit: CGI:IRC (EOF))
15:58:53kugelI think we're too concerned with how the history looks like
15:59:09Tornekugel: i think you are not concerned enough with how the history looks like
15:59:10Torne:)
15:59:19kugel:)
15:59:25Torneespecially for a project migrating from svn where many people are *not* familiar with git
15:59:51Torneit's already going to be tricky enough for many casual folks (e.g. users who compile their own builds) that the versionsa re not just numbers in sequence :p
16:00
16:01:30Tornekugel: at the end of the day i can live with whatever. if we hav the opt-in merge group thing, with just some simple guidelines like "have you considered rebasing, it might be nicer", that would be fine; i'm just exploring options before we actually start doing it :)
16:03:44Tornei do kinda want that basic level of protection, or some other process which avoids the problem in the first place, though, because people who are new to git are likely to make stuff kinda yucky otherwise
16:03:59Torneespecially as the vast majority of git docs/tutorials barely mention, or actively advise against, rebasing your changes
16:04:30 Join TBCOOL [0] (~tb@c-c63471d5.09-42-73746f22.cust.bredbandsbolaget.se)
16:05:00LalufuTorne: would you want to discourage just merging from master, or also merging bewteen development branches?
16:05:26LalufuFor the work I do on IAP I use rather a handful of branches, and I merge quite freely between them
16:05:45Tornesure
16:05:50Tornethat's not the part that matters
16:05:54Tornewhat matters is what you commit to master
16:06:02Tornenot what you do in the process of getting there.
16:06:14Torneyour development branches are all just private on your local machine, right?
16:06:30Torneor, generally, not public to the world in a way that encourages other people to pull them
16:07:21LalufuI publish one of them, but that one is explicitly produced for publishing (by cherry-picking from other branches)
16:07:29Torneright
16:07:56TorneSo, currently, because we use svn, to submit you would periodically produce one or more patches and commit them
16:08:16Torneyou might just have one patch which is "implement this new stuff", or a series which you commit in order that make up logical steps
16:08:23Tornebut you would not commit your own private intermediate development states
16:08:43TorneMy preference is that you'd continue to work just like this with git
16:09:00Lalufuso you want one big patch, instead of lots of small ones?
16:09:07TorneLot sof small ones is fine too
16:09:15Torneas long as they reflect actual interestnig seperate steps in the development of a feature
16:09:22Tornelike patch serieses sent to LKML
16:09:30Tornewhere things are broken up to make them easier to review and understand
16:09:47TorneWhat I would prefer *not* to see is commits like "oops, changed my mind, removing this function again"
16:09:50Torneor similar :)
16:10:10TorneWhether you even commit that kind of thing to your development branch int he first place or not varies, of course; maybe you already take care to make your development branches hygenic
16:10:16Tornein which case it's very easy to submit them
16:10:36Tornedoes that make sense?
16:10:44LalufuDepends. If it takes two weeks to realize that I don't need the function after all it's hard to remove that entirely from the history
16:10:52TorneWell, you say that
16:11:03TorneBut if that's just one big thing you are working on anyway
16:11:08Tornethen maybe you are going to flatten it anyway
16:11:15Torneat which point the intermediate state with the function existing goes away
16:11:33Lalufuright.
16:11:42TorneFlattening is always possible and always gets rid of all intermediate states, but sometimes *not* flattening is desirable for some reason
16:11:53Tornee.g. when a patch is large and complicated and woudl be hard to review or understand in one blob
16:12:09Tornebut in that case you generally want to produce a patch series which reflects the *logical steps* in implementing the change
16:12:15Tornerather than the actual chronological steps you went through developing it.
16:12:42 Join GermanMushroom [0] (~c@s5146db6a.adsl.wanadoo.nl)
16:12:47TorneSo yeah. In workflows like Linus's this is basically enforced because there is no other way to get your code into the tree
16:12:53TorneYou make a patch (series) and you email it
16:12:58Torneand someone merges it if they like it
16:13:07TorneIf you make a big ugly mess they will tell you to go away
16:13:36TorneWhen everyone has permissiont o push to master, you can only really enforce this by peer pressure
16:14:05Torneand when people make mistakes it's generally too late to change you rmind since the branch is already published and built
16:14:10Torneand so revising history would be bad.
16:14:20TorneYou can explain to them what they did wrong and ask them not to do it again, but.. yeah :)
16:14:44*Torne idles, tree is red :)
16:15:17LalufuI think I'd continue to publish the cherry-picked branch, just so that people can see the history of the thing.
16:15:43Lalufuwhether that is pulled as-is into master, or as a series of further condensed patches or not at all is a different matter
16:15:43 Quit B4gder (Quit: Konversation terminated!)
16:23:29LalufuMy problem with the rebase approach is that it kills my current workflow
16:23:58LalufuOr maybe not.
16:24:04LalufuCurrently I do this:
16:24:19kugellet's not force rebase. it's can be a pida
16:24:21kugelpoita
16:24:24kugelpita!
16:24:28Lalufu- Clone the rockbox git tree
16:24:34Lalufu- Create a branch
16:25:06Lalufu- Work on that branch
16:25:25Lalufu(let's call the first branch A)
16:25:42Lalufu- create a second branch B from the same start point
16:25:51Lalufu- cherry-pick from A into B
16:25:54Lalufu- publish B
16:26:50Lalufuif I now rebase A I can throw away B, right?
16:28:19kugelyea
16:29:15Lalufuespecially if there are merge conflicts
16:30:54TorneOkay, back :)
16:31:03TorneOK, so I hav a problem with your workflow in the first place, I think
16:31:18TorneI don't think it *is* a different matter of whether your published changes are pulled as-is or not
16:31:28TorneEitehr the intermediate development state is useful or it isn't
16:31:33TorneIf it's useful it should be merged into master
16:31:40TorneIf it's not then you have no need to keep publishing it
16:32:45TorneI don't quite follow your example above with cherrypicking; it would help if you explained *why* you were doing those things, not just what you did
16:32:46LalufuThe things I put in the published tree are the things that I think are needed for the development of the feature at that point in time.
16:32:57Lalufumaybe, later, some of the changes will turn out to be wrong
16:33:06Lalufubut I cannot unpublish them then.
16:33:10TorneYes you can
16:33:14TorneYou can just throw them away. It's trivial.
16:33:33Lalufurewriting history in a published tree?
16:33:37TorneNo
16:33:41TorneYou misundersatnd
16:33:46TorneThrow away, not rewrite
16:33:56TorneYou developm the change, publishing as you go along if you want
16:34:00TorneYou finish it up and it's ready to submit
16:34:09TorneYou make that into a set of nice patches and submit them to master
16:34:15TorneYou then just throw the development branch away entirely
16:34:22Torneyou don't rewrite it
16:34:27Lalufuyes, that was the difference between "pulling from the tree" and "make larger patches"
16:34:31TorneIt's merged, so there's no need for it to exist any more
16:34:32*kugel thinks Torne lives in a world where you think your development state is useful, but you see mistakes in later time
16:34:50Tornekugel: i don't understand what you mean
16:35:17kugelyou say "if it's useful merge to master, if not don't even publish"
16:35:46Torneyes.. i generally don't think my develoipment state is useful
16:36:02TorneI work with patchsets, not branches
16:36:11Tornei write a change, flattened as a single commit,a nd publish it as a patch
16:36:23Tornewhen I revise that, i amend the commit and upload it as a new patch to replace the old one
16:36:34Torneif it's a complex change it might be a patch series, instead of one patch
16:36:48kugelbut there's a third where you think it's useful but notice you made mistakes in earlier commits
16:37:07Tornei don't see what you mean
16:37:31 Join ChickeNES [0] (~ChickeNES@rouxbicon.rh.uchicago.edu)
16:38:06Tornekugel: i wasn't really meaning to imply two choices there
16:38:15Tornei was trying to make the point that if it's useful, it's not really development state
16:38:27Torneif it's useful, commit it :)
16:39:04kugelsometimes changes are only useful in context of other, future changes
16:39:46Tornesure.
16:39:48Tornewhy is that a problem?
16:40:29kugelyou don't push it immediately
16:40:36Tornenobody said you had to
16:40:48Tornewhen i say "commit" i mean "keep around as a commit you are going to push"
16:40:51Tornenot "push it right now"
16:42:39kugelwell, what I was originally suggesting is that you can publis in a development state, and notice in a later state that earler commits are flawed
16:42:55kugelpublish because you want to provide an early prototype or something
16:42:58TorneRight
16:43:02TorneBut that's irrelevant
16:43:08Tornesee what i just suggested to lalufu
16:43:14TorneYou can publish it all you like
16:43:17Tornepeople can play with it, etc
16:43:32Tornebut you are not bound to committing what you published to master
16:43:43Torneyou can commit it in a nicer form.
16:44:05Tornethen simply abandon that development branch
16:44:13Torneit's committed, it's done with.
16:45:07Tornebrb, chrome is broken :)
16:46:15kugelyes of course
16:51:27-->"ods 200" received from cgthayer (~chatzilla@184.235.1.118)
16:54:06 Join antil33t| [0] (~antil33t@203-100-223-143.callplus.net.nz)
16:54:40 Quit pamaury (Quit: Page closed)
16:55:01 Quit antil33t (Ping timeout: 260 seconds)
16:58:26 Join kadoban [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net)
16:58:58 Quit blind (Ping timeout: 252 seconds)
17:00
17:00:01ukleinekLalufu: I have a script for that workflow
17:00:45 Part Zagor
17:00:55ukleinekLalufu: that is maintain a always-forward-branch master and a branch master-flat with a tidied history that has master^{tree} == master-flat^{tree}
17:01:39ukleinekmaster-flat is regularily rebased to get rid of merges and a nice history for upstreaming
17:01:51LalufuI'd be interested in a look at that
17:02:31ukleinekLalufu: It has some rough edges but works for me (TM)
17:03:13ukleinekLalufu: I will check with my employer if I can give it out, as I wrote it during my day-job. (Usually he agrees)
17:03:33LalufuOK, thanks
17:08:24Torneyah. there are lots of ways to achieve this kind of thing, with or without scripts, depending on the exact effect you want to have and how lazy you are :)
17:08:38Tornei am just not sure that people are universally willing to do this *at all*
17:09:06Tornesince it has seemed in some discussions like people are looking forward to the git transition as meaning they no longer have to do that kind of thing for the benefit of svn :)
17:12:26ukleinekTorne: you can sell them to do $(git merge −−squash $topicbranch) (while being on master). The upside is no ugly history + the same effect as $(svn up; svn commit), only with the better merge support of git
17:12:41Torneukleinek: You *can*, but there are people who actively *do not want to do that*
17:12:51TorneThey are looking forward to the fact that they *don't* have to do that any more
17:13:06Tornesince right now they basically do, becaus eof svn
17:14:25ukleinekTorne: but the commiter has to specify the endresult of master + $theirwork anyhow (using merge) and resolve eventual conflicts. The difference is only the result and that you have to do merge −−squash instead of merge
17:14:42Torneukleinek: you appear not to be understanding what i say
17:14:53Torneit's not the *effort* of squashing/resolving conflicts/etc that peopl eobject to
17:14:59Tornethey *want history to end up containing all that stuff*
17:15:53ukleinekah, ok. IMHO that's only acceptable for sane intermediate steps
17:16:12ukleinekbut MHO doesn't count much I guess
17:17:46 Quit ChickeNES (Quit: Computer has gone to sleep.)
17:22:56***Saving seen data "./dancer.seen"
17:24:07 Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93)
17:26:20 Join mamarley [0] (~quassel@Lee-08-199.rh.ncsu.edu)
17:32:32Torneukleinek: Yeah, I dunno :)
17:32:53Torneukleinek: anyway, that is why i am considering things like the always-merge-to-master trick, to try and please a larger set of people
17:33:08TorneI would proabbly prefer encouraging people to put slightly more work in to tidy their stuff up, though :)
17:33:48 Quit dfkt|n (Ping timeout: 240 seconds)
17:41:02 Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel)
17:50:36 Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel)
17:51:02 Join y4n [0] (y4n@unaffiliated/y4ndexx)
17:51:35 Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel)
17:54:02 Quit matze` (Remote host closed the connection)
17:58:41 Join Topy44 [0] (~Topy44@f049034078.adsl.alicedsl.de)
18:00
18:00:07 Quit petur (Quit: *plop*)
18:04:02 Quit God_Eater (Quit: Page closed)
18:06:16 Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel)
18:06:21 Join Keripo [0] (~Keripo@SEAS418.wlan.seas.upenn.edu)
18:06:29 Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel)
18:16:01 Quit GermanMushroom (Ping timeout: 258 seconds)
18:25:25 Join pamaury [0] (~quassel@rockbox/developer/pamaury)
18:33:20 Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel)
18:33:37 Join powell14ski_ [0] (~powell14s@c-174-51-194-6.hsd1.co.comcast.net)
18:35:50 Join Jerom [0] (~jerome@2a02:8420:215:f000:f66d:4ff:fe45:790f)
18:38:09 Join ChickeNES [0] (~ChickeNES@rouxbicon.rh.uchicago.edu)
18:41:45 Quit ChickeNES (Read error: Connection reset by peer)
18:41:52 Join ChickeNES [0] (~ChickeNES@rouxbicon.rh.uchicago.edu)
18:54:02 Join Buschel [0] (~chatzilla@p54A3BA65.dip.t-dialin.net)
18:56:37 Join blind [0] (~blind@c-71-235-61-84.hsd1.ct.comcast.net)
18:57:00 Quit swilde (Remote host closed the connection)
18:57:02 Quit ChickeNES (Quit: Computer has gone to sleep.)
18:57:50 Quit Keripo (Quit: Leaving.)
18:58:58 Quit Jerom (Quit: Leaving.)
18:59:18 Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl)
18:59:18 Quit bertrik (Changing host)
18:59:18 Join bertrik [0] (~bertrik@rockbox/developer/bertrik)
19:00
19:03:47CIA-14New commit by 03buschel (r30615): Fix a 'set but not used' warning.
19:05:49CIA-14r30615 build result: All green
19:06:49 Join Zagor [242] (~bjst@rockbox/developer/Zagor)
19:08:21 Join Strife89 [0] (~Strife89@207.144.201.128)
19:09:54 Join domonoky [0] (~Domonoky@agsb-5d871971.pool.mediaWays.net)
19:10:00 Quit domonoky (Changing host)
19:10:00 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky)
19:11:17 Join GermanMushroom [0] (~c@s5146db6a.adsl.wanadoo.nl)
19:17:54 Join TheLemonMan [0] (~LemonBoy@ppp-218-41.26-151.libero.it)
19:22:17 Quit factor (Remote host closed the connection)
19:22:57***Saving seen data "./dancer.seen"
19:30:00 Join Bagder [0] (~daniel@1-1-5-26a.hud.sth.bostream.se)
19:30:01 Quit Bagder (Changing host)
19:30:01 Join Bagder [241] (~daniel@rockbox/developer/bagder)
19:37:23 Join dfkt|n [0] (~dfkt@chello062178002170.1.11.univie.teleweb.at)
19:37:23 Quit dfkt|n (Changing host)
19:37:23 Join dfkt|n [0] (~dfkt@unaffiliated/dfkt)
19:45:21 Quit Buschel (Ping timeout: 260 seconds)
19:50:59Zagorhow much would break if we replace all pixel coordinates with decipercent on raaa?
19:52:23Zagorfont sizes are problematic. and bitmaps can obviously not be scaled at whim. what else?
19:53:18kugelthemes or internally also
19:53:19kugel?
19:53:50ZagorI'm thinking internally, so the skin engine doesn't have to know/care
19:54:25kugelI don't think that works
19:54:47kugelalso why restrict to RaaA?
19:55:03Zagordetails, please. why doesn't it work?
19:55:29Zagorraaa is the main problem because it has a zillion different screen sizes. other targets are much more static.
19:55:47kugelbut two separate code bases?
19:55:48Zagorif it works for raaa, it might make sense on other targets too. I'm not ruling that out.
19:56:08 Quit madskiny (Read error: Operation timed out)
19:56:13Zagorno, that's why I want it internally. basically android has a 1000x1000 framebuffer
19:56:25Zagors/android/raaa/
19:56:25kugelI doubt you can work with only (deci)percentage
19:57:26Zagorthat's why I'm asking. enlighten me, please!
19:58:01kugelwell, for example the things you mentioned (bitmaps)
19:58:18Zagoryes but those are resources and can be supplied in density-specific versions
19:58:32Zagori.e. it's just a logistics issue
19:58:52kugel1000x1000 ignores aspect ratio (landscape vs portrait)
19:59:19Zagorour problem isn't that we have different densities, it's that we have *many* small variations in screen size
19:59:23kugelI can't explain exactly why I'm doubtful, I just feel it's not going to work
19:59:46Zagorof course it ignores it, it's percent!
20:00
20:00:04Zagora percent scaled UI could even rotate
20:01:26 Join gbl08ma [0] (~gbl08ma@195-23-182-194.net.novis.pt)
20:01:58kugelthe same layout on portrait and landscape?
20:02:35Zagorscaled to proportions
20:02:52Zagorit might not be terribly pretty though :-)
20:03:21Zagorthings like a square area album art needs special consideration
20:04:13Zagora square area *for* album art
20:04:36Zagorhow is AA scaling done today?
20:05:01kugelon load, keeping aspect ratio
20:07:38gevaertsSomething that might work is marking specific viewports as "stretchable", and making sure that the viewports left of it or below it use offsets relative to the "other end". That of course doesn't solve *all* problems (i.e. it doesn't do anything about the backdrop), and I'm sure some themes won't be able to work well with this
20:09:20 Join Horscht [0] (~Horscht@p57B57A8E.dip.t-dialin.net)
20:09:20 Quit Horscht (Changing host)
20:09:20 Join Horscht [0] (~Horscht@xbmc/user/horscht)
20:09:47Zagorgevaerts: but we also need stretching within each viewport. button position, for example, have to be scaled to viewport size
20:10:21kugelI think percentage viewports for skins would solve most problems
20:10:32ZagorI don't
20:11:19Zagorit only solves the case of one tag per viewport
20:11:26Zagorbasically, only the list
20:12:13gevaertsZagor: that depends on what's in the viewport. Stretching an AA viewport is probably reasonably easy to do, and stretching "UI viewport" (i.e. the list) is rather trivial for most themes (although I have a theme where that wouldn't work...).
20:13:54gevaertsI'm not convinced that it's possible to scale our current approach in a general way
20:14:29Zagorneither am I :-) but I think it's an idea worth exploring
20:15:33Zagorgevaerts: can you think of a few things in particular that won't work? (other than what I listed)
20:16:56gevaertsZagor: no, fonts and bitmaps are basically it I think.
20:17:32ZagorI think that's solvable by having low, mid and high-density versions
20:17:44Zagorthat's the android way
20:19:42gevaertsThat's doable for large differences. The main things I'm concerned about are the small differences like 480x800 vs 480x832
20:19:52gevaertsa.k.a. the disappearing status bar
20:20:20gevaertsYou can just scale the whole thing of course, but I'm afraid that will be ugly in at least some cases
20:20:57Zagoryes, the theme has to be designed with room for such scaling
20:21:32Zagorwe can't do pixel counting designs on android
20:22:04gevaertsMaybe we should also consider moving to freetype on android so we get scalable fonts
20:22:25gevaertsOr native font rendering, presumably
20:23:02Zagorthat's certainly possible. but I'm trying to limit the scope a bit here :)
20:23:06gevaertsAnd (*shudder*) native buttons and lists :)
20:31:02 Join antil33t [0] (~antil33t@203-100-223-143.callplus.net.nz)
20:34:11 Quit antil33t| (Read error: Connection reset by peer)
20:35:45 Quit dfkt|n ()
20:45:56 Quit mamarley (Remote host closed the connection)
20:58:37 Quit gbl08ma (Quit: Saindo)
20:59:39CIA-14New commit by 03bertrik (r30616): FS #12296 - latvian translation update by Mārtiņš Šimis
21:00
21:01:12 Join matze` [0] (~pflaume@p5498A67E.dip.t-dialin.net)
21:01:28CIA-14r30616 build result: All green
21:02:32CIA-14New commit by 03zagor (r30617): Enable Android status bar.
21:04:07CIA-14r30617 build result: All green
21:05:06kugelZagor: not sure if that's a good idea
21:05:16Zagoroh, why not?
21:05:24kugeldoesn't it overlap with cabbie?
21:05:38ZagorI'll fix that
21:05:50kugelokay :)
21:08:38 Join Slappyhaze [0] (~philjones@94-192-140-122.zone6.bethere.co.uk)
21:09:14 Join Mineo [0] (~wh@2001:638:904:ffca:4261:86ff:fe87:5544)
21:09:34 Quit Strife89 (Ping timeout: 248 seconds)
21:09:55Slappyhazehey, I posted a query in the forums and was pointed here. Is it ok?
21:10:05Mineohi. I'm not sure if this is the right place to ask because I can't access the ircguidelines linked in the topic :p
21:10:11 Quit GermanMushroom (Read error: Connection reset by peer)
21:10:45MineoI'm having trouble accessing rockbox.org over ipv6. is that a common problem?
21:11:22SlappyhazeI have a link to my issue: http://forums.rockbox.org/index.php/topic,28927.0.html
21:12:39Mineotraceroute6 is showing huge round trip times on some se.portlane.net hops which are the hops directly before www.haxx.se
21:19:06ZagorMineo: hmm, I don't think I have tested ipv6 since we changed server two weeks ago. are you not getting any response at all, or packet loss?
21:21:39 Join GermanMushroom [0] (~c@s5146db6a.adsl.wanadoo.nl)
21:22:52Mineosometimes I don't get any response at all (I had to kill rockboxdev.sh because it was trying to load a patch for over 2 minutes) or loading anything takes a really long time
21:22:59***Saving seen data "./dancer.seen"
21:25:02Zagorweird. I have no problems reaching out to for example ipv6.google.com from the server, and curl -6 www.rockbox.org on the server works too.
21:26:10 Join petur [0] (~petur@rockbox/developer/petur)
21:26:38Zagorbut http://ipv6-test.com shows a problem too. hmm.
21:28:27Mineofwiw I can't access portlane.net either
21:29:44ZagorI'll report it to them
21:29:56Zagorthank you for the notice
21:30:52Mineono problem
21:31:02Mineo(and thank you very much for rockbox :) )
21:31:50 Join ChickeNES [0] (~ChickeNES@rouxbicon.rh.uchicago.edu)
21:36:41 Quit TheLemonMan (Quit: WeeChat 0.3.5)
21:40:17 Quit simonlnu (Ping timeout: 255 seconds)
21:44:00 Join wodz [0] (~wodz@87-206-240-131.dynamic.chello.pl)
21:49:48LalufuWhat's the valid range of global_settings.volume?
21:51:36wodzLalufu: depends on the hardware
21:53:17LalufuIs there a generic way to set/query the volume between "mute" and "this is as loud as it gets"?
21:53:41Lalufuwhere does the GUI get the info from ?
21:54:30wodzfrom audiohw_settings[]
21:54:45wodzwhich is defined in codec driver file
21:55:16wodzfor example rockbox-git/firmware/drivers/audio/wm8751.c
21:55:30wodzs/rockbox-git/rockbox/
21:57:41Lalufuthe generic interface for that is firmware/sound.c?
21:58:28wodzprobably, I am not very familiar with code at higher level
22:00
22:01:26 Quit benedikt93 (Quit: Bye ;))
22:04:44 Quit y4n (Quit: 6,000,000 ways to die — choose one.)
22:04:52 Part blind
22:08:49 Join knob [0] (~knob@87.112.154.1)
22:09:03 Join Keripo [0] (~Keripo@165.123.49.217)
22:10:19 Join Strife89 [0] (~Strife89@207.144.201.128)
22:12:44 Quit matze` (Remote host closed the connection)
22:15:35 Quit GermanMushroom (Quit: Ik ga weg)
22:17:39 Quit Keripo (Ping timeout: 252 seconds)
22:18:51 Join notlistening [0] (~tom@94-195-105-95.zone9.bethere.co.uk)
22:19:16notlisteningHi what did the commit today enabling the android status bar do?
22:19:18ukleinekwodz: I found a contact email address in the net, but the reply directed me to their web formular
22:21:33Zagornotlistening: it simply makes the android app no longer be full-screen, so the android status/notification bar still shows. like in most other apps.
22:23:26n1syay, i finally managed to hack up tremor enough to not allocate all the memory for huge comment packets in the codec buffer
22:23:46Zagorn1s: nice!
22:23:51n1snot in a nice way at all but it seems to work for the one file with embedded aa i have
22:24:15 Quit petur (Remote host closed the connection)
22:27:58 Part knob
22:30:06notlisteningZagor, thanks
22:33:23 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk)
22:42:57 Join factor [0] (~factor@74.197.205.204)
22:46:55 Quit saratoga (Ping timeout: 252 seconds)
22:47:00 Quit wodz (Quit: Leaving)
23:00
23:03:43 Quit tjb0607 (Read error: Connection reset by peer)
23:04:43 Join tjb0607 [0] (~quassel@208-100-128-206.bendbroadband.com)
23:07:28 Join T44 [0] (~Topy44@g228173242.adsl.alicedsl.de)
23:08:34 Part Zagor
23:10:38 Quit Topy44 (Ping timeout: 248 seconds)
23:13:44 Join Marcin_ [0] (~chatzilla@baq194.neoplus.adsl.tpnet.pl)
23:18:15 Part Slappyhaze
23:20:03 Join funman [0] (~fun@rockbox/developer/funman)
23:21:39 Join [Saint] [0] (~st.lasciv@203.184.50.187)
23:23:03***Saving seen data "./dancer.seen"
23:25:57 Join mamarley [0] (~quassel@Lee-08-199.rh.ncsu.edu)
23:32:19 Quit n1s (Remote host closed the connection)
23:36:29 Quit bluefoxx_ (Ping timeout: 252 seconds)
23:49:52 Quit bertrik (Ping timeout: 255 seconds)
23:51:57 Join hilbert [0] (~hilbert@adsl-89-217-42-135.adslplus.ch)
23:58:35 Quit stripwax (Quit: http://miranda-im.org)

Previous day | Next day