#launchpad-meeting 2006-07-24
<mpool> hullo
<mpool> are we here?
<spiv> I am.
<lifeless> dudes and dudettes
<mpool> ah
<ddaa> Hello, sorry for being late to the meeting, we're chatting with sabdfl now
<lifeless> are we ?
* lifeless thought sabdfl was on leave :)
<ddaa> everybody please get acquainted with https://launchpad.canonical.com/BazaarMeetingAgenda while i'm answering a call of nature
<spiv> ddaa: is my proposed item on the agenda?
<spiv> ddaa: you probably want to subscribe to that page :)
<ddaa> subscribed
<ddaa> sabdfl interrupt
<SteveA> spiv: hi
<SteveA> I'm interested in how the smartserver work is going
<lifeless> its coming along nicely
<lifeless> all transport tests are passing, and a number of the bzrdir interface conformance tests.
<lifeless> we're refactoring/extending some infrastructure at the moment to accomodate it better
<spiv> I haven't actually been involved in the smartserver work recently, I've been doing other things.  I should organise another day with mpool.
<SteveA> I don't know the plan for it, so while this is very interesting, it doesn't give me a picture of how things are going.   What's the one sentence goal, and how much is left towards that goal?
<lifeless> uhhh
<lifeless> what metric are you hoping for the answer to be in ?
<mpool> the goal is to push & pull over smartserver over ssh, and have it be much faster than sftp
<mpool> i would say we are in the middle third of the work
<mpool> we plan to release it in august
<mpool> lifeless: do you concur, doctor?
<lifeless> I think that fits
<SteveA> when you say "release", does that mean release as open source kind of release, or release to internal testing for launchpad / supermirror ?
<SteveA> does it require a new bzr release?
<lifeless> it will be a new bzr release
<lifeless> its not a separate product
<mpool> yes, at least in the main public bzr.dev tree, hopefully in an actual released tarball
<mpool> SteveA: i've spoken to sabdfl about this and heard no suggestion we needed private testing - do you know something i don't?
<lifeless> SteveA: integration with launchpad/supermirror is a second-stage feature. Its been designed with spivs input to allow that to take place, but its not being implemented in parallel at this point. Though that may be an idea.
<SteveA> okay
<SteveA> I just talked with mark, and this is all fine
<spiv> Implementing in parallel would probably help uncover unexpected issues.
<SteveA> I'd like to get the smartserver used on the supermirror for the "launchpad 1.0" october release
<SteveA> so, we should do some planning of that sometime
<mpool> spiv: yes, i'd like to keep you involved 
<lifeless> SteveA: did you have some different expectations ?
<SteveA> I had unformed expectations
<mpool> SteveA: seems like it would be nice if spiv can take responsibility for the lp side of that
<mpool> as he is so far
<SteveA> I had no idea how big/long/hard/uncut a task the supermirror would be
<SteveA> s/supermirror/smartserver/
<mpool> is there anything about say planning of it that he would need to know but doesn'tt?
<SteveA> he being mark?
<lifeless> http://samba.org/~jelmer/bzr/bzr-git-kernel.png
<lifeless> ^^ awesome :)
<lifeless> should we cancel this meeting ?
<lifeless> I have another in 30 minutes
<mpool> he in that sentence being spiv?
<mpool> s/\?//
<mpool> ok, let's keep moving on
<mpool> i'll talk to stevea afterwards if that's ok
<SteveA> ah, you're in a meeting
<SteveA> I hadn't realize
<SteveA> d
<lifeless> ddaa is meant to be here
<SteveA> anyway, thanks for the status update.
<mpool> *acion* spiv, lifeless, mbp will meet this week
<SteveA> mark is happy
<SteveA> ddaa is sprinting with jamesh
<lifeless> but I understand mark to be talking with him
<SteveA> is there anything in particular you need from ddaa?
<lifeless> hes the meeting chair :)
<SteveA> lifeless: would you take on that role for this meeting?
<ddaa> yeah, I'm coming
<lifeless> sure
<ddaa> okay I'm here
<SteveA> thanks lifeless 
<lifeless> meeting agenda coming up in 10
<lifeless> (seconds)
<lifeless> Usual introduction *      roll call *      production status
<lifeless> Current focus
<lifeless> *      SFTP advertising *      vcs-import knits *      cscvs/bzr-native *      supermirror branch browser *      private branches *      cscvs/svn-symlinks *      dyson *      About 9% of hosted branches are empty directories -- are people finding SFTP service too hard to use? (spiv)
<lifeless> Usual end
<lifeless> *      other meeting actions *      critical bugs *      pending sysadmin tasks *      any other business
<lifeless> meh
<lifeless> silly toolchain
<ddaa> -EUSER
<spiv> lifeless: hey, it's more compact that way ;)
<ddaa> So, lifeless, spiv, mpool are here.
<lifeless> Usual introduction *      roll call *      production status
<lifeless> Current focus
<lifeless> *      SFTP advertising *      vcs-import knits *      cscvs/bzr-native *      supermirror branch browser *      private branches *      cscvs/svn-symlinks *      dyson *      About 9% of hosted branches are empty directories -- are people finding SFTP service too hard to use? (spiv)
<lifeless> Usual end
<lifeless> *      other meeting actions *      critical bugs *      pending sysadmin tasks *      any other business
<lifeless> nope, GARH
<ddaa> Jamesh, ddaa, SteveA are mostly here and being periodically NMUed by sabdfl
<lifeless> Usual introduction
<lifeless>     *      roll call
<lifeless>     *      production status
<lifeless> Current focus
<lifeless>     *      SFTP advertising
<lifeless>     *      vcs-import knits
<lifeless>     *      cscvs/bzr-native
<lifeless>     *      supermirror branch browser
<lifeless>     *      private branches
<lifeless>     *      cscvs/svn-symlinks
<lifeless>     *      dyson
<lifeless>     *      About 9% of hosted branches are empty directories -- are people finding SFTP service too hard to use? (spiv)
<lifeless> Usual end
<lifeless>     *      other meeting actions
<lifeless>     *      critical bugs
<lifeless>     *      pending sysadmin tasks
<lifeless>     *      any other business
<lifeless> thats better
<lifeless> ddaa: SteveA has asked me to chair to allow you to be NMU'd
<lifeless> production status : anyone have issues to report?
<lifeless> 5
<lifeless> 4
<lifeless> 3
<lifeless> 2
<ddaa> problem with samba branches
<lifeless> 1
<ddaa> apparently jelmer's plugin is producing revisions that get through the branch puller
<lifeless> with the scanner ? there is a bug report I believe.
<ddaa> but cause the branch scanner to crash
<lifeless> ok. who has the backtrace? can they enlarge on the bug report ?
<lifeless> ddaa: is that you ?
<lifeless> or jamesh or spiv ?
<spiv> Anyone that gets the launchpad-errors-reports email.
<ddaa> one of the responsibilities of the branch puller is to sanitize the data so that would not happen
<lifeless> ok, spiv can you do that ?
<spiv> I've replied to the bug already with the exception (though not the full traceback)
<lifeless> ok, any other production errors ?
<spiv> It died in get_revision, claiming invalid XML iirc.
<lifeless> ddaa: this is a decision meeting not a design meeting
<lifeless> ddaa: please discuss the detail in the bug report
<ddaa> I'm not having a design discussion.
<ddaa> no other issue
<lifeless> well you're assuming the data is invalid, it may be skew between systems for instance.
<spiv> (bug 53825, for the record)
<ddaa> no other important issues that I'm aware of, at least
<lifeless> spiv: can you do this examination please ?
<spiv> lifeless: I've already followed up on the bug, do you want me to dissect it further?
<lifeless> I will eyeball it and comment
<lifeless> ok, sftp advertising
<lifeless> this was in ddaa's queue IIRC
<lifeless> ddaa: status  ?
<ddaa> actions from last meeting:
<ddaa>    * ddaa to tell jdub about existing blog entry
<ddaa>    * jamesh to blog about team-shared branches and using them with checkouts 
<lifeless> actually, jamesh was to blog on it
<lifeless> the agenda is not detailed enough.
* lifeless fixes
<jamesh> I haven't written the article yet
<ddaa> I did the first one, did not observe any resulting effect
<ddaa> jamesh: still planning to do it, or want to hand it over?
<jamesh> Still planning to do it
<lifeless> ok
<lifeless> vcsimports knits
<ddaa> action from last meeting
<ddaa> * ddaa to file bug about converting existing vcs-import branches to knits. 
<ddaa> mh
<ddaa> do not remember clearly
<ddaa> looking
<ddaa> https://launchpad.net/products/launchpad-bazaar/+spec/vcs-imports-knits-upgrade
<lifeless> ok
<lifeless> who is moving this forward - you ?
<ddaa> I would like feedback on that spec
<lifeless> ok, jamesh - could you review it while you are at the sprint?
<jamesh> okay
<lifeless> seems like a good use of the face time
<lifeless> ok
<lifeless> bzr-native
<lifeless> ddaa: that seems to be coming along well. 
<ddaa> feedback has bee requested from lifeless, jamesh and steve
<jamesh> we've been discussing the importd changes a bit this morning
<lifeless> on bzr-native ?
<ddaa> feedback on vcs-imports-knits-upgrade has been requested
<ddaa> we discussed bzr-native this morning
<ddaa> got to order food
<lifeless> ok, in progress. cool
<lifeless> branch browser
<lifeless> spiv: ?
<ddaa> action from last meeting:
<ddaa> * spiv to have a pre-impl call with SteveA
<spiv> No progress worth reporting.  It's my top priority for this week.
<spiv> Oh, I had that call.
<lifeless> ddaa: please dont blat the actions list, we've all read the page
<ddaa> nice, make it rock
<spiv> And the mail sent to the list by Steve outlines the plan.
<lifeless> spiv: do you have an expected time of completion ?
<lifeless> spiv: like 'august' ?
<lifeless> spiv: ?
<spiv> lifeless: That seems a reasonable estimate.  Ask me again next meeting for a firmer answer.
<lifeless> ok. for the next meeting, have an answer :)
<lifeless> private branches:
<ddaa> ACTION: spiv to give delivery estimate for branch browser
<lifeless> still in spec form. I have feedback to give. Steve has updated the spec.
<lifeless> to be clearer - a terminology change
<lifeless> svn-symlinks.
<lifeless> ddaa: is that rolled out ?
<ddaa> lifeless: jamesh has rolled out
<ddaa> hu
<ddaa> has committed
<ddaa> I rolled out
<ddaa> It rocks
<lifeless> cool
<lifeless> dyson:
<lifeless> jamesh has got it working from behind the proxy
<jamesh> stub reported a new bug
<lifeless> stub has yet to trial it again on staging. expecting that soon
<lifeless> ahha!
<jamesh> https://launchpad.net/products/launchpad/+bug/53698
<lifeless> I did not notice that
<jamesh> it failed when scanning a GRASS cvs snapshot tarball
<jamesh> because the version number component of the tarball did not match the DB constrainyt
<lifeless> 6.1.cvs_src_snapshot_2006_07_15  being the string
<ddaa> "dyson blows on grass"
<jamesh> I guess valid_version() is looking for valid debian version numbers
<jamesh> which wouldn't like the underscores
<lifeless> jamesh: can you please talk this over with Mark ? 
<jamesh> okay
<lifeless> jamesh: its in the product registry area which I know he cares about
<lifeless> I think representing what upstream does in ProductSeriesRelease is important, my vote is to loosen the constraint for this table.
<lifeless> hosted branches:
<lifeless> About 9% of hosted branches are empty directories -- are people finding SFTP service too hard to use? (spiv)
<lifeless> spiv: ?
<lifeless> ddaa: can you prep a critical bugs list please.
<ddaa> One of the problem with the sftp service is that once a branch has been created, if you did not create a proper branch the first time, for some reason, then you are screwed
<lifeless> ddaa: as i dont have one ready
<mpool> right
<spiv> I got stub to add some stats about branches to cricket.
<mpool> can i suggest we discuss this (empty branches, lp use, etc) on the lp list please?
<lifeless> yes.
<lifeless> I think 10% is uncomfortable, and discussion is needed.
<spiv> Sure, I can move this to the list.
<lifeless> any other meeting items ?
<lifeless> 5
<lifeless> 4
<lifeless> 3
<lifeless> 2
<lifeless> 1
<lifeless> ok
<lifeless> critical bugs:
<lifeless> ddaa: do you have a list handy ?
<ddaa> doing
<lifeless> we will come back
<lifeless> pending sysadmin tasks?
<ddaa> critical bugs:
<ddaa> 31308: cannot set branch associated to productseries: lifeless to spec
<ddaa> 37897: renaming breaks vcs-imports: david to do something about it
<ddaa> basically, no progress on that
<lifeless> ok, no change on those.
<lifeless> pending sysadmin tasks.. anyone got stuff to nag about ?
<ddaa> and 51130
<lifeless> 5
<lifeless> 4
<lifeless> 3
<lifeless> 2
<lifeless> 1
<lifeless> ok
<lifeless> any other business? or meeting over time
<lifeless> 5
<lifeless> 4
<lifeless> 3
<lifeless> 2
<lifeless> 1
<lifeless> meeting over, thanks
<lifeless> see some of you in 9 minutes for the review meeting
<lifeless> mpool: can you do me a favour  ?
<lifeless> mpool: collate the irc log into a minutes for the meeting?
<lifeless> I need to prep my meeting
<mpool> sure
<lifeless> thanks
* ddaa goes out from a cig and some coffee
<ddaa> s/from/for/
<jelmer> sorry, hope I'm not too late
* ddaa wakes up
<ddaa> sorry was meditating about bugs, branches and revisions
<jelmer> (-:
<ddaa> jelmer: sabdfl wants us to reconcile your work and importd
<ddaa> he said, essentially "I sponsored jelmer work for the ability to commit to subversion, but I want it to work with our existing import system"
<jelmer> ddaa: Reconcile how exactly?
<ddaa> so that importd can do something useful with the metadata bzr commit puts into svn
<jelmer> making existing imports compatible with bzr-svn or simply integrating bzr-svn into importd?
<jelmer> Ah, right
<jelmer> http://samba.org/~jelmer/bzr/mapping.txt contains a short write-up of the metadata used by bzr-svn
<ddaa> so, id-wise, importd and your plugin have two different approaches: random and deterministic
<ddaa> there are advantages to both
<jelmer> yes, do those have to be reconciled as well?
<ddaa> I do not think it is reasonably feasible
<ddaa> I think what would make sabdfl happy would be the possibility to use your work to:
<jelmer> I don't have a lot of time at the moment, have to go in 5 minutes - any chance we can arrange a meeting later this week?
<ddaa> get a bzr branch produced by importd, makes some new changes there, commit to svn, and have importd get the information from there
<ddaa> so I'm happy to have two branch universes, the one based on cscvs imports, and the one based on your import system
<ddaa> but both should be able to roundtrip with svn
<ddaa> jelmer: please think about it
<ddaa> jelmer: when would a meeting suit you?
<jelmer> ddaa: Sure, I will. There's a couple of issues we'll ahve to deal with
<ddaa> let's arrange meeting first
<ddaa> sabdfl focus is no importd data, your deterministic import stuff is nice, but it's not the essential stuff as far as he is concerned
<ddaa> "is _on_ importd data"
<jelmer> ddaa: Thursday and friday, preferably
<ddaa> ASAP, we are in a sprint with SteveA, jamesh and sabdfl in voice range
<jelmer> I'll be away on tuesday and wednesday
<ddaa> Thursday, what time?
<jelmer> oh, ok - please say hi to them :-)
<ddaa> not between 1200 and 1300 UTC, that's all
<jelmer> After 1300 UTC.. I'm arriving at the airport early morning, not sure when I'll be home exactly.
<ddaa> (that's the time of the weekly launchpad mass^Wmeeting)
<jelmer> (-:
<ddaa> I'd like a firm hour so we can schedule effectively
<ddaa> say, 15 UTC?
<jelmer> ddaa: Feel free to pick one, it's all fine by me. 
<jelmer> Yeah, 15 UTC sounds fine. 
<ddaa> deal
<jelmer> Great. 
<jelmer> I've got to run. See you on thursday!
<ddaa> see you
<SteveA> mpool: ping?
#launchpad-meeting 2006-07-27
<ddaa> hello there
<jelmer> hi
<jelmer> Is right now ok for you for the meeting? We can postpone it to this evening if you like. I don't mind
<ddaa> yes, just need to clarify the issues with SteveA first
<ddaa> sorry for the delay
<jelmer> no worries, just let me know when you're ready
<ddaa> let's do it
<ddaa> jelmer: last time we talked, I gave you a short summary of the issue
<ddaa> jelmer: I would you to explain it back to me, to make sure we are in sync
<jelmer> ddaa: Sure
<jelmer> As I understand it, you're looking into improving importd so it can recognize the special properties set on Subversion branches using bzr-svn.
<jelmer> Is that correct?
<ddaa> that's probably the shortest way of framing the issue
<jamesh> jelmer: my understanding is that the main feature we are after is for people working off branches we publish as vcs-imports on launchpad.net can land changes to SVN
<jelmer> jamesh: Ok, that's quite a bit different
<jamesh> jelmer: the question is whether to do it by making your plugin handle our current vcs-imports code, or whether to change vcs-imports to be compatible with your code
<jelmer> jamesh: I assume invalidating all the existing vcs-imports is not an option?
<jelmer> for example, by changing the revision id generation algorithm?
<jamesh> we are discussing that.
<jelmer> If you haven't seen it yet, there's a short summary of the SVN properties bzr-svn sets on http://samba.org/~jelmer/bzr/mapping.txt
<ddaa> jelmer: I'd rather we not use your svn import system
<ddaa> it has nice properties, in that it does not require a central authority to work
<ddaa> but it also has issues with referential integrities in the face of changes in the conversion code
<jelmer> ddaa: I'm not suggesting replacing importd by bzr-svn, but those are some of the properties importd will have to set
<jamesh> i.e. if you find a problem with your revision and file ID mapping and need to change it
<jelmer> if you want to allow people to take an importd-generated branch and push it to subversion
<ddaa> let me have a quick look, so do not talk _entirely_ out of my ass
<jelmer> jamesh: There's a version number that's part of the generated revision id that I'll increment whenever I change the mapping code; that hasn't been necessary so far.
<jelmer> jamesh: The revision ids are used for informational purposes by bzr-svn, they're not just random identifiers.
<ddaa> okay
<ddaa> AIUI there are two important processes in what your plugin does
<ddaa> the first one is the "commit to svn" process. Its inputs are: 1. a bzr branch 2. a svn url. Its output is 1. a svn repo with a commit in it that includes some magical metadata.
<ddaa> the second one is the "merge with svn" process. Its inputs are: 1. a bzr branch that was initially imported from svn, and may have a number of native bzr commits after the last imported revision 2. a svn url to a repository which includes a revision created by "commit to svn", and which may include some of the native commits on the bzr branch. Its output is a bzr working tree which is merged in a history sensitive way with the svn repo.
<jelmer> Yeah, I guess dividing it that way makes the most sense from a launchpad POV
<ddaa> excuse me, the guys are chatting around
<ddaa> I'll move to some quieter place
<jelmer> ok
<ddaa> back
<ddaa> what we would like to have in the end is the ability to:
<ddaa> 1. commit to svn from a bzr branch imported from svn, but with non-deterministic ids
<ddaa> to do that meaningfully, we might have to alter our import tool to provide the commit tool with some special metadata it needs to do its job
<ddaa> a highly desirable property here, is that it should not be a requirement for _all_ the revisions in the history of the bzr branch to have this special metadata
<ddaa> but that's only a secondary requirement
<ddaa> we can throw away all the existing svn import, as a one-off event
<jelmer> Ok, that makes sense. 
<jelmer> So, in order to be able to do a commit, given a certain SVN branch and a Bazaar branch derived from that SVN branch, the bzr-svn plugin needs:
<jelmer> * A common revision that contains a branch path, revision number, uuid and file ids that can be mapped back to paths in the Subversion repository
<jelmer> At the moment, the branch path, revision number and uuid are simply "stored" in the revision id, but I guess you could store them somewhere in Bazaar revision properties
<ddaa> 2. import svn into a bzr branch, that uses non-deterministic ids, sets the parent_ids in revision that were comitted using the bzr-svn plugin, and preserves the file-ids for files that were introduced on the svn repo using the bzr-svn plugin.
<jelmer> ddaa: I doubt 2 is very well feasible
<ddaa> jelmer: okay, so we could start storing that information into, say, a "svn-revision" revision property, and once a launchpad import has a single revision with this property, it could be used to branch off and commit back to svn?
<jelmer> ddaa: Yes, but if the revision ids are non-deterministic, there are a couple of weird problems that'll show up
<ddaa> I'm all electronic ears.
<jelmer> mostly, if you have two bazaar branches created from different svn branches in the same repository
<ddaa> yes?
<jelmer> then, you merge branches/foo into trunk using bzr-svn
<jelmer> later on, you can still merge whatever branch was created by importd for branches/foo
<ddaa> I sense trouble here, but can you spell out what the problem will be?
<ddaa> from the user perspective, what is the failure mode you are concerned with?
<jelmer> because that revision (the same revision) has different revision ids
<jelmer> the fact that you will get the same history twice
<jelmer> but with different revision ids
<jelmer> I'm not sure how much of a problem that is for you
<jelmer> it's not a very big problem, it's just not very nice
<ddaa> does svn actually _tracks_ merge?
<jelmer> well, bzr-svn does
<jelmer> or at least, the revision ids of the merged revisions are stored, the revision itself aren't
<jelmer> Subversion 1.5 will actually track merges, and as it looks now, bzr-svn should be easily able to support that
<ddaa> jelmer: in the end, the problem you just mentioned only happens because there are two competing mappings from svn to bzr revision ids: the deterministic ones you produce, and the random ones importd produce.
<jelmer> ddaa: Sure, so I guess as long as you don't mix the two, there isn't much of a problem.
<jelmer> ddaa: I guess checkouts don't work on importd branches?
<ddaa> jelmer: I do not understand that question about checkouts.
<jelmer> ddaa: You can't have a branch bound to a vcs-import, right?
<jamesh> jelmer: well, checkouts fail for read-only bzr branches right now, independent of who made them
<ddaa> what jamesh said
<jamesh> ah.  You mean so that commits go directly to svn?
<jelmer> jamesh: Yes. There'll be no need for bzr-svn to support direct commits to svn for importd-branches
<jelmer> only push
<jelmer> If I understand the system correctly
<ddaa> that sounds like it, except push is a bit too limited
<jamesh> that's pretty much -- just get the delta committed to svn with the metadata needed to recognise the merge
<jelmer> ok, that should be doable if importd sets the right metadata in the revision properties
<ddaa> I just realised something that your approach gives that importd cannot readily give
<jelmer> what is it?
<ddaa> Using your system, to merge a bzr branch to svn, you do a checkout of svn, merge your external branch there, and commit.
<ddaa> you have the opportunity to resolve any conflict at the merge point
<ddaa> And once you have comitted, you immediately get the import branch that includes your merge.
<ddaa> Putting importd in the loop to assign non-deterministic yet "canonical" revision ids force the workflow to become:
<ddaa> 1. do an atomic "merge and push" operation to the svn repository, that only accept clean merges 2. wait for importd to come around updating its branch to get the revision you just comitted
<ddaa> jelmer: is that correct, or do you see a way to avoid this loss in agility?
<ddaa> oh! yes, there would be a way to avoid it!
<ddaa> When doing the atomic "merge and push" thing, stick the "canonical bzr revision id" in a property of the svn revision.
<jelmer> ddaa: well, you'll always commit locally and push to svn - never commit directly to SVN, unless we add a 'commit-svn' command or something
<jelmer> right, that used to be the original idea for push-as-merged. Ideally revision id aliases would be used for that
<ddaa> let's stay away from revision ids aliases for now
<ddaa> if abentley says "it confusing the heck out me", that means it's definitely too complicated for mere mortals to understand
<jelmer> ddaa: I don't think that was about revision id aliases - probably about file id aliases
<jelmer> ddaa: anyhow, how would you know what revision id importd is going to assign?
<ddaa> in that case, the revision id to use by importd would be encoded explicitly in the svn revision.
<jelmer> though that makes it deterministic
<ddaa> yeah your are right
<ddaa> wrong track
<ddaa> I was on crack
<jelmer> Are you opposed strongly to deterministic revision ids? Or mainly to breaking the existing revision ids?
<ddaa> one minute
<ddaa> Okay...
<ddaa> I think your determinitic revision id approach is necessary to get something that people will want to use.
<ddaa> the push-then-wait-for-launchpad is, IMO, not something people will realistically want to use
<ddaa> however, to use those deterministic revision ids, we need additional guarantees
<ddaa> the way it currently works, we have a potentially open-ended number of namespace transitions that may affect all svn revisions
<ddaa> that's not acceptable in that it makes users of svn branches pay for svn features they do not use
<ddaa> for example, consider svn symlinks
<jelmer> so, to summarize: you don't want a bug in the mapping code force all vcs-import users to ditch their existing branch copies?
<ddaa> yes
<ddaa> fixing the bug should only bump the revision id namespace of revisions whose ancestry contains at least one revision affected by the bugfix
<ddaa> note that this is not limited to bugs, it also matter for new features
<ddaa> like nested trees and stuff like that
<ddaa> or file properties
<jelmer> right
<ddaa> can you deliver functionality in your plugin to provide that logic right away?
<jelmer> The easy way would be to just iterate over the branch and compare all the existing revisions with the ones on the SVN branch
<jelmer> (where the ones on the SVN branch are created using code with the bug fixed)
<jelmer> but I guess it makes sense to provide an upgrade mechanism, much like the one for data formats in bzr at the moment
<ddaa> jelmer: I think there's more to it
<ddaa> consider the independent import
<jelmer> independent import using bzr-svn, you mean?
<ddaa> yes
<ddaa> in that case, you need to determine how many namespace bumps each revision needs to undergo in order to be compatible with other imports
<jelmer> hmm
<jelmer> back in a minute
<ddaa> I'm starting to think that, maybe, it would be simpler (as in more robust) to actually go the git way, and use content-addressed revision ids.
<ddaa> jelmer: cool, I need some nicotin
<jelmer> ddaa: that's not really an option for bzr-svn as it requires you to fetch the full svn revision just to figure out what the revision id should be
<ddaa> that fixes my main problem at least
<ddaa> when comitting to svn, you have the full revision handy, so you can readily hash it
<ddaa> and importd is very good at sucking the data out of svn servers
<jamesh> ddaa: do you hash on the data you preserve, or all the data SVN stores?
<ddaa> the hash would have to be computed on what the bzr revision looks like, after being transformed by bzr-svn
<jamesh> so if later versions of bzr-svn preserve more data you'd get different hashes?
<ddaa> the alternative is to guarantee that for all revision, we can reliably count the number of required namespace version bumps, using any bzr-svn version ever released 
<ddaa> which seems too strong a promise to make
<ddaa> jamesh: yes
<jelmer> ddaa: Keeping a hash is probably a good idea - I'm not sure whether it should be part of the revision id though
<jelmer> can't we just rely on the revision sha1?
<ddaa> unless you can come up with a good way to detect and recover from loss of referential integrity of revision id, I think we need to put the hash in the revision id.
<jelmer> I simply can't put the hash in the revision id for bzr-svn, it's way too expensive
<ddaa> jelmer: what if launchpad provides you readily imported branches, and handles re-importing them now and then?
<ddaa> you do need to suck in that data anyway when pulling or branching from a svn repo, dont' you?
<jelmer> ddaa: big loss of functionality - bzr-svn works stand-alone right now, and svn commits appear immediately in the bzr-svn plugin
<jelmer> ddaa: Yes, but if I just run 'bzr log' on a remote branch, that's only a couple of roundtrips now, even on a very big repository
<jelmer> ddaa: if you add a hash in the revision id, Branch.revision_history() will slow down big time
<ddaa> jelmer: can you propose a different way to reliably handle the requirement of limiting revision-id changes to those revision that are affected by changes in the conversion logic?
<ddaa> So far I see only two options:
<jelmer> ddaa: I hope so.. that would be the ideal solution, so I'm trying to think of something
<ddaa> 1. merge-and-push then wait for importd
<ddaa> 2. put a hash in the revision id
<ddaa> none of them are ideal, so I'm certainly open to better ideas
<jelmer> where (1) would be with a non-deterministic revision id, (2) with a deterministic revision id?
<ddaa> jelmer: yes
<ddaa> I think log-directly-from-svn could be handled using a special revision id namespace
<ddaa> because then the actual contents of the revision do not really matter
<jelmer> ddaa: but how are you going to detect you're in a log-directly-from-svn?
<jelmer> ddaa: log isn't really special, it's just a bunch of get_revision() calls
<ddaa> maybe have "bzr log svn://something" be interpreted as "bzr log svn+logonly://something"
<jelmer> that's just plain ugly :-)
<ddaa> yes
<ddaa> What I'm looking for here, is something that would make the sabdfl happy.
<ddaa> To slightly rephrase what he told me: "we are not paying for the svn plugin because it's cool, but because we want some feature working"
<ddaa> so, working trumps pretty
<jelmer> Well, bzr-svn works very well without importd... (-:
<jelmer> (1) and (2) both sortof defeat the purpose of bzr-svn, as (1) doesn't allow mixing of merges from bzr-svn and importd and (2) slows down bzr-svn too much
<ddaa> The reason I'm talking to you here, is that I do not think that in its current form it can work reliably enough for us.
<ddaa> but maybe some less anal launchpad folks will disagree with me.
<ddaa> where reliability means, mainly, preserving referential integrity of revision ids and avoid breaking imports that are not affect by changes in the import logic
<ddaa> Finally, I do not personally believe that having launchpad assign "canonical" bzr ids to imports from other vcs increases the value of launchpad in a useful way, but some people in the company seem not to share that conviction yet.
<jelmer> Why exactly can't it work reliably? I can see the issue with mapping changes and I am convinced that should be fixed, but I'd rather not cripple bzr-svn for it.
<ddaa> Because you have not told me yet how to fix that issue in another way.
<ddaa> I'm totally open to suggestions.
<ddaa> If you need time to think about it, that's fine with me.
<ddaa> jamesh: anything you would like to add?
<jelmer> Well, one of the original ideas behind bzr-svn (as it read on the wiki) was that it worked without depending on Launchpad. Another option would be to simply extract the commit code of bzr-svn and create a launchpad-svn-commit plugin without complicating the bzr-svn code.
<ddaa> Mh, which wiki?
<jelmer> launchpad - page BzrRoundTrippingSvn, though I can no longer access that
<jelmer> ddaa: I'm still trying to think of a way to properly detect problems.
<jamesh> ddaa: my feeling is that jelmer's system is the right general direction, but I agree that we need to address the future in the bzr <-> svn mapping spec
<ddaa> jelmer: the idea of the launchpad-svn-commit plugin is one of the option I see  now. But it's far from ideal.
<ddaa> in that this functionality will just suck
<jelmer> ddaa: If we can figure out some way to deal with upgrades but still have deterministic revision ids, that'd be by far the best solution imo.
<ddaa> jelmer: I agree with jamesh that your design goes in the right general direction
<ddaa> jelmer: how can we help in the figuring out?
<jelmer> ddaa: I'm not sure - I'm currently trying to generalize the problem a bit.
<ddaa> I mean, how can we help in terms of gathering resources: like attention from core bzr devels working at canonical.
<jelmer> ddaa: Ah, in that sense. I think it would be a good idea to discuss this with Martin, Robert or John.
<ddaa> I understand that you need to sit back and think about the issues, but when I report to the company, I want to be able to give a date when I will have some more information.
<jelmer> ddaa: Sure, I understand. Perhaps it's a good idea to have another discussion on, say, monday?
<ddaa> if you expect to have some progress on that issue monday, great
<ddaa> btw, I hereby invite you to the launchpad-bazaar meeting
<ddaa> Which is held at 1000UTC on monday in that very channel
<jelmer> Cool, I'll be there.
<ddaa> With SteveA, mpool, lifeless (usually), jamesh, spiv and myself.
<jelmer> Ok, I'm off to dinner. See you on monday.
<ddaa> just for clarification, this meeting is intended to be a short discussion to assign tasks and resources
<ddaa> design discussion should take place outside of the meeting
<jelmer> ok
<ddaa> thank you for your time
<ddaa> have a nice dinner
#launchpad-meeting 2006-07-28
<jelmer> hi again :-)
<jelmer> so, I just had a discussion with j-a-meinel
<jelmer> he came up with something so obvious I hadn't thought about it yet
<jelmer> ddaa: which is simply doing the upgrade by hand, when necessary
<ddaa> okay, then what happens when you do the upgrade?
<jelmer> then it breaks
<ddaa> that does not look like a useful upgrade mechanism...
<jelmer> there is no need to do the upgrade to v2 though, when v1 is working fine
<jelmer> so you just keep at v1
<ddaa> I think that still does not address my concern that an import using an old version, followed by an upgrade, and the same import using a new version of the plugin (w/o upgrade) may produce incompatible imports.
<jamesh> what happens when someone else switches to v2 (e.g. you) and does a merge to SVN that we later scan?
<jamesh> we'd need to version the properties used to record merges in that direction too
<jelmer> the more complicated, but more complete solution, would be to use revision id aliases
<jelmer> and, when you upgrade, set 'svn-v1:2@uuid-branch_path' to be equal to 'svn-v2:2@uuid-branch_path2' if it isn't affected by the bugfix
* ddaa thinks he's missing something obvious about this upgrade thing
<ddaa> jelmer: the revision id alias thing might be interesting, but until we have a working definition of how that should work, it's just handwaving.
<ddaa> jelmer: so, say you have an branch that was imported from svn using svn-1.
<jelmer> right
<ddaa> a few people are working on branches derived from that one
<ddaa> one of those people decides that he wants the benefit of svn-2
<ddaa> he does "bzr svn upgrade" or something, and then what happens?
<jelmer> ddaa:he ends up with a tree filled with svn-v2 revisions
<jelmer> and can no longer exchange revisions with the others
<ddaa> jelmer: that means that bzr upgrade is only possible when the tip of the branch is a svn-1 revision, right?
<jelmer> yes
<ddaa> okay, there's a specific reason why I avoided this suggestion before
<ddaa> it means that we need provide an explicit upgrade knob in launchpad for svn imports
<ddaa> and then give a list of every available svn import version for people to choose from
<jelmer> Yes, that's correct. But there's not really a sane way around that without revision id aliases.
<jelmer> and those are probably not going to be around soon
<jelmer> ddaa: would it be problematic to have to require such an option?
<jelmer> ddaa: Another thing you could do is simply provide one branch per mapping version
<ddaa> it would make things much more complicated that they sould have to be, both the developer and for users.
<jelmer> ddaa: or we could just stick with v1 until revision id aliases land. Other then bugfixes, what changes are waiting other than ignore lists, renames and externals ?
<ddaa> and then you have data volume explosion issues when one user upgrades then merges back into svn
<ddaa> BUGFIXES!!!
<ddaa> bugfixes change the way a svn is converted to bzr, that needs to change the revision id to preserve referential integrity
<ddaa> that it also true of temporary regressions in the conversion code
<ddaa> if the bzr.dev folks say they are happy with violating referential integrity, I'll change my stance here, but right now it's a sacred cow.
<jelmer> ddaa: What kind of bugs?
<ddaa> jelmer: precisely that kind of bug
<ddaa> the one you do not expect
<ddaa> programmers make mistakes
<ddaa> with arch imports, the deterministic id thing was a bit shaky
<jamesh> any bug that would change how a revision is represented
<ddaa> but it's already, because arch->bzr transition was essentially one off
<ddaa> s/already/alright/
<ddaa> and because the conversion was very trivial
<ddaa> for svn, we have an ongoing, widely distributed, conversion process, integrity is much more critical
<ddaa> it is also likely to get a lot more use
<jelmer> sure, but what happens when you find a bug?
<jelmer> can't you just upgrade only the branches affected by it?
<ddaa> that's precisely the issue I do not have a satisfying solution for yet
<ddaa> jelmer: and how do you know, when doing an import the first time, which format you should use?
<jelmer> ddaa: if you do the import for the first time, always use the latest mapping since there are no users with upgrade issues
<ddaa> by default, you would probably choose the latest, but that's wrong if other people are already using svn-1, that's wrong
<jelmer> ddaa: how can people be using svn-v1 in that case?
<ddaa> because they started using it before there was a svn-v2
<ddaa> and they did not need/want to upgrade
<ddaa> this "explicit upgrade and breaks interop inconditionally" is going to be a usability problem
<jelmer> ddaa: how can they start using the importd branch when there was no import yet?
<jelmer> ddaa: don't you do the same thing in launchpad at the moment? What do you do if you find a bug in the mapping?
<ddaa> Fix the bug.
<ddaa> in theory, at least
<ddaa> it does not matter since the revision ids are arbitrary
<jelmer> but what happens to existing revisions that are touched by the bug?
<jelmer> so you just keep old revisions with the bug?
<ddaa> yes
<ddaa> under the theory that old history quickly loses value
<jelmer> how about adding a "fake upgrade revision" ?
<jelmer> so when you upgrade to v2, you fake a merge from a full v2 branch?
<jelmer> hmm.. that causes a lot of history around, I guess
<jelmer> unless you add the v2 revision as a ghost, I guess...
<jelmer> yeah, that might actually work..
<jelmer> ddaa: still there?
<ddaa> partly
<ddaa> I'm on a crunch to get native bzr imports up like right now
<ddaa> Ideally, I think we would need to sit around some beer with some bzr.dev guy
<ddaa> I feel like we are not getting through to one another
<jelmer> I'm all for beer, but I think I'm onto something now...
<ddaa> let's talk about that monday
<jelmer> sure
<jelmer> I'll just check it for obvious issues I've missed with John
#launchpad-meeting 2008-07-23
<barry> #startmeeting
<MootBot> Meeting started at 09:02. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<barry> hello and welcome to this week's ameu reviewers meeting.  who's here today?
<bigjools> me
<sinzui> me
<gmb> me
<jtv> me
<bac> me
<flacoste> me
<cprov> me
<intellectronica> me
<salgado> me
 * barry kicks EdwinGrubb 
<EdwinGrubb> me
<EdwinGrubb> ow
<barry> BjornT: ping
<barry> allenap_: ping
<barry> [TOPIC] agenda
<MootBot> New Topic:  agenda
<barry>  * Roll call
<barry>  * Next meeting
<barry>  * Action items
<barry>  * Queue status
<barry>  * Mentoring update
<barry>  * Review process
<barry> [TOPIC] next meeting
<MootBot> New Topic:  next meeting
<barry> i won't be here, but salgado is going to chair.  week +=1 ?
<sinzui> I don't think I will attend
<salgado> yes, I will
<intellectronica> the bugs folks will have a sprint, but we'll probably be able to make it
<barry> salgado: thanks
 * bigjools will not be here
<BjornT> me
<barry> [TOPIC] action items
<MootBot> New Topic:  action items
<barry>  * intellectronica to write up guidelines on check_permission in the wiki and email the ml for additional input
<intellectronica> sorry, i haven't done any of my items this week :(
<intellectronica> please let's carry them to next week
<barry> intellectronica: i'm only letting you off the hook because i haven't done any of mine either :)
<intellectronica> ;)
<barry> we'll just carry them all forward
<barry> [TOPIC] queue status
<MootBot> New Topic:  queue status
<barry> sinzui says that there's strong evidence that a lot of reviewers are sprinting
<barry> i see A LOT of merged branches have not been removed from PR
<bigjools> death to PR
<bigjools> keel eet
<barry> thumper: wake up and jfdi!
<barry> anything else on the queue?
<barry> [TOPIC] mentoring update
<MootBot> New Topic:  mentoring update
<bigjools> the GQ needs attending to
<barry> bigjools: i know :(  i don't know how much the foundations will be able to review this week
<barry> i don't have anything on mentoring.  anything from y'
<barry> y'all?
<barry> [TOPIC] review process
<MootBot> New Topic:  review process
<barry> i have nothing.  anything from you guys?
 * barry takes that as a "no"
<barry> that's it from me.  anything not on the agenda?  if not, we can end early
<jtv> yay!
<barry> #endmeeting
<MootBot> Meeting finished at 09:17.
<barry> thanks everyone
<bigjools> cheers
#launchpad-meeting 2008-07-24
<flacoste> mpt: meeting time?
<mars> moo
 * thumper yawns
<mpt> oh, yes
<mpt> MEETING TIME
<rockstar> me
<matsubara> moo
<mars> moo
<mpt> For the next half hour or so we'll be discussing Launchpad development
<cprov> me
<Ursinha> me
<mpt> Who is here today?
<al-maisan> me
<abentley> me
<barry> me
<bac> me
<salgado> me
<sinzui> me
<rockstar> Since when did we go to animal noises?
<adeuring> me
<flacoste> me
 * rockstar didn't get the memo
<herb> moomo
<sinzui> .o
<BjornT> me
<mrevell> me
<leonardr> me
<EdwinGrubbs> me
<matsubara> me
<thumper> me
<matsubara> releases is here
<intellectronica> me
<matsubara> no mootbot today?
<flacoste> foudnations is here
<thumper> code is hee
<thumper> r
<jtv> me
<BjornT> gmb had to go out, so he isn't here
<mpt> What's that magic word
<mpt> #startmeeting
<MootBot> Meeting started at 13:08. The chair is mpt.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<mpt> there we go
<mpt> so, the agenda
<stub> me (sorry - new kernel doesn't like my network stick)
<mpt>  * Next meeting
<mpt>  * Actions from last meeting
<mpt>  * Oops report (Matsubara)
<mpt>  * Critical Bugs (Rinchen)
<mpt>  * Bug tags
<mpt>  * Operations report (mthaddon/herb/spm)
<mpt>  * DBA report (stub)
<mpt>  * Sysadmin requests (Rinchen)
<mpt>  * New packages required (salgado)
<mpt>  * A top user-affecting issue (mrevell)
<mpt>  * Doc Team report (mrevell)
<mpt>  * New MOTU liaison
<mpt>  * Oopses for unauthorized exceptions
<mpt> [TOPIC] Next meeting
<MootBot> New Topic:  Next meeting
<mpt> Any problem with the same time next week?
<sinzui> I may not be
<BjornT> the bugs team will be sprinting, but should make it anyway
<flacoste> barry and sinzui are away
<sinzui> here ot there
 * barry pre-apologizes
<al-maisan> I'll be off on Thursday next week
<mpt> We have an apology from allenap for this week
<mpt> and from kiko and Rinchen who are famously at Oscon
<mpt> ok, next meeting same time next week
<mpt> [TOPIC] Actions from last meeting
<MootBot> New Topic:  Actions from last meeting
<mpt> There are no notes available from the last meeting, so no actions
<mpt> [TOPIC] Oops report
<MootBot> New Topic:  Oops report
<matsubara> Hi everyone, say hello to Ursinha, she started this week and is the new QA person
<matsubara> Ursinha, the stage is yours. Go ahead.
<thumper> hi Ursinha
 * Ursinha waves
<mpt> welcome Ursinha
<Ursinha> hi all
<herb> hi Ursinha
<stub> o/
<rockstar> Hi Ursinha
<barry> Ursinha: welcome!
<mars> hi Ursinha
<al-maisan> hello Ursinha
<Ursinha> :)
<sinzui> hi
<adeuring> hi Ursinha
<abentley> Hi.
<flacoste> welcome Ursinha!
<mrevell> welcome Ursinha
<salgado> welcome aboard, Ursinha
<Ursinha> thanks all
<Ursinha> well, I have two bugs in here
<Ursinha> one is a Unicode error, bug 251569
<ubottu> Launchpad bug 251569 in launchpad "UnicodeEncodeError when trying to search in launchpad/people/+index" [Undecided,Confirmed] https://launchpad.net/bugs/251569
<Ursinha> can anybody please take a look at it?
<Ursinha> it's oopsing when trying to do a people search
<Ursinha> the other is a timeout problem that is causing more oopses than normal
<Ursinha> an old bug, 124205
<thumper> hey ubotto, bug 124205
<flacoste> salgado?
<flacoste> could you look into 251569?
<salgado> sure
<Ursinha> thanks salgado
 * flacoste kicks ubotto
<ubottu> Launchpad bug 124205 in blueprint "timeout in specworkload page" [Undecided,New] https://launchpad.net/bugs/124205
<matsubara> the second one is a bug on +specworkload. it's assigned to BjornT (why?) BjornT are you going to have a look on that one?
<Ursinha> \o/
<BjornT> matsubara: nope :) i've unassigned myself
<Ursinha> this bug is old but is happening very often in the last days
<matsubara> okie. so, I guess that's another one for Foundations
<matsubara> flacoste: can you keep it under the radar?
<flacoste> matsubara: sure
<flacoste> Ursinha: bac is looking at it
<Ursinha> thanks flacoste
<Ursinha> guess that's all for today
<matsubara> btw, thanks all for the effort on the fixes for yesterday's rollout. oops summary today's been very quiet.
<mpt> thanks Ursinha and matsubara
<Ursinha> indeed, kudos for you all :)
<mpt> [TOPIC] Critical bugs
<MootBot> New Topic:  Critical bugs
<mpt> Rinchen is away
<mpt> Ursinha, are there any?
<matsubara> I'll take care of that one
<mpt> (other than the ones you've already mentioned)
<matsubara> there's only one not in progress which was re-opened by sinzui
 * sinzui show fix that
<matsubara> bug 247878
<ubottu> Launchpad bug 247878 in launchpad ""Contact details" section shows only one e-mail address" [Critical,Confirmed] https://launchpad.net/bugs/247878
<sinzui> s/show/should/
<matsubara> sinzui: given your comment there, I guess you're going to take care of it, right? :-)
<matsubara> thanks sinzui
<sinzui> I'll fix it tonight.
<matsubara> great
<matsubara> back to you mpt. thanks
<sinzui> I'll look to land it tomorrow
<mpt> thanks
<mpt> [TOPIC] Bug tags
<MootBot> New Topic:  Bug tags
<mpt> There are no proposed tags.
<mpt> [TOPIC] Operations report
<MootBot> New Topic:  Operations report
<mpt> herb?
<herb> Early Saturday (2008-07-19) did a cherry pick of r6726 to lpnet* and the script server.
<herb> Yesterday rolled out r6753.
<herb> On a couple of occasions in the past week we've had to restart codebrowse because it was unresponsive and using >40% of system RAM.
<herb> On a couple of occasions in the past week we've had to restart lpnet processes (3x in prod, 1x in staging) that had died leaving stale PID files. These have been related to the bug filed a few weeks ago, bug 247227.
<ubottu> herb: Bug 247227 on http://launchpad.net/bugs/247227 is private
<herb> That's it from the LOSAs unless there are any questions for me.
<mpt> Thanks herb
<mpt> [TOPIC] DBA report
<MootBot> New Topic:  DBA report
<stub> Its all been pretty static on the DBA front - no patches, no worries. Yay!
<stub> Next stage of replication/read-only-launchpad should be up for review tomorrow. We will need more disk space on chokecherry to test this - it has been previously discussed and an rt ticket raised today in case it got forgotten.
<stub> Out timeouts seem relatively good, so thanks everyone who has been opimizing the worst offenders!
<stub> Nothing else.
<mpt> ok, thank you
<mpt> [TOPIC] Sysadmin requests
<MootBot> New Topic:  Sysadmin requests
<mpt> Was anyone tracking these in Rinchen's absence?
<mrevell> Not me. You matsubara?
<matsubara> not formally
<mpt> Anyone have urgent RTs?
<matsubara> but if there're any I can chase those
<matsubara> anyone?
<stub> I can't find my rt ticket :-(
<stub> nm - looks like disk got added when I wasn't looking
<mpt> okie dokie
<mpt> [TOPIC] New packages required
<MootBot> New Topic:  New packages required
<mpt> salgado?
<salgado> anything for me this week?
<salgado> probably not, but anyway
<mpt> [TOPIC] New user-affecting issue
<MootBot> New Topic:  New user-affecting issue
<mpt> None from mrevell this week
<mrevell> Hi - sorry, been snowed under with the tour.
<mpt> and so we go sprinting onward through the agenda
<mpt> [TOPIC] Doc Team report
<MootBot> New Topic:  Doc Team report
<mpt> mrevell, anything on this this week?
<mrevell> Not relaly, I'm afraid.
<mrevell> Just full steam ahead for next week.
<mpt> okay
<mpt> [TOPIC] New MOTU liaison
<MootBot> New Topic:  New MOTU liaison
<mpt> Is this an old item that wasn't deleted?
<mrevell> mpt:  I think it might have been, unless someone else raised it. Sorry, I should have deleted this but was on vacation after it was in the meeting.
<mpt> ok, no problem
<mpt> [TOPIC] Oopses for unauthorized exceptions
<MootBot> New Topic:  Oopses for unauthorized exceptions
<mpt> salgado, is this current?
<salgado> mpt, it is
<salgado> We sometimes present links to pages that the logged in user doesn't have the rights to see.  When users follow them they get the Forbidden page, but we don't record that (as an OOPS) like we do for 404s.  I think we should do that as we probably want to either hide these links or present them in a disabled form
<salgado> these would be listed in a separate section of the OOPS report, just like the 404s
<flacoste> +1
<salgado> matsubara, can we do that?
<thumper> +1
<mpt> That seems like a good idea
<flacoste> that would help debug permission problem as well
<salgado> flacoste, exactly
<flacoste> like those reported by hobsee
<mpt> as long as the page has a referer
<abentley> +1 for disabling, preferably with a "why" tooltip.
<mpt> So, we've had a discussion a couple of weeks ago about how to present links that you don't have permission to visit
<thumper> abentley: "disabled as you aren't l33t enough" :)
<mpt> This is a related but separate issue, about finding the problems in the first place.
<salgado> right, but that's not what we're discussing here
<mpt> finding the problem links in the first place, I mean.
<abentley> thumper: But then what will it say for me?
<salgado> so, I'll file a bug to generate OOPSes for unauthorized exceptions
<matsubara> salgado: yes, we can do that. sorry, got caught up in the phone
<mpt> [ACTION] salgado to report a bug on generating oopses for unauthorized exceptions
<MootBot> ACTION received:  salgado to report a bug on generating oopses for unauthorized exceptions
<salgado> cool
<salgado> guess we've finished, then?
<mpt> That's about it
<mpt> And so, as Launchpad's fluorescent green fades slowly into the cocktail of memory
<mpt> It's time to bring this Launchpad developer meeting to a close.
<mpt> #endmeeting
<MootBot> Meeting finished at 13:34.
<mpt> thanks everyone
<mrevell> mpt: Nice one Humph. Thanks.
<thumper> thanks mpt
<flacoste> thanks mpt!
<salgado> thanks mpt
<matsubara> thanks mpt!
<Ursinha> thanks mpt :)
<rockstar> mpt, I LIKED the green1  :)
<flacoste> so did others
<flacoste> green is peaceful :-)
<mrevell> that shade of green wasn't peaceful :)
<abentley> Yep, me too.  At least there was some vibrancy there.
<barry> it's not easy being green
<sinzui> Soon we can make a new Launchpad that is even greener
<mpt> rockstar, don't tell anyone, but I have a secret plan to bring it back
<mpt> It will require a lot of tricky CSS though
<abentley> sinzui: With hookers and blackjack?
<rockstar> mpt, you're supposed to say that in the other channel!
<mpt> ssssshhh
<rockstar> +1 hookers and blackjack
#launchpad-meeting 2009-07-22
<barry> #startmeeting
<MootBot> Meeting started at 09:00. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<barry> hello everyone and welcome to this week's ameu reviewers meeting.  who's here today?
<allenap> me
<noodles> me
<mars> me
<bac> me
<bigjools> me
<adeuring> me
<henninge> ms
<abentley> me
<henninge> me
<salgado> me
<leonardr> me
<deryck> me
<barry> jtv, intellectronica ping
<jtv> barry: pong
<jtv> me
<barry> cprov, BjornT_ sinzui ping
<cprov> me
<BjornT_> me
<EdwinGrubbs> me
<sinzui> me
<barry> rockstar: ping
<barry> gmb: ping
<gmb> me
<barry> [TOPIC] agenda
<MootBot> New Topic:  agenda
<barry>  * Roll call
<barry>  * bac to chair for the next two weeks - barry
<barry>  * Action items
<barry>  * Mentoring update
<barry>  * deryck graduates
<barry>  * Alphabetical sorts are case sensitive? insensitive? - barry
<barry>  * Peanut gallery (anything not on the agenda)
<barry>  
<barry> [TOPIC] bac to chair for the next two weeks - barry
<MootBot> New Topic:  bac to chair for the next two weeks - barry
<barry> so i will not be at these meetings for the next two weeks.  bac will chair them in my absence
<intellectronica> me
<barry> bac: thanks!
<bac> np
<barry> [TOPIC]  * Action items
<MootBot> New Topic:   * Action items
<barry>  * deryck to update js wiki page with recommendations on loading js files in devmode only
<deryck> did it yesterday. :)
<barry> deryck: awesome, thanks
<deryck> np
<barry>  * gmb to update style guides to clarify that `reST` is to be used in doctests, with existing pages to be converted at coder's discretion
<gmb> Done.
<barry> fantastic!  can we keep this momentum going?
<gmb> Though I'm going to reword it to make the second part a bit more explicity.
 * gmb has a new hobby - adjectifying adjectives.
