[00:00] cheater99: Also, for people who are familiar with CVS or Svn, it has a basically-compatible command set. [00:00] cheater99: And finally, it can do remote operations, which git cannot. [00:00] ok [00:01] cheater99: git's advantage is that it is ridiculously, blindingly fast. [00:01] what's the slowest thing in bzr? [00:01] cheater99: Probably annotate, like every DVCS (git and hg will be the same). Also, "bzr log -v" can be slow on large projects. [00:01] interesting question [00:01] 'check' is probably the least optimized code [00:02] what is the slowest thing in bzr that is comparably very fast in git? [00:02] poolie_: But also one that normal users will almost never be running. [00:02] probably also check [00:02] what about local branching? [00:02] bzr being in python has a startup time overhead of a fraction of a second on each command, which git doesn't have [00:02] how does that work out? [00:03] aha [00:03] cheater99: If you have created a "repository" with bzr, local branching is very fast. [00:03] but can't you have a python daemon.. [00:03] bzr commit was recently measured (benchmarks are all bogus) as faster than hg [00:03] which didn't used to be true [00:03] mhm [00:03] cheater99: The day-to-day difference of speed using bzr and git makes no significant difference in my development productivity. [00:03] but if you have a running python process already then there's no startup overhead [00:04] cheater99: But if I had 100,000 commits in my repo, that might be a different story. [00:04] cheater99: The startup overhead is not something that's going to affect your productivity. [00:04] cheater99: There isn't any common operation where there isn't a linear difference between bzr and git. [00:04] aha [00:04] that is good to know [00:05] cheater99, there is a plugin that gives you a longrunning python process [00:05] and then a c program that passes commands to it [00:05] poolie_: That's cool; I didn't know that. [00:05] nice [00:06] cheater99: Also, I suppose one of the advantages of bzr is that you go into #bzr and the project lead helps you out, there. Hahaha. [00:06] (Although actually, pretty much everybody in this channel I've found to be pretty helpful.) [00:06] who's the project lead? [00:06] cheater99: poolie [00:06] ah [00:06] nice [00:06] hi [00:07] also, very different experience from the git channel :) [00:07] Yeah. [00:07] Where you go in and people insult you because you're not doing it right. :-D [00:07] (Well, not always, though. Sometimes #git is helpful.) [00:07] that's sadly the kind of experience i got [00:08] what do you think is missing most in bzr? [00:09] ah, cleaner colocated (git-style) branches [00:09] s//and built-in [00:09] ditto built in nested trees aka submodules aka externals [00:10] is it far off? [00:12] i guess it doesn't matter that much though :) [00:12] bzr feels very solid [00:12] what i really like about it is the manuals are so friendly [00:12] big difference from cvs, git, svn, rcs, .. [00:13] can i somehow make bzr version files inside archives? [00:13] how do you mean? [00:13] well [00:14] some applications save documents as archives. for example, mysql workbench [00:14] it has this .mwb file format, which is in fact a zip with xml and other ascii files in it [00:14] :) [00:15] cheater99: The answer to that is "no, but it comes up from time to time" [00:15] cool [00:16] i would need to convert from cvs to bzr. [00:17] will that make historical commits in cvs atomic? [00:17] most of the conversion tools put some effort into that, yes [00:18] cool [00:18] does that actually work? [00:18] the repository i'm talking about isn't huge [00:18] Often :) [00:18] and it wasn't extremely busy [00:18] about up to 5 developers at any time... doing just a handful of commits every day [00:18] should be fine [00:19] that will atomize the non-atomic commits in cvs? [00:19] really? [00:19] nice! [00:20] hm, one thing that would be cool: to be able to use bzr for my editing buffer in vim ;) [00:20] for undo/redo [00:20] :) [00:21] Well, most converters try. CVS makes it difficult to be sure of success, so results vary. [00:21] that's cool though [00:21] after all we're not talking about rocket brain surgery [00:22] If you haven't done repo surgery, or a lot of cross-branch work, it usually turns out OK. [00:22] not at all [00:22] i would say, maybe 3 concurrent branches at most [00:23] Well, things like having a file on one branch that are later added to another branch can be squirrely. And figuring branch points is educated guesswork. [00:23] It really just ends up as "try and see". [00:24] cheater99: I'm drafting a blueprint specifically for that use case (diffing and merging zip files) [00:24] (that's not bzr-specific; it's the "figure out what actually should have happened from CVS records" side of things) [00:24] jbowtie: nice! [00:25] jbowtie: any cool bits to talk about? :) [00:26] The proposal is specifically for working with free software formats that we currently treat as unmergable binaries. [00:27] yes [00:27] but then i ask myself [00:27] if a zip has a zip in it [00:27] you will have to merge recursively. [00:27] For zip files (and variants and other archives) we should be able to treat them as folders. [00:27] and then you are really defining a new "dimension" of files [00:28] so not only horizontally across the file system [00:28] but also vertically inside files. [00:28] And we already know how to merge folders recursively. [00:28] yes [00:28] i guess if you think of it that way [00:28] then it becomes easy [00:28] a folder is just a different "file format" then [00:29] and then, i guess, other formats which do not depend on zip etc, but still have some sort of modules in them, could possibly have a plugin that talks to some sort of api [00:29] Well, there are going to be performance issues working with archives (particularly tar files) but the improved user experience should make up for it. [00:29] yes [00:29] Yes, that's what I really need to pin down in the blueprint proposal - what the API looks like. [00:29] but those "performance issues" should only happen when they choose to merge, right? [00:31] any operation that requires accessing the contents of the files is going to incur some overhead from decompression [00:31] i think the simplest api would be: present the plugin with both files to be merged, expect a third file in a special location :)) [00:31] Correct; I imagine in the first iteration of an implementation you'd have to turn it on via plugin. [00:31] dOxxx: that's obvious :) [00:31] that's me, captain obvious :P [00:32] jbowtie: but if you want your merge to only overwrite? [00:32] jbowtie: you'd need to have a special way to do that too [00:32] i.e. i want to merge, but all my binaries overwrite remote binaries. [00:32] something like that might be possible with the per_file merge hooks [00:33] ah [00:33] there's already a plugin that handles merging of NEWS files specially [00:33] but, that's a bit crappy not to have this granularity then and there [00:33] We just need to make sure the merge hook API covers our scenarios, and add corresponding diff hooks. [00:34] i would even like to be able to say "bzr always-overwrite-on-merge myarchive.tgz" [00:34] yeah, I'm not sure how configurable it is, whether it can selectively operate on some files some of the time [00:34] What you do is have your plugin use the hooks, then make the plugin configurable. [00:34] :) [00:34] theoretically, the plugin could add a file to the .bzr directory in the branch which contains a list of files that have to merged specially [00:35] btw [00:35] can i use bzr with github? [00:35] not as the main repository [00:35] but just so that i can use github statistics, graphs, and all that silly stuff [00:35] But I'm also looking at more complex scenarios, like merging Photoshop files - the diff and merge works on layers instead of lines of text. [00:35] yes [00:35] Yes, just use the bzr-git plugin. [00:35] i guess you'd need a graphical log then huh? [00:36] displaying graphics :) [00:36] i really like this jbowtie [00:37] I think you need to work with the GIMP folks to see what can be reported in text (layer names perhaps) as well as hooks for the (existing) graphical diff tools. [00:37] My goal is to ultimately make bzr a good experience for artists as well as programmers. [00:38] jbowtie: Does bzr even do binary deltas right now? [00:38] Working on, say, a game, you should be able to version your art assets in the same repository as your code assets. [00:39] jbowtie: That would definitely fix the third common unanswerable question that people come in here with. [00:39] jbowtie: "I have this repository with these 20GB files in it, and..." [00:39] mkanat: I'm pretty sure it does, but diff and merge is reduced to (these binaries differ) and (choose mine or theirs) respectively. [00:40] mkanat: Though I'd actually have to look at the branch format to see how it stores things. [00:40] the problem of course is that compressed content doesn't diff well, on the whole [00:40] jbowtie: *nod* [00:41] jbowtie: great idea [00:41] hard to squeeze out entropy in two ways at once [00:42] jbowtie: does it let you interactively download and open the two binaries? [00:42] jbowtie: so that you actually know what you're overwriting, [00:42] and so that you can open it in, for example, photoshop. [00:43] cheater99: Yes, if you use qdiff right now it shows you images side-by-side, that sort of thing. [00:44] yeah but what if they're, say, UnrealED maps. [00:44] i need to open them in the level editor [00:44] (just giving you an idea of where you need access to the files) [00:45] cheater99: That's the point of the blueprint I'm drafting; so you have an API that lets plugins hook in and provide that for both diffing and interactively merging. === sidnei-dinner is now known as sidnei [00:45] yep [00:45] but that api won't be implemented for everything! [00:46] so the situation i describe will still be the default for most things.. [00:46] Absolutely - but we'll start by handling zips (I would think) and start talking to the main free software artist tools. [00:47] Once we've got a decent API and good examples to build of off, people will be able to write plugins for any binary format. [00:47] And we always have a fallback for generic, unhandled binary files, which is the current behaviour. [00:47] yup [00:47] :) [00:48] i'm off to sleep, cya guys! [00:48] thanks for the info! [00:48] :) [00:49] ciao [01:00] poolie: I'm going to do some loggerhead research and possibly some work today. :-) [01:07] mkanat: nice [01:14] I can't help but feel like loggerhead.config is a reinvention of a wheel that exists somewhere else. [01:14] It's not that complex, though. [01:15] There's got to be duplicate code in bzrlib, though, since it's doing very bzr-ish things. [01:17] In fact, looking over the general startup code for loggerhead, I'm tempted to join the "this should entirely be a bzr plugin" camp. [01:26] Man, there's a lot of Paste stuff in loggerhead, strewn about. :-( [01:28] Largely because Paste itself does too many things. [01:32] jam: Does the existing bzr-history-db stuff do on-disk file locking? That is, would multiple loggerhead processes running be OK? [01:32] I assume it does, and that it's just part of the normal bzr locking mechanisms. [01:52] mkanat: i think that's correct [01:52] it uses a pack db i think, which is multi writer safe [01:52] poolie: Okay. [02:01] poolie: Did you need any supporting material for my CV? Last time I asked you were still waiting on HR. [02:02] * poolie looks [02:02] i still am waiting :/ [02:02] will ping them tonight [02:02] actually can you send me a copy direct, in parallel? [02:04] Sure, will do. [02:12] poolie: Sent through to your canonical account. [02:26] thanks [02:27] poolie: I'm starting to lean toward's lifeless's suggestion of making a 1-thread paste server and running it multiple times, and just putting it behind a proxy. [02:28] ok, interesting [02:28] why behind a proxy? [02:28] poolie: The reason being that Paste is sort of littered throughout the code. [02:28] poolie: For load-balancing. [02:29] poolie: That is, we simply would run serve-branches four times, on four different ports, on a four-core machine. [02:29] Or we'd run it 10 times, if we wanted to be able to handle 10 simultaneous requests. [02:29] you know you can actually have multiple processes listening on the same port [02:30] poolie: Yes, with a master + forking situation. [02:30] poolie: Which would be Spawning, then, not Paste, since Paste can't do multi-process. [02:31] doesn't SO_REUSADDR let you bind a port that's already open? [02:31] poolie: Unless you just mean have the process release the port when it's working, and then wait in a queue. [02:31] imbw [02:31] i'm just saying it seems nice to avoid adding a proxy if it's only going to distribute work across ports [02:32] poolie: What lifeless suggested is what Launchpad does now. [02:32] poolie: The advantage is that it's just a configuration change. [02:32] Although I'd have to test it locally and make sure that running multiple loggerhead processes actually works. [02:37] poolie: The scaling problem is only a problem at Launchpad, AFAIK. [02:37] ok, that makes sense [02:38] poolie: The complexity of threading is a problem everywhere, so it would still be nice to switch to a multi-process model, and I'd love the code cleanup that would involve. But I feel like the best time investment might be to investigate the 1-thread paste server solution. [02:40] how do I get the source for bzr-rewrite? using bzr? [02:40] I have the url for trunk... but how do I check it out? [02:40] doesn't seem to be a repo [02:41] GungaDin: 'bzr branch lp:bzr-rewrite' doesn't work? [02:41] will try [02:41] works [02:41] thx [02:58] poolie: Next time I work on loggerhead I'm probably going to try out the 1-thread system and see if it works and what would need to be fixed. [02:59] spiv: Thanks for reviewing those doc patches so quickly. [03:00] I was thinking that more of those links should be turned in Sphinx ref directives, might reduce link breakage bugs. [03:03] jbowtie: yeah, that sounds good [03:03] jbowtie: we only switched to just Sphinx relatively recently [03:03] Before that we were a bit limited by also supporting plain docutils. [03:05] I've accidently rebased a branch and I'd like to undo it... how can I do that? [03:05] (using bzr rebase) [03:07] GungaDin: Perhaps with 'bzr pull --overwrite -r revid:OLD_REVID', if you know the old revision ID (or can find it with 'bzr heads' from the bzrtools plugin) [03:08] something very weird happened.. because I specified a branch I had merged into and not the parent branch [03:08] and now both branches looks the same [03:33] * spiv -> lunch. Looking forward to some replies from PQM when I get back... [04:24] Good evening [04:30] http://img137.imageshack.us/img137/2454/bzr3.png (some more work on a new website) [04:31] (for bzr, that is :) ) [04:33] hi there anteru [04:33] spiv could you take a pass through the New bug queue? [04:33] Slow progress, as I'm investing 1 hour every two weeks or so right now, busy with work... [04:34] it's good [04:34] i wonder if the command-line samples are a bit too directly derivative of the git homepage? [04:34] hg has the same :) [04:34] also, to me, the different shades of blue kind of clash with each other [04:35] Yeah, the colors are crap, I need to fabricate a few images later on. [04:35] And I still wonder how to place the explorer screenshot [04:35] after all, it's a usp for bzr [04:36] right, i think we want to communicate both the gui and cli bits [04:36] I assume you're going to align the second block to the grid at some point? [04:36] I'm going to pull a grid over this really soon now, wanted to get the big fat bazaar text right today. [04:38] navigation will be close to what ubuntu.com has, that shouldn't be a problem as it's canonical here as well [04:39] I wonder if someone agrees that it's enough to have the version number at the downloads instead of having it below the bazaar text? [04:39] At least for me as a user, I'm going to search the version at downloads, to see if X.Y is available for my OS. [04:42] I agree, though it would be good if a major release made a bit of a splash on that page - is there an obvious place for that? [04:42] agree [04:42] i like having the blog and announcements syndicated there [04:42] above the fold [04:42] also it kind of sucks to say "no test release" [04:42] let's just omit that if there is none [04:42] well, you could always add a big 3 next to bazaar === FryGuy_ is now known as FryGuy- [04:45] Ok, taking some notes: Different color scheme, gridified layout, place for syndication, less version numbers. [04:49] For the color scheme you might want to see what the full Ubuntu palette looks like (I'm sure they have compatible shades of yellow and blue to go with their dominant colors) [04:51] Once you've nailed down the grid I'll start overhauling the documentation templates to coordinate. [04:51] That'll probably bring up color issues with the images in the doco. [04:53] Do you have a link to the ubuntu color scheme? [04:58] I'd probably start on design.canonical.com - I'm just running off to a meeting or I'd hunt it down. [04:58] Ok, thanks! [04:58] Should do it [04:59] Found the color palette [05:28] when merging only several commits, how come you can't see the merged commits in qlog? [05:30] You don't see the plus sign? [05:31] nope [05:31] just one commit [05:31] without a plus sign [05:32] and bzr log --include-merges shows it? [05:37] qlog doesn't accept that. and with just log doesn't seem so . [05:38] If bzr log doesn't show it, then it's not a qlog problem. [05:38] Are you sure you didn't push? [05:38] * anteru never had an issue with a merge loosing history ... [05:46] just merged and commited [05:47] no, log doesn't show them. [05:49] Sounds like a bug. [05:56] GungaDin: "merging only several commits", you mean "bzr merge -r x..y"? [05:57] GungaDin: if so, then that's cherrypicking, bzr can't record those as merges, it's more like just applying the diff [05:58] GungaDin: if you look at the "bzr st" output before committing that sort of merge it won't have any "pending merges" [05:59] GungaDin: so I think it's not a qlog issue, just a bzr limitation: http://doc.bazaar.canonical.com/latest/en/user-guide/adv_merging.html#cherrypicking [06:01] yes [06:01] -r x..y [06:02] I'm just looking for a way to move commits to a different branch... if that's possible. [06:02] I have a branch where there are two sets of commits which are mutually exclusive. [06:08] Well, one option may be to "bzr branch original-branch different-branch; cd different-branch; bzr merge -r Y..X; bzr ci -m 'Revert changes from X to Y'" — note the order of Y..X, i.e. a reverse cherrypick. So all the revs are still in the history, but then you add a rev that undoes the changes those revs make. [06:08] Not sure if that suits your needs or not. [06:09] Hm, is bzr going to track cherrypicking in the future? [06:10] anteru: hopefully, but we're unlikely to work on that in the near future :( [06:10] Stuff like co-located branches are higher on Canonical's todo list... but patches are always welcome ;) [06:10] Ok. I often cherry-pick something before merging the rest of the branch later on, didn't notice that yet. [06:11] spiv: I'll look again at contributing to bzr when I'm back at home, ~ 2 months. [06:12] The use case I'm running into is that I do some quick fix on a feature branch, and I want to move that fix immedialtey back to my trunk, and merge the rest of the feature later. [06:12] In practice cherrypicking often works out ok, because although bzr doesn't track them, it does avoid reporting a conflict when you merge two branches that appear to have independently made an indentical change. [06:12] s/indentical/identical/ [06:12] Ah ok. Colocated-branches is branches svn:external? [06:12] Args: Colocated branches are the svn:external equivalent? [06:13] No, colocated branches is having a single working tree that can contain multiple branches that you can 'bzr switch' between. [06:14] Similar to what git does? [06:14] Right. [06:14] Ah ok. All the DVCS are so similar now, it's just a question until they converge to a common feature set ... [06:14] There's a bzr-colo plugin already, but there's some progress towards making it a polished feature of core bzr. [06:15] Sounds useful for some of the C++ stuff I do, as I won't need to have several build trees. [06:16] Right. [06:17] You can already have a single working tree for multiple branches in bzr, but it's a bit more effort to set up and use than we'd like. [06:18] (Make a shared repo of tree-less branches, and have a single lightweight checkout that you 'bzr switch' between those branches, and of course create/remove/etc branches in the repo) [06:22] I can see why colocated branches are moving into core :) [06:22] :) [06:25] I really hope that some more high-profile projects finally pick up Bzr, the amound of Fud on the intertubes is incredible. [06:25] it'd be nice if cherry picking was better supported. [06:25] if you could see the actual partial commits that have been merged.. [06:51] night [06:58] i'm using colo now [06:58] quite good so far [07:51] poolie: quick chat ? [07:52] err, hi all ! [07:52] Hi vila :) [07:52] spiv: hey ! [07:52] spiv: did I thank you for the unicode patch ? I don't think so, so THanks ! [07:53] spiv: is there a reason you didn't try to target it at 2.0/2.1 ? [07:54] vila: 2.2 was the source of the initial repot [07:54] spiv: ok [07:54] It's probably easy to backport (at least of the affected tests doesn't exist in 2.1, I'm fairly sure). [07:54] spiv: if we try to activate the testsuite during the builds in the future we may want to backport it [07:55] spiv: if you could do that that will be great [07:55] vila: your 644855-test-isolation just bounced due to a NEWS conflict, btw [07:55] yeah, a backport makes sense to me. [07:55] spiv: shudder, thanks for the heads-up [07:56] spiv: I thought about it and... forgot :-/ [07:56] spiv: I mean, I suspected that adding the first bug entry may lead to problems down the road and forgot to check [08:03] dOxxx: thanks for merging my README changes ! [08:03] dOxxx: of course I made typos :-/ I'll fix them in the 2.3 branch [08:04] hi there vila [08:08] poolie: we can't officially release 2.2.1 yet, we still miss the windows installers, and a complete bzr-proposed PPA [08:08] ok [08:10] vila: I just uploaded the last bits to bzr/proposed [08:10] Unfortunately the launchpad build farm is broken [08:11] maxb: hurrah ! === vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: spiv | Release Manager: vila | bzr 2.2.0 is officially out | bzr-2.0.6, 2.1.3, 2.2.1 and 2.3b1 need installers, aTdHvAaNnKcSe ! Some of them are already available, please test !| work on bzr: http://webapps.ubuntu.com/employment/canonical_BSE/ [08:12] maxb: does this means that *you* need to resubmit something or only that your submissions are delayed ? [08:15] Just a delay, I hope [08:16] vila: Is there anything left to do under "ping Debian maintainers" on http://wiki.bazaar.canonical.com/Releases/2.2.1 ? [08:17] maxb: hmm, I was waiting for an answer from them, but I think you proxied quite nicely so I guess we should delete this item [08:35] 'evening maxb, vila [08:36] jelmer: wow, now, *where* are you ? [08:36] jelmer: maxb, maxb: jelmer, I think you have matter to discuss and I will carefully listen :) [08:37] vila: I'm in California :-) [08:37] we do? Debian packaging? Nothing urgent if jelmer is somewhere esoteric [08:37] jelmer: cool :) [08:38] hello jelmer! [08:38] are you at a conference? [08:38] 'morning poolie! [08:38] maxb, yes, debian packaging and plugins for the PPAs needing (or not( new releases), this also can have an impact on OSX and windows installers [08:39] meh [08:39] yep, I'm at the storage conference in Santa Clara [08:39] maxb, yes, debian packaging and plugins for the PPAs needing (or not) new releases, this also can have an impact on OSX and windows installers [08:39] I can't tolerate typos in parens, no way [08:39] :D [08:42] vila: On the second point, if bzrlib has not api-bumped in 2.3, then it's purely an issue with the debian packaging metadata assuming it will [08:46] vila: proposed PPA is now complete apart from one karmic build which is still running [08:47] maxb: rock-and-roll ! Thanks a lot for all your efforts there ! [08:48] maxb: started 28 minutes ago on shipova ? [08:52] so all we need now are the windows installers and we can push for testing, which means the official release is already delayed until at least monday [08:52] I will mail the list as soon as I get feedback from Gary [08:53] that's for 2.2.1 [08:53] maxb: what's the overall status of the bzr-beta-ppa ? Already testable ? [08:56] maxb: email is perhaps the best medium for me at the moment, the connection is pretty bad here. [08:56] alternatively we can discuss it when I get back on monday [08:59] vila, re the SRU [08:59] http://doc.bazaar.canonical.com/bzr.dev/developers/releasing.html#getting-the-release-into-ubuntu [08:59] basically says subscribe the sru team [08:59] (it should say) tag it sru [09:00] and add a comment asking for it [09:00] just a comment then and "they" will now how to get the diff ? [09:01] well, you may need to get in #ubuntu-devel and nag someone to help with it [09:01] they're basically just going to pull in the new tarball or tag, i think [09:02] ok, yeah, I'd like to better understand what happens there and what is missing to make it easier and/or address the issues (or at least understand what they are) [09:03] I know it's about parallel imports but I'm unclear about what workarounds are available... or not [09:05] vila, well, i think diving in and trying to document or solve things that come up is pretty worthwhile [09:06] poolie: so, bug #636930 to start with. It already affects 'bzr (Ubuntu)' so I sould nominate it for maverick [09:06] Launchpad bug 636930 in Launchpad Bazaar Integration "Upgrading a repository fails with 'Inter1and2Helper' object has no attribute 'source_repo' (affected: 4, heat: 876)" [High,Triaged] https://launchpad.net/bugs/636930 [09:07] but there is no 'nominate' button anymore ;) so is it 'also affects distribution' or 'target to release' ? Neither it seems [09:10] both i think [09:11] poolie: well, 2.2 is already targeted, and distribution seems to be for Ubuntu (not maverick or lucid) [09:12] * poolie looks [09:13] or may be I don't have enough access to add the needed distrotask (or whatever it's named) to the 'bzr (Ubuntu)' part [09:14] I can't even change the assignee to 'ubuntu-sru'. 'no items matched "ubuntu-sru"' >-/ [09:15] so basically you want to follow https://wiki.ubuntu.com/StableReleaseUpdates#Procedure [09:15] eerk https://bugs.edge.launchpad.net/ubuntu/+source/bzr 28 New bugs ??? [09:15] though, you can't do all of that [09:16] Ok, I have a small human grabbing at my foot, time to go I think :) [09:16] you need to subscribe them, not assign them [09:16] omomom [09:16] g/l [09:16] poolie: the StableReleaseUpdates wike page still says subscribe ubuntu-sru, not tag sru [09:16] Happy weekend, everyone! [09:17] maxb: yeah but we want to tag it anyway for easier tracking for *us* [09:17] ah [09:17] you can tag it [09:17] vila, so i think: tag it, subscribe them, create a distro task, post a comment asking for an SRU [09:17] let's do that and see if they have any further feedback [09:18] vila: HAH [09:18] ok, but still, how do I 'create a distro task' ? [09:18] I have found the missing nominate button [09:18] maxb: haaa, where ? [09:18] "also affects distribution" [09:18]