Hi, For the first time, Fedora release name have non-ascii and pelican characters which https://bugzilla.redhat.com/show_bug.cgi?id=922433
Could we consider change release name from "Schrödinger's Cat" to "Schrodingers Cat" or other name that not have this additional problem ?
Thanks,
On Mon, 18 Mar 2013 23:56:28 +0000 Sérgio Basto sergio@serjux.com wrote:
Hi, For the first time, Fedora release name have non-ascii and pelican characters which https://bugzilla.redhat.com/show_bug.cgi?id=922433
Could we consider change release name from "Schrödinger's Cat" to "Schrodingers Cat" or other name that not have this additional problem ?
I'd rather we fix things to handle this case than paper it over by changing it.
kevin
On Mon, 2013-03-18 at 18:34 -0600, Kevin Fenzi wrote:
On Mon, 18 Mar 2013 23:56:28 +0000 Sérgio Basto sergio@serjux.com wrote:
Hi, For the first time, Fedora release name have non-ascii and pelican characters which https://bugzilla.redhat.com/show_bug.cgi?id=922433
Could we consider change release name from "Schrödinger's Cat" to "Schrodingers Cat" or other name that not have this additional problem ?
I'd rather we fix things to handle this case than paper it over by changing it.
I would very much like that we paper it over right now, unless you propose to discover and fix every single problem it causes by tomorrow, when I want us to start rolling TC images.
This bug just *smells* like one of those which will pop up again and again and again causing carnage wherever it shows up. I'm not sure I want to have to deal with that crap while also trying to fix things we *don't* have a known, straightforward workaround for. I know we want to Fix Things The Right Way and Contribute Upstream and Be Good Engineers and blah, but there's a damn limit.
On Mar 18, 2013, at 6:56 PM, Adam Williamson awilliam@redhat.com wrote:
This bug just *smells* like one of those which will pop up again and again and again causing carnage wherever it shows up.
I think so. I expect we'll find issues with isolinux, grub, livecd-tools, liveusb-creator. It could be hilarious to see how many problems this causes. But I'll bet $3.50 that by week 4 QA people start feeling like the cat in the box, and will be looking for a way to release the gas themselves.
I'm not sure I want to have to deal with that crap while also trying to fix things we *don't* have a known, straightforward workaround for.
Right. It's always a case of trying to find out where the bodies are buried for each release. This like adding a whole separate cemetery of unknown size and depth. It could be one of those town of 1000 varieties, or it could end up like one in the French Quarter where "there's always room for one more."
And is fixing this apostrophe issue going to have some clear benefit anywhere else? It's 2013, this is the 19th release of Fedora, and this is the first time it's come up?
Chris Murphy
On 19 March 2013 08:30, Nicolas Mailhot nicolas.mailhot@laposte.net wrote:
Le Mar 19 mars 2013 02:24, Chris Murphy a écrit :
And is fixing this apostrophe issue going to have some clear benefit anywhere else?
Fixing an apostrophe – no Fixing our UTF-8 handling – definitely yes
I expected both of these things creating problems for the next release. It will also break all kind of web sites that create lists of distributions.
I see it as a good thing, the problems we find are usually real bugs that just haven't been discovered yet. Fixing them now will benefit all future releases and all the people living in non pure ASCII countries.
Reminds me of the xkcd "Exploits of a Mom" strip http://xkcd.com/327/
On 19/03/13 01:27 AM, Christof Damian wrote:
I see it as a good thing, the problems we find are usually real bugs that just haven't been discovered yet.
Sure. But it's a question of priorities. "A shortage of bugs to work on" is one the very few problems with which Fedora developers do _not_ have to contend. It's not like, if we don't find some unicode bugs to hack on, all the developers are just going to lie around doing nothing...
Fixing them now will benefit all future releases and all the people living in non pure ASCII countries.
...who want to edit the fedora-release name? I guess?
Reminds me of the xkcd "Exploits of a Mom" strip http://xkcd.com/327/
It reminds everyone of that. I think it's a reasonable rule of thumb that, if something makes you think of an xkcd strip, you can pretty much assume everyone else is thinking of the same xkcd strip, and skip the citation. =)
On Tuesday 19 March 2013 09:27:16 Christof Damian wrote:
Fixing an apostrophe – no Fixing our UTF-8 handling – definitely yes
The issue here is not only about the Fedora's release name rather than fixing our UTF-8 handling. Sounds like an important bug to fix, at least to me
Fixing them now will benefit all future releases and all the people living in non pure ASCII countries.
Which is pretty much every non-english speaking country
Marc
On 19 March 2013 11:03, Marc Deop i Argemí marc@marcdeop.com wrote:
On Tuesday 19 March 2013 09:27:16 Christof Damian wrote:
Fixing an apostrophe – no
Umlaut, not apostrophe.
Fixing our UTF-8 handling – definitely yes
The issue here is not only about the Fedora's release name rather than fixing our UTF-8 handling. Sounds like an important bug to fix, at least to me
I generally haven't had problems with UTF-8 stuff, though of course I'm not a heavy user (which is not the same as not using it). However are the bug or bugs in question serious enough that introducing a change which will require them to be fixed before the next release is only a minor compounding factor? Because we're not talking about not improving unicode handling, we're talking about backing off a change which causes problems with things as they are at the minute.
Or, to put it another way, for Fedora 18, Fedora got a lot of publicity for being late to release. The project was able to say, quite reasonably, "The installer has undergone a major rewrite, and we want to make sure all the problems are ironed out first." For Fedora 19 do we want to say, "We're late to release because we wanted to put an 'ö' in the release name."?
Dne 19.3.2013 12:23, Ian Malone napsal(a):
On 19 March 2013 11:03, Marc Deop i Argemí marc@marcdeop.com wrote:
On Tuesday 19 March 2013 09:27:16 Christof Damian wrote:
Fixing an apostrophe – no
Umlaut, not apostrophe.
Schrödinger*'*s Cat
I tried to visualize the apostrophe, but it's not that visible anyway ;)
Vít
On 19 March 2013 12:20, Vít Ondruch vondruch@redhat.com wrote:
Dne 19.3.2013 12:23, Ian Malone napsal(a):
On 19 March 2013 11:03, Marc Deop i Argemí marc@marcdeop.com wrote:
On Tuesday 19 March 2013 09:27:16 Christof Damian wrote:
Fixing an apostrophe – no
Umlaut, not apostrophe.
Schrödinger*'*s Cat
I tried to visualize the apostrophe, but it's not that visible anyway ;)
Ah, I missed that bit. It seems this name is as good at breaking assumptions as the original paradox.
Le Mar 19 mars 2013 09:27, Christof Damian a écrit :
On 19 March 2013 08:30, Nicolas Mailhot nicolas.mailhot@laposte.net wrote:
Le Mar 19 mars 2013 02:24, Chris Murphy a écrit :
And is fixing this apostrophe issue going to have some clear benefit anywhere else?
Fixing an apostrophe – no Fixing our UTF-8 handling – definitely yes
I expected both of these things creating problems for the next release. It will also break all kind of web sites that create lists of distributions.
I sort of agree, given how pervasive apostrophe use is in English it was wishful thinking to accept multi-word release names without fixing apostrophe use. But most other languages care more about the UTF-8 part :)
Regards,
On 03/20/2013 07:23 PM, David Woodhouse wrote:
On Tue, 2013-03-19 at 09:27 +0100, Christof Damian wrote:
Fixing them now will benefit all future releases and all the people living in non pure ASCII countries.
∄ pure ASCII countries.
It is incredibly naĩve to believe otherwise.
It is _American_ Standard Code for Information Interchange, after all.
On 03/20/2013 07:23 PM, David Woodhouse wrote:
On Tue, 2013-03-19 at 09:27 +0100, Christof Damian wrote:
Fixing them now will benefit all future releases and all the people living in non pure ASCII countries.
∄ pure ASCII countries.
It is incredibly naĩve to believe otherwise.
That should be naïve — i.e. i-diaeresis, not i-tilde.
:þ
On Fri, 2013-03-22 at 14:44 -0400, Kaleb S. KEITHLEY wrote:
On 03/20/2013 07:23 PM, David Woodhouse wrote:
On Tue, 2013-03-19 at 09:27 +0100, Christof Damian wrote:
Fixing them now will benefit all future releases and all the people living in non pure ASCII countries.
∄ pure ASCII countries.
It is incredibly naĩve to believe otherwise.
That should be naïve — i.e. i-diaeresis, not i-tilde.
So it should. Evidently I hit RightAlt-] instead of RightAlt-[ before the 'i' key, and failed to notice. Sorry about that.
Btw, please remember to Cc me on replies – I've only just seen this!
I see you're a Thunderbird user. Does it have the same option that Evolution does, to ignore abusive Reply-To: settings on mailing lists?
On Wed, May 01, 2013 at 09:17:46 +0100, David Woodhouse dwmw2@infradead.org wrote:
I see you're a Thunderbird user. Does it have the same option that Evolution does, to ignore abusive Reply-To: settings on mailing lists?
If you use maildrop filtering, you can have it strip reply-to headers from messages sent to lists that do reply-to munging.
On Mon, Mar 18, 2013 at 05:56:28PM -0700, Adam Williamson wrote:
On Mon, 2013-03-18 at 18:34 -0600, Kevin Fenzi wrote:
On Mon, 18 Mar 2013 23:56:28 +0000 Sérgio Basto sergio@serjux.com wrote:
Hi, For the first time, Fedora release name have non-ascii and pelican characters which https://bugzilla.redhat.com/show_bug.cgi?id=922433
Could we consider change release name from "Schrödinger's Cat" to "Schrodingers Cat" or other name that not have this additional problem ?
I'd rather we fix things to handle this case than paper it over by changing it.
+1
I would very much like that we paper it over right now, unless you propose to discover and fix every single problem it causes by tomorrow, when I want us to start rolling TC images.
If by right now you mean until we get TC out (or even until we get alpha out), I wouldn't be opposed to that. These sort of bugs really are something that need to be fixed and this release name is a good candidate for doing so... but the time from alpha to beta is appropriate for fixing bugs so it's okay if we defer fixing them for a little while.
-Toshio "who's been working on various iterations of a fix for this in the python3 package[1] for a few days" Kuratomi
.. [1]_: http://bugs.python.org/issue17429
On 18/03/13 10:22 PM, Toshio Kuratomi wrote:
On Mon, Mar 18, 2013 at 05:56:28PM -0700, Adam Williamson wrote:
On Mon, 2013-03-18 at 18:34 -0600, Kevin Fenzi wrote:
On Mon, 18 Mar 2013 23:56:28 +0000 Sérgio Basto sergio@serjux.com wrote:
Hi, For the first time, Fedora release name have non-ascii and pelican characters which https://bugzilla.redhat.com/show_bug.cgi?id=922433
Could we consider change release name from "Schrödinger's Cat" to "Schrodingers Cat" or other name that not have this additional problem ?
I'd rather we fix things to handle this case than paper it over by changing it.
+1
I would very much like that we paper it over right now, unless you propose to discover and fix every single problem it causes by tomorrow, when I want us to start rolling TC images.
If by right now you mean until we get TC out (or even until we get alpha out), I wouldn't be opposed to that. These sort of bugs really are something that need to be fixed and this release name is a good candidate for doing so... but the time from alpha to beta is appropriate for fixing bugs so it's okay if we defer fixing them for a little while.
-Toshio "who's been working on various iterations of a fix for this in the python3 package[1] for a few days" Kuratomi
Well, look, my point is that sometimes our commitment to 'fixing things the right way' appears to verge on bloody masochism.
You want to set up a side project to spin some images with crazy release names and see what breaks and fix that, then you know, go for it. But I'm trying to ship an operating system that works here, and leaving something we know is causing all kinds of problems in the problematic state just so we can keep finding exciting new problems to fix does not suffuse me with joy.
If we have to compromise on just papering it over for Alpha, I mean, _fine_. But seriously: sometimes papering it over is just the right thing to do.
On 03/19/2013 02:11 AM, Adam Williamson wrote:
Well, look, my point is that sometimes our commitment to 'fixing things the right way' appears to verge on bloody masochism.
<snip>
If we have to compromise on just papering it over for Alpha, I mean, _fine_. But seriously: sometimes papering it over is just the right thing to do.
I disagree. This particular problem points out a problem that is only going to become more of a problem as the internationalization of software increases. Not everything is ASCII or English, and not defensively programming for such cases is short-sighted.
Perhaps we are getting "burned out" by the hectic pace that Fedora tries to keep with a six-month release cycle. I know I sat out a lot of the 18 cycle due to a sense of being overwhelmed by the rush.
On 19/03/13 01:04 AM, G.Wolfe Woodbury wrote:
On 03/19/2013 02:11 AM, Adam Williamson wrote:
Well, look, my point is that sometimes our commitment to 'fixing things the right way' appears to verge on bloody masochism.
<snip> > If we have to compromise on just papering it over for Alpha, I mean, > _fine_. But seriously: sometimes papering it over is just the right > thing to do.
I disagree. This particular problem points out a problem that is only going to become more of a problem as the internationalization of software increases. Not everything is ASCII or English, and not defensively programming for such cases is short-sighted.
Perhaps we are getting "burned out" by the hectic pace that Fedora tries to keep with a six-month release cycle. I know I sat out a lot of the 18 cycle due to a sense of being overwhelmed by the rush.
I don't object at all to fixing UTF-8 issues, but it seems needlessly stressful to force ourselves to do so as a part of release validation, with booby traps exploding all around us. It's the kind of thing that can easily be worked on in a less stressful manner. Instead of using the development method 'let's break it now in our main product and fix stuff as we happen across it', how about the development method 'let's not break our main product for now, let's let people who want to hack on it do so as a side stream, and then when they think they have fixed the most important issues, _then_ they can propose putting the disruptive change into the main product'.
On Tue, Mar 19, 2013 at 01:31:30AM -0700, Adam Williamson wrote:
On 19/03/13 01:04 AM, G.Wolfe Woodbury wrote:
On 03/19/2013 02:11 AM, Adam Williamson wrote:
Well, look, my point is that sometimes our commitment to 'fixing things the right way' appears to verge on bloody masochism.
<snip> >If we have to compromise on just papering it over for Alpha, I mean, >_fine_. But seriously: sometimes papering it over is just the right >thing to do.
I disagree. This particular problem points out a problem that is only going to become more of a problem as the internationalization of software increases. Not everything is ASCII or English, and not defensively programming for such cases is short-sighted.
Perhaps we are getting "burned out" by the hectic pace that Fedora tries to keep with a six-month release cycle. I know I sat out a lot of the 18 cycle due to a sense of being overwhelmed by the rush.
I don't object at all to fixing UTF-8 issues, but it seems needlessly stressful to force ourselves to do so as a part of release validation, with booby traps exploding all around us. It's the kind of thing that can easily be worked on in a less stressful manner. Instead of using the development method 'let's break it now in our main product and fix stuff as we happen across it', how about the development method 'let's not break our main product for now, let's let people who want to hack on it do so as a side stream, and then when they think they have fixed the most important issues, _then_ they can propose putting the disruptive change into the main product'.
An interesting question is: Why don't we try out the new release name early on in Rawhide. ie. we would change the release name now to whatever F20 is going to be + " (Rawhide)". Wouldn't that give us a lot more time to test and fix?
Rich.
From: "Richard W.M. Jones" rjones@redhat.com
An interesting question is: Why don't we try out the new release name early on in Rawhide. ie. we would change the release name now to whatever F20 is going to be + " (Rawhide)". Wouldn't that give us a lot more time to test and fix?
That seems like a great idea ... and it also adds in a test for handling parenthesis. I can't imagine how they'd pose a problem, but clearly nobody foresaw this train coming either.
In fact, maybe should be something like:
F20name + " (Rawhide); touch /tmp/little-bobby-tables"
I joke of course ... sort of. ;-)
-- John Florian
On 19 Mar 2013 14:33, John.Florian@dart.biz wrote:
From: "Richard W.M. Jones" rjones@redhat.com
An interesting question is: Why don't we try out the new release name early on in Rawhide. ie. we would change the release name now to whatever F20 is going to be + " (Rawhide)". Wouldn't that give us a lot more time to test and fix?
That seems like a great idea ... and it also adds in a test for handling
parenthesis. I can't imagine how they'd pose a problem, but clearly nobody foresaw this train coming either.
Err the fedora 19 voting for names started around the release of F18 alpha. Its been set as this for around 6 months already, I suspect its only become an issue with people starting to create images etc.
Peter
Peter
----- Original Message -----
On 19 Mar 2013 14:33, < John.Florian@dart.biz > wrote:
From: "Richard W.M. Jones" < rjones@redhat.com >
An interesting question is: Why don't we try out the new release name early on in Rawhide. ie. we would change the release name now to whatever F20 is going to be + " (Rawhide)". Wouldn't that give us a lot more time to test and fix?
That seems like a great idea ... and it also adds in a test for handling parenthesis. I can't imagine how they'd pose a problem, but clearly nobody foresaw this train coming either.
Err the fedora 19 voting for names started around the release of F18 alpha. Its been set as this for around 6 months already, I suspect its only become an issue with people starting to create images etc.
I think notting joked about it when the name was announced... Well, it's not a joke anymore ;-)
As we are still on the same spot, without conclusion I created FESCo ticket [1] as it's one of the Test Composes blocker...
Jaroslav
[1] https://fedorahosted.org/fesco/ticket/1102
Peter
Peter
devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On 19/03/13 08:30 AM, Peter Robinson wrote:
On 19 Mar 2013 14:33, <John.Florian@dart.biz mailto:John.Florian@dart.biz> wrote:
From: "Richard W.M. Jones" <rjones@redhat.com
An interesting question is: Why don't we try out the new release name early on in Rawhide. ie. we would change the release name now to whatever F20 is going to be + " (Rawhide)". Wouldn't that give us a lot more time to test and fix?
That seems like a great idea ... and it also adds in a test for
handling parenthesis. I can't imagine how they'd pose a problem, but clearly nobody foresaw this train coming either.
Err the fedora 19 voting for names started around the release of F18 alpha. Its been set as this for around 6 months already, I suspect its only become an issue with people starting to create images etc.
It isn't applied anywhere till branch. Rawhide always uses the release name 'Rawhide'. Even though it's voted on a long way ahead of time, the new release name is only applied in the tree at branch time. Several people were using Rawhide considerably in advance of branching - including myself - and the problems showed up right when we branched and the new fedora-release package was rolled.
How about spending time and energy on fixing the bugs rather then bike shed over whether we should apply a duct tape or not?
Once upon a time, drago01 drago01@gmail.com said:
How about spending time and energy on fixing the bugs rather then bike shed over whether we should apply a duct tape or not?
The problem is that there are possibly many unknown bugs that could hold up building composes, and it is just about time for composes to start going out the door. I don't feel it is worth holding up composes over a name that can easily be changed.
Repeating what was said earlier: the proper way to do this is to treat it like a feature (making all release name handlers UTF-8 and shell quote safe), and start working on it now for F20.
From: Adam Williamson awilliam@redhat.com
On 19/03/13 08:30 AM, Peter Robinson wrote:
On 19 Mar 2013 14:33, <John.Florian@dart.biz mailto:John.Florian@dart.biz> wrote:
From: "Richard W.M. Jones" <rjones@redhat.com
An interesting question is: Why don't we try out the new release
name
early on in Rawhide. ie. we would change the release name now to whatever F20 is going to be + " (Rawhide)". Wouldn't that give
us a
lot more time to test and fix?
That seems like a great idea ... and it also adds in a test for
handling parenthesis. I can't imagine how they'd pose a problem, but clearly nobody foresaw this train coming either.
Err the fedora 19 voting for names started around the release of F18 alpha. Its been set as this for around 6 months already, I suspect its only become an issue with people starting to create images etc.
It isn't applied anywhere till branch. Rawhide always uses the release name 'Rawhide'. Even though it's voted on a long way ahead of time, the new release name is only applied in the tree at branch time. Several people were using Rawhide considerably in advance of branching - including myself - and the problems showed up right when we branched and
the new fedora-release package was rolled.
Ah, that makes sense. I had no idea how feasible name + " (Rawhide)" would be, I just liked the idea.
-- John Florian
On Tue, 2013-03-19 at 14:14 -0400, John.Florian@dart.biz wrote:
From: Adam Williamson awilliam@redhat.com
On 19/03/13 08:30 AM, Peter Robinson wrote:
On 19 Mar 2013 14:33, <John.Florian@dart.biz mailto:John.Florian@dart.biz> wrote:
From: "Richard W.M. Jones" <rjones@redhat.com
An interesting question is: Why don't we try out the new
release name
early on in Rawhide. ie. we would change the release name
now to
whatever F20 is going to be + " (Rawhide)". Wouldn't that
give us a
lot more time to test and fix?
That seems like a great idea ... and it also adds in a test for
handling parenthesis. I can't imagine how they'd pose a problem,
but
clearly nobody foresaw this train coming either.
Err the fedora 19 voting for names started around the release of
F18
alpha. Its been set as this for around 6 months already, I suspect
its
only become an issue with people starting to create images etc.
It isn't applied anywhere till branch. Rawhide always uses the
release
name 'Rawhide'. Even though it's voted on a long way ahead of time,
the
new release name is only applied in the tree at branch time.
Several
people were using Rawhide considerably in advance of branching - including myself - and the problems showed up right when we branched
and
the new fedora-release package was rolled.
Ah, that makes sense. I had no idea how feasible name + " (Rawhide)" would be, I just liked the idea.
It's an interesting idea, but I suspect it may break rather more stuff than people expect :) Be neat to try though, and Rawhide is certainly the place to break it.
On Tue, 2013-03-19 at 11:26 -0700, Adam Williamson wrote:
On Tue, 2013-03-19 at 14:14 -0400, John.Florian@dart.biz wrote:
From: Adam Williamson awilliam@redhat.com
On 19/03/13 08:30 AM, Peter Robinson wrote:
On 19 Mar 2013 14:33, <John.Florian@dart.biz mailto:John.Florian@dart.biz> wrote:
From: "Richard W.M. Jones" <rjones@redhat.com
An interesting question is: Why don't we try out the new
release name
early on in Rawhide. ie. we would change the release name
now to
whatever F20 is going to be + " (Rawhide)". Wouldn't that
give us a
lot more time to test and fix?
That seems like a great idea ... and it also adds in a test for
handling parenthesis. I can't imagine how they'd pose a problem,
but
clearly nobody foresaw this train coming either.
Err the fedora 19 voting for names started around the release of
F18
alpha. Its been set as this for around 6 months already, I suspect
its
only become an issue with people starting to create images etc.
It isn't applied anywhere till branch. Rawhide always uses the
release
name 'Rawhide'. Even though it's voted on a long way ahead of time,
the
new release name is only applied in the tree at branch time.
Several
people were using Rawhide considerably in advance of branching - including myself - and the problems showed up right when we branched
and
the new fedora-release package was rolled.
Ah, that makes sense. I had no idea how feasible name + " (Rawhide)" would be, I just liked the idea.
It's an interesting idea, but I suspect it may break rather more stuff than people expect :) Be neat to try though, and Rawhide is certainly the place to break it.
I vote for Räwh'de myself :-)
Simo.
On Ter, 2013-03-19 at 14:29 -0400, Simo Sorce wrote:
On Tue, 2013-03-19 at 11:26 -0700, Adam Williamson wrote:
On Tue, 2013-03-19 at 14:14 -0400, John.Florian@dart.biz wrote:
From: Adam Williamson awilliam@redhat.com
On 19/03/13 08:30 AM, Peter Robinson wrote:
On 19 Mar 2013 14:33, <John.Florian@dart.biz mailto:John.Florian@dart.biz> wrote:
> From: "Richard W.M. Jones" <rjones@redhat.com
> > An interesting question is: Why don't we try out the new
release name
> early on in Rawhide. ie. we would change the release name
now to
> whatever F20 is going to be + " (Rawhide)". Wouldn't that
give us a
> lot more time to test and fix?
That seems like a great idea ... and it also adds in a test for
handling parenthesis. I can't imagine how they'd pose a problem,
but
clearly nobody foresaw this train coming either.
Err the fedora 19 voting for names started around the release of
F18
alpha. Its been set as this for around 6 months already, I suspect
its
only become an issue with people starting to create images etc.
It isn't applied anywhere till branch. Rawhide always uses the
release
name 'Rawhide'. Even though it's voted on a long way ahead of time,
the
new release name is only applied in the tree at branch time.
Several
people were using Rawhide considerably in advance of branching - including myself - and the problems showed up right when we branched
and
the new fedora-release package was rolled.
Ah, that makes sense. I had no idea how feasible name + " (Rawhide)" would be, I just liked the idea.
It's an interesting idea, but I suspect it may break rather more stuff than people expect :) Be neat to try though, and Rawhide is certainly the place to break it.
I vote for Räwh'de myself :-)
hi, state my point of view , my last email just go to Chris Murphy thing is, we introduce one ö (my keyboard don't have it) is like what I have to leave with my é of Sérgio and one apostrophe , so cases complete different. I bet ö will give much more problems . I'm not saying to forget the bug, I'm saying: hey, this introduce a bug , so first, we roll-back, second we fix the bug and third when bug or bugs are fixed , we put release name with "what ever we want"
Cheers,
On 03/20/2013 03:59 PM, Sérgio Basto wrote:
On Ter, 2013-03-19 at 14:29 -0400, Simo Sorce wrote:
hi, state my point of view , my last email just go to Chris Murphy thing is, we introduce one ö (my keyboard don't have it) is like what I have to leave with my é of Sérgio and one apostrophe , so cases complete different. I bet ö will give much more problems .
No. Both cases are almost equivalent. Both are non-ASCII and both are covered by UTF-8. Both chars are part of most European ISO 8859 variants.
Whether "é" or "ö" is more common to individuals is just a matter of ones language/locale/script. ö is more common in North European languages (and German, my keyboard has it), "é" is more common in South European languages (my keyboard has it hidden under a multi-key sequence).
Ralf
On 20 March 2013 15:35, Ralf Corsepius rc040203@freenet.de wrote:
On 03/20/2013 03:59 PM, Sérgio Basto wrote:
On Ter, 2013-03-19 at 14:29 -0400, Simo Sorce wrote:
hi, state my point of view , my last email just go to Chris Murphy thing is, we introduce one ö (my keyboard don't have it) is like what I have to leave with my é of Sérgio and one apostrophe , so cases complete different. I bet ö will give much more problems .
No. Both cases are almost equivalent. Both are non-ASCII and both are covered by UTF-8. Both chars are part of most European ISO 8859 variants.
Whether "é" or "ö" is more common to individuals is just a matter of ones language/locale/script. ö is more common in North European languages (and German, my keyboard has it), "é" is more common in South European languages (my keyboard has it hidden under a multi-key sequence).
I think Sergio is referring to the thing I also missed, there is an apostrophe in the release name as well as an umlaut. That may be ASCII (though there are higher unicode points for specific apostrophes, not sure that was a great idea...), but obviously has a different set of potential problems (which you'd hope would be easier to fix).
On Qua, 2013-03-20 at 16:26 +0000, Ian Malone wrote:
On 20 March 2013 15:35, Ralf Corsepius rc040203@freenet.de wrote:
On 03/20/2013 03:59 PM, Sérgio Basto wrote:
On Ter, 2013-03-19 at 14:29 -0400, Simo Sorce wrote:
hi, state my point of view , my last email just go to Chris Murphy thing is, we introduce one ö (my keyboard don't have it) is like what I have to leave with my é of Sérgio and one apostrophe , so cases complete different. I bet ö will give much more problems .
No. Both cases are almost equivalent. Both are non-ASCII and both are covered by UTF-8. Both chars are part of most European ISO 8859 variants.
Whether "é" or "ö" is more common to individuals is just a matter of ones language/locale/script. ö is more common in North European languages (and German, my keyboard has it), "é" is more common in South European languages (my keyboard has it hidden under a multi-key sequence).
I think Sergio is referring to the thing I also missed, there is an apostrophe in the release name as well as an umlaut. That may be ASCII (though there are higher unicode points for specific apostrophes, not sure that was a great idea...), but obviously has a different set of potential problems (which you'd hope would be easier to fix).
yes , single quote or apostrophe have ascii code 39, could break strings in others ways
On Tue, 2013-03-19 at 11:26 -0700, Adam Williamson wrote:
On Tue, 2013-03-19 at 14:14 -0400, John.Florian@dart.biz wrote:
From: Adam Williamson awilliam@redhat.com
On 19/03/13 08:30 AM, Peter Robinson wrote:
On 19 Mar 2013 14:33, <John.Florian@dart.biz mailto:John.Florian@dart.biz> wrote:
From: "Richard W.M. Jones" <rjones@redhat.com
An interesting question is: Why don't we try out the new
release name
early on in Rawhide. ie. we would change the release name
now to
whatever F20 is going to be + " (Rawhide)". Wouldn't that
give us a
lot more time to test and fix?
That seems like a great idea ... and it also adds in a test for
handling parenthesis. I can't imagine how they'd pose a problem,
but
clearly nobody foresaw this train coming either.
Err the fedora 19 voting for names started around the release of
F18
alpha. Its been set as this for around 6 months already, I suspect
its
only become an issue with people starting to create images etc.
It isn't applied anywhere till branch. Rawhide always uses the
release
name 'Rawhide'. Even though it's voted on a long way ahead of time,
the
new release name is only applied in the tree at branch time.
Several
people were using Rawhide considerably in advance of branching - including myself - and the problems showed up right when we branched
and
the new fedora-release package was rolled.
Ah, that makes sense. I had no idea how feasible name + " (Rawhide)" would be, I just liked the idea.
It's an interesting idea, but I suspect it may break rather more stuff than people expect :) Be neat to try though, and Rawhide is certainly the place to break it.
It could be Name Rawhide which gets changed to Name after branching.
No strict need for () I think.
Kai
Le Mar 19 mars 2013 09:31, Adam Williamson a écrit :
I don't object at all to fixing UTF-8 issues, but it seems needlessly stressful to force ourselves to do so as a part of release validation, with booby traps exploding all around us. It's the kind of thing that can easily be worked on in a less stressful manner.
And Fedora switched to UTF-8 by default when exactly (was it even Fedora or a RHL decision)? The less stressful manner seems to have failed utterly here, at some point some problems only get fixed (and not procastinated indefinitely) when software breaks.
Moreover, experience shows any python tool (and we have tons of them system-side) will break on UTF-8 by default. And that python devs do not remember to test this case. Therefore, I doubt the problem could be realistically detected and fixed before branching point.
Regards,
On Tue, 2013-03-19 at 12:23 +0100, Nicolas Mailhot wrote:
Le Mar 19 mars 2013 09:31, Adam Williamson a écrit :
I don't object at all to fixing UTF-8 issues, but it seems needlessly stressful to force ourselves to do so as a part of release validation, with booby traps exploding all around us. It's the kind of thing that can easily be worked on in a less stressful manner.
And Fedora switched to UTF-8 by default when exactly (was it even Fedora or a RHL decision)?
Red Hat Linux 8.0: http://en.wikipedia.org/wiki/Red_Hat_Linux
On 03/19/2013 02:38 PM, Bastien Nocera wrote:
And Fedora switched to UTF-8 by default when exactly (was it even Fedora or a RHL decision)?
Red Hat Linux 8.0: http://en.wikipedia.org/wiki/Red_Hat_Linux
I still remember how many things were broken in that moment (7.3 was considered the only usable RH for some time, and I have one machine still running it). RHL 8.0 also changed something at the font level (introduced antialias, maybe freetype?), so the entire text thing was a minefield.
Anyway, that was the moment which demonstrated to me that Linux was so ahead of everyone else. I still fight today with iso88591 and cp1252 and utf16 BOMs and stupid crazy things which Windows and Java spread around, while everything in Linux always works perfectly.
On 2013-03-20 12:54 (GMT+0100) Roberto Ragusa composed:
everything in Linux always works perfectly.
Right, like function keys in MC that mean one thing when running it in a VC and something else when running it in X or Single, because keyboard layouts aren't consistent among them.
On Wed, 2013-03-20 at 09:41 -0400, Felix Miata wrote:
On 2013-03-20 12:54 (GMT+0100) Roberto Ragusa composed:
everything in Linux always works perfectly.
Right, like function keys in MC that mean one thing when running it in a VC and something else when running it in X or Single, because keyboard layouts aren't consistent among them.
That will very likely be fixed in F19:
https://bugzilla.redhat.com/show_bug.cgi?id=837292
On 19 March 2013 08:04, G.Wolfe Woodbury redwolfe@gmail.com wrote:
On 03/19/2013 02:11 AM, Adam Williamson wrote:
Well, look, my point is that sometimes our commitment to 'fixing things the right way' appears to verge on bloody masochism.
<snip> > If we have to compromise on just papering it over for Alpha, I mean, > _fine_. But seriously: sometimes papering it over is just the right > thing to do.
I disagree. This particular problem points out a problem that is only going to become more of a problem as the internationalization of software increases. Not everything is ASCII or English, and not defensively programming for such cases is short-sighted.
This is conflating an issue that affects the release name and issues related to it to internationalisation in general. I see that fixes are being worked on for this issue, but it also seems it can't be guaranteed that there are no further problems it will cause right now and holding up the release for what is basically a triviality seems a bit silly.
Le Mar 19 mars 2013 11:38, Ian Malone a écrit :
and holding up the release for what is basically a triviality seems a bit silly.
The perception correct UTF-8 handling is a triviality that should be worked on at some later date is the reason we have this breakage now.
On 19 March 2013 11:24, Nicolas Mailhot nicolas.mailhot@laposte.net wrote:
Le Mar 19 mars 2013 11:38, Ian Malone a écrit :
and holding up the release for what is basically a triviality seems a bit silly.
The perception correct UTF-8 handling is a triviality that should be worked on at some later date is the reason we have this breakage now.
No, the exact spelling of the release name is a triviality when there is a typographically acceptable alternative.
Yet another post on the devel list which seeks to cast the previous poster in the worst possible light when there might be a more rational interpretation of what they wrote. Can people try and be a little bit more reasonable and less combative maybe?
Le Mar 19 mars 2013 12:27, Ian Malone a écrit :
On 19 March 2013 11:24, Nicolas Mailhot nicolas.mailhot@laposte.net wrote:
Le Mar 19 mars 2013 11:38, Ian Malone a écrit :
and holding up the release for what is basically a triviality seems a bit silly.
The perception correct UTF-8 handling is a triviality that should be worked on at some later date is the reason we have this breakage now.
No, the exact spelling of the release name is a triviality when there is a typographically acceptable alternative.
Yet another post on the devel list which seeks to cast the previous poster in the worst possible light when there might be a more rational interpretation of what they wrote. Can people try and be a little bit more reasonable and less combative maybe?
Pot, met kettle. Don't ask others to be less combative when you choose such a loaded word as triviality to qualify some problem they care about.
On 19 March 2013 11:41, Nicolas Mailhot nicolas.mailhot@laposte.net wrote:
Le Mar 19 mars 2013 12:27, Ian Malone a écrit :
On 19 March 2013 11:24, Nicolas Mailhot nicolas.mailhot@laposte.net wrote:
Le Mar 19 mars 2013 11:38, Ian Malone a écrit :
and holding up the release for what is basically a triviality seems a bit silly.
The perception correct UTF-8 handling is a triviality that should be worked on at some later date is the reason we have this breakage now.
No, the exact spelling of the release name is a triviality when there is a typographically acceptable alternative.
Yet another post on the devel list which seeks to cast the previous poster in the worst possible light when there might be a more rational interpretation of what they wrote. Can people try and be a little bit more reasonable and less combative maybe?
Pot, met kettle. Don't ask others to be less combative when you choose such a loaded word as triviality to qualify some problem they care about.
Are you talking about the choice of ö versus 'oe' as a workaround or something else? Because what you said was that I was calling UTF-8 support a triviality, which I didn't. And you've ignored my attempt to clarify that instead following up with a playground retort And this goes on and on on this list. It generates endless circular discussions which degenerate into name calling and does nothing more useful than waste people's time and entrench their positions.
For what it's worth, I spent a while years ago helping out with issues of UTF-8 support in Vorbis. I filled the odd bug for UTF-8 emacs support in Fedora. It is something I do care about.
On Tue, 2013-03-19 at 12:24 +0100, Nicolas Mailhot wrote:
Le Mar 19 mars 2013 11:38, Ian Malone a écrit :
and holding up the release for what is basically a triviality seems a bit silly.
The perception correct UTF-8 handling is a triviality that should be worked on at some later date is the reason we have this breakage now.
No. As I understand it, this bug would have happened if we were still in the 20th century and using the legacy 8-bit encodings too.
We have an 'is it text?' function which arbitrarily allows 2% of bytes to be >= 0x80. Which means that even in ISO8859-1, a file containing just the words "Schrödinger's Cat" wouldn't be considered to be text.
It's just broken; it's not even UTF-8 specific. In fact, UTF-8 makes things *easier* because you can check for valid UTF-8 byte sequences instead of just bytes >= 0x80.
On Wed, 2013-03-20 at 23:35 +0000, David Woodhouse wrote:
On Tue, 2013-03-19 at 12:24 +0100, Nicolas Mailhot wrote:
Le Mar 19 mars 2013 11:38, Ian Malone a écrit :
and holding up the release for what is basically a triviality seems a bit silly.
The perception correct UTF-8 handling is a triviality that should be worked on at some later date is the reason we have this breakage now.
No. As I understand it, this bug would have happened if we were still in the 20th century and using the legacy 8-bit encodings too.
We have an 'is it text?' function which arbitrarily allows 2% of bytes to be >= 0x80. Which means that even in ISO8859-1, a file containing just the words "Schrödinger's Cat" wouldn't be considered to be text.
That was the bug in abrt. The bug in grub2 was that the single quote closed quotes in the grub config file, which uses...single quotes...for quoting.
Of course, that's not a unicode bug either.
On 20 March 2013 23:35, David Woodhouse dwmw2@infradead.org wrote:
On Tue, 2013-03-19 at 12:24 +0100, Nicolas Mailhot wrote:
Le Mar 19 mars 2013 11:38, Ian Malone a écrit :
and holding up the release for what is basically a triviality seems a bit silly.
The perception correct UTF-8 handling is a triviality that should be worked on at some later date is the reason we have this breakage now.
No. As I understand it, this bug would have happened if we were still in the 20th century and using the legacy 8-bit encodings too.
We have an 'is it text?' function which arbitrarily allows 2% of bytes to be >= 0x80. Which means that even in ISO8859-1, a file containing just the words "Schrödinger's Cat" wouldn't be considered to be text.
It's just broken; it's not even UTF-8 specific. In fact, UTF-8 makes things *easier* because you can check for valid UTF-8 byte sequences instead of just bytes >= 0x80.
I had to read that twice before my brain would accept its meaning. There's a smiley on a forum I use that would be appropriate, but :eek: isn't quite so good without the picture.
Once upon a time, G.Wolfe Woodbury redwolfe@gmail.com said:
I disagree. This particular problem points out a problem that is only going to become more of a problem as the internationalization of software increases. Not everything is ASCII or English, and not defensively programming for such cases is short-sighted.
Okay, but I agree with Adam. If somebody wants to add support of UTF-8 (and arbitrary characters that need quoting like an apostrophe) in the boot loader and all associated tools, the Feature deadline has passed. There should have been a test plan, fallback, etc.
This is a trivial thing to hold up a whole distribution release (even test releases), especially when there may be bugs lurking in many unknown places. Simplify the name for this release, and somebody can submit a Feature and do proper testing/bug fixing/etc. for a future release (if and when another name with non ASCII alphanumeric characters is chosen).
----- Original Message -----
Once upon a time, G.Wolfe Woodbury redwolfe@gmail.com said:
I disagree. This particular problem points out a problem that is only going to become more of a problem as the internationalization of software increases. Not everything is ASCII or English, and not defensively programming for such cases is short-sighted.
Okay, but I agree with Adam. If somebody wants to add support of UTF-8 (and arbitrary characters that need quoting like an apostrophe) in the boot loader and all associated tools, the Feature deadline has passed. There should have been a test plan, fallback, etc.
This is a trivial thing to hold up a whole distribution release (even test releases), especially when there may be bugs lurking in many unknown places. Simplify the name for this release, and somebody can submit a Feature and do proper testing/bug fixing/etc. for a future release (if and when another name with non ASCII alphanumeric characters is chosen).
+1!
Jaroslav
-- Chris Adams cmadams@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Jaroslav Reznik wrote:
----- Original Message -----
Once upon a time, G.Wolfe Woodbury redwolfe@gmail.com said: submit a Feature and do proper testing/bug fixing/etc. for a future release (if and when another name with non ASCII alphanumeric characters is chosen).
+1!
Jaroslav
What do you mean, if and when? I can already see the next Release Name page shaping up with
"Motörhead's Moshpit is a name with non ASCII alphanumeric characters, like ..."
On Tue, Mar 19, 2013 at 01:08:35PM -0000, Paul Flo Williams wrote:
Jaroslav Reznik wrote:
----- Original Message -----
Once upon a time, G.Wolfe Woodbury redwolfe@gmail.com said: submit a Feature and do proper testing/bug fixing/etc. for a future release (if and when another name with non ASCII alphanumeric characters is chosen).
+1!
Jaroslav
What do you mean, if and when? I can already see the next Release Name page shaping up with
"Motörhead's Moshpit is a name with non ASCII alphanumeric characters, like ..."
I'm voting for ☃.
Rich.
On 19 Mar 2013 16:22, "Richard W.M. Jones" rjones@redhat.com wrote:
On Tue, Mar 19, 2013 at 01:08:35PM -0000, Paul Flo Williams wrote:
Jaroslav Reznik wrote:
----- Original Message -----
Once upon a time, G.Wolfe Woodbury redwolfe@gmail.com said: submit a Feature and do proper testing/bug fixing/etc. for a future release (if and when another name with non ASCII alphanumeric characters is chosen).
+1!
Jaroslav
What do you mean, if and when? I can already see the next Release Name page shaping up with
"Motörhead's Moshpit is a name with non ASCII alphanumeric characters, like ..."
I'm voting for ☃.
I'm voting for "DROP table *;" or what ever everyone's current favourite SQL injection attack is.
This fixes all of our problems with punctuation and unicode. It may introduce other problems. --- fedora-release.spec | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fedora-release.spec b/fedora-release.spec index 0791715..43eed3e 100644 --- a/fedora-release.spec +++ b/fedora-release.spec @@ -1,4 +1,4 @@ -%define release_name Schrödinger’s Cat +%define release_name Zoidberg %define dist_version 19
Summary: Fedora release files
Il 19/03/2013 18:50, Peter Jones ha scritto:
This fixes all of our problems with punctuation and unicode. It may introduce other problems.
fedora-release.spec | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fedora-release.spec b/fedora-release.spec index 0791715..43eed3e 100644 --- a/fedora-release.spec +++ b/fedora-release.spec @@ -1,4 +1,4 @@ -%define release_name Schrödinger’s Cat +%define release_name Zoidberg %define dist_version 19
Summary: Fedora release files
i prefer the cat... only my opinion regards gil
On 03/19/2013 11:50 AM, Peter Jones wrote:
This fixes all of our problems with punctuation and unicode. It may introduce other problems.
fedora-release.spec | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fedora-release.spec b/fedora-release.spec index 0791715..43eed3e 100644 --- a/fedora-release.spec +++ b/fedora-release.spec @@ -1,4 +1,4 @@ -%define release_name Schrödinger’s Cat +%define release_name Zoidberg %define dist_version 19
Summary: Fedora release files
Your patch is bad and you should feel bad!
----- Original Message -----
This fixes all of our problems with punctuation and unicode. It may introduce other problems.
fedora-release.spec | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fedora-release.spec b/fedora-release.spec index 0791715..43eed3e 100644 --- a/fedora-release.spec +++ b/fedora-release.spec @@ -1,4 +1,4 @@ -%define release_name Schrödinger’s Cat +%define release_name Zoidberg %define dist_version 19
"Names of living people or well-known trademarks or goods will be rejected by Red Hat Legal."
The questions regarding Doctor John A. Zoidberg are 1) is he alive? (he will be in the year 3000!) 2) living people? (he is a lobster-like alien!)
And then trademarks (in the year 3000!) - you know how it ended with Popplers!
Jaroslav
Summary: Fedora release files
1.8.1.4
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Wed, 20 Mar 2013 06:17:23 -0400 (EDT) Jaroslav Reznik jreznik@redhat.com wrote:
"Names of living people or well-known trademarks or goods will be rejected by Red Hat Legal."
why not on Rawhide do: Release Name: $^&*"'#~?@% and any other characters that may cause boot problems.
Hopefully there is no-one who is called above.
On Wednesday 2013-03-20 11:20, Frank Murphy wrote:
On Wed, 20 Mar 2013 06:17:23 -0400 (EDT) Jaroslav Reznik wrote:
"Names of living people or well-known trademarks or goods will be rejected by Red Hat Legal."
why not on Rawhide do: Release Name: $^&*"'#~?@% Hopefully there is no-one who is called above.
There most definitely is. Just participate in big towns' daily road traffic. Other names by which said person(s) is/are known is ~!@#$%^&* , and other region-specific variations such as `!"£$%^&* in the UK and ^!"§$%&/ in Germany.
On 03/19/2013 09:22 AM, Richard W.M. Jones wrote:
On Tue, Mar 19, 2013 at 01:08:35PM -0000, Paul Flo Williams wrote:
What do you mean, if and when? I can already see the next Release Name page shaping up with
"Motörhead's Moshpit is a name with non ASCII alphanumeric characters, like ..."
I'm voting for ☃.
Me, I'm pulling for "the release formerly known as Schrödinger's Cat".
J. Randall Owens (jrowens.fedora@ghiapet.net) said:
On 03/19/2013 09:22 AM, Richard W.M. Jones wrote:
On Tue, Mar 19, 2013 at 01:08:35PM -0000, Paul Flo Williams wrote:
What do you mean, if and when? I can already see the next Release Name page shaping up with
"Motörhead's Moshpit is a name with non ASCII alphanumeric characters, like ..."
I'm voting for ☃.
Me, I'm pulling for "the release formerly known as Schrödinger's Cat".
Well, if you're going to yank the decided on release name, might as well just call it \0.
Bill
From: Bill Nottingham notting@redhat.com To: Development discussions related to Fedora
Date: 03/21/2013 09:52 Subject: Re: fedora release name problem Sent by: devel-bounces@lists.fedoraproject.org
J. Randall Owens (jrowens.fedora@ghiapet.net) said:
On 03/19/2013 09:22 AM, Richard W.M. Jones wrote:
On Tue, Mar 19, 2013 at 01:08:35PM -0000, Paul Flo Williams wrote:
What do you mean, if and when? I can already see the next Release
Name
page shaping up with
"Motörhead's Moshpit is a name with non ASCII alphanumeric
characters,
like ..."
I'm voting for ☃.
Me, I'm pulling for "the release formerly known as Schrödinger's Cat".
Well, if you're going to yank the decided on release name, might as well
just
call it \0.
Bill
Ooh, then F20 could then be called "1 / \0" ... the inverse of null, or the "everything" release. And switch to a rolling release at that point too just to complete the paradigm.
-- John Florian
On 03/19/2013 08:08 AM, Paul Flo Williams wrote:
Jaroslav Reznik wrote:
----- Original Message -----
Once upon a time, G.Wolfe Woodbury redwolfe@gmail.com said: submit a Feature and do proper testing/bug fixing/etc. for a future release (if and when another name with non ASCII alphanumeric characters is chosen).
+1!
Jaroslav
What do you mean, if and when? I can already see the next Release Name page shaping up with
"Motörhead's Moshpit is a name with non ASCII alphanumeric characters, like ..."
To avoid trademark issues, there's always Heavy Metal Umlaut (dressed up with both appropriate and gratuitous umlauts, of course).
- Michael
----- Original Message -----
On 18/03/13 10:22 PM, Toshio Kuratomi wrote:
On Mon, Mar 18, 2013 at 05:56:28PM -0700, Adam Williamson wrote:
On Mon, 2013-03-18 at 18:34 -0600, Kevin Fenzi wrote:
On Mon, 18 Mar 2013 23:56:28 +0000 Sérgio Basto sergio@serjux.com wrote:
Hi, For the first time, Fedora release name have non-ascii and pelican characters which https://bugzilla.redhat.com/show_bug.cgi?id=922433
Could we consider change release name from "Schrödinger's Cat" to "Schrodingers Cat" or other name that not have this additional problem ?
I'd rather we fix things to handle this case than paper it over by changing it.
+1
I would very much like that we paper it over right now, unless you propose to discover and fix every single problem it causes by tomorrow, when I want us to start rolling TC images.
If by right now you mean until we get TC out (or even until we get alpha out), I wouldn't be opposed to that. These sort of bugs really are something that need to be fixed and this release name is a good candidate for doing so... but the time from alpha to beta is appropriate for fixing bugs so it's okay if we defer fixing them for a little while.
-Toshio "who's been working on various iterations of a fix for this in the python3 package[1] for a few days" Kuratomi
Well, look, my point is that sometimes our commitment to 'fixing things the right way' appears to verge on bloody masochism.
You want to set up a side project to spin some images with crazy release names and see what breaks and fix that, then you know, go for it. But I'm trying to ship an operating system that works here, and leaving something we know is causing all kinds of problems in the problematic state just so we can keep finding exciting new problems to fix does not suffuse me with joy.
If we have to compromise on just papering it over for Alpha, I mean, _fine_. But seriously: sometimes papering it over is just the right thing to do.
I'd say - go with the current one and fix all possible bugs OR change it (and well, I prefer this solution as we really need working composes soon for other devs and I'm really glad for more integration/stabilization time between branching and freeze!) but not both. If we change it for Alpha, fix bugs we are aware of now, we will hit new bugs during Beta cycle for sure...
On the other hand - I really think we should fix it but it's probably longer term run - we know that umlaut and ' are not a good citizens in release name but there are probably much more combinations we could hit in the future...
To make it short: de-internationalize release name, stick with it for final.
Jaroslav
-- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Mon, 2013-03-18 at 23:11 -0700, Adam Williamson wrote:
On 18/03/13 10:22 PM, Toshio Kuratomi wrote:
On Mon, Mar 18, 2013 at 05:56:28PM -0700, Adam Williamson wrote:
On Mon, 2013-03-18 at 18:34 -0600, Kevin Fenzi wrote:
On Mon, 18 Mar 2013 23:56:28 +0000 Sérgio Basto sergio@serjux.com wrote:
Hi, For the first time, Fedora release name have non-ascii and pelican characters which https://bugzilla.redhat.com/show_bug.cgi?id=922433
Could we consider change release name from "Schrödinger's Cat" to "Schrodingers Cat" or other name that not have this additional problem ?
I'd rather we fix things to handle this case than paper it over by changing it.
+1
I would very much like that we paper it over right now, unless you propose to discover and fix every single problem it causes by tomorrow, when I want us to start rolling TC images.
If by right now you mean until we get TC out (or even until we get alpha out), I wouldn't be opposed to that. These sort of bugs really are something that need to be fixed and this release name is a good candidate for doing so... but the time from alpha to beta is appropriate for fixing bugs so it's okay if we defer fixing them for a little while.
-Toshio "who's been working on various iterations of a fix for this in the python3 package[1] for a few days" Kuratomi
Well, look, my point is that sometimes our commitment to 'fixing things the right way' appears to verge on bloody masochism.
You want to set up a side project to spin some images with crazy release names and see what breaks and fix that, then you know, go for it. But I'm trying to ship an operating system that works here, and leaving something we know is causing all kinds of problems in the problematic state just so we can keep finding exciting new problems to fix does not suffuse me with joy.
If we have to compromise on just papering it over for Alpha, I mean, _fine_. But seriously: sometimes papering it over is just the right thing to do.
(nods)
If we were *really* masochistic, the release name would contain unicode code points from outside the BMP i.e. > 65535 e.g. the musical notation characters.
I, for one, am not that masochistic.
Dave
On Tue, Mar 19, 2013 at 10:47 AM, David Malcolm dmalcolm@redhat.com wrote:
On Mon, 2013-03-18 at 23:11 -0700, Adam Williamson wrote:
On 18/03/13 10:22 PM, Toshio Kuratomi wrote:
On Mon, Mar 18, 2013 at 05:56:28PM -0700, Adam Williamson wrote:
On Mon, 2013-03-18 at 18:34 -0600, Kevin Fenzi wrote:
On Mon, 18 Mar 2013 23:56:28 +0000 Sérgio Basto sergio@serjux.com wrote:
Hi, For the first time, Fedora release name have non-ascii and pelican characters which https://bugzilla.redhat.com/show_bug.cgi?id=922433
Could we consider change release name from "Schrödinger's Cat" to "Schrodingers Cat" or other name that not have this additional problem ?
I'd rather we fix things to handle this case than paper it over by changing it.
+1
I would very much like that we paper it over right now, unless you propose to discover and fix every single problem it causes by
tomorrow,
when I want us to start rolling TC images.
If by right now you mean until we get TC out (or even until we get
alpha
out), I wouldn't be opposed to that. These sort of bugs really are something that need to be fixed and this release name is a good
candidate
for doing so... but the time from alpha to beta is appropriate for
fixing
bugs so it's okay if we defer fixing them for a little while.
-Toshio "who's been working on various iterations of a fix for this in
the
python3 package[1] for a few days" Kuratomi
Well, look, my point is that sometimes our commitment to 'fixing things the right way' appears to verge on bloody masochism.
You want to set up a side project to spin some images with crazy release names and see what breaks and fix that, then you know, go for it. But I'm trying to ship an operating system that works here, and leaving something we know is causing all kinds of problems in the problematic state just so we can keep finding exciting new problems to fix does not suffuse me with joy.
If we have to compromise on just papering it over for Alpha, I mean, _fine_. But seriously: sometimes papering it over is just the right thing to do.
(nods)
If we were *really* masochistic, the release name would contain unicode code points from outside the BMP i.e. > 65535 e.g. the musical notation characters.
I, for one, am not that masochistic.
Dave
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
It wouldn't be so bad. Just have everything BuildRequires: lilypond. . .
-J
While this doesn't solve unicode-releated problems with /etc/os-release or /etc/fedora-release, for example, it does mean that we won't have problems with parsing this through shell scripts, which we do quite often.
Signed-off-by: Peter Jones pjones@redhat.com --- fedora-release.spec | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fedora-release.spec b/fedora-release.spec index 408feff..0791715 100644 --- a/fedora-release.spec +++ b/fedora-release.spec @@ -1,4 +1,4 @@ -%define release_name Schrödinger's Cat +%define release_name Schrödinger’s Cat %define dist_version 19
Summary: Fedora release files
On Tue, 2013-03-19 at 11:57 -0400, Peter Jones wrote:
While this doesn't solve unicode-releated problems with /etc/os-release or /etc/fedora-release, for example, it does mean that we won't have problems with parsing this through shell scripts, which we do quite often.
Signed-off-by: Peter Jones pjones@redhat.com
Can't possibly be worse than what we have.
Reviewed-by: Adam Jackson ajax@redhat.com
- ajax
While this doesn't solve unicode-releated problems with /etc/os-release or /etc/fedora-release, for example, it does mean that we won't have problems with parsing this through shell scripts, which we do quite often.
This uses /Punctuation apostrophe/, U+2019, which is the preferred unicode character for a displayed apostrophe, as opposed to /typewriter apostrophe/, U=0027, which is also the shell quote character.
Signed-off-by: Peter Jones pjones@redhat.com Reviewed-by: Adam Jackson ajax@redhat.com --- fedora-release.spec | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fedora-release.spec b/fedora-release.spec index 408feff..0791715 100644 --- a/fedora-release.spec +++ b/fedora-release.spec @@ -1,4 +1,4 @@ -%define release_name Schrödinger's Cat +%define release_name Schrödinger’s Cat %define dist_version 19
Summary: Fedora release files
On Tue, Mar 19, 2013 at 1:07 PM, Peter Jones pjones@redhat.com wrote:
While this doesn't solve unicode-releated problems with /etc/os-release or /etc/fedora-release, for example, it does mean that we won't have problems with parsing this through shell scripts, which we do quite often.
This uses /Punctuation apostrophe/, U+2019, which is the preferred unicode character for a displayed apostrophe, as opposed to /typewriter apostrophe/, U=0027, which is also the shell quote character.
Signed-off-by: Peter Jones pjones@redhat.com Reviewed-by: Adam Jackson ajax@redhat.com
I applied this to the fedora-release package and pushed the fix out.
josh
Thanks, pulled in upstream, build is issued will go out tomorrow
Dennis On mar, 2013-03-19 at 13:07 -0400, Peter Jones wrote:
While this doesn't solve unicode-releated problems with /etc/os-release or /etc/fedora-release, for example, it does mean that we won't have problems with parsing this through shell scripts, which we do quite often.
This uses /Punctuation apostrophe/, U+2019, which is the preferred unicode character for a displayed apostrophe, as opposed to /typewriter apostrophe/, U=0027, which is also the shell quote character.
Signed-off-by: Peter Jones pjones@redhat.com Reviewed-by: Adam Jackson ajax@redhat.com
fedora-release.spec | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fedora-release.spec b/fedora-release.spec index 408feff..0791715 100644 --- a/fedora-release.spec +++ b/fedora-release.spec @@ -1,4 +1,4 @@ -%define release_name Schrödinger's Cat +%define release_name Schrödinger’s Cat %define dist_version 19
Summary: Fedora release files
1.8.1.4
On 19/03/13 08:57 AM, Peter Jones wrote:
While this doesn't solve unicode-releated problems with /etc/os-release or /etc/fedora-release, for example, it does mean that we won't have problems with parsing this through shell scripts, which we do quite often.
Signed-off-by: Peter Jones pjones@redhat.com
+1: the distinction Peter makes between the single quote and the umlaut is a valid and important one. I would still prefer we just go plain ASCII, but if we're not going to do that, we absolutely _should_ do what Peter suggests.
----- Original Message -----
On 03/19/13 01:56, Adam Williamson wrote:
This bug just *smells* like one of those which will pop up again and again and again causing carnage wherever it shows up.
Shouldn't be worse than F18 where we slipped how many weeks? Or was it even months in the end?
The difference is between slipping for a real reason - new installer, updater, SB or nitpicking on release name. Definitely, we should not hide the issue - bugs are already reported but it does not make sense to shoot ourself to knees when we have a possible solution.
Jaroslav
cheers, Gerd
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On 19/03/13 02:22 AM, Gerd Hoffmann wrote:
On 03/19/13 01:56, Adam Williamson wrote:
This bug just *smells* like one of those which will pop up again and again and again causing carnage wherever it shows up.
Shouldn't be worse than F18 where we slipped how many weeks? Or was it even months in the end?
Of course not, but that's kinda different. In the one case, the long slip bought us an entirely rewritten installer. In this case, any potential slip buys us...a prettified release name. Gee, willikers, watch me trying to restrain my excitement.
Adam Williamson wrote:
Of course not, but that's kinda different. In the one case, the long slip bought us an entirely rewritten installer. In this case, any potential slip buys us...a prettified release name. Gee, willikers, watch me trying to restrain my excitement.
In any case, what this teaches us is that release names are not "harmless fun" as the fans of continuing with release names have repeatedly claimed. This pointless "fun" has a real cost. In this case, it actually PREVENTED SYSTEMS FROM BOOTING! And once this got worked around, we're still wasting time trying to fix issues with non-ASCII characters in the release name. Not to mention all the time wasted discussing the nonsense.
Let's drop release names NOW (ideally immediately, before the F19 release)! The harmFUL "fun" is not worth the harm it causes.
If some tools expect a release name, just use Nineteen as the release name.
Kevin Kofler
On Qui, 2013-03-28 at 21:22 +0100, Kevin Kofler wrote:
Adam Williamson wrote:
Of course not, but that's kinda different. In the one case, the long slip bought us an entirely rewritten installer. In this case, any potential slip buys us...a prettified release name. Gee, willikers, watch me trying to restrain my excitement.
In any case, what this teaches us is that release names are not "harmless fun" as the fans of continuing with release names have repeatedly claimed. This pointless "fun" has a real cost. In this case, it actually PREVENTED SYSTEMS FROM BOOTING! And once this got worked around, we're still wasting time trying to fix issues with non-ASCII characters in the release name. Not to mention all the time wasted discussing the nonsense.
Let's drop release names NOW (ideally immediately, before the F19 release)! The harmFUL "fun" is not worth the harm it causes.
If some tools expect a release name, just use Nineteen as the release name.
I agree with you , some tool are design to work with ASCII as in nineties and don't see any advantage of release name becomes UTF-8 strings.
Sérgio Basto <sergio <at> serjux.com> writes:
For the first time, Fedora release name have non-ascii and pelican characters which https://bugzilla.redhat.com/show_bug.cgi?id=922433
Could we consider change release name from "Schrödinger's Cat" to "Schrodingers Cat" or other name that not have this additional problem ?
If we do, shouldn't there be another vote asking if it's okay to make this change, in light of the possible release delay? It's not the name that was originally voted for. (I'm not trying to be difficult - I was one of those who voted against having a release name, based on the belief that it was a waste of time, although I didn't imagine that the waste would include QA and developers.)
If the release name only needs to apply to the Final release, the name could be temporarily changed to "Schrodingers Cat" for Alpha if it takes longer to hold the vote.
On Mon, Mar 18, 2013 at 10:44 PM, Andre Robatino robatino@fedoraproject.org wrote:
Sérgio Basto <sergio <at> serjux.com> writes:
For the first time, Fedora release name have non-ascii and pelican characters which https://bugzilla.redhat.com/show_bug.cgi?id=922433
Could we consider change release name from "Schrödinger's Cat" to "Schrodingers Cat" or other name that not have this additional problem ?
If we do, shouldn't there be another vote asking if it's okay to make this change, in light of the possible release delay? It's not the name that was originally voted for. (I'm not trying to be difficult - I was one of those who voted against having a release name, based on the belief that it was a waste of time, although I didn't imagine that the waste would include QA and developers.)
If the release name only needs to apply to the Final release, the name could be temporarily changed to "Schrodingers Cat" for Alpha if it takes longer to hold the vote.
I suppose "Greebo" is right off the list? To go along with the Ogg Vrobis, and other Terry Pratchett references? To quote a Terry Pratchett story, the possible staes of a cat in a box are actually "alive, dead, or bloody furious", which is what the developers are going to be when they encounter extraneous punction in basic system configuration files. They files are being parsed by /bin/sh in ./configure scripts and Makefiles, not a complex data format.
On Mar 18, 2013, at 8:44 PM, Andre Robatino robatino@fedoraproject.org wrote:
If we do, shouldn't there be another vote asking if it's okay to make this change, in light of the possible release delay?
Definitely not. There is equivalent that doesn't require apostrophe or umlaut (diaeresis) characters. Legal will have a far less difficult time with this than flat out incorrect spellings, or new names.
It's not the name that was originally voted for.
Schrodinger is not the man's name, and is the wrong solution. Schroedinger is as acceptable as Schrödinger.
If the release name only needs to apply to the Final release, the name could be temporarily changed to "Schrodingers Cat" for Alpha if it takes longer to hold the vote.
I disagree any duration of the incorrect spelling of a surname is acceptable. For a private/closed project it might be tolerated for internal distribution only, but I'm skeptical. For a public project I don't think it's appropriate.
Chris Murphy
Dne 19.3.2013 04:05, Chris Murphy napsal(a):
On Mar 18, 2013, at 8:44 PM, Andre Robatino robatino@fedoraproject.org wrote:
If we do, shouldn't there be another vote asking if it's okay to make this change, in light of the possible release delay?
Definitely not. There is equivalent that doesn't require apostrophe or umlaut (diaeresis) characters. Legal will have a far less difficult time with this than flat out incorrect spellings, or new names.
It's not the name that was originally voted for.
Schrodinger is not the man's name, and is the wrong solution. Schroedinger is as acceptable as Schrödinger.
Yes, definitely Schroedinger if Schrödinger does not work.
Vít
On Tue, 2013-03-19 at 10:01 +0100, Vít Ondruch wrote:
Dne 19.3.2013 04:05, Chris Murphy napsal(a):
On Mar 18, 2013, at 8:44 PM, Andre Robatino robatino@fedoraproject.org wrote:
If we do, shouldn't there be another vote asking if it's okay to make this change, in light of the possible release delay?
Definitely not. There is equivalent that doesn't require apostrophe or umlaut (diaeresis) characters. Legal will have a far less difficult time with this than flat out incorrect spellings, or new names.
It's not the name that was originally voted for.
Schrodinger is not the man's name, and is the wrong solution. Schroedinger is as acceptable as Schrödinger.
Yes, definitely Schroedinger if Schrödinger does not work.
Could it be a Cat of Schroedinger perhaps?
On Mon, 2013-03-18 at 23:56 +0000, Sérgio Basto wrote:
Could we consider change release name from "Schrödinger's Cat" to "Schrodingers Cat" or other name that not have this additional problem ?
In my opinion, it makes sense to distinguish between code and content.
When compared with 10-15 years ago, it's my perception that most applications that nowadays process user visible content are able to deal with international characters. This is a great advancement.
However, code is usually limited to ASCII. We cannot use Umlauts in variable names in most programming languages. It's no surprise to me that many programmer tools have similar limitation.
The Fedora release name is part of the code, and also used by programmer or administrative tools to process it. What we are facing here is the question: "Are we ready to introduce non-ASCII characters into the code and tool level?".
It seems like the answer is "not yet".
While I agree it cannot hurt to be able to support umlauts and special characters everywhere, supporting it at the code and tool level seems like a challenge, as we are learning. I don't agree to that argument that it must be fixed immediately, because it's not required to correctly process user visible content.
And if you are looking for a more formal justification:
"Consistently support international and special characters in Fedora release tools" sounds like a Fedora Feature to me. But we are already past the Feature Freeze date. So, if you would like to see this as a priority, then propose to make it a future Fedora Feature and offer to work on it. But for this round, it seems too late.
I'd like to propose a compromise for the release name.
From http://en.wikipedia.org/wiki/Schr%C3%B6dinger%27s_cat I'm learning
that Schrödinger was Austrian. Austria uses German language.
The german equivalent of "Schrödinger's Cat" is "Schrödingers Katze". No apostrophe is being used here. http://de.wikipedia.org/wiki/Schr%C3%B6dingers_Katze
And it's quite common to replace the ö umlaut with oe, for example in email addresses.
Because of the above, I propose that we use the following string for the Fedora 19 release name:
Schroedingers Katze
Regards Kai
For those who didn't scroll to the end of my previous message, I propose to use the name:
Schroedingers Katze
Kai
On Tue, Mar 19, 2013 at 12:57 PM, Kai Engert kaie@kuix.de wrote:
For those who didn't scroll to the end of my previous message, I propose to use the name:
Schroedingers Katze
Again no if we find bugs we should fix them not apply duct tape to hide them.
On Thu, 21 Mar 2013 21:49:34 +0100 Lars Seipel lars.seipel@gmail.com wrote:
On Tuesday 19 March 2013 12:57:46 Kai Engert wrote:
Schroedingers Katze
If Peter's patch isn't enough and we really have to change the name this is a nice solution I think.
But I don't know if changing the language is warranted.
Fedora 19 - Cat of Schroedinger
On Thu, 21 Mar 2013 23:03:46 +0200 Susi Lehtola wrote:
On Thu, 21 Mar 2013 21:49:34 +0100 Lars Seipel lars.seipel@gmail.com wrote:
On Tuesday 19 March 2013 12:57:46 Kai Engert wrote:
Schroedingers Katze
If Peter's patch isn't enough and we really have to change the name this is a nice solution I think.
But I don't know if changing the language is warranted.
Fedora 19 - Cat of Schroedinger
Is there a problem with Schroedinger acting effectively as an adjective (as in many other QM terminology, like e.g. Schrödinger equation, Schrödinger field, Schrödinger picture)?
Schroedinger Cat sounds much more natural then Cat of Schroedinger...
http://en.wikipedia.org/wiki/Schroedinger_cat Of course, only if there are more problems than with just *'*.
Regards, Martin
On Mar 21, 2013, at 3:22 PM, Martin Sourada martin.sourada@gmail.com wrote:
Schroedinger Cat sounds much more natural then Cat of Schroedinger…
Except it's linguistically incorrect. Cat of Schroedinger is genitive case, as is Schroedinger's Cat. And although the alternative is uncommon in English, it's still correct. It's common in German. Schroedinger Cat is wrong. Schroedingers Cat is wrong.
Chris Murphy
On 2013-03-21 15:40 (GMT-0600) Chris Murphy composed:
Martin Sourada wrote:
Schroedinger Cat sounds much more natural then Cat of Schroedinger…
Except it's linguistically incorrect. Cat of Schroedinger is genitive case, as is Schroedinger's Cat. And although the alternative is uncommon in English, it's still correct. It's common in German. Schroedinger Cat is wrong. Schroedingers Cat is wrong.
Fesco's simply naming its child. If birth certificate entries are any indication, there is no such thing as misspelling a name prior to it's having been officially recorded. In this case, I would think that point in time would be announcement of official F19 release.
IMO, if you want a name that will commonly be seen in print misspelled, and that many would have no clue how to type correctly with common keyboards (if that's even possible), keep the diacritic. If not, a spelling including oe instead makes good sense, with or without of or s or apostrophe.
On 03/21/2013 05:40 PM, Chris Murphy wrote:
On Mar 21, 2013, at 3:22 PM, Martin Sourada martin.sourada@gmail.com wrote:
Schroedinger Cat sounds much more natural then Cat of Schroedinger…
Except it's linguistically incorrect. Cat of Schroedinger is genitive case, as is Schroedinger's Cat. And although the alternative is uncommon in English, it's still correct. It's common in German. Schroedinger Cat is wrong. Schroedingers Cat is wrong.
The obvious solution is to have the name of the release be the superposition of "Schrödinger's Cat" and "Schrodingers Cat", and hope that the waveform collapses to the former version when it is observed on the wiki and in emails, but to the latter version when it is observed in files that are parsed programmatically.
-- Dan
On Thu, 21 Mar 2013 15:40:06 -0600 Chris Murphy wrote:
On Mar 21, 2013, at 3:22 PM, Martin Sourada martin.sourada@gmail.com wrote:
Schroedinger Cat sounds much more natural then Cat of Schroedinger…
Except it's linguistically incorrect. Cat of Schroedinger is genitive case, as is Schroedinger's Cat. And although the alternative is uncommon in English, it's still correct. It's common in German. Schroedinger Cat is wrong. Schroedingers Cat is wrong.
Yes, I know there's difference between Schroedinger's Cat (who's cat) and Schroedinger Cat (which cat), but both are correct English and both are acceptable names for the thought experiment. Schroedingers Cat is however wrong on much more fundamental basis so that's out of question automatically.
Since this is release name I would go for something with minute difference to the original meaning, but still sounding good, than with awkward (but correct and having the same meaning) paraphrase. But that's my humble opinion.
Martin
On 22 March 2013 22:02, Martin Sourada martin.sourada@gmail.com wrote:
On Thu, 21 Mar 2013 15:40:06 -0600 Chris Murphy wrote:
On Mar 21, 2013, at 3:22 PM, Martin Sourada martin.sourada@gmail.com wrote:
Schroedinger Cat sounds much more natural then Cat of Schroedinger…
Except it's linguistically incorrect. Cat of Schroedinger is genitive case, as is Schroedinger's Cat. And although the alternative is uncommon in English, it's still correct. It's common in German. Schroedinger Cat is wrong. Schroedingers Cat is wrong.
Yes, I know there's difference between Schroedinger's Cat (who's cat) and Schroedinger Cat (which cat), but both are correct English and both are acceptable names for the thought experiment. Schroedingers Cat is however wrong on much more fundamental basis so that's out of question automatically.
Since this is release name I would go for something with minute difference to the original meaning, but still sounding good, than with awkward (but correct and having the same meaning) paraphrase. But that's my humble opinion.
N.B. this discussion is hypothetical since FESCo decided to try and fix issues with the original name. I suppose hypothetical is still appropriate for discussion of this particular feline, there are many ways to skin a cat.
On Tue, Mar 19, 2013 at 11:49 AM, Kai Engert kaie@kuix.de wrote:
On Mon, 2013-03-18 at 23:56 +0000, Sérgio Basto wrote:
Could we consider change release name from "Schrödinger's Cat" to "Schrodingers Cat" or other name that not have this additional problem ?
In my opinion, it makes sense to distinguish between code and content.
When compared with 10-15 years ago, it's my perception that most applications that nowadays process user visible content are able to deal with international characters. This is a great advancement.
However, code is usually limited to ASCII. We cannot use Umlauts in variable names in most programming languages. It's no surprise to me that many programmer tools have similar limitation.
The Fedora release name is part of the code, and also used by programmer or administrative tools to process it. What we are facing here is the question: "Are we ready to introduce non-ASCII characters into the code and tool level?".
It seems like the answer is "not yet".
Which is a bug that needs to be fixed, it could even be a security bug (but you'd need to be root and would have other problems). The Fedora Release name is not part of the code how ever you try and spin it.
Ultimately there's no point putting a whole lot of points across. It comes down to two things: 1) FESCo deciding how they want to deal with it (I suggest changing it to ascii for alpha, and back straight after to ensure it has lots of testing up to beta) 2) when and how quickly the bug can be fixed.
The code is used by lots of other orgs all over the world, it needs to be robust.
Peter
Kai Engert wrote:
The Fedora release name is part of the code
Is it? What is its technical function then? What would break if two releases were to have the same name but different numbers? Are programs supposed to compare release names to determine which release they're looking at? All comparisons I've seen have used the number, not the name.
There have been discussions about dropping release names. The argument for that seemed to be that the name has no function and is mostly a waste of time. If the name were part of the code, then dropping it would have required code changes left and right.
As I understand it Fedora has release names because people like to see them displayed in various places. That means they are user-visible content.
Björn Persson
On 03/18/2013 11:56 PM, Sérgio Basto wrote:
For the first time, Fedora release name have non-ascii and pelican characters which https://bugzilla.redhat.com/show_bug.cgi?id=922433
Could we consider change release name from "Schrödinger's Cat" to "Schrodingers Cat" or other name that not have this additional problem ?
People wanted to continue to use release names and voted both on that topic and the name.
They also get the benefit of fixing what breaks in the process.
JBG
Hello.
I think it is really time for some authority to decide ASAP, taking into account that this is now (proposed) alpha blocker bug and the scope of the overall fix is still unknown.
I could not resist, sorry.
Brgds,
Eduard Vopicka
On Wed, 20 Mar 2013 21:28:49 +0100 "eduard.vopicka" eduard.vopicka@seznam.cz wrote:
Hello.
I think it is really time for some authority to decide ASAP, taking into account that this is now (proposed) alpha blocker bug and the scope of the overall fix is still unknown.
I could not resist, sorry.
"agreed leave name as is, fix issues as they arise (+6,0,0)"
https://fedorahosted.org/fesco/ticket/1102#comment:10
kevin
On Wed, 2013-03-20 at 21:28 +0100, eduard.vopicka wrote:
Hello.
I think it is really time for some authority to decide ASAP, taking into account that this is now (proposed) alpha blocker bug and the scope of the overall fix is still unknown.
I could not resist, sorry.
FESCo already did, this morning. It's in the minutes of their meeting, which were sent to this list. They decided we will stick with the current fedora-release (which leaves the ö in place, and makes the apostrophe a Unicode apostrophe rather than a single quote; this is enough to fix grub at least) for now and fix issues as they arise.
-
Adam Jackson -
Adam Williamson -
Andre Robatino -
Bastien Nocera -
Bill Nottingham -
Björn Persson -
Bruno Wolff III -
Chris Adams -
Chris Murphy -
Christof Damian -
Dan Winship -
David Malcolm -
David Woodhouse -
Dennis Gilmore -
drago01 -
eduard.vopicka -
Felix Miata -
Frank Murphy -
Gerd Hoffmann -
gil -
Gregory Woodbury -
Ian Malone -
J. Randall Owens -
Jan Engelhardt -
Jaroslav Reznik -
John Hutchison -
John.Florian＠dart.biz -
Jon Ciesla -
Josh Boyer -
Jóhann B. Guðmundsson -
Kai Engert -
Kaleb S. KEITHLEY -
Kevin Fenzi -
Kevin Kofler -
Lars Seipel -
Marc Deop Argemí -
Martin Sourada -
Michael Ekstrand -
Nico Kadel-Garcia -
Nicolas Mailhot -
Paul Flo Williams -
Peter Jones -
Peter Robinson -
Przemek Klosowski -
Ralf Corsepius -
Rich Megginson -
Richard W.M. Jones -
Roberto Ragusa -
Simo Sorce -
Susi Lehtola -
Sérgio Basto -
Thomas Moschny -
Tomas Mraz -
Toshio Kuratomi -
Vít Ondruch