<barry> cool
<barry>  * flacoste to update reviewer docs and dev wiki about avoiding permission explosions
<barry> oops, looks like we're missing flacoste and gary
<bigjools> autofail, he's not here
<mars> barry, flacoste is on vacation this week
<barry> ah thx
<mars> and gary is at OSCON
<barry> thx
<bac> flacoste did add that page
<barry> bac: super
<barry> [TOPIC] mentoring updates
<bac> and, it turns out, the example he cited of permission explosion was actually necessary...
<MootBot> New Topic:  mentoring updates
<barry> bac: oh!  did he talk about that in the wiki?
<bac> no.  the lesson still stands...
<barry> cool
<barry> so.  everyone, please congratulate deryck on his graduation to full-fledged reviewership!
 * bigjools hi-5s deryck
 * deryck hi-5s bigjools back
<barry> deryck: i heard glowing reports of your reviews.  i think you graduated in record time.  great job! :)
<deryck> barry, I feel so grown up now. :)
<barry> and thanks gmb for your mentoring
<noodles> Congrats deryck!
<deryck> yes gmb rocks as a mentor
 * gmb applauds
<gmb> deryck: Only when the student doesn't actually need all that much mentoring :)
<barry> deryck: remember that you can now switch ocr days if you want.  just ping me in email or pvtmsg to work out any day changes
<deryck> barry, ok, will do.  I'm flexible about that and happy to do whatever day is best for others.
<intellectronica> congratulations deryck!!!
<barry> one other quick note: rockstar is out tomorrow, so i will be switching my ocr this week from friday to thursday so that i can mentor leonardr
<barry> any other mentoring issues today?
<barry> moving on then
<barry> [TOPIC]  * Alphabetical sorts are case sensitive? insensitive? - barry
<MootBot> New Topic:   * Alphabetical sorts are case sensitive? insensitive? - barry
<barry> so, in __all__ and a few other places, we want lines to be sorted
<intellectronica> insensitive
<sinzui> insensative
<barry> we are currently inconsistent about this.  so i'd like to hear opinions
<bigjools> insensitive
<abentley> insensitive
<henninge> insensitive
<allenap> UCA
 * henninge wonders if we are an insensitive bunch ...
 * jtv feels particularly insensitive
