[00:03] SamB: well, even if the release is 2.0, I'm happy for the verb to be 1.19. [00:04] I don't want the name of the verb to actually mislead, though :) [00:04] spiv: that's what I'm saying. there's no sense in bumping it from a nonexistant release ;-) [00:04] indeed [00:04] (And I'm happy to pay the fairly minimal cost to bump it when it misses the intended release.) [00:05] you don't want it named for a release before/after the one it debuts in ;-) [00:06] * SamB finds 2a pretty slow for just about anything involving conversion at the moment, actually ... [00:07] ... though it's extremely pathetic for it to be using more downstream than upstream during a push, which I assume your branch eliminates [00:07] hard for me to test this, though :-( [00:26] SamB: over the network conversions? [00:37] lifeless: any! [00:37] over network, local ... [00:37] if the 2a repository isn't local, that makes it worse, certainly [00:45] local should be ok [00:46] hullo again lifeless [00:46] did i see you were working on bug 375013? [00:46] Launchpad bug 375013 in bzr "Commit doesn't honor stacking invariants" [Critical,Triaged] https://launchpad.net/bugs/375013 [00:47] morning [00:49] Classic. Write a long reply to a bzr mailing list thread, only to realize in the end that if I'm going to pontificate like this, I'd better do it in a blog post instead. Bother. [00:49] "Save Draft" think about again later [00:53] which thread, just for curiousity? [00:54] poolie: GPL licencing [00:54] poolie: nothing to do with bzr [00:55] I just liked John's "moral" comment and wanted to add something [00:55] [battery, back in 60] [01:12] jam, i think explaining the gpl is good but it's not appropriate to be so flippant in the context of a business inquiry [01:14] poolie: yes [01:14] yes you agree? [01:14] poolie: I'm thinking of just untagging it from 2.0 [01:14] oh ok [01:14] poolie: [bug 375013?] [01:14] Launchpad bug 375013 in bzr "Commit doesn't honor stacking invariants" [Critical,Triaged] https://launchpad.net/bugs/375013 [01:14] right [01:15] I heavyweight checkouts will work as they push via streams [01:15] lightweight checkouts over the network are a bad idea anyway [01:16] at least as they currently exist [01:16] lightweight checkouts of stacked branches would seem to be a rare case at the best of times [01:16] well, indeed. [01:16] i think we should make them work in future [01:16] it's a reasonable thing to want [01:16] fixing commit to use streams would make them suck less hard [01:16] sure [01:16] it may require tweaking the definitions a bit [01:16] at the moment, working content local, all history remote, performs badly [01:17] so even with the bug fixed, its not a recommended way to deploy/use bzr today. [01:17] which is why I'm thinking of downgrading it to high, or even leaving it critical but untargeting from 2.0. [01:17] what do you think? [01:18] i think it might be right [01:18] [and it's not 2a specific, it fails with 1.9 if you have content in the tree] [01:25] would it be possible to detect the problem cases and just fail cleanly? [01:25] eg to ban committing in lightweight checkouts of a remote repository? [01:25] or remote stacked repository [01:26] remote isn't part of the equation [01:26] we could put a check in commit.py to say if self.branch.repository._fallback_repositories: bail() [01:27] in general i'm more comfortable downgrading a bug if it causes a traceback rather than a problem in what's recorded [01:27] yah [01:28] want to add that check, including a mention of the bug number near it, and then downgrade/untarget? [01:28] emmajane: hi, still around? [01:28] ping [01:29] just eating a cow. or myabe it's a steer. definitely it's beef though. [01:31] poolie: yes [01:59] jam, are you back at all? [02:03] poolie: I'm mostly just heading upstairs, I may be back in another hour or so [02:03] np [02:03] i was just thinking about your mail about 2.0 [02:03] poolie: about the release schedule, etc? [02:03] I'd be happy to chat with you about that later [02:04] yes, and whether this should be 2.0b1 [02:04] ok [02:04] just ping me [02:04] poolie: ping, mind if I call now? [02:08] sure [02:11] igc, ping. I'll be up for a little bit and thought I'd check to see if you were around? [02:17] hi emmajane [02:17] hey :) [02:19] Have you had a chance to play with Sphinx any more? [02:19] emmajane: a little [02:20] * emmajane nods [02:21] emmajane: you have pretty fine control over the title page for example [02:22] You can apply style sheets to sphinx pages though. [02:22] yes [02:22] I can't remember if you've got the source for what you sent me as a branch? [02:23] I htink I just remember seeing output? [02:23] emmajane: if it helps, have a look at https://launchpad.net/bzr-alldocs [02:23] thanks :) [02:23] emmajane: grab the trunk and see how it hangs together [02:24] the interesting files are en/_templates/index.html and en/_templates/layout.html [02:24] excellent. [02:24] emmajane: I'm just building the 1.18rc1 docs as we speak and tweaking that site to reference them [02:24] awesome :) [02:25] I love automatic builds of documentation. [02:25] I recognize that I need better hobbies, but it's right up there with magic tricks and ponies for me. [02:25] emmajane: well the alldocs stuff isn't automated *enough* yet but that can come post 2.0 [02:26] * emmajane nods [02:26] emmajane: e.g. still one site per langu rather than something smarter [02:26] * emmajane nods [02:26] emmajane: we do automatic (ie, live) _screenshots_ for our documentation. http://java-gnome.sourceforge.net/4.0/doc/api/org/gnome/gtk/TreeView.html :) [02:26] igc, do you have people working on translations, or is it mostly beuno jsut working on one language? [02:27] \o/ Sovereigns of Canada. :) [02:27] emmajane: no, several people working on different languages [02:27] igc, cool [02:27] emmajane: the alldocs website has been translated to French, Japanese and Russian [02:28] very nice! [02:28] emmajane: and it's messy right now - if it were done via LP translations, I'm sure we'd get many more [02:28] * emmajane grumbles. the ubuntu package of bzr is old. [02:29] igc, tough call. Docs are hard to translate. LP doesn't necessarily make it easier (we deal with this for the ubuntu docs team as well) [02:29] LP is optimized for string translation. [02:29] the User Guide != strings. :) [02:29] poolie: fwiw, the NEWS in bzr.dev has 2 'In development' headings and no 1.18 heading :-( [02:30] lifeless: c.f. our conversation at dinner a few weeks ago, see emmajane's comment above. [02:30] emmajane: right, but the wrapper site is really just a few strings. see http://doc.bazaar-vcs.org/en/ [02:30] lifeless: and yes, I realize we're working on the problem. [02:31] igc, you're right. that's not bad. [02:31] emmajane: but wrapper site aside, I know at least one person is actively working on translating the bzr docs to Japanese [02:32] * emmajane taps her keyboard and tries to decide the most elegant way of upgrading and ignoring ubuntu. [02:32] that's easy. Run Gentoo. [02:32] * AfC ducks [02:32] HAHAHAHA [02:32] you're HilARIOUS. :) [02:33] The gentoo cow is the best part about gentoo. :) [02:33] emmajane: the cool thing is, I still haven't announced the alldocs project yet so having those translations being contributed already is awesome [02:33] igc, that is cool!! [02:33] AfC: which specific comment? [02:33] emmajane: [but that also explains why I still don't run Ubuntu, and is the gist of my quick aside to Robert a moment ago. As I said, the packaging issue is being addressed. I hope it works out, because then maybe I could run a Debian distro again] [02:34] lifeless: "grumbles. the ubuntu package of bzr is old." [02:34] AfC, APT is made of win. [02:34] Gentoo is made of pain. [02:34] emmajane: [but this is otherwise off topic for #bzr, and I'm not a distro zealot] [02:35] lifeless, bzr 1.13.1 on python 2.6.2 (linux2) makes me sad. [02:35] emmajane: what release? [02:35] lifeless, jaunty. up to date. [02:35] wow [02:35] sounds about right [02:36] it was current when released [02:37] AfC: old releases of distros stagnating isnt really being worked on; rather we're aiming to have point releases for them, for critical fixes etc [02:37] so in this case, emmajane might be seeing 1.13.2 at this point. [02:38] OTOH we already do point releases when we think its important enough, so I'm not all that sure that that will change at all. [02:38] 2.0 will get packaged though, right? [02:38] yes [02:38] but getting it into jaunty is about as hard as getting 1.17 into jaunty [02:38] I only care because igc's docs are in 2a for which I need 1.16+ [02:38] which is to say, very. [02:39] emmajane: use the PPA :) [02:39] lifeless, don't you know people who can do that? ;) [02:39] emmajane: yes. The problem is that the delta is huge - 10's of thousands of lines, and SRU policy is to essentially audit that delta. [02:39] [02:39] cry [02:39] backports have no such policy [02:39] and neither do PPA's [02:39] * emmajane nods [02:40] thus the answer to 'I /need/ a newer bzr' is - use the PPA. [02:40] the major thing that is going to help here, isn't the new release schedule [02:40] lifeless: without any emotional charge whatsoever, and I do understand the engineering decisions that led the situation being the way it is (after all, inherited from Debian), [02:40] its doing less formats. [02:40] lifeless: I really suggest there is something wrong when Canonical Ltd can't tell it's Linux distro project to backport and include another Canonical project's current version. But you and poolie have heard that enough from me, so I really need to stop bothering you about it. [02:41] Yes. Because distros and packages have taught us that progress and change are both bad. :) [02:41] so, poolie and I sat down with james_w one time, he was offering to walk bzr through a SRU [02:41] emmajane: That is also a Debian inheritance. [02:41] he spoke to the RM, who vets SRU's [02:41] AfC: I think emmajane was being sarcastic :) [02:42] SRU is a TLA for "pain"? [02:42] I have to say though that I think the SRU (stable release policy) is good, and something many customers depend on. [02:42] ah, right. [02:42] in our case, we *have* regressions vs 1.13.1 at the moment [02:42] lifeless: yeah, well, it's the reason (and pretty much the only one) we migrated away from Debian in 2002, and so I'm very alert for it changing, because I'd love to go back [or, forward, if you will, to Ubuntu] [02:42] emmajane: once you get 1.16 or later, grab https://edge.launchpad.net/~ian-clatworthy/+junk/bzr-explorer-docs as well [02:42] igc, :) [02:43] there are several bugs in the bug database where users are being hurt hugely by changes we've made [02:43] corner cases, to be sure [02:43] but thats what the SRU aims to prevent. [02:43] I think it does a decent job. [02:43] lifeless: frankly, "we [know we] *have* regressions vs" is actually what's important. That's very responsible, and very cool of you. Most projects aren't that mature. [02:43] thanks :) [02:44] Hm. I need to stop writing about the weather and write about this topic instead. [02:45] lifeless: (the seed being this, then going to "... but the problem is what happens when customers running a stable release don't upgrade to the next stable release". But again, off topic) [02:45] finish your small business accounting package. Please. [02:45] igc, the 1.18 branch isn't merged back to bzr.dev yet, when we do that it will fix the headings [02:45] lifeless: got to finish my word processor first, but I'm actually starting to get excited about working on the accounts package again. I think I've figured out a way to make progress. [02:45] AfC, you're writing a word processor?! [02:45] poolie: is there anything delaying that merge-back? I'm about to be blocked on it.. [02:45] [and yes, this should be followed by a "what the fuck are you doing writing a word processor"?] [02:46] LOL [02:46] clearly you were thinking about writing a book but decided that docbook and OOo sucked so much that you'd just write your own word processor first? [02:46] Not that I'd know anything about that :) [02:46] emmajane: yak shaving FTW! [02:46] emmajane: s/docbook/LaTeX/, and yes [02:47] LOL [02:47] yummy yummy yak [02:47] afc, so "why can't Canonical tell X to do Y" has many interesting threads [02:47] there's nothing like an author trying to avoid writing a chapter. :) [02:47] one being that people may object, rightly or wrongly, to canonical making Ubuntu do what Canonical wants [02:48] poolie: I know. I'm approaching this as a management consultant, not a techie. [02:48] the short answer is that i think we should meet in the middle [02:48] (afc: http://www.amazon.com/Front-End-Drupal-Designing-Developers/dp/0137136692 is me) [02:48] poolie: (and I don't pretend to know all the factors, so this *is* interesting to me, even if we're all tired of talking about it) [02:48] if we make bugfix-only updates they should go through SRU without needing a big hammer [02:49] and if a rubber mallet is needed, canoncial will apply that with discretion [02:49] emmajane: very nice [02:49] poolie: I suspect we'll need further process changes roughly orthogonal to the release schedule changes to help cases like emmajane's. [02:50] poolie: the fundamental problem is that this isn't Cisco IOS. It's open source, and for essentially every open source project with the possible exceptions of (eg) Linux 2.4 vs 2.6 and (once upon a time) Apache 1.3 vs 2.0 [02:50] docbook is a word processor? [02:50] SamB: no, XML documentation fomat [02:50] SamB, emmajane: wait one [02:50] * emmajane finally gets the PPA installed. [02:50] AfC: you forgot! [02:50] it's also an SGML documentation format [02:51] SamB, that's old skool. [02:51] poolie: ... and for open source (and commercial software too, but no one admits it), the bug fixes are in the next version, locked up in new features. There's no difference; the new features are the bug fixes; the bug fixes are new features. [02:51] poolie: (this is one of my keynote themes) [02:51] though at this point I guess you should probably use XML even if you do want to use it with DSSSL sheets [02:51] hi SamB [02:51] lifeless: if you mean "but i don't want just bugfixes i want the new black" then yes, that needs - either good ppas or backports or whatever [02:51] sometimes I wish error messages had LESS information. [02:52] afc, i think in some ways open source is just recognizing reality there [02:52] Tracebacks scare me. [02:52] emmajane: yeah that's an interesting question too [02:52] +unexpected tracebacks [02:52] SamB: I've put some work into fast-import in recent days to make it more reliable coming up to the 2.0 release [02:52] possibly we should hide them unless the user actually wants to report a bug [02:52] afc, at the end of the road is something like tom lord's position that everyone should just maintain their own branch and cherrypick the features they want or need [02:52] poolie: I loves reporting bugs if I have a clue what bugs I'm reporting [02:52] poolie: so (and now that it's come up, this is essentially be feedback for the 6-month release thread), I am very wary of such a cycle; for all it's benefits I would suggest that the bzr hacker community will have a hard time mustering much enthusiasm to do anything on 2.stable.x instead of bzr.dev [02:53] you may be right [02:53] From a user perspective it looked like this: bzr: ERROR: exceptions.KeyError: 'Bazaar repository format 2a (needs bzr 1.16 or later)\n' (the slash n is awesome) and the lkjadjkldjlksfadjlksdfljk;asadfjl;sadfjl;sadfljk; for a long time and the error again in English. [02:53] i think it's worth a try though [02:53] !! [02:53] SamB: after all, 2.0 will undoubtedly mean more people trying to import into bzr [02:53] that's a bit poor [02:53] That's what tracebacks look like to me. :) [02:53] igc: mmm hmm [02:54] poolie: yes, thats what I mean (and my hunch is thats what most folk are asking for) [02:54] emmajane: if that's what i think it is should be saying 'unrecognized format' and no traceback [02:54] SamB: so my priorities for fast-import are: [02:54] poolie: "recognizing reality" yes, exactly. But Debian-esque release freezing and upstream evolving reality just don't seem to jive. I think that's the fundamental problem in the open source sphere currently. [02:54] i agree they're gibberish [02:54] igc: you want me to try getting that tarball importer working? [02:54] 1. make importing reliable and bug free [02:54] 2. make exporting from other tools really easy [02:54] SamB: are you on Mac OSX ? [02:54] poolie and lifeless: anyway, sorry to get into that. [02:54] poolie, It's plausible that someone tried to help me at some point and turned on tracebacks by default. [02:54] lifeless: no [02:54] why? [02:55] poolie and lifeless: but always a pleasure to talk with (and learn from) you gents. [02:55] 3. fast-export bugs [02:55] there is a bug in the python tarball module in some versions of the python Apple ship [02:55] afc, i think users will never agree 100% on what's worthwhile fixes and what's unwanted churn [02:55] they shipped a beta, if I remember the details correctly. [02:55] anyhow... [02:55] lifeless: hmm ... iirc, the script in question is written in perl [02:55] SamB: any help you can offer on making import highly reliable would be great [02:55] poolie: there's also the "corporate sysadmin" vs "developer" vs "end user". All three have radically different needs. [02:55] SamB: Pfft. SGML roolz :p [02:55] anyhow [02:56] SamB: that 'tag from ref' bug or whatever it was sounds important if git-fast-export is now producing that more reguarly [02:56] fullermd: well, I don't know if they've been updating the SGML DTDs and those are kind of important if you're going to use abbreviated forms ... [02:56] SamB: but in general, any help on bug fixing or adding tests is ultra-welcome [02:57] SamB, emmajane: I'm happy to talk to you about what I'm working on, I _have_ done up a very preliminary web page, but it's not at "I can download it and play with it myself stage" yet so I'm reluctant to talk it up too much. [02:57] SamB: Well, I don't either; I don't use Docbook. I was just making a general trol^Wcomment ;p [02:57] igc: actually, that was generated by a slightly-altered form of the tarball import script from git's contrib tree [02:57] SamB: I'll like to release bzr-fastimport 0.9 next Monday say ... [02:57] SamB, emmajane: but this isn't the place to talk about it further, so after a couple URLs if you want to chat with me about it (please do!) -> #java-gnome on irc.gimp.net [02:57] SamB: you know that bzr can import from tarballs itself? [02:57] SamB: to give some time to get it packaged into karmic, etc. [02:57] lifeless: it's nice to just set it loose on a bunch of 'em, though ... [02:58] SamB, emmajane: general motivations http://blogs.operationaldynamics.com/andrew/#one-year-and-more and what isn't linked to from there because I'm not promoting it anytime soon is http://research.operationaldynamics.com/projects/quill/ [02:59] afc, that's nice [03:00] i've always thought the thing about 'a man's reach exceed his grasp' is especially relevant to software or similar creations [03:01] lifeless: oh, also this fast-import thing gets the datestamps right on the commits, I think ... [03:02] that is, it takes them from the tarballs [03:02] SamB: thats a fairly esoteric definition of 'right' ;) [03:02] yeah ;-P [03:03] poolie: it's been a fascinating couple of weeks, because I met a poet who understands (well, almost) what open source is. Really great discussions. [03:03] igc: so ... if I were going to send you a modified version of a git contrib/ script to include, where should I put it? [03:03] oh, exporters [03:03] :-) [03:04] poolie, where would the traceback stuff be turned off/on? I don't see anything in bazaar.conf [03:04] hmm ... is there some easy way to import a single file's history from another branch? [03:04] a completely unrelated branch? [03:04] emmajane: ah i might have been talking about what should happen rather than what does happen [03:05] classic major Australian isp service announcement a while ago "no email should have been lost during the upgrade" [03:05] yeah :) [03:05] poolie, ahhhh [03:05] emmajane: we could change trace.py to not show them and only log them [03:05] poolie, that'd be lovely. [03:05] there's a flag that does the opposite, -Derror, always shows them [03:05] want to send an rfc mail? [03:05] sure. [03:06] poolie: it should be easy to configure it to behave like now, I think [03:06] I prefer not to have to dig too deep for my tracebacks [03:06] it'd be a small change to trace.py [03:06] at least, when it's a bug-type traceback [03:06] oh i see [03:06] "the version you want is newer than the version you're using" isn't a bug IMO. [03:06] we could add another flag or somethnig then you could set in bazaar.conf [03:07] * emmajane nods. Flags work. [03:07] we should make unknown formats not traceback, if they are. [03:07] yeah, that's not a bug per-se [03:07] we can render it reasonably well [03:07] just an absent feature [03:07] I'll paste the full message with the RFC. [03:08] there are kwargs involved. [03:09] so ... how would I import a file *with* it's entire history from a branch ... will that thing in that mail I saw recently do it? [03:11] Files don't have history; history has files. [03:11] fullermd: maybe that's true in the soviet union ;-P [03:12] It's also true in bzr :p [03:12] And mergitatone, for that matter... [03:20] well, *I* was speaking english [03:21] nevermind that the file in question is actually under git ;-P [03:26] poolie, RFC sent. I'm not sure that it quite captures things correctly, so feel free to tell me what my opinion is supposed to be if I got it wrong. :) [03:26] lol [03:27] * emmajane scrolls up and notes the references to oppressive regimes and figures it all fits quite nicely together. :) [03:55] poolie: is there a list of failing testids with your plugin? [03:55] nup, not up to date [03:55] i can attach it to that bug [03:55] please [03:55] many are now fixed so i'll re-run it [03:55] even a larger list would be helpful - massively reduces the window to look at [03:55] i'm tempted to do subunit-sort first, it woul rock for that kind of thing [03:55] but i won't [03:55] :) [04:07] merge back to trunk sent [04:09] poolie: new docs built and uploaded - email sent to list [04:09] * igc lunch [04:09] ok [04:09] igc my merge will incidentally fix news [04:17] * emmajane shuts down for the night. [04:23] hey poolie, still working? [04:23] night emmajane [04:23] i am [04:23] struggling to keep awake at 1:23pm :) [04:24] more seriously i would like some lunch soon.... [04:24] i was going to work this afternoon but away from email and irc [04:25] I thought bzr pack was supposed to compress/garbage-collect a repository? After running it on an old one, repo size jumps from 41mb to 54mb [04:25] Adys: it consolidates the storage to reduce roundtrips when accessing it over the VFS [04:25] Adys: there are probably some pack files in obsolete_packs that are retained in case someone's still using them [04:25] but that will be removed soon [04:25] Adys: basically you never need to run it [04:25] and what he said [04:25] jam, did you want to talk? [04:26] um, does that mean I should revert back to the old one or it doesnt matter? [04:27] it doesn't matter [04:27] Adys: its not harmful [04:27] fair enough [04:27] Adys: but its not usually helpful either - bzr will pack behind the scenes when it needs to. [04:27] see bug 304320 and bug 373539 [04:27] Launchpad bug 304320 in bzr "bzr pack should (optionally?) delete obsolete packs" [High,Confirmed] https://launchpad.net/bugs/304320 [04:27] Launchpad bug 373539 in bzr "Add a `clean` command that deletes obsolete packs and uploads" [Medium,Confirmed] https://launchpad.net/bugs/373539 [04:27] i agree it's surprising/confusing [04:29] poolie: I'm happy to chat a bit if you want [04:29] i was going to ask you about the 1.18rc1 thing [04:29] but if you prefer to head off, that's fine [04:29] i replied [04:29] at any rate i don't plan to do anything more on it before i fly so it's not urgent [04:30] unless you really want to talk [04:31] poolie: no, I just read your reply, and it fits pretty well my understanding [04:31] as far as it goes, I don't really care if we just do a 1.18 and make the big change at 2.0 [04:31] I'd prefer to make the change at 2.0 [04:31] it feels a bit more straightforward, to be honest [04:31] ok [04:32] avoids problems with debian version numbers around the version number [04:32] not to mention giving packagers warning [04:32] therefore we'll do a 1.18 in a week, and then a 2.0beta1 following that? [04:32] after the default changes [04:33] poolie: sounds ~ right, though a bit of a stepped up schedule when the next release would hit [04:33] are you thinking to get a beta out before 2.0-final? [04:33] it might be good [04:33] i think a bit of extra exposure after we change the format could be good [04:33] even if we don't think every change is finished [04:34] I'll think about it [04:34] I was hoping to see 2.0 be the next release [04:34] ok [04:34] me too [04:34] i wouldn't have a one-month beta [04:34] but we'll have to see how things are shaping up [04:34] maybe we can just do an rc, or a couple of rcs, and then see [04:34] let's see when things land [04:34] biab [04:38] poolie: 2.0 had better have spiv's branch landed, that's all I can say! [04:39] SamB: stop working cross format, and it won't matter [04:39] if you want 2a, use it [04:39] :) [04:39] jam: so ... it doesn't use VFS calls over the hpss if you're using just 2a? [04:40] SamB: yep [04:40] well, no more than the current one does, which is only edge cases IIRC [04:40] but it seems kind of dumb to have it using 95% VFS calls over the hpss like it is ... [04:41] SamB: so I optimize the cross-format conversion to be fast when you have 2 local branches or "bzr upgrade" [04:41] because cross-format over long distances didn't seem that important [04:41] jam: that's not very fast either! [04:41] if you want to upgrade, then you upgrade [04:41] SamB: it could be a *lot* slower [04:41] jam: so? [04:41] the primary issue is getting the data out of the old format [04:41] I should steal some of your RAM [04:41] about 60+% of the time [04:41] jam: that's not saying much [04:42] for me, it's at roughly ∞ anyway ... [04:42] for bzr.dev-sized repos [04:44] jam: also, you guys haven't upgraded lp:bzr yet [05:17] poolie: I think the bzr-windows team has got off to a good start - we have 22 members now [05:17] poolie: I'd like to do the same for os x [05:18] poolie: do you agree? if so, bzr-mac or bzr-os-x as the name? [05:19] poolie: once again, topic #1 will be packaging/installers, following a similar RFI/call-for-volunteers process as the Windows team [05:28] igc: I don't quite understand your mail about windows installer changes [05:28] bialix: which bit? [05:29] maybe I need some coffee first [05:29] btw, Inno can't build msi, but it definitely build one exe [05:29] item #2 is unclear for me, WDYM? [05:30] and you talk about consensus. Does there already consensus reached? [05:30] bialix: Well, if the consensus is that msi is what we want, then we need to look at how we build that [05:31] bialix: there was a fair amount I think, e.g. ... [05:31] msi is long standing wish with lowest priority as I can say [05:32]