Package name conflict: eina, the media player or optimized data types and useful tools for e-17.
Hi, I've tried to build e-17 by hand. When I try to build from eina from e-17, however, I found that the package name, eina, is already been taken by eina, the media player. How should I do with them? Regards, -- Ding-Yi Chen -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Proposal for voice data naming guide
I've tried out gcin's voice data, it's neat, interesting, and useful. Since it does not depend on gcin, I wish to pack it as an independent package, so other packages can use it. However, generally, what should we name it and other voice data? How about: voicedata Where * locale: Locale string like en_US, zh_CN... * generated_method: The algorithm or synthesizer that generate the voice, or "realperson" if the recorded voice is from a real person. * source: Name of the project or organization that provides the voice. * variant: Optional field for noticeable info, such as the person who provide the voice, or parameter of the synthesizer. Thus, according to the naming guild, gcin's voice data should be named as: voicedata-zh_TW-realperson-gcin-EdwardLiu Any comments? -- Ding-Yi Chen Software Engineer Internationalization Group Red Hat, Inc. Looking to carve out IT costs? www.apac.redhat.com/promo/carveoutcosts/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Proposal for voice data naming guide
I've tried out gcin's voice data, it's neat, interesting, and useful. Since it does not depend on gcin, I wish to pack it as an independent package, so other packages can use it. However, generally, what should we name it and other voice data? How about: voicedata Where * locale: Locale string like en_US, zh_CN... * generated_method: The algorithm or synthesizer that generate the voice, or "realperson" if the recorded voice is from a real person. * source: Name of the project or organization that provides the voice. * variant: Optional field for noticeable info, such as the person who provide the voice, or parameter of the synthesizer. Thus, according to the naming guild, gcin's voice data should be named as: voicedata-zh_TW-realperson-gcin-EdwardLiu Any comments? -- Ding-Yi Chen Software Engineer Internationalization Group Red Hat, Inc. Looking to carve out IT costs? www.apac.redhat.com/promo/carveoutcosts/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Last few orphans left
- "Jesse Keating" wrote: > There are only a few orphans left. I blocked all that weren't > causing > dep breakage, so these /really/ need a home or we need to block a few > more things beyond just the orphans. glade2 is on this list because > it > was just recently orphaned. > > Unblocked orphan tomoe > I would take tomoe, and related package such as tomoe-gtk, scim-tomoe. Regards, -- Ding-Yi Chen Software Engineer Internationalization Group Red Hat, Inc. Looking to carve out IT costs? www.apac.redhat.com/promo/carveoutcosts/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphans on the chopping block for F12
於 二，2009-07-28 於 23:13 -0700，Jesse Keating 提到： > On Wed, 2009-07-29 at 08:00 +0200, Sven Lankes wrote: > > > > While it's arguably past UTC already the facts that the owner > > change worked and that the packages are still in cvs make me believe > > that your day isn't quite over yet. > > Nope not yet, although I think I'll give people until tomorrow to pick > things up. > > -- > fedora-devel-list mailing list > fedora-devel-list@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list Hi, I am sorry for the late reply, as I just back from vacation. May I still take the tomoe and scim-tomoe? People who need Japanese and Simplified Chinese handwriting might be upset if tomoe and scim-tomoe are left orphaned. Regards, -- Ding-Yi Chen Software Engineer Internationalization Group Red Hat, Inc. Looking to carve out IT costs? www.apac.redhat.com/promo/carveoutcosts/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Man pages need love from native speakers!
Currently I maintain man-pages-es, man-pages-it, and man-pages-ko. In terms of package maintenance, they are easy and requires low maintenance effort. These packages are also good for a novice packager to get use to the rpm spec. But since I speak none of them, it is better for them to be handled in better hands (and tongues). So, who wants them? -- Ding-Yi Chen Software Engineer Internationalization Group Red Hat, Inc. Looking to carve out IT costs? www.apac.redhat.com/promo/carveoutcosts/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
於 三，2009-07-08 於 11:37 +0200，Kevin Kofler 提到： > Ding Yi Chen wrote: > > Tell Denture your constraint and > > it will build packages if it can; or reasons why it cannot build. > > The word "build" there is another big fail. Users DO NOT WANT to build their > packages from source. If they did, they'd all be using Gentoo! Users with rpm building knowledge can build. Users came from FreeBSD and Gentoo are familar with build. Even those ex-Windows users, if there is good GUI that only require you to click on "Next" or "Ok", they don't mind to build. *Sign*, well, How about following prompt: Denture will build the package for you, however, in order to do so, it will consume cpu time, disk space, network bandwidth, proceed? -- Ding-Yi Chen Software Engineer Internationalization Group Red Hat, Inc. Looking to carve out IT costs? www.apac.redhat.com/promo/carveoutcosts/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
- "John5342" wrote: > 2009/7/8 Ding Yi Chen : > > > I don't think this has anything to do with motivation. You have an > idea and on the face of it it sounds great but even the greatest > ideas > can be doomed by the details. If you don't believe me (or Kevin) then > go for it and when you get to the details you will see exactly what > we > are talking about. We are simply trying to save you the time. You have good deed. But it does not help by simply saying everything break. As I do have some example to break your claim. :-) I would like to know, specifically, what packages did you tried and optionally, why did they fail? > And if you develop ad-hoc logic (which i had too) which is required > for it to come even close to working then who is going to maintain > the > data that drives this ad-hoc logic? If you think the users will then > you are likely wrong because the same people who are capable of > helping with this will find it less effort just to use the latest > release and build some compatibility packages for the older stuff. If nobody is willing to provide sufficient data for the ad-hoc logic, then those packages should be black-listed. > First of all that largely wouldnt be possible for your proposal. You > also cant account for differences between releases (different > releases > can have the same version but entirely different features and > dependencies). I actually encountered the dependency issue you stated. but I've solved that before, and I don't think it is impossible to convert my steps to code. > Also minimum versions probably aren't enough. You would > also need maximum versions to make your proposal work. I've consider that (thus the data file that keep the "correct" dependency), but thanks anyway. You may asked how this data file be generated. Well, at infant stage, it needs to be filled by the early adopters who crush into bugs. You are free to join the data file building. Don't use Denture if you are uncomfortable with that. > You clearly don't know how many ways a package can fail. There are a > lot of subtle advantages provided by the flow of updates during a > release but Denture will be completely and utterly outside those > comfortable walls. Package fails in old releases and current releases. But it's not end of world. Either file bug reports, fix it yourself, find alternative ones that do the same thing, or live with it. Given it's experimental nature, don't use Denture on the packages that is critical to your life, job or other thing you value much. Use Denture on the packages that, "It's good to have, but can live without it." Perhaps that's why I haven't yet got bitten by extra bugs. > If you really want a run down of some of the issues you will run into > i can provide although i don't think the list is the place for them. Please mail me the issues that you encountered. Appreciated. > > I can also tell you the far simpler and more effective solution i > came > up with for your use case. It is also a frankly much more efficient > use of the time. Instead create a program to generate side by side > installable packages. Then you can use the latest release with all > its > features but your old programs that works better on an older Fedora > has all the libs it needs to run. The whole concept is more > efficient, > easier to test, less likely to break systems, less dependent on the > user, the type of user in your use case could deal with it more > easily, etc and it also covers most of your use cases on your blog. I am interested in what you said, what do you mean "side by side"? -- Ding-Yi Chen Software Engineer Internationalization Group Red Hat, Inc. Looking to carve out IT costs? www.apac.redhat.com/promo/carveoutcosts/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
- "John5342" wrote: > > Firstly, not all people turn the automatic upgrade on. > > Secondly, there are folks use rpm -hiv or build from srpm. > > In that case, they are more likely to spot the bugs. > > I am not talking about upgrades. I am talking about updates. Most > people just run updates when packagekit (or similar) tells them to. > In > a proper release updates are released together. In Denture they will > be updated out of order and from various different releases. As for > people rebuilding from srpms etc they represent a minority and it is > in any case irrelevant. What you said is true, but since what Denture is for unsupported released, which is unlikely getting any updated. Your case is not suitable for unsupported release. > > If what you said is completely true, I would not even bother to > propose Denture. :-) > > What i said is plain and simple fact. The scenario i mentioned is one > of several points of failure. I am not suggesting it is a problem > with Denture itself but it is a problem with the real world. Thats just > life. But the fact does not cover all packages, so that's why I need Denture, and take the risk. That's also life. :-) > This isn't about whether Y-1.3 will be pulled in. If you do what the > vast majority of users do then you will get the equivelant of yum > update. Regardless of whether X-1.3 explicitly specifies Y-1.3. Y-1.3 > will still be updated siply because there is a later version. When > you > update using Denture however you could easily end up with X-1.3 and > Y-1.2 for any number of reasons. Yes I could hit the bump, so are the guys that using source build and other distribution which have not yet put Y-1.3 to their repos. > > So do other package managers. > > Tell me, why are you so sure that the current version packages > > don't break the system secretly and user and the package managers > > has no way of knowing until it is too late? > > If you read all i wrote then you will find that has been answered > thoroughly already. I also states my justification why the packages should specify the exact depended versions. > You have found the exceptions there. Try looking at some others. I see. What I mainly need Denture help is for end-user applications. I am not quite sure about using Denture for library or toolkit directly. > I am sure even your dependency versions become stale. Taking your > example of dvdauthor > BuildRequires: libpng-devel > BuildRequires: flex > BuildRequires: bison > BuildRequires: fribidi-devel > BuildRequires: freetype-devel > BuildRequires: GraphicsMagick-devel > BuildRequires: autoconf automake gettext-devel > > In a single release you perhaps can be pretty sure that the versions > in the build root are good enough to satisfy dvdauthor. If on the > other hand you end up with a version of one of these packages from a > previous release due to blacklisting then things may well start to > break. > > Would you however insist that all of these are bugs? Mmm, BuildRequires: libdvdread-devel >= 0.9.4-4 BuildRequires: libxml2-devel >= 2.6.0 Without these, dvdauthor might break even within current release. You were saying that version is not important? :-) Nevertheless, you raise a valid point that version information is sometime unavailable or unreliable. But this can be overcome by a datafile that stores correct version. > The result could be great but i can be pretty sure that the actually > stability of a partially updated system is probably much worse than > rawhide and people who are happy with that level of stability would > ore than likely just prefer actual recent release For people who requires absolute stable, they can just use CentOS/ RHEL and totally ignore Denture. Denture is for the people that need to keep some critical packages, but wouldn't mind to take some risk. :-) > I like the idea because the concept is great. The idea that you can > run whatever version of whatever package you want and get the best of > all worlds is a nice dream but unfortunately i also know that it is > only a dream and in real life it simply can't work because the huge > requirements that Denture would place on packaging just can't be > done. "Whatever" is possibly the problem. Denture only eats what it can eat. :-) According to my experience, some of the dreams can come true. > When i was working on my project i quickly realised that for the > reasons i have been trying to explain (falling on deaf ears > apparently). Please don't assume that I am not aware your concerns. Did you see my answers about them? > I really wish you all the best. I really do. I would love to be > surprised and see it work but i won'
Re: Keyboard US Internacional
- "Rodrigo Padula de Oliveira" wrote: > Hello guys. > > How can we add gtk2-immodules and gtk2-immodule-xim by default in a > PT_BR Fedora installation ? > > We need to correct this problem ASAP for Fedora 10 ,11 and rawhide > > We are receiving a lot of claims about this problem in Brazilian lists > > and forum. > > Bugzilla entry: https://bugzilla.redhat.com/show_bug.cgi?id=505100 > > Thanks! How about adding gtk2-immodules and gtk2-immodule-xim in Portuguese support? -- Ding-Yi Chen Software Engineer Internationalization Group Red Hat, Inc. Looking to carve out IT costs? www.apac.redhat.com/promo/carveoutcosts/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
- "Kevin Kofler" wrote: > Ding-Yi Chen wrote: > > Therefore, I would like to propose an alternative approach, > > namely, project Denture. See my blog post for further information: > > http://dingyichen.livejournal.com/14055.html > > > > Any comments? > > As I've tried to explain to you last time you proposed that approach > on your > blog, that approach is completely broken by design and cannot work. > Please > go back to those blog posts and reread my comments. John5432's replies > here > also point out the issues. I know what you were saying, but like I said to you: I have such system, I have motivation, I put some effort to try, and I succeed. I know some can be done and some would have serious consequences. You, on the other hand, don't have such motivation, never tried seriously, thus you think everything tend to be broken. :-) > For example, you suggest blacklisting qt because of the renames, but > that > means NO Qt/KDE app can be upgraded to a supported version. (Fedora 8, > the > last release prior to the renames, is no longer supported.) If what you require is the latest Qt/KDE, then you may remove it from black-listed. But mind you, unless you know what you are doing and deal with it carefully, such action will break KDE3 apps such as kbabel. Of course, you can develop an ad-hoc logic for Denture to deal this problem, but currently I have no plan for it. > > You'll find that many of the packages you'll want to upgrade won't > work > because of some blacklisted dependency, I know. I wish IBus can run on RHEL5, but it cannot because it requires Python 2.5. I also know that Denture can tell me that such install/upgrade is not possible unless I remove Python form black-list and face all the consequences. > and even where they appear to > work, > they might not actually work (see also John5432's point about > unspecified minimum version dependencies). If that is the case, either file a bug to the package owners and ask them to correct the minimum version dependencies if the package version is covered by current supported released; or to Denture to override. > There's no way to just use the packages > from > a newer distribution on an older one, we have separate branches for a > reason, there's no way around them. And your idea of cherry-picking > individual packages for upgrading is just unsupportable. Some packages can support the certain older releases, some packages don't. Blindly assuming all package versions can work with older releases will surely fail. Tell Denture your constraint and it will build packages if it can; or reasons why it cannot build. -- Ding-Yi Chen Software Engineer Internationalization Group Red Hat, Inc. Looking to carve out IT costs? www.apac.redhat.com/promo/carveoutcosts/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
- "John5342" wrote: > 2009/7/7 Ding-Yi Chen : > > > > 於 二，2009-07-07 於 14:44 +0100，John5342 提到： > >> 2009/7/7 Ding-Yi Chen : > >> > > >> > Any comments? > >> > >> In theory your proposal sounds great but i see just one major flaw > >> that probably doesn't have a solution. Your idea of packages being > >> built based on dependencies should work great apart from the fact > that > >> most packages don't tend to have hard dependencies on versions. > >> Hypothetically in F11 package X-1.2.X relies on package Y-1.2. > Later > >> in the release cycle Y-1.3 is released followed later by X-1.3. > Eve > >> though X-1.3 actually requires Y-1.3 the maintainer probably never > >> thinks to update the required version (assuming there even was one > in > >> the first place). Now your system can easily fail. It picks X-1.3 > from > >> F-11 (because thats the latest one) but Y-1.3 isn't allowed > (because > >> one of its dependencies is black listed) so it falls back to Y-1.2 > >> which was the latest in F-10. Everything builds fine because they > are > >> source compatible but Y-1.2 doesnt have a crucial bug fixed. Now > your > >> software is broken. > > > > All systems have bugs and may break. So you don't use any of them? > :-) > > Of course all systems have bugs. However some are minor whilst others > are so much work to make them usable that they are simply not worth > it. Stuff that requires constant user intervention to cope with > scenarios that cannot be automated is one such major issue. > > > The scenario you raised could happen if not so many people use the > > package X. Otherwise, it would likely be spot by people who use > > yum update X, as Y-1.3 is not dragged in. > > Given X-1.3 is broken without Y-1.3, thus bug will likely be spot. > > Wouldn't be spotted until it is used in your system. It wouldn't be > used during standard usage because in a normal release both would be > updated at the same time (or at least in the right order) so the > scenario never happens. Firstly, not all people turn the automatic upgrade on. Secondly, there are folks use rpm -hiv or build from srpm. In that case, they are more likely to spot the bugs. > > Well, Y depends on black-listed packages doesn't mean Y cannot be > > upgraded at all. As long as the the newer Y does not require higher > > version of black-listed packages. > > Of course Y can be updated but not necessarily to the required > version. If the world was perfect all versions of packages would > contain the exact versions required for things to work and your > proposed system would either update fine or refuse to with a message > if a dependency is blacklisted or unavailable as a recent enough > version. > > However unfortunately for the same reasons i stated already virtually > no package will state the dependant versions accurately enough to do > what you want. If what you said is completely true, I would not even bother to propose Denture. :-) > > But if black-listed packages requires Y, or Y is black-listed, > > then Y will not be upgraded. > > In those cases, it is expected behavior that X should not be > upgraded to > > X-1.3 because Y cannot be upgraded to Y-1.3. > > That is of course assuming X-1.3 has an explicit dependency on Y-1.3. > It would be lovely if all packages has these versioned dependencies > and a lot have automatically due to things like sonames but take the > scenario where the soname is the same but the presence of the bug is > not. If X-1.3 does not specify Y-1.3 as dependency, I don't think yum update X will pull Y-1.3, even with the current version. Not to mention people who use rpm directly or build from srpm. So please file bug to X, don't blame Denture. > > Yes, you find out the limitation of Denture, but no, > > Denture is not broken. :-) > > Denture is not broken. Unfortunately though Denture only works in the > ideal world. In reality though scenarios like i just mentioned happen > all the time (along with many other similar issues) and the scenario > i > mentioned would break the users system and Denture has no way of > knowing until it is too late. So do other package managers. Tell me, why are you so sure that the current version packages don't break the system secretly and user and the package managers has no way of knowing until it is too late? > > >> Believe it or not i actually tried something similar for some of > my > >> internal servers and i like the idea but its impossible to get the > >> dependenci
Re: Feature proposal: Extended Life Cycle Support
於 二，2009-07-07 於 14:44 +0100，John5342 提到： > 2009/7/7 Ding-Yi Chen : > > > > Any comments? > > In theory your proposal sounds great but i see just one major flaw > that probably doesn't have a solution. Your idea of packages being > built based on dependencies should work great apart from the fact that > most packages don't tend to have hard dependencies on versions. > Hypothetically in F11 package X-1.2.X relies on package Y-1.2. Later > in the release cycle Y-1.3 is released followed later by X-1.3. Eve > though X-1.3 actually requires Y-1.3 the maintainer probably never > thinks to update the required version (assuming there even was one in > the first place). Now your system can easily fail. It picks X-1.3 from > F-11 (because thats the latest one) but Y-1.3 isn't allowed (because > one of its dependencies is black listed) so it falls back to Y-1.2 > which was the latest in F-10. Everything builds fine because they are > source compatible but Y-1.2 doesnt have a crucial bug fixed. Now your > software is broken. All systems have bugs and may break. So you don't use any of them? :-) The scenario you raised could happen if not so many people use the package X. Otherwise, it would likely be spot by people who use yum update X, as Y-1.3 is not dragged in. Given X-1.3 is broken without Y-1.3, thus bug will likely be spot. Well, Y depends on black-listed packages doesn't mean Y cannot be upgraded at all. As long as the the newer Y does not require higher version of black-listed packages. But if black-listed packages requires Y, or Y is black-listed, then Y will not be upgraded. In those cases, it is expected behavior that X should not be upgraded to X-1.3 because Y cannot be upgraded to Y-1.3. Yes, you find out the limitation of Denture, but no, Denture is not broken. :-) > Believe it or not i actually tried something similar for some of my > internal servers and i like the idea but its impossible to get the > dependencies right which makes the whole idea a no go. Believe it or not I actually tried something similar, but by hand though. I agree some maintainers does not accurately specify the dependency. but it is not beyond fix. One way to overcome this is maintaining a small datafile that contain the *true* dependency. Denture is not meant to be used to upgrade the whole system, but an automated tool to build a target package and corresponding mid-packages under specified constrain. So you only need to correct the dependencies of the target packages and mid-packages if you really need the target package. > > -- > There are 10 kinds of people in the world: Those who understand binary > and those who don't... > I like your signature. :-) -- Ding-Yi Chen Software Engineer Internationalization Group Red Hat, Inc. Looking to carve out IT costs? www.apac.redhat.com/promo/carveoutcosts/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
於 日，2009-07-05 於 12:32 +0200，Jeroen van Meeuwen 提到： > On 07/05/2009 12:12 PM, Jos Vos wrote: > > On Sun, Jul 05, 2009 at 12:03:05PM +0200, Jeroen van Meeuwen wrote: > > > >> The CentOS project, or it's upstream, has a release cycle of approximately > >> three years -not a steady release cycle of three years but that's what it > >> turns out to be. This disqualifies the distribution(s) as desktop Linux > >> distributions, as desktops tend to need to run the latest and greatest for > >> as far the latest and greatest lets them. > > > > I don't completely agree that "desktops tend to need to run the latest and > > greatest" (when we're talking about business desktops), but desktops > > (especially also when talking about laptops because of HW compatibilities) > > need newer software than RHEL offers, based on now 3 year old base versions > > of most packages (except Firefox and a few others). > > > > Agreed, I exaggerated a little there ;-) What I meant is they tend to > need to run the latest and greatest *compared* to servers, and as you > said, especially laptops and newer hardware. > > -- Jeroen > Usually, people stick with older releases because they like to keep some packages/applications which are known to works on those releases. On the other hand, they may still want to upgrade other packages to obtain security fixes or crucial features. But the problem is, there is no unanimous way to determine what packages to keep and what packages to update, so generic Fedora legacy repository might not provide much help for those people, who actually need the legacy support. Therefore, I would like to propose an alternative approach, namely, project Denture. See my blog post for further information: http://dingyichen.livejournal.com/14055.html Any comments? -- Ding-Yi Chen Software Engineer Internationalization Group Red Hat, Inc. Looking to carve out IT costs? www.apac.redhat.com/promo/carveoutcosts/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Kernel changes that may affect desktops
- "Matthew Garrett" wrote: > On Tue, Jun 30, 2009 at 05:48:44PM +0200, Kevin Kofler wrote: > > Matthew Garrett wrote: > > What changes are needed to the desktop? > > > > The big problem we've been facing integrating new features of core > system > > services into KDE so far was lack of documentation. What do we need > to > > change? > > An event will be generated and a policy agent then needs to choose > what > to do in terms of unmounting any media. The precise interface doesn't > > exist yet, but will be documented. > > > If this will be all handled within DeviceKit, then this will come by > itself > > with the Solid DeviceKit backend ltinkl is working on, but if we > need to > > add some desktop interaction for it, we have to know what it should > be. > > So, what you'll get is a notification that a block device has > requested > removal along with a notification that a dock device is being > undocked. > What you do with the block device is up to you, but in general you'll > > want to unmount it. Whether you're willing to kill applications that > have open files on it is a policy decision. After the unmount you'll > then trigger the completion of the undock and tell the user that it's > > now safe to remove their hardware. IMHO, it is pretty much similar to the way that we handle USB hubs and devices. In terms of UI, it may have a nice dock status icon to show status and to be pressed if users want to un-dock safely. Yet we still need to handle the force-undock event, just like we handle the forced unplug USB devices. -- Ding-Yi Chen Software Engineer Internationalization Group Red Hat, Inc. Looking to carve out IT costs? www.apac.redhat.com/promo/carveoutcosts/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
於 四，2009-06-04 於 07:23 +0200，Ralf Corsepius 提到：
> Steven M. Parrish wrote:
>
> > Many people have mentioned that it is not right to ask the users to file
> > their
> > bug reports upstream. I ask why not?
>
> Let me summarize what I already wrote elsewhere in this thread:
> * Users aren't necessarily developers.
> * Users aren't necessarily interested in getting involved upstream.
> * Users are reporting bugs against your product (your package in
> Fedora), not against upstream's work (somebody else's product).
>
>
> Let me try an analogy: How do you handle defects/malfunctions with your
> car?
>
> You'll visit your car dealer/a garage and report the issue to them.
> You'll expect them to identify the problem and to take appropriate steps
> to solve your issue. You don't expect them to direct you to the car's
> manufacturer or a component manufacturer and to discuss technical
> details you have no knowledge about with them ("Is the stuttering engine
> cause by triac 7 in a component A you haven't heard about before" or by
> the hall sensor in component B you also haven't heard about before).
Using your analogy:
If the car workshop does not have sufficient knowledge and material,
yes, that's right, the parts are ordered from upstream (the car
manufacturer).
If you want to, say, make a suggestion for your Ford, giving the
suggestion to the car workshop does not help much, unless it is one of
Ford's branch.
Some bugs need to go upstream, some bugs need not.
> Ralf
>
--
Ding-Yi Chen
Software Engineer
Internationalization Group
Red Hat, Inc.
Looking to carve out IT costs?
www.apac.redhat.com/promo/carveoutcosts/
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: List of packages including country flags
於 一，2009-05-25 於 08:54 +0200，Kevin Kofler 提到： > Ding-Yi Chen wrote: > > Unless there is a plan to complete the flags/icons for 83-78=5 layouts, > > it does not look consistent, does it? > > Those 5 layouts do not match a country, so it makes sense not to show any > flags for them. This is neither a real issue, nor an argument for removing > the remaining 78 flags. I prefer the consistence way. :-) > > QWERTY-- Default > > +-ja_JP > > +-ko_KR, > > +-de_CH > > +-fr_CH > > +-it_CH > > +-en_UK > > +... > > DVORAK-- > > QWERTZ-- > > +-de_CH > > +-de...@sundeadkey > > +-de...@nosundeadkey > > +-de...@mac > > +-fr_CH > > +-it_CH > > +... > > AZERTY--fr_FR > > +-fr_BE > > > > > > The benefits of this category systems are: > > 1. Input method developers only need to deal with the keys that matter > > (i.e. 0-9 and a-z) instead of go through the whole country list. > > 2. End users need fewer scroll for the first level category. > > 3. Reduce the redundancy: Many countries use essentially the standard > > QWERTY layout, no need to show all of them. > > 4. Flags can be assigned to the second level, either from the listing > > locale string or the regional setting. So Aussies, Kiwi, Singaporean can > > use their own flags (instead of American flags), everybody is happy. :-) > > Please propose these UI improvements to KDE upstream. They have nothing to > do with Fedora's policy on flags in any case. (You write yourself that > flags would still be useful, or even more useful, under that scheme.) > > Kevin Kofler I will bring up the key layout issue in i18n meeting first. Well, I myself did not against the flags, just want them to be informative and nobody should feel being left out. By the way, the keyboard icons should be customizable, so they can be flags, part of keyboards, pretty flowers or left blank for space/performance/political concerns. -- Ding-Yi Chen Software Engineer Internationalization Group Red Hat, Inc. Looking to carve out IT costs? www.apac.redhat.com/promo/carveoutcosts/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: List of packages including country flags
於 六，2009-05-23 於 19:26 +0200，Kevin Kofler 提到： > I know that countries and languages don't map 1:1 and that keyboard layouts > don't map 1:1 to either. But if you look at the list of keyboard layouts, > you'll see that 78 layouts out of 83 (checked on Fedora 9) are named after > a country. I don't see how it would be inappropriate to match those up with > a flag. If that's inappropriate, then the name needs fixing too! Unless there is a plan to complete the flags/icons for 83-78=5 layouts, it does not look consistent, does it? > But then > it's kinda hard to find a proper name and especially a proper 2-letter code > to show in the switcher (so I don't see how 2-letter codes are any better > than flags). (How do you fit "Germany and Austria" into 2 letters? "da" > won't cut it, that's already Denmark. Even 3 letters are insufficient for > some layouts used in multiple countries. And you can't fit more into a > systray icon.) The remaining 5 layouts (Arabic, Braille, Esperanto, Latin > America and Maori) are shown without a country flag, using just a 3-letter > abbreviation (Maori could probably use a New Zealand flag, but it currently > doesn't). I don't see how that interface is inappropriate. Technically, up to 6 alphabets can be actually squeeze in the systray icon. I already explained in my previous posts. See icon for SCIM of concrete example. > As for the multi-language countries which have been cited, both Switzerland > and India have A SINGLE keyboard layout in that list (which is generated > from xkb data)! I think there are some Dvorak keyboards in China and India, but Dvorak is not listed in either of them. > Switzerland has variants for German and French (not sure > which one the Italian speakers use) which you select AFTER you selected the > main layout in the list (and the dialog allows you to pick 2 variants and > to rename them, so if you want to switch between Swiss German and Swiss > French layouts, you can make them show up as de and fr or something of your > choice in the switcher). India has a default + 15 variants (and there too > you can pick multiple ones and rename them). So if you think selecting > layouts per country and considering the language variants variants of the > same layout is broken, complain to the xkb folks, not to KDE! It might be too late for xkb, but KDE/GNOME key layout selector on the other hand, can provide alternative UI to achieve the same effect. It is good that KDE can customize the layout label.However as a input method developer, I am more willing to see the key layouts which are categorized by ... layout themselves. Such as QWERTY-- Default +-ja_JP +-ko_KR, +-de_CH +-fr_CH +-it_CH +-en_UK +... DVORAK-- QWERTZ-- +-de_CH +-de...@sundeadkey +-de...@nosundeadkey +-de...@mac +-fr_CH +-it_CH +... AZERTY--fr_FR +-fr_BE The benefits of this category systems are: 1. Input method developers only need to deal with the keys that matter (i.e. 0-9 and a-z) instead of go through the whole country list. 2. End users need fewer scroll for the first level category. 3. Reduce the redundancy: Many countries use essentially the standard QWERTY layout, no need to show all of them. 4. Flags can be assigned to the second level, either from the listing locale string or the regional setting. So Aussies, Kiwi, Singaporean can use their own flags (instead of American flags), everybody is happy. :-) -- Ding-Yi Chen Software Engineer Internationalization Group Red Hat, Inc. Looking to carve out IT costs? www.apac.redhat.com/promo/carveoutcosts/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
