[12:08] mdke: pong [12:09] spiv, oh great, hi. [12:10] spiv, we would like to get hold of a list of email addresses of users who have accounts on the wiki. how hard is that going to be? [12:10] As in, a list of email addresses of users that have ever logged in to the wiki? [12:11] spiv, well ideally, those who have ever edited the wiki, but I think we'd settle for logged in [12:11] Hmm. [12:11] in normal moin i guess it wouldn't be very hard [12:12] but i don't know what the user database looks like on our moin [12:12] Well, the changes to our moin aren't that big. [12:12] It's basically a two-step process: [12:12] so some kind of search script for /data/user/* would do the trick? [12:13] 1) extract a list of user IDs from the moin files [12:13] 2) query the launchpad database for the email addresses for those users [12:13] ok, so maybe not too bad? [12:14] For step 1, you could even trawl through the history of all edits to narrow it down to people that have edited the wiki, but that's more work than just grabbing the id of every user file :) [12:14] yeah the id way works for me [12:15] spiv, do you have any idea how long something like that would take to write for one of you super geek guys? [12:15] We'll need an admin to do step 1, I don't have access to the wiki data files (although I can help by writing a script for them to run) [12:16] the admin thing shouldn't be a problem [12:16] it's just a question of getting the script written [12:16] Not very long, let me remind myself what the data files look like :) === SteveA [n=steve@195.182.78.95] has joined #launchpad === bradb_ [n=bradb@modemcable033.209-70-69.mc.videotron.ca] has joined #launchpad === Nafallo is now known as Nafallo_away === mdke_ [n=matt@ubuntu/member/mdke] has joined #launchpad [12:25] spiv, sorry, may have missed anything you said since "remind myself what the data files look like", got disconnected [12:25] mdke_: You didn't miss anything. [12:25] ah cool === mdke_ is now known as mdke [12:25] The script for the admins to run is easy, though: "ls [12:25] bah, [12:26] "ls $moin_user_dir" :) [12:26] mdke: Do you just need this as a once-off? [12:27] yup [12:27] we can work out the exact details with elmo another time [12:27] i just wanted to find out how hard/easy it would be [12:29] spiv, is stage (2) quite easy too? [12:29] mdke: Yeah, just a simple matter of SQL. [12:30] :) [12:30] spiv, ok great, thanks for your time === doko [n=doko@dslb-084-059-078-192.pools.arcor-ip.net] has joined #launchpad [01:15] bradb: ping [01:15] doko: hi [01:16] sorry, I strongly disagree on #3882 [01:17] doko: Why? [01:17] the whole distro team does work this way: work on one aspect on one package, and then go on to the next one. If I have to subscribe to each package I apply a fix ... that's just administration effort [01:18] doko: You don't have this feature in Bugzilla, AIUI, right? [01:18] bugzilla is not the measure === SteveA [n=steve@195.182.78.95] has joined #launchpad [01:20] if I look at debian, they some kind of this feature implemented. it's not just a malone thing. it's about tracking of an upload you make, and taking responsibilty about it. currently I have to poll many different sources for this information: [01:21] doko: I'm not saying your suggestion is a bad one, only that you're the only person I've heard ask for it and, IMHO, it would add more complexity than benefit. [01:21] people.ubuntu.com/~lamont/buildLogs, bugzilla/malone, anastacia output, colin's dapper-probs, etc ... [01:22] doko: How would Malone know when to subscribe you? Can it make these kinds of assumptions for every upload done to Malone? How would it know when to unsubscribe you? [01:23] bradb: because everybody just polls this information, which seems to be a ridicoulous waste of resources. [01:24] doko: Okay, let's walk through this. First question: how would Malone know when to subscribe you to all bugmail for a package? [01:24] SteveA: ping [01:24] bradb: launchpad should know about the uploader field, so that is the information you need. for unsubscription: either unsubscribe when somebody else uploads the package, or terminate the subscribte after some fixed time [01:24] bradb: subscribe: when somebody makes an upload [01:25] doko: Would that assumption be a helpful one for the majority of cases? [01:26] where upload is: upload signed by this person (which probably will not cover sponsored uploads, I'll have to check this) [01:26] spiv: ping [01:27] bradb: yes, manual uploads are usually signed by the people who work on the packages. exceptions are syncs from unstable and sponsored packages [01:28] doko: Okay, so will most developers want to start getting bugmail from packages at the moment they do an upload of that package? [01:29] we surely can formalize syncs from unstable. for sponsored uploads, we could maybe subscribe the sponsor (uploader) and the person in the changelog [01:30] bradb: yes, I think that would be helpful. that would elminate the work done by a bug master (currently mdz) assigning bugs to members of the distro team [01:31] bugs are one aspect, but this kind of sbscription feature should cover all other information related to a package [01:31] doko: And will it be the most helpful option to have Malone unsubscribe developers as pkg bug contacts automatically when someone else does an upload of their package? [01:32] s/their/the/ [01:33] bradb: that's one point to discuss. I'm not sure about it. I surely do not want to last the subscription forever. therefore the proposal to terminate the subscription after some time, or terminate it after the next upload done by another person [01:34] doko: What if the person were actually a pkg bug contact by choice as well? [01:34] then the point of contact has priority [01:34] This is the kind of complexity to which I'm referring? [01:35] er, s/\?/:)/ [01:36] From this other questions fall out about the complexity: can a user turn this off? If so, how? How do we communicate clearly to the developer why they suddenly started getting bugmail, and also somehow let them know that it won't continue forever, and don't-worry-we'll-auto-unsubscribe-you-soon-enough, etc? [01:36] I know ... please see it from my side. currently I have to poll several sources of information for each package I touch. a) that's work which can be automated b) if I forget/make mistakes, nobody will notice (at least for some time) === lifeless raises the spec flag [01:36] s/user/developer/ [01:37] doko: I agree fully with you that wasting your time is bad. [01:37] lifeless: pong [01:37] this may be more effective if a spec with use cases is worked through [01:37] that will make clear whats involved, and let other folk put in feedback, whereas IRC conversation is markedly opaque [01:37] spiv: yoyoyo [01:37] spiv: in DB interfaces [01:38] are related things like 'owner' normally presented as the object or as the underlying db type. [01:38] i.e. in IFoo [01:38] lifeless: agreed, but IMO there are use cases in the report. I'm just happy about the status change for needinfo->rejected [01:38] if there is an 'owner', and I have something implementing IFoo, would we expect thing.owner to be an 'int' or a 'IPerson' [01:38] lifeless: The object. So 'owner' would typically be something providing IPerson, for instance. [01:39] + owner = Int( [01:39] > + title=_('Owner'), required=True, readonly=True) [01:39] so that looks wrong to you? [01:39] Yep [01:39] Should be a ForeignKey. [01:39] yay [01:39] bradb: I agree that it would be not a minor change to malone/launchpad. should we make this discussion on a mailing list as well? [01:39] Oh, interface. [01:39] But yeah, not Int :) [01:40] doko: Sure. [01:40] doko: Do you want me to forward the information somewhere, and where would you prefer to have the discussion take place? (I'm not sub'd on any Ubuntu lists, FWIW.) [01:42] bradb: I think ubuntu-devel would be appropriate, let's prepare that mail, it's not that urgent. start of January should be fine [01:42] lifeless: Look at IBugSubscription, for instance [01:42] spiv: its ok [01:42] spiv: I needed to check the expected state, not the 'occuring state' [01:42] doko: Can non-subs post to that list? [01:42] spiv: which is why the source wasn't good enough ;) [01:43] spiv: thanks ! [01:43] bradb: if jdub takes care of these post, yes. so better subscribe ;-) [01:43] lifeless: Well, IBugSubscription's person attribute looks like what I expect :) [01:44] thanks [01:44] s/post/posts/ [01:47] doko: Hm, I'd rather not subscribe to the list just to get mail about this one thread. I wonder if you'd be happy with this solution: 1. I move the bug report back to "New", 2. You mail ubuntu-devel asking for input on the feature request and Cc me. Is that reasonable? [01:47] spiv: IBugSubscription exposes the bug number rather than the bug. [01:47] spiv: that seems wrong to me. [01:48] spiv: going off what we just discussed [01:48] spiv: while I have your attention, is exposing the 'id' de rigeur ? [01:48] bradb: ok. I'll prepare an email. let us polish that email until we agree on the points we disagree [01:50] lifeless: Hmm, there is a BugVocabulary, but it appears to be unused. I wonder why. [01:50] doko: Sure. BTW, it's not that I "disagree" with your time being important and that Malone should help reduce your development burden as much as possible, only that adding this feature would add a lot more complexity than benefit for most users, IMHO. But, I look forward to enlightenment from your email. ;) [01:51] (I guess because Int works well enough...) === thierry [n=thierry@modemcable084.72-131-66.mc.videotron.ca] has joined #launchpad [01:52] spiv: well it applies force on IBug to show the db id [01:52] spiv: as we are punning the number and db id [01:52] spiv: anyway, is showing the 'id' usual ? [01:53] or is it explicitly thought through each time ? [01:53] lifeless: To be honest, I'm not sure. [01:54] ok [01:54] And a quick survey of the existing code gives inconsistent results ;0 [01:54] doko: I marked the bug as "New" again, btw. Thanks for your feedback, and I'm looking forward to hearing what u-d says about it. [01:55] bradb: mailman allows you to "subscribe", but mark your subscription as "no mail". [01:55] spiv: Indeed. How would that help here? [01:55] bradb: So you can post unrestricted, without being flooded with mail. [01:55] Ah, ok, good point. [01:57] I think doko will do the best job of selling his feature request to u-d. [01:58] Fair enough. [01:59] lifeless: BTW, my code has spent all day in the #1 spot in pqm by now. It seems like the 40 min estimate earlier may have been optimistic. [02:00] Er, "upwards of 40 minutes or more", but that was two and a half hours ago. :) [02:00] bradb: I said upwards for a reason [02:01] bradb: this is what sftp push in bzr does at the moment [02:01] bradb: its extremely inefficient [02:03] right [02:04] FWIW, I hate whining about pqm and I'm mostly surely a pest about it, but I dislike even more not being able to do my job. [02:09] right [02:09] so right now, how is it blocking you ? [02:14] lifeless: I need to get at the most recent code in Launchpad to fix the tests and conflicts in my bug status changes branch. I could do a sideways merge, but you said earlier that I can't necessarily trust that. [02:14] bradb: I suggested you do one [02:15] bradb: the trust is whether pqm succeeds in its push or not [02:17] Ok, I'll do one tomorrow if for some reason I still don't have access to that revision in my usually rsync launchpad-upstream => local merge workflow. [02:19] It's all literally blocking me in the sense that if I'd done that and submitted it immediately after seeing that all the tests pass, it'd still be #3 in pqm's queue right now. This two patches I'm getting through right now are kind of particularly critical to land before causing painful conflicts in almost any other Malone changes. [02:19] unfortunately I cannot make it faster [02:19] this is where the tech is at at this point [02:19] the bzr group are working very hard to get improvements in place. [02:21] bradb: I'll update my bugzilla default assignees migration script to work with the initial-bug-contacts stuff [02:22] jamesh: Ok, great, thanks. === kjcole [n=kjcole@pchb1f.gallaudet.edu] has joined #launchpad === bradb heads off, later === bradb [n=bradb@modemcable033.209-70-69.mc.videotron.ca] has left #launchpad [] [02:26] Did you guys see http://geekz.co.uk/lovesraymond/archive/clique? [03:36] shuttleworth foundation empire [03:36] ;) === sevrin [n=sevrin@202.75.186.154] has joined #launchpad === stub [i=stub@sweep.bur.st] has joined #launchpad === robitaille [n=robitail@ubuntu/member/robitaille] has joined #launchpad === robitaille [n=robitail@ubuntu/member/robitaille] has joined #launchpad [06:30] jamesh: ping [06:30] jblack: pong [06:30] I think your http://people.ubuntu.com/~jamesh/bzr.smallfixes branch may be borked [06:30] jblack: oh? [06:31] bzrlib.errors.MissingText: Branch http://people.ubuntu.com/~jamesh/bzr.smallfixes is missing revision robertc@robertcollins.net-20050919060519-f582f62146b0b458 of cacheremoterevisions.diff-20050615041652-ec41056afda8ec11 [06:31] that's unfortunate [06:31] ohhh.... [06:31] orrr.. [06:31] the supermirror bzr may be too old [06:31] I don't think there are any unmerged revisions in that branch though [06:31] s [06:44] Nope. [06:44] That won't do it. [06:44] jamesh: Can you branch yourself? === jamesh tries [06:45] jblack: "bzr branch" seems to work with my local copy of the branch === jblack tries starting over. [06:47] jblack: I'm just pushing the branch again [06:47] my local copy includes some extra revisions I'd pulled from bzr.dev [06:49] finished pushing [06:50] thanks [07:07] jamesh: I think you may need to reweave your branch [07:08] Which I can provide instructions for === ubuntulog [n=ubuntulo@port49.ds1-van.adsl.cybercity.dk] has joined #launchpad === Topic for #launchpad: launchpad.net | developer meeting: Thur 22 Dec, 1200UTC (wiki:MeetingAgenda) | launchpad-users@lists.canonical.com (wiki:MailingLists) | Channel logs are here: http://tinyurl.com/72w39 === Topic (#launchpad): set by lifeless at Tue Dec 20 07:52:46 2005 [09:25] (SteveA/#launchpad) although, there are other forms for multiple men or men and women, and for multiple women [09:25] (sivang/#launchpad) eh, niec [09:25] (sivang/#launchpad) *nice [09:26] (lifeless/#launchpad) thats getting seriously kinky [09:26] (sivang/#launchpad) lifeless: lol :) === eruin [n=eruin@unaffiliated/eruin] has joined #launchpad [09:28] SteveA: seems that Lithuanian is very specific language [09:32] SteveA: were you pinging or just wasving ? [09:43] lifeless: you pinged earlier, when i was asleep === tuhl [n=tuhl@p5498D893.dip.t-dialin.net] has joined #launchpad [09:47] mmm, did I [09:47] oh right [09:47] style for interfaces. spiv helped me === carlos [n=carlos@23.Red-83-55-110.dynamicIP.rima-tde.net] has joined #launchpad [10:08] morning [10:08] carlos: Hola [10:08] sivang, hola! === fabbione [n=fabbione@port49.ds1-van.adsl.cybercity.dk] has joined #launchpad === jinty [n=jinty@205.134.224.215] has joined #launchpad === lamont [n=lamont@mix.mmjgroup.com] has joined #launchpad [10:27] sivang: for example if you're greeting a group of young women, "sveikos panels!" would be "hello girls!" === mdke writes that down [10:32] i meant, "sveikos panels" means "i smell of donkeys" [10:36] thats not MY donkey [10:37] that will work on the ladies [10:38] well, it won't work on *all* the ladies === SteveA decides to get out of this conversation, and go to lunch instead [10:48] SteveA: LOL === fabbione [n=fabbione@port49.ds1-van.adsl.cybercity.dk] has joined #launchpad === koke [n=koke@ubuntu/member/koke] has joined #launchpad === stub [i=stub@sweep.bur.st] has joined #launchpad === stub [i=stub@sweep.bur.st] has joined #launchpad [11:45] jamesh: So you had no luck with that odd foaf pagetest failure? [11:46] stub: I've added a couple of syncUpdate() calls in places that look like they need it [11:47] and I can't reproduce it anymore, but that might not mean it is solved [11:47] jamesh: Have these landed? We could reproduce consistantly on the PQM box for no apparent reason [11:48] jamesh: I was going to attack the problem with pdb thought I better ask in case I was wasting my time [11:48] stub: no. They're in my select-results-len-fix branch [11:48] ok. I might merge that in and see what happens on balleny [11:48] stub: search for syncUpdate() for the bits that might be the culprit [11:49] it might be easier to just pick out the hunks in question [11:49] there are two hunks which add syncUpdate() calls [11:51] ping Daniel Silverstone | Steve Alexander === Deepa [n=deepy@bb-dhcp-85-11-204-88.ornskoldsvik.com] has joined #launchpad [11:52] can you no longer get free ubuntu CD's? [11:53] Deepa: Sure - https://shipit.ubuntu.com [11:53] oops my mistake :P [11:53] i was searching around on launchpad.net XD === thisfred [n=thisfred@a80-127-80-154.adsl.xs4all.nl] has joined #launchpad === salgado [n=salgado@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [12:06] stub, around? [12:07] yes === poningru [n=poningru@pool-68-238-172-74.tampfl.fios.verizon.net] has joined #launchpad [12:07] stub, do you have a couple minutes to take a look at my DB patch for mirror management (https://chinstrap.ubuntu.com/~dsilvers/paste/filei41vyp.html)? === matsubara [n=matsubar@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [12:09] good morning! [12:10] salgado: Should distributionmirror.name have a constraint, or is any old rubbish acceptible as the name? [12:10] stub, it needs the valid_name constraint. I added it in the interface but forgot to add here [12:11] Are there comments available? [12:11] not yet, I forgot them again. will write now, though [12:17] salgado: What is an rsync_base_url look like? [12:18] c/is/does [12:19] stub, I expect it's something like rsync://host.tld/some/path === Seveas [n=seveas@ubuntu/member/seveas] has joined #launchpad [12:21] salgado: Ok. Just wanted to make sure it was really a url and not foo.domain:whatever syntax [12:21] speed > 0 ? [12:21] salgado: ^^ [12:21] Or is that a dbschema [12:21] yep [12:21] dbschema [12:22] and content dbschema? [12:22] yes [12:25] salgado: MirrorProbeRecord has a NULLable date_created? Is that correct? [12:26] and no default [12:26] no, it's not. it should default to NOW and be not null. my fault === stub tests out his updates [12:50] salgado: https://chinstrap.ubuntu.com/~dsilvers/paste/filee4kUpc.html [12:50] salgado: Approved patch-40-13-0.sql pending addition of good comments [12:50] stub, great. thank you === cprov [n=cprov@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [12:53] morning ... === bradb [n=bradb@modemcable033.209-70-69.mc.videotron.ca] has joined #launchpad [01:00] tick. tick tock [01:00] it's meeting time! [01:00] SteveA: new items for the agenda === niemeyer_ [n=niemeyer@201.23.160.9] has joined #launchpad [01:01] I have a hunch I know what [01:01] thanks lifeless [01:01] MEETING TIME [01:01] who is here today? [01:01] me [01:01] I am [01:01] me [01:01] I am here in body [01:01] moi [01:01] me [01:01] me [01:02] me [01:02] me [01:02] ME [01:02] I am [01:02] sorry for the caps [01:02] kiko is on vacation [01:03] ddaa is on vacation too [01:03] stub? [01:03] me [01:03] Kinnison is on vacation, I think [01:03] me [01:03] he is, yes [01:03] hi fabbione [01:03] i am always here [01:03] Here [01:03] MHUAAA [01:03] * Roll call [01:03] * Agenda [01:03] * Next meeting [01:03] * Activity reports [01:03] * Items from last meeting [01:03] * Production / staging (stub) [01:03] * Requiring tests for merges. (lifeless) [01:03] * Keep, Bag, Change [01:03] * Three sentences [01:03] [01:04] next meeting, 5 january, okay? [01:04] ya [01:04] fine with me, I'll still be on leave ;) [01:04] aye [01:04] yep === ..[topic/#launchpad:SteveA] : launchpad.net | developer meeting: Thur 5 Jan, 1200UTC (wiki:MeetingAgenda) | launchpad-users@lists.canonical.com (wiki:MailingLists) | Channel logs are here: http://tinyurl.com/72w39 [01:04] ok. I should be there (I fly back from Penang in the morning on the 5th) === beyond [n=beyond@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [01:05] activity reports: how's all that going? [01:05] Fine [01:05] up to date === SteveA hasn't sent one for a while. new year's resolution, perhaps... === daf just caught up [01:05] up to day [01:05] I'm two days behind with the activity reports [01:06] I'm up to date [01:06] up to date [01:06] up to date === jamesh is not === cprov is up to date === bradb is up to date [01:06] I'm up to date, I think [01:06] I'm behind. [01:06] * items from the last meeting [01:06] i've been slack with the meeting summary from last week [01:07] * RobertCollins to set up a bzr-for-launchpad meeting at a different time to the launchpad developers meeting. [01:07] oh yea, right. [01:07] * Kiko to set up a launchpad community meeting. [01:07] I've been 'getting to that' all week. [01:07] kiko's away, but this hasn't happened still [01:07] * Steve to announce the production of last week's summary on the launchpad-users mailing list. [01:07] no summary, no announcement :-/ [01:08] And me or Steve should schedule an infrastructure meeting when people are back from hols [01:08] there was a wiki page set up for bzr-for-launchpad-development priorities [01:09] i need to do some prioritization there [01:09] mpt wrote a proposal about product groups / projects [01:09] which now needs further discussion [01:10] i think that's it [01:10] i'd like to note that kiko and i now have access to change priorities on the admins' RT queue [01:11] or rather, on the launchpad tasks queue in RT [01:11] Do you have time to describe the intended process a little? [01:11] this should give us a better quality of service for the things that are immediately important [01:11] the intended process of getting admins to do RT stuff? [01:11] Of getting a bump [01:12] It went rough when you and I tried, because you didn't have the bug yet? [01:12] https://rt.admin.canonical.com/ === sivang is here [01:12] you can view the launchpad queue there [01:12] the username and password is the same one as for the wiki [01:12] the internal canonical wiki, that is [01:13] so, when you add an rt issue, it gets put into a "pending classification" queue, that is not public [01:13] salgado: MM spec was updated with your answers [01:13] when an admin has classified it, and put it in the 'launchpad' RT queue, then I or kiko can change its priority, and also change it in other ways [01:14] i'm using a priority of 99 to mean "this should be the next thing in the admins' queue" [01:14] and working down from there [01:14] the idea is to have urgent things or blocking things registered with a priority of 99 [01:14] and to have a mix of quick and longer-term things there [01:14] jblack: does that answer your question? [01:15] How do you want to be requested? [01:15] in order to make something a high priority, i need to understand why it is important [01:15] strictly email? both email and irc? [01:15] email or irc is okay [01:15] irc, when i'm here and listening [01:16] email when i'm not, and whenever [01:16] Thanks [01:16] an email saying "RT issue X is important!" isn't much use unless we've already discussed that issue being important [01:16] so, it's important to communicate the rationale [01:17] * Production / staging (stub) [01:17] Asuka (the server) was upgraded to breezy and PostgreSQL 8.0 earlier today. Expect it to be unavailable for the next few days as I test out PostgreSQL 7.4 -> 8.0 migration procedures and iron out the bugs. [01:17] Gina has been run on production. Yay. Might need some love from the publishing scripts to be useful, as Gina just creates 'PENDING' packages. [01:17] and let's talk about the gina run and bugzilla imports too [01:17] are we using the launchpad dependencies package in production? [01:18] Production update will happen Tuesday from head as of now, unless people require otherwise. [01:18] As far as I'm aware, we are not using the launchpad dependencies package in production. That is elmo and Znarl's turf really. [01:18] we should be using it [01:18] I just put some updates for ErrorReportManagement up for review. It might be nice to have that rolled out === stub isn't using it either... not sure where to install it from [01:18] we should all be using it on our systems too === sivang is using it === carlos too [01:19] stub, universe [01:19] what's the name of the package? [01:19] jamesh: ok. I'll consider rolling out that revision when it lands. [01:19] SteveA: launchpad-dependencies === duchier [n=duchier@AOrleans-152-1-70-232.w86-195.abo.wanadoo.fr] has joined #launchpad [01:20] SteveA: and launchpad-database-dependencies [01:20] thanks [01:20] steve@einheit:~$ apt-cache policy launchpad-dependencies [01:20] W: Unable to locate package launchpad-dependencies [01:20] maybe it is only for dapper [01:21] it's in dapper/multiverse [01:21] i'll file an RT issue to ask the admins to use that package [01:21] heh... it tells me I don't have bison and ncompress ;) [01:21] I see it - probably it is in -backports or something [01:22] on gina and bugzilla imports [01:22] i'm concerned about the packages not being visible in the web app [01:22] i don't know what needs to run to make them so [01:22] i think we should not run the bugzilla import until these things are actually visible [01:22] cprov: do you know anything about this? [01:23] SteveA: not much about bugzilla-import touched the code yesterday ... [01:23] otherwise, i'll try phoning people who aren't here [01:23] (launchpad packages are in breezy-updates) [01:23] cprov: do you know what we need to do to get packages showing up in the web pages of launchpad? [01:23] Merge to devel/launchpad: [r=bjornt] Soyuz/Buildd UI fixes, introducing batched list and ordering soyuz tests. (r2934: Celso Providelo) [01:24] SteveA: but of course we need a publisher run after gina imports to have "visible" pkgs === duchier [n=duchier@AOrleans-152-1-70-232.w86-195.abo.wanadoo.fr] has left #launchpad [] [01:24] SteveA: they need " publishing" transition from PENDING to PUBLISHED [01:25] so that's another script for stub to run? [01:25] i'll see if i can talk with kiko later [01:25] SteveA: I'm not sure about the current status of RF publisher, but it works fine from my branch [01:25] I think that requires Daniel in fact [01:25] scripts/publish-distro -Cvv -d ubuntu [01:25] kiko will be able to say if it is okay to run on production [01:26] ok. We have backups ;) [01:26] it will mode all PENDING to PUBLISHED and obviously create an archive [01:26] DoIt :) [01:26] on this subject, https://wiki.launchpad.canonical.com/BugzillaImportProcess [01:26] move not mode [01:26] cprov: We should probably talk about that branch integration at some point [01:26] a-moving on with the meeting... [01:26] * Requiring tests for merges. (lifeless) [01:26] niemeyer_: NOW ;) [01:26] cprov: I mean, with Steve [01:27] requiring test coverage in commits. Brought up by kiko two weeks back, has my complete support. The idea is that reviewers will be allowed to say [01:27] 'this cannot be merged' based on test coverage, irrespective of other criteria. [01:27] niemeyer_: right, it probably requires some review team love [01:27] this needs lp management to say 'ok' before I can ask the review team to enforce it [01:27] or its just dog-wagging. [01:27] i'm more in favour of cat-swinging [01:27] so +1 from me [01:28] it has my +1. [01:28] what does it need ? [01:28] how about adding needs-tests as a pending reviews status [01:28] (on cat swinging, see http://en.wikipedia.org/wiki/Cat_o%27_nine_tails) [01:28] please ping me when we discuss product-groups instead of projects..I have to attedn to something in the office :-/ [01:29] why the new state ? [01:29] sivang: that's not on the agenda today [01:29] I mean, the new tests will need review [01:29] so its no different to 'not ready yet' from my perspective [01:29] SteveA: ah, ok. thanks [01:29] i suggested it so that the fact that it's good to go except for tests is made clear [01:29] i'm not attached to the idea [01:30] quite possibly, it needs nothing other than a note in the reviewer guidelines [01:30] I'll add that to the next review meeting as a specific process question [01:30] ok [01:30] so - we have the go ahead on this ? [01:30] also [01:30] i'd encourage people to ask those who are good with tests, for help on how to write good tests for a branch [01:30] while the branch is being worked on, even at the start [01:31]