<intellectronica> allenap: what does uca stand for?
<jtv> Unicode Collation Algorithm?
<adeuring> the nice thing about case-sensitive sorting is the emacs helper we have
<barry> ouch
<allenap> jtv: Yep.
<noodles> By insensitive, do we mean: from blah import Apples, apple, Banana, banana
<barry> adeuring: agreed
<adeuring> ...for sorting imports
<allenap> I know next to nothing about it though! :)
<bac> adeuring: yes.
<barry> also M-x sort-lines is case sensitive by default :)
<intellectronica> noodles: that's already theology, but yes, i guess caps first makes sense
<noodles> lol
<jtv> allenap: don't need to, it's mostly about nasty stuff like I/i with/without dots and weird orders of reading a string.
<allenap> jtv: I didn't realise at first that we were talking just about module imports and the like. Doh.
<allenap> ECU - Emacs Collation Algorithm.
<intellectronica> Ulgorithm
<allenap> Crap.
<barry> so, am i alone in wanting case sensitive sorting? ;)
<jtv> I still prefer insensitive... is emacs being sensitive because it just is, or because people are running it in C locale?
<adeuring> barry: me too ;)
<barry> jtv: it's just case sensitive by default.  you have to (setq sort-fold-case t) to make it otherwise
<bac> i'm for sensitive but mainly due to the tools...
<barry> this is one place i /would/ like to be consistent so we don't end up in line sorting churn
<BjornT_> bac: !sort in vim is case insensitive
<bigjools> heh
<barry> BjornT_: is this going to be an emacs vs vim fight? :)
<jtv> I've been doing insensitive...  for me converting what you already have is usually more important than Making a Decision.
<bac> BjornT_: i should have said "my tools" but let's not go there.
<allenap> Sensitive, so classes get sorted separately from functions.
<barry> allenap: oh.  nice point!
<cprov> allenap: that's a good point.
<allenap> Finally, I say something that makes sense. Phew.
<barry> :-D
<intellectronica> tools aside, anything but case-insensitive is harder for humans to work with. we should optimize for that
<noodles> +1
<barry> intellectronica: python is case sensitive :)
<abentley> allenap: But just in the context of imports and __all__, not in the body of the file?
<barry> abentley: gawd no
<allenap> abentley: Yeah, that's true. I tend to like putting functions at the top.
<noodles> barry: but you are not a python interpreter ;)
<barry> noodles: you're sure about that?
<bigjools> barry: start a vote so we can move on!
<barry> bigjools: fantastic idea
<allenap> barry can already run the python 4.0 bytecode.
<sinzui> I wish I could find this discussion from two years ago. This is not the first time we have discussed this
<noodles> lol
<barry> #startvote sort __all__ and similar case insensitive = -1, case sensitive = +1
<jtv> guys, no Turing tests here please
<bigjools> yeah I have deja vu
<barry> #startvote
<adeuring> +1
<sinzui> -1
<jtv> 0
<bac> +1
<cprov> +1
<allenap> +1
<bigjools> botfail
<intellectronica> -1
<noodles> -1
<BjornT_> -1
<barry> hang on folks!
<barry> [VOTE]
<MootBot> Please vote on: .
<MootBot> Public votes can be registered by saying +1/-1/+0 in the channel, private votes by messaging the channel followed by +1/-1/+0  to MootBot
<MootBot> E.g. /msg MootBot +1 #launchpad-meeting
<allenap> +1
<barry> okay, now!
<MootBot> +1 received from allenap. 1 for, 0 against. 0 have abstained. Count is now 1
<gmb> +1
<MootBot> +1 received from gmb. 2 for, 0 against. 0 have abstained. Count is now 2
<intellectronica> -1
<MootBot> -1 received from intellectronica. 2 for, 1 against. 0 have abstained. Count is now 1
<barry> +1
<MootBot> +1 received from barry. 3 for, 1 against. 0 have abstained. Count is now 2
<cprov> +1
<BjornT_> -1
<MootBot> +1 received from cprov. 4 for, 1 against. 0 have abstained. Count is now 3
<bac> +1
<MootBot> -1 received from BjornT_. 4 for, 2 against. 0 have abstained. Count is now 2
<jtv> 0
<noodles> -1
<MootBot> +1 received from bac. 5 for, 2 against. 0 have abstained. Count is now 3
<sinzui> -1
<MootBot> -1 received from noodles. 5 for, 3 against. 0 have abstained. Count is now 2
<MootBot> -1 received from sinzui. 5 for, 4 against. 0 have abstained. Count is now 1
<jtv> +0
<MootBot> Abstention received from jtv. 5 for, 4 against. 1 have abstained. Count is now 1
<abentley> +1
<bigjools> -1
<adeuring> +1
<MootBot> +1 received from abentley. 6 for, 4 against. 1 have abstained. Count is now 2
<MootBot> -1 received from bigjools. 6 for, 5 against. 1 have abstained. Count is now 1
<MootBot> +1 received from adeuring. 7 for, 5 against. 1 have abstained. Count is now 2
<salgado_> -1
<MootBot> -1 received from salgado_. 7 for, 6 against. 1 have abstained. Count is now 1
<henninge> -1
<MootBot> -1 received from henninge. 7 for, 7 against. 1 have abstained. Count is now 0
<deryck> +1
<MootBot> +1 received from deryck. 8 for, 7 against. 1 have abstained. Count is now 1
<bigjools> jtv you meanie
 * barry is on the edge of his seat!
