[12:16] Merge to rocketfuel@canonical.com/launchpad--devel--0: pagetests updated, but still failling locally (patch-712) [12:34] Merge to rocketfuel@canonical.com/launchpad--devel--0: Mostly page fixes. Include bug #2144 (patch-713) [12:36] thanks dilys === ddaa [~ddaa@nemesis.xlii.org] has left #launchpad [] === debonzi [~debonzi@200-158-107-234.dsl.telesp.net.br] has joined #launchpad [01:46] Hi BradB... do you know why the data Ive put yesterday in launchpad_dogfood was deleted? [01:51] debonzi: nope [01:52] debonzi: sounds like somebody screwed something up though. [01:52] debonzi: what data was deleted? [01:53] i can see the source packages fine [01:53] BradB, the sourcepackage stuff [01:53] uhmm!! [01:53] they're in there [01:53] just a second [01:57] BradB, right.. they are there but the publishing table for them was deleted... thats why I can see them in soyuz [01:58] Probably it was done when the available distrorelease was changed from warty to hoary.. [01:58] thanks BradB [01:58] no prob [02:38] Merge to thelove@canonical.com/bazaar--devo--1.0: cherry pick recommended fix for get-changeset by abentley (patch-18) [02:59] Merge to rocketfuel@canonical.com/launchpad--devel--0: edit notification additions and fixes, and small UI fixes (patch-714) === 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 [09:12] Merge to thelove@canonical.com/bazaar--devo--1.0: Fixing id for test-get-changeset (patch-19) === ddaa [~ddaa@nemesis.xlii.org] has joined #launchpad [09:19] Merge to thelove@canonical.com/bazaar--devo--1.0: Input validation for join-branch (joelatrosdahl.net) (patch-20) [09:21] 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:24] Merge to thelove@canonical.com/bazaar--devo--1.0: Cosmetic changes to archive-mirror and cmd-tag (Cameron Patrick) (patch-22) [09:38] Merge to thelove@canonical.com/bazaar--devo--1.0: Various small star-merge changes (patch-23) [09:50] Merge to thelove@canonical.com/bazaar--devo--1.0: Grab fixes (Thaeter) (patch-24) [10:06] Merge to thelove@canonical.com/bazaar--devo--1.0: Automatic changelog tag fixups (Droneaud) (patch-25) [10:08] lifeless: running a replay/commit script? [10:16] Merge to thelove@canonical.com/bazaar--devo--1.0: --no-greedy-add to buld-cfg (Riiser) (patch-26) [10:30] Merge to thelove@canonical.com/bazaar--devo--1.0: Changing default inventory options to saner defaults (Walters) (patch-27) [10:36] Merge to thelove@canonical.com/bazaar--devo--1.0: Adding --silent option to file-find (Bentley) (patch-28) [10:41] Merge to thelove@canonical.com/bazaar--devo--1.0: Break hard links in set-tree-version (Bentley) (patch-29) [10:47] !Md:*! oops... we have lost a main rotation server. sorry for the inconvenience [10:47] Merge to thelove@canonical.com/bazaar--devo--1.0: Fixed missing exit in set-tree-version (Bentley) (patch-30) === 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 [10:50] lifeless: ping [10:52] Merge to thelove@canonical.com/bazaar--devo--1.0: Try using revlibs with cmd-changes (Bentley) (patch-31) [11:03] Merge to thelove@canonical.com/bazaar--devo--1.0: Get-changeset fix (Bentley) (patch-32) [11:12] Merge to thelove@canonical.com/bazaar--devo--1.0: Prevent getting from -MIRROR, _SOURCE, etc (Bentley) (patch-33) [11:14] Haha. #arch is awakening to baz. [11:18] 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) === Kinnison [~dsilvers@haddenham.pepperfish.net] has joined #launchpad [11:23] elmo: ping? [11:24] 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:30] 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) === carlos [~carlos@69.Red-80-33-181.pooles.rima-tde.net] has joined #launchpad [11:42] morning [11:43] Merge to thelove@canonical.com/bazaar--devo--1.0: Remove incorrect help from inventory -H (Jivera) (patch-37) [11:44] hey carlos [11:54] Merge to thelove@canonical.com/bazaar--devo--1.0: Help cleanup for cmd-changeset.c (Palmer) (patch-38) [11:55] ddaa: hi [11:59] Merge to thelove@canonical.com/bazaar--devo--1.0: Contant time version of DAV file_exists (Bentley) (patch-39) [12:01] jblack is on a roll today [12:01] Yeah. I'll be busy for the next few days. [12:01] I'm done for tonight though. [12:02] Tomorrow the hard work starts -- merging the patches that don't go cleanly. [12:02] hehe === Kinnison has faith [12:03] How; if I could have a bloody archive I could set-to getting gina running [12:21] jblack: duh, I thought lifeless set up a replay script... [12:21] ddaa: Nope. those were done by hand, one at a time. [12:22] About 3/5 of the patches replayed, and about 2/5 didn't. [12:22] What was the strategy? Follow 1.2.2rc2 ancestry? [12:22] for a variety of reasons. I'll go over them starting tomorrow. [12:22] Or start with Tom's 1.2.1 and then merge your patches? [12:22] Nope. [12:23] He started off of lords patchlog pruned gnua tree. [12:23] Yuck. [12:23] Already fixed. [12:23] Phew. [12:23] I replayed a patch that put the patchlgos back. [12:23] I would have hated to see the brain damage spread. [12:23] I would have rebelled. [12:24] Oh, want the punchline? [12:24] Apparently Tom knew exactly how evil it was, because he treated himself specially, and _put_his_patchlogs_back_ [12:25] Nobody else's mind you. Just his own. === ddaa is suprised by how apathetic the gnu-arch community is... almost no reaction from the announce of baz yet. [12:25] Yeah, you told me. [12:25] That just does not make any fucking sense. [12:25] Sure it does. Tom wanted to replay. [12:25] He just doesn't want anyone else to. [12:26] What I said. [12:26] Makes no sense. [12:26] Anyways.... [12:26] I replayed most of jblack@inframix last night. Almost everything went in from there. [12:26] 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:27] BTW, how the release policy going to be like? [12:27] So for the last 3 hours or so, I had to merge dance for the last few hours. [12:27] And the versioning policy. [12:27] ddaa: If I get to decide, the same as I did the rc/release policy. [12:27] So, you'd start at baz-1.2.2? [12:27] 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:28] What number will we start with? Hmmmm. [12:28] Didn't consider that yet. [12:28] That's an important issue. [12:28] Definitely. [12:28] Starting with 1.2.2 will makes it easier to see how it relates to tla. [12:28] loaded with all sorts of meaning an innuendo. [12:28] ddaa: As it relates to tla, it'll be 1.2.3 [12:29] But it might be perceived as more conflictual. [12:29] I've put in 1.2.2rc + 1.2.3rc patches together. [12:29] Hu? [12:29] I would have made sense to just start off 1.2.2, add the missing one-line patch, and release. [12:29] Heh. You think development stopped just because 1.2.2rcX was released? Nope. I kept going towards 1.2.3 [12:30] The point of it would have been being _immediately_ better than tla. [12:30] And giving a release for contributors to tag from. [12:30] Talk to lifeless about making the announcement a mere 24 hours after opening up the archive. [12:31] The early announcement makes sense. [12:31] "We are not hiding anything, you see." [12:31] you can't have it both ways. [12:31] But, in addition, an early release would have made sense too. [12:31] either its immediately better, or nothing's hid. [12:31] in this case, nothing's hid, so there's a lag time of a few days while stuff goes in. [12:32] Starting off a finished 1.2.2 would have immediately given a production-grade release. [12:32] But anyway. The choice is made. [12:32] tell you what. [12:33] 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] you know I can't promise that. [12:33] Then I'll have to do it now, before too much gets in. [12:33] I'm going to be too busy to forward port 40 patches. [12:34] not to mention the tree will probably move too quickly to do it. [12:34] regarding release process, archive setup, et. al, I have to talk to lifeless first. [12:35] There's an impedance mistmatch between the old release process, and lifeless' merge process. [12:35] Yeah. [12:36] But I still think that the rc process was basically a good idea. [12:36] Oh, its a resolvable issue. [12:36] Probably we could apply Linus release process here: [12:37] freeze the trunk during rc, so devels will get involved in testing it. [12:37] Like 2 weeks hacking, 2 weeks freezing. [12:37] Are you serious? [12:38] Lets do something better. [12:38] The debian release process is notoriously ineffective: keep unstable moving while hoping that testing gets fixed. [12:38] Give me until monday to outline a way to do it, which I'll present at the meeting. [12:38] Well, maybe the fact we have paid staff to make it work will help that. But RCs need as much testing as possible. [12:39] Uh huh. [12:39] I don't think that the "freeze to make software better" idea works. [12:39] Not that I am any authority in matters or release process management... [12:39] If that were true, Tom's 6 month freezes would mean that tla would be of very high quality. [12:40] That was not a freeze, that was a stop. [12:40] shrug. [12:40] A freeze involves RC bugfixing. [12:40] Whatever. [12:40] My two cents. [12:40] Here's the process I'm imagining. [12:41] I tag a rc from the tree that is dev-current. [12:41] I review all of the patches. That I don't like, I pull out. [12:41] I then announce the rc. [12:42] people start testing, saying where things are broken in the rc, etc. [12:42] developers see complaints, put in patches to fix the rc complaints, which gets pulled into the rc. [12:42] simultaneous with an rc being out, I'm already reviwing the first rc for the next revision. [12:43] I assume you realize that's a massive amount of work... [12:43] I'm making the best of the situation. [12:44] lifeless seems to think that I can review patches on the backend. [12:44] which really just shifts the backlog around. [12:45] Chi va piano, va sano; chi va sano, va lontano. [12:46] Dont' forget that eventually I'll have the supermirror equipment too, and I'll be doing that on top. [12:46] So I'll have a bit of fun. [12:47] Go in the direction you think is best. If you get swamped we are not going to wait 6 months before reacting. [12:48] Where I have choices, I'll of course try for what I think is best. ;) [12:49] So, anything else we need to discuss before I head off to bed? [12:49] Nothing in particular. [12:50] ddaa: Don't worry. I like having lots of work. === ddaa is busy refactoring the backend layer of pyarch... [12:50] 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] and if I consistantly have more than I can realistically do, we'll figure something more sane out. [12:51] It's a lot of work to figure all the details out... [12:52] jblack: g'night.... [12:53] ddaa: Thats ok. You'll do fine. :) [01:04] elmo: reping? === debonzi [~debonzi@200.158.100.251] has joined #launchpad [01:42] which airport is right for south kensington? LHR ? [01:42] yeah LHR is good [01:44] jblack, hi man [01:44] heya debonzi [01:44] jblack, how is it going? [01:45] pretty good. Just realized how close the arch sprint is [01:46] jblack, yeah.. the time flies :) [01:47] travelocity can't find me a 3 leg hop. [01:47] jblack, ahh, btw... do you know how to describe me that "problem" when tla wants to merge some modifications that was already applied? [01:48] debonzi: Yes. That happens if you star merge rocketfuel before rocketfuel is done star-merging you. [01:49] 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:50] jblack, and there is no pqm involved.. or better, cprov is the PQM :) [01:51] hey debonzi. [01:51] Kinnison, hi [01:51] debonzi: He should only merge to and from one guy. [01:51] debonzi: is it possible for anyone but elmo to update the archive on mawson? [01:51] And to make sure that he and the other guy doesn't merge each otehr at the same time [01:52] jblack: And that their mirror are up to date before merging? [01:52] jblack, right.. I know the guy only star-merge from and to cprov.. [01:52] Kinnison, I don't know.. sorry === 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 [01:54] oh my. [01:54] spiv: correct. [01:54] debonzi: Then probably they merged each otehr at the same time. [01:55] I thought star-merge was meant to cope with this [01:56] Kinnison: Teehee. [01:57] jblack, probably because the mirrors should always be up to date since both are using hook for it [01:57] Kinnison: Can't. [02:01] 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] Right. [02:01] exactly right. [02:03] 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:04] s/to/too [02:04] Yes. [02:04] right.. Ill talk about it to them.. thanks jblack === kiko [~kiko@200.144.121.120] has joined #launchpad [02:38] 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:39] hey spiv [02:39] I'm reorganizing the pyarch backend model. [02:39] Hey. [02:39] The twisted stuff used to live in arch._twisted, now I'd like to move it to arch.backends.twisted. [02:40] 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] However, that would cause a name conflict. [02:40] in fact, my postgresql is mad now, with launchpad stopped it continues eating my CPU... [02:40] debonzi: yes [02:40] spiv: any idea for a better name? arch.backend.twisted_process is a bit of a mouthful imho. [02:40] carlos, will try to firgure it out.. [02:40] carlos, sound like a broken query; I did post a fix to that I believe [02:40] or was it salgado? [02:41] and things like arch.backend.reactor or arch.backend.meltdown not really obvious imho. [02:41] thanks [02:42] carlos, at any rate, let me get salgado on it [02:42] Maybe arch.backend.untwisted? === salgado [~salgado@200-206-134-238.async.com.br] has joined #launchpad [02:42] ok [02:42] The Twisted bits of pyarch only affect process handling? [02:43] salgado, dude [02:43] with the sampledata cprov has given carlos [02:43] I guess I'm fuzzy about what "backend" means for pyarch :) [02:43] http://localhost:8086/soyuz/distros/ubuntu/src/warty/apache/1.3.31-6 [02:43] It's a very generic term. [02:43] salgado, pgsql starts blowing up [02:43] spiv: yes, that's essentially a ProcessProtocol and a thread-side blocking API. [02:43] lp_dump-20041025-mr.sql [02:43] can you look into it? it's probably a query missing a join clause [02:43] That's the file I'm using [02:44] salgado, debonzi: which brings me to the matter: I think we should start considering using views to avoid this sort of problem [02:44] 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] Ok, they feel like different things to me. [02:45] kiko: I've just had the same problem [02:45] If anything, the twisted support is a layer between tla/baz and the rest of pyarch. [02:45] 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] salgado, fixes and merges appreciated === carlos -> lunch [02:45] kiko: I was waiting the notie come back to life to fix it [02:45] Rather than at the same level as tla/baz. [02:45] salgado, if you want you can just tag off debonzi or mail him patches for fast merges === Kinnison -> town [02:45] spiv: yes, but all those different things are somewhat tightly coupled. [02:46] kiko: ok [02:46] salgado, but seriously, I think we should talk about using a view to simplify this [02:46] I think we are forgetting join clauses too often.. [02:46] The cli interface depends on process spawning, which depends on cli logging... [02:47] And the process name stands somewhere in the middle of that. [02:47] So, from pyarch perspective, they are quite the same hairball. [02:48] kiko: Is this related to clauseTables? [02:48] spiv: but what you are saying is essentially correct. Only twisted/pyarch is only one axis of the backend configuration. [02:48] 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] spiv, did anything like that land? [02:49] spiv: so, any kind of conventional name for this sort of thing in the twisted world? [02:50] 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. === debonzi [~debonzi@200.158.100.251] has joined #launchpad === ddaa ponders [02:51] carlos, for sure there is a problem there.. it killed my machine.. :( [02:51] btw, PyArchSpawningStrategy is not based on popen. It's doing the fork/exec and pipe handling itself. [02:51] 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] ddaa: pyarch.spawning.diy then ;) [02:51] maybe [02:52] (Plus I haven't seen a reply to my post to the launchpad list about it) [02:52] Mh... the point of arch.backend is that there needs to be a single place to glue all the parts toghether. [02:53] spiv, I saw it but haven't discussed it yet [02:53] And anyway arch.spawning.twisted is not going to help the fact that I cannot import twisted from there! [02:53] What is annoying me is that name conflict. [02:53] Oh, right, now I get what you were asking about. [02:54] And please do not give me any of that sys.module crack :-) [02:54] No, I don't know of any conventions for this. Relatively few projects don't go 100% twisted. [02:55] Hah, no :) [02:55] Python's import stuff is frustrating enough ;) [02:55] pyrad has a module called "curved" for this purpose. [02:55] spiv: so, what would be evocative to a twisted person? [02:55] "wedged"? :-P [02:56] An obtuse Monty Python, Pokey the Penguin, Isometric reference ;) [02:56] gne? [02:56] s/, I/, or I/ [02:57] ddaa: Most of the Twisted devs are mildly obsessed with webcomics. [02:57] I terrible lack culture in all those domains. [02:57] I'd say "knotted" would be good. [02:57] And then you can tell people to "get knotted" ;) === ddaa misses the reference [02:59] It's english slang, similar to "get stuffed" I guess. [03:00] That's something involving penetration I guess. [03:00] Similar to "get " ;) [03:01] In french, "noeud" (knot) is slang for penis. === kiko is now known as kiko-afk [03:01] Okay. Sounds good. [03:02] spiv, can you help me to check one query? [03:03] Mind if I give credit for the name? [03:04] it's a trade secret! [03:06] debonzi: Sure, but I'm about to duck out for 10 min. [03:06] spiv, it very fast I think.. [03:06] So either be fast or patient :) [03:08] """Twisted process handling. [03:08] The name of this module"knotted", was suggest by Andrew Bennets as a [03:08] way to avoid the name clash with the "twisted" top-level package: [03:08] I'd say "knotted" would be good. [03:08] And then you can tell people to "get knotted" ;) [03:08] """ [03:08] ddaa: Hehe. But my surname has two "t"s :) [03:08] I disclaim all responsibility for the bad taste of Twisted devels :-) [03:09] Ooops. Fixed. Thanks. [03:12] stub, are you around? [03:13] Yup [03:14] stub, debonzi and I are this weekend going to move some queries into views [03:14] we've got a lot of massive joins and the code is kinda unwieldy [03:14] Sounds sane [03:15] what's your take on this? [03:15] we'll probably drop some sql on your lap sometime soon then [03:15] btw, did you get my index request? [03:15] Yup - that went in the last patch, yesterday I think [03:16] thanks === kiko-afk perf munster [03:21] jblack ddaa we are working towards 1.0. Sorry to beat you to the punch, but I needed a decision when tagging. [03:22] lifeless: Pardon? [03:22] Oh, you mean uh, baz version #. [03:22] Whatever you want to start at is cool with me. [03:22] I'm not sure that the namespace version excludes anything for the release version. [03:23] But 1.0 is certainly less controversial, even if less evocative. [03:23] ddaa: true, but having 1.0 in the namespace makes 1.0 as the release natural ond abvious to folk. [03:23] The starting number isn't the part I'm thinking about atm. [03:24] 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] BTW, maybe 0.9 releases would be in order until we have redone the command set. What do you think? [03:24] Because we are surely going to redo the command set... [03:25] 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] ddaa: well, 1.0preX releases are equally visible to the user. [03:25] 1.0pre3rc2.... [03:25] No. [03:25] yuck [03:25] I think we need to set a few feature goals for the first release, and then a timeframe for that. [03:26] that will give us structure to consider the other priorities in. [03:26] preferably XrcY, acceptably XpreY, but XpreXrcY, yuck no. [03:26] Apparently jblack's feature goals are "whatever was scheduled for inclusion in 1.2.3" [03:26] I think that a quick release is a damn good idea. [03:27] Yeah. I want that code out. [03:27] ddaa: I asked jblack to incorporate all of that work, and hes' doing a great job of doing so. === debonzi will be back in a minute [03:27] If I were in jblack's shoes I would have made the first release the equivalent of 1.2.2-final. [03:27] 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] ddaa: we don't have a release manager for bazaar [03:28] lifeless: Um, lifeless, here's the problem.... [03:28] People make mistakes. _frequently_. [03:28] lifeless: we are going to make releases, aren't we? [03:28] From arch experience, the accuracy rate on patch submissions for high calibre people is about 90%. [03:28] Eternal Beta is not what the community needs. [03:28] ddaa: act. [03:28] bahh. [03:29] ddaa: ack. [03:29] lifeless: ? [03:29] 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] can we unmultiplex these conversations. jblack - lets focus on the process stuff. [03:29] sure boss. [03:29] jblack: which is what you are talking about :) [03:29] So, releases w/o release manager? Sounds... risky... === stub [~stub@dsl-246.248.240.220.dsl.comindico.com.au] has left #launchpad [] [03:30] I was just putting ddaa's stuff to the side. [03:30] heh. [03:30] Here's the cycle I envision. === ddaa goes back to turning pyarch guts upside down. [03:30] so. there are two ways of addressing the review bottleneck. [03:30] (two fundamental ways). [03:30] I get an Xrc out. While Xrc is being reviewed for 1~2 weeks, I'm reviwing for X+1rc. [03:30] a) scale out the review process into lieutenants. [03:31] If a fix is needed, it goes into devel, and I merge it into both rcs. [03:31] b) allow the review process to lag the development [03:31] Long term, yeah. We can do that with buddy systems. [03:31] now, the process I've introduced here has both element. [03:31] We pair frequent developers up, and they check each other. [03:32] a) - there are 4 lieutenants - you, me, ddaa, bob2. [03:32] b) - the review is allowed to lag, but we have a nominated reviewer who will check. [03:32] (you for now, if your bandwidth is wide enough) [03:33] yes, it is [03:33] (when I say 'for now' - when we get this dedicated C programmer, I'm expecting to make this his|her problem) [03:33] ok [03:34] so the question that matters w.r.t. 'released code' is: how many layers of review are enough? [03:34] (btw, I like that) [03:34] What level of quality do you want? [03:35] Both you and Tom, in series, for the 1.2.1 release accepted bugs. [03:35] so 2 reviewers obviously isn't enough :) [03:35] If we start with a accuracy rate of 80%, and assume that each developer cuts the error rate in half... [03:36] (the original submitter counts as reviewer 1) [03:36] 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] I've put a unit test suite into libarch now, that is easy to extend. [03:36] I don't get you. [03:36] So, when *I* review stuff, I'll be writing tests. [03:37] I hope my accuracy rate will be ~ 95%. [03:37] test cases, test cases, test cases [03:37] You're not that good. [03:37] dude, I'm better than that, but I have multiple priorities. [03:38] Trust me. You're not. You're one of the three best, but you're not 95%. === lifeless shrugs [03:38] 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:39] 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:40] in terms of test cases. [03:40] I agree. [03:40] that sort of coverage allows rapid review. [03:40] rather than hour long code path picky sessions. [03:40] I'm not sure how we measure that metric though. [03:41] gcov [03:41] gcc compiler coverage tool. [03:41] tells you what parts of a binary are exercised by a specific code run. [03:41] Yeah. I'm looking at the man page. [03:41] Ok. That answers that. [03:42] 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] but, we have a window between now and the test suite being mature, which is higher risk. [03:42] No sir. [03:42] its not higher risk ? [03:42] We may be able to cover the code base, but we won't cover some of the most important things. [03:43] Previous comment. [03:43] In fact, the test suite can catch most everything but the most dangerous changes. Unintentional compatibility changes. [03:44] at least not with a conventional test kid. [03:44] *kit. [03:44] erm, the test suite can absolutely catch those. you run the previous version test suite against the newer version code. [03:44]