[01:00] cjwatson: at some point I'd be interested in a blog post on how you use VCS (or would *like* to use VCS) for packaging [01:02] LaserJock: I've been meaning to do a developer video at some point [01:03] cjwatson: that would be good [01:04] cjwatson: I just haven't found a good workflow for bzr-specifically that seemed worthwhile [01:04] I'm maintaining packages with git in Debian and it seems to work ok [01:04] I'm not doing anything particularly special with bzr for packaging [01:05] I think maybe people are just looking too hard [01:05] but I'm really kind of struggling to see a lot of improvements for Universe [01:05] you don't have to [01:05] LaserJock, have you seen this? http://www.eyrie.org/~eagle/notes/debian/git.html [01:05] as I've said multiple times in that thread, if you don't like it, you can ignore it [01:05] cjwatson: well, I don't think that's exactly accurate [01:05] we don't want to have multiple methods around, it's very very confusing for new people [01:06] it is necessary [01:06] and I don't think we can just ignore it [01:06] people will continue to send patches [01:06] whatever you do [01:06] and, frankly, I have a really hard time saying that our current processes are not horrifically confusing for new people [01:06] yeah, but if some people don't take bzr branches [01:06] then that's not a cool thing [01:06] if you step back and look at them dispassionately, they're horribly complicated [01:07] and much of that is directly due to things that revision control precisely fixes [01:07] not participating in an archive-wide workflow is going to cause issues [01:07] oh, I know they're complicated [01:07] but they're largely documented [01:07] and consistent [01:07] they really aren't [01:08] there are two or three different versions of everything spread around the place [01:08] you mean like patch systems? [01:08] even just things as simple as instructions for formatting and sending patches [01:08] wow, 38K on using git [01:08] patch systems are a particular culprit, certainly, but an inherited one [01:08] right [01:09] yeah, it's not ideal, I'd agree [01:09] but just adding complexity doesn't seem to help [01:09] archive-wide workflow: I think that will sort itself out over time, and will certainly be no worse than current reality [01:09] if we're gonna move it'd be nice to just move [01:09] I ask people (who seem capable of producing them easily) for bzr branches for things, right now [01:09] but trying to leave a lot of legacy seems like a mess to document and confusing for new people [01:09] LaserJock: running two VCS systems is itself complexity :- the source package archive acts as a VCS on its own [01:10] lifeless: yeah [01:10] LaserJock: IME, real systems that involve real people tend to involve real legacy handling [01:10] so far from my experience it's much easier to drop the DVCS and just use the source package VCS [01:10] but I'm hopeful there'll be a time when that's not the case [01:10] lifeless: The thing there is that at least the archive as a VCS has a format shared between us and Debian. [01:10] bzr is not. [01:10] LaserJock: nearly all of the complexity in this space is driven by retaining that VCS as primary; I'd like to see it become a read only mirror of a better, primary vcs [e.g. bzr] eventually [01:10] wgrant: hence import work [01:11] cjwatson: As much as I love bzr, importing everything seems rather one-way. [01:11] wgrant: but hence also retaining the archive-as-VCS [01:11] wgrant: not in the slightest [01:11] LaserJock: the source package vcs has a number of serious scaling and participation problems. for instance, user assigned revision ids. [01:11] Say we maintain something in bzr that Debian maintains in git. This is not going to be uncommon. How does this work? [01:11] wgrant: its kindof-shared, but no deeper than two tailor imports of a CVS repo, when you look closely. [01:12] lifeless: I'm not saying it doesn't have problems [01:12] wgrant: what do you think MoM is, if not a massively large scale tailor for debian source :) [01:12] wgrant: regular incremental import from git to bzr. worst case, the other direction goes by patches; best case, you could probably use bzr fast-export | git fast-import to construct a matching git repository [01:12] (if you wanted to put that effort in) [01:12] note that the worst case is no worse than archive-as-VCS [01:14] * lifeless stops his rant on the VCS-design-headaches of the archive [01:14] I'd just written about three lines of rant :P [01:14] lifeless: the problem is, most people don't care :/ [01:15] people just want easy ways of uploading packages [01:15] LaserJock: we see prospective developers on #ubuntu-motu DAILY that struggle with the archive-as-VCS problems [01:15] I agree that there is likely to be some difficulty once people are sending bzr branches that some sponsors aren't interested in taking [01:15] I want those daily problems to stop happening [01:15] Archive-as-VCS does need to die. But moving to something incompatible with most of Debian seems odd. [01:15] wgrant: +1 [01:15] my suggestion there is that we develop a very simple tool that people can use to turn that bzr branch into a debdiff [01:16] cjwatson: sure, but it seems like just adding more "stuff" to the pot [01:16] wgrant: debian is Archive-as-VCS, those two goals are incompatible unless you get debian to standardise on something not Archive-as-VCS. [01:16] wgrant: only for sponsors, who by definition are more capable; and only for those people who deliberately want to avoid easier tools [01:16] err [01:16] wgrant: and that debate has been going on since, *at least* 2004. [01:16] s/wgrant/LaserJock/ sorry [01:17] lifeless: Debian seems to largely be moving to git. [01:17] wgrant: I dispute "most" [01:17] cjwatson: what happens when somebody comes into #ubuntu-motu and asks how to contribute? [01:17] wgrant: as a toolchain for managing packages, not as authoritative content. [01:17] a sizeable number of developers have moved to git, but very very many developers either use other systems (including bzr and svn) or have ignored version control altogether [01:17] cjwatson: It is a not insignificant fraction, and it is growin. [01:17] +g [01:17] we say , well you can either use this method or the other method [01:17] wgrant: I'm aware of that, but I completely dispute that that means we have to use git [01:17] wgrant: (and I would dispute 'debian' - some prominent develoeprs sure, but other ones are arguing against git continuously) [01:18] wgrant: also, svn was very popular at one point, and CVS [01:18] LaserJock: we give them a single method on a wiki page, with footnotes in case they run into problems [01:18] bzr is hardly used outside of Ubuntu, which means most people will have to learn a new VCS [01:18] many people don't know VCSs at all even [01:18] wgrant: there is a huge difference between 'many packages are maintained in an external VCS' and 'Archive-as-VCS is going' [01:18] cjwatson: I'd like to see us use bzr everywhere. But I'd like to not diverge unnecessarily from Debian. [01:18] "bzr is hardly used outside of Ubuntu" is a fallacy I'm getting tired of [01:19] I'll say, thats news to me [01:19] that's just my experience [01:19] ubuntu is our smallest user, IME. [01:19] I've seen a handful of repos from gnome [01:19] but other than that ... [01:20] * sistpoty pets good old cvs... stable as a rock, and as many features as a rock [01:20] wgrant: I also don't think our directions to new contributors would be especially improved by moving to git [01:20] it is by far the hardest of the current major contenders to learn [01:20] cjwatson: no, but it'd help them elsewhere at least [01:21] the last presentation I saw by a git user, on using git, they had a WTF moment on their second command. [01:21] in front of a lecture theatre. And this isn't unusual. [01:21] git's a lot easier for me to use than bzr, though I think bzr will be better in the end [01:21] LaserJock: IME, there are as many ways of using git as there are git users [01:21] so I don't think it would in fact help them [01:22] bzr has been better for me since somewhere around 0.7 [01:22] I'm not particularly anti-bzr or anything [01:22] but it's got some real issues when it comes to packaging, IMO [01:22] namely? [01:22] it's not svn [01:22] speed and complexity [01:22] it takes forever to do anything [01:23] and it often require a lot of commands to do anything [01:23] formats keep changing [01:23] complexity: very similar to svn for regular packaging use [01:23] every time I go to do anything I end up spending a couple hours in #bzr getting help [01:23] formats: name when bzr last broke an old format [01:23] LaserJock: No VCS that I know of has finished its formats. [01:23] I have the opposite experience to LaserJock. [01:23] LaserJock: even git has been making changes. [01:23] speed: have to say it just isn't an issue for me with packaging [01:24] lifeless: it's never been a problem for me, that's all I can say [01:24] cjwatson: The problem with formats is that one needs to be run bzr 1.somethingverylarge or one cannot read most of the repositories. [01:24] lifeless: I'd say that cvs has :P [01:24] But then again, svn broke compatibility with 1.5. [01:24] bzr seems a bit more complex than any other VCS I've used [01:24] but maybe that's just me :-) [01:24] git is as complex as you can get. [01:24] I do better with git than bzr for sure [01:25] though I don't like git [01:25] how many git commands need options to do the right thing by default, and how many bzr commands need options to do the right thing by default? [01:25] (the same goes for cvs actually; less so for svn) [01:25] sistpoty: actually, if you look - the atomic changeset UUID added is quite recent [01:25] I don't know, I rarely get bzr to do what I want [01:25] that truly amazes me [01:25] sistpoty: only a few years ago now, and I believe there was a locking improvement done too. [01:26] and end up deleting my branches and tring something else [01:26] the basic commands are trivial and almost identical to svn [01:26] lifeless: yeah, it was a bad move in the first place... I'm quite sure the one bug in cvs I saw during the last five years is from the uuid thingy *g* [01:26] sistpoty: also, back in breezy I think it was, cvs added a race condition to commit, bug is still open. [01:26] cjwatson: if the basic commands actually did what I wanted then yeah [01:26] https://bugs.edge.launchpad.net/ubuntu/+source/cvs/+bug/12230 [01:26] Launchpad bug 12230 in cvs "cvs checkout is racy, it wasn't in the past" [Medium,Confirmed] [01:26] LaserJock: they do what I want, reliably and consistently [01:27] cjwatson: I'm required to use a much larger "vocabulary" of command in bzr than any other VCS [01:27] than git? you have to be kidding me [01:27] but also, cvs is as user-friendly as a rock... a particular spikey one, to be precise [01:27] git's rather easy [01:27] git's vocabulary is outrageous [01:27] git has a nasty vocabulary, but I only need a small part of it to do what I want [01:27] bzr has a nice vocabulary, but I need to know a lot more of it than I'd like [01:28] Are you sure that you're not trying to do different things in bzr? [01:28] who knows [01:28] I can't see how anybody could find git easier. [01:28] rather than going generic here [01:28] well, every time I try things in bzr there's some problem, some bug, some great new feature I need [01:29] how about - LaserJock next time you are willing to give bzr a shot, grab myself, or james_w, and we'll give you a hand [01:29] with the version in intrepid :) [01:29] lifeless: that's precisely the problem [01:29] I do that all the time [01:29] with git I don't need to [01:29] <_MMA_> LaserJock: +1 [01:29] I need hand-holding from bzr experts/devs to use bzr [01:29] bzr makes me feel stupid [01:30] I have to say, I think you are the exception [01:30] git, for the most part, "Just Works" [01:30] this is not my experience of other developers [01:30] without wishing to denigrate your experiences [01:30] hg works somewhat too, though I have some of the same issues with it [01:30] LaserJock: That offer wasn't for you, it was for me. [01:30] LaserJock: I've never seen anybody else say that. [01:30] LaserJock: I want to understand the way you approach your problems, so I can see if there is something I can improve in bzr to fit better. [01:31] lifeless: well, I do appreciate that [01:31] and I really do believe that bzr is gonna be awesome [01:31] now I may be dumb, but I seem to have the same problems as LaserJock with bzr [01:31] cjwatson: isn't like 3 a.m. in your tz? [01:31] <_MMA_> lifeless: I have precisely that issue. Where I use Hardy for most of my development but Im told, "Its fixed in Hardy". I dont see this as acceptable. I thing the packages in the current release of Ubuntu should be bleeding-edge or backports keeps up. SOmething. [01:31] nxvl: 1:30 [01:31] <_MMA_> gah "Its fixed in Intrepid" [01:32] cjwatson: oh! not that bad [01:32] yeah, I don't to track the bleeding edge in my VCS [01:32] and funnily enough, one thing which I first thought would be a problem from me using bzr wrongly, turned out to be a bzr bug... (though I guess that's really the exception *g*) [01:32] I've never had to use anything but distro git/hg/svn [01:32] sistpoty: interesting; bzr is closer to rcs than cvs by default, have you used rcs extensively at any point? [01:32] but I'm *constantly* having to get bzr stuff from source [01:32] lifeless: nope [01:33] I have not had to use non-distro bzr for about two years [01:33] cjwatson: I was told by #bzr that I should just use bzr (and any plugins/tools) from bzr branch [01:33] sistpoty: that could be it; using a shared treeless repo w/switch might suite you better because that 'feels like cvs' pretty closely [01:34] LaserJock: that's as may be, but nevertheless many people do not and it works just fine [01:34] I find that the formats have changed and I need to upgrade branches to get bzr to work [01:34] naturally, it depends what you're doing, but for simple use ... [01:34] LaserJock: well, its not bad advice, because things do keep improving, but its certainly not mandatory - the vast bulk of bzr users are using packaged versions from their distro. [01:34] I'm the most basic of VCS users [01:34] I first learned about VCSs in Ubuntu [01:35] all current default formats work in bzr/hardy, don't they? [01:35] LaserJock: we haven't changed the default format since 1.0 [01:35] unless you're using experimental things [01:35] I'm told I don't want to use the default format [01:35] 1.0 isn't even in gutsy... [01:35] lifeless: actually I guess I (ab)used bzr to do this... :) (but then was tempted by the features, like merging, which is a very good thing imho, but just failed since I got it totally wrong) [01:35] but some latest-and-greatest [01:35] I have no idea what the default format is [01:35] LaserJock: by whom, specifically? ("#bzr" is not what I'm looking for) [01:35] this is my point [01:36] gutsy had 0.90, which can't read packs [01:36] did you come to #bzr with some particular problem, or just ask for general advice? [01:36] I'm just trying to use the thing, but I have to know things about formats and VCS guts to use bzr [01:36] you really don't. friends of mine use bzr and have no idea about such things. [01:36] git is nasty and has some of that problem too, but there's tons of Howtos around that help [01:36] cjwatson: by #bzr I generally mean bzr developers [01:37] and bzr-plugin developers [01:37] how about we be quite clear: the simplest possible use of bzr involves your system only, with a local repository [01:37] right [01:37] I do like bzr for local code [01:37] bzr init .; bzr add .; bzr commit [01:37] bzr init, bzr add, bzr commit. Can't get simpler than that. [01:38] Damn. [01:38] there is no need to know anything about formats for that [01:38] yep, that's all wonderful [01:38] cjwatson: you don't need the '.'s [01:38] well, except people tell me that I need repos [01:38] then you can push to another system, and you don't need to know anything about formats either [01:38] lifeless: distraction [01:38] and that my repos need to be some specific format [01:38] cjwatson: :P [01:38] bzr push sftp:///othersystem/... [01:38] LaserJock: "people". you're being vague again [01:38] you don't need repos [01:38] unless you are doing something specific [01:39] cjwatson: well, it's happened at least 5 times, I don't remember all who [01:39] 01:36 did you come to #bzr with some particular problem, or just ask for general advice? [01:39] usually lifeless, jelmer, and a few others [01:39] abently sometimes I talk with I think [01:39] it sounds like you were given advice that was more complicated than your needs, and I'm trying to figure out why; for example you might have asked for advice on reducing disk space for very large branches, and been pointed to repositories [01:39] mwhudson when it comes to LP related stuff [01:40] but if you just say "people" and won't explain what was going on in context at the time, it's hard to say [01:40] I usually come with "I can't branch something from LP, help?" [01:40] I am amazed that anyone would have advised a repository in that context [01:41] there is one particular case that bzr gives people grief. [01:41] well, it was helpful [01:41] the bzr-svn integration [01:41] right [01:41] hmm, maybe that's it [01:41] I primarily use bzr through bzr-svn [01:41] that *does* require a non-default format, and tends to have *very big* branches because it has ancient projects [01:41] that's a pain, I agree. that's why I was asking *what LaserJock was doing and he wouldn't tell me!* [01:41] as I very very rarely work with code that's in bzr [01:41] LaserJock: *now* you tell us, half an hour later [01:41] bzr just isn't used that much [01:42] lifeless: the other case was the ubuntu-doc repo, which had issues [01:42] and, to add to the confusion, bzr-svn support has been changing a lot over the last few releases :- and I do mean a _lot_. Fixing major memory leaks [01:42] I don't think bzr-svn problems are remotely comparable to how most people would be using bzr for Ubuntu package development [01:42] ubuntu-doc is another bzr-svn converted repo [01:42] ok, but how am I supposed to know? [01:42] this is exactly the kinds of problems [01:43] "oh, bzr is awesome except X, Y, Z" [01:43] and I'm always doing X, Y, or Z [01:43] well, is it not fairly obvious that using one revision control to work with another is likely to be a fairly difficult case? [01:43] revision control -> revision control system [01:43] and worth mentioning up-front in this kind of discussion [01:43] cjwatson: difficult yes, common and critically important, yes [01:43] sure, but worth mentioning up-front in this kind of discussion [01:43] most packages in Debian that use a VCS use SVN [01:44] bzr-svn working well will be very important [01:44] I'm going to keep battering on about this because you just had us talking for half an hour without mentioning that fact [01:44] cjwatson: I didn't know it was relevant? [01:44] should I say every plugin I have installed? [01:44] I asked several times for anything you could think of [01:44] I was told working with bzr-svn ~= working with bzr [01:45] you just said you were the most basic of users, which suggested to me that you weren't doing anything very complicated [01:45] I didn't think it was [01:45] sorry [01:45] I just bzr branch, bzr pull, etc. [01:46] FWIW, I work with many Debian projects that use svn by means of Launchpad's vcs-imports, which don't involve bzr-svn right now [01:46] but my experience is certainly not exclusively bzr-svn [01:46] I don't use vcs-imports anymore [01:46] I understand there are some plans to move Launchpad to bzr-svn, but I hope that'll involve firming it up and getting the formats to be defaults [01:47] cjwatson: I've said that bzr-svn is a bad idea for LP until its 'finished' more, including default formats supporting it etc. [01:47] I hope I'm listened too :) [01:47] in any case, as far as this phase of Ubuntu package development in Bazaar goes, interaction with other revision control systems is irrelevant [01:47] it will hopefully become relevant later [01:47] I had 4 projects that I contribute to imported into LP, and 3 of them died without saying anything [01:48] but the first phase will only support it in the kind of way you're thinking of if separate imports have already been done [01:48] so I've moved to just using bzr-svn,git-{svn,cvs} [01:48] so Ubuntu developers will not encounter this to start with; they'll be using bzr to work with bzr branches, period [01:48] cjwatson: why? [01:48] I just don't see how that's possible [01:48] because we aren't solving every problem simultaneously [01:49] if I work on packages maintained by Debichem [01:49] to start with, we're just importing package history, not a full fine-grained import from upstream with Debian branches and Ubuntu branches off those [01:49] then I need to be able to work with SVN [01:49] so it'd make sense to use bzr-svn on that [01:49] we aren't solving every problem simultaneously [01:49] the reason it has taken four years to get to this point is that we were trying to do it the perfect way [01:49] doesn't seem to me that you're solving *any* significant problems [01:49] now we are going to get it done, and fill in the perfection later [01:50] as it happens, we will be solving many significant problems [01:50] I know there are a lot of "down the road" things going on [01:50] but it's not really selling well, IMO, for the "right now" case [01:51] even just having a web-browsable archive of recent packaging history and current code for every single package in Ubuntu is a big deal [01:51] "Launchpad sucks so we'll use a VCS" doesn't really appeal all that well to a lot of people [01:52] many people don't care about history, they just want to work on stuff [01:52] people will be able to experiment with merge workflows that don't involve tossing diffs around, and figure out something better; people will be able to use multiple branches to handle work-in-progress; etc. [01:52] what on earth has this got to do with "Launchpad sucks so we'll use a VCS"? [01:52] cjwatson: you said in your emails that LP doesn't give a good view of history so bzr would be better [01:52] lifeless: btw, what does "N revisions where removed from the branch" tell me, which I get sometimes from RainCT's commits to revu-trunk as commit-mails? [01:53] (where N is usually 1) [01:53] launchpad sucking has nothing to do with using VCS [01:53] LaserJock: please quote the exact text you're talking about so that I know what you mean, because that is not familiar to me [01:54] cjwatson: I'll try. I could be wrong, but that's what I remember anyway [01:54] the second phase of the Ubuntu/Bazaar plans involve a parallel import of Debian into bzr, which will mean that everyone can use 'bzr merge' in place of merge-o-matic if they so choose [01:54] again, per-upload granularity only, but that's the only level that many people are operating on, certainly for the bulk merge [01:55] sure [01:55] I know there's a lot of stuff going on, and I like quite a bit of it [01:55] while we may not get there for intrepid+1 unfortunately, that stuff is not far off [01:55] so I really think it's offensive to say that we're not solving any significant problems [01:56] sistpoty: the rev number in bzr is done along the left-hand parents in the graph; RainCT is probably pushing to the common branch rather than using a checkout for edits on it. [01:56] cjwatson: I don't see it "right now" though, was what I was trying to say [01:56] sistpoty: which means he may have a shorter path to his new tip, because he's done (say) 2 commits, then merged trunk, committed and pushed. [01:56] cjwatson: long term I totally see it [01:57] sistpoty: but other people have done 5 or 6 commits. [01:57] but *right now* I'm trying to figure out what the advantage is for me [01:57] sistpoty: for things where a strict 'what was in mainline' doesn't matter, its completely normal [01:57] LaserJock: "right now" == before it's implemented? [01:57] I mean, sure - but I think that's sort of the trivial case [01:58] cjwatson: then why is it being talked about if it's not implemented? [01:58] * LaserJock is confused [01:58] LaserJock: is it not usually traditional to try to design things before finishing implementing them? [01:58] cjwatson: hmm, except I've not seen a lot about desgin [01:58] it's usually "trust us, we hired somebody to work on it" [01:59] hmm, I think that's the sign I should go to bed and give up [01:59] I've been talking some with james_w and it does seems exciting [01:59] this type of conversation never seems to go well, I'm afraid [01:59] May I say that I like Hardy's logout screen much more than Intrepid's? [01:59] but I'm confused as to what I'm supposed to get out of your thread [01:59] it's not my thread [02:00] lifeless: I'm not 100% sure yet that I understand it correctly what it means... give me sec, and I'll pastebin you three consequent history events [02:00] cjwatson: ok, granted you didn't start most of it, you just posted a lot [02:00] it's a discussion about the possibilities for how sponsorship could work given various proposed changes to infrastructure [02:00] cjwatson: I'm genuinely interested in how this stuff will work, how it can help me, etc. [02:01] that's why I asked for a blog post [02:01] which very shortly got derailed into people lobbing bricks about how bzr could never work for Ubuntu development [02:01] well, *never* is a long time [02:01] ;-) [02:02] I'm hopeful for the future [02:02] lifeless: http://paste.ubuntu.com/42575/ (in chronological order from top to bottom, separated by #####) [02:02] bzr is just not very easy to me, so I'm a bit nervous about it happening soon [02:03] sistpoty: that looks like RainCT pushed something, realised a mistake, so uncommitted, then pushed a fixed version [02:03] in any case, I need to go and I really wasn't looking for a fight [02:04] I'm going to try to take lifeless up on his offer [02:04] lifeless: ah, ok, thanks for the explanation :) [02:04] sistpoty: uncommit is different to 'commit the reverse' because we can't necessarily get a diff of what was uncommitted [02:05] LaserJock: ok, sorry, maybe I shouldn't have engaged in one at getting on for 2am [02:05] cjwatson: np, I learned some stuff [02:05] sistpoty: in CVS terms, its 'cvs admin -jdead 293 foo.c' [02:05] LaserJock: I certainly will be posting something about packaging in bzr at some point, although exactly which areas I'm not quite sure [02:06] sistpoty: or something like that [02:06] cjwatson: thanks [02:06] lifeless: heh, thanks [02:06] I'd like to hear from the experts :-) [02:06] BTW, if distro git is always just fine and stable forever, what's bug 250526 for? :-) [02:06] Launchpad bug 250526 in hardy-backports "please backport git-* 1.5.6 to hardy" [Wishlist,Incomplete] https://launchpad.net/bugs/250526 [02:07] cjwatson: people gotta have crack? I have no idea [02:07] well, while I was pretty much impressed by siretart merging with bzr, I doubt it's too practical for what we see in regards to universe sponsoring... [02:08] because I saw a number of merges which pretty much just grabbed the MoM output, than thinking about the merge [02:08] sistpoty: I honestly think a good deal of that is down to it being impossible to construct a unified process right now because we just don't have branches for everything [02:08] sistpoty: yeah, I worry about that too [02:08] but of course that's an educational problem, which is imo neither solved by any tool [02:08] once we have Ubuntu and Debian branches for every package, 'bzr merge' will be a much more natural thing to do [02:08] I heard a few "MoM is down, now I can't do merges" [02:09] I can attest to it being *much* easier to merge packages that way [02:09] anyway, gotta run [02:09] thanks for the discussion, it was helpful to me [02:09] cjwatson: that's not really the problem I was thinking of... it's rather the problem of "do the changes still apply" or "I have this tool, it works, though I don't know what I do, but I don't have any conflicts left" [02:09] but that's inherant to the tool in question imho [02:10] inherent? (it doesn't come from the tool used, but is educational *g [02:10] +*) [02:10] that's the opposite of inherent [02:10] independent of, perhaps [02:11] yes. that's it... /me will use only simply words from now on *g* [02:11] simple [02:11] argh [02:11] I have never found merges straightforward to sponsor by any process [02:12] *nod* [02:12] being able to use 'bzr diff -rancestor:../debian' and such can be a timesaver, but no matter what you end up diffing all over the place to try to figure out whether the change is sane [02:13] the cost-benefit ratio is significantly worse than when sponsoring ordinary patches; in terms of time, it's at least a factor of three worse [02:28] Wahoo. Looks like I missed all the fun. [02:28] Hm? There was fun? [02:36] * sistpoty heads off to bed, and then off to vacation... cya [02:36] later. === lamont` is now known as lamont === superm1|away is now known as superm1 [05:44] gooooood morning [06:25] Good morning [06:25] hi pitti [06:26] good... yes, it is morning, isn't it? [06:29] holy crap, check this out: http://googlesystem.blogspot.com/2006/03/google-browser.html [06:29] damnit [06:29] 5 secs after I post it I see it's fake. [06:30] well not exactly, I just posted the wrong link [06:31] http://googleblog.blogspot.com/ [06:34] conftest.c:19: error: 'NULL' undeclared (first use in this function) [06:34] * StevenK blinks [06:34] I could have sworn NULL is a built in ... [06:34] no, it's a #define [06:35] but it is funny to see it not defined [06:35] should be unistd.h [06:35]