| === mr_ian_ is now known as mr_ian | ||
| jMyles | Hey everybody. | 02:06 |
|---|---|---|
| ddoom_ | honk | 04:52 |
| ddoom_ | is there a cli for ubuntu one? | 04:52 |
| === mr_ian_ is now known as mr_ian | ||
| === CardinalXiminez_ is now known as CardinalFang | ||
| === aquarius is now known as jono | ||
| === jono is now known as aquarius | ||
| urbanape | Morning, folks. | 14:13 |
| dobey | meh-ning | 14:14 |
| aquarius | hey urbanape | 14:17 |
| urbanape | smells like standup | 15:00 |
| urbanape | *sniff sniff* yup | 15:00 |
| dobey | that's just the teen spirit | 15:00 |
| urbanape | ah, basically the same thing | 15:00 |
| rodrigo_ | :) | 15:00 |
| * urbanape slouches | 15:00 | |
| urbanape | MEETING BEGINS AND/OR STARTS! Desktop+ crowd, say "me" to get your turn for DONE/TODO/PLANNING/BLOCK | 15:03 |
| urbanape | me | 15:03 |
| CardinalFang | me | 15:03 |
| teknico | me | 15:03 |
| vds | me | 15:03 |
| rodrigo_ | me | 15:04 |
| dobey | me | 15:04 |
| urbanape | aquarius, jblount, Chipaca? | 15:05 |
| aquarius | me | 15:05 |
| urbanape | (I forget who else, so forgive) | 15:05 |
| urbanape | DONE: Separated out the lazr-js/YUI 3 from the new behavior and proposed the former for review. Will propose the latter shortly. | 15:06 |
| urbanape | TODO: Get Bindwood into SRU pipeline, so people don't have to rely on the PPA build. | 15:06 |
| urbanape | PLANNING: Bindwood improvements (manifest, threading, proper delete handling, &c) | 15:06 |
| urbanape | BLOCK: None | 15:06 |
| urbanape | CardinalFang: The COMFY CHAIR! | 15:06 |
| dobey | wait, what | 15:06 |
| CardinalFang | DONE: Found cause of Bug#475447, and assigned to python-gobject. Landed attachments (yay). Made list of things to fix in desktopcouch. | 15:06 |
| CardinalFang | TODO: Fix minor d-c bug 445611 ("expose revision in Record"). Release desktopcouch 0.6. Upload to Lucid. | 15:06 |
| CardinalFang | BLOCKED: None | 15:06 |
| CardinalFang | teknico! It's a fair cop. | 15:06 |
| ubottu | Launchpad bug 445611 in desktopcouch "The Record class should expose the current record revision" [Medium,Triaged] https://launchpad.net/bugs/445611 | 15:06 |
| dobey | what is this PLANNING thling? | 15:06 |
| teknico | DONE: more reviews, funambol presentation, discussed timestamps code for Funambol with thisfred and vds (#399200), started work on disabling free phone sync after 30 days (#403941) | 15:06 |
| teknico | TODO: more planning with Chipaca and vds, finish disabling free phone sync after 30 days (#403941) | 15:06 |
| teknico | BLOCK: none | 15:06 |
| teknico | next: vds | 15:06 |
| vds | DONE: did the review with a lot of people from the team, investigated on 30 days free plan, found problems with sync, triaged with thisfred, triaged problems with simplejson, discussing bout 30 free plan | 15:06 |
| vds | TODO: check the sync works after the fixes, go ahead with the 30 free plans | 15:06 |
| vds | BLOCKED: nope | 15:06 |
| vds | rodrigo_: please | 15:06 |
| urbanape | dobey: Chipaca asked for it yesterday | 15:07 |
| rodrigo_ | • DONE: XML<->HTML fixes. Face and review duty | 15:07 |
| rodrigo_ | • TODO: Conflict resolver tool in pair tool. Look at becoming a MOTU (https://wiki.ubuntu.com/UbuntuDevelopers). Make sandy's snowy test suite work with our server (http://git.gnome.org/cgit/snowy/tree/api/tests.py). Discuss with jdo and aquarius about oauth token per app, not per machine? | 15:07 |
| rodrigo_ | • PLANNING: contacts picker, music store, XML<->HTML move to lxml | 15:07 |
| rodrigo_ | • BLOCKED: no | 15:07 |
| rodrigo_ | next: dobey | 15:07 |
| dobey | ☺ DONE: Chat with John Lea about some issues in new client app spec, Triage, Client backports | 15:07 |
| Chipaca | me! | 15:07 |
| dobey | ☹ TODO: Planning, Verify client backports and bugs, 1.0.3 client release, SRU packages | 15:07 |
| dobey | ☹ BLCK: None. | 15:07 |
| dobey | aquarius: roll | 15:07 |
| urbanape | I'm not sure how it differs from TODO | 15:07 |
| aquarius | ⚀ DONE: work out how music store stuff all fits together; planning homework | 15:07 |
| aquarius | ⚁ TODO: make tomboy first-sync experience nicer; continue work on desktopcouch developer docs; write up things learned at UDS/sprint; work with rodrigo on Music Store, some more music store architecture planning; step-by-step guide to what happens during contact sync; write "pipe" to transfer data between two HTTP connections with twisted 9.0; write lazr-js branch | 15:07 |
| aquarius | ⚂ BLOCKED: music partner | 15:07 |
| aquarius | jblount? | 15:07 |
| rodrigo_ | urbanape: yeah :) | 15:07 |
| dobey | urbanape: no, he wanted us to do the planning he sent e-mail asking us to do last week... "put it in your TODO to do that planning" :) | 15:08 |
| urbanape | ah, my misread | 15:08 |
| dobey | aquarius: i think Chipaca is next | 15:08 |
| urbanape | nm, then | 15:08 |
| aquarius | ah, soz, Chipaca, go for it | 15:08 |
| Chipaca | DONE: hit people on the head re planning. TODO: continue hitting people on the head re planning, and get planning done. BLOCKED: no, except by people whose heads are harder than I can hit | 15:08 |
| * rodrigo_ gets his helmet | 15:09 | |
| rodrigo_ | Chipaca: so, the planning thing, I understood last week that you wanted a planning for the week, is that so? | 15:09 |
| * urbanape is insensate in the head area, he assumes. | 15:09 | |
| Chipaca | rodrigo_: for the week, every week. I also need a release plan, but that is different (and I have most of those parts) | 15:10 |
| rodrigo_ | Chipaca: and should we send it to you at the beginning of each week? | 15:10 |
| urbanape | aha, it all makes sorta sense now. | 15:10 |
| Chipaca | your day on monday should start something like: read email, ingest caffeine, read friends blogs, do planning | 15:11 |
| aquarius | we're supposed to email it to you? | 15:11 |
| aquarius | I must have missed that bit | 15:11 |
| Chipaca | no, you're supposed to create branches for the work you'll be doing | 15:11 |
| aquarius | ah, good. | 15:11 |
| Chipaca | empty branches, to be filled in when you actually do it | 15:11 |
| aquarius | did that. ;) | 15:11 |
| Chipaca | aquarius: is your launchpad user "sil"? | 15:12 |
| urbanape | I missed the original meeting on 30 Nov. and the one that presumably happened this past Monday. | 15:12 |
| aquarius | Chipaca, yep | 15:12 |
| rodrigo_ | bbiab | 15:12 |
| dobey | branches don't correlate with 99% of the work i've done this week | 15:12 |
| aquarius | nor me, really, but one does, so it got a branch | 15:12 |
| CardinalFang | Chipaca, what about researching bugs? E.g., my #475447, "Ubuntu-One client/syncd cause 10 wake ups / second each". That took some time to figure out if it's legitimate and whose problem it was, and it didn't need a branch or work from me this time. | 15:14 |
| Chipaca | dobey: I thought you prepared SRUs in launchpad? | 15:14 |
| Chipaca | CardinalFang: could you have planned for that at the start of the week? | 15:15 |
| Chipaca | in any case, I'm open to suggestions as to how to plan with minimal overhead | 15:15 |
| dobey | Chipaca: there are revisions from trunk that i backported to stable, but that's just a matter of finding the revision that fixed the bugs we need to get fixed in the SRU (for those that have been fixed already) | 15:15 |
| dobey | bzr merge -c REVNO ../trunk; bzr commit --author "Original Author" is all the "branch work" really | 15:16 |
| CardinalFang | Chipaca, I could have made a branch, but there was no way of knowing that I'd follow it from our apps -> twisted -> gobject -> pygtk source. | 15:16 |
| dobey | which is all insignificant as far as time goes | 15:16 |
| dobey | most of the work is searching through LP for the bugs, and matching them up with the revisions in trunk that fixed them. making sure the bugs are targetted properly, etc... | 15:17 |
| dobey | then i just gotta make a release of client today and do the SRU packaging, and submit it to get uploaded to karmic | 15:17 |
| CardinalFang | thisfred, aquarius, I'm adding a getter property for d-c Record for record revision. This should be read-only, right? There's never a good reason to set the _rev on something, right? | 15:18 |
| aquarius | CardinalFang, correct. | 15:18 |
| dobey | but hopefully i can start working on the new client bits | 15:19 |
| aquarius | CardinalFang, if someone wants to explicitly do that then they can do it the hard way. :) | 15:19 |
| Chipaca | rodrigo_: CardinalFang: dobey: re the different bits you're working on that are not new features, would one day a week (more or less) be enough to cover that? | 15:22 |
| rodrigo_ | Chipaca: yes, but sometimes a branch needs a previous one, and it takes more than one day to get them approved, but generally yes | 15:24 |
| Chipaca | rodrigo_: waiting for a branch to be approved shouldn't be busy time :) | 15:25 |
| dobey | Chipaca: not really. at least not yet. maybe after this initial SRU hump, that will be fine. | 15:25 |
| dobey | rodrigo_: you can specify a branch needs another one when proposing now, btw | 15:25 |
| rodrigo_ | Chipaca: it is, at least for the contacts picker, which I guess is 'new features' though :) | 15:25 |
| rodrigo_ | dobey: ah, ok | 15:26 |
| dobey | rodrigo_: but waiting for review shouldn't block development | 15:26 |
| CardinalFang | aquarius, thisfred, https://code.edge.launchpad.net/~cmiller/desktopcouch/record-expose-revid-bug445611/+merge/15953 | 15:26 |
| dobey | though i really wish i could spend some time working on infrastructure | 15:26 |
| thisfred | CardinalFang: might not have time to look at it any time soon. Maybe after lunchish | 15:27 |
| CardinalFang | thisfred, okay. it's v small, fwiw. | 15:27 |
| aquarius | CardinalFang, a bit worried about record_revision.startswith("1-") -- can we depend on the couch people not changing that/ | 15:27 |
| aquarius | ? | 15:27 |
| Chipaca | dobey: I'll ping you later to talk about that | 15:28 |
| Chipaca | dobey: most infrastructure work is best passed on to other people to do :) | 15:28 |
| aquarius | I asked last week whether we can guarantee that revisions go 1-xxx, 2-yyy, 3-zzz, etc, and no-one was prepared to say yes :) | 15:28 |
| thisfred | CardinalFang: right. This is a very leaky abstraction. I though the whole point was we didn't want to expose couchdb internals | 15:28 |
| thisfred | CardinalFang: and if people do want to get at them, ._rev seems fair warning | 15:29 |
| thisfred | aquarius: I think they don't, especially in the face of conflict resolution | 15:29 |
| Chipaca | ok, bbiab | 15:29 |
| CardinalFang | aquarius, no. It could start with "0" next week. It's just a sanity test, not part of the code. | 15:29 |
| CardinalFang | I do want to test that it's something I get from the DB. | 15:30 |
| aquarius | CardinalFang, yeah, but if they change couch they'll break that test, and we're not relying on 1-* as the first revision, which means that we've got a test that tells us that couch has changed but there's no benefit to it | 15:30 |
| CardinalFang | The only guarantee I have is that a subsequent revision id would lexically sort later. | 15:30 |
| dobey | Chipaca: ok | 15:31 |
| aquarius | if it was protecting us because elsewhere we rely on that behaviour, it's certainly a good thing to test, but it feels a bit like we're just setting up to get a broken test there :) | 15:31 |
| aquarius | or is that test really saying "is this record stored to the DB"? | 15:31 |
| CardinalFang | aquarius, so, another put, get, test for greater-than. That would make me somewhat more sure that the value came from the DB. Would it make you happy? | 15:32 |
| aquarius | what I'm wondering is: "is this record from the DB" is a useful question to ask; should we have an explicit way of answering it, rather than something sorta subsidiary like "does it have a revno"? | 15:32 |
| aquarius | or am I misunderstanding the point of your test? | 15:32 |
| thisfred | I would think the testing for is not None would be enough | 15:33 |
| CardinalFang | I want to make sure it's something the user should expect and find useful. I test not-None, but I want something better. | 15:33 |
| aquarius | sorry, I know I'm bikeshedding here | 15:34 |
| thisfred | I still think it should be underscored, so as to warn API consumers from relying on any specifics. | 15:35 |
| CardinalFang | aquarius, how is that now? | 15:37 |
| aquarius | CardinalFang, nice, that looks good | 15:39 |
| aquarius | will test | 15:39 |
| aquarius | approving. | 15:41 |
| CardinalFang | thisfred, okay, your complaint is that the very idea of revision id is too much internal knowledge of couchdb? | 15:44 |
| thisfred | yes. I can see where it may be useful sometimes, but an _ method/property makes it clear it is not part of our API and subject to change at any time | 15:45 |
| thisfred | that is an opinion though, so if I'm outvoted I can live with that and will approve the branch | 15:46 |
| urbanape | I don't see how you can test for something being a CouchDB-related thing without having some internal knowledge of its state or representation | 15:46 |
| CardinalFang | thisfred, it's your bug. aquarius any opinion? | 15:46 |
| thisfred | is it?eh which bug? | 15:47 |
| thisfred | ah | 15:47 |
| thisfred | the branchname is a clue | 15:47 |
| aquarius | thisfred, my opinion is: if we don't give people a way to get at that stuff, they'll just go around our API anyway. Knowing the revision number of something is useful (look at what you're doing with revnos elsewhere, for example) | 15:47 |
| CardinalFang | thisfred, ah, it was assigned to you. I thought you reported it. | 15:47 |
| thisfred | aquarius: if it's in our API, we are responsible for it not changing dramatically | 15:48 |
| aquarius | thisfred, only sorta. I mean, we expose a revision number. We don't care what it is | 15:49 |
| thisfred | aquarius: right, but then what's the point? I'd rather expose something useful, like _changes. As chad already has | 15:49 |
| thisfred | aquarius: I forget what I'm using revnos for elsewhere | 15:50 |
| aquarius | thisfred, same reason you're using revnos on the server; to be able to say "this document I've got? is it different from last time?" | 15:50 |
| thisfred | aquarius: I don't think I do, much. | 15:50 |
| thisfred | I explicitly try to hide that from consumers, by having the update_fields method | 15:51 |
| thisfred | which behaves as if you update a single field in a document | 15:51 |
| thisfred | update_field, likely | 15:51 |
| thisfred | so you don't have to care about revnos | 15:51 |
| thisfred | IMO that's an omission in python-couchdb | 15:52 |
| thisfred | aquarius: actually, cloud_server does not use revision numbers anywhere, I don't think | 15:53 |
| thisfred | I just grepped | 15:53 |
| thisfred | the watchdaemon does, | 15:53 |
| thisfred | but I don't know why, I didn't write that | 15:53 |
| thisfred | it should probably use _changes | 15:53 |
| aquarius | I thought you were using revnos for phonesync tracking? | 15:54 |
| thisfred | nope | 15:54 |
| thisfred | db sequence numbers | 15:54 |
| urbanape | so, does this little exercise render the original bug Invald? | 15:54 |
| thisfred | which should also be deprecated in favor of _changes I think | 15:54 |
| thisfred | I don't know, teknico filed it | 15:55 |
| aquarius | you can't deprecate seqnos in favour of _changes because you won't know what to put in "since" :) | 15:55 |
| thisfred | maybe the contacts web ui relies on revnos | 15:55 |
| thisfred | aquarius: why not? | 15:55 |
| CardinalFang | I have another complaint. I mentioned it in the attachments branch. To store attachments in Record and make CouchDatabase.put_record add them, I need the revision id to add them the piecemeal way. for blob in blobs: put_attachment(container_id, container_revision, ...) . | 15:55 |
| CardinalFang | So my step is put, get the latest(!), attach, attach, attach. | 15:56 |
| CardinalFang | That latest might not be what I just sent. | 15:56 |
| thisfred | aquarius: maybe I misunderstood that: we may have to still keep sequence numbers to query the _changes, but we would have a more efficient way to query for all the changes | 15:57 |
| aquarius | CardinalFang, yeah. How do you propose to resolve that, though? | 15:57 |
| thisfred | CardinalFang: I haven't done anything with attachments, but I gather they're not exactly a miracle of beauty in couchdb itself | 15:58 |
| thisfred | CardinalFang: can that be handled the same as the update_field method does? (I guess that should move to d-c since it doesn't have the same code as the cloud_server does) | 15:59 |
| CardinalFang | aquarius, I don't have a plan yet. Perhaps petition couchdb to return the record_id and the revision. | 15:59 |
| CardinalFang | ... on put | 15:59 |
| thisfred | http://friendpaste.com/2ppJfGsIzG25YmPJTigrnC | 15:59 |
| rtgz | Re: bug #479475 (my favorite bug these days). 1. Shared With Me directory should be translated into $HOME/.local/share/ubuntuone/shares on DBus request and remember the original path to update nautilus view (I have it done in Vala, much like readlink(1), need some Glib/C magic). 2. Since it is unlikely that SD will be rewritten to report status for a directory (bug #440848), I think the first step is to make ~/Ubuntu One emblems reflect current state, i.e. un | 16:00 |
| rtgz | synchronized, synchronized, transferring. Q/C? | 16:00 |
| ubottu | Launchpad bug 479475 in ubuntuone-client "File emblems don't display correct sync status" [Medium,Triaged] https://launchpad.net/bugs/479475 | 16:00 |
| ubottu | Launchpad bug 440848 in ubuntuone-client "UbuntuOne sync status emblems should apply to folders as well as files" [Wishlist,Triaged] https://launchpad.net/bugs/440848 | 16:00 |
| teknico | thisfred, what original bug did I file? | 16:01 |
| thisfred | teknico: #445611 | 16:01 |
| thisfred | bug #445611 | 16:02 |
| ubottu | Launchpad bug 445611 in desktopcouch "The Record class should expose the current record revision" [Medium,Triaged] https://launchpad.net/bugs/445611 | 16:02 |
| urbanape | CardinalFang: that would be helpful for Bindwood, as well. | 16:03 |
| urbanape | well, not so much, actually. I thought it could before and talked myself out of it then, too. | 16:03 |
| teknico | thisfred, right, I need it in the contacts web ui | 16:04 |
| urbanape | I should go for a bike ride sometime today. | 16:04 |
| thisfred | CardinalFang: well, it seems all Client consumers disagree with me, so that would appear to be conclusive evidence ;) | 16:06 |
| thisfred | API consumers, I mean | 16:06 |
| teknico | thisfred, any suggestions of a different way to detect attemps to changing the same record revision? | 16:07 |
| thisfred | teknico: I don't know what that means? why would you wnat to detect attempts to change a revision? | 16:07 |
| thisfred | revisions never change | 16:07 |
| teknico | thisfred, we talked about it :-) here's the sequence: | 16:07 |
| thisfred | I'll have a look at the code | 16:08 |
| thisfred | (I remember that we did, but not the specifics) | 16:08 |
| teknico | 1) a user opens the contact editing form, thereby loading rev.1 | 16:08 |
| teknico | 2) a sync changes the record, moving it to rev.2 | 16:08 |
| teknico | 3) the user tries to save the changed rev.1 | 16:09 |
| thisfred | teknico: ah. Again this is better solved by using update_fields() | 16:09 |
| teknico | 4) the server code notices rev.1 is not current anymore, denies the changes, and issues a conflict notice to the user | 16:09 |
| thisfred | which will update only the specified fields | 16:09 |
| thisfred | places a bit more burden on the webui, because the form there needs to keep track of which fields changed or did not, but then it will work | 16:10 |
| aquarius | can't you just *try* and save the thing? couch will give you a conflict anyway | 16:11 |
| teknico | thisfred, that's exactly what the web ui code is | 16:11 |
| teknico | *not* doing now | 16:11 |
| thisfred | aquarius: not easily in python-couchdb | 16:11 |
| aquarius | sounds like you're reinventing the couch conflict code, no? | 16:11 |
| teknico | but that's not the problem | 16:11 |
| teknico | the problem is, how do you know that the user is agreed with merging their changes with the ones coming from the sync? | 16:11 |
| thisfred | aquarius: no, I'm doing preemptive conflict resolution in the case you only update one or a few fields | 16:11 |
| aquarius | thisfred, that's not how you're supposed to do it ;) | 16:12 |
| aquarius | clever, mind :) | 16:12 |
| teknico | the user was seeing some values, and they changed them accordingly | 16:13 |
| thisfred | teknico: yeah, you're right | 16:13 |
| teknico | it does not seem good to end with something different from what the user thought it would | 16:13 |
| thisfred | teknico: well, you never end up with something different than the user intended, it's just that they might have intended something else if they had had more information... | 16:14 |
| teknico | that's why I prefer to punt and have the user start again from the new, synced values | 16:14 |
| teknico | discarding the now obsolete user changes | 16:14 |
| thisfred | yes, it's better. But more annoying ;) | 16:14 |
| thisfred | You don't know that they're obsolete | 16:14 |
| teknico | thisfred, yeah, I know, it's a fast world, who cares about quality, and all that | 16:15 |
| teknico | I say: screw it! ;-) | 16:15 |
| thisfred | In most case they won't be obsolete, I would bet | 16:15 |
| teknico | thisfred, the power of the ring is great, but you must resist it ;-) | 16:15 |
| thisfred | They might be fixing a typo that someone else also fixed, in which case the changes will be identical (update fields is smart enough to not even write the change in that case) | 16:16 |
| thisfred | or the user might have a different opinion than the other updater, in which case letting their change win is optimal | 16:16 |
| teknico | thisfred, that's like having bazaar merge together a different, but almost identical line :-) | 16:17 |
| thisfred | aquarius: I should rename the function to force_update_fields, probably | 16:17 |
| teknico | thisfred, so it doesn't even fail when there are changes to the same fields? | 16:17 |
| thisfred | and put <blink> tags in the docstring | 16:17 |
| thisfred | teknico: it will never fail | 16:17 |
| aquarius | it does sound a bit less like "please update these, if nothing's changed" and a bit more like "YAAR! I AM RIGHT! YOU LOSE, OLD CHANGES! YAAAAR!" | 16:17 |
| thisfred | the values the method tries to change will always win, any updates to other fields will be preserved | 16:18 |
| teknico | thisfred, is that function already in trunk? DID I REVIEW IT? oh, the horrors ;-P | 16:18 |
| thisfred | aquarius: you *only* lose updates to the fields you're changing, not to other fields | 16:18 |
| thisfred | I don't know if you reviewed it, but it has been in trunk for months | 16:19 |
| aquarius | this is like saying "I have only pissed on *some* of your chips", I think. ;-) | 16:19 |
| teknico | thisfred, oh, ok, that function has no notion of some fields having being changed by something else | 16:19 |
| aquarius | I quite like teh cleverness of update_fields, though :) | 16:19 |
| thisfred | aquarius: well, only on the chips I meant to piss onb | 16:19 |
| thisfred | ;) | 16:19 |
| thisfred | aquarius: I will rename it to force_update_fields, but then I think it could go into desktopcouch | 16:20 |
| teknico | so, in my previous scenario, if the sync changed field A, and the user changed field A too, the user will not ever see the value of field A coming from the sync | 16:20 |
| teknico | thisfred, I don't see I that could possibly be good | 16:20 |
| thisfred | teknico: yes | 16:20 |
| thisfred | correct | 16:20 |
| teknico | I don't see *how | 16:20 |
| thisfred | well, I it's convenience over correctness | 16:20 |
| thisfred | I agree that storing a conflict document would be better | 16:21 |
| teknico | thisfred, it's MySQL over PostgreSQL :-( | 16:21 |
| thisfred | you take that back! | 16:21 |
| thisfred | ;) | 16:21 |
| teknico | thisfred, "storing a conflict document"? | 16:22 |
| teknico | how would the user see that? | 16:22 |
| thisfred | but I would like to store a conflict document with all the changes merged in, and have my version win | 16:22 |
| thisfred | teknico: that would be up to the ui | 16:22 |
| thisfred | you just ask couch for the document with ?conflicts=true | 16:22 |
| teknico | thisfred, if I can show the user a summary of the situation with conflict values in evidence, that's so much better :-) | 16:23 |
| thisfred | and it will show you all conflicting versions | 16:23 |
| thisfred | yes | 16:23 |
| thisfred | I agree | 16:23 |
| teknico | thisfred, because you know how much love the user :-) | 16:23 |
| teknico | how much *I love | 16:23 |
| thisfred | but python-couchdb completely ignores this AFAIK | 16:23 |
| teknico | recently I've seen talk of an async couchdb wrapper, what was it called? | 16:23 |
| thisfred | hey me too, I love them even more: I assume they know what they're doing and that they mean what they say ;) | 16:23 |
| thisfred | I don't know if couchdbkit does better, and if that's what you mean | 16:24 |
| teknico | thisfred, they can only do so if you don't hide stuff from them :-P | 16:24 |
| thisfred | teknico: yes | 16:25 |
| teknico | mmm, no, it was Something Completely Different™ | 16:25 |
| thisfred | so what I'd like optimally is: merge the changes to fields that don't conflict, and have the users changes for fields that do conflict win, *but* store the losing values in a conflict doc. then have the ui show the conflicting values | 16:26 |
| thisfred | I don't know if that is possible, or how I would do it | 16:26 |
| teknico | I like it, except for the winning part | 16:27 |
| thisfred | teknico: well, one of the conflicting versions wins. That is couchdb | 16:27 |
| thisfred | teknico: unfortunately you have no control over which one | 16:28 |
| thisfred | or maybe that's good, in case both sets of changes came from my method ;) | 16:28 |
| rtgz | if (local && server && strcmp (local, server) == 0) { mark_as_synchronized } | 16:32 |
| rtgz | local = "", server = "", ... grrr | 16:32 |
| * thisfred rethinks the method | 16:34 | |
| thisfred | perhaps I should have it barf on changes to the same fields | 16:34 |
| thisfred | or store conflicts | 16:34 |
| thisfred | if I can from python-couchdb | 16:34 |
| teknico | thisfred, at least an option to *not* have it apply conflicting changes silently | 16:35 |
| thisfred | teknico: that's for wimps | 16:35 |
| thisfred | :) | 16:35 |
| thisfred | yeah you're right. | 16:35 |
| thisfred | I don't think the function is used all that much, to put everyone's mind at ease. I just had fun writing it ;) | 16:35 |
| teknico | thisfred, then it'll be even more fun fixin^Wchanging it! ;-) | 16:38 |
| * dobey fixes up bugs for doing SRUs | 16:39 | |
| rtgz | dobey, have you got to nautilus or not yet? In case no, then good - I have some additional comments (as always...) | 16:40 |
| dobey | no | 16:40 |
| * rtgz hates that apt-get update erases his own little build of ubuntuone-client-gnome every time... | 16:41 | |
| dobey | facundobatista: ping | 16:44 |
| rtgz | yup, the emblems got 'synchronized' for files immediately because the server hash and local hash matched perfectly when file was dropped into the directory: both were equal to empty string... | 16:45 |
| thisfred | teknico: I'll do this: if the merge of all changes succeeds, store it. if not, strore nothing return conflicting fields, with both values. Rename the method to try_update_fields. | 16:47 |
| thisfred | No more silent anything, and no conflicts possible | 16:47 |
| thisfred | wildly ugly code and function behavior though | 16:48 |
| rtgz | can anybody tell me what 'server_hash' means for directories? | 16:48 |
| teknico | thisfred, that's brilliant, consider yourself hugged ;-) | 16:48 |
| thisfred | teknico: it will mean work on the ui | 16:49 |
| thisfred | so don't hug too soon ;) | 16:49 |
| teknico | the heavy lifting in that ugly code will beautify code elsewhere though :-) | 16:49 |
| thisfred | true | 16:49 |
| dobey | rtgz: it's the hash of the directory content, that the server knows | 16:49 |
| teknico | thisfred, at worst i can just punt like I do now ;-) | 16:49 |
| thisfred | and it's sort of unixy: return nothing in case of success | 16:50 |
| rtgz | dobey, okay, local_hash then?... | 16:50 |
| thisfred | but not very pythonic | 16:50 |
| dobey | rtgz: similar, but local version of it | 16:50 |
| teknico | showing the different values will require effort on the design side though | 16:50 |
| rtgz | dobey, :).. I mean if i put a file into the dir, then hash should be recalculated, I guess | 16:50 |
| dobey | rtgz: empty local means it hasn't been hashed yet, empty server means it hasn't been created on the server yet | 16:50 |
| teknico | thisfred, when did python have something to say about return values? :-) | 16:50 |
| rtgz | dobey, the local hash i mean | 16:50 |
| dobey | rtgz: yes | 16:50 |
| thisfred | teknico: just an extra row of text inputs, with <-> arrows, so you can ajax them around | 16:51 |
| rtgz | dobey, and if it does not then this is a bug report? | 16:51 |
| dobey | rtgz: if it's not rehashing, it's probably not getting the inotify event or something, so yeah, it's a bug in syncdaemon perhaps (or possibly in inotify) | 16:51 |
| dobey | rtgz: this sounds like the "syncdaemon not noticing new files" bug | 16:51 |
| teknico | thisfred, feel free to give advice to the design team, I just do what I'm told here ;-) | 16:52 |
| dobey | rtgz: i've seen a few reports of that nature, but don't know a bug # off hand | 16:52 |
| thisfred | teknico: it's not very pythonic to have a method that does stuff, but if it fails returns something. An exception would be better. Can I return a conflicts dictionary as part of the exception? | 16:52 |
| rtgz | dobey, syncdaemon has hashed the file but did not recalculate the directory info, Ok, will check that once more | 16:52 |
| teknico | thisfred, I think you can add custom attributes to an exception object, let me check | 16:52 |
| dobey | rtgz: ok, that might be the problem then :) | 16:53 |
| aquarius | you can | 16:53 |
| thisfred | word | 16:54 |
| thisfred | that's the way to go then | 16:54 |
| aquarius | class UpdateConflictException(Exception): def __init__(self, brokenness): self.brokenness = brokenness | 16:54 |
| aquarius | and then people can get attributes of the exception when they catch it | 16:54 |
| thisfred | thanks all, for fixing my code! ;) | 16:55 |
| thisfred | aquarius: would you agree that this modified version of update_fields might have a place in d-c? | 16:55 |
| aquarius | yeah, I think it does. It's a useful API. | 16:55 |
| aquarius | what I'm not sure about is: should it be a completely separate way of working? surely every single access should work like this? | 16:56 |
| thisfred | ok, I'll make a branch tonight, after I fix my other broken code ;) | 16:56 |
| thisfred | aquarius: eh yeah, I would use this everywhere on the server. | 16:56 |
| thisfred | aquarius: it might still be useful to have conflicts though: unattended processes can't resolve the conflicts, and it would suck if they could not write to the db | 16:58 |
| thisfred | like sharing-sync | 16:58 |
| aquarius | it still *is* a conflict. | 16:58 |
| thisfred | aquarius: I mean, they would not have a good way to deal with the exception | 16:58 |
| aquarius | it is pretty much never right for you to say "save my changes" if something else has happened in the interim | 16:58 |
| aquarius | you can avoid it by updating the record. | 16:59 |
| thisfred | aquarius: yeah that's what I'm doing now, but in the case the same field was changed, you need to pick a winner | 16:59 |
| thisfred | or store a conflict | 16:59 |
| thisfred | in the case where a user is driving, present the conflict to the ui, and have them picj | 17:00 |
| thisfred | pick | 17:00 |
| aquarius | I...think it's up to the app to pick a winner. | 17:00 |
| thisfred | right | 17:00 |
| aquarius | if it's possible to do unattended, then let the app that writes second do it | 17:00 |
| aquarius | if it's not possible to do unattended, then don't run unattended | 17:00 |
| aquarius | storing conflicts seems to me to not be the right thing to do; we just can't avoid it in a world with replication in it | 17:01 |
| thisfred | aquarius: I would say store conflicts documents on exceptions when unattended | 17:01 |
| aquarius | I'm not convinced | 17:01 |
| thisfred | and then the user/app can resolve them later | 17:01 |
| aquarius | also, can we? | 17:01 |
| thisfred | aquarius: we can, through http if need be | 17:01 |
| aquarius | isn't replication mildly magic? can we deliberately store a conflict? | 17:01 |
| thisfred | hmm, I thought you could | 17:02 |
| thisfred | bulk updates can | 17:02 |
| thisfred | or can't they? | 17:02 |
| thisfred | anyhow | 17:02 |
| thisfred | I will ask for input when I start coding | 17:03 |
| thisfred | now my trunk is broken, because there is no _add_record method anymore | 17:03 |
| thisfred | that's good though | 17:04 |
| CardinalFang | :) | 17:07 |
| dobey | lunch time | 17:19 |
| rtgz_ | dinosaurs?.. | 17:31 |
| Chipaca | teknico: ok, let's do this thing | 17:33 |
| Chipaca | mandel: eh, hola! | 17:33 |
| teknico | Chipaca, it would be best to do it with vds too | 17:34 |
| mandel | Chipaca, hola :D | 17:34 |
| Chipaca | teknico: can you wait up that long? | 17:34 |
| teknico | also, I owe an answer to mandel since yesterday :-) | 17:34 |
| Chipaca | teknico: the planning is so much easier when one of the people that has to do things is away! | 17:34 |
| teknico | Chipaca, yes, I'll be around | 17:34 |
| Chipaca | teknico: ok :) | 17:34 |
| teknico | Chipaca, you're not getting away with that, you know ;-P | 17:35 |
| mandel | Chipaca, I'll entertain him teknico if you need him to stay for a while ;) | 17:35 |
| teknico | mandel, thanks, but I don't really need him to *not* be elsewhere right now ;-) | 17:36 |
| CardinalFang | mandel, hi. attachments branch is merged. | 17:37 |
| mandel | CardinalFang, awesome, as soon as I can I'll add avatars to the contacts, thanks A LOT | 17:38 |
| CardinalFang | mandel, de nada. Tell me if it's not exactly obvious how to use it. | 17:39 |
| mandel | CardinalFang, will ask you, within the limits | 17:40 |
| aquarius | verterok, ping? | 17:40 |
| teknico | mandel, wow, bazaar is erroring out while trying to merge your branch :-/ | 17:56 |
| teknico | mandel, no, wait, PEBKAC | 17:57 |
| teknico | I'm too used to live in the server code :-) | 17:58 |
| mandel | teknico, hehe I've not heard PEBKAC in a long time | 17:58 |
| teknico | mandel, well, in this age of laptops, it reeks of viagra spam ;-) | 17:59 |
| mandel | teknico, you forget watches and university titles... | 18:01 |
| teknico | mandel, yes, I do, what about them? :-) | 18:02 |
| mandel | teknico, they go hand in hand with the viagra spam :P | 18:03 |
| teknico | mandel, no, I mentioned viagra in specific relation to the acronym, think about it ;-) | 18:05 |
| mandel | teknico, agg... you are to graphic for me hehe | 18:05 |
| teknico | mandel, can you please merge forward your branch? | 18:22 |
| teknico | I see unrelated changes in it | 18:22 |
| mandel | teknico, waht do you mean? | 18:24 |
| teknico | mandel, it looks like there have been changes in desktopcouch trunk since you branched it | 18:24 |
| teknico | you should merge the current trunk into your branch | 18:25 |
| teknico | so that its diff only contains you changes | 18:25 |
| mandel | ok, I'll do, that is probably the merge from CardinalFang related to the attachments | 18:25 |
| teknico | or am I missing something? | 18:25 |
| teknico | mandel, yes, I saw those | 18:25 |
| mandel | teknico, I'll update the branch, sorry I forgot to do it, give me a sec | 18:26 |
| teknico | mandel, sure, thanks | 18:26 |
| mandel | teknico, sorted | 18:27 |
| rtgz | dobey, how about adding 'Danger' emblem to u1conflict.* files? | 18:32 |
| dobey | but they aren't dangerous | 18:32 |
| dobey | and that emblem also doesn't make any sense | 18:32 |
| dobey | and it's a separate file | 18:32 |
| dobey | but i'm not sure what we should do in the file manager | 18:32 |
| rtgz | dobey, but they are neither non-synchronized nor synchronizable... | 18:32 |
| rtgz | dobey, right, not dangerous, but calling for attention, of some sort... | 18:33 |
| rtgz | 'Oh no!' ... | 18:33 |
| rtgz | and .. 'Important'? | 18:34 |
| dobey | if they do deserve an emblem, it should probably be some new thing | 18:35 |
| dobey | not one of the broken things already in nautilus that really shouldn't be there anyway | 18:35 |
| Chipaca | what does the nautilus bzr plugin do for conflicts? | 18:35 |
| dobey | what nautilus bzr plugin? | 18:35 |
| rtgz | Chipaca, bzr plugin o_O ? | 18:36 |
| rtgz | not in ubuntu :( | 18:36 |
| Chipaca | verterok: ping :) | 18:37 |
| Chipaca | I think it's part of bzr-gtk | 18:37 |
| Chipaca | http://samba.org/~jelmer/bzr/nautilus-bzr1.png | 18:38 |
| Chipaca | johnlea: ping you too :) | 18:39 |
| rtgz | I guess .u1partial deserves some icon as well | 18:39 |
| teknico | mandel, it looks like we need more discussion to evaluate your branch changes to desktopcouch | 18:40 |
| rtgz | Or at least it does not deserve the default 'sync/unsync' emblems | 18:40 |
| mandel | teknico, ok, let me know | 18:40 |
| dobey | rtgz: .u1partial files don't exist | 18:40 |
| mandel | teknico, I've done my best to reduce the redundancy in contact details and make the tests better.simpler | 18:40 |
| teknico | mandel, yes, that's a marked improvement | 18:41 |
| rtgz | dobey, "I want to believe", yup, never seen them but they are documented on Wiki... | 18:41 |
| teknico | some of my suggestions are not there yet, though ;-) | 18:41 |
| mandel | teknico, dammed, what did I forget! | 18:41 |
| dobey | Chipaca, rtgz: you have to manually copy /usr/share/pyshared/bzrlib/plugins/gtk/nautilus-bzr.py to the nautilus python plug-ins dir | 18:41 |
| teknico | however, I concentrated on the mechanics, while we need more clarity on the api level | 18:41 |
| teknico | that's what we need to focus on now | 18:42 |
| dobey | maybe that should be done in the package, and split to a nautilus-bzr package | 18:42 |
| dobey | (or bzr-nautilus) | 18:42 |
| dobey | rtgz: the wiki is old :) | 18:42 |
| mandel | teknico, sure, let me know :) | 18:42 |
| rtgz | dobey, aaaaaaaaaa | 18:42 |
| Chipaca | dobey: I've got bzr-gtk via "bzr co lp:bzr-gtk" in .bazaar/plugins :) | 18:42 |
| dobey | Chipaca: did you copy the nautilus-bzr.py file over to /usr/lib/nautilus/extensions-2.0/python/ ? | 18:43 |
| Chipaca | dobey: nope (I'm not using the nautilus extension) | 18:43 |
| dobey | Chipaca: that's probably a bad idea, since bzr-gtk isn't only a plug-in :) | 18:43 |
| dobey | or isn't only a bzr plug-in | 18:44 |
| teknico | mandel, I will | 18:44 |
| teknico | mandel, on a related subject, when can I start playing with macaco itself? :-) | 18:44 |
| Chipaca | dobey: I obey verterok | 18:44 |
| dobey | but anyway, it looks like you have to manually copy the nautilus extension over | 18:44 |
| dobey | verterok: bad verterok :) | 18:44 |
| dobey | of course it works, but probably not as useful as could be | 18:44 |
| dobey | Chipaca: do you actually use the g* commands in bzr? | 18:45 |
| rtgz | dobey, okay, don't see any conflict emblems - bzr-ignored, bzr-controlled, bzr-modified, bzr-added, bzr-removed... | 18:45 |
| mandel | teknico, well, I'm working on the groups support which I want to have for next week, then you are more than welcome | 18:45 |
| Chipaca | dobey: yes, of course | 18:45 |
| mandel | teknico, and avatars since Chad added attachments support | 18:45 |
| teknico | mandel, oh right, that the other thing I saw you discussing | 18:45 |
| dobey | Chipaca: and the fact that they hold bzr locks doesn't bother the heck out of you? :) | 18:45 |
| teknico | what's with the dicts for groups/categories? I did not quite get that | 18:45 |
| Chipaca | dobey: not in the least, no | 18:46 |
| Chipaca | dobey: in fact I didn't know they did | 18:46 |
| sandsmark | are there any plans to release the source code for the server side part? :-) | 18:47 |
| rtgz | dobey, yeah, right... bzr-conflict. The emblem exists, but it is not referenced from the script. Nice. | 18:47 |
| dobey | Chipaca: yep, they hold the lock on the branch. so you can't do bzr gdiff & and then do bzr st in the same branch :-/ | 18:47 |
| dobey | sandsmark: no. but several pieces we use in the server are already open source :) | 18:48 |
| rtgz | dobey, but it does need some kind of emblem, It took a while to understand that my folder_with_long_name.u1conflict looks much different from folder_with_long_name | 18:48 |
| mandel | teknico, I was just asking how would the group sbe represented in the document | 18:48 |
| sandsmark | dobey: heh, ok | 18:48 |
| * sandsmark already has a server :-P | 18:48 | |
| sandsmark | (as in the hardware and rackspace :-) | 18:48 |
| mandel | teknico, I believe aquarius and I were both thinking about doing it this way: http://pastebin.com/dd904c0a | 18:48 |
| teknico | mandel, mmm, right, the MergeableList thing | 18:50 |
| mandel | teknico, I initially found it quite confusing since if you have a list of lists desktopcouch will convert that in a MergeableList of MergeableLists, I don't mind the first, but the second mergeable list I find a bit over the top | 18:51 |
| nperry | Hello guys, Hope somone can help me. | 18:52 |
| teknico | mandel, I don't see why two levels...? | 18:52 |
| nperry | I'm helping doing bugs at the moment and we seem to be having a lot of ubuntuone bugs in LP - What would you recommend to be enough information for us to triage the bug. | 18:53 |
| dobey | hi nperry | 18:54 |
| nperry | Hello dobey :) | 18:54 |
| dobey | nperry: they can be hard to triage... most of them are likely dups of bugs that I am about to push SRUs for :) | 18:54 |
| teknico | mandel, fyi, evolution keeps categories in one comma-separated text field | 18:55 |
| mandel | teknico, the record API will convert the following [["Rock", "AC/DC"]["Friends", "Rugby"]] in two dicts. aquarius recommended to stick with a list of lists because he must have some friend in AC/DC (that is allow any char in the name of the group) | 18:55 |
| jblount | nperry: https://wiki.ubuntu.com/UbuntuOne#Bug%20Triage has some details | 18:55 |
| mandel | teknico, although rodrigo_ and I where more up for the char separated idea | 18:55 |
| teknico | that's one of the sticky points in the move to attribute names :-/ | 18:55 |
| aquarius | mandel, you've gotta do nested mergeablelists. Weird, but true. | 18:56 |
| teknico | anyway, back the point, I don't see the meaning | 18:56 |
| teknico | aquarius, care to explain what that means? | 18:56 |
| teknico | "that" = "[["Rock", "AC/DC"]["Friends", "Rugby"]]" | 18:56 |
| dobey | nperry: if you have any questions or concerns about specific bugs, please ping and ask us though. hopefully I can plow through some of the bugs once I get these SRU builds finished. | 18:57 |
| aquarius | if you were setting up a list of categories that a contact was in, and you want to have nested categories, you'd instinctively think of storing it like this: ["Sports Club/Tennis", "Family"] | 18:58 |
| aquarius | if, for example, the contact was my brother, and he's also in my tennis group | 18:58 |
| rtgz | dobey, okay, is "Shared with Me" folder supposed to have correct emblems or that is something that is low priority? | 18:58 |
| aquarius | and I want to have Sports Club/Football for people in my football group | 18:58 |
| aquarius | but I also want to know everyone who's in the sports club, whether tennis or football, yes? | 18:58 |
| dobey | rtgz: not sure what you mean | 18:58 |
| aquarius | teknico, but...I don't like using / as a separator, since it screws you up if you want a group named "AC/DC" | 18:59 |
| Chipaca | dobey: rtgz: wasn't there a wiki page somewhere to help with u1 bug triage? | 18:59 |
| rtgz | dobey, currently SD is being queried for "/home/rtg/Ubuntu One/Shared With Me/Sharename from Shareuser/file", but it has no info about that path | 18:59 |
| mandel | aquarius: unless the separator is an even number of chars "//" | 18:59 |
| aquarius | so, store a list of categories that a person is in as a set of nested lists: [ "Italians", "Twisted users", [ "Canonical", "Ubuntu One"] ] (for my record of you, for example :)) | 19:00 |
| aquarius | mandel, why bother to write some complicated parser that cares about splitting up a string? Just store it as a list; that's what lists are for. | 19:00 |
| * rtgz is not a native speaker for English and "triage" looks somehow like triple age, or tripod... | 19:00 | |
| dobey | Chipaca: maybe. i don't know. i don't traverse the wiki much | 19:00 |
| nperry | dobey & jblount : Thanks ever so much! | 19:00 |
| dobey | rtgz: oh, because nautilus isn't giving us the expanded path apparently :( | 19:01 |
| rtgz | Chipaca, do you mean the script that was used to detect issues on the client side? | 19:01 |
| Chipaca | rtgz: yes | 19:01 |
| jblount | nperry: Thank you! I love it when people triage bugs. | 19:01 |
| mandel | aquarius: I'm just being annoying ;) (dejabu from UDS, reception hall + coffee + arguing about groups) | 19:01 |
| rtgz | dobey, yes, it does not, therefore additional link resolution is required | 19:01 |
| rtgz | nperry, something like this https://wiki.ubuntu.com/RomanYepishev/UbuntuOne/Diagnostics might help | 19:02 |
| * rtgz really needs to find out what "triage" means... | 19:02 | |
| dobey | the process of sorting victims, as of a battle or disaster, to determine medical priority in order to increase the number of survivors. | 19:04 |
| rtgz | dobey, yes, the process of sorting, don't see how a script helps to sort the victims... | 19:05 |
| urbanape | rtgz: incidentally, triage is of French origin | 19:06 |
| teknico | back, sorry | 19:06 |
| dobey | mandel: i like arguing about groups! :) | 19:06 |
| teknico | aquarius, I must have missed the memo about *nested* categories :-/ | 19:07 |
| dobey | rtgz: well, victims == bugtasks. some are more important than others, and some are faster to fix than others. | 19:07 |
| teknico | even given that we want them (and I'm not sure about it) | 19:07 |
| mandel | dobey, I remember hehe we just miss rodrigo_ | 19:08 |
| dobey | rtgz: it's sometimes hard for a script to determine those factors, but it's easy to determine if two issues in the tracker are due to the same problem | 19:08 |
| aquarius | teknico, yeah, it seems reasonable to do them, since if we don't, people will just try and emulate them by naming their groups "Friends/People I have not slept with" or whatever | 19:08 |
| teknico | how do we reconcile them with evolution not supporting them? | 19:08 |
| * aquarius waves hands about in the air vaguely | 19:08 | |
| teknico | ehi, you really thought this through, didn't you? ;-D | 19:09 |
| aquarius | I have thoughts of a few ways: obvious way is to display group memberships on a contact in Evo but don't make it editable. | 19:09 |
| dobey | evolution does groups | 19:09 |
| dobey | in the exact same way that outlook does groups :) | 19:09 |
| aquarius | Two better ways: 1. actually model groups as a separate record, which is useful if you want to share a whole group with someone or share to a group, etc | 19:09 |
| teknico | evolution does *categories*, and flat at that | 19:10 |
| aquarius | 2. make evo support groups. | 19:10 |
| aquarius | 2 is best but hardest. :) | 19:10 |
| dobey | it's not the best | 19:10 |
| dobey | but i have a certain amount of want for replacing evolution with purpose-built applications :) | 19:10 |
| mandel | dobye, which way? | 19:10 |
| teknico | btw, I like "categories" more than "groups", because "groups" sound more exclusive | 19:11 |
| aquarius | dobey, that's, like, the long-term goal here, I admit it :) | 19:11 |
| mandel | dobye, I mean does evo do groups | 19:11 |
| dobey | mandel: categories | 19:11 |
| mandel | dobye, aquarius, am I included on that (purpose-built applications) ;) | 19:11 |
| aquarius | teknico, but people think of things as groups. "I'm going out tonight with my theatre group", not "I'm going out tonight with the people in my 'theatre' addressbook category" | 19:11 |
| teknico | as in, a contact only "belonging" to a group | 19:11 |
| aquarius | mandel, hell yes :P | 19:11 |
| mandel | dobye, ahh well that I knew ;) | 19:12 |
| dobey | teknico: group is just another name for the same result | 19:12 |
| dobey | teknico: which is that you are categorizing your contacts in some way | 19:12 |
| teknico | I'm focusing on the ability of having the same contact in more than one group/category/whatever | 19:13 |
| teknico | which luckily is present in evolution | 19:13 |
| mandel | teknico, but that is easy right? you can have a contact in more than one category | 19:14 |
| teknico | and useful at least to me, if not to the general "people" | 19:14 |
| aquarius | teknico, that's why it's stored as a list of lists; each "category" is a list, and the list of categories a contact is in is itself a list. | 19:16 |
| teknico | I'm trying to make up my mind whether nested groups (ok, ok) are generally useful | 19:16 |
| teknico | I can see the usefulness in a blog or cms | 19:16 |
| mandel | teknico, you might be able to create a view that returns all the groups and with those you generate the categories following some kind of rule Friends-Rugby for subgroup friends, and finding such a categories implies the existence of Friends | 19:16 |
| aquarius | we had half-a-dozen use-cases for them at UDS. johnlea, ping abotu that/ | 19:16 |
| teknico | for contacts, it somewhat smells of geeky overkill :-) | 19:17 |
| teknico | oh, ok, is it recorded somewhere? | 19:17 |
| mandel | teknico, you would be amazed on how people organize their contacts with groups | 19:17 |
| aquarius | teknico, it doesn't have to be used, much. But think of a different display mechanism for your addressbook; not a list of contacts like in Evo, but something more like Nautilus, where each person gets a little icon | 19:18 |
| aquarius | teknico, which gives you a new way of interacting with contacts; drag a contact onto a file to share that file with that contact, etc | 19:18 |
| verterok | Chipaca: pong | 19:18 |
| aquarius | groups, in that example, would be like folders | 19:18 |
| teknico | with hardlinks, hopefully ;-) | 19:19 |
| aquarius | if you drag one folder into another folder you can either (a) support that [and that's nested groups], or (b) pop up a dialog saying "you can't put one group inside another, get stuffed", which is actively user-hostile for no reason :) | 19:19 |
| teknico | implementation simplicity *is* reason, whether good or bad :-) | 19:20 |
| mandel | teknico, aquarius, which is the new UI I have been working on and rodrigo_ | 19:20 |
| teknico | so, I guess all this is being reflected in mockups somewhere? or at least written down? | 19:21 |
| mandel | teknico, aquarius, I'm more worried on how do you represent the storing of a group. Do you store the Group and update all the contacts or assuming a group is not stored unless there are contacts in it? I can think of people filling bugs saying that empty groups disappear from the UI | 19:21 |
| mandel | teknico, first mockup I did is in lp:macaco, you can give it a go, but has no groups | 19:22 |
| aquarius | that's why I also mentioned Alternative Option Number 1, which is that groups are a separate record. | 19:22 |
| rtgz | mandel, I would file such bug, for sure :) | 19:22 |
| mandel | rtgs, dammed I knew there would be at least one.... I hate u ;) | 19:23 |
| teknico | mandel, don't hate the user, you end up hating yourself ;-) | 19:24 |
| mandel | teknico, is that in the zen of programming? hehe | 19:25 |
| Chipaca | verterok: never mind, was re bzr nautilus thing | 19:26 |
| mandel | aquarius, anyway,getting back to it, so if there are no contacts in a group, there is no group? that is weird 'cause a would expect the same behavior as with an empty dir | 19:26 |
| aquarius | mandel, then groups have to be a separate record. | 19:26 |
| mandel | aquarius, if you want to support them as a dir I think it is the only sane way to do it, and let evo ignore them... | 19:27 |
| dobey | wouldn't a group with no contacts just be an empty list? | 19:28 |
| teknico | sigh, I liked evolution's simple approach, even if a bit "dirty" | 19:28 |
| mandel | dobey, no, since the list is in the record of the contact. If not contact points to the group, there is no group | 19:28 |
| mandel | dobey, kinda like if a tree falls in a forest and no one... blah blah | 19:29 |
| verterok | Chipaca: oh, ok...I'm a qt guy | 19:29 |
| aquarius | dobey, if groups are stored as an attribute on a contact, you can't have an empty group 'cos there's nowhere to store its existence | 19:29 |
| Chipaca | verterok: ah | 19:30 |
| dobey | mandel: i thought i understood it would be a two-way association. creating a group creates a new record that is a list of contacts, and those contacts all have a list of which groups they are in | 19:30 |
| Chipaca | verterok: does that mean I have to hate you? | 19:30 |
| verterok | Chipaca: at all :) | 19:30 |
| Chipaca | verterok: phew | 19:30 |
| verterok | Chipaca: soon qt will be everywere ;) | 19:30 |
| dobey | aquarius: it probably needs to be a separate record anyway, since there may be metadata to set on that "group" | 19:31 |
| aquarius | dobey, that's why I don't like groups as a separate record, because you have to keep the two in sync | 19:31 |
| mandel | dobey, like a double linked list? | 19:31 |
| dobey | aquarius: for example, in evo, you can specify an icon for a category | 19:31 |
| * urbanape resists falling into discussions of taxonomies | 19:31 | |
| aquarius | dobey, yeah; you want to be able to do things like share a group with someone. I wrote up a load of stuff about this months ago, thinking about it | 19:31 |
| dobey | aquarius: well, the sync bit should be trivial, since the lists should just contain the UIDs or whatever, no? :) | 19:32 |
| aquarius | urbanape, yeah, this is a KISS thing; I'm not modelling really complex stuff :) | 19:32 |
| mandel | aquarius, yes, but then subdir are not that nice to do | 19:32 |
| aquarius | dobey, it's not *hard*, I just don't like changes where you have to write the same thing twice in two places. | 19:32 |
| urbanape | aquarius: even simple taxonomies have to answer hard questions | 19:33 |
| dobey | aquarius: eh, twice is nothing | 19:33 |
| urbanape | it's 100% more than once. | 19:33 |
| dobey | aquarius: you haven't even considered that we might need to keep such things in sync across multiple social networking sites too :) | 19:33 |
| mandel | dobey, but with a sub-group of a sub-group etc.. pain in the ass | 19:33 |
| aquarius | my point exactly :) | 19:33 |
| dobey | mandel: sub-groups are the slippery slope down the spiral | 19:33 |
| aquarius | dobey, I have considered it, and it's irritating but true. That sort of sync can be done asynchronously, though. | 19:34 |
| aquarius | subgroups are easy enough; as you said, we're just storing a list of IDs. | 19:34 |
| dobey | well, desktopcouch doesn't need to care about facebook/etc... | 19:34 |
| dobey | that's more the realm of central-services :) | 19:34 |
| aquarius | no, exactly. | 19:34 |
| dobey | yes, in the model sub-groups is easy | 19:35 |
| dobey | but they make the UI 10x worse | 19:35 |
| mandel | aquarius, they are easy to represent (subgroups), yes, but you will have be very lazy when implementing groups in the apps making it very chatty with desktopcouch and I just like chatty in IRC... | 19:35 |
| aquarius | mandel, that's why there's a contacts abstraction layer amirite? so applications don't have to think about that. :) | 19:36 |
| aquarius | this is what bulk updates are for, incidentally. | 19:36 |
| mandel | aquarius, dammed, I got bitten in the ass by my one stuff, good answer though ;) | 19:36 |
| teknico | yes, the UI is going to be a bear, unless... | 19:38 |
| teknico | ...unless we use trees, and I hope those are not going to cost us multiple associations | 19:39 |
| teknico | hence hardlinks :-) | 19:39 |
| aquarius | why will the UI be hard? | 19:39 |
| dobey | how do you avoid circular groups? | 19:39 |
| mandel | dobey, a group should have a unique path | 19:40 |
| dobey | yes | 19:40 |
| dobey | but if i have group id A and group id B, and i say B is a sub-group of A, can i also not say A is a subgroup of B? | 19:40 |
| mandel | dobey, so it is easy to find the error, | 19:40 |
| aquarius | dobey, same way you do it with folders; you prevent that explicitly. | 19:41 |
| dobey | mandel: the groups themselves would have their paths be /A and /B no? | 19:41 |
| mandel | dobey, aquarius, can't we use the path to the group as its id? there is nothing technically avoiding that, right? | 19:42 |
| aquarius | mandel, you can't do that, because if you rename a group then you have to edit every contact in it, because contacts link to their group by ID | 19:42 |
| aquarius | that's doable, but daft :) | 19:42 |
| mandel | id of group A "_id":A ofsub group B "_id":"AB" or something of the kind | 19:43 |
| mandel | aquarius, are we in the page of using a diff record for groups, right? so why letting the contact know in which group he is | 19:44 |
| mandel | Contact: that is external to him, someone place me there, ok, do I care? can I do something about it? | 19:44 |
| aquarius | it's possible to just have groups know about people and not have people know about groups. I'm fine with that, myself. | 19:44 |
| * dobey would be happy just not having sub-groups | 19:45 | |
| dobey | they increase complexity for little/no gain | 19:45 |
| mandel | aquarius, two way links are harder to deal with and in this case do not add anything to the user | 19:45 |
| aquarius | they don't increase complexity much. | 19:45 |
| statik | who what? are we having groups as objects rather than just tags on contacts? | 19:46 |
| mandel | I agree there is not more complexity | 19:46 |
| aquarius | and people will just fake them if we don't provide them: a group called "Canonical/Ubuntu One" with all you guys in it. | 19:46 |
| teknico | I agree with dobey, not sure about this tradeoff | 19:46 |
| aquarius | statik, that's the conclusion we're coming to. | 19:46 |
| mandel | teknico, initially file systems just had one level, and know.... | 19:46 |
| dobey | well i don't think groups are the right way to deal with managerial hierarchy :) | 19:47 |
| teknico | mandel, I have 300k files from packages only, on this machines | 19:47 |
| teknico | that's about three orders of magnitude more :-) | 19:48 |
| teknico | than contacts | 19:48 |
| mandel | teknico, what I mean is that most normal people cannot deal with a huge amount of data | 19:48 |
| statik | aquarius, can you catch me up on why having groups as first class objects instead of just using a tagging system? | 19:48 |
| mandel | average people can only remember 10 items in short memory | 19:48 |
| aquarius | dobey, I'm not thinking of it being done that way for management. I have a legitimate use case for wanting to see (a) who I know at Canonical and (b) who I know in the Ubuntu One team, and I shouldn't have to explicitly put someone in both groups | 19:49 |
| teknico | sure, groups are useful, but I'not sure *nested* groups warrant the added complexity | 19:49 |
| aquarius | statik, big problem with tags: you can't have an empty group. | 19:49 |
| urbanape | boolean searches against single groups accomplishes the same thing | 19:49 |
| urbanape | Canonical AND UbuntuOne | 19:49 |
| urbanape | Community AND UbuntuOne | 19:49 |
| aquarius | urbanape, you join, I have to explicitly put you in both groups. That's stupid. The "Canonical" grouping is quite clearly a group of groups, not a group in its own right. | 19:49 |
| mandel | urbanape, you get back to the problem of empty groups | 19:50 |
| aquarius | statik, second issue (which is smaller): you can't share a group if it's not an independent entity | 19:50 |
| mandel | urbanape, people will complain a lot if the groups disappear because there is no tag about it | 19:51 |
| urbanape | aquarius: and do you duplicate that taxonomy to put rtgz somewhere? He's not a Canonical employee (unless I missed a note somewhere) | 19:51 |
| urbanape | but he's a contributor | 19:51 |
| urbanape | mandel: not if it's termed tags | 19:51 |
| mandel | contributors are lame... hehe (including me) | 19:51 |
| urbanape | no one gripes when they remove the last of their tags off a photo on Flickr | 19:51 |
| aquarius | urbanape, yeah, that's the issue with a hierarchy. That's not modellable visually in any kind of sane way, though. | 19:52 |
| urbanape | tags are extremely easy to apply and remote | 19:52 |
| urbanape | remove | 19:52 |
| mandel | urbanape, but they do if you are using a dir metaphor | 19:52 |
| urbanape | groups by definition are less ephemeral and are more boxey. | 19:52 |
| aquarius | there's no reason why it can't be presented as tags in the UI, if you like that metaphor. | 19:52 |
| mandel | wait, I empty my dir of movies and the dir is not more there? WTF? | 19:52 |
| urbanape | people aren't movies | 19:52 |
| teknico | I don't think the filesystem metaphor will take us far | 19:53 |
| urbanape | damnit, I was hoping to resist getting invovled. I should just go hack bindwood. | 19:53 |
| aquarius | empty things disappearing breaks the user experience. I move home and I drag my previous flatmates out of the "Flatmates" group, before dragging the new people into the "Flatmates" group, and...pow, the Flatmates group disappears. | 19:53 |
| mandel | urbanape, the problem is the choice of metaphor, where you can work with contacts as you do in a file system | 19:53 |
| teknico | containment and exclusivity are tough to fight | 19:53 |
| aquarius | so I'm not able to drag the new ones in. | 19:53 |
| aquarius | It's also not completely clear how you *create* a group, if we're using a visual metaphor like Nautilus. | 19:54 |
| aquarius | (and empty groups can't exist) | 19:54 |
| mandel | right click, new group => pow, not there is not people in it I have to remove it | 19:55 |
| aquarius | if the underlying implementation is groups-are-independent-entities it can be presented in UI as groups or as tags. If the underlying implementation is groups-are-tags-on-contacts then you can *only* present the visual metaphor as tagging, not as a folder/file hierarchy. | 19:55 |
| aquarius | statik, that's my summary, coupled with a(n attempted) rebuttal of urbanape's points | 19:56 |
| statik | this is very interesting | 19:56 |
| dobey | hmm | 19:56 |
| statik | i've just been playing with groups in google contacts and the snow leopard address book | 19:57 |
| dobey | i do think you've oversimplified that case a bit though | 19:57 |
| statik | i don't see a problem with having an index of tags, so that you have something to keep the empty group alive, and maybe a couple of special virtual things like "contacts which are not tagged with any group" | 19:58 |
| aquarius | that's a horrible, horrible bodge. | 19:58 |
| aquarius | because then if you want "the list of groups" you have to look in two places | 19:59 |
| statik | the code would, yeah | 19:59 |
| aquarius | this whole discussion boils down to, essentially, two questions: can a group with no members exist, and can a group contain groups as well as people? | 20:00 |
| aquarius | we need firm answers on those, because those answers dictate the model. | 20:00 |
| mandel | aqurius, well, with a view you could query all docs with a categories field and you can create a special doc with all the empty groups in. When calling the view you get all groups easily | 20:01 |
| aquarius | I think the answers are yes, and yes, which basically means that the model needs to maintain a group as a separate entity from a person, or have a load of strange work-around bodges. | 20:01 |
| aquarius | if you think the answers are no and no, then tags on a contact is a fine way of modelling them | 20:01 |
| statik | my gut answer is yes a group with no members could exist (and we'd probably want to have a couple special groups to start with), and no to storing groups within other groups | 20:01 |
| statik | although UI niceness to make it easy to perform actions on groups of people selected by combining tags would be good | 20:02 |
| dobey | that's pretty much how i feel about that too | 20:03 |
| aquarius | google contacts doesn't allow groups within groups as far as I can tell when I checked this a while back | 20:03 |
| * aquarius checks again | 20:03 | |
| statik | yeah i just confirmed that | 20:03 |
| urbanape | well, if we're tying ourselves to an existing implementation, then forget anything I've suggested. It's useless to go down the ad-hoc tagging route, if we have to support arbitarily nestable hierarchies due to one client. | 20:03 |
| Howard_Kindig_ | Does anyone know how to delete (unsubscribe) from a folder in Ubuntu One? (I accepted a share from someone else, and I now want to delete that folder from my account...but I don't see any way to do this...) | 20:03 |
| dobey | urbanape: evolution doesn't work that way | 20:03 |
| statik | same with OS X Address book, no groups within groups | 20:03 |
| dobey | statik: and facebook as well | 20:04 |
| aquarius | urbanape, nah, we build what we think is best. If some client supports a more complex and rich taxonomy than we do, tough; that's a problem to be solved by that client's integration with the addressbook. this is what application_annotations is for. | 20:04 |
| statik | Howard_Kindig_, I think you can go to the web UI, select the folder and then reject the share. I will check now | 20:04 |
| urbanape | then I'd vote no/no. Lightweight tags that are ephemeral but are super low cost to create. | 20:05 |
| aquarius | statik, third reason to have groups as a separate entity; metadata for a group (Evo allows you to associate a picture with a category of contacts, for example) | 20:05 |
| mandel | doing the lowest denominator is not a good idea usually... | 20:05 |
| urbanape | deep hierarchies can be made with equivalent boolean searching. | 20:05 |
| aquarius | mandel, true, but if we try and make our system capable of modelling everything else that anyone has ever thought of, we end up in pain. Not gonna do that. | 20:05 |
| statik | tags feel more like how the world works, taxonomies seem doomed from the very beginning | 20:06 |
| aquarius | urbanape, I'm not totally wedded to the idea of nested groups. I am totally wedded to the idea of empty groups being able to exist. | 20:06 |
| dobey | statik: well, they do contain the word 'tax" | 20:06 |
| mandel | if I have the right to vote, I would go for diff records or I implement them in macaco and we see what people think (if they use my code ofcourse) | 20:06 |
| mandel | we can use my project as a playground area :P | 20:06 |
| urbanape | i agree with statik. I don't think there's much value in a tangible, empty group | 20:06 |
| statik | and i think we can do metadata on a group and empty groups by doing strange work around bodges in the implementation to track what tags we've seen | 20:06 |
| urbanape | not when tagging is so inexpensive. | 20:07 |
| aquarius | urbanape, see example above about dragging "flatmates" out and then new flatmates into your "flatmates" category. | 20:07 |
| statik | i have a real world use case for an empty tag group, that i implemented on launchpad a while back (but never landed) | 20:07 |
| rtgz | anybody has anything against realpath() call? | 20:07 |
| statik | it was a search for all bugs that did not have any tags | 20:07 |
| urbanape | aquarius: see previous comment: If we're tying ourselves to an implementation then I retract. You said we weren't tied to an implementation. | 20:07 |
| statik | so it showed up as a special hardcoded thing in the tag listing, and it felt pretty natural to use | 20:07 |
| dobey | rtgz: for the Shared with Me symlink? | 20:07 |
| rtgz | dobey, yup | 20:08 |
| urbanape | presenting them as folders is tied to an implementation, as far as I'm concerned. | 20:08 |
| rtgz | dobey, I don't like the idea to parse for 'Shared With Me'... | 20:08 |
| dobey | rtgz: i don't recall exactly where we're getting that path from, but if it's from a NautilusFileInfo, then i think nautilus should be doing it, and giving us the real path | 20:08 |
| dobey | rtgz: actually, i don't know why nautilus wouldn't be doing that already | 20:08 |
| aquarius | urbanape, we're not *tied* to it. However, I like the idea of being able to present them as folders, because it's good UI, and doing it your way flat rules that out. So you're explicitly *excluding* an implementation, and I don't think that the benefit we derive is worth it. | 20:08 |
| mandel | statik, how did you implemented removing an empty group/tag? | 20:09 |
| aquarius | urbanape, from a UI perspective, it can still be presented as lightweight tagging if we want | 20:09 |
| rtgz | dobey, NautilusFileInfo returns info as seen by nautilus, and when it dives into the directory it reports about it as a proper dir :( | 20:09 |
| statik | hey jblount, Howard_Kindig_ was asking about how to reject a share after it's been accepted and I can't figure it out. where is this in the web UI? | 20:09 |
| dobey | rtgz: sounds like a bug in nautilus | 20:09 |
| rtgz | dobey, I have checked available methods and members on NautilusFileInfo and it looks like that does not give enough info... | 20:09 |
| Chipaca | verterok: ping | 20:09 |
| * rtgz thinks that #nautilus is waiting for him... again... | 20:10 | |
| jblount | statik: I don't think there is a way to do this, am I wrong? | 20:10 |
| statik | mandel: for this one, it was a hard coded tag that couldn't be deleted. what i'm imagining for other user created tags is that you have a view that shows all the tags and can directly delete it. | 20:10 |
| jblount | statik: That is other than using the command line client thingie | 20:11 |
| statik | jblount, i don't know. sounds like something that we definitely should have! | 20:11 |
| urbanape | aquarius: I think the question boils down to: are they tags (metadata on contacts) or are they bags, into which contacts (or representatives of contacts) can be placed? | 20:11 |
| urbanape | I don't think you're going to find a model/representation that satisifies both equally well | 20:11 |
| statik | xactly | 20:11 |
| urbanape | because they mean different things | 20:11 |
| jblount | urbanape: Can I say "get rid of this folder" to a folder shared with me in the web ui? I have no idea how. | 20:11 |
| Howard_Kindig_ | I concur jblount & statik...as a user, right now I'm skunked...no way to delete a share that I've accepted..... | 20:12 |
| aquarius | urbanape, statik, I disagree. If you model a group as a separate entity, then you can present it as metadata on contacts in the UI. | 20:12 |
| urbanape | tags, a la flickr are not arbitrary folders making a hierarchy, though they can be browsed as a collection. However, once the last tag is gone, there is no tag | 20:12 |
| urbanape | jblount: I don't think so yet. | 20:12 |
| jblount | statik: ^^ :( | 20:12 |
| aquarius | I'm basically OK with the idea of not allowing nested tags. | 20:12 |
| urbanape | you can rescind shares to other people | 20:12 |
| urbanape | but you can't drop a share that you've accepted yet. | 20:13 |
| statik | we could make tags sticky though, so they don't disappear when the refcount goes to zero | 20:13 |
| urbanape | statik: bleah, then you've still got a "thing" | 20:13 |
| aquarius | not without making them a separate entity | 20:13 |
| Howard_Kindig_ | Yes--you can rescind the share if you're the owner...I'm the *recipient* of the share...(I accepted the share) and now I want to dump it...but no way to do so it seems. | 20:13 |
| dobey | statik, Howard_Kindig_: i think there is an option to pass to u1sdtool to remove a share you've accepted | 20:13 |
| urbanape | Howard_Kindig_: Yes, I just agreed to that. | 20:13 |
| statik | we gotta fix this for Howard_Kindig_, this is terrible | 20:13 |
| dobey | but i don't recall if that's totally true | 20:13 |
| Howard_Kindig_ | I have a knack for finding bugs...it's a gift! :) | 20:14 |
| mandel | has anyone read this about tag hierarchies: http://heymann.stanford.edu/taghierarchy.html | 20:14 |
| aquarius | dobey, it is | 20:14 |
| urbanape | Howard_Kindig_: I think there's a bug filed on that. Lemme look | 20:14 |
| aquarius | Howard_Kindig_, you can reject a share from the command line (sorry it doesn't seem to be available from the web or desktop interfaces!) | 20:15 |
| aquarius | Howard_Kindig_, would you like me to talk you through that? | 20:15 |
| Howard_Kindig_ | do you have the command? | 20:15 |
| Howard_Kindig_ | Sure...walk thru would be great | 20:15 |
| statik | Howard_Kindig_, this is totally something we need in the webUI, but to fix your problem today you can use u1sdtool --list-shares, get the shareID, then use u1sdtool --reject-share=SHAREID | 20:15 |
| aquarius | "u1sdtool --list-shares" will show all the things that are shared with yo | 20:15 |
| urbanape | Howard_Kindig_: https://bugs.edge.launchpad.net/~urbanape | 20:15 |
| urbanape | her | 20:15 |
| urbanape | er.. | 20:16 |
| urbanape | https://bugs.edge.launchpad.net/ubuntuone-servers/+bug/354174 | 20:16 |
| urbanape | rather. | 20:16 |
| ubottu | Ubuntu bug 354174 in ubuntuone-servers "Rejecting or "unaccepting" shares in the webui" [High,Triaged] | 20:16 |
| urbanape | you can mark that as "Affects me too" | 20:16 |
| aquarius | Howard_Kindig_, the id will look like "6984d386-68eb-4075-858b-bb3453481da" | 20:16 |
| Howard_Kindig_ | hmmm...ulsdtool command not found... | 20:16 |
| rtgz | btw, just in order not to forget, it seems that removing the share does not remove the folder from the "other" pc. | 20:16 |
| Howard_Kindig_ | do I have to be in a specific director? | 20:16 |
| aquarius | u1sdtool (u, digit 1, sdtool) | 20:16 |
| Howard_Kindig_ | ah... | 20:17 |
| aquarius | it's the Ubuntu One (1) Sync Daemon tool :-) | 20:17 |
| aquarius | Howard_Kindig_, and once you've rejected that share, u1sdtool --list-shares will show that share as "accepted=False" | 20:18 |
| statik | mandel, i've not read that paper before thanks for the link. I'm thinking of something sort of like BeFS style live queries against attributes, where you can navigate by building a query rather than having a pre-built taxonomy | 20:19 |
| aquarius | yeah, I think that'll be fine to deal with the "do we need nested groups" question | 20:19 |
| Howard_Kindig_ | u1sdtool --list-shares now showing "No shares" as a result... | 20:19 |
| Howard_Kindig_ | So...good on the web, but that folder still is present on my desktop...(which isn't as much of an issue...I can delete that (I hope) from the command line? | 20:20 |
| aquarius | Howard_Kindig_, excellent; that should do it for you. It might take the web UI a little while to update to reflect that change. | 20:20 |
| mandel | statik, that is something I was thinking to, but you surly can express it better than I do | 20:20 |
| Howard_Kindig_ | Just did a refresh on the web and the change was reflected... | 20:20 |
| Howard_Kindig_ | Will it eventually delete the no longer accepted share on my desktop? | 20:21 |
| Howard_Kindig_ | (My Ubuntu One Folder)? | 20:21 |
| Howard_Kindig_ | Or will I need to deleted that as root? | 20:21 |
| statik | verterok, do you know if we reject a share does the syncdaemon delete that share from the laptop, or does it have to be manually deleted? | 20:21 |
| aquarius | Howard_Kindig_, that...I'm not sure about, I'll be honest. verterok? if a previously-accepted share is rejected with u1sdtool, does chicharra delete the share folder? | 20:22 |
| aquarius | ha! | 20:22 |
| statik | we are in sync! | 20:22 |
| verterok | statik: the data isn't deleted | 20:22 |
| verterok | Howard_Kindig_, aquarius ^ | 20:23 |
| statik | verterok, thanks! | 20:23 |
| verterok | statik, aquarius: we basically delete all traces of the share and it contents from the metadata | 20:23 |
| verterok | so, local_rescan don't find it in the next run | 20:23 |
| statik | aquarius, so i think i'm ok with groups disappearing when the last member is removed because we can Fake It in the User Interface to have a couple of hardcoded groups as breadcrumbs to let people know they can use groups. | 20:24 |
| statik | i don't know the answer to your point about metadata applied to a group though... | 20:24 |
| aquarius | statik, I am way not keen on that. Example from above about a "flatmates" group, in a Nautilus-style UI (which is currently what we're angling towards), and also on metadata associated with a group. | 20:25 |
| Howard_Kindig_ | Ok...so I've killed it on this machine now from the command line as root (since the share was not accessible to be deleted via my user account). BUT--I assume I'm going to now need to also delete that share from all the other computers I have on my Ubuntu One account manually.... | 20:25 |
| mandel | statik, John and I though about it, what about being able to give contact data to a group or other details | 20:25 |
| Howard_Kindig_ | Thanks guys...appreciate the help! | 20:25 |
| Howard_Kindig_ | :) | 20:25 |
| statik | Howard_Kindig_, sorry about the rough edges, thanks for your patience | 20:25 |
| aquarius | Howard_Kindig_, no problem. Sorry this isn't quite as elegant yet as we'd like it to be | 20:25 |
| mandel | statik, where Canonical has contact in it and urls such as the ubuntu url | 20:25 |
| Howard_Kindig_ | It's all good...that's what open source is all about...constant development (and help when you need it!) :) | 20:26 |
| mandel | aquarius, although I love the id of metadata for groups I think is far too early to think about it | 20:26 |
| Howard_Kindig_ | Taking off...thanks again! | 20:27 |
| statik | mandel, exactly thats the thing i don't know how to answer. i have an idea but aquarius will say it's a nasty hack ;) | 20:27 |
| aquarius | mandel, I agree. I'm just trying to close as many future doors as we can while not closing ones that we really think we're going to need | 20:27 |
| mandel | statick, aquarius, if you do not add metadata to the group people will never know since is something that few of us need | 20:28 |
| statik | right | 20:28 |
| statik | and a taglike system just feels so good compared to LDAP or launchpad teams or other hierarchical approaches | 20:29 |
| mandel | question has anyone read: http://www.nobius.org/~dbg/practical-file-system-design.pdf might give ideas... (following statik comment of BeFS) | 20:29 |
| statik | that is an awesome book | 20:29 |
| statik | dominic made me fall in love with C pointers in that book | 20:29 |
| mandel | statik, do you recommend it? | 20:30 |
| aquarius | imagining that we come up with some dreadful hack for empty tags still existing, and imagining that we don't allow metadata on groups (neither of which I am convinced about, but go with it), I still want to be able to share a group. | 20:30 |
| urbanape | what's that mean? | 20:30 |
| statik | mandel, it's more about outdated implementation hacks and showing how to write a filesystem in userspace before porting it to the kernel. he's since gone on to work at google and then apple, on the spotlight team | 20:30 |
| urbanape | share the members? | 20:31 |
| urbanape | or share the metadata (assuming there is some) of the group itself? | 20:31 |
| mandel | statik, sounds good time, I like to know as mush as possible, even if outdated, I'll give it a go :) | 20:31 |
| aquarius | Use case: someone new joins my book-reading class, and we all collaborate on notes on a book via Ubuntu One. When they join, I add them to the group, and share the group record with them; they then know who else is in the group, *and* everyone else in the group gets an updated group record telling them about the new person. | 20:32 |
| statik | oh yeah, thats facebook | 20:32 |
| aquarius | and they'll automatically get access to our shared folder with the notes in, *because* the folder is shared to the group, not individually to all the people within it. | 20:32 |
| statik | yeah, group based access control starts to break down using a tag scheme. i think | 20:33 |
| statik | i mean, how to implement group based access control via a system that is tag based isn't immediately obvious to me. | 20:34 |
| aquarius | think about it the alternate way (with tags): how would you do that situation? I tag the new person with "book study group". I go and find the shared folder and share it again to the new person. I then share the new person's contact record individually with all the other people in the group, and I share everyone else's contact record individually with the new person. | 20:34 |
| mandel | aquarius, I don't like the idea of sharing personal info of other people... includes legal problems and other headache... plus you have to start dealing with people that are in a group and do not want their info share, just part of it etc... | 20:34 |
| aquarius | that's, like, sixteen steps. | 20:34 |
| aquarius | mandel, I've already worked all that out :) | 20:35 |
| aquarius | mandel, you, yourself, control what information you share with me. I can then share that information on, because, frankly, you can't stop me -- if you tell me your phone number, you can't stop me then telling it to urbanape :) | 20:35 |
| urbanape | be wary of anyone who utters "I've already worked all that out" | 20:35 |
| mandel | aquarius, and what about partial replication (if it lands) to implement the group share using tags | 20:36 |
| mandel | replicate record with a given tag to your friends db | 20:36 |
| aquarius | urbanape, that was hyperbole, I admit -- it was more to suggest "I'm not just making this up as I go along, I have put some thought into it" :-) | 20:36 |
| urbanape | the only trouble I see with groups as tags is that you can't control who applies the tag. | 20:36 |
| urbanape | in that sense, yes, it is too ephemeral. | 20:36 |
| urbanape | when I worked at Socialtext, we were implmenting a user directory app. | 20:36 |
| urbanape | it had both tags and groups, and needed them, because they're very different things. | 20:37 |
| urbanape | Groups have membership, and tags are (again) ephemeral | 20:37 |
| urbanape | No one would tag someone as "subordinate" because there's no relationship there. | 20:37 |
| urbanape | groups can reflect a relationship, where tags can't. | 20:38 |
| urbanape | no one would go to the trouble to establish a *group* called "dog lovers" | 20:38 |
| urbanape | but it's easy enough to apply to someone. | 20:38 |
| dobey | relationships shouldn't be done with tags or groups | 20:38 |
| dobey | they should be done with relationship fields | 20:38 |
| urbanape | all I'm saying is that the act of becoming a member of a group is a different act than self-identifying with a tag (or having that tag applied to you by someone else, if permitted) | 20:39 |
| urbanape | becoming/being nominated to | 20:39 |
| mandel | well tags are metadata, while groups are data, that in the main difference.. a tag is a second class citizen in my worlds | 20:39 |
| dobey | urbanape: there are 3900 "dog lovers" groups on facebook :) | 20:39 |
| urbanape | dobey: when all you have is a hammer... | 20:39 |
| dobey | urbanape: well, there are 60 pages now | 20:40 |
| dobey | urbanape: but a group for dog lovers does make sense | 20:40 |
| dobey | urbanape: at least in the sense of what a group is on facebook | 20:40 |
| urbanape | group membership entails a whole different mindset than being tagged something. | 20:40 |
| statik | verterok, not deleting shares when they are revoked was a deliberate design decision, right? | 20:40 |
| dobey | which is a forum for exchange and discussion | 20:40 |
| urbanape | membership requires a different mental model than a tag | 20:41 |
| dobey | yes it dose | 20:41 |
| dobey | does | 20:41 |
| verterok | statik: yes | 20:41 |
| urbanape | but I don't think they need to be exclusive. | 20:41 |
| urbanape | or exclusory | 20:41 |
| dobey | i should stop arguing about groups | 20:41 |
| aquarius | the point here is: we can model both tags and groups from the user perspective if we have group entities in the data structure. If we only have tags in the data structure we can't really model groups from the user perspective. | 20:42 |
| dobey | and do the SRUs | 20:42 |
| dobey | what is the difference between a group and a tag from the user perspective, really? | 20:42 |
| verterok | statik: but we can easily delete a revoked share | 20:42 |
| dobey | groups in this context are not things the members make a conscious decision to join or not join | 20:42 |
| dobey | which doesn't make it much of a group | 20:42 |
| urbanape | aquarius: My revised point is that they are two different things, and maybe we should do them both. | 20:43 |
| mandel | dobey, group can exist by itself, tag need a contact to be present | 20:43 |
| urbanape | dobey: they absolutely do, if we're going to apply access rules to them. | 20:43 |
| verterok | statik: one option to avoid data loss is to delete the share contents that we have in the metadata | 20:43 |
| mandel | dobey, metadata == tag, group == data which is aBIg diff | 20:43 |
| verterok | statik: should we have a bug about this? :) | 20:43 |
| urbanape | then we do need them to be consciously moderated | 20:43 |
| dobey | mandel: i don't believe in metadata | 20:43 |
| dobey | mandel: it's all just data to me | 20:43 |
| dobey | :) | 20:44 |
| aquarius | no. a group isn't some sort of free-floating Platonic entity in empty space; it belongs to a person | 20:44 |
| aquarius | that person can decide to share their group with others | 20:44 |
| aquarius | so someone becomes, essentially, "administrator" for that group, in the example of my book-reading club above | 20:44 |
| urbanape | aquarius: no, groups are independent of a person | 20:44 |
| mandel | dobey, I do, example the metadata data is going to attack you | 20:44 |
| statik | verterok, yes please. your last idea, and filing a bug, sounds great | 20:44 |
| aquarius | urbanape, that's what I'm trying to avoid. I don't want independent groups, because then you need to worry about group ownership and so on and it's very complicated. | 20:45 |
| mandel | dobey, set metadata to big and data to dog, missing the metadata does not matter, missing the data does :P | 20:45 |
| aquarius | urbanape, and I'm trying to avoid having both groups and tags. | 20:45 |
| urbanape | aquarius: that can't be avoided, especially if we're going to make access rules based on groups | 20:45 |
| verterok | statik: ok :) | 20:45 |
| aquarius | urbanape, it can if you don't have tags. | 20:45 |
| urbanape | aquarius: why? they're two different things | 20:45 |
| aquarius | not to a punter they aren't. | 20:46 |
| dobey | mandel: "big" is an adjective, not metadata | 20:46 |
| aquarius | they're different if you delve right into the detail. | 20:46 |
| urbanape | are punters our audience? | 20:46 |
| aquarius | but most people will not. | 20:46 |
| urbanape | I aspire to have a smarter user | 20:46 |
| aquarius | urbanape, as opposed to people who think it's fun to talk about taxonomies, like us? yes, they are :) | 20:46 |
| dobey | deploying knowledge is always the best option | 20:47 |
| dobey | but taxonomies are the debil | 20:47 |
| urbanape | no, I mean someone intuitively understanding that tagging their friend John with 'baking' doesn't necessarily put him in the "bakers" group. | 20:47 |
| statik | dat debil will git you ebery time | 20:47 |
| mandel | dobey, definition (or one) of adjective: not standing by itself, dependent, Metadata depend on data as an adjective depend on a noun | 20:47 |
| aquarius | urbanape, then that's two different groups, no? | 20:48 |
| rtgz | realpath lost the battle. Current winner: canonicalize_file_name | 20:49 |
| urbanape | I recant, I recant, I recant. Tags are not groups. Done. | 20:49 |
| urbanape | both have their purposes, and each has a distinct semantic | 20:49 |
| statik | aquarius, taking a step back, whats the future use cases for access control based on groups? stuff like we do with launchpad teams today, sharing and revoking a folder to a group rather than a bunch of individual people? | 20:49 |
| urbanape | and while each can be an approximation of the other, doing so misses out. | 20:49 |
| === mandel is now known as mandel_afk | ||
| aquarius | statik, broadly, yes. Anywhere you can pick a person, you should be able to pick a group instead. | 20:50 |
| statik | right on | 20:50 |
| statik | so for the purposes of organizing my own contacts, tags seem the natural fit | 20:50 |
| statik | for implementing an access control scheme, groups seem the natural fit | 20:50 |
| dobey | like i said. no such thing as metadata :) | 20:51 |
| statik | apparently making software is complicated | 20:53 |
| statik | no wonder you guys work so hard on it | 20:53 |
| urbanape | so, with the u1sdtool, how does the reject-share part work? We don't seem to have a view for that in the /files/ UI. | 20:53 |
| statik | urbanape, it sends a dbus command to the syncdaemon which sends a protocol message back to the api server | 20:53 |
| urbanape | which means we can't easily wire it up in javascript | 20:53 |
| urbanape | if it's sending it to the api server, it must be hitting the api, yeah? I don't see a view that governs rejecting a share | 20:54 |
| statik | yeah, it would need a new view. it's kinda sad that our protocol is so separate from our rest API | 20:54 |
| urbanape | I see deleting (rescinding) a share that I've made. | 20:54 |
| statik | the twisted storage aPI server | 20:54 |
| urbanape | ah | 20:54 |
| urbanape | yes, that is sad. | 20:54 |
| statik | in a totally fixable way of course. all we need is time. | 20:56 |
| urbanape | can someone associated confirm that that message is "decline_share"? | 20:58 |
| dobey | oh time | 20:59 |
| * dobey would love to have more time | 20:59 | |
| urbanape | Because I see that in the storage controller, and can probably wire it up through a view, and through javascript | 20:59 |
| urbanape | but I don't know if decline_share is only tied to the offer or to the share after it's accepted, or both. | 21:00 |
| urbanape | ah, looks like our web controller does the mediating under the guise of "delete_share" | 21:01 |
| urbanape | so we can use that for both (depending on who you are in the relationship, it calls the right method underneath) | 21:01 |
| urbanape | kinda gross. | 21:02 |
| Chipaca | dobey: I have a mental stick note about talking to you about planning and ... something. Not sure what, seems the sticky note got dropped in nacho sauce or something | 21:02 |
| urbanape | mmmm, nachos | 21:02 |
| dobey | cheesy | 21:02 |
| dobey | Chipaca: infrastructure fixings | 21:03 |
| Chipaca | dobey: what kind of infrascrotal fixtures? | 21:03 |
| Chipaca | whoops, typo :-p | 21:04 |
| dobey | Chipaca: there's some work we need to get done on tarmac, and we need to get it running in a cron job in ec2 | 21:04 |
| statik | aquarius, now my head is spinning with groups. the whole sharing/access control thing is complicated | 21:04 |
| statik | we need massive shared virtual whiteboards | 21:05 |
| aquarius | statik, have you still got a copy of the groups & teams document I wrote up months ago? | 21:05 |
| aquarius | actually, I do believe it's on the wiki somewhere. | 21:05 |
| Chipaca | statik: can I context switch the hell out of you for a minute or five? | 21:05 |
| statik | i go into these twitching fits where i delete stuff. is it in ubuntu one? ah wiki, even beeter | 21:05 |
| statik | Chipaca, i love context...hey a squirrel | 21:05 |
| statik | by which i mean i am at your service | 21:06 |
| Chipaca | statik: dobey wants tarmac fixed. Is that work for dobey himself, or is it something we can palm off on ops+? :) | 21:06 |
| statik | Chipaca, you can dump it on ops+. pfibiger is supposed to be hiring someone | 21:07 |
| Chipaca | dobey: can you spec up what work needs doing, so we can pass it on to ops+ and yell at them if they don't do it right? | 21:08 |
| === mandel_afk is now known as mandel | ||
| urbanape | So, a thought: in the Web UI, I think a natural way to remove a folder that's been shared with you is to delete it. However, that's a conflicting (internally) gesture with being able to delete a shared folder to which you have write access. Or is it? | 21:08 |
| dobey | Chipaca: sure | 21:08 |
| Chipaca | not that we would do something as crass as yelling you understand | 21:08 |
| urbanape | To the user to whom the folder is shared, both actions have the same end. | 21:08 |
| Chipaca | it's completely figurative | 21:08 |
| urbanape | I.e., that damned folder no longer appears in my "Shared with Me" space. | 21:09 |
| Chipaca | dobey: anything else? | 21:09 |
| jblount | urbanape: Maybe instead of a trash can there is some "unlink" sort of icon? Some other thing? | 21:09 |
| aquarius | urbanape, they're the same thing, aren't they? being able to "delete" a folder that you have write access to without unsharing it is a supremely pointless activity, since nine seconds later syncdaemon will just put it back | 21:09 |
| urbanape | well, it sorta begs a question: Do we really ever intend to let people we share folders with (even read/write) delete the folder itself? | 21:09 |
| aquarius | nah, because it's not really a folder. it's a share, which we happen to model as a folder | 21:10 |
| urbanape | aquarius: no, if I'm in the book study group, and I've been given read-write access to the folder, and I just want to drop the share, but click delete, boom. There it goes for everyone else. | 21:10 |
| urbanape | f | 21:10 |
| urbanape | erm. | 21:11 |
| mandel | need to take a rest, please let me know if you made a decision on groups since it was my self imposed homework for the weekend, laters ;) | 21:11 |
| aquarius | there's a difference between having write access to a share and being the owner of it, though | 21:11 |
| urbanape | I'd imagine deleting a folder if I have r/w access actually deletes it, and syncdaemon should undersatnd that. | 21:11 |
| urbanape | I don't see how. | 21:11 |
| rtgz | hmm..... can I share some directory with someone from those that were shared with me?... | 21:11 |
| rtgz | and in this case what will happen if someone shares with me something that I shared with them.. | 21:11 |
| rtgz | If I stare into the shared directory, the shared directory stares back into me | 21:12 |
| aquarius | deleting a share folder if you own it should remove the share from everyone else; deleting a share folder if you don't own it should reject that share. | 21:12 |
| Chipaca | rtgz: no, no resharing | 21:12 |
| urbanape | rtgz: typically, those are modeled as two separate permissions/actions | 21:12 |
| urbanape | aquarius: is that actually codified anywhere? | 21:12 |
| aquarius | you can't reject a share if you're owner of it, and you can't delete a share if you're not owner of it. So the cases are disjoint, and the action is unambiguous. | 21:12 |
| rtgz | sorry for reposts, reconnect happens... | 21:12 |
| urbanape | how about deleting subfolders, if I've got read/write access? | 21:12 |
| aquarius | urbanape, it is technically possible that that's just how it Should Work, but I'm pretty sure that that's how it actually does work | 21:13 |
| aquarius | deleting subfolders is fine; that'll delete them from everyone (that's what write access means), unless I've totally misunderstood, and if i have then I think syncdaemon is wrong. I don't think I have though! | 21:13 |
| dobey | aquarius: well, i can delete the contents of a share if i was granted write permissions | 21:14 |
| dobey | which is somewhat effectively the same as deleting the share | 21:14 |
| aquarius | dobey, yep. there's not much difference between actually deleting a share and deleting all its contents, I admit, but there's not really a way around that. | 21:14 |
| urbanape | yes, I don't see the distinction, if you've been granted write access | 21:14 |
| aquarius | there is quite a big distinction in a world with history in it. | 21:14 |
| aquarius | If you delete the contents, and you have history, you can get them back | 21:15 |
| urbanape | if you delete a folder and have history you can get it back. | 21:15 |
| urbanape | no difference, eh? | 21:15 |
| aquarius | if you delete the share, a recipient of that share can't get the files back, even with history, because they no longer have access to the share. | 21:15 |
| urbanape | I feel like we're talking at cross purposes here. | 21:15 |
| dobey | well, if we had history of who shared what to whom | 21:15 |
| dobey | then that could be recovered as well | 21:15 |
| dobey | Chipaca: and then there's the planning thing | 21:16 |
| Chipaca | dobey: yes. But I'm leaving; you want us to do it together tomorrow? | 21:16 |
| dobey | but i'm more ad-hoc and spontaneous | 21:16 |
| aquarius | urbanape, model a share as follows. Oscar the Owner has a folder. He shares it read-write to William the Writer and shares it read-only to Roger the Reader. | 21:16 |
| dobey | Chipaca: that would be fine, sure | 21:16 |
| Chipaca | dobey: yes, I know. Brownian would also be an adjective for that :) | 21:16 |
| aquarius | urbanape, if William deletes all the contents of the share, and there is history, Roger can still see the historical versions of the files (as can William and Oscar) | 21:17 |
| urbanape | aquarius: In my mind, Roger can reject the share, which does nothing to the folder. William can reject the share, doing the same thing, but he can also delete the folder. | 21:17 |
| aquarius | urbanape, if Oscar deletes the share itself, then Roger no longer has any access to it, and therefore can't see the history | 21:17 |
| urbanape | orthogonal to what I'm asking | 21:18 |
| * Chipaca waves | 21:18 | |
| urbanape | there are two things that can be acted upon: the share, which is a relationship, and the folder, which is a content object. | 21:18 |
| dobey | grmbl | 21:19 |
| dobey | i think dpm deleted his branch(es) | 21:19 |
| urbanape | what started this whole mess is a proposition: that for a user who has had a folder shared with her, it is intuitive to "delete" the folder to make it go away from her "Shared with Me" stuff. | 21:19 |
| aquarius | agreed completely. | 21:19 |
| aquarius | I also think that it is intuitive fo a user who has shared a folder with others to "delete" the folder to both remove the contents and remove the share from others | 21:20 |
| urbanape | So, one thing we could say is: "Recipients of shares, even with write access, never delete folders via the trash can icon, they only delete shares" | 21:20 |
| aquarius | I agree. | 21:20 |
| urbanape | well, sharing a folder with others doesn't place it in your "Shared with Me" area - it's still within your "My Files" area. | 21:20 |
| urbanape | and yes, deleting it should delete any shares you've granted. | 21:21 |
| urbanape | (would be my expectation) | 21:21 |
| aquarius | I think the "folder" for a share actually represents that share itself; deleting it means "I don't want this share" if it was shared with you, and "delete all these files and unshare it with others" if you shared it with others | 21:21 |
| aquarius | so we agree, right? | 21:21 |
| aquarius | confused about where we disagreed :) | 21:21 |
| urbanape | no, but the effect is the same. | 21:21 |
| urbanape | what I'd propose is: | 21:21 |
| urbanape | within My Files, deleting a folder deletes the folder, also deleting any of its shares. | 21:22 |
| aquarius | yes | 21:22 |
| urbanape | within Shared with Me, "deleting" a folder merely deletes the share. | 21:22 |
| urbanape | although that only works at the root. | 21:22 |
| urbanape | fuck me. | 21:22 |
| urbanape | screw this, I'm going shopping. | 21:23 |
| dobey | verterok: ping | 21:23 |
| aquarius | within Shared With Me, deleting a root folder rejects the share. | 21:23 |
| verterok | dobey: pong | 21:23 |
| dobey | verterok: does https://edge.launchpad.net/~verterok/ubuntuone-client/dont-delete-child-partials fix a bug? (there isn't one linked) | 21:23 |
| urbanape | aquarius: not for subfodlers | 21:24 |
| verterok | dobey: the second part of the capabilities mismatch bug | 21:24 |
| verterok | dobey: actually the data loss that triggered the caps mismatch | 21:24 |
| urbanape | I don't believe you can reject a share "somewhere down the stack" | 21:24 |
| urbanape | sorry, yes, root folder | 21:25 |
| aquarius | urbanape, yeah; deleting a non-root-folder within Shared With Me just deletes that folder (if you have rw access to the share) or denies you (if you have ro permissions) | 21:25 |
| dobey | verterok: is there a bug # it should be linked to? | 21:25 |
| dobey | verterok: i need bug #s to put it in the stable branch for SRU | 21:25 |
| urbanape | Hmm, I don't think our code differentiates "root folder" vs. "anything else" | 21:25 |
| dobey | verterok: and it sounds like i need to put that in the SRU | 21:25 |
| verterok | dobey: there is, but I don't remember it | 21:25 |
| urbanape | guess it probably could, given time. | 21:25 |
| dobey | hrmm | 21:25 |
| verterok | dobey: gimme 1' | 21:26 |
| urbanape | aquarius: so are we in violent agreement? | 21:26 |
| aquarius | urbanape, we are. | 21:26 |
| verterok | dobey: it's the bug with 1k dupes of caps mismatch | 21:26 |
| urbanape | "You're right!" "No, YOU'RE RIGHT!" | 21:26 |
| aquarius | :) | 21:26 |
| * CardinalFang anticipates fisticuffs. | 21:26 | |
| dobey | brb | 21:30 |
| verterok | dobey: Bug #462828 | 21:30 |
| ubottu | Launchpad bug 462828 in ubuntuone-client "Files are marked for deletion on server when syncdaemon is killed during sync" [Critical,Fix released] https://launchpad.net/bugs/462828 | 21:30 |
| dobey | verterok: ok, thanks! | 21:30 |
| dobey | ok, brb for real :) | 21:36 |
| urbanape | CardinalFang: fisticuffs where we both punch ourselves. | 21:36 |
| aquarius | right, I'm going away. Cheers, all. Back tomorrow! | 21:45 |
| dobey | later all | 22:26 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