<gmb> This is the tensest vote evar.
<mars> 0
<sinzui> flacoste is a vim users and a human being: he would vote -1
<bigjools> agh another fence-sitter!
<jtv> bigjools: I _honestly_ _don't_ _care_
<abentley> -1
<barry> yeah, but gary would definitely vote +1 <wink>
<gmb> I'm a vim user and a human being... I vote +1
<sinzui> kiko is also a vim user, he will vote -1
<gmb> Well, I'm a vim user...
<bigjools> haha
<sinzui> gmb: you have issues. I don't think we need to bring them up now.
<jtv> And I still say what we decide here doesn't matter that much unless we clean up what we already have.
<bigjools> abentley: you already voted +1!
<gmb> Touche.
<bigjools> I prefer to use an editor, not an OS
 * bigjools hides
<abentley> bigjools: Yes, but the vote was unspecified, so I assumed we were voting for insensitive.
<barry> abentley: mootbot is stricter than the florida election committee
<allenap> vim is an OS. A DOS-era OS.
<intellectronica> aha, i abentley changed his vote that changes the picture
 * allenap ducks
<barry> well, don't forget asiapac has to weigh in
<bigjools> since it's so close, I vote we leave it *random*
<barry> bigjools: perfect!
<bac> jml, mwh will definitely +1
<bigjools> :)
<allenap> bigjools: +1, and if it's at least sorted one way or the other, don't change it.
<barry> bac: yeah, i think so
<barry> #endvote
<bigjools> yep, on reflection I think this is a pointless debate
<noodles> yap
<intellectronica> bigjools: it's not. if we could avoid the editor wars and make a decision it would be good to have a standard on that
<jtv> What's already there generally overrules what is decided somewhere, and I don't think this is worth a cleanup effort.
<barry> we're about evenly divided anyway.  i'll consult with asiapac and see where we stand, then make an announcement later today
<bigjools> intellectronica: in the grand scheme of things, it's not that important IMO
<sinzui> If only barry had thought to include his editor's behaviour into PEP8
 * barry looks around for the time machine keys
