| dilys | Merge to rocketfuel@canonical.com/launchpad--devel--0: pagetests updated, but still failling locally (patch-712) | 12:16 |
|---|---|---|
| dilys | Merge to rocketfuel@canonical.com/launchpad--devel--0: Mostly page fixes. Include bug #2144 (patch-713) | 12:34 |
| debonzi | thanks dilys | 12:36 |
| === ddaa [~ddaa@nemesis.xlii.org] has left #launchpad [] | ||
| === debonzi [~debonzi@200-158-107-234.dsl.telesp.net.br] has joined #launchpad | ||
| debonzi | Hi BradB... do you know why the data Ive put yesterday in launchpad_dogfood was deleted? | 01:46 |
| BradB | debonzi: nope | 01:51 |
| BradB | debonzi: sounds like somebody screwed something up though. | 01:52 |
| BradB | debonzi: what data was deleted? | 01:52 |
| BradB | i can see the source packages fine | 01:53 |
| debonzi | BradB, the sourcepackage stuff | 01:53 |
| debonzi | uhmm!! | 01:53 |
| BradB | they're in there | 01:53 |
| debonzi | just a second | 01:53 |
| debonzi | BradB, right.. they are there but the publishing table for them was deleted... thats why I can see them in soyuz | 01:57 |
| debonzi | Probably it was done when the available distrorelease was changed from warty to hoary.. | 01:58 |
| debonzi | thanks BradB | 01:58 |
| BradB | no prob | 01:58 |
| dilys | Merge to thelove@canonical.com/bazaar--devo--1.0: cherry pick recommended fix for get-changeset by abentley (patch-18) | 02:38 |
| dilys | Merge to rocketfuel@canonical.com/launchpad--devel--0: edit notification additions and fixes, and small UI fixes (patch-714) | 02:59 |
| === BradB is now known as BradB|away | ||
| === stub [~stub@dsl-246.248.240.220.dsl.comindico.com.au] has joined #launchpad | ||
| === stub [~stub@dsl-246.248.240.220.dsl.comindico.com.au] has joined #launchpad | ||
| === doko [doko@dsl-082-082-068-160.arcor-ip.net] has joined #launchpad | ||
| === mako [mako@micha.hampshire.edu] has joined #launchpad | ||
| === ddaa [~ddaa@nemesis.xlii.org] has joined #launchpad | ||
| dilys | Merge to thelove@canonical.com/bazaar--devo--1.0: Fixing id for test-get-changeset (patch-19) | 09:12 |
| === ddaa [~ddaa@nemesis.xlii.org] has joined #launchpad | ||
| dilys | Merge to thelove@canonical.com/bazaar--devo--1.0: Input validation for join-branch (joelatrosdahl.net) (patch-20) | 09:19 |
| dilys | Merge to thelove@canonical.com/bazaar--devo--1.0: create a minimal unit test for arch_chatter, and tweak the test Makefile a little to support that (patch-21) | 09:21 |
| dilys | Merge to thelove@canonical.com/bazaar--devo--1.0: Cosmetic changes to archive-mirror and cmd-tag (Cameron Patrick) (patch-22) | 09:24 |
| dilys | Merge to thelove@canonical.com/bazaar--devo--1.0: Various small star-merge changes (patch-23) | 09:38 |
| dilys | Merge to thelove@canonical.com/bazaar--devo--1.0: Grab fixes (Thaeter) (patch-24) | 09:50 |
| dilys | Merge to thelove@canonical.com/bazaar--devo--1.0: Automatic changelog tag fixups (Droneaud) (patch-25) | 10:06 |
| ddaa | lifeless: running a replay/commit script? | 10:08 |
| dilys | Merge to thelove@canonical.com/bazaar--devo--1.0: --no-greedy-add to buld-cfg (Riiser) (patch-26) | 10:16 |
| dilys | Merge to thelove@canonical.com/bazaar--devo--1.0: Changing default inventory options to saner defaults (Walters) (patch-27) | 10:30 |
| dilys | Merge to thelove@canonical.com/bazaar--devo--1.0: Adding --silent option to file-find (Bentley) (patch-28) | 10:36 |
| dilys | Merge to thelove@canonical.com/bazaar--devo--1.0: Break hard links in set-tree-version (Bentley) (patch-29) | 10:41 |
| !Md:*! oops... we have lost a main rotation server. sorry for the inconvenience | 10:47 | |
| dilys | Merge to thelove@canonical.com/bazaar--devo--1.0: Fixed missing exit in set-tree-version (Bentley) (patch-30) | 10:47 |
| === lifeless [~robertc@dsl-78.1.240.220.rns01-kent-syd.dsl.comindico.com.au] has joined #launchpad | ||
| === daf [daf@muse.19inch.net] has joined #launchpad | ||
| ddaa | lifeless: ping | 10:50 |
| dilys | Merge to thelove@canonical.com/bazaar--devo--1.0: Try using revlibs with cmd-changes (Bentley) (patch-31) | 10:52 |
| dilys | Merge to thelove@canonical.com/bazaar--devo--1.0: Get-changeset fix (Bentley) (patch-32) | 11:03 |
| dilys | Merge to thelove@canonical.com/bazaar--devo--1.0: Prevent getting from -MIRROR, _SOURCE, etc (Bentley) (patch-33) | 11:12 |
| ddaa | Haha. #arch is awakening to baz. | 11:14 |
| dilys | Merge to thelove@canonical.com/bazaar--devo--1.0: files other than regular, links and dirs should be tagged precious by default (Johannes) (patch-34) | 11:18 |
| === Kinnison [~dsilvers@haddenham.pepperfish.net] has joined #launchpad | ||
| Kinnison | elmo: ping? | 11:23 |
| dilys | Merge to thelove@canonical.com/bazaar--devo--1.0: Fix the star-merge works only one way problem. With test case (Bentley) (patch-35) | 11:24 |
| dilys | Merge to thelove@canonical.com/bazaar--devo--1.0: Give more useful error if the library cannot be created because parent is missing (Johannes) (patch-36) | 11:30 |
| === carlos [~carlos@69.Red-80-33-181.pooles.rima-tde.net] has joined #launchpad | ||
| carlos | morning | 11:42 |
| dilys | Merge to thelove@canonical.com/bazaar--devo--1.0: Remove incorrect help from inventory -H (Jivera) (patch-37) | 11:43 |
| ddaa | hey carlos | 11:44 |
| dilys | Merge to thelove@canonical.com/bazaar--devo--1.0: Help cleanup for cmd-changeset.c (Palmer) (patch-38) | 11:54 |
| carlos | ddaa: hi | 11:55 |
| dilys | Merge to thelove@canonical.com/bazaar--devo--1.0: Contant time version of DAV file_exists (Bentley) (patch-39) | 11:59 |
| Kinnison | jblack is on a roll today | 12:01 |
| jblack | Yeah. I'll be busy for the next few days. | 12:01 |
| jblack | I'm done for tonight though. | 12:01 |
| jblack | Tomorrow the hard work starts -- merging the patches that don't go cleanly. | 12:02 |
| Kinnison | hehe | 12:02 |
| === Kinnison has faith | ||
| Kinnison | How; if I could have a bloody archive I could set-to getting gina running | 12:03 |
| ddaa | jblack: duh, I thought lifeless set up a replay script... | 12:21 |
| jblack | ddaa: Nope. those were done by hand, one at a time. | 12:21 |
| jblack | About 3/5 of the patches replayed, and about 2/5 didn't. | 12:22 |
| ddaa | What was the strategy? Follow 1.2.2rc2 ancestry? | 12:22 |
| jblack | for a variety of reasons. I'll go over them starting tomorrow. | 12:22 |
| ddaa | Or start with Tom's 1.2.1 and then merge your patches? | 12:22 |
| jblack | Nope. | 12:22 |
| jblack | He started off of lords patchlog pruned gnua tree. | 12:23 |
| ddaa | Yuck. | 12:23 |
| jblack | Already fixed. | 12:23 |
| ddaa | Phew. | 12:23 |
| jblack | I replayed a patch that put the patchlgos back. | 12:23 |
| ddaa | I would have hated to see the brain damage spread. | 12:23 |
| jblack | I would have rebelled. | 12:23 |
| jblack | Oh, want the punchline? | 12:24 |
| jblack | Apparently Tom knew exactly how evil it was, because he treated himself specially, and _put_his_patchlogs_back_ | 12:24 |
| jblack | Nobody else's mind you. Just his own. | 12:25 |
| === ddaa is suprised by how apathetic the gnu-arch community is... almost no reaction from the announce of baz yet. | ||
| ddaa | Yeah, you told me. | 12:25 |
| ddaa | That just does not make any fucking sense. | 12:25 |
| jblack | Sure it does. Tom wanted to replay. | 12:25 |
| jblack | He just doesn't want anyone else to. | 12:25 |
| ddaa | What I said. | 12:26 |
| ddaa | Makes no sense. | 12:26 |
| jblack | Anyways.... | 12:26 |
| jblack | I replayed most of jblack@inframix last night. Almost everything went in from there. | 12:26 |
| jblack | Then while I was sleeping, lifeless, not realizing I hadn't finished yet (I had jb@gnua yet to do), applied some other patches. | 12:26 |
| ddaa | BTW, how the release policy going to be like? | 12:27 |
| jblack | So for the last 3 hours or so, I had to merge dance for the last few hours. | 12:27 |
| ddaa | And the versioning policy. | 12:27 |
| jblack | ddaa: If I get to decide, the same as I did the rc/release policy. | 12:27 |
| ddaa | So, you'd start at baz-1.2.2? | 12:27 |
| jblack | Once I'm done getting my stuff out of my old archives into baz, then I'll cut a new archive and tag off of that. | 12:27 |
| jblack | What number will we start with? Hmmmm. | 12:28 |
| jblack | Didn't consider that yet. | 12:28 |
| ddaa | That's an important issue. | 12:28 |
| jblack | Definitely. | 12:28 |
| ddaa | Starting with 1.2.2 will makes it easier to see how it relates to tla. | 12:28 |
| jblack | loaded with all sorts of meaning an innuendo. | 12:28 |
| jblack | ddaa: As it relates to tla, it'll be 1.2.3 | 12:28 |
| ddaa | But it might be perceived as more conflictual. | 12:29 |
| jblack | I've put in 1.2.2rc + 1.2.3rc patches together. | 12:29 |
| ddaa | Hu? | 12:29 |
| ddaa | I would have made sense to just start off 1.2.2, add the missing one-line patch, and release. | 12:29 |
| jblack | Heh. You think development stopped just because 1.2.2rcX was released? Nope. I kept going towards 1.2.3 | 12:29 |
| ddaa | The point of it would have been being _immediately_ better than tla. | 12:30 |
| ddaa | And giving a release for contributors to tag from. | 12:30 |
| jblack | Talk to lifeless about making the announcement a mere 24 hours after opening up the archive. | 12:30 |
| ddaa | The early announcement makes sense. | 12:31 |
| ddaa | "We are not hiding anything, you see." | 12:31 |
| jblack | you can't have it both ways. | 12:31 |
| ddaa | But, in addition, an early release would have made sense too. | 12:31 |
| jblack | either its immediately better, or nothing's hid. | 12:31 |
| jblack | in this case, nothing's hid, so there's a lag time of a few days while stuff goes in. | 12:31 |
| ddaa | Starting off a finished 1.2.2 would have immediately given a production-grade release. | 12:32 |
| ddaa | But anyway. The choice is made. | 12:32 |
| jblack | tell you what. | 12:32 |
| jblack | If you want to promise to forward port the patches that are waiting for 1.2.3 after 1.2.2, I'll back them out. | 12:33 |
| ddaa | you know I can't promise that. | 12:33 |
| jblack | Then I'll have to do it now, before too much gets in. | 12:33 |
| jblack | I'm going to be too busy to forward port 40 patches. | 12:33 |
| jblack | not to mention the tree will probably move too quickly to do it. | 12:34 |
| jblack | regarding release process, archive setup, et. al, I have to talk to lifeless first. | 12:34 |
| jblack | There's an impedance mistmatch between the old release process, and lifeless' merge process. | 12:35 |
| ddaa | Yeah. | 12:35 |
| ddaa | But I still think that the rc process was basically a good idea. | 12:36 |
| jblack | Oh, its a resolvable issue. | 12:36 |
| ddaa | Probably we could apply Linus release process here: | 12:36 |
| ddaa | freeze the trunk during rc, so devels will get involved in testing it. | 12:37 |
| ddaa | Like 2 weeks hacking, 2 weeks freezing. | 12:37 |
| jblack | Are you serious? | 12:37 |
| jblack | Lets do something better. | 12:38 |
| ddaa | The debian release process is notoriously ineffective: keep unstable moving while hoping that testing gets fixed. | 12:38 |
| jblack | Give me until monday to outline a way to do it, which I'll present at the meeting. | 12:38 |
| ddaa | Well, maybe the fact we have paid staff to make it work will help that. But RCs need as much testing as possible. | 12:38 |
| jblack | Uh huh. | 12:39 |
| jblack | I don't think that the "freeze to make software better" idea works. | 12:39 |
| ddaa | Not that I am any authority in matters or release process management... | 12:39 |
| jblack | If that were true, Tom's 6 month freezes would mean that tla would be of very high quality. | 12:39 |
| ddaa | That was not a freeze, that was a stop. | 12:40 |
| jblack | shrug. | 12:40 |
| ddaa | A freeze involves RC bugfixing. | 12:40 |
| ddaa | Whatever. | 12:40 |
| ddaa | My two cents. | 12:40 |
| jblack | Here's the process I'm imagining. | 12:40 |
| jblack | I tag a rc from the tree that is dev-current. | 12:41 |
| jblack | I review all of the patches. That I don't like, I pull out. | 12:41 |
| jblack | I then announce the rc. | 12:41 |
| jblack | people start testing, saying where things are broken in the rc, etc. | 12:42 |
| jblack | developers see complaints, put in patches to fix the rc complaints, which gets pulled into the rc. | 12:42 |
| jblack | simultaneous with an rc being out, I'm already reviwing the first rc for the next revision. | 12:42 |
| ddaa | I assume you realize that's a massive amount of work... | 12:43 |
| jblack | I'm making the best of the situation. | 12:43 |
| jblack | lifeless seems to think that I can review patches on the backend. | 12:44 |
| jblack | which really just shifts the backlog around. | 12:44 |
| ddaa | Chi va piano, va sano; chi va sano, va lontano. | 12:45 |
| jblack | Dont' forget that eventually I'll have the supermirror equipment too, and I'll be doing that on top. | 12:46 |
| jblack | So I'll have a bit of fun. | 12:46 |
| ddaa | Go in the direction you think is best. If you get swamped we are not going to wait 6 months before reacting. | 12:47 |
| jblack | Where I have choices, I'll of course try for what I think is best. ;) | 12:48 |
| jblack | So, anything else we need to discuss before I head off to bed? | 12:49 |
| ddaa | Nothing in particular. | 12:49 |
| jblack | ddaa: Don't worry. I like having lots of work. | 12:50 |
| === ddaa is busy refactoring the backend layer of pyarch... | ||
| ddaa | Duh... the baz support was the drop that made it urgent to clean up a lot of accumulated nastiness in some dark corners... | 12:50 |
| jblack | and if I consistantly have more than I can realistically do, we'll figure something more sane out. | 12:50 |
| ddaa | It's a lot of work to figure all the details out... | 12:51 |
| ddaa | jblack: g'night.... | 12:52 |
| jblack | ddaa: Thats ok. You'll do fine. :) | 12:53 |
| Kinnison | elmo: reping? | 01:04 |
| === debonzi [~debonzi@200.158.100.251] has joined #launchpad | ||
| jblack | which airport is right for south kensington? LHR ? | 01:42 |
| Kinnison | yeah LHR is good | 01:42 |
| debonzi | jblack, hi man | 01:44 |
| jblack | heya debonzi | 01:44 |
| debonzi | jblack, how is it going? | 01:44 |
| jblack | pretty good. Just realized how close the arch sprint is | 01:45 |
| debonzi | jblack, yeah.. the time flies :) | 01:46 |
| jblack | travelocity can't find me a 3 leg hop. | 01:47 |
| debonzi | jblack, ahh, btw... do you know how to describe me that "problem" when tla wants to merge some modifications that was already applied? | 01:47 |
| jblack | debonzi: Yes. That happens if you star merge rocketfuel before rocketfuel is done star-merging you. | 01:48 |
| debonzi | jblack, yes.. this I know and I happily did't get this anymore :).. but there is a guy that have a tag from cprov and got this problem.. he ask me what should he do to avoid it but I could not explain | 01:49 |
| debonzi | jblack, and there is no pqm involved.. or better, cprov is the PQM :) | 01:50 |
| Kinnison | hey debonzi. | 01:51 |
| debonzi | Kinnison, hi | 01:51 |
| jblack | debonzi: He should only merge to and from one guy. | 01:51 |
| Kinnison | debonzi: is it possible for anyone but elmo to update the archive on mawson? | 01:51 |
| jblack | And to make sure that he and the other guy doesn't merge each otehr at the same time | 01:51 |
| spiv | jblack: And that their mirror are up to date before merging? | 01:52 |
| debonzi | jblack, right.. I know the guy only star-merge from and to cprov.. | 01:52 |
| debonzi | Kinnison, I don't know.. sorry | 01:52 |
| === Kinnison is doing other stuff in the meantime; but I can't do the gina run on mawson until the mirror actually has hoary in it | ||
| jblack | oh my. | 01:54 |
| jblack | spiv: correct. | 01:54 |
| jblack | debonzi: Then probably they merged each otehr at the same time. | 01:54 |
| Kinnison | I thought star-merge was meant to cope with this | 01:55 |
| spiv | Kinnison: Teehee. | 01:56 |
| debonzi | jblack, probably because the mirrors should always be up to date since both are using hook for it | 01:57 |
| jblack | Kinnison: Can't. | 01:57 |
| debonzi | jblack, so, a right way to handle it could be: both working in diferent things and commiting. At a given time on star-merge from the other and when it is finished, commited and mirrored, the other one can make the star-merge.. right? | 02:01 |
| jblack | Right. | 02:01 |
| jblack | exactly right. | 02:01 |
| debonzi | jblack, and if after the firt one finish the star-merge the second one work a little more, make some commits and only then make the star-merge. Is it ok to? | 02:03 |
| debonzi | s/to/too | 02:04 |
| jblack | Yes. | 02:04 |
| debonzi | right.. Ill talk about it to them.. thanks jblack | 02:04 |
| === kiko [~kiko@200.144.121.120] has joined #launchpad | ||
| carlos | debonzi, kiko: Is it normal that when using the launchpad sample data celso gave me and going to http://localhost:8086/soyuz/distros/ubuntu/src/warty/apache/1.3.31-6 postgresql and launchpad start eating all my CPU and IO channel? | 02:38 |
| ddaa | hey spiv | 02:39 |
| ddaa | I'm reorganizing the pyarch backend model. | 02:39 |
| spiv | Hey. | 02:39 |
| ddaa | The twisted stuff used to live in arch._twisted, now I'd like to move it to arch.backends.twisted. | 02:39 |
| debonzi | carlos, it not normal, but sometimes it happens... cprov has done some work to get it better.. are you up to date with rocketfuel? | 02:40 |
| ddaa | However, that would cause a name conflict. | 02:40 |
| carlos | in fact, my postgresql is mad now, with launchpad stopped it continues eating my CPU... | 02:40 |
| carlos | debonzi: yes | 02:40 |
| ddaa | spiv: any idea for a better name? arch.backend.twisted_process is a bit of a mouthful imho. | 02:40 |
| debonzi | carlos, will try to firgure it out.. | 02:40 |
| kiko | carlos, sound like a broken query; I did post a fix to that I believe | 02:40 |
| kiko | or was it salgado? | 02:40 |
| ddaa | and things like arch.backend.reactor or arch.backend.meltdown not really obvious imho. | 02:41 |
| carlos | thanks | 02:41 |
| kiko | carlos, at any rate, let me get salgado on it | 02:42 |
| ddaa | Maybe arch.backend.untwisted? | 02:42 |
| === salgado [~salgado@200-206-134-238.async.com.br] has joined #launchpad | ||
| carlos | ok | 02:42 |
| spiv | The Twisted bits of pyarch only affect process handling? | 02:42 |
| kiko | salgado, dude | 02:43 |
| kiko | with the sampledata cprov has given carlos | 02:43 |
| spiv | I guess I'm fuzzy about what "backend" means for pyarch :) | 02:43 |
| kiko | http://localhost:8086/soyuz/distros/ubuntu/src/warty/apache/1.3.31-6 | 02:43 |
| spiv | It's a very generic term. | 02:43 |
| kiko | salgado, pgsql starts blowing up | 02:43 |
| ddaa | spiv: yes, that's essentially a ProcessProtocol and a thread-side blocking API. | 02:43 |
| carlos | lp_dump-20041025-mr.sql | 02:43 |
| kiko | can you look into it? it's probably a query missing a join clause | 02:43 |
| carlos | That's the file I'm using | 02:43 |
| kiko | salgado, debonzi: which brings me to the matter: I think we should start considering using views to avoid this sort of problem | 02:44 |
| ddaa | spiv: in the case of pyarch that's going to be all the stuff that relates to interfacing with tla, baz, and the mythical libarch. | 02:44 |
| spiv | Ok, they feel like different things to me. | 02:44 |
| salgado | kiko: I've just had the same problem | 02:45 |
| spiv | If anything, the twisted support is a layer between tla/baz and the rest of pyarch. | 02:45 |
| ddaa | Which is going right now to include the command name (tla/baz) the spawning strategy (pyarch/twisted) and the process logging (silent or debug). | 02:45 |
| kiko | salgado, fixes and merges appreciated | 02:45 |
| === carlos -> lunch | ||
| salgado | kiko: I was waiting the notie come back to life to fix it | 02:45 |
| spiv | Rather than at the same level as tla/baz. | 02:45 |
| kiko | salgado, if you want you can just tag off debonzi or mail him patches for fast merges | 02:45 |
| === Kinnison -> town | ||
| ddaa | spiv: yes, but all those different things are somewhat tightly coupled. | 02:45 |
| salgado | kiko: ok | 02:46 |
| kiko | salgado, but seriously, I think we should talk about using a view to simplify this | 02:46 |
| kiko | I think we are forgetting join clauses too often.. | 02:46 |
| ddaa | The cli interface depends on process spawning, which depends on cli logging... | 02:46 |
| ddaa | And the process name stands somewhere in the middle of that. | 02:47 |
| ddaa | So, from pyarch perspective, they are quite the same hairball. | 02:47 |
| spiv | kiko: Is this related to clauseTables? | 02:48 |
| ddaa | spiv: but what you are saying is essentially correct. Only twisted/pyarch is only one axis of the backend configuration. | 02:48 |
| kiko | spiv, I don't think so, I didn't review that part of cprov's crack yesterday, I'll only have time to look at it tomorrow | 02:48 |
| kiko | spiv, did anything like that land? | 02:48 |
| ddaa | spiv: so, any kind of conventional name for this sort of thing in the twisted world? | 02:49 |
| spiv | ddaa: Right. So, not being an expert in how pyarch works, I'd naively expect there to be pyarch.spawning.{twisted,popen}, pyarch.cli.{tla,baz}, etc. | 02:50 |
| === debonzi [~debonzi@200.158.100.251] has joined #launchpad | ||
| === ddaa ponders | ||
| debonzi | carlos, for sure there is a problem there.. it killed my machine.. :( | 02:51 |
| ddaa | btw, PyArchSpawningStrategy is not based on popen. It's doing the fork/exec and pipe handling itself. | 02:51 |
| spiv | kiko: No, but I was just curious, only half-listening to what you were saying to salgado... I saw you say something about joins, and wondered if it was related. | 02:51 |
| spiv | ddaa: pyarch.spawning.diy then ;) | 02:51 |
| kiko | maybe | 02:51 |
| spiv | (Plus I haven't seen a reply to my post to the launchpad list about it) | 02:52 |
| ddaa | Mh... the point of arch.backend is that there needs to be a single place to glue all the parts toghether. | 02:52 |
| kiko | spiv, I saw it but haven't discussed it yet | 02:53 |
| ddaa | And anyway arch.spawning.twisted is not going to help the fact that I cannot import twisted from there! | 02:53 |
| ddaa | What is annoying me is that name conflict. | 02:53 |
| spiv | Oh, right, now I get what you were asking about. | 02:53 |
| ddaa | And please do not give me any of that sys.module crack :-) | 02:54 |
| spiv | No, I don't know of any conventions for this. Relatively few projects don't go 100% twisted. | 02:54 |
| spiv | Hah, no :) | 02:55 |
| spiv | Python's import stuff is frustrating enough ;) | 02:55 |
| spiv | pyrad has a module called "curved" for this purpose. | 02:55 |
| ddaa | spiv: so, what would be evocative to a twisted person? | 02:55 |
| ddaa | "wedged"? :-P | 02:55 |
| spiv | An obtuse Monty Python, Pokey the Penguin, Isometric reference ;) | 02:56 |
| ddaa | gne? | 02:56 |
| spiv | s/, I/, or I/ | 02:56 |
| spiv | ddaa: Most of the Twisted devs are mildly obsessed with webcomics. | 02:57 |
| ddaa | I terrible lack culture in all those domains. | 02:57 |
| spiv | I'd say "knotted" would be good. | 02:57 |
| spiv | And then you can tell people to "get knotted" ;) | 02:57 |
| === ddaa misses the reference | ||
| spiv | It's english slang, similar to "get stuffed" I guess. | 02:59 |
| ddaa | That's something involving penetration I guess. | 03:00 |
| spiv | Similar to "get <insert random verb here>" ;) | 03:00 |
| ddaa | In french, "noeud" (knot) is slang for penis. | 03:01 |
| === kiko is now known as kiko-afk | ||
| ddaa | Okay. Sounds good. | 03:01 |
| debonzi | spiv, can you help me to check one query? | 03:02 |
| ddaa | Mind if I give credit for the name? | 03:03 |
| kiko-afk | it's a trade secret! | 03:04 |
| spiv | debonzi: Sure, but I'm about to duck out for 10 min. | 03:06 |
| debonzi | spiv, it very fast I think.. | 03:06 |
| spiv | So either be fast or patient :) | 03:06 |
| ddaa | """Twisted process handling. | 03:08 |
| ddaa | The name of this module"knotted", was suggest by Andrew Bennets as a | 03:08 |
| ddaa | way to avoid the name clash with the "twisted" top-level package: | 03:08 |
| ddaa | <spiv> I'd say "knotted" would be good. | 03:08 |
| ddaa | <spiv> And then you can tell people to "get knotted" ;) | 03:08 |
| ddaa | """ | 03:08 |
| spiv | ddaa: Hehe. But my surname has two "t"s :) | 03:08 |
| ddaa | I disclaim all responsibility for the bad taste of Twisted devels :-) | 03:08 |
| ddaa | Ooops. Fixed. Thanks. | 03:09 |
| kiko-afk | stub, are you around? | 03:12 |
| stub | Yup | 03:13 |
| kiko-afk | stub, debonzi and I are this weekend going to move some queries into views | 03:14 |
| kiko-afk | we've got a lot of massive joins and the code is kinda unwieldy | 03:14 |
| stub | Sounds sane | 03:14 |
| kiko-afk | what's your take on this? | 03:15 |
| kiko-afk | we'll probably drop some sql on your lap sometime soon then | 03:15 |
| kiko-afk | btw, did you get my index request? | 03:15 |
| stub | Yup - that went in the last patch, yesterday I think | 03:15 |
| kiko-afk | thanks | 03:16 |
| === kiko-afk perf munster | ||
| lifeless | jblack ddaa we are working towards 1.0. Sorry to beat you to the punch, but I needed a decision when tagging. | 03:21 |
| jblack | lifeless: Pardon? | 03:22 |
| jblack | Oh, you mean uh, baz version #. | 03:22 |
| jblack | Whatever you want to start at is cool with me. | 03:22 |
| ddaa | I'm not sure that the namespace version excludes anything for the release version. | 03:22 |
| ddaa | But 1.0 is certainly less controversial, even if less evocative. | 03:23 |
| lifeless | ddaa: true, but having 1.0 in the namespace makes 1.0 as the release natural ond abvious to folk. | 03:23 |
| jblack | The starting number isn't the part I'm thinking about atm. | 03:23 |
| jblack | the part I'm thinking about is the potential falling behind between what gets into dev and what I review before making an rc. | 03:24 |
| ddaa | BTW, maybe 0.9 releases would be in order until we have redone the command set. What do you think? | 03:24 |
| ddaa | Because we are surely going to redo the command set... | 03:24 |
| lifeless | jblack: thats release policy. I don't have a strong opinion on what we should do there yet, so I'll be seeking input. | 03:25 |
| lifeless | ddaa: well, 1.0preX releases are equally visible to the user. | 03:25 |
| ddaa | 1.0pre3rc2.... | 03:25 |
| jblack | No. | 03:25 |
| ddaa | yuck | 03:25 |
| lifeless | I think we need to set a few feature goals for the first release, and then a timeframe for that. | 03:25 |
| lifeless | that will give us structure to consider the other priorities in. | 03:26 |
| jblack | preferably XrcY, acceptably XpreY, but XpreXrcY, yuck no. | 03:26 |
| ddaa | Apparently jblack's feature goals are "whatever was scheduled for inclusion in 1.2.3" | 03:26 |
| ddaa | I think that a quick release is a damn good idea. | 03:26 |
| jblack | Yeah. I want that code out. | 03:27 |
| lifeless | ddaa: I asked jblack to incorporate all of that work, and hes' doing a great job of doing so. | 03:27 |
| === debonzi will be back in a minute | ||
| ddaa | If I were in jblack's shoes I would have made the first release the equivalent of 1.2.2-final. | 03:27 |
| lifeless | jblack: remember that when you review 'on the backend' - you are doing a final sanity check - any patch has already been 'oked' by one of us four. | 03:27 |
| lifeless | ddaa: we don't have a release manager for bazaar | 03:27 |
| jblack | lifeless: Um, lifeless, here's the problem.... | 03:28 |
| jblack | People make mistakes. _frequently_. | 03:28 |
| ddaa | lifeless: we are going to make releases, aren't we? | 03:28 |
| jblack | From arch experience, the accuracy rate on patch submissions for high calibre people is about 90%. | 03:28 |
| ddaa | Eternal Beta is not what the community needs. | 03:28 |
| lifeless | ddaa: act. | 03:28 |
| lifeless | bahh. | 03:28 |
| lifeless | ddaa: ack. | 03:29 |
| ddaa | lifeless: ? | 03:29 |
| jblack | That means that if there's 10 revisions that haven't been looked at by at least two people, the chance of a serious problem is very high. | 03:29 |
| lifeless | can we unmultiplex these conversations. jblack - lets focus on the process stuff. | 03:29 |
| jblack | sure boss. | 03:29 |
| lifeless | jblack: which is what you are talking about :) | 03:29 |
| ddaa | So, releases w/o release manager? Sounds... risky... | 03:29 |
| === stub [~stub@dsl-246.248.240.220.dsl.comindico.com.au] has left #launchpad [] | ||
| lifeless | I was just putting ddaa's stuff to the side. | 03:30 |
| jblack | heh. | 03:30 |
| jblack | Here's the cycle I envision. | 03:30 |
| === ddaa goes back to turning pyarch guts upside down. | ||
| lifeless | so. there are two ways of addressing the review bottleneck. | 03:30 |
| lifeless | (two fundamental ways). | 03:30 |
| jblack | I get an Xrc out. While Xrc is being reviewed for 1~2 weeks, I'm reviwing for X+1rc. | 03:30 |
| lifeless | a) scale out the review process into lieutenants. | 03:30 |
| jblack | If a fix is needed, it goes into devel, and I merge it into both rcs. | 03:31 |
| lifeless | b) allow the review process to lag the development | 03:31 |
| jblack | Long term, yeah. We can do that with buddy systems. | 03:31 |
| lifeless | now, the process I've introduced here has both element. | 03:31 |
| jblack | We pair frequent developers up, and they check each other. | 03:31 |
| lifeless | a) - there are 4 lieutenants - you, me, ddaa, bob2. | 03:32 |
| lifeless | b) - the review is allowed to lag, but we have a nominated reviewer who will check. | 03:32 |
| lifeless | (you for now, if your bandwidth is wide enough) | 03:32 |
| jblack | yes, it is | 03:33 |
| lifeless | (when I say 'for now' - when we get this dedicated C programmer, I'm expecting to make this his|her problem) | 03:33 |
| jblack | ok | 03:33 |
| lifeless | so the question that matters w.r.t. 'released code' is: how many layers of review are enough? | 03:34 |
| jblack | (btw, I like that) | 03:34 |
| jblack | What level of quality do you want? | 03:34 |
| lifeless | Both you and Tom, in series, for the 1.2.1 release accepted bugs. | 03:35 |
| lifeless | so 2 reviewers obviously isn't enough :) | 03:35 |
| jblack | If we start with a accuracy rate of 80%, and assume that each developer cuts the error rate in half... | 03:35 |
| jblack | (the original submitter counts as reviewer 1) | 03:36 |
| lifeless | So, what I'd *like* - and here is where we can debate about if its doable - is for us to aggresively introduce things to increase that quality per reviewer. | 03:36 |
| lifeless | I've put a unit test suite into libarch now, that is easy to extend. | 03:36 |
| jblack | I don't get you. | 03:36 |
| lifeless | So, when *I* review stuff, I'll be writing tests. | 03:36 |
| lifeless | I hope my accuracy rate will be ~ 95%. | 03:37 |
| ddaa | test cases, test cases, test cases | 03:37 |
| jblack | You're not that good. | 03:37 |
| lifeless | dude, I'm better than that, but I have multiple priorities. | 03:37 |
| jblack | Trust me. You're not. You're one of the three best, but you're not 95%. | 03:38 |
| === lifeless shrugs | ||
| lifeless | I've run enough projects, and know how often I need to back out changes I thought were good, to have a pretty good idea of how good I am. | 03:38 |
| lifeless | anyway, leaving that aside, the goal I'd like us to reach is an 80%-90% code path coverage on the tla code base. | 03:39 |
| lifeless | in terms of test cases. | 03:40 |
| jblack | I agree. | 03:40 |
| lifeless | that sort of coverage allows rapid review. | 03:40 |
| lifeless | rather than hour long code path picky sessions. | 03:40 |
| jblack | I'm not sure how we measure that metric though. | 03:40 |
| lifeless | gcov | 03:41 |
| lifeless | gcc compiler coverage tool. | 03:41 |
| lifeless | tells you what parts of a binary are exercised by a specific code run. | 03:41 |
| jblack | Yeah. I'm looking at the man page. | 03:41 |
| jblack | Ok. That answers that. | 03:41 |
| lifeless | so, I'm confident that good coding style from our changes, which will be the bulk of 'risky' changes, will address the quality aspect. | 03:42 |
| lifeless | but, we have a window between now and the test suite being mature, which is higher risk. | 03:42 |
| jblack | No sir. | 03:42 |
| lifeless | its not higher risk ? | 03:42 |
| jblack | We may be able to cover the code base, but we won't cover some of the most important things. | 03:42 |
| jblack | Previous comment. | 03:43 |
| jblack | In fact, the test suite can catch most everything but the most dangerous changes. Unintentional compatibility changes. | 03:43 |
| jblack | at least not with a conventional test kid. | 03:44 |
| jblack | *kit. | 03:44 |
| lifeless | erm, the test suite can absolutely catch those. you run the previous version test suite against the newer version code. | 03:44 |
| lifeless | thats a few hours work to setup a script to checkout & copy in the right things. | 03:44 |
| lifeless | we need an archive format test suite, for all these implementations floating around. | 03:46 |
| lifeless | that would be (IMO) a good third party project, perhaps one we could kick off under the bazaar umbrella. | 03:47 |
| jblack | Yes, we do. | 03:47 |
| jblack | Bug out on archive format, warn on library and working tree | 03:47 |
| jblack | Oh, and bugout on changesets. | 03:48 |
| lifeless | or flag to choose :). | 03:48 |
| lifeless | 'I care if I broke anything' | 03:48 |
| lifeless | 'I care if I broke archives' | 03:48 |
| lifeless | etc | 03:48 |
| jblack | same difference, as long as those are the defaults. :) | 03:48 |
| lifeless | let me fire up a browser, gonna note that down on the wiki | 03:48 |
| lifeless | ok, I've noted that so we won't forget . | 03:50 |
| jblack | ok. | 03:50 |
| jblack | Another issue that needs discussing real soon is divergance. | 03:50 |
| lifeless | so the bottom line on this review thing: I absolutely want the 4 of us able to commit when we are happy with what we want to commit. | 03:50 |
| jblack | we're developing at a different rate. developers very quickly are going to have to decide which tree to target, and port to the other tree. | 03:51 |
| jblack | even if the code is conceptually similiar, patch just ain't very smart. | 03:51 |
| lifeless | as long as we are able to do that, I will happily entertain discussions on ways to increase the amount of peer review, and reduce the lag from commit -> review. | 03:51 |
| lifeless | jblack: right. | 03:51 |
| jblack | ok. peer review. | 03:52 |
| jblack | One thing we could do is put up a website with the revisions in -dev listed. | 03:52 |
| lifeless | archzoom ? | 03:52 |
| jblack | developers are listed one way, revisions another. | 03:52 |
| jblack | in a table. | 03:52 |
| lifeless | ahr. | 03:52 |
| jblack | in each field of a table, there is a Good and a bad tick. They can tick either one. If X number of developer tick good, it goes in. if anybody marks bad, its pulled out.\ | 03:53 |
| jblack | Say a Good/Bad/Undecided radio | 03:53 |
| lifeless | erm, too complex. | 03:53 |
| lifeless | this has to be -simple-. Thats why I made you post-commit 'nazi', cause thats real simple. | 03:54 |
| jblack | Ok. I'll try and come up with a simpler way to parrallize. | 03:54 |
| kiko-afk | where's the eggmeister | 03:55 |
| jblack | I mean, sure, we can add as many developers as you want, and keep it serialized (and thus very simple). | 03:55 |
| lifeless | right. My criteria are: we commit when someone with commit rights is happy. (If they aren't trustworthy to decide whats good & whats not, we pull those rights). | 03:55 |
| lifeless | any processes we introduce on top of that need to be dead simple. | 03:55 |
| jblack | how about an email to with a subject along the lines of "Q--R--V-N good" or "Q--V--R-N bad" | 03:57 |
| carlos | debonzi: your patch fixes the problem, thank you | 03:57 |
| jblack | on the other end is a procmail script. | 03:57 |
| lifeless | email to ?? with | 03:57 |
| lifeless | whats the good email for ? | 03:57 |
| jblack | to count reviews. | 03:57 |
| lifeless | sounds like the same idea, just via email. | 03:58 |
| jblack | Well, we have to count good reviews, otherwise we can't distinguish between whether or not a patch has been reviewed, or just neglected. | 03:58 |
| debonzi | carlos, cool .. :) | 03:58 |
| lifeless | I think the email thing has merit... what about a pqm command 'revert' to revert out a commit - and everything past it if the patch won't replay --reverse cleanly. | 03:59 |
| jblack | THat works for "QVRN bad". (In fact, I like that) | 03:59 |
| jblack | But the alternative to counting goods is counting time, and then we're just hoping somebody looked in a window. | 04:00 |
| lifeless | sure. | 04:00 |
| jblack | (within a window) | 04:00 |
| lifeless | we've limited resources right? | 04:00 |
| lifeless | and a huge pool of contributors in theory. | 04:01 |
| jblack | the subset of reviewers is much smaller. | 04:01 |
| lifeless | right, so its inevitable they will get swamped. | 04:01 |
| jblack | The process needs to handle every revision as if its a complicated star-merge fix. | 04:01 |
| lifeless | thats overengineering. | 04:01 |
| lifeless | leave room for the humans to be motivated and interested in the thing. | 04:02 |
| jblack | want me to unpack that? | 04:02 |
| lifeless | Sure. | 04:02 |
| jblack | Ok. | 04:02 |
| jblack | simple revisions get reviewed quickly and often. | 04:02 |
| jblack | they are, after all, obvious. | 04:02 |
| jblack | difficult revisions don't. They get put off because they're difficult. "I'll dive into it later, after coffee...dinner...sleep...etc" | 04:03 |
| jblack | so the patch that needs review the most inevitably ends up getting reviewed the least. | 04:03 |
| jblack | So if we rely on a timer, we need to set the timer for the amount of time necessary to make sure the most difficult patches get looked at. | 04:03 |
| lifeless | no, we don't. | 04:03 |
| jblack | because if we set it towards the simle ones, the simple ones will fly by and get checked, but the tough ones won't. | 04:04 |
| lifeless | thats what I meant by overengineering. | 04:04 |
| lifeless | lets walk an example complex patch through. | 04:04 |
| lifeless | abentley's backbuilder for instance, which he is interested in getting into a mainline tree. | 04:04 |
| lifeless | he has to convince one of us to merge it. | 04:04 |
| jblack | atm, yes | 04:04 |
| lifeless | that means, that one of us has to give it a proper review before it goes in. | 04:05 |
| lifeless | if the reviewer doesn't feel 100%, they won't merge it. And they can ask someone else to help, or to co review. | 04:05 |
| jblack | Ok. Lets say we do that. | 04:05 |
| lifeless | we're all sensible people. You know when you need an extra pair of eyeballs to decide something. Trust in that, for yourself, and for the rest of us. | 04:05 |
| jblack | who's in charge of tracking that patch for review? | 04:06 |
| lifeless | whoever says to abentley 'I'll review that' | 04:06 |
| jblack | who's in charge of saying "nobody's merging this, so I need to chase it down to get somebody to say the buck stops here" | 04:06 |
| lifeless | abentley. | 04:06 |
| jblack | Ok. | 04:07 |
| jblack | so instead of me simplying doing mutt pqmaster@hbd.com -s "aaron.bently@panoramicfeedback.com--2004/baz--devo--1.0--patch-43 good", we're going to have people running around in a disorganized manner, seeking out patrons, and the patron seeking out super patrons, and so forth and so on? | 04:08 |
| lifeless | do you see my point? we can swamp ourselves in process when we have more committers - and thus more reviewers. I'm sure the community @ large will have an opinion by then. | 04:09 |
| lifeless | jblack: exactly. | 04:09 |
| jblack | Ok. Lets do it your way for now. | 04:09 |
| jblack | I think you'll change your mind eventually, though. :) | 04:09 |
| lifeless | in other news, I've done up a baz diff, heading towards the strawman cli's 'diff' | 04:12 |
| lifeless | (I needed something to hack on in the train :)) | 04:13 |
| lifeless | anyway, ddaa - you wanted to talk release process. | 04:13 |
| lifeless | lay it on me. | 04:13 |
| === ddaa reads backlog | ||
| ddaa | point on the discussion that just ended: jblack, I believe we can give a chance for the community to self-organize. | 04:15 |
| jblack | lifeless: I just had a crazy thought. :) | 04:15 |
| jblack | What if we stood pqm on its head. | 04:16 |
| jblack | Instead of waiting for merge commands, what if it scanned other trees, and if it saw a revision in more than X trees, it merged into -dev? | 04:16 |
| ddaa | lifeless: so, I was saying "we want a quick initial release and frequent releases after that". | 04:16 |
| jblack | I.E. if abentley's patch-5 shows up in my tree, and ddaa's tree, then pqm merges it, and it comes down the pipe to everyone else ? | 04:16 |
| lifeless | jblack: I think thats a cool idea, for crack of the day, but it shouldn't be the devo tree. | 04:17 |
| lifeless | that could be 'experimental' or 'premerged' or something. | 04:17 |
| jblack | reasoning? | 04:17 |
| lifeless | I want simple, but human. | 04:18 |
| jblack | ultimately, it is human. | 04:18 |
| lifeless | thats complex (heuristics) | 04:18 |
| jblack | It doesn't go in unless X number of trusted people already merged it locally. | 04:18 |
| lifeless | it also means you'd need to be using replay --skip-present as the merge operator. | 04:18 |
| ddaa | lifeless: I think a good feature goal for 1.0 whould have been "complete tla-1.2.2". Now jblack is merging the 1.2.3 stuff, so "what was in the pipe for 1.2.3" is still a good release goal to start with. A early release will give something to use and tag from to contributors. | 04:18 |
| ddaa | Also you said there is no release manager. So I wonder how we can make regular and reliable releases w/o that. | 04:19 |
| lifeless | ddaa: 'complete tla 1.2.2' would be a tla process dig. we're not going there. | 04:20 |
| lifeless | we may well need a release manager. but I haven't assigned one at this point. | 04:20 |
| ddaa | Mh. Not sure I understand... pragmatically that is the best thing to start with... | 04:20 |
| jblack | then I'm confused about what I'm supposed to be doing. | 04:21 |
| jblack | because I thought I was supposed to be reviewing for release. | 04:21 |
| lifeless | no, you are reviewing full stop. | 04:21 |
| ddaa | And "what would have been 1.2.3" is equally a "process dig". But ultimately baz itself is a "tla process dig". | 04:21 |
| lifeless | ddaa: we can avoid having that comparison drawn until we are an established meme, if we are careful | 04:22 |
| ddaa | So, you are saying "we are not making a release in the forseeable future"? | 04:22 |
| lifeless | I'm saying thatL | 04:22 |
| lifeless | bah | 04:22 |
| lifeless | I'm saying that: | 04:23 |
| lifeless | * I haven't thought deeply about release schedules etc. And I'm taking input from you guys right now. | 04:23 |
| ddaa | The GNU Arch community is totally ripe for accepting baz at the moment. I really think that's the good time for a release. Tell me that you disagree. | 04:23 |
| lifeless | We should also get some input from the arch community, and I'll email them to ask once we've bounced this around a little. | 04:24 |
| lifeless | one sec | 04:25 |
| ddaa | I assume that is going to have mostly good feedback. If I am correct, we could put out a RC in say, two weeks? | 04:25 |
| jblack | personally, I think we're in a fight against time. | 04:25 |
| ddaa | I do not think that's a fight against time. | 04:25 |
| lifeless | we are absolutely in a fight against time. | 04:25 |
| jblack | Tom's not going to stand by idly, regardless of the semantics you use. He's going to sabotage this. | 04:25 |
| lifeless | svn is gaining traction 'out there'. | 04:25 |
| jblack | That's what patch-log pruning was all about. | 04:25 |
| lifeless | even folk that love arch will spend an entire meeting bitching the UI, | 04:26 |
| ddaa | I just see that people in the community are waiting for someone to stand up. That's the Right Time. | 04:26 |
| lifeless | ddaa: releases don't make the difference here. patch merging does. | 04:26 |
| jblack | ddaa: Not in my experience. | 04:26 |
| === jblack agrees with lifeless | ||
| ddaa | jblack: I'm say that now is the time. Not that it was the time before. | 04:27 |
| lifeless | jblack did patch merging, and from what I saw, folk flocked to feed him patches. | 04:27 |
| ddaa | Bad. | 04:27 |
| ddaa | Bah | 04:27 |
| ddaa | Sorry typo. | 04:27 |
| ddaa | Because he was working on tla and they was seeing the release coming. | 04:27 |
| ddaa | Currently bas is vapor to the community. | 04:27 |
| lifeless | I'm willing to bet that if we did out first 'release' in 3 months, we'd have 50%-60% of the arch developers using and contributing to bazaar by then, and some large % of the community also. | 04:28 |
| ddaa | We put a release out and suddenly we are there and in good shape. | 04:28 |
| jblack | 3 months? | 04:28 |
| jblack | you want to wait until 2005 for a release? | 04:28 |
| lifeless | I'm not proposing that as such, I'm simply putting it out there: the release aspect is not the rush for us, right now. IMO the rush right now is the user interface. | 04:29 |
| ddaa | I'm willing to bet that if we make a release soon, either Tom amend his proposed release process or we have 80% of the devs in 3 months. | 04:29 |
| jblack | I want a release candidate by friday, and a release by the friday after. | 04:29 |
| lifeless | ddaa: releases have pros and cons. | 04:29 |
| ddaa | lifeless: I'm listening to you. | 04:30 |
| jblack | btw, you're both right. | 04:30 |
| jblack | Here's how | 04:30 |
| lifeless | when we do a 'release', expectations will be set about ... | 04:30 |
| === lifeless waits | ||
| ddaa | about? | 04:30 |
| jblack | release drive users. development drives developers to develop more. developers are also a subset of users. | 04:31 |
| lifeless | users will happily use auto-built binaries. ALL the tla users I know in SLUG here use asuffields daily builds. | 04:31 |
| lifeless | thats users: not developers. | 04:31 |
| jblack | lifeless: Ok. Well then, can you explain to me why the download rate for tla goes up *hugely* whenever a release or a release candidate goes up? | 04:32 |
| lifeless | thats probably me being rong. | 04:32 |
| lifeless | *wrong* | 04:32 |
| ddaa | I must be some kin of maniac then. I use releases almost exclusively. | 04:32 |
| jblack | ddaa: For normal use, so do I. | 04:32 |
| lifeless | ok, I'm convinced. we'll start releases soon. | 04:32 |
| === Kinnison uses whatever apt-get gives him :-) | ||
| lifeless | Lets define soon in a minute. | 04:33 |
| === lifeless paints Kinnison purple | ||
| ddaa | a VCS is something way too mission-critical to use "maybe broken" and untested versions of. | 04:33 |
| === Kinnison sneezes on lifeless | ||
| lifeless | I want our releases time based, with feature goals. | 04:34 |
| lifeless | let me explain why, and you can try to change my mind. | 04:34 |
| jblack | ddaa: Yeah. That's why I think the "lets hope review happens" dump-every-thing-in-the-tree-and-review-after-the-fact is a colosal screw up. | 04:34 |
| lifeless | time based gives users regularity, an expectation of when they can have a supported release with their per bugfix in it. | 04:34 |
| === ddaa is skeptical, time-based/feature-based seem to be a "pick one" choice. | ||
| lifeless | ddaa: we just released a freaking linux distro that was time based with feature goals. | 04:35 |
| lifeless | We've got a fantastic example of how to do it all around us. | 04:35 |
| ddaa | jblack: I can use a rc VCS with some precautions if I am not too much in a hurry. After he has passed the eyeballs test. | 04:35 |
| lifeless | the feature goals thing stops the developers freewheeling, in a positive way. | 04:36 |
| ddaa | *after it | 04:36 |
| jblack | lifeless: We're not doing a gnome app here. We're doing a revision control system. One archive eating bug sneaks into a release, and we'll pay *dearly* | 04:36 |
| jblack | In fact, we'll prove to the community that Tom's snail pace is correct. | 04:36 |
| lifeless | dude, tom has released more archive eating bugs in tla than anyone else. | 04:36 |
| lifeless | (thats 2, IIRC). | 04:37 |
| ddaa | lifeless: you may have noticed that several feature goals have been backed out to honor the deadline... | 04:37 |
| lifeless | ddaa: true. thats why its 1) time based, 2) feature goals. | 04:37 |
| jblack | lifeless: I think the method you want will have more, not less. | 04:38 |
| ddaa | Mh... so it's time-based to decide what to put in or not, with feature goals to set priorities? | 04:38 |
| spiv | ddaa: Yes, that's the point... they're goals, they give direction to development, but the deadline is still the priority. That's my understanding :) | 04:38 |
| jblack | They'll pick "2 over 2 years" over "3 in six months" | 04:38 |
| lifeless | ddaa: exactly. | 04:39 |
| spiv | (and because the next release already has a deadline in the not-too distant future, pushing a feature back one release doesn't hurt too badly) | 04:39 |
| lifeless | jblack: we've a track record of 0 releases so far. give me some credit as project lead ok? I'm not using this to exercise random project theories. | 04:39 |
| ddaa | jblack: I think there are enough arch saviness and paranoia among the three of us that if we all say "I'm sure there is no archive-damage bug" we stand against pretty good odds. | 04:39 |
| jblack | lifeless: Just so long as you understand that I'm not making any guarantees on the process you've setup. | 04:40 |
| ddaa | s/three/four/ | 04:40 |
| ddaa | lifeless: okay, about the time-then-features. | 04:40 |
| lifeless | jblack: if you do what I've asked, I will be happy. | 04:41 |
| jblack | I'll try my best. | 04:41 |
| ddaa | So, about the first release. When and what? | 04:41 |
| lifeless | so in 3 weeks we hit london for a two week sprint. | 04:41 |
| lifeless | I think a good time for the first release is in 5 weeks. | 04:41 |
| === ddaa notes that soon has an interesting value there... | ||
| lifeless | that gives us time to get a couple of small but significant features in play, get some traction in the arch developers, and be confident in what goes out. | 04:42 |
| ddaa | I am not really convinced that a sprint is the right way to put out a _release_ | 04:42 |
| lifeless | ddaa: 3 weeks from a cold start means, if we do 50-50 code & stabilise, 1.5 weeks to do code in. | 04:43 |
| === ddaa stands on his position that just merging what's almost ready is a good thing to do in the first release. | ||
| lifeless | if we do 66-33, thats 2 to code in. | 04:43 |
| lifeless | ddaa: that would send a very wrong message. | 04:44 |
| Kinnison | it'd send a bad msg. regarding the ui | 04:44 |
| lifeless | miles bader asked 'what is baz, it looks just like tla'. | 04:44 |
| Kinnison | our first release *must* be visibly and palpably different in the UI front | 04:44 |
| ddaa | ack | 04:44 |
| === BradB|away is now known as BradB | ||
| jblack | so what if he asked that? | 04:44 |
| jblack | He won't be asking that for wrong. | 04:45 |
| ddaa | Okay. I buy that we need to change the color of the bike shed first. | 04:45 |
| jblack | for long | 04:45 |
| Kinnison | so three weeks to merge stuff and stabilise; then a two week sprint to sort the UI out; release-candidate at the end of the sprint... one week... release ? | 04:45 |
| Kinnison | (says he, rambling entirely uninformed :-) | 04:45 |
| lifeless | ddaa: we need to change the bike sheds size and shape, f*ck the colour. | 04:45 |
| lifeless | jblack: sure, my point is our first release is a statement about our conviction to our mission. | 04:46 |
| ddaa | So. What is the release goal you have in mind, in addition to jblack's backlog? | 04:46 |
| lifeless | Kinnison: 5 week schedule would be '3 weeks code like crazy, 2 weeks to sort out any issues, release at the end'. | 04:46 |
| lifeless | @ the sprint, we'd be working on the next release after. | 04:47 |
| ddaa | I'd think something that would set it straight would be reorganizing the UI> | 04:47 |
| lifeless | ddaa: right. | 04:47 |
| jblack | Night. | 04:47 |
| ddaa | I mean the command set. | 04:47 |
| ddaa | Fewer, more relevent commands with options. | 04:47 |
| lifeless | jblack: ok, night. looks like we'll have a straw man release process before long... | 04:48 |
| Kinnison | lifeless: I think the "rc, wait 1 week, stamp the official release" process is good | 04:48 |
| ddaa | e.g. "baz cat-log [-d DIR] [--library|--archive] [spec] " where spec can be a simple patchlevel if the directory is within a tree. | 04:48 |
| lifeless | library vs archive shouldn't be there. | 04:49 |
| ddaa | stuff like that... | 04:49 |
| lifeless | it should just work. | 04:49 |
| lifeless | but yes. | 04:49 |
| ddaa | Low risk. | 04:49 |
| lifeless | nuke cat-archive-log. | 04:49 |
| ddaa | the log from the archive can me different from the log in the library can be different from the tree. | 04:50 |
| ddaa | So we need all the options. | 04:50 |
| lifeless | actually, we don't. library is by definition == archive, or the library is corrupt. | 04:51 |
| ddaa | They _should_ not be different, but the devil is already out of the box. | 04:51 |
| ddaa | Except logs can be mutated. | 04:51 |
| lifeless | oh damn, .. | 04:51 |
| lifeless | forgot about cached log vs log in resulting tree. | 04:51 |
| ddaa | Mh... | 04:52 |
| ddaa | you are correct about archive/lib btw... | 04:52 |
| ddaa | So, there is still the need for one option... --canonical... errr scrap that! | 04:53 |
| lifeless | lol | 04:53 |
| ddaa | --revlog ? | 04:53 |
| lifeless | yeah | 04:53 |
| ddaa | Well... we agree on the general direction. | 04:53 |
| ddaa | We can hammer out the specific with our pool of very demanding users. | 04:54 |
| === ddaa radiates enthusions | ||
| lifeless | baz log [-r spec] [--archive] [path] | 04:55 |
| lifeless | is what I would propose | 04:55 |
| === Kinnison absorbs some of the enthusions and slowly becomes interested in the world again | ||
| Kinnison | lifeless: yay, simple short command names rock | 04:55 |
| Kinnison | lifeless: if baz could end up feeling as easy to use as perforce does, then it'd be ace | 04:55 |
| lifeless | Kinnison: show me perforce some time | 04:55 |
| ddaa | lifeless: log would be confusing with logs. And the spec is the commonly used argument. | 04:55 |
| lifeless | ddaa: in tla. | 04:56 |
| Kinnison | lifeless: I could come down to london in the middle of the arch sprint and show you if you like | 04:56 |
| Kinnison | lifeless: at the w/e | 04:56 |
| lifeless | Kinnison: love to have you | 04:56 |
| lifeless | rock up | 04:56 |
| === cprov [~cprov@200.158.100.251] has joined #launchpad | ||
| lifeless | ddaa: use case : show me the logs for 'configure.ac' | 04:56 |
| ddaa | lifeless: If we need to hammer out all the uses cases, we are not going to make it. | 04:56 |
| lifeless | ddaa: the simplearchcli page has a huge number already hammered out. | 04:57 |
| lifeless | we could take a couple of commands, and just /do those/. | 04:57 |
| ddaa | use case: show me the details of patch-42 | 04:57 |
| ddaa | in your use case, --archive is superfluous | 04:58 |
| lifeless | ddaa: yes, but its needed because tlas semantics on {arch} are problematic. | 04:59 |
| ddaa | and maybe my use case could use a "revlog" command instead. | 04:59 |
| lifeless | so, your use case: | 04:59 |
| ddaa | They are clear to me. | 04:59 |
| lifeless | baz log -r patch-42 | 04:59 |
| lifeless | my use case: | 04:59 |
| lifeless | baz log configure.ac | 04:59 |
| lifeless | baz log [-r spec] [--archive] [path ...] | 04:59 |
| lifeless | is actually better. | 04:59 |
| ddaa | confusing | 05:00 |
| lifeless | baz log configure.ac Makefile.am - shows logs for all revisions that alter either of the two. | 05:00 |
| ddaa | --archive is not relevant to path and -r and path together do not make sense. | 05:00 |
| lifeless | -r and path do so make sense. | 05:00 |
| ddaa | We want overloading, but not abusively | 05:00 |
| lifeless | if the path is not altered in that log, nothing would be shown. | 05:01 |
| ddaa | mh... | 05:01 |
| ddaa | BTW, I fear I'm going to miss my promise of supporting baz in pyarch for monday. | 05:02 |
| lifeless | ok. | 05:02 |
| ddaa | It turned out that it was great time to do some heavy duty refactoring. | 05:02 |
| lifeless | no problemo. | 05:02 |
| ddaa | I'm taking baby steps, this stuff is totally hairy. | 05:03 |
| lifeless | so heres a point. revisions -s is really useful. | 05:03 |
| lifeless | is it better to do | 05:03 |
| ddaa | yup | 05:03 |
| ddaa | logs -s is really useful too | 05:03 |
| lifeless | baz log -r patch-1 -r patch-4 -s ? | 05:03 |
| lifeless | or have the separate revisions command ? | 05:03 |
| ddaa | I think we need to make it clear that tree patchlogs are a different thing, structurally, than archive patchlogs... | 05:04 |
| lifeless | right, thats why --archive is there. | 05:04 |
| lifeless | '--archive show the archive logs, rather than the cached log for the selected logs' | 05:05 |
| ddaa | baz logs -a -s | 05:05 |
| lifeless | would show all the logs making up the code base, in summary version, from the archive. | 05:06 |
| lifeless | (if it was baz log :)) | 05:06 |
| ddaa | equivalent of "tla revisions -s `tla tree-version`" | 05:06 |
| lifeless | right. | 05:06 |
| ddaa | maybe you want "baz log" instead... | 05:06 |
| ddaa | "logs" is muscle memory for me... | 05:07 |
| lifeless | aliases :) | 05:07 |
| Kinnison | aliases will be implemented as something in .arch-params ? | 05:07 |
| ddaa | though... logs makes a nice shortcut for "tla logs -s" in tlash... | 05:07 |
| lifeless | % baz log [-r package [-r package2] ] [-d date [-d date2] ] [-a|--archive] [-s|--summary] [file_or_directory ...] | 05:07 |
| lifeless | the requirement for tlash is a bug in tla | 05:07 |
| lifeless | the above strawman is the proposed log from the simplearchcli page. | 05:08 |
| ddaa | I need to have some time aside to exercise my annoyance skills on that stuff. | 05:08 |
| lifeless | :) | 05:09 |
| ddaa | for example, I do not like multiple -r options. | 05:09 |
| ddaa | What if the versions are different? | 05:09 |
| lifeless | then we traverse the tag | 05:09 |
| ddaa | I'd rather like an interval notation, a la abrowse | 05:09 |
| Kinnison | cvs/svn/p4 people are used to multiple -r arguments | 05:09 |
| ddaa | spec..spec | 05:10 |
| ddaa | where the vsn of the second spec defaults to the vsn of the first | 05:10 |
| lifeless | ddaa: thats harder for scripters, and harder to parse. | 05:10 |
| ddaa | scripters can give both versions explicitely | 05:10 |
| ddaa | And of course the version of the first defaults to the tree-version | 05:10 |
| lifeless | but they can't do '$first $second' and just define second when needed, as trivially. | 05:11 |
| ddaa | I'm not concerned with "harder to implement" at this point, just "easier to use". | 05:11 |
| lifeless | ddaa: agreed. | 05:11 |
| === ddaa tries to figure out what lifeless means | ||
| lifeless | Kinnisons point is also very valid, there is a huge body of knowledge in muscle memory in cvs commands. | 05:12 |
| === ddaa goes to fetch coke | ||
| spiv | lifeless: I thought svn used an interval notation, e.g. -r111:222 | 05:12 |
| lifeless | spiv: it does. | 05:13 |
| spiv | Yeah, svn doesn't use multiple -r args that I can see, it just allows intervals to be passed to -r. | 05:13 |
| lifeless | spiv: that has an annoying property under the hood. | 05:14 |
| lifeless | commands then parse this and barf wwhen they didn't want a range. | 05:14 |
| lifeless | I think from a ui perspective, that -r -r is actually easier. | 05:14 |
| spiv | I don't feel strongly either way here, I'm just giving a data point :) | 05:15 |
| lifeless | ddaa: please do contribute to the wiki page. I plan to move it to the public wiki soon as well. | 05:15 |
| spiv | I think overloading -r to accept ranges sometmes is eqaually bad as overloading it to mean a range when it's specified twice. | 05:15 |
| spiv | :) | 05:16 |
| lifeless | spiv: hmm. | 05:16 |
| lifeless | technically, its not overloaded to mean a range :). | 05:16 |
| lifeless | each -r specifies a point. | 05:16 |
| spiv | What does that mean? :) | 05:17 |
| lifeless | saying that -r -r is overloading is like saying Rectangle(Point(), Point()) is overloading Point(). | 05:17 |
| === ddaa comes back with coke and nutella... | ||
| spiv | Well, in the sense that -r means different things depending on whether it's the first or second -r... makes writing docs annoying. | 05:17 |
| lifeless | spiv: thats the point, it doesn't mean different things. | 05:17 |
| spiv | "If this is the first -r, then it means this, but if it's the second it means this" | 05:18 |
| Kinnison | the form: "baz diff -r patch-100 -d yesterday" should work | 05:18 |
| lifeless | Kinnison: yes, absolutely. | 05:18 |
| lifeless | but -r patch-50 -r patch-200 -d yesterday | 05:18 |
| lifeless | is more useful :) | 05:18 |
| Kinnison | Oooh 3-way diffing | 05:18 |
| Kinnison | mmmm | 05:18 |
| Kinnison | meld! | 05:18 |
| lifeless | well, just intersection. | 05:19 |
| spiv | Forgive my weak cvs-fu, but what would two -rs and a -d mean? :) | 05:19 |
| ddaa | spiv++ | 05:19 |
| spiv | (I was actually a pretty limited user of cvs.) | 05:19 |
| lifeless | spiv: dunno about cvs, but I'd *expect* it to do the intersection of the two ranges. | 05:20 |
| ddaa | lifeless: when you first wrote the multiple -r command, I thought it was a way to specify multiple exact revisions. | 05:20 |
| ddaa | not a way to specify a range... | 05:20 |
| spiv | lifeless: Which two ranges? I can guess at multiple interpretations. | 05:20 |
| lifeless | https://wiki.canonical.com/SimpleArchCli?action=show | 05:21 |
| lifeless | read the Log section | 05:21 |
| spiv | (I'm not saying it's a bad idea, I'm just being curious) | 05:21 |
| spiv | Ta. | 05:21 |
| ddaa | monkeying cvs is so not the right to do | 05:21 |
| ddaa | Even as tla is know, people keep doing and expecting things that are completely inappropriate because their brain is cvs-washed. We do not _need_ to encourage the confusion. | 05:22 |
| lifeless | ddaa: actually, we do. | 05:22 |
| lifeless | here's why. | 05:22 |
| lifeless | we want as many folk as possible at the peak of arch knowledge and skill. | 05:23 |
| spiv | lifeless: Hmm, it doesn't give an example of multiple -r options... and it seems to use -r as a way to specify a version? | 05:23 |
| lifeless | that means that the learning curve must be approachable at all levels. | 05:23 |
| lifeless | any point of insane steepness will dramatically drop the # of folk that traverse the entire path. | 05:24 |
| ddaa | lifeless: I follow you so far | 05:24 |
| lifeless | CVS has a very simple model. | 05:24 |
| lifeless | We need the basic interface to baz to present a simplified model. | 05:24 |
| lifeless | And to encourage and support folk working with more and more complex facilities. | 05:24 |
| ddaa | you want "baz update foo.c" do the same stupid thing as cvs does? | 05:25 |
| lifeless | not necessarily. | 05:25 |
| ddaa | Because that's a pretty common expectation. | 05:25 |
| lifeless | tla update is just about right. | 05:25 |
| ddaa | I reckon that simple things needs to be simple. | 05:25 |
| lifeless | cvs update -Pd is used to restore a file that is missing. | 05:25 |
| lifeless | and thats the usual expectation that update foo.c usually appears in IIRC. | 05:26 |
| ddaa | And not gratuitously different from established practise. | 05:26 |
| ddaa | lifeless: yes | 05:26 |
| ddaa | However, users should be pushed at reading the damn --help output for any operation which is not done 10 times a day. | 05:27 |
| lifeless | so, update, needs some thought, but I'm inclined to have it restore foo.c, IF: the file is missing (not tla renamed). | 05:27 |
| ddaa | lifeless: that's a job for undo and you know it. | 05:27 |
| lifeless | ddaa: UI UI UI. | 05:27 |
| spiv | (oi oi oi!) | 05:27 |
| lifeless | baz baz baz! | 05:28 |
| ddaa | Yes. We do not want update to restore a file to the pristive version, ever. | 05:28 |
| ddaa | That's what undo is for. | 05:28 |
| lifeless | we need to deliver what users need though. | 05:28 |
| lifeless | this is a balancing act. | 05:28 |
| ddaa | I understand. The first thing user need is a consistent UI. | 05:28 |
| ddaa | The second thing is a familiar UI> | 05:29 |
| ddaa | The third thing is a concise UI. | 05:29 |
| lifeless | perhaps actually, I'd reverse those priorities. | 05:29 |
| lifeless | familiar, concise, consistent. | 05:29 |
| ddaa | The last is a powerful UI. | 05:29 |
| ddaa | I so disagree. | 05:29 |
| lifeless | emacs is consistent, so why does it have a vim emulation mode ? | 05:30 |
| lifeless | ddaa: join the wiki page. | 05:30 |
| ddaa | Will do once I run out of fuel on the pyarch stuff. | 05:30 |
| ddaa | btw, I was still not able to test taxi.py | 05:30 |
| lifeless | :[ | 05:31 |
| spiv | ("rm somefile; svn update somefile" will restore the pristine copy of somefile, if you're wondering) | 05:31 |
| ddaa | The debug logging is considerably slowing stuff down, it seems. | 05:31 |
| spiv | (even though "svn revert somefile" will do it too (and faster?)) | 05:31 |
| ddaa | Dunno what to do. If I disable debug logging, it is certainly going to hang according to murphy. | 05:31 |
| ddaa | Prolly, I should use a known-good and short project... | 05:32 |
| ddaa | like x-fonts-thai-ttf... | 05:33 |
| spiv | ddaa: Run it without debugging, use gdb? | 05:33 |
| ddaa | spiv: ? | 05:33 |
| spiv | (use gdb once it hangs) | 05:33 |
| ddaa | how is gdb useful to debug python code? | 05:33 |
| lifeless | spiv: page updated | 05:34 |
| spiv | There are hacks that let you get a python backtrace via gdb macros. | 05:34 |
| ddaa | and btw, is there a python with debugging symbols in ubuntu? | 05:34 |
| spiv | (And there are some hacks in dist/src/Misc/gdbinit in python cvs) | 05:34 |
| spiv | Not that I know of :/ | 05:34 |
| ddaa | spiv: your mission, shall you accept it, is to document that for the benefit of the buildbot-debug staff. | 05:35 |
| ddaa | I can rebuild python. That's not a big issue. | 05:35 |
| lifeless | ok, here's my proposal for release process. | 05:36 |
| lifeless | release date: 5 weeks. | 05:36 |
| ddaa | spiv: please | 05:36 |
| lifeless | bah | 05:36 |
| lifeless | release date: 3 weeks. | 05:36 |
| ddaa | lifeless: that's not a date | 05:36 |
| lifeless | 2 weeks coding. | 05:36 |
| lifeless | 1 week release candidate. | 05:36 |
| lifeless | then we start a new cycle @ the start of the sprint. | 05:37 |
| lifeless | feature goals: | 05:37 |
| spiv | ddaa: Ok, I might write up a HeavyDutyPythonDebugging page or something. | 05:37 |
| lifeless | implement 3 of the revamped commands in simplearchcli | 05:37 |
| ddaa | spiv: thank you very much, that would help a lot. | 05:37 |
| lifeless | fix 2 of the arch gripes. | 05:37 |
| spiv | (I don't have much experience here either, but I'll jot down what I know) | 05:38 |
| lifeless | in terms of release management, I'll do that. but release management != code review. | 05:38 |
| lifeless | what do you think? | 05:39 |
| ddaa | Dunno. | 05:40 |
| ddaa | Not qualified to judge that. | 05:40 |
| ddaa | Never hacked tla. | 05:40 |
| ddaa | BTW | 05:40 |
| ddaa | What about the imports? | 05:40 |
| ddaa | That is sort of a very time consuming and very urgent task... | 05:41 |
| lifeless | ddaa: yes, and its my primary focus. I'll be hacking on that all weekend. | 05:41 |
| lifeless | baz is parallel urgency, no point having archives no one can stand using. | 05:41 |
| ddaa | Okay. Let's call that over. | 05:41 |
| BradB | Sorry for the random, I-slept-in-this-morning sniping, but I'm really hoping this rewrite considers Apple HFS+ performance tips: http://tinyurl.com/5qupk | 05:41 |
| BradB | s/Apple/OS X/ | 05:42 |
| ddaa | lifeless: very good point... | 05:42 |
| BradB | I can give you guys an account on my new machine, if needed. | 05:42 |
| ddaa | BradB: the focus of this release is not performance, sorry. | 05:42 |
| BradB | ok | 05:43 |
| ddaa | But I'll bookmark it once I can see it... | 05:43 |
| lifeless | heh, we're getting traction: | 05:43 |
| lifeless | The devel versions of tla and baz already have fixes for | 05:43 |
| lifeless | get-changeset, so that issue is likely fixed. If not, you'll probably | 05:43 |
| lifeless | have to rewrite your patch anyhow. | 05:43 |
| lifeless | thats a quote from abentleys latest email to -users :) | 05:43 |
| ddaa | abentley is already sold to us. | 05:43 |
| ddaa | That's going to be a considerable edge :-) | 05:44 |
| lifeless | BradB: there are several things to answer your request. | 05:45 |
| ddaa | I mean, he did not tell me that. | 05:45 |
| lifeless | firstly, none of us use macOS X. | 05:45 |
| ddaa | But as far as I know him, I believe he just want to ride the non-stalled train out the dark tunnel. | 05:45 |
| lifeless | secondly, performance is a UI metric. Its a factor, but not a feature goal in v1.0 | 05:45 |
| lifeless | thirdly, a profile-run of tla giving us detailed breakdowns on the major speed overheads on macos X would be a good start. | 05:46 |
| lifeless | you can build that by exporting CFLAGS='-pg -O2' | 05:47 |
| BradB | lifeless: "us" being whom? | 05:47 |
| lifeless | me, jblack, bob2, ddaaa | 05:47 |
| Kinnison | BradB: the Bazaar team | 05:47 |
| lifeless | the arch team. | 05:47 |
| lifeless | here @ canonical. | 05:47 |
| Kinnison | BradB: also known as the 'Bizarre' team | 05:47 |
| lifeless | 'how bazaar, how bazaar' | 05:47 |
| BradB | lifeless: yeah, that's why i've offered an account on my machine. I don't have the time to actual do any work on this myself. | 05:47 |
| lifeless | BradB: so, our goals will roughly be 'make it work, make it work right, make it work fast'. I'm not discounting your performance needs, but there are other serious issues that need to be addressed ASAP. | 05:48 |
| BradB | sure | 05:48 |
| lifeless | for example, potential archive corruption because of macos X's default HFS+ configuration. | 05:49 |
| BradB | case sensitivity, you mean? | 05:49 |
| lifeless | yup | 05:49 |
| BradB | er, insensitivty, but yeah, same difference | 05:49 |
| lifeless | case sensitivity is UI, should /not/ be a core property, and apples decision there was/is a PITA. | 05:49 |
| BradB | lifeless: eh, that's a windows thing too | 05:50 |
| BradB | lifeless: and mark will happily agree that fs case *sensitivity* is insane. :) | 05:50 |
| lifeless | BradB: NTFS is able, without being reformatted, to be case sensitive, case preserving. | 05:50 |
| BradB | HFS+ isn't able to at all. | 05:50 |
| lifeless | on windows thats just a file open flag. | 05:50 |
| ddaa | lifeless: Name suggestion request. I am making a arch.backends module with all sorts of stuff (cli info, process handling, logging, etc), and I keep spelling it arch.backend. But I also want to have a arch.backend object which is the glue object used by the high-level bindings. Any idea how to rename/reorganize things? | 05:51 |
| ddaa | * a arch.backends package | 05:51 |
| lifeless | BradB: for a UI, case sensitivity is bad. For a file system, case insensitivity is bad. | 05:51 |
| BradB | lifeless: it's only a pita if you wrote it without that in mind. | 05:51 |
| lifeless | BradB: HFS+ can do case sensitive just fine, just gotta reformat it :). | 05:51 |
| lifeless | BradB: I'm not really interested in having this argument right now. I've won it every time I've had it, but its 2am. | 05:52 |
| BradB | lifeless: nope, HFS+ is always case insensitive. | 05:52 |
| BradB | http://developer.apple.com/documentation/MacOSX/Conceptual/BPFileSystem/index.html | 05:53 |
| lifeless | BradB: apples documentation differs. | 05:53 |
| BradB | lifeless: you're thinking of UFS. | 05:53 |
| BradB | which Doesn't Work on OS X, really. | 05:53 |
| lifeless | no, I'm not. | 05:53 |
| BradB | ok, well, i've pasted an apple link that concurs with what i say, i can't do anymore before this turns into bikeshedding. :) | 05:54 |
| lifeless | http://lists.apple.com/archives/macos-x-server/2004/May/msg01479.html | 05:54 |
| lifeless | BradB: I climbed through all the apple doco on this when researching the issues with tla & case sensitive/insensitive ~ 1 year back. | 05:55 |
| lifeless | note ""Case-sensitive HFS+" | 05:55 |
| Kinnison | You can't have Case-sensitive Journalled HFS+ afaict though | 05:55 |
| lifeless | http://www.codepoetry.net/archives/2003/10/26/casesensitive_hfs_for_the_masses.php | 05:56 |
| Kinnison | elmo: ping | 05:56 |
| BradB | lifeless: dude, i pasted an apple documentation link. if they're wrong, i'm not sure how to defend that. :) | 05:57 |
| lifeless | I'm willing to accept if I'm wrong... but so far, I've seen nothing to indicate I am wrong. | 05:57 |
| lifeless | that doco link only documents hfs+'s default behaviour | 05:57 |
| lifeless | there are extensions to it introduced by apple in OS X updates. | 05:58 |
| === debonzi is now known as debonzi|lunch | ||
| lifeless | BradB: http://developer.apple.com/technotes/tn/tn1150.html#HFSX | 05:59 |
| lifeless | so technically, its HFSX I'm talking about. | 05:59 |
| BradB | baz has to work on a case-insensitive fs because no matter what fs's os x can do, and what can be formatted to be case-sensitive or not, os x in general just Doesn't Work with case sensitivity (according to limi, anyway) | 05:59 |
| carlos | cprov, debonzi: Could you give me an easy way to get the list of source packages that are inside Ubuntu warty? | 05:59 |
| lifeless | BradB: I'm not debating that at all. | 06:00 |
| BradB | ok, then let's stop wasting time on this. :) | 06:00 |
| carlos | cprov, debonzi|lunch: I'm a bit lost with all DB objects | 06:00 |
| lifeless | You made two assertions, one is factual and trivial to refute, which I've done. the other is opinion, and I'm not debating that right now. | 06:00 |
| lifeless | baz's requirements are a completely different ballgame :) | 06:00 |
| cprov | carlos: sorry, I didn't understand .. | 06:02 |
| cprov | carlos: are you using soyuz ? | 06:02 |
| carlos | cprov: I'm looking at it | 06:02 |
| debonzi|lunch | carlos, just a moment | 06:02 |
| cprov | carlos: do you want a query ? | 06:02 |
| carlos | cprov: I need to get the list of SourcePackageRelease that are inside a concrete distribution release (for instance, warty) | 06:03 |
| debonzi|lunch | carlos, from canonical.launchpad.database import SourcePackageRelease | 06:03 |
| carlos | cprov: well, a query will help me to map that into sqlobjects, yes | 06:03 |
| debonzi|lunch | my_list = SourcePackageRelease.getReleases(distroreleaseSQLObject) | 06:04 |
| carlos | debonzi|lunch: that's all? | 06:05 |
| carlos | hmmm | 06:05 |
| debonzi|lunch | should be | 06:05 |
| cprov | carlos: nop, we have it inside database/sourcepackage.py already done, I think | 06:05 |
| carlos | it's simple | 06:05 |
| carlos | thanks | 06:05 |
| debonzi|lunch | carlos, Im going for lunch.. if you have problems with it send me a mail | 06:06 |
| debonzi|lunch | carlos, Ill be back soon | 06:06 |
| carlos | debonzi|lunch: sure, thank you | 06:06 |
| === BradB discovers with glee another cup of coffee in the coffee machine | ||
| BradB | carlos: I noticed that you didn't get any response on-list about your proposed DB schema changes. It might move along quicker if you use the process Mark suggested: https://wiki.canonical.com/DatabaseSchemaChanges | 06:35 |
| carlos | BradB: didn't know about it, thanks for the suggestion | 06:36 |
| BradB | no prob | 06:36 |
| carlos | hmmm | 06:37 |
| carlos | BradB: well, it's not exactly the same case, I need that daf/Mark validate it before I request the change to Stub | 06:38 |
| carlos | the main "problem" is that both are more offline than online this week | 06:39 |
| BradB | daf is getting overwhelmed by life in NYC, or what? :P | 06:39 |
| carlos | BradB: I think he's trying to visit the whole city before leaving it :-) | 06:41 |
| BradB | awesome | 06:41 |
| === BradB is now known as BradB|lunch | ||
| === debonzi|lunch is now known as debonzi | ||
| carlos | debonzi, cprov: about: | 07:02 |
| carlos | # FIXME: (distinct_query) Daniel Debonzi - 2004-10-13 | 07:02 |
| carlos | # the results are NOT UNIQUE (DISTINCT) | 07:02 |
| carlos | I think we had a similar problem in Rosetta and Lalo fixed it using a Set | 07:03 |
| carlos | (with a note to remove it when the DISTINCT problem is fixed in SQLObject) | 07:03 |
| debonzi | carlos, yes.. we use it sometime.. but look | 07:06 |
| debonzi | supose we have a set of sourcepackagerelease and 10 of them have the same sourcepackage | 07:07 |
| debonzi | I want it to be distinct by sourcepackage.. can you see that Set does not solve it? | 07:08 |
| debonzi | thats the point :).. but thanks anyway | 07:08 |
| carlos | I see your point | 07:08 |
| carlos | we need to fix sqlobject soon :-P | 07:09 |
| debonzi | :) | 07:09 |
| carlos | debonzi, cprov: Another suggestion, is it possible to give a public API that gives SQLObjects instead of the string at builddepends | 07:14 |
| carlos | so I don't need to use python-apt O:-) | 07:14 |
| cprov | carlos: Set() sucks !!! | 08:01 |
| carlos | cprov: :-) | 08:01 |
| cprov | carlos: python-apt is a serious problem, but do you really thinks it is a problem to linux users ? for Mac OS it is, for sure | 08:02 |
| carlos | cprov: I mean that I don't want to use it directly, if we use it inside a method I don't see it :-) | 08:03 |
| carlos | cprov: I have a script to get the warty packages using it since some weeks ago | 08:03 |
| cprov | carlos: about the DISTINCT, yet, we should have it on SQLO soon (distinctBy=<fieldname>) | 08:03 |
| carlos | I'm moving it to use soyuz data now | 08:04 |
| carlos | so I know it sucks :-) | 08:04 |
| === daf_ [daf@muse.19inch.net] has joined #launchpad | ||
| === BradB|lunch is now known as BradB | ||
| cprov | carlos: We are not using your approach in DB, since we have text dependencies, but would be nice to have it in a table SRCdeps & BINdeps, there we will have coerent .deb deps | 08:11 |
| carlos | cprov: I know, that's why I'm suggesting a public method that does it so we have it done in a concrete place instead of needing to do it everytime from external scripts (like mine), I know that you do it also inside soyuz code so we could reuse that code easily | 08:15 |
| carlos | don't think is needed to change the database schema for it | 08:15 |
| === daf_ is now known as daf | ||
| cprov | carlos: ehe, maybe was flying a bit :) but your suggestion is not implemented inside soyuz, we just parser DEPS to build links not for the SQLO | 08:20 |
| === dilys [daf@muse.19inch.net] has joined #launchpad | ||
| carlos | cprov: well, it's more or less what I need | 08:21 |
| carlos | cprov: I just need to know if the package depends on 'cdbs' | 08:21 |
| carlos | BradB: do you have rights to relaunch the Rosetta alpha server? | 08:23 |
| BradB | i'm only handling the dogfood app. daf was the one who deployed the rosetta alpha (which I know sabdfl wasn't folded into the dogfood app soonish, dunno what your guys' timeline for that is though.) | 08:28 |
| BradB | s/wasn't folded/wants folded/ | 08:28 |
| carlos | BradB: I know that | 08:30 |
| carlos | is just that the alpha server is down | 08:30 |
| carlos | and I need someone to relaunch it :-) | 08:30 |
| carlos | and Daf is not available at the moment | 08:31 |
| cprov | carlos: ask daf !!! he has joined some minutes ago ( idle 00:11:56) | 08:32 |
| carlos | cprov: that's his irc session | 08:32 |
| carlos | cprov: but he's not online | 08:32 |
| carlos | he has it always online | 08:32 |
| carlos | with screen from his server | 08:33 |
| cprov | carlos: if you look on sql.py, we will see our depContainer() = {'srcpkgname', 'version', 'operator'} | 08:33 |
| === daf is around | ||
| BradB | carlos: ask elmo to give you an account on mawson. i know nothing about the rosetta alpha. | 08:35 |
| cprov | carlos: it's not that difficult to turn is in a new container sqlodepcontainer = {SourcePackageRelease, 'operator'} | 08:35 |
| carlos | daf: !! | 08:35 |
| carlos | :-D | 08:35 |
| carlos | daf: you are offline in jabber O:-) | 08:35 |
| carlos | well, Away | 08:36 |
| carlos | cprov: don't worry, I'm still looking at it, if get a concrete proposal I will mail launchpad | 08:36 |
| carlos | daf: Jordi told me that the alpha server is down | 08:37 |
| carlos | daf: could you execute it ? | 08:37 |
| daf | hmm | 08:37 |
| daf | I'll take a look | 08:37 |
| carlos | daf: thanks | 08:44 |
| daf | ok, Launchpad is running | 08:44 |
| daf | looks like the certificate is borked, though | 08:44 |
| carlos | daf: should we ask elmo? | 08:49 |
| daf | I suppose so | 08:51 |
| daf | basically, the problem is that the certificate for rosetta.sf.o is for mawson.u.c | 08:51 |
| daf | wrong hostname | 08:51 |
| BradB | mdz: ping | 08:52 |
| === daf foods | ||
| mdz | BradB: pong | 08:54 |
| BradB | mdz: so i'll be adding a "note" field to assignments (product and package). should infestations have notes too? | 08:55 |
| mdz | BradB: have you reviewed this with Mark? | 08:56 |
| mdz | I know he wants to be rather cautious with changes to the data model | 08:56 |
| BradB | yeah, i haven't reviewed it, but there's nothing to review if you don't think it's necessary. | 08:56 |
| BradB | there's a small process to follow to get new schema changes approved/added, which would have been my next step. | 08:56 |
| BradB | s/haven't reviewed it/haven't review it with mark/ | 08:59 |
| dilys | Merge to rocketfuel@canonical.com/launchpad--devel--0: added labels for comment fields on the bug index form and fixed all the dreadful id = 1 hardcoding for owner and creator ID's (patch-716) | 09:53 |
| === cprov [~cprov@200.158.100.251] has joined #launchpad | ||
| === mdz [~mdz@69-167-148-207.vnnyca.adelphia.net] has joined #launchpad | ||
| BradB | mdz: So what was your answer re: wanting notes on infestations? | 10:18 |
| mdz | BradB: let's wait and see | 10:18 |
| BradB | ok | 10:18 |
| mdz | the thing which is crucial for us is the additional status data (forwarded upstream, needinfo, etc.) | 10:19 |
| mdz | but Mark was against adding those as states | 10:19 |
| BradB | hm, interesting | 10:19 |
| === salgado [~salgado@200-206-134-238.async.com.br] has joined #launchpad | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!