[12:04] I don't think a normal human being would differentiate U/C/A. But U/C/IP could be worthwhile [12:04] yeah === LarstiQ chalks himself down as not normal [12:05] whichever is done, it's wrong for someone else to be able to mark a bug as Accepted when it's assigned to me [12:05] because I might think the bug is complete crack [12:05] or something I don't know how to fix [12:06] yeah. LP doesn't really have workflows, ATM. at least not enforced programatically [12:08] LarstiQ, well, you and I understand it, but many don't, apparently including one or two of my managers :-) [12:09] bradb, would you be happy with "Being Fixed" instead of "In Progress"? (In Progress is possibly a little too similar to PendingUpload) [12:09] Being Fixed is even better [12:09] ok, cool [12:16] In other news, bradb, we seem to be getting a mountain of duplicate bug reports [12:17] from which I conclude that priority #2 is making searching work better :-) [12:22] our search is not very useful, sadly, but I don't think it's been a priority yet for stub to look into ispell integration and such. We're working on it though. For example, we added sourcepackage name to the bug searching during UBZ, but it doesn't appear to have been rolled out yet. [12:25] but yes, i'd fully agree on it being priority #2. === bradb has to leave now, later all === bradb [n=bradb@modemcable033.209-70-69.mc.videotron.ca] has left #launchpad [] [12:25] 'night === mpt [n=mpt@tvwna-ip-a-3.princeton.org] has left #launchpad ["http://mpt.net.nz/"] === Ubugtu` [n=bugbot@81.171.100.21] has joined #launchpad === kiko [n=kiko@c-65-96-188-167.hsd1.ma.comcast.net] has joined #launchpad === kiko [n=kiko@dsl092-076-224.bos1.dsl.speakeasy.net] has joined #launchpad === kiko_ [n=kiko@c-65-96-188-167.hsd1.ma.comcast.net] has joined #launchpad === mpt [n=mpt@tvwna-ip-a-3.princeton.org] has joined #launchpad === kiko__ [n=kiko@dsl092-076-224.bos1.dsl.speakeasy.net] has joined #launchpad === dewd [n=dewd@201.29.123.206] has joined #launchpad === TinMan [n=Lotus@cpe-24-194-140-191.nycap.res.rr.com] has joined #launchpad === kiko [n=kiko@dsl092-076-224.bos1.dsl.speakeasy.net] has joined #launchpad [04:49] jordi, you may want to subscribe to bug 3954 [04:49] Malone bug #3954: Tamazigh needs adding to Rosetta Fix req. for: rosetta (upstream), Severity: Normal, Assigned to: Nobody, Status: New http://launchpad.net/malone/bugs/3954 === tambaqui [n=patricia@200.247.65.172] has joined #launchpad === robitaille [n=robitail@ubuntu/member/robitaille] has joined #launchpad === sankar [n=sankar@202.144.95.245] has joined #launchpad === mpt [n=mpt@tvwna-ip-a-3.princeton.org] has joined #launchpad === netjoined: irc.freenode.net -> brown.freenode.net === TinMan [n=Lotus@cpe-24-194-140-191.nycap.res.rr.com] has joined #launchpad === Ubugtu` [n=bugbot@81.171.100.21] has joined #launchpad === gml [i=gml@dyn-83-156-7-10.ppp.tiscali.fr] has joined #launchpad === mdke [n=matt@ubuntu/member/mdke] has joined #launchpad === ajmitch [n=ajmitch@port161-157.ubs.maxnet.co.nz] has joined #launchpad === SteveA [n=steve@195.182.78.95] has joined #launchpad === auth00 [i=auth@fiji.grd.sgsnet.se] has joined #launchpad === jamesh [n=james@203-59-207-160.dyn.iinet.net.au] has joined #launchpad === poningru [n=poningru@n128-227-11-184.xlate.ufl.edu] has joined #launchpad === mantiena [n=AKL@ctv-84-55-0-52.init.lt] has joined #launchpad === Znarl [n=karl@bb-82-108-14-161.ukonline.co.uk] has joined #launchpad === JanC [n=janc@lugwv/member/JanC] has joined #launchpad === jblack [i=jblack@static-209-158-45-74.scr.east.verizon.net] has joined #launchpad === siretart [i=siretart@ubuntu/member/siretart] has joined #launchpad === \sh_away [n=nsh@ubuntu/member/backslash-sh] has joined #launchpad === bob2 [i=rob@crumbs.ertius.org] has joined #launchpad === uws [n=mathilda@scrat.hensema.net] has joined #launchpad === LarstiQ [n=larstiq@cust.7.157.adsl.cistron.nl] has joined #launchpad === asw [n=asw@karuna.med.harvard.edu] has joined #launchpad === Nafallo_away [n=nafallo@ubuntu/member/nafallo] has joined #launchpad === sladen [i=paul@starsky.19inch.net] has joined #launchpad === ajmitch [n=ajmitch@port161-157.ubs.maxnet.co.nz] has joined #launchpad === mpt [n=mpt@tvwna-ip-a-3.princeton.org] has joined #launchpad === stub [i=stub@sweep.bur.st] has joined #launchpad === mpt [n=mpt@tvwna-ip-a-3.princeton.org] has left #launchpad ["http://mpt.net.nz/"] === Nafallo_away is now known as Nafallo === Burgundavia [n=corey@S0106000000cc07fc.gv.shawcable.net] has joined #launchpad [08:44] good morning! [08:47] HI! === Seveas [n=seveas@ubuntu/member/seveas] has joined #launchpad === ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has joined #launchpad [09:54] ddaa: good morning [09:55] Hello SteveA === carlos [n=carlos@243.Red-83-47-24.staticIP.rima-tde.net] has joined #launchpad [10:14] morning [10:15] hi carlos [10:16] oh, carlos, i had a question for you [10:17] SteveA, tell me === SteveA looks up email [10:20] carlos: okay, i have just forwarded you a mail that was on the schooltool mailing list, but also kind of a debian debbugs mail [10:20] ok [10:20] there is a complaint about rosetta there which i think has been addressed [10:21] so, i want to check what a proper reply to that is, and then to make the reply, so that the record is set straight [10:24] SteveA, ok, it was a side effect of our old codebase when we showed all those fr_FR, es_ES, etc... locales by default [10:25] Mark said that we should not expend time implementing a way to merge .po files [10:25] so the old ones remain there [10:26] but it's not easy to create new ones [10:27] to create new translations in fr_FR you mean? [10:27] right [10:28] okay. so, what should the schooltool people do given the current situation? [10:28] ask for a merge of the fr_FR into fr by a French translator [10:29] downloading the .po file and uploading the merged one into the fr locale [10:29] and then ping me so I ask stub to remove that POFile from the database [10:29] it's the only way to fix it [10:29] hmm... i can't describe that so well in an email. so, i'll ask them to come here and talk with you about it. [10:29] of course, they should remove the fr_FR.po from the release [10:29] or Rosetta will add it again [10:30] SteveA, ok [10:36] https://chinstrap.ubuntu.com/~dsilvers/paste/fileiifGVM.html [10:36] carlos: does that read correctly? [10:38] SteveA, "so translators are not offered these language variants..." I think it implies that there is no way to create them anymore [10:38] and that's not true, if someone wants to do that, it's still possible [10:38] ok === jinty [n=jinty@205.134.224.215] has joined #launchpad [10:39] but you are not "invited" to do it, you should request it being explicit (uploading a fr_FR.po file or typing the URL by hand) [10:39] okay [10:41] SteveA: what is the recommended format for epydoc entries in launchpad docstrings? ReST or epydoc syntax? (or something else?) [10:44] ddaa: i have no specific recommendation, because i don't use that style. i can look into it and form an opinion if this is blocking you. [10:44] carlos: sent the mail. [10:44] I use ReST format generally, as it's the more likely to become "standard" in the future. [10:44] SteveA, ok, thanks [10:45] jinty: hi. you just missed carlos and me talking about how the schooltool po files / country-specific-language-variant translations can be fixed up in rosetta === WaterSevenUb [n=WaterSev@193.136.48.45] has joined #launchpad === WaterSevenUb [n=WaterSev@193.136.48.45] has joined #launchpad [10:47] ddaa: can you get me URLs with examples of each of the alternatives? [10:47] or examples in Kinnison's pastebin? [10:51] SteveA: http://epydoc.sourceforge.net/fields.html === stub [i=stub@sweep.bur.st] has joined #launchpad [11:05] stub, hi, could you give me a patch number for the DB patch you reviewed yesterday? (The TranslationUploads branch) [11:06] eh? oh. patch-40-04-0.sql [11:06] stub, thanks [11:09] ddaa: i like this best: http://epydoc.sourceforge.net/fields.html#rst [11:10] I do not like it because it does not allow putting types and descriptions side by side. [11:11] When i want to put types and descriptions or params I usually write: [11:11] ddaa: what do you prefer? [11:11] :param foo: The foo to froboize. [11:12] :type foo: `IFoo` [11:12] :param bar: The bar to have beer at. [11:12] :return: Froboized foo with a pint. [11:13] It's reasonably efficient in vertical space. [11:14] hmm... [11:14] why is it so important to have a separate :type: line for arguments, but not for the return value? [11:14] There's :rtype: as well [11:15] it's just that sometimes I give only a description, and sometimes only a type, sometimes both, sometimes none. [11:16] okay. [11:17] so, i can say this: if you want to use a structured docstring, use one of the rst formats, and not the javadoc or epytext format [11:17] perfectly happy with that. [11:37] is there anyway to execute just one pagetest that uses librarian? ./test.py --test=... does not work [11:41] I suggest "./test.py -v . name_of_the_test" [11:41] the little dot in the middle is important [11:42] where name is the filename for a doctest/pagetest or the method name for a unitttest [11:48] ddaa, will that execute librarian? [11:48] mh... [11:48] nah, don't think so... would have to start it by hand... [11:49] ok === ddaa -> lunch === niemeyer [n=niemeyer@200.138.36.87] has joined #launchpad === matsubara [n=matsubar@201-13-106-123.dsl.telesp.net.br] has joined #launchpad [12:10] good morning! === cprov [n=cprov@201-13-106-123.dsl.telesp.net.br] has joined #launchpad [12:19] good morning hackers [12:20] morning :-) [12:21] Morning Celso [12:22] cprov: I'd like to setup the build system here as we discussed at UBZ.. would you be able to talk about it today? [12:22] niemeyer: hi niemeyer, sure ... join ##soyuz [12:25] niemeyer: I mean, when you have time. [12:25] cprov: I'm there :) [12:25] Alone.. :( [12:25] ;) [12:26] niemeyer: he, it wasn't a typo, double hash . [12:26] cprov: I'm there, really [12:28] niemeyer: sorry, ##soyuz1.0, which is totally out of context, whatever [12:29] np :) === beyond [n=beyond@201-13-106-123.dsl.telesp.net.br] has joined #launchpad === beyond_ [n=beyond@201-13-106-123.dsl.telesp.net.br] has joined #launchpad === salgado [n=salgado@201-13-106-123.dsl.telesp.net.br] has joined #launchpad === WaterSevenUb [n=WaterSev@azevedo.astro.up.pt] has joined #launchpad === GoRoDeK [n=gorodek@p5083FB12.dip.t-dialin.net] has joined #launchpad === jbailey [n=jbailey@modemcable139.249-203-24.mc.videotron.ca] has joined #launchpad === netjoined: irc.freenode.net -> brown.freenode.net === LarstiQ [n=larstiq@cust.7.157.adsl.cistron.nl] has joined #launchpad [01:16] Hey niemeyer === koke [n=koke@adsl229-164.unizar.es] has joined #launchpad [01:18] Hiho [01:18] What's up? [01:18] :) === netjoined: irc.freenode.net -> brown.freenode.net === LarstiQ [n=larstiq@cust.7.157.adsl.cistron.nl] has joined #launchpad [01:22] niemeyer: I've done lifeless' part of the review comments [01:23] I've delayed doing yours until you could tell me whether I can expect it from you today. [01:27] ddaa: Yes, you may expect it for today [01:27] ddaa: What's the lifeless part that you've done? [01:28] The "Robert blamed" bit. See new message in the launchpad-reviews mailing list. === TinMan is now known as t1n_m4n [02:21] SteveA: sorry, I felt so bad this morning I slept in 'til now [02:21] SteveA: I still have a sore throat but at least my head isn't spinning [02:21] hello Kinnison [02:29] Kinnison: too much whooping yesterday? [02:31] LarstiQ: not quite :-) === BjornT [n=bjorn@84.32.140.183] has joined #launchpad [02:32] launchpad developers: make sure you're subscribed to https://wiki.launchpad.canonical.com/LaunchpadHackingFAQ [02:45] ddaa: i added a note about docstrings to https://wiki.launchpad.canonical.com/LaunchpadHackingFAQ [02:46] Thanks. [02:58] ddaa: Have you changed your branch (.../launchpad/branches) in any strange way? [02:58] not that I'm aware of [02:59] ddaa: I did a pull and bzr removed *everything* [02:59] mh === ddaa checks [02:59] You mean /home/warthogs/archives/david/launchpad/branches right? [03:00] Yes [03:01] bzr status shows a remove list with the whole launchpad.. :) [03:01] I'm updating bzr, and will try again [03:02] If it doesn't work, I'll have to resync everything. === mhz [n=mhz_chil@moinmoin/fan/mhz] has joined #launchpad [03:03] It looks sane on chinstrap, waiting for bzr status there [03:03] ji ther [03:03] hi [03:04] there === mgalvin_away is now known as mgalvin [03:04] :) [03:04] ddaa: Yes, it looks fine indeed [03:04] ddaa: Which is even worse.. :( [03:04] Any chances LaunchPad assigns Karma for IRC and Wiki contributions? [03:04] and also for Talks and Evangelisation? === niemeyer will have lunch and brb === heyko [n=heyko@port-212-202-49-90.dynamic.qsc.de] has joined #launchpad === mgalvin [n=mgalvin@host-66-202-95-170.spr.choiceone.net] has joined #launchpad === JaneW [n=JaneW@wbs-146-169-236.telkomadsl.co.za] has joined #Launchpad [03:47] mhz, how would we track that? [03:48] carlos: no idea yet. === mhz is not a developer === mhz is an edubuntu evangeliser only [03:48] :) [03:48] mhz, the only way to track those contributions is manually.... [03:48] maybe manually [03:48] hehehe [03:49] indeed [03:49] carlos: hablas castellano? [03:49] mhz, si [03:49] que bueno! [03:49] where are u from? [03:49] mhz, Spain [03:50] and you? [03:51] Spain is probably THE largest spanish speakers voice for free as in freedom community [03:51] Chile [03:52] and the number country with the highest number of Debian based distributions in the world.... :-( [03:53] s/number country/country/ === bradb [n=bradb@modemcable033.209-70-69.mc.videotron.ca] has joined #launchpad [03:54] why sad? [03:58] mhz, we should not create that amount of distributions but contribute each other to improve a common base. At least now seems like some of them are moving to use Ubuntu as their base without forking it [03:59] carlos: really? to ubuntu? cool [03:59] I have been so much into the project that I loose outside perception [03:59] :) [03:59] AFAIK, ubuntu is a good base [04:00] so is Knoppix :D [04:00] morphix was close [04:01] IMHO, Ubuntu will become what RedHat meant to be (rpm's though) and Debian couldn't (not a company) === matsubara is now known as matsubara-lunch [04:04] carlos: re-Karma/ so? how can it be manually? === jinty [n=jinty@226.Red-81-39-9.dynamicIP.rima-tde.net] has joined #launchpad [04:05] mhz, no atm [04:05] mhz, we would need to figure a way to do it [04:06] carlos: do you understand why I ask? [04:06] mhz, please, file a bug against launchpad with that suggestion [04:06] ok [04:07] mhz, yeah, I understand your concerns as the karma is being used as a way to know your Ubuntu contributions [04:07] carlos: is there a 'why we use karma' doc or definition? [04:07] maybe karma is meant for 'developers' (code stuff) [04:07] mhz, we have a document that describes a bit how it's implemented [04:07] ok [04:07] thx [04:08] mhz, you get it translating or working with bug reports [04:08] so it's not a developer 'thing' [04:08] everyone can get it [04:08] ok, cool then [04:08] deserves a bug [04:08] deserves a bug filing [04:12] mhz, thanks [04:12] np [04:12] thank you all for LP [04:12] LP + Moin would rock! [04:14] mhz: you always manage to get a punt in for moin :P [04:14] hehehehe [04:15] that's the idea [04:15] yesterday I was ina 3 hour meeting and I must have mentioned edubuntu at least 30 times === JaneW gives mhz a virtual gold star (tm) [04:16] JaneW: the thing is that I tried trac once (very cool wiki + devel tools) and I noticed Moin was cooler. So now I see LP + Moin like a pretty cool idea [04:16] JaneW: hehehe [04:32] This bzr transition puts me in a funny situation wrt to pybaz... [04:32] ddaa: have many users been in contact about it? [04:33] hard to tell... I have the impression that only a few intrepid devels ever used it, most of them are now on bzr... [04:33] but I was sometimes surprised [04:34] i know... put a release out there with obvious errors in the packaging, and see how many complain ;-) [04:34] that works :) [04:34] I have not put a release out in ages [04:34] mhz_cooking: the wiki in trac is Moin based [04:34] my release management sucks too much for that, people just get it from the baz archive [04:35] cripple the baz archive? ;) [04:35] I'll just do something horribly crippled and wrong for mirroring, so I get proper verbosity. Instead of added the right feature to pybaz. === koke [n=koke@ubuntu/member/koke] has joined #launchpad [04:35] convert the baz archive of pybaz to bzr... [04:35] * instead of adding [04:36] SteveA: that sort of defeats the point of pybaz... [04:36] well... I guess that would be a way of putting out a statement as well... [04:37] maybe throw an email at mpool and lifeless and see what they suggest [04:37] would be faster for me just to code the feature I need... on a bzr hosted branch. [04:37] If anybody appear to care about pybaz in the future, I'll think about backporting. [04:37] Thanks for talking. That helped me take a decision. === WaterSevenUb [n=WaterSev@azevedo.astro.up.pt] has joined #launchpad === koke [n=koke@ubuntu/member/koke] has joined #launchpad === mpt [n=mpt@tvwna-ip-a-3.princeton.org] has joined #launchpad === matsubara-lunch is now known as matsubara === BjornT_ [n=bjorn@84.32.140.183] has joined #launchpad [05:27] LarstiQ: yup, indeed [05:27] hence I say Moin+LP is cooler [05:28] .oO(my non english-thinking plays tricks on me, usually) [05:29] SteveA: please review sftp://chinstrap/home/warthogs/archives/david/pybaz/iter_mirror ASAP [05:29] ddaa: is it on the pending reviews page? [05:29] just added :) === Seveas [n=seveas@ubuntu/member/seveas] has joined #launchpad === gneuman [n=gneuman@201-13-106-123.dsl.telesp.net.br] has joined #launchpad [05:52] mhz: I do miss some trac features in lp atm [05:52] which ones? === mhz still does not use LP so much [05:53] LarstiQ: if you say "subversion integration" I'll go nasy ;) [05:54] nasy? [05:54] lol [05:54] hu... "nasty" [05:54] oh, ok [05:54] ddaa: no, afaics the timeline and source view [05:54] mh... tell me more about the source view [05:55] that might be part of the stuff I'm responsible for. [05:57] ddaa: http://wiki.powerdns.com/projects/trac/browser/trunk/pdns/ [05:57] do you use the changeset view much? [05:59] got to say that trac viewsource is quite nice, compared to the usual viewsvn nonsense [06:00] ddaa: frequently enough, yes [06:00] Would be a great feature to have in launchpad for bzr branches. [06:00] (AND rcs imports!) [06:00] look like a lot of work though. [06:01] the timeline bit might already be solved [06:01] What's the timeline thing? [06:02] looks like the Moin recentchanges, for wiki edits/bug changes/changesets [06:02] http://wiki.powerdns.com/projects/trac/timeline [06:02] and it has an rss feed ;) [06:02] mhhh [06:02] malone has this for bugs via mail at least [06:02] so it's mostly an integration question? [06:03] not sure how that would work with a few dozen random community branches registered for a product... you'd probably not want community branches in the timeline. [06:03] Maybe only branches associated to a series. [06:03] LarstiQ: http://projects.edgewall.com/trac/wiki/TracOnUbuntu [06:03] had you seen it? [06:04] Wel... except for the linking to the viewsource, it looks like it would be reasonably easy to implement. [06:04] well... once the branch migration to bzr is done, that is... [06:04] ddaa: I'm mainly looking at it from my project point of view, our own trac is now nicer than lp [06:05] Of course. [06:05] mhz: that doesn't look that special? [06:05] mhz: trac+bzr is more interesting for me :) [06:06] i know it is not special. it's good they are taking care of it (packaging it) [06:06] I know moin is packaged but not trac [06:06] LarstiQ: It's not clear who should take time from other objectives to implement that feature. It will probably not be implemented unless your file a bug and talk sabdfl into it. Should not be difficult though. [06:06] trac has been packaged for a loooong time [06:07] trac+bzr? excellent. I have heard a lot about bzr but nevere tasted it yet, only sbv. [06:07] For bzr integration, it's going to take some time, if only because bzr integration is quite embryonic and I have a larg data migration (from baz) task in my pipe. [06:07] subversion, I meant [06:08] That would be quite a shiny feature to have. === LarstiQ trots off for training === Seveas [n=seveas@ubuntu/member/seveas] has joined #launchpad [06:15] BjornT_: replied to X-Malone-Bug review === mhz [n=mhz_chil@moinmoin/fan/mhz] has left #launchpad ["Leaving"] === zygis [n=zygis@clt-84-32-129-122.dtiltas.lt] has joined #launchpad === SnakeBite [n=SnakeBit@212.25.63.37] has joined #launchpad === palmTree [n=chatzill@213.210.241.110] has joined #launchpad === mpt [n=mpt@tvwna-ip-a-3.princeton.org] has joined #launchpad [07:35] ddaa: Ouch.. you've sent bzrsync.py to the revision "as-is".. [07:36] ddaa: Including a print in the constructor. 8) === slomo [n=slomo@ubuntu/member/slomo] has joined #launchpad [07:37] hi... is it possible to get the po files from rosetta with name and email adress and copyright of the author filled in? === Seveas [n=seveas@ubuntu/member/seveas] has joined #launchpad [08:03] well, as far as your code works, I'm happy with it, it's the reviewer job to be picky about things like that ;) [08:04] BjornT_: ping [08:05] ddaa: Considering that you introduced the prints in the first place, I'm not surprised that you're happy with it. :) [08:05] ddaa: But using print inside a constructor is.. erm.. awful. :) [08:06] Sounds a bit sloppy indeed. === ddaa -> dishes === palmTree_ [n=chatzill@213.210.241.110] has joined #launchpad === koke [n=koke@adsl229-164.unizar.es] has joined #launchpad === dewd [n=dewd@201.29.115.83] has joined #launchpad === mpt [n=mpt@tvwna-ip-a-3.princeton.org] has joined #launchpad === tambaqui [n=patricia@200-231-134-58-mns.cpe.vivax.com.br] has joined #launchpad [08:49] SteveA: I'm not subscribed to launchpad-reviews, and the subscription seems to be moderated. Would you be able to approve it, please? [08:53] Does anyone know when the import of Ubuntu packages into Launchpad is happening? === tambaqui [n=patricia@200-231-134-58-mns.cpe.vivax.com.br] has left #launchpad ["Fui] [08:58] BjornT_: ping [08:58] mpt: not really, it depends of the gina results in staging ... lot of timeouts atm. [09:00] niemeyer: sure [09:03] niemeyer: nope, i can't. i think kiko is the manager of that list [09:04] SteveA: Ok, thanks for trying it [09:05] jblack: ping [09:06] ddaa: reviewing the pybaz code now [09:08] pong [09:09] jblack: I've been reading CreatingBranchesOnSupermirror [09:09] the spec says that autocreated branches should not be displayed in launchpad until title and description have been set. [09:09] is that still what is intended? === Nafallo is now known as Nafallo_away [09:13] ddaa: That was not the idea when we talked about it in UBZ === Keybuk [n=scott@syndicate.netsplit.com] has joined #launchpad [09:14] niemeyer: that's why I'm asking, there's apparently a discrepancy. === jblack gives niemeyer an odd look [09:14] ddaa: Publically displayed, you mean? [09:14] yes === niemeyer runs scared [09:14] :) [09:15] I think that there should be two options. A user level option to set a default, for which the default is to hide new branches. [09:15] That way, the branches list for someone doesn't get spammed up with throwaway branches. [09:16] Mh... I see the motivation... [09:16] The question comes down whether the saner default is marking stuff thats good to talk about, or marking stuff that's not. [09:17] I expect that with the way that its trivial and encouraged to branch early and often, there will be a lot more stuff that's not pertinant enough to list. [09:17] Also, it prevents a problem with people pushing 30 branches and having a list of 30 things that say "undescribed branch in the some_branch" dir. [09:18] My gut feeling is to rather display everything up front and then think about way to automatically show what is still relevent... [09:18] jblack: that's not how I would make them appear. [09:19] We may be desynced. I'm thinking about pushsftp branches. are you thinking about import branches? [09:19] I'm just thinking that non-described branches could be listed, but less prominently (smaller font), with no rude nagging text and an obvious link to edit the description. [09:19] jblack: we're talking about pushftp. [09:19] Import branches are all important. [09:20] Ideally, we could guess a likely landing target and put the merged branches away once they are merged. [09:20] (and if they have no description) [09:21] I suppose with good seperation hiding isn't strictly necessary. [09:21] Let's clarify assumptions: [09:21] But imagine looking at Aaron's page. He could easily have hundreds of branches a year from now, of which ony 10 may still be pertinant. [09:22] Sure. [09:22] I think it would be very sexy to have stuff publicly visible once pushed. It can give a nice "here's what is going on in the bazaar" view of a product. === Nafallo_away is now known as Nafallo [09:23] Ok. That's a fair reasoning. [09:23] to get there we cannot expect people to go out of their way and put descriptions. I expect that 95% of branches will have no description. Just because people do not care. [09:23] Exactly. [09:24] And for me personally, that would reduce the value of the 5% that were described. I would be less likely to look at somebody's branch page, knowing that 95% of that cruft is unidentifiable stuff. [09:24] To be clear, I'm not arguing a community consensus. That's strictly my own opinion. [09:25] Sure. But I think it's reasonable to assume that, for a given person, described branches are likely the few important ones. [09:25] Your opinion is important. [09:25] But thanks for clarifying. [09:26] But no, its not a requirement. [09:26] I'd like to get something real simple and with as few restrictions as possible at first, and get the bzr folks to use it. [09:26] Its a preference issue [09:26] Then we can have real user feedback. [09:26] jblack: Wouldn't you like to know that there's a branch of bzr called bzr.wowfeature by mpool? [09:26] I would like to make a more general point. [09:26] however, the way branches are currently listed is almost certainly not right. [09:27] carlos: around? [09:27] ddaa: you're approved [09:27] mdz, yes [09:27] niemeyer: Not if he hadn't cared about it enough to approve it, no. [09:27] SteveA: come on, you can do better than that! [09:27] mdz, hi [09:27] wowfeature could not be complete, or could have been a half-baked idea he abandoned. [09:27] SteveA: maybe I should put some pep8 violations in to make it more interesting? ;) [09:27] jblack: He may have approved, but just not cared to get into launchpad and put title/description. [09:27] ddaa: i made comments [09:27] ha :) [09:27] If martin meant for wowfeature to be known about by the public, he'd describe why it gets a name like "wowfeature" [09:28] SteveA: thanks [09:28] jblack: He may do that in the mailing list, rather than in launchpad.. [09:28] When I say hide, I mean from browsing, not from direct access. [09:30] jblack: I understood what you meant.. and I'm just saying that if we give users the chance to create branches without providing title/description like we're doing, most users will not care to get into launchpad just to give it a title and description. [09:30] jblack: Even though these branches are interesting for other peopl [09:30] e [09:31] Here's an idea... [09:31] niemeyer: Sure. [09:32] A person's branch listing should prominently show the 5 branches that had commits most recently, regardless of the presence of a description. [09:32] But if it displayed undescribed branches by default, if it wren't done well, I probably wouldn't go browsing for branches at launchpad unless I had to. [09:32] The signal-to-noise ratio would be too low for me to have personal use for it. [09:32] Described branches that are neither MERGED or ABANDONED would be displayed as well, regardless of freshness. [09:33] Yeah, if you have FRESHNESS, thats useful to me. [09:33] automatically hide anything either not FRESH or not described, and I'd be a happy camper indeed [09:33] ddaa: Tests for bzrsync are exploding because I'm using getUtility without first calling execute_zcml_for_scripts(). [09:33] Then the less-active and non-described branches could be on a "show other branches" page. [09:33] ddaa: Any standard way to fix it? [09:34] ddaa: Sure, with checkboxes to hide/show undescribed, hide/show merged. [09:34] jblack: I'm not thinking of setting an explicit freshness, just computing it from the metadata in the db. [09:34] I'd have a lot of uses for that. [09:35] niemeyer: I've been told to look at dyson for that. [09:35] However the backend figures out freshness... same difference to me as the likely first enduser. =) [09:35] jblack: If the "signal" is too low, having no noise doesn't help. ;) [09:35] ha, right, you mean as end user, I though you meant as developer. [09:36] jblack: now, an interesting problem, is can we guess a likely landing target for automatic hiding of merged branches? [09:36] jblack: I have no idea about what would be the right way to do it, for sure. But I wouldn't care about hidding branches before it actually becomes a problem. [09:36] niemeyer: Yes, but displaying garbage just because you don't have enough non-garbage doesn't turn the garbage into non-garbage, no? [09:37] well, let's just show the lesser garbage :) [09:37] garbageness is relative, you know [09:37] I agree. [09:37] So, how fresh is fresh? I think a month [09:37] Ha... that way... [09:38] jblack: Whatever.. [09:38] a branch with no description and a month with no commits is probably not valuable to me. [09:38] I think it's better to to show a fixed absolute number of branches. [09:38] and people should be able to mark branches stale too. [09:38] I don't agree. [09:38] Here's why: That makes somebody that works very fast difficult to track. [09:39] That also makes the garbage ratio go up for sporadic developers. [09:39] I think it should be time based. === SnakeBite [n=SnakeBit@212.25.63.37] has joined #launchpad [09:40] for example, I get to work on about half a dozen branches a month for work. [09:40] ddaa: Dyson doesn't seem to have anything interesting.. [09:40] aaron probably does many multiples of that. [09:40] SteveA: Do you know anything about that issue? [09:40] ddaa: Tests for bzrsync are exploding because I'm using getUtility without first calling execute_zcml_for_scripts(). [09:40] So a dozen things on aaron's list would only list the last 3 days of his activity. [09:41] but a dozen things on my list would show the last two months of mine. [09:41] Two things... 1. fixed number is not a problem for sporadic if it's low enough to glance at (less than 10), and date limit will cause the page to go empty with only a stupid "more branch" link [09:41] SteveA: Any standard way to fix it, besides calling the zcml loader on constructor, which could potentially break the test when used as a suite from somewhere else? [09:42] 2. very active... mh... maybe time limit would be better for those, as there can be many (say up to twenty) interesting branches for a person. [09:42] jblack: so, I'd suggest the initial listing should show max(fixed number, commited in last month) [09:42] um... don't use getUtility without first calling execute_zcml_for_scripts(). [09:42] it is the zcml that registers the utilities# [09:42] jblack: how does that sound? [09:43] jblack: A branch with 10 commits per-day which is just merging from mpool is not really interesting.. measurement of branch interest rate is a non-trivial task, IMO. [09:43] niemeyer: it is to me. It tells me which branches to track for activity. :) [09:43] SteveA: Yes, that part is already implied in the above comment :) [09:43] It also tells me which branch to branch off of. :) [09:43] any test that needs to use getUtility is by definition not a unit test. it is a functional test. so it needs a functional test set-up. [09:43] in the latest zope3 test runner, there's the concept of 'layers' to deal with this kind of requirement. [09:43] meanwhile... [09:43] but still, I did mention the ability to mark something stale, right? [09:44] niemeyer: it would not be very difficult to measure the amount of real new stuff on a branch, but it would be CPU intensive. [09:44] if it doesn't already, execute_zcml_for_scripts() should have a flag to ensure it is run only once per process. [09:44] SteveA: The getUtility is not being used in the test, but inside the BzrSync class. [09:44] right [09:44] (if it matters at all) [09:44]