<barry> anyway.  that's all i have on my list, so now...
<barry> [TOPIC] peanut gallery
<MootBot> Vote is in progress. Finishing now.
<MootBot> Final result is 8 for, 7 against. 1 abstained. Total: 1
<MootBot> New Topic:  peanut gallery
<sinzui> I have a sonic screw driver in my hand roght now
<barry> any topics you might have that are not on the agenda?
<mars> +1 for Doctor Who references
<jtv> sinzui: pour me one too please
<intellectronica> did we ever decide how to get new contributors in?
 * sinzui really does have a sonic screwdriver
<intellectronica> do they do normal reviews?
<intellectronica> are we going to put something in place to guide them through the development process, pre-imp-->landing ?
<barry> intellectronica: yes, i think so, with a dedicated shepherd to help them through the process.
<barry> intellectronica: i will write up a proposal for this
<barry> [ACTION] barry to write a proposal about guiding new outside contributors
<MootBot> ACTION received:  barry to write a proposal about guiding new outside contributors
<intellectronica> so the current recommendation, if anyone wants to start working on lp branches is to find a mentor who will guide them through the process?
<intellectronica> i think that's a good way to do this
<sinzui> I think our current process of hack on code for 3 months, then being mentat training will work fine
<bigjools> barry: how much more info than the existing wiki page do you plan on adding?
<adeuring> i think if somebody just sends a little bug fix, but clearly says that he sodes not want to get closer invloved, we should not require the regular proceure
<adeuring> s/sodes/does/
<jtv> Let's not re-use "mentor" here...
<intellectronica> sinzui: oh, i'm not talking about becoming reviewers, but about getting branches in
<intellectronica> we can worry about that later
<barry> sinzui: agreed
<sinzui> intellectronica: my bad
<barry> bigjools: i don't know i have to review what we've got ;)
<bigjools> https://dev.launchpad.net/PatchSubmission
<barry> jtv: right, "shepherd" is what i've been using, but maybe not a great term
<abentley> What about this policy that we're not supposed to put procedures on the dev wiki?  I think it would make a lot of sense to put all the procedures we can on the dev wiki.
<barry> abentley: this is process that directly involves the community now, so definitely dev wiki
<intellectronica> i think it would be good to emphasize the importance of getting a mentor before starting the work, but other than that it looks perfect
<barry> bigjools: thanks, i'll review that
<gmb> Didn't we rip out hte mentorship code for bugs? Shame...
<adeuring> how do we know if somebody signed the contributor's agreement?
<barry> adeuring: and once they sign it, can they land branches into pqm directly?
<intellectronica> we could add everyone who did to a team when they send it
<gmb> barry: That would be dangerous.
<gmb> potentially, anyway.
<barry> gmb: well, signing it is a necessary but not sufficient condition!
<adeuring> barry: we're testing via EC2, so I think one of us needs to do that.
<gmb> barry: Okay, agreed.
<barry> adeuring: meaning, our outside contributors can't run through ec2?  i guess there's the little matter of cost
<jtv> barry: just remembered the term I had in mind: "sponsor."
<adeuring> barry: yes, that's what I meant
<bigjools> make check *cough*
<gmb> jtv: +1
<noodles> +1 for sponsor
<gmb> bigjools: make computer_melt
<barry> jtv: nice
<bigjools> gmb: speak for yourself!
<intellectronica> i think mentor is better because it communicates that you will get help from the person through the entire process
<sinzui> adeuring: The CoC code is generic. We just assume it is The ubuntu code co conduct in the UI. We will update the CoC UI to support mutilple signings
<intellectronica> i think that's very important because i worry that people will come, out of the blue, with branches they want merged, and will be dissapointed when we have to reject them for whatever reason
<barry> let's take further discussions of this to the new public mailing list, and i will take the action item to collect feedback and update wiki pages
<barry> intellectronica: we need to triage branches early.  people may submit things we won't ever care about (e.g. convert all lp code to perl :).  we should let them know this early in the process so they don't waste their time
<jtv> intellectronica: a sponsor is also supposed to go to bat for you.  But we've already had confusion over this, might as well keep separate terms.
<barry> intellectronica: the beauty of course, is that we're free software now
<intellectronica> barry: exactly
<barry> cool.  7 minutes left.  anything more on this or any other topic?
<jtv> ceterum censeo carthaginem esse delendam
<barry> i believe we are done then
<barry> #endmeeting
<MootBot> Meeting finished at 09:39.
<barry> thanks everyone!
<jtv> thanks barry, you evil emacs user!
<bac> thanks barry
<barry> jtv: i am now doing irc in emacs too :)
<intellectronica> thanks barry
<jtv> emacs is an os... vim was written by someone who already had a nice one
<bigjools> barry: irc in emacs?  you sick puppy!
<barry> jtv: what's an os?  oh, it's all that extra crap that slows down emacs?
<bigjools> chuckle :)
<jtv> barry: sure, blame some other piece of software...  !
<barry> jtv: let me count the ways... :)
<jtv> barry: at least that extra crap doesn't usually use a pointer's high byte to store lisp bits!
 * jtv is enjoying this
