[07:00] doko_: ^^^ has bug fixes we should have in at the open. [07:22] Good morning everybody [08:08] cjwatson / ScottK: Please could you accept the maas SRU? === henrix_ is now known as henrix === doko_ is now known as doko [10:03] ... I can't say I would have accepted those before general opening, personally [10:03] They aren't important for building other packages [10:15] cjwatson: I find the lack of syntax hilighting while preparing other uploads wildly annoying, but YMMV. [10:16] cjwatson: Working on eglibc and base-files right now, which are, admittedly, a bit more crucial. [10:16] I'm happy to edit that locally temporarily. [10:16] Since usually I continue running stable for a while (although this release may be different). [10:17] I'm looking forward to britney making this the first release I'm not scared poopless about running from day 1 on my laptop. [10:17] * infinity crosses his fingers. [10:17] Yeah. I'm starting in on the LP changes now. [10:19] Hrm. If you apply the rewrite magic universally to all releases, I wonder if I should make the emacs-el bits match Debian (which only allows/hilights $release and $release-security, due to their auto-rewriting for -proposed-updates) [10:19] I was going to make it a per-DS flag. [10:19] Would make sense to just do it universally anyway, but will take some time to socialise it. [10:19] Dunno, maybe it should be on Distribution. [10:20] And I assume it won't attempt to rewrite -proposed, to people using the old method will still get the desired results. [10:20] s/to people/so people/ [10:20] Indeed. [10:20] My fingers need tea. [10:20] I guess Distribution already has a substantial assortment of random columns. [10:20] I can't see any reason why this would be a per-series flag. [10:21] Just confused to have it DTRT for some series and not all. [10:21] s/confused/confusing/ # see above, WRT tea for fingers... BRB. [10:21] I was sort of thinking of the old state of Ubuntu, where we might have liked to have it auto-rewrite for everything but the dev series. [10:21] But whatever. [10:21] wgrant: ^- any opinions? [10:22] Oh, there's that possibility, yes. Could still be a Distribution thing, but have a toggle for "don't do this for non-stable series". [10:22] Then it won't need to be twiddled as we release/open old/new series. [10:22] But rather, just be a question of setting a policy that DTRT. [10:22] It's certainly a reasonable point that we don't want to add more steps to NewReleaseCycleProcess. [10:23] Mmm [10:23] My opinion is that the whole thing is terrible :P [10:23] But [10:24] cjwatson: I think it makes more sense as a policy thing than a per-series thing. If we want stable/supported rewritten, but not devel, we don't want that to always be true, not just when we remember to set it. :) [10:25] cjwatson: (Not that I think we want that, but I see that we may in the future decide to go back that direction, or that some other mystical LP-using distro may want it that way) [10:25] It's certainly what Debian would want if they used Soyuz. [10:25] If any other distro wanted to use LP we'd have to rework the whole suite system anyway [10:26] Yeah, I guess so. Certainly in the Debian case, where there are technically two suites in development at all times. [10:30] * infinity wonders idly why we unsplit the glibc docs, rather than just pulling in the non-free package and having a dependency, and goes about reducing that massive delta. [10:31] Do we really want to rewrite post-release release to proposed? [10:31] I guess it's OK since it'll end up in Unapproved anyway [10:31] wgrant: I'm failing to see why we wouldn't? [10:31] Well [10:31] wgrant: It how I do all my uploads anyway (precise in the changelog, precise-proposed in the .changes) [10:31] LP has always done what you told it to in this respect [10:31] s/It/It's/ [10:32] Where one of the options is "fail and make you reupload" and the other is "do what you meant" [10:32] Right, and it's not so bad since it always requires approval, I suppose [10:33] Indeed. There've been basically no complaints about Debian auto-rewriting stable to proposed-updates, which has been the case for years [10:34] Hm, I'd been going with .forbid_release, but now that I come to write help strings and such I think it should be .redirect_release_uploads [10:34] Yeah, forbid_release is a bit wrong [10:35] Also, depending on where you do the rewrite you might need to think about how it impacts binary uploads [10:35] And what about copies? [10:36] Definitely must not redirect copies, because that's how we're going to do promotion from -proposed. [10:36] Might at some point consider allowing copies only to queue admin. [10:36] Right, but this sort of inconsistency has the potential to bite people [10:37] Well, syncpackage, true. [10:37] "oh I want to upload to raring... but let me go via a ppa... oh whoops copies don't redirect" [10:37] dak doesn't really have this problem since the only way mortals interact with it is via dput [10:38] I think a possibility I suggested in passing last week was to have copies redirect unless you're a queue admin and use auto_approved=True (thereby signalling that you're acting as a queue admin) [10:38] That seems even more magic [10:39] So I agree a lot of this is a fair bit of magic; I'm open to suggestions that don't involve having to re-educate every Ubuntu uploader [10:41] Well, I think most of this, if done as written above, only requires educating archive admins. Since the average uploader will just have the Right Thing happen, no? [10:41] infinity: Not for copies [10:42] Where "as written above" includes my more-magic suggestion, I think [10:42] wgrant: I was including Colin's... Yeah. [10:42] The auto_approved=True thing is far too magic [10:42] Alternative proposal which probably isn't too hard: redirect=False (or similar) [10:42] It *might* be acceptable for it to reject if auto_approved=False, but not redirect [10:43] Right [10:43] Not redirecting for normal uploaders means we have all the hassle of changing syncpackage in stable series [10:44] But all the sanity of having one less opaque boobytrap in Launchpad. [10:44] Which is then encoded in tools for years/forever [10:44] And impossible to change without disastrous consequences [10:45] So you'd actually prefer copies to behave differently from uploads? [10:45] That's kind of a boobytrap too, just a different one [10:45] It's not a boobytrap if the copy API tells you to go away when you try :) [10:45] I suppose copies are more explicit about a bunch of things [10:45] True [10:45] Right, that too [10:46] Copies rejecting and suggesting you might have wanted -proposed would be an alright compromise, but as stated, we'd need to SRU all the old releases to sync to proposed. [10:47] * infinity glares at pidgin-libnotify landing after Q released. [10:47] I guess people can use -r raring-proposed in the meantime. [10:47] Assuming that works. [10:48] Yeah, it does. [10:48] Oh, wait, that notification bubbles, not indicator integration. [10:48] The fact that you have to SRU any API change is an excellent argument for making the API not be full of boobytraps. [10:48] yeah [10:48] Because if they prove to be a problem then we can't change them later [10:48] someone is working on a patch for the indicator stuff [10:49] Laney: Good. I'm wildly miffed that when I upgraded my main machine to Q, I lost the only two consumers of the messaging menu that I care about (pidgin and gm-notify) [10:50] wgrant: Mm. True. [10:51] The reasons given for wanting the upload redirect are a) retraining developers, and b) ugly changelogs [10:51] I hardly think a) is particularly valid at all :) [10:51] And b) doesn't apply to copies [10:52] Well, we could fix (b) with end-user tools doing the rewrite, though I don't really want that hack in dpkg-genchanges. :P [10:53] Mostly, I just felt the redirect was the right DWIM thing, but that's years of Debian redirects that have trained me to expect that. [10:53] Sure, it is the right DWIM thing. [10:53] And, if the counter-proposal is just to hard reject all uploads to $series, don't we still need to consider how that affects copies, and when? [10:53] But there's a tradeoff there [10:54] The rewriting seems orthogonal to the "no uploads to $series except for copies from $series-proposed in a devel release" thing. [10:54] infinity: Indeed, that would probably need to be made explicit (or it could be folded into auto_approve; I don't have a problem with auto_approve approving extra stuff, it just must not affect a redirect) [10:57] wgrant: Well, a redirect=False on copies would work then, right? Allowing us to attempt a copy to $series, and check if we have the right perms to do so, etc? [10:58] I'm inclined to suggest that build uploads should never be redirected. [10:58] Build uploads must never be directed, indeed [10:58] That would destroy ~everything [10:59] It's possible that you can just hack the insecure policy to do it [10:59] I'm not sure if that's reasonable [11:01] Probably better than doing it in the upload processor + nascentupload (which mysteriously both construct policies independently). [11:01] Hee hee [11:01] Yeah [11:01] That code has some terrible demons lurking [11:01] With not insignificant chunks ripped straight from dak... [11:01] Build uploads wouldn't need to bypass the redirect. [11:01] They always upload to the right series. [11:02] (And why does soyuz_process_upload live under lp/soyuz anyway?) [11:03] Oh, except if it's a retry after it's been promoted, then it would build in $series, but a redirection would try to rewrite that. [11:03] Otherwise, though, buildds don't get the upload series from the changelog, but from sbuild (which gets it from buildd-master), so it should be correct. [11:04] infinity: Hmm? [11:04] wgrant: Was just talking myself through why buildds need an exception here. :P [11:04] uploadprocessor doesn't get it from the changelog either [11:04] It's normally from the Distribution field in the .changes [11:04] wgrant: uploadprocessor gets it from the changes, I assme? Or is that different for binary uploads for some reason? [11:04] wgrant: Yes, exactly. [11:04] But depending on the layer that cjwatson rewrites at... [11:05] We hopefully ignore the .changes Distribution for buildd uploads [11:05] Given that we know the build it's coming into [11:05] And by "ignore", you mean "don't rewrite". [11:05] There's a sanity check that various .changes metadata matches the build, but I forget if that's part of it [11:05] Cause binary .changes is always what we want it to be. [11:05] It should always match, indeed [11:06] But Launchpad already knows where the build is meant to go [11:06] It doesn't need to read the .changes [11:06] This isn't Debian :) [11:06] True, given that the .changes contains exactly what LP told us. [11:06] Though, that's true in Debian as well. :P [11:06] The insecure policy seems like an OK place to do this, which makes the question moot. [11:07] So we *probably* ignore the .changes Distribution, but depending on where cjwatson overrides it could impact the build-derived target suite too [11:07] But if you do it in insecure, it's fine as you say [11:08] Actually, wait. [11:08] infinity: Is that really true in Debian now? [11:08] We absolutely ignore .changes [11:08] infinity: I thought Debian buildds still just uploaded signed binaries into whatever suite and dak believed them [11:09] infinity: Why do we absolutely ignore .changes? [11:09] wgrant: Well, yes, but the buildds are getting the suite from wanna-build. So, not much different from buildd-master telling us what to build for. [11:09] Sure, but the thing in question here is how the upload processor chooses the target suite [11:10] In dak it will respect what the buildd tells it [11:10] In LP it probably won't [11:10] Do we want a log message telling the uploader about the redirect (as Debian does)? [11:10] wgrant: Oh, nevermind. I was thinking something relating to Daniel's stellar design decision to pass -dautobuild to sbuild, but I fixed that years ago. Some part of my brain is living in the past. [11:11] infinity: Heh [11:11] cjwatson: Please [11:11] cjwatson: Even better if that ends up in a convenient place in the Accepted mail somewhere [11:11] That's what I was thinking [11:11] Although I forget if the new format has a logical place for that [11:11] Not that upload policies currently have a logger, but ... [11:11] It should end up in the Accept/Hold mail anyway. [11:12] Since an upload to $foo should end up saying "Accepted in $foo-proposed" [11:12] cjwatson: there's probably a well-known logger name, like there is in buildd-manager [11:12] It can go somewhere near "Announcing to ..." [11:12] Subjects say something like [ubuntu/raring-proposed] already, don't they? [11:12] But I'd prefer an explicit log line [11:12] As the subject is easy to miss [11:12] Yeah, both are fine. [11:12] wgrant: Did I just catch you assuming logic from LP? [11:13] (AFAICT archiveuploader just passes through an explicit logger everywhere.) [11:13] Heh [11:13] Well [11:13] It's an open question which of those is more logical [11:14] Oh, bah, the notification mails are just constructed from a great big static template [11:15] PPA acceptance emails have something fairly free-form at the top [11:16] I can't remember how dissimilar the PPA template is [11:16] I could shove %(SUMMARY)s into the distro one, I suppose [11:17] But I think it fits better down below in the new format [11:17] Yeah [11:17] Since IIRC the intention was for the top bit to still be vaguely parseable, in principle [11:21] Indeed, although that matters more for announcement than acceptance [11:22] Announcements don't really need to be terribly explicit about redirects. [11:22] Exactly [11:22] It's not important for the announcement at all [11:22] And it's the announcement that was intended to be parseable [11:23] I suppose I should actually look at an acceptance mail to see just how parseable they are today [11:24] Ah [11:24] Would it be OK for this to go in an "Upload Warnings:" section? archiveuploader constructs once of those, although it doesn't currently go in distro acceptance messages. [11:24] They are more similar than I remembered. [11:24] Yeah, that sounds reasonable [11:24] Upload warnings don't spam us [11:25] I forget the full set of current warnings, though [11:25] All I can remember is the one about the lack of debian/copyright [11:26] I think that may, in fact, be the only one [11:27] Ah, PPA quota too [11:27] So yeah, seems like a reasonable place [11:28] Also urgency overrides [11:29] Hmm [11:29] But we get cronspam about those [11:29] Oh [11:29] priority overrides cronspam, urgency overrides end up in Upload Warnings [11:29] Right [11:30] Makes sense :/ [12:59] infinity: it looks like we have a small prob with the lts-quantal [12:59] infinity: we're not able to create the tracking bug because the package has never been uploaded [12:59] any chances of getting it back? :) [13:00] herton: bjf: ^^ [13:00] which was _why_ I uploaded last Friday. [13:00] i agree and why i said an 18 would be coming soon [13:00] all stable activity is predicated on the existence of the source code package [13:01] henrix, if necessary, just upload an 18 without a tracking bug [13:01] rtg: right, and makes sense. i didn't realised that we wouldn't get a tracking bug. [13:04] henrix, the other thing you can do is just create a bug by hand which will become the tracking bug for the package you upload [13:04] henrix, once it hits -proposed you can then just fix it up by hand [13:05] create it using 'linux' as the source package name, then just change it later. [13:05] bjf: hmm, ok. i guess that could be done. thanks [13:05] ack [13:07] henrix: Ahh, yeah, can't file bugs against something that doesn't exist. Not world-ending. [13:08] (Not worth QAing a -17- upload just to be able to file bugs against it, mind you, which was why I rejected it if -18- was happening today) [13:08] I could accept -17- to proposed just to make your life easier, I suppose. [13:08] infinity, it isn't going to be QA'd if we mark the tasks invalid, we just need something in the archive [13:09] bjf: Well, "need" being a bit strong. The copy will still work if the target doesn't exist. [13:09] bjf: But if you'd prefer it this way to make the bot less grumpy, it's not like burning buildd time right now will hurt. [13:09] bjf: I can accept Tim's uploads right now. [13:09] infinity, just accept rtg's upload please [13:10] bjf: infinity: ok, so i'll wait for -17 to get accepted [13:10] Sure, just give me a moment to do the NEW review. [13:11] infinity: sorry for the mess. i should have thought about that before ;) [13:11] henrix: Well, just having it in the PPA without the tracking bug (until after I copy) would have worked just fine too. [13:12] But I need to review this at one point or another anyway. [13:12] So. May as well do it now. [13:16] henrix: BTW, for my peace of mind, do you intend to generate lts-quantal using an exact copy of the .orig.tar.gz from quantal? [13:17] henrix: (Cause Tim's was built natively, which makes it a fair chunk different from Q) [13:21] infinity: we use a script debian.quantal/etc/update-from-quantal-master, which rebases the lts branch against the release repo [13:22] henrix: Branch rebasing isn't building the debian source package. I mean when you build the source package, have a linux-lts-quantal_3.5.0.orig.tar.gz in .. that is an exact copy of linux_3.5.0.orig.tar.gz from quantal. [13:22] henrix: Saves space for mirrors that use hardlinks, and also makes the two source packages much easier to audit as being related to each other. [13:23] infinity: ah, ok. we do that for the linux packages, but not for the lts [13:24] henrix: Might be nice if you started. ;) [13:24] henrix: Given that, other than some bits in Debian, they're pretty much identical and all. [13:25] infinity: ack [13:27] henrix: Just make sure the orig is an exact copy, or it'll kinda defeat the purpose. Cause if it's identical, you just saved ~100MB (per source package) for every mirror that isn't silly. And a lot more, once you factor in version bumps. [13:32] infinity, is the orig tarball name a function of the source package name ? in which case we're gonna end up with a 2nd tarball anyways, but we can still save a shitload of space for subsequent uploads. [13:32] s/is/isn't/ [13:33] rtg: Yes. [13:34] (Although a few mirrors know how to hardlink identical files.) [13:35] rtg: Yes, I specifically mentioned the hardlinking above for that reasons. [13:35] s/reasons/reason/ [13:35] rtg: Either way, as you note, it saves space in subsequent uploads, even for less bright mirrors. [13:35] ah, missed that [13:37] henrix: Oh, and if I missed mentioning it, I accepted Tim's uploads, so shankbot should be happy about creating bugs. [13:38] infinity: ack, thanks [15:06] abcde is a test case I'm running for -proposed migration [15:09] the name of the package is too generic, testme-please-ignore1 would be better.... oh wait it's a real package called "abcde" and it has nothing to do with teaching alphabet.... *sigh* abcde: A Better CD Encoder [15:10] * highvoltage always liked the name of that program [15:10] http://people.canonical.com/~ubuntu-archive/proposed-migration/ - most boring possible output :-) [15:10] you can do a lot worse, like there's an educational flashcard program called "iGNUit!" (urgh) [15:11] all I needed was something that wasn't compiled and so wasn't involved in any toolchain work; abcde happened to be first in the list from auto-sync output [15:51] I am suspecting ben the transition tracker is still pointing to quantal instead of raring http://people.canonical.com/~ubuntu-archive/transitions/ [15:51] http://people.canonical.com/~ubuntu-archive/transitions/python3.3.html has lxml at 2.3.5-1 yet it is 3.0.1-1 in raring [15:53] xnox: fixed for next run [15:53] though you could have done that yourself I think - it's ubuntu/download/archive{,_ports}.ben [15:53] yeah [15:53] I don't think it's encoded in the script that runs it [15:53] it's not [15:54] http://paste.ubuntu.com/1297805/ [15:54] we need to be making this learn about proposed [15:54] Laney: do you have access to the chroot this runs in nowadays? [15:54] no [15:54] we should get you into ~ubuntu-archive so that you do [15:55] then you can sort out the new tracker code so I don't have to :-) [15:55] I wouldn't complain [15:55] since I'm obviously failing to [15:55] there's already an RT to get ben installed on that box [15:55] I suspect it won't happen until someone pushes at it though [15:58] https://launchpad.net/ubuntu/+source/abcde/+publishinghistory - looks moderately sane [15:59] ubuntu-archive-robot will end up being blamed for a lot of stuff :) [15:59] heh [15:59] cjwatson: thanks... doh =) should have done myself. [15:59] will there be a hinting mechanism for our britney? [15:59] It shouldn't affect anything processing *-changes lists [15:59] * xnox wants new tracker =)))) [15:59] But if there are things that try to assign blame by processing the publishing history, they'll probably need to be adjusted [16:00] Laney: the code's there, and I expect we'll need it occasionally, but I was going to cross that bridge when we came to it [16:01] Laney: well manual copies are still possible to bypass britney =) [16:01] mmm [16:01] * Laney is aware of what we do to Debian's RT with Haskell. [16:01] xnox: that's not a given [16:02] cjwatson: ?! /me doesn't get it. [16:02] xnox: manual copies to bypass britney will probably not remain possible [16:02] * xnox :`( [16:02] oh well. Better be good with my uploads then. [16:02] otherwise everyone using syncpackage would bypass it [16:03] (until we modify it, but even then ...) [16:16] hmm... mk-sbuild should add -proposed to sources by default. And quantal ppa's as well?! [16:16] No! [16:16] Absolutely not! [16:17] *Don't* encourage actual users to use -proposed [16:17] A lot of people use sbuild chroots for non-buildy things ... [16:17] but buildd will build against -proposed, while locally it will build against release. [16:18] (Sorry, maybe my exclamations were a bit OTT) [16:18] well, you have a point =) [16:18] Why talk about quantal PPAs then? [16:18] buildds won't build against those ... [16:18] s/quantal/raring/ [16:18] buildds won't build against raring PPAs either [16:19] yeah, agree. Forget I ever mentioned PPAs. [16:19] but pbuilder-dist & mk-sbuild - should or shouldn't add -proposed? [16:19] OK, maybe that confused me [16:19] Arguably [16:19] for raring, while it's development release. [16:20] well always.... as it becomes SRU staging archive. [16:20] I guess at least with an option [16:20] (like --skip-updates) [16:20] opt-in then. [16:20] I could see it either way; it kind of depends on the target audience [16:21] Builds in raring PPAs probably won't use -proposed by default [16:21] Builds aimed at the primary archive might well want to be tested against -proposed [16:21] Then you get into the situation where people end up enabling -proposed on their machines to satisfy dependencies [16:22] ack. And if a developer is caught in a transition, they should know & learn about it. [16:22] We're still going to have to put effort into keeping transitions as brutally short as possible [16:23] So, yeah, disregard my "No!" above - I was out of line [16:23] I'm being a bit hair-trigger on the risk that people might start widely using -proposed [16:23] Because if they do it kind of makes a lot of this work pointless [16:23] server & X where building against -proposed this cycle. Did we have any "support" issues with enabling -proposed for those devs...? (I am guessing kernel & X developers are fairly sophisticated and do not require the #ubuntu-motu style hand-holding) [16:24] Not really, but there was so little in -proposed at any one time that it hardly mattered; they mostly had the pocket to themselves [16:24] The support issue was keeping track of when things were ready to be promoted [16:25] And being aware that we were going to start doing auto-promotion was why we were repeatedly discouraging people from doing manual testing there [16:25] which mostly funnelled down to all of them pinging infinity =) [16:39] is Raring Ringtail a proper name, and hence capitalised. Or is it a common noun and hence should be lower-cased. [16:39] ? [16:42] When written in full like that, it should be in title-case as you have it [16:43] For just the adjective, opinions evidently vary. I tend to capitalise it when I'm using it as an abbreviation for Raring Ringtail / Ubuntu 13.04 / whatever, and lower-case when I'm referring to the technical identifier (the Launchpad series, upload targets, whatever) [16:44] But that's probably just me. [16:46] I think I agree [16:46] even though my usage tends not to be so consistent :) [16:46] I'm sure mine isn't unless I'm thinking about it. [16:52] I am debating weather /etc/lsb-release DISTRIB_CODENAME is human readable or machine parsable. Since I am afraid things may break if the codename is suddently capitalised. [16:52] Does someone want to give a quick review to that base-files in the queue? It's a reasonably beefy merge, so wouldn't mind a second set of eyes rather than self-accepting. [16:53] xnox: It's meant for computers, not people, IMO. If you're referring to the bug I just closed. [16:53] by the loooks of things openSUSE capitalize their codenames in lsb-release, debian doesn't. Checking fedora now. [16:53] infinity: yeah. it is about the bug you closed. [16:54] I like os-release it has a pretty and machine names. [16:54] let's see what you crafted for raring =) [16:55] xnox: raring is the same as every release previous. [16:55] there certainly may be software that assumes the codename field is directly usable for apt and the like [16:56] Oh, goodness, yes, don't change the capitalisation in DISTRIB_CODENAME. [16:56] No excuse or reason for doing that. [16:56] Hrm, wait. This can't be about CODENAME anyway. [16:57] That sort of thing doesn't need to obey the normal rules of English grammar. [16:57] xnox: Which string is this? [16:57] ah, oh right, it's about DISTRIB_DESCRIPTION [16:57] which lowercases the codename prior to release [16:58] With an added s/\(.*// ? [16:58] and /that/ it would be reasonable to uppercase [16:58] Cause I wouldn't be against.. Yeah. [16:58] well the os-prober fetches it, and then ubiquity parses it further and we end up in Ubiquity with a string:"You have Ubuntu quantal installed on this computer. What would you like to do?" [16:58] Agreed, that doesn't matter. [16:58] during development. [16:58] xnox: Right, I'm just trying to nail down precisely (raringly?) where that comes from. [16:59] xnox: If it's lsb_release -d | sed 's/\(.*//' (or so), then yeah, we could uppercase that one. [16:59] /usr/lib/os-probes/mounted/40lsb [16:59] Basically DISTRIB_DESCRIPTION [17:00] cjwatson: Minus the " (development branch)" bit, I assume. [17:00] I guess. I haven't followed the twisty maze. [17:00] well ubiquity strips (development branch) [17:00] but it is there. [17:00] http://paste.ubuntu.com/1297966/ [17:00] Ahh. [17:00] Check. [17:00] this is paste of raw os-prober results against some of my chroots. [17:00] If ubiquity's already post-processing it, you could tr the first character of the name too. :P [17:01] * xnox wants to remove all of the logic out of ubiquity [17:01] so I rather Base-Files to be Capitalised =) [17:01] But I think I can see a valid argument for the bits in DISTRIB_DESCRIPTION, PRETTY_NAME, and /etc/issue* to have an uppercase R. [17:02] xnox: ITYM BasE-FIleS [17:02] I shall reject my upload and do that now, if there are no objections. [17:02] "We’ll make something… wonderful, and call it the Raring Ringtail." and "However, for the sake of sanity, it’s not a raring ringtail raccoon, just a raring ringtail." As per http://www.markshuttleworth.com/archives/1195 [17:03] slangasek: I am not from east london. [17:05] RFC: http://paste.ubuntu.com/1297969/ [17:05] I have a "that looks wrong" reaction which I think is just unfamiliarity. [17:06] I think it would be fine. [17:06] Yeah, I think it looks wrong to Capitalize It Without The Ringtail. [17:06] I wonder how many things will break, and why is it "Ubuntu Raring" and not "Ubuntu Raring Ringtail" everywhere. [17:06] Maybe we should add the animal too. [17:06] And totally break with tradition. [17:06] =)))))) [17:07] I'd be a bit worried about increasing the length causing some strings to wrap and ... [17:07] xnox: Nothing should break, since those fields all change regularly anyway. [17:07] we are really raring this time around =) [17:07] But I suppose it's reasonable to try it now [17:07] cjwatson: Yeah, I was thinking about wrapping issues too. Especially in installers. [17:07] As long as we don't attempt to SRU it [17:07] What the heck, let's get all animally. [17:07] I'm pretty sure that at one point "Ubuntu quantal" etc. was displayed in some contexts that didn't have a lot of horizontal space. [17:08] Like the horizontal partition display we had at one point. [17:08] Actually, yeah. I'll change it in issue/issue.net, I won't change it in lsb/os-release. [17:08] Well. Wait. People using those already cut out the (devel release) garbage. [17:08] but then ubiquity will say: "You have Ubuntu Raring installed. What do you want to do?" [17:08] They can cut the animal too if it's really an issue. [17:08] I do, FWIW, think it's perfectly fine to talk about raring or Raring; it's not like it's *wrong* without Ringtail. We've been abbreviating it ever since warty. [17:09] Bah. [17:09] Screw it. I'm done having opinions. [17:09] Everyone gets ringtails. It's a new world oder. [17:09] Also, an order. [17:09] =))))) [17:09] And I just typed "Raring Ringtails"... [17:09] Stupid brain. [17:10] http://paste.ubuntu.com/1297985/ [17:10] And uploading. [17:10] (As in, I have a mail from 2004-04-09 talking about all of "warty", "Warty", and "Warty Warthog" essentially interchangeably.) [17:11] Yeah. Well, this feels more correct for /etc/issue* anyway. [17:11]