| === matsubara-dinner is now known as matsubara | ||
| === kiko is now known as kiko-afk | ||
| === ursula_ is now known as Ursinha | ||
| === spiv_ is now known as spiv | ||
| tgm4883_laptop | Is there some reason that project bugs won't expire, even though the project is setup to have them expire? Like bug 151612 | 03:32 |
|---|---|---|
| ubottu | Launchpad bug 151612 in mythbuntu "Remote not supported" [Wishlist,Incomplete] https://launchpad.net/bugs/151612 | 03:32 |
| IntuitiveNipple | Is there a problem with PPA package downloads with apt? | 04:11 |
| beuno | IntuitiveNipple, there shouldn't be. What's the problem | 04:12 |
| IntuitiveNipple | not sure, but had a couple of reports today of apt-get failing to fetch packages from my PPA, and I've just tried a --reinstall of one I have and it reported "Reinstallation of r5u870-dkms is not possible, it cannot be downloaded" - I can see and grab the packages manually though | 04:13 |
| IntuitiveNipple | My PPA is "https://launchpad.net/~intuitivenipple/+archive" | 04:14 |
| beuno | IntuitiveNipple, I've used PPAs a few times today, and haven't had any problems. Could be your ISP acting u[? | 04:14 |
| beuno | *up | 04:14 |
| IntuitiveNipple | not my downloads - other people reporting it from various parts of the world. | 04:15 |
| beuno | oh, I see | 04:16 |
| beuno | hm | 04:16 |
| beuno | spm, is there anything in the logs about that ^ ? | 04:16 |
| IntuitiveNipple | Originally I put it down to non-techie user error, but I'm talking to someone on IRC now who has followed my directions and it is failing for them | 04:17 |
| beuno | IntuitiveNipple, is the problem with newly uploaded packages? | 04:19 |
| IntuitiveNipple | I don't think so - r5u870-dkms has been there since mid-August | 04:19 |
| IntuitiveNipple | let me go back to the user... It has just worked for me now | 04:20 |
| beuno | IntuitiveNipple, sure, and we'll see if there's anything odd in the logs | 04:21 |
| beuno | thanks | 04:21 |
| IntuitiveNipple | thanks | 04:21 |
| IntuitiveNipple | beuno: Here's a forum post that says the repository failed for another package in my PPA (unfortunately no details of what happened though): http://ubuntuforums.org/showpost.php?p=5832299&postcount=2 | 04:22 |
| beuno | IntuitiveNipple, that doesn't look like a PPA problem, but a problem with the package | 04:23 |
| IntuitiveNipple | hmmm | 04:24 |
| IntuitiveNipple | not the installer bit - I know about that! - the comment at the very start "the repository didn't seem to work" | 04:24 |
| beuno | IntuitiveNipple, ok. We'll see if the admins find anything odd | 04:25 |
| IntuitiveNipple | thanks. | 04:26 |
| IntuitiveNipple | This user is going to retry it in a few moments when a download has finished | 04:26 |
| beuno | IntuitiveNipple, ok, be sure to get his IP number to see if we can track it down | 04:28 |
| IntuitiveNipple | He's in Iraq - service personnel | 04:28 |
| IntuitiveNipple | It seems to have been transient - he's got it too now | 04:31 |
| beuno | ok | 04:31 |
| beuno | if there's something major going on, we'll see it in the log analysis at the end of the day | 04:31 |
| IntuitiveNipple | okay :) | 04:33 |
| Peng_ | Augh! | 04:34 |
| Peng_ | LP stopped mirroring my new bzr+http branch. :( | 04:34 |
| Peng_ | Revision not present in KnitVersionedFiles object. | 04:34 |
| spiv | jml: ^ | 04:37 |
| Peng_ | The message has already reverted to "will not mirror" even though it's making HTTP requests right now. | 04:38 |
| Peng_ | Ooh, done! | 04:39 |
| Peng_ | With bug 260219, is the fix deployed now? | 04:39 |
| ubottu | Launchpad bug 260219 in launchpad-bazaar "bzr+http branches will be completely remirrored every time the puller runs" [High,Fix committed] https://launchpad.net/bugs/260219 | 04:39 |
| mwhudson | Peng: no | 04:49 |
| Peng_ | mwhudson: But it should still successfully mirror, right? | 04:49 |
| Peng_ | mwhudson: When will it be? | 04:49 |
| mwhudson | Peng_: good question | 05:41 |
| === persia_ is now known as persia | ||
| Peng_ | Which question is good, and are there any good answers? :( | 06:39 |
| sits | Are there any launchpad admins about? | 06:51 |
| sits | If so could they unsubscribe (or deactivate or investigate the following account): | 06:52 |
| sits | https://launchpad.net/~teresadd1-0 | 06:52 |
| sits | (User is repeatedly saying they don't want emails) | 06:52 |
| spm | sits: interesting problem - chasing | 06:54 |
| persia | sits: That user is getting the mail from being a member of the Ubuntu Audio team. It's probably better just to change group membership than to disable the user. | 06:54 |
| * persia escalates to the relevant team admin, rather than needing an LP admin | 06:55 | |
| sits | persia: I know | 06:55 |
| sits | persia: or rather - I can see that the user is part of the team | 06:56 |
| sits | but I think the user REALLY wants out | 06:56 |
| sits | I don't think emailing instructions how would be wise at this point | 06:56 |
| persia | sits: Right. It's having the team admin deactivate the user from the team, rather than having an LP admin deactive the user from LP. | 06:56 |
| sits | I'm curious how the user was added to that group myself | 06:56 |
| persia | It's an open team: just a click away. | 06:57 |
| sits | oh sorry | 06:57 |
| persia | sits: No issue. I just belong to the school of the smaller hammer, carefully applied :) | 06:57 |
| sits | persia: I can unsubscribe other people from open teams... what a novel concept | 06:58 |
| sits | hmm no I can't | 06:58 |
| persia | sits: Well, team admins can do it. You can't, but you can raise awareness of an issue, and the team admins may take action. | 06:58 |
| RAOF | sits: For what it's worth, I emailed instructions a couple of days ago when she appeared on a bug I was watching. | 06:58 |
| persia | RAOF: Instructions to remove herself from the team? | 06:59 |
| spm | What's also worth considering - the same user was commenting positively on bugs about a month ago | 06:59 |
| sits | ok in that case I would definitely just unsubscribe the user | 06:59 |
| RAOF | persia: Indeed. | 06:59 |
| sits | it will save ugliness | 06:59 |
| persia | Odd. I wonder if the person behind the email address changed for some reason. | 06:59 |
| RAOF | And an explaination of where the emails are coming from, too. | 06:59 |
| sits | kid singed up with family email address? | 07:00 |
| spm | persia: that's my thinking - looks like a vaguely generic address | 07:00 |
| spm | sits: could be - but from the address used I'd be inclined to think not | 07:00 |
| persia | It does look like a generic ISP address. | 07:00 |
| persia | spm: No? I don't see how the address might influence that: isn't the sort of address one gets when having a line connected? | 07:01 |
| sits | ok thanks for your help. Hopefully the user will be unsubscribed and things will settle back down | 07:04 |
| persia | the user is being deactivated from the team now. | 07:05 |
| frk2 | hi guys | 08:18 |
| frk2 | i got a problem with merging proposed merges | 08:18 |
| jml | frk2: what's up? | 08:19 |
| frk2 | well i got a developer with his branch | 08:19 |
| frk2 | and when he proposes merging to trunk and i do mark as merged- nothing happens | 08:19 |
| jml | frk2: as in, all that happens is the web page now says 'merged'? | 08:20 |
| Odd_Bloke | frk2: I don't think Launchpad does the merging for you (yet). | 08:20 |
| Odd_Bloke | thumper's working on that, I think. | 08:20 |
| frk2 | oh really? | 08:20 |
| jml | right. | 08:20 |
| jml | the current features are there for tracking | 08:20 |
| frk2 | well that explains everything | 08:21 |
| Odd_Bloke | frk2: :D | 08:21 |
| persia | Is the converse also being implemented: that if someone performs a manual merge (using bzr merge), LP will update the branch as merged? | 08:21 |
| jml | yeah | 08:22 |
| jml | probably that before the other :) | 08:22 |
| persia | Cool. I always lose track of the status of my branches, and have to schedule branch admin time. | 08:23 |
| Odd_Bloke | jml: Do you know that that is not done? | 08:23 |
| jml | Odd_Bloke: I bet one of those words is wrong. | 08:23 |
| Odd_Bloke | s/that that/that the converse/ | 08:24 |
| jml | persia: yeah. we're talking about phasing out manual branch status management actually. | 08:24 |
| jml | persia: although we haven't made firm decisions. | 08:24 |
| Odd_Bloke | jml: What sort of timescale would that be on? | 08:24 |
| jml | Odd_Bloke: I know that the converse is not done. | 08:24 |
| frk2 | jml, so i manually merge and then push to launchpad, thats the idea - correct? sorry im new to DVCSs :) subversion convert here :P | 08:24 |
| jml | frk2: that's right. | 08:25 |
| persia | jml: Well, I do like some of it. It's nice to indicate whether something is a idea that one is playing with, something that is likely to be proposed for regular merges as the features come together, or an idea that no longer has value. | 08:25 |
| jml | frk2: or you could use a tool like pqm. | 08:25 |
| frk2 | hmm whats pqm? | 08:25 |
| jml | frk2: I'll let Odd_Bloke field that one :P | 08:25 |
| persia | I especially like being able to mark branches "Experimental" when they are known to break stuff, to discourage merging. | 08:25 |
| spm | jml: you wimp! :-P | 08:25 |
| jml | persia: experimental is probably the one with the greatest value, imo | 08:26 |
| Odd_Bloke | So, PQM is a robot that does merging for you. | 08:26 |
| Odd_Bloke | Patch Queue Manager, BTW. | 08:26 |
| jml | persia: 'abandoned' is generally fairly well represented by just 'not touched in a while'. | 08:26 |
| persia | jml: Abandoned has a lot of value too, I think. New/Development is tricky to determine, and Merged ought be done based on tree comparisons. | 08:27 |
| Odd_Bloke | It can also do nice stuff like: 'merge', 'run tests', 'if tests successful, push to public location'. | 08:27 |
| jml | persia: well 'new' should not be a status at all. | 08:27 |
| jml | persia: we already have a hojillion ways of telling how recent a thing is :) | 08:27 |
| Odd_Bloke | jml: I dunno, a lot of my PQM branches from over the summer haven't been touched in a while but are just waiting to be merged. | 08:27 |
| jml | Odd_Bloke: :( | 08:27 |
| frk2 | so pqm submits to a pqm service? | 08:28 |
| persia | jml: See, I disagree. While it's a slightly different case, I've a package in Ubuntu that I last uploaded on 10th May 2007. I haven't touched it since, because it works, and there's only one bug (related to the ogre model, and not easily soluable). Just beacuse I've not touched it in 16 months doesn't mean I won't touch it tomorrow if someone files a bug. | 08:28 |
| persia | Err. I disagree about "Abandoned". I agree about "New". | 08:28 |
| jml | persia: ahh, that's an interesting case. | 08:28 |
| jml | persia: out of curiosity, is the branch bound to a series? | 08:28 |
| frk2 | jml, i'll just merge manually :) | 08:29 |
| persia | Also, sometimes I'll abandon something after only a couple days, because I've talked with others, and the path I was taking was entirely wrong. | 08:29 |
| jml | frk2: probably easiest :) | 08:29 |
| Odd_Bloke | frk2: You submit a branch to PQM. It then merges that branch into your trunk and runs whatever integration tests you want (if any). If these are successful, it pushes it to a public location. | 08:29 |
| frk2 | yeah, and i can test the code too | 08:29 |
| persia | jml: I doubt it. I'm a reluctant VCS user at best, so just occasionally push updates to others branches when they want to receive patches that way. | 08:29 |
| Odd_Bloke | frk2: Having first set up a PQM instance somewhere. | 08:29 |
| Odd_Bloke | jml: Does Launchpad allow there to be more than one branch which merges could be Merged into? | 08:30 |
| jml | Odd_Bloke: yes. | 08:30 |
| jml | Odd_Bloke: technically, any branch can be merged into any other branch. | 08:30 |
| Odd_Bloke | jml: Sure, but you wouldn't want 'Merged' to be based on that. | 08:31 |
| jml | Odd_Bloke: oh right. | 08:31 |
| Odd_Bloke | Sorry, should have quoted first time 'round too. | 08:31 |
| jml | Odd_Bloke: I'd probably say 'Merged' should mean 'merged into dev focus (aka trunk)' or 'merged into a series branch' | 08:32 |
| jml | Odd_Bloke: alternatively, if it's been merged into all the branches for which it has merge proposals. | 08:32 |
| jml | Odd_Bloke: not sure which of those approaches I like best. | 08:33 |
| Odd_Bloke | jml: How would that fit the model of a project (like the kernel or, maybe, Django) where you have 'foo-dev-1', 'foo-dev-2' and 'foo-dev-3' which should be merged into 'foo-integration' which will eventually be merged into the dev focus? | 08:33 |
| jml | persia: so, my theory wrt your "18 months untouched" branch had been that branches like that are generally already marked as special in some way | 08:34 |
| frk2 | thanks guys!!!! back to work! | 08:34 |
| jml | Odd_Bloke: you can still mark them manually | 08:34 |
| persia | jml: Yeah, that's not actually in VCS, but it would be considered trunk. | 08:34 |
| jml | persia: right. | 08:34 |
| Odd_Bloke | jml: Sorry, I'm still talking in terms of 'Merged' auto-detection. | 08:35 |
| jml | Odd_Bloke: I don't think Launchpad should try guessing what the status should be in that case. | 08:35 |
| Odd_Bloke | (in the context of the speculative mention of removing manual management) | 08:35 |
| jml | Odd_Bloke: ahh | 08:35 |
| persia | jml: So you assert that "Abandoned" is covered by time-since-last-push and not being trunk? What about the case where one abandons quickly, as one has started down the wrong path? | 08:35 |
| jml | persia: do you think there's much benefit in marking such a branch as Abandoned? | 08:36 |
| jml | persia: to yourself or others? | 08:36 |
| jml | Odd_Bloke: so, I think that "Merged" as a status is actually too ambiguous for precisely that reason | 08:36 |
| Odd_Bloke | Yeah. | 08:37 |
| jml | Odd_Bloke: it immediately raises the question "merged where?" | 08:37 |
| persia | jml: Certainly, especially as more activity becomes seen as branches. It removes it from my list of active branches, which helps me to sort out what I'm actually working on. It also tells others that it's not worth looking there if they want to experiment with other's work-in-progress (not merging to trunk). | 08:38 |
| Odd_Bloke | Yeah, perhaps a 'Done' status with something more to clarify how would work. | 08:38 |
| frk2 | jml, can i 'un-merge' | 08:38 |
| frk2 | or thats revert? | 08:38 |
| Odd_Bloke | Which could be "Merged to x" or "Abandoned". | 08:38 |
| jml | frk2: depends if you've committed already | 08:38 |
| frk2 | i have | 08:38 |
| jml | frk2: if you haven't, 'bzr revert'. if you have, 'bzr uncommit' | 08:38 |
| frk2 | cool | 08:39 |
| frk2 | works :) | 08:39 |
| frk2 | bazaar kicks ass | 08:39 |
| jml | frk2: and then possibly 'bzr revert' -- depending on what you want to do. | 08:39 |
| jml | frk2: that it does :) | 08:39 |
| jml | persia: why not just delete it? | 08:39 |
| persia | jml: to avoid rewriting history? | 08:40 |
| * persia doesn't generally like the concept of "delete". | 08:40 | |
| jml | persia: fair enough. | 08:40 |
| jml | persia: this is interesting. | 08:40 |
| persia | jml: I'm not suggesting to remove "delete", as it's useful when one accidentally pushes one's private data, but I don't think it ought be the default workflow. | 08:41 |
| jml | *nod* | 08:41 |
| persia | Also, just because I decide some idea isn't worth pursuing doesn't mean someone else won't want to do it. Assuming some later interface that allows for easy searching of all branches (perhaps just hints to google codesearch), having abandoned branches show (clearly labeled as such) may even be a god thing towards reduced duplication of effort. | 08:42 |
| jml | perhaps. | 08:43 |
| * jml thinks | 08:45 | |
| jml | there definitely should be a way to say explicitly that a branch is uninteresting. | 08:48 |
| jml | and if Launchpad also detects that a branch is uninteresting (no one has touched it, not trunk, not a release branch etc) then care needs to be taken to make sure it plays nice with explicit status stuff. | 08:49 |
| jml | I sometimes wonder if experimental could be just as conveniently expressed with well-chosen names. | 08:50 |
| persia | I don't think so, because something could stop being experimental, but you'd want to have a static branch name. | 08:51 |
| jml | persia: well, no one should have been using it before then, right? | 08:51 |
| jml | persia: it's experimental after all;) | 08:51 |
| persia | jml: Except the other people with whom I'm collaborating to make it not so experimental. | 08:51 |
| jml | persia: surely there's no better way to celebrate a successful experiment than a round of jovial renaming and cake? | 08:52 |
| persia | Also, since one can subscribe to a branch, it becomes interesting to see status changes: consider a project leader who wants to know when various features might be ready to review for trunk. | 08:52 |
| spiv | If there's active collaboration, then it's safe to say it's an "interesting" branch for the purposes of browsing branches via LP's UI. | 08:52 |
| persia | Sure, but just being interesting doesn't mean that it's suitable for consideration by those using trunk. | 08:53 |
| jml | persia: merge proposals cover that case, I think. | 08:53 |
| spiv | Why would someone think it is? | 08:53 |
| persia | jml: Only if you assume a push-only model. What about several teams working on stuff who want to occasionally pull from each other to avoid collisions, yet none are ready for trunk? | 08:54 |
| spiv | I'd tell the teams to keep separate branches for "ready" and "not ready" work. | 08:54 |
| persia | Or just someone who's working on something, and wants to pull some (possibly incomplete) feature from someone else to avoid duplication of work, and won't be pushing to trunk until the feature on which they depend has gone? | 08:55 |
| spiv | Which they probably will tend to do anyway (it's easier to work from a stable base). | 08:55 |
| jml | persia: I think I've missed a link of your thoughts | 08:55 |
| persia | OK. I'll try again. Imagine the following model: | 08:55 |
| persia | There is some trunk. There are *lots* of developers. Some developers are working on things that are known to break trunk. | 08:56 |
| persia | These are the three cases where "Experimental" vs. "Development" are useful: | 08:56 |
| spiv | I think my basic assumption is that people *don't* merge unfamiliar branches without first finding out some things about them. | 08:56 |
| persia | 1) A project leader wants to know when a given feature is ready for discussion, and can subscribe to the branch for that feature. | 08:57 |
| persia | 2) One developer wants to work on something that depends on an experimental feature another developer is working on: their work shouldn't be considered for trunk until the feature on which they depend is no longer experimental | 08:58 |
| persia | 3) A developer is working on something with a bound branch. As they get closer to the goal, they want to be able to mark it as ready for others to test (but perhaps not ready for merge), without needing to branch it again. | 08:58 |
| jml | persia: ok | 08:59 |
| jml | persia: why don't merge proposals meet the cases described in 1 and 2? | 08:59 |
| jml | (btw this is a very helpful discussion for me, thank you) | 09:00 |
| persia | spiv: I question that assumption. For Ubuntu maintenance, people often pull changes from other distros (Debian, Fedora, SuSE, Gentoo), and test them locally. While there is often communication directly with upstream, or with Debian, it is considerably more rare for Fedora, SuSE, Gentoo, etc. In these cases, it's mostly pulling a solution, testing it, and maybe applying it. | 09:00 |
| persia | I don't see any reason why a sufficiently large group of developers on a sufficiently large project wouldn't do the same thing. | 09:01 |
| spiv | persia: right, but in those cases you know something about the source. | 09:01 |
| persia | It's generally more efficient to look for an existing solution than to create a new one, and once a team gets large enough (>Dunbar's number), and distributed enough, communications lag can cause issues. | 09:01 |
| jml | I would hope that branch whiteboards would get used more often in those circumstances | 09:02 |
| jml | although that's nearly orthogonal to explicit statuses. | 09:02 |
| spiv | persia: it's "ah, debian has packaged a newer version" or "I want to synchronise my packaging to be up to date with what's happened in debian testing", or there's some other explicit reason *why* the merge was done. | 09:03 |
| persia | spiv: Right. Let's assume you trust me to do cool stuff. Wouldn't it be handy if you could see which of my branches I thought were pretty good, which were not for general use, and which were not useful when you wanted to pick a patch from me? | 09:03 |
| jml | I asked my question first guys :) | 09:03 |
| persia | spiv: No. Ignore Debian. Consider Fedora, SuSE, Gentoo. It's about getting patches to add features or fix bugs. | 09:03 |
| persia | jml: I suppose I could use a whiteboard, but that takes longer than clicking a button, and doesn't summarise well in a long list. | 09:04 |
| spiv | Right, so it's "get bug fixes made by Gentoo", then. It still strikes me as a different case to finding a branch I know *nothing* about and just merging it. | 09:04 |
| jml | <jml> persia: why don't merge proposals meet the cases described in 1 and 2? | 09:04 |
| persia | spiv: That's not what I'm saying: I'm talking about merging from a branch where you don't have non-VCS communication with the branch author. You might know the code, but given the volume of branches for a given author, you may want to only pick the good ones. | 09:05 |
| spiv | persia: so finding out "pretty good" vs. "not for general use" vs. "not useful" doesn't seem like something a single "Experimental" status can communicate :) | 09:05 |
| jml | persia, spiv: all of this is making me think that bzr's launchpad plugin needs to grow more features. | 09:05 |
| persia | jml: for 1, because just because something is ready for testing doesn't mean it's ready for merge, especially for a project on which lots of other projects depend (e.g. gcc). For 2) it's a pull merge. The second developer needs to know when the first developer thinks it won't break stuff in order to guide timeline planning. | 09:06 |
| persia | spiv: I want three statuses: "Experimental", "Development", "Abandoned". | 09:06 |
| spiv | persia: ideally the fact that Fred's changes in branch X have been accepted into Gentoo would tell you that branch X is good, rather than hoping that Fred is keeping his statuses up to date. | 09:06 |
| persia | I think "New" and "Merged" should be automatic, but don't want to lose the existing manual feature. | 09:07 |
| spiv | Especially if you aren't in direct contact with Fred to check that they are. | 09:07 |
| spiv | jml: I agree that more features for that plugin would be very good. I'd love to do all my LP branch management from a command line. | 09:08 |
| persia | spiv: Not really. We might have a different model for that infrastructure than Gentoo, and Fred's patch could completely break it for Ubuntu. The point is that I'll want to look at the set of patches from a likely OK source (e.g. Gentoo), even though I'm not in communication. I don't expect that Gentoo will send merge requests. | 09:08 |
| spiv | persia: If we can't find a better way than explicit statuses, then I agree they would be ok. But I think we should be trying to find ways to make this stuff totally automatic and effort-free. | 09:09 |
| persia | Let's assume for this that Gentoo is also using LP for VCS hosting. I'll be looking at the Gentoo dev team branches. It would be nice to see which ones are "Experimental" or "Abandoned" to reduce the search and review time. | 09:09 |
| spiv | Right, but if Fred's patch for Gentoo breaks Ubuntu, Fred isn't going to know that or tag his branch with that info. | 09:09 |
| spiv | So at some point you need to inspect the changes. So the question is how much of that inspection effort can be automated. | 09:10 |
| persia | spiv: I understand the desire for automation, but I think it's better not to dispose of useful features just because it's easier. If you default to "Development", only people who use it would ever have to know it's there. | 09:10 |
| persia | spiv: Yes, but if Fred's patch is expected to break Gentoo, it's not likely worth me reviewing it for Ubuntu. | 09:11 |
| persia | (Yes, it might be a good patch for Ubuntu, but it's more likely to not be) | 09:11 |
| spiv | Right. | 09:11 |
| spiv | So that is an interesting use case. | 09:11 |
| jml | persia: we should totally default to Development. | 09:12 |
| * jml always thinks of that as 'vanilla' | 09:12 | |
| persia | jml: Absolutely. That means that people who don't have a need for "Experimental" or "Abandoned" won't use them. | 09:12 |
| spiv | I'd think that merge proposals would model that ok though -- if Fred's branch isn't proposed for merging into Gentoo, it probably isn't ready yet. | 09:12 |
| spiv | i.e. if you're looking for interesting new work being done by Gentoo, start by browsing their merge proposals. | 09:13 |
| spiv | jml: +1 for defaulting to Development :) | 09:13 |
| persia | spiv: So rather than going to https://code.launchpad.net/foo-plugins to see the patches, you'd suggest I check each similar project, review which branches might be merge candidates, and build a list for review that way? How is this easier? | 09:13 |
| spiv | Well, more broadly speaking, view all branches proposed for merging into anything. | 09:14 |
| persia | OK. How do I sort the branches for e.g. Fedora (likely fairly safe) vs. the branches for e.g Arch (likely have some issue or they would have been requested for merge into Ubuntu)? | 09:14 |
| spiv | Ideally LP should have a single page per project to show you that, if that would be useful. | 09:14 |
| spiv | And I'd imagine that page would give you the usual nice table, with the clickable column headings that sort the table however you like. | 09:15 |
| * jml hugs bzr-removable | 09:15 | |
| persia | I guess. I have a single page per project that shows me a reasonably good overview now. If there's a better page, I could see giving up the current page, but I don't want to give up the current page because a better page might be possible. | 09:15 |
| spiv | If "is proposed for merging somewhere" signifies someting important, I don't see why that attribute couldn't be highlighted on the front page. | 09:16 |
| spiv | In much the same way as "Status" is now. | 09:16 |
| persia | spiv: I agree. I think it needs significant review. I'd prefer to either have parallel pages, or show both pieces of information for a while to see which works better. | 09:17 |
| spiv | Except rather than "Status" being a simple list you manually fill out from a drop-down, it's an automatically derived thing that Launchpad shows based on what's actually happening to the branch. | 09:17 |
| jml | ok. now I really really want to do some plugin hacking. | 09:17 |
| persia | spiv: Just as a thought exercise, let's go through indication markers for each of the statuses with merge requests. | 09:18 |
| * persia will have to leave in 10 minutes | 09:18 | |
| persia | spiv: How do we represent a developer indicating that the branch is useless, and should be ignored (Aboandoned)? | 09:19 |
| spiv | That's basically my wish: that with all the information Launchpad has about a branch (changes in it, it getting merged into other branches, proposals to merge it, bugs linked to it, people viewing it, people downloading it, etc), that I shouldn't have to then manually tell Launchpad what its status is, except maybe in exceptional circumstances. | 09:19 |
| persia | Oh, I agree with that. I'm only talking about exceptional circumstances :) | 09:19 |
| spiv | I'd be ok with an explicit Abandoned state, but I also wouldn't expect it to be used very often. | 09:20 |
| persia | Right. That matches my thoughts. | 09:20 |
| persia | How do we represent the case that a branch may break things, and shouldn't be used as a basis for others work? | 09:20 |
| spiv | Well, I really don't think there's much need to guard against that. | 09:20 |
| jml | persia: perhaps I'm cynical, but isn't that the default case? | 09:21 |
| spiv | Most breakages are really obvious. "bzr merge; make" --> BOOM, compile error... "oh, ok, I guess that branch is busted". | 09:21 |
| spiv | And again, I think merging from branches speculatively is pretty unusual. | 09:21 |
| persia | jml: Well, when I'm working on something to target trunk soon, there's no need. If I'm reimplmenting something in e.g. a different programming language, there's no expectation of merge *anytime* soon. | 09:22 |
| spiv | Perhaps important enough that we need to think about how to make it smoother, but still unusual. | 09:22 |
| spiv | I have enough trouble keeping up with branches I have reason to be interested in :) | 09:22 |
| persia | spiv: I disagree. I see it a lot in some teams: where team members track each others' branches, and grab interesting bits. Mostly for teams that don't have commit to trunk, and want to collaborate on a merge proposal. | 09:23 |
| spiv | Right, but that's not the same: that's watching a team's work. | 09:23 |
| spiv | You have other information to help you out there; you're probably lurking on a relevant mailing list, for instance. | 09:23 |
| persia | Heh. Some of these folk need to be prodded to read ML traffic :) This is the new immediate age: mail takes too long. | 09:24 |
| spiv | It's not "hey there's a branch I've never seen and know nothing about, let's see if it makes my system explode." I just don't understand how that would ever be productive :) | 09:24 |
| spiv | "Hey there's a branch that touches feature X that I care about"... sure, I can see why you'd try that out. | 09:25 |
| spiv | But not totally arbitrary, where the only thing you know about a branch is it's URL. | 09:25 |
| persia | Oh. I do it all the time with patches to fix bugs in Ubuntu. If there's a bug that I want to fix, and I don't have a solution, I'll google for every bugtracker, patch, blog entry, etc. I can find, and try one or more patches to see if they work. | 09:25 |
| persia | I can read the code, so I understand when it's roughly right, but I don't necessarily know the source. | 09:25 |
| persia | s/source/source of the patch/ | 09:26 |
| jml | persia: so, if you came across one of these patches and saw the word "Experimental" on it, would that change your behaviour? | 09:27 |
| persia | If I assume that LP imports or hosts all interesting branches everywhere, that becomes simpler, but status tagging is helpful. | 09:27 |
| persia | jml: Yep. I don't pull from Fedora development or Debian Experimental unless I have some assurance that it's the right solution. My common initial trolling points are Fedora released and Debian unstable. | 09:28 |
| jml | interesting. | 09:28 |
| spiv | So, if the branch didn't come from the official upstream branch, it might not be good enough quality for inclusion even if it appears to fix the relevant bug. | 09:28 |
| spiv | Or from some other blessed source. | 09:28 |
| persia | spiv: Rather, it's about optimising my patch review path. I start with things known to be more stable, and then look for things that might be less stable. | 09:29 |
| spiv | So you're saying there are sources that are sometimes blessed and sometimes not, and you need them to be explicitly marked to know which is which? | 09:29 |
| spiv | Ok. | 09:29 |
| persia | If someone specifically indicates that something is known unstable (e.g. Debian Experimental), it's not likely a good place to start. | 09:29 |
| spiv | So, how I'd imagine this would go, is rather than scanning all branches first, | 09:29 |
| spiv | I'd scan the *release* branches of Debian, Fedora, etc first, to see if they have a fix. | 09:30 |
| * jml has to go. | 09:30 | |
| spiv | And only if that search fails to find something would I look further afield. | 09:30 |
| persia | Well, rather that I'd like to have some indication if someone things their branch isn't ready. I'm not that hung up on "official" sources. | 09:30 |
| jml | g'night gentlemen. | 09:30 |
| * persia has to go too. Let's continue another time. | 09:30 | |
| spiv | jml: g'night | 09:30 |
| spiv | persia: so I think searching for a fix can be done better :) | 09:31 |
| spiv | persia: let's continue another time :) | 09:31 |
| spiv | persia: thanks for the patient discussion! | 09:31 |
| === Ng_ is now known as Ng | ||
| * wgrant wonders if CVE stuff is ever going to be touched again, or if he'll end up working on it when LP does eventually become Free. | 10:27 | |
| === Nafallo_ is now known as Nafallo | ||
| === bac_afk is now known as bac | ||
| === salgado-afk is now known as salgado | ||
| === nebi is now known as nebi|away | ||
| === nebi|away is now known as nebi | ||
| === warp10_ is now known as warp10 | ||
| === nebi is now known as nebi|away | ||
| === nebi|away is now known as nebi | ||
| === bac is now known as bac_breakfast | ||
| === nebi is now known as nebi|away | ||
| === mrevell is now known as mrevell-lunch | ||
| === bac_breakfast is now known as bac | ||
| === nebi|away is now known as nebi | ||
| === bac is now known as bac_standup | ||
| jcastro | barry: one more team list to unmangle: ~ubuntuforums-unanswered | 14:38 |
| barry | jcastro: done | 14:39 |
| jcastro | thanks! | 14:39 |
| elmo | ubuntuwhatnow? | 14:45 |
| === bac_standup is now known as bac | ||
| Hobbsee | elmo: long form of ubuntucrack. | 14:47 |
| wgrant | That sounds about right. | 14:48 |
| === ursula_ is now known as Ursinha | ||
| === mrevell-lunch is now known as mrevell | ||
| === Verterok is now known as Verterok|out | ||
| andrea-bs | mrevell: I think that this FAQ should be updated: https://answers.launchpad.net/launchpad/+faq/39 | 16:20 |
| * mrevell looks | 16:20 | |
| mrevell | andrea-bs: Absolutely. I agree. I'll update that in the next few minutes. Thanks. | 16:20 |
| === Verterok|out is now known as Verterok | ||
| === matsubara is now known as matsubara-lunch | ||
| === jkakar_ is now known as jkakar | ||
| === ursula_ is now known as Ursinha | ||
| === bac is now known as bac_lunch | ||
| === salgado is now known as salgado-lunch | ||
| === matsubara-lunch is now known as matsubara | ||
| NCommander | beuno_, hola | 17:25 |
| === bac_lunch is now known as bac | ||
| === salgado-lunch is now known as salgado | ||
| === nebi is now known as nebi|away | ||
| === nebi|away is now known as nebi | ||
| === andreas__ is now known as ahasenack | ||
| === Verterok is now known as Verterok|out | ||
| === bac is now known as bac_bbiab | ||
| === warp10_ is now known as warp10 | ||
| === bac_bbiab is now known as bac | ||
| === Verterok|out is now known as Verterok | ||
| === nebi is now known as nebi|away | ||
| === nebi|away is now known as nebi | ||
| === mikrox is now known as mikro | ||
| === bac is now known as bac_afk | ||
| === nebi is now known as nebi|away | ||
| === nebi|away is now known as nebi | ||
| === thumper_laptop is now known as thumper | ||
| === salgado is now known as salgado-afk | ||
| RainCT | Hi. Where is the option to change a project name gone? :P | 22:38 |
| beuno_ | RainCT, there should be a yellow edit button next to the title | 22:38 |
| === beuno_ is now known as beuno | ||
| RainCT | beuno: there's the "Edit details" but it only allows to change the "Display Name" and the "Title" | 22:39 |
| RainCT | ie, not the name used in the URL | 22:39 |
| RainCT | (or could it never be changed?) | 22:39 |
| beuno | RainCT, you can't edit the name used in the URL | 22:39 |
| beuno | you have to poke kiko-afk or Rinchen about it | 22:39 |
| beuno | or, file question requesting it | 22:39 |
| RainCT | ah, then I may have dreamed that there was an option for it :P | 22:39 |
| RainCT | OK, thanks :) | 22:39 |
| beuno | np :) | 22:40 |
| Rinchen | ouch | 22:40 |
| Rinchen | someone poke? | 22:40 |
| RainCT | Rinchen: Don't worry :). I wanted to change a provisional project name to another provisional name, but if that has to be done manually I'll wait until I have a real name for it :P | 22:42 |
| Rinchen | RainCT, yes it's manual at the moment. But an easy manual | 22:43 |
| RainCT | Anyway, don't worry about it for now :). | 22:45 |
| * RainCT goes to bed, good night | 22:46 | |
| === fta_ is now known as fta | ||
| tuxxy__ | im having trouble with my mailing lsit if anyones around? | 23:51 |
| beuno | tuxxy__, sure, what seems to be the problem? | 23:55 |
| tuxxy__ | hi beuno, well it seems I cannot send out mail to my own mailing list, yet team members can send to it successfully, I have tried from two different e-mail providers also and every time no one receives the mails, not even me heh | 23:56 |
| tuxxy__ | I receive e-mails sent to the list by anyone else but I cannot send them | 23:57 |
| tuxxy__ | https://lists.launchpad.net/64-bit/ | 23:58 |
| tuxxy__ | as you can see it is working for them but not the owner | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!