<barry> jtv: ouch
<barry> jtv: what are you, a parenthesist?
<jtv> barry: I've got nothing against parentheses...
<jtv> ...in reasonable numbers.
<jml> lalalala
<thumper> jml: tellytubbies
 * thumper pictures jml in a yellow fuzz suit
<barry> #startmeeting
<MootBot> Meeting started at 17:30. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<jml> thumper, I was actually singing the Bob Dylan song that features in the Big Lebowski
<barry> jml, thumper, mwhudson howdy
<jml> barry, hi
<thumper> hi
<barry> jml: i am loving erc :)
<thumper> erc?
<barry> emacs irc client
<jml> barry, :(
<barry> jml: no.  :)
<jml> barry, last time I used erc, I accidentally ended up editing other people's nicks.
<thumper> heh
<barry> ouch
<jml> when I wasn't blocked on network io
<barry> i hook it up to bip so it's fast
<barry> and isn't hampered by canonical's ssl craziness
<barry> anyway...
<barry> quick update and then topics?
<barry> summary from ameu...
<barry> deryck graduates
<thumper> congrats
<barry> i have an action item to start a discussion about sponsoring contributions from the community
<barry> and we had a discussion and vote about __all__, etc, sorting, vis case sensitive or insensitive
<barry> on the latter, without knowing the results of this morning's vote, what say ye?
<jml> slow news week, eh?
<barry> yep
<jml> barry, I was told insensitive in the past.
<jml> barry, and so that's what I've been doing
<barry> jml: yes, but what do you /really/ want :)
<jml> barry, but I don't have a strong feeling on the matter
<jml> barry, as long as it's consistent.
<barry> jml: agreed.  we don't currently have consistency
 * jml would much rather have from foo import (bar,\nbaz,\n) than ordering.
<thumper> +1 on consistency
<barry> jml, thumper, mwhudson so if you had to vote, which would it be?
<jml> barry, so in that case, I default to everyone else being consistent with what I already do :P
<thumper> jml: is this alphabetical case sensitivity of imports?
<barry> jml: in __all__'s do you use M-x sort-lines?
<jml> but I might change my vote for a barrel of salted pork.
<thumper> sorry, barry not jml
<jml> thumper, yeah.
<barry> thumper: yes
<jml> barry, umm... no, I think I manually edit.
 * jml votes [A, a, B, b, ...]
<barry> jml: ah
<thumper> barry: I've not been personally consistent
<barry> jml: that's case insensitive then
<jml> barry, yes
<thumper> barry: not really
<thumper> what about [DEF, dab] ?
<thumper> capitals first or real insensitive?
<jml> thumper, that's case sensitive
<jml> thumper, [A, B, ..., a, b, ...]
<thumper> [DEF, dab, EFG, eag]
<jml> all caps being special?
<jml> *gasp*
<thumper> possibly?
<barry> nothing special about it.  ascii sort
<thumper> I'm abstaining because I really don't care
<thumper> as long as people are consistent and it is documented
<jml> maybe sorting like: sorted(__all__, key=lambda name: sum(map(ord(name))))
<barry> ok.  and jml votes for insensitive.  mwhudson is silent :)
<jml> barry, what was the public vote?
<barry> jml: it was almost exactly tied.  abentley threw it to the supreme court by changing his vote :)
<thumper> barry: mwhudson said he had to step away for a few minutes
 * mwhudson reappears
<jml> barry, so I guess you lean to sensitive sorting because of sort-lines
<barry> jml: yeah
<thumper> mwhudson: just in tie for a vote on case sensitivity of import orderings :)
<jml> I'll give you what you want, if I can change to...
<jml> from foo import (
<jml>   bar,
<thumper> s/tie/time/
<jml>   baz,
<jml> )
<thumper> I vote for jml's one
<thumper> less conflicts on merging
<mwhudson> thumper: sadly i don't care
<barry> jml: you mean, one import per line always?
<thumper> barry: yeah baby, yeah!
<barry> jml: M-x py-sort-imports :)
<mwhudson> tbh
<mwhudson> with flymake keeping unnecessary imports out
<mwhudson> i just mentally skip over import blocks
 * jml agrees
<thumper> mwhudson: me too
<jml> the whole point is avoiding conflicts, in my mind.
<mwhudson> it could be formatted in one line using ; for all i care
<thumper> I tend to skip over them in reviews too
<mwhudson> so i think i agree with jml then
<barry> i've been in import unspaghetti mode today so i can't ignore them.  it's like being hungry when you go food shopping.  all the poptarts and chef boyardee is screaming out to me
<barry> i hear you about the conflicts
<mwhudson> barry: https://bugs.edge.launchpad.net/launchpad-registry/+bug/402845 ?
<ubottu> Ubuntu bug 402845 in launchpad-registry "./bin/py -c 'from lp.registry.model import person' fails due to circular import" [Undecided,Triaged]
<thumper> barry: one import per line - true case insensitive sort
<barry> thumper: gotcha
<mwhudson> i believe the 'rope' library has support for automatically managing import sections
<mwhudson> but i've never got it working
<barry> okay, enough with the trivial stuff.  that is all i have for the summary.  what's on y'alls mind these days?
<thumper> the code review UI :)
<jml> barry, not much of import, but two crazy ideas that someone else might like to take up.
<barry> thumper: tell me how you will increase its awesomeness
<barry> jml: let's here it
<jml> barry, I'd really love to see a graph of 'branches waiting review' over time, and a graph of 'branches approved to land' over time.
<thumper> barry: love to, but now is not the time
<mwhudson> jml: globally, or for launchpad?
<jml> barry, I'd also love to see a distribution chart of time between submitting & landing.
<jml> mwhudson, just Launchpad itself.
<mwhudson> k
<thumper> jml: we have date created, date reviewd, date merged :)
<jml> thumper, *nod*
<jml> I know it's all possible.
<thumper> I'd be nice to have the graphs on LP actually
<thumper> for any project
<jml> I just haven't had the opportunity to do it, and I've had the idea for months
 * thumper thinks about this...
<jml> so I'm putting it out there for others :)
<jml> that's it.
<jml> barry, ^
<barry> jml: thanks
<barry> it would be cool
<barry> mwhudson, thumper anything else?
<mwhudson> nope
<thumper> nope
<barry> #endmeeting
<MootBot> Meeting finished at 17:50.
<barry> thank you guys!
#launchpad-meeting 2009-07-23
* Ursinha changed the topic of #launchpad-meeting to:  Launchpad Meeting Grounds | Channel logs: http://irclogs.ubuntu.com/ | Weekly meetings: https://dev.launchpad.net/IRCMeetings | Lost in time? date -u
<henninge> me ;)
<henninge> oh, I did not miss it. Google Calendar *still* has the wrong time ...
<Ursinha> lol
<Ursinha> henninge, I thought google calendar was showing utc time
<henninge> Ursinha: it does
<henninge> Ursinha: But my copy of the meeting was at the wrong time ...
<Ursinha> oh
<henninge> Ursinha: but there used to be some confusion about this in Google Calendar but it seems to be fixed now ... ;)
<Ursinha> henninge, :P
<matsubara> #startmeeting
<MootBot> Meeting started at 10:00. The chair is matsubara.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<matsubara> Welcome to this week's Launchpad Production Meeting. For the next 45 minutes or so, we'll be coordinating the resolution of specific Launchpad bugs and issues.
<matsubara> [TOPIC] Roll Call
<MootBot> New Topic:  Roll Call
<henninge> me
<herb> me
<bigjools> me
<Ursinha> me
<mars> me
<abentley> me
<sinzui> me
<matsubara> hi stub
<stub> me
<matsubara> let's move on, tom berger can join in later
<matsubara> [TOPIC] Agenda
<MootBot> New Topic:  Agenda
<matsubara>  * Actions from last meeting
<matsubara>  * Oops report & Critical Bugs & Broken scripts
<matsubara>  * Operations report (mthaddon/herb/spm)
<matsubara>  * DBA report (stub)
<matsubara> [TOPIC] * Actions from last meeting
<MootBot> New Topic:  * Actions from last meeting
<matsubara>  * Ursinha to check if all accounts requesting fix on feedback@ were fixed
<matsubara>  * matsubara to chase rockstar about failure on updatebranches script
<Ursinha> matsubara, apparently all accounts were fixed
<matsubara> I talked to rockstar about the updatebranches script failures, he was debugging. I'll ask him again when he comes back from holidays
<matsubara> [action] matsubara to chase rockstar about failure on updatebranches script
<MootBot> ACTION received:  matsubara to chase rockstar about failure on updatebranches script
<matsubara> thanks Ursinha
<matsubara> [TOPIC] * Oops report & Critical Bugs & Broken scripts
<MootBot> New Topic:  * Oops report & Critical Bugs & Broken scripts
<matsubara> Ursinha, please take the stage
<Ursinha> ok
<Ursinha> most of the "unusual" oopses we had were rollout glitches, also we had a few very low priority which I talked to people and filed bugs
<Ursinha> we have two critical bugs, after the rollout
<Ursinha> https://bugs.edge.launchpad.net/launchpad-foundations/+bug/403283
<Ursinha> https://bugs.edge.launchpad.net/launchpad-foundations/+bug/403306
<ubottu> Error: This bug is private
<ubottu> Ubuntu bug 403306 in launchpad-foundations "missing softlinks for shipit and login" [Critical,In progress]
<matsubara> Ursinha, the private one is in progress but not assigned?
<matsubara> who's taking care of it?
<Ursinha> I wasn't sure if that was ok for the librarian bug to be public, given the info in the report, if so I'll be happy to switch
<Ursinha> matsubara, apparently stub changed the status
<Ursinha> stub, are you taking care of that?
<matsubara> I assigned that one to stub
<Ursinha> about the missing softlinks, I know stub is taking care of that, but I have a question
<stub> I have a branch awaiting RC
<Ursinha> how could we avoid that to happen?
<Ursinha> I see that the revision that caused that wasn't QAd - at least in the testplan that was NEEDSTESTING
<stub> However, the production side of things needs to be done by the losas - editing the /etc/init.d script etc.
<matsubara> [action] stub to get RC for branch that fixes bug 403283
<MootBot> ACTION received:  stub to get RC for branch that fixes bug 403283
<ubottu> Bug 403283 on http://launchpad.net/bugs/403283 is private
<ubottu> Bug 403283 on http://launchpad.net/bugs/403283 is private
<herb> stub: is the branch listed in the bug? I'd like to take a look at it so we know what to expect.
<stub> https://code.edge.launchpad.net/~stub/launchpad/trivial/+merge/9179
<stub> herb: it should be linked. You don't need that script of course, but it makes sense to keep it in the lp tree so devs can test if they broke it
<herb> stub: cool. thanks. I'll take a look.
<matsubara> Ursinha, are we expecting some of those low importance oops fixes to land for the re-roll?
<mars> strange, the commit message doesn't mention having to touch those two links
<Ursinha> matsubara, nope
<mars> "List
<mars>         duplicate subscribers in the bug subscribers portlet even when
<mars>         there is already an indirect subscription via a team membership."
<Ursinha> matsubara, not so far
<matsubara> Ursinha, isn't that what kiko asked yesterday?
<stub> herb: And feel free to jump in and change and implement stuff if you want - lp-foundations doesn't have to own this stuff
<Ursinha> matsubara, nope
<stub> mars: I think it was a cock up rather than a deliberate change
<Ursinha> but we have some outstanding oopses that keep happening
<Ursinha> who's on behalf of flacoste today?
<matsubara> Ursinha, yes, those are the ones I meant
<matsubara> Ursinha, mars
<mars> stub, agreeded, but if so, did it just happen to slip past the dev, and the rc-reviewer?
<stub> https://code.edge.launchpad.net/~stub/launchpad/pending-db-changes/+merge/9188 is also awaiting rc anyway. What I'm more interested in is how come the test suite still passes.
<mars> Ursinha, I'm standing in for flacoste
<matsubara> stub, why the branch that introduced the critical bug wasn't QA'd on staging?
<Ursinha> matsubara, I guess that was a bugs branch
<matsubara> oh, sorry. I thought it was a foundations issue
<mars> stub, has the test suite changed to accommodate open sourcing in some way?  And thus removing those components from the suite?
<Ursinha> matsubara, the missing links are, but which introduced that not
<matsubara> Ursinha, ok.
<stub> mars: I don't know.
<Ursinha> mars, we have an oopses that happens almost everyday
<Ursinha> *an oops
<Ursinha> mars, https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1300XMLP5
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1300XMLP5
<Ursinha> mars, once I talked with flacoste about them, and he said that basically that wasn't our problem, iirc :)
<mars> Ursinha, who would be the 'us' in "our problem"?
<Ursinha> mars, foundations/launchpad
<Ursinha> mars, i.e. not a bug
<Ursinha> do you know what could we do to avoid those?
<abentley> Ursinha: is this the private or public XMLRPC server?
<mars> Ursinha, do we have a procedure for dealing with such noise?  The feels like a 404: it is an error in the system state, but not a programmer error.
<Ursinha> I mean, we have a list of oopses that are growing every day because of hanging little things
<Ursinha> mars, that's exactly my question :)
<mars> Ursinha, for this specific issue, I would have to investigate.
<Ursinha> mars, if we could deal differently those oopses, raising 404 instead of that oops, or even if we (me and matsubara) could move them to another section of the report
<matsubara> abentley, private one
<mars> for the larger issue of noise, well, maybe creating a new OOPS category or tag that can filter them out
<stub> matsubara: The branch was rc, so not much QA time. Even if it was qa'd, that doesn't mean anyone would have tested the login or shipit systems which should have been unaffected according to the commit message.
<abentley> matsubara: Well, it kinda is our problem, since we control both ends, then.
<mars> Ursinha, not 404, but one of the other status codes, for "Ill-formed request"
<Ursinha> mars, sorry, bad brain link :)
<abentley> I agree that bad input should not be treated as an OOPS
<matsubara> I don't like moving those oopses to another section.
<Ursinha> matsubara, me neither.
<abentley> But it should be logged *somewhere*.
<matsubara> if the input is bad and we know it, let's not log an oops for it
<Ursinha> mars, could you do some more investigation on this? I'll file a bug, can I?
<matsubara> we used to have a bug for ExpatErrors
 * Ursinha looks
<matsubara> was it fixed?
<mars> Ursinha, certainly, please do
<Ursinha> mars, ok, so I'll search for the bug, and file one if not able to find
<matsubara> [action] ursinha do file bug for OOPS-1300XMLP5
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1300XMLP5
<MootBot> ACTION received:  ursinha do file bug for OOPS-1300XMLP5
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1300XMLP5
<Ursinha> thanks matsubara
<matsubara> Ursinha, anything else?
<mars> I think the procedure is to turn bad data from a "500: Internal Server Error" into a "400: Bad Request"
<Ursinha> matsubara, yes
<Ursinha> copy and paste fail
<Ursinha> we also have constant UnicodeDecodeErrors and the like
<Ursinha> everyday, and I noticed that they're somehow growing
<Ursinha> is the unicode problem really unsolvable?
<abentley> Ursinha: A bunch of them should disappear as of this rollout.
<Ursinha> abentley, right, but they seem to be everywhere. I'll keep one eye on them, and will report back next meeting
<Ursinha> matsubara, [action] Ursinha to ^
<Ursinha> :P
<Ursinha> mars, this one is hanging for some time: bug 354593
<mars> Ursinha, a unicode error in Python is solvable.  Are they coming from everywhere in the system?
<ubottu> Launchpad bug 354593 in launchpad-foundations "SSO exceptions views need proper branding" [High,Triaged] https://launchpad.net/bugs/354593
<abentley> Ursinha: If you're looking for an ultimate solution, it's along the lines of "use Python 3.0".
<matsubara> [action] Ursinha to keep one eye on UnicodeDecodeErrors, and will report back next meeting
<MootBot> ACTION received:  Ursinha to keep one eye on UnicodeDecodeErrors, and will report back next meeting
<Ursinha> abentley, :)
<Ursinha> mars, I'll show you later, we have several oopses and different bugs for them
<Ursinha> 5 digit bugs :)
<Ursinha> mars, can you take a look in that bug, please?
<mars> ok
<Ursinha> using kiko's words: "if they happen more than once a week they are not low priority"
<Ursinha> matsubara, [action] mars to take a look at bug 354593
<ubottu> Launchpad bug 354593 in launchpad-foundations "SSO exceptions views need proper branding" [High,Triaged] https://launchpad.net/bugs/354593
<mars> ok, so we know the problem, and we have an ideal solution
<matsubara> [action] mars to take a look at bug 354593
<MootBot> ACTION received:  mars to take a look at bug 354593
<mars> did Francis mention a quick interim solution?
<mars> stub, ^?
<stub> interim solution of what?
<Ursinha> stub, bug 354593
<ubottu> Launchpad bug 354593 in launchpad-foundations "SSO exceptions views need proper branding" [High,Triaged] https://launchpad.net/bugs/354593
<stub> No - I haven't discussed that with him.
<mars> ok
<mars> I'll have a look at the reports, split them into new bugs, try to eliminate the OOPSes
<Ursinha> mars, can you make comments in the bug, if that applies, please?
<stub> It should be possible to register new exception views for that layer, no?
<mars> the branding is a related, but larger issue
<mars> Ursinha, sure
<matsubara> Ursinha, anything else? we need to move on as we only have 11min
<Ursinha> matsubara, no, I'm done for today.
<matsubara> thanks everyone
<Ursinha> thanks mars, stub, abentley and herb
<matsubara> [TOPIC] * Operations report (mthaddon/herb/spm)
<MootBot> New Topic:  * Operations report (mthaddon/herb/spm)
<herb> 2009-07-19 - We had another app server hang during log rotation. Fortunately it seems there has been some progress on bug #287304
<Ursinha> and all the others :)
<ubottu> Launchpad bug 287304 in launchpad-foundations "App Servers: Remove need for restart on logrotation" [High,Incomplete] https://launchpad.net/bugs/287304
<herb> 2009-07-21 - We open sourced! Congratulations to all the developers on a job well done. We saw an uptick in traffic to the codehosting system and, apparently, quite a few new project registrations. Overall the system handled the increased load well.
<herb> 2009-07-22 - Yesterday evening we rolled out 2.2.7. We had some hiccups again but we have bugs filed for those, as was discussed during the critical bugs section.
<herb> That's it from the LOSAs unless there are questions.
<matsubara> thanks herb
<matsubara> [TOPIC] * DBA report (stub)
<MootBot> New Topic:  * DBA report (stub)
<herb> thanks matsubara
<stub> Database update went painlessly, or at least I haven't heard any tales of pain and misery and nobody woke me up.
<stub> With 2.2.7, we can start pruning unwanted People. We just need to add '--experimental' to garbo-daily.py and maybe tweak the --abort-script argument if the default of 24 hours is too long.
<stub> Nothing else interesting happening.
<matsubara> stub, are you taking care of enabling the pruning script? or have an RT for the losas to do it?
<mthaddon> stub: yep, db updates were pretty quick and painless this time around
<stub> I think salgado might have done that already. I was going to worry about it after reroll and the fires are all out.
<matsubara> [action] matsubara to chase salgado about people pruning script
<MootBot> ACTION received:  matsubara to chase salgado about people pruning script
<matsubara> ok, anything else for stub?
<matsubara> thanks stub
<matsubara> before I close, just want to let you know that I created the 2.2.8 milestone
<matsubara> during yesterday's TLs meeting, the TL said it would be useful to coordinate work even if we're not doing a release for 2.2.8
<matsubara> so please, since we're not doing the 2.2.8 release, don't let your QA itens otherwise will have a huge backlog for 2.2.9
<matsubara> s/itens/items slip/
<matsubara> I think that's all for today
<matsubara> Thank you all for attending this week's Launchpad Production Meeting. See the channel topic for the location of the logs.
<matsubara> #endmeeting
<MootBot> Meeting finished at 10:43.
<herb> thanks everyone
<Ursinha> thanks matsubara
<Ursinha> and everyone
<abentley> thanks matsubara.
<Ursinha> matsubara, you have to change the final message, the location at the logs aren't in topic anymore :)
<Ursinha> matsubara, "Thank you all for attending this week's Launchpad Production Meeting. See https://dev.launchpad.net/MeetingAgenda for the logs."
<matsubara> Ursinha, will update. thanks
#launchpad-meeting 2010-07-28
<henninge> bac: did I miss the reviewers meeting or has it been canceled?
