Re: Summary/Minutes from today's FESCo Meeting (2012-07-23)
Adam Williamson wrote: I'm not sure it makes sense to worry about which approach is best for the really commonly used core fonts in deciding, because whichever approach we take, clearly we'll wind up taking care to make sure those fonts look good. Of course – for somebody's idea of good. As we found out in another branch of this thread, people can disagree on which rendering method makes a font look good. Björn Persson -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2012-07-23)
- 元のメッセージ - | Our default font set for most languages, DejaVu, ships carefully | designed | hinting bytecode written specifically for FreeType's bytecode | interpreter, | and its designers explicitly ask for it to be used rather than the | autohinter. (Some people dislike the font's look with the hinting, | but it is | how the designers intended it to look.) Sure. I'm not saying that there are no well-hinted fonts in free fonts. I'd respect their efforts. Anyway, as I planned to prepare some references for comparison, I've done and put them at http://tagoh.fedorapeople.org/tmp/hints/. all.tar.xz may helps to see all smoothly on your machine. I used pango-view this time to avoid the out of alignment on taking a screenshot as far as possible for easy comparison and to reduce the workload. also disabled most fontconfig rules at /etc/fonts/conf.d to avoid the side-effects of them on this testing because the user fonts.conf can't override it if it's changed after 50-user.conf. and only picked up the fonts packages installed by default. My feeling on this testing is fifty-fifty to determine which should be better for default. there are some fonts that hinting is totally broken, and partly broken that depends on the pixel size. of course well-hinted fonts and no changes because of maybe no hinting or using ttfautohint perhaps. Having said, from any possibilities that there may be the case other fonts can't get a win to be default because of its quality (of course it may be not necessarily the case), I'm still thinking that enabling autohinting by default may helps a lot. FWIW I'm about to add a feature of hinting related things in fonts-tweak-tool so even if something goes wrong for self-installed fonts by users say, they can change it easily as needed. -- Akira TAGOH -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2012-07-23)
Akira TAGOH wrote: Well, that's true for proprietary fonts, but not necessarily true for free fonts. Our default font set for most languages, DejaVu, ships carefully designed hinting bytecode written specifically for FreeType's bytecode interpreter, and its designers explicitly ask for it to be used rather than the autohinter. (Some people dislike the font's look with the hinting, but it is how the designers intended it to look.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2012-07-23)
Matthew Garrett wrote: If it's clear to FESCo that the feature is going to have a significant impact on packages outside of those directly affected by the change then FESCo should take that into account when approving the feature. However, if a feature is well-confined to the packages under the maintainer's responsibility then second-guessing the maintainer's judgement is dangerous. Any negative fallout should be dealt with by the maintainer, and unless that fails I don't see any reason for FESCo to be involved. The feature definitely has a significant impact on freetype. And freetype- freeworld (which I own in RPM Fusion), though that's not in Fedora for obvious reasons. At the very least, you need to talk to Marek Kasik, the Fedora maintainer of freetype. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2012-07-23)
Paul Wouters wrote: Every single Fedora upgrade in the last few years (with perhaps F17 the exception) surprised me with superior fonts over the previous release. We might not have conveyed that, but I've been pretty happy with what people have done with fonts so far. I did not look at the latest feature proposal or there impact The latest feature proposal is to basically revert to how things had been up to Fedora 14, unless a font manually opts in to having the hinting information it carries actually used (through a fontconfig configuration file). :-( Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2012-07-23)
Benny Amorsen wrote: As far as I can tell subpixel rendering is disabled in these examples. You need freetype-freeworld for that. It's still patented. :-( Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2012-07-23)
On Tue, 2012-07-31 at 22:58 +0200, Kevin Kofler wrote: Akira TAGOH wrote: Well, that's true for proprietary fonts, but not necessarily true for free fonts. Our default font set for most languages, DejaVu, ships carefully designed hinting bytecode written specifically for FreeType's bytecode interpreter, and its designers explicitly ask for it to be used rather than the autohinter. (Some people dislike the font's look with the hinting, but it is how the designers intended it to look.) It seems like we're really just debating between: * Default to autohinting and tweak specific fonts to use BCI * Default to BCI and tweak specific fonts to use autohinting I'm not sure it makes sense to worry about which approach is best for the _really commonly used core fonts_ in deciding, because whichever approach we take, clearly we'll wind up taking care to make sure those fonts look good. I think the appropriate criterion to use for the decision is which approach tends to work out best for J. Random Font - the large body of less-used fonts both within the distro and outside it. These are the fonts that are _not_ going to get special treatment and will most likely wind up using the default rendering path, so we should pick the default rendering path to work best for _those_ fonts, not for the 'showcase' fonts which we take special care of. -- 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
Re: Summary/Minutes from today's FESCo Meeting (2012-07-23)
- 元のメッセージ - | Akira TAGOH wrote: | I admit simply enabling force-auto-hinting isn't enough. we | definitely | need to optimize a lot to make it more better. | | The FreeType autohinter has been developed for years, leading to what | we | have now. It is totally unreasonable to expect to be able to | optimize it | in the time frame of a single release. | | It should also be quite expected that using the hinting information | provided | by the fonts will necessarily lead to better hinting than not using | it. Well, that's true for proprietary fonts, but not necessarily true for free fonts. I see FreeType upstream is working on ttfautohint, that may implies that there are the case autohinting is better than hinting in the font as it tries to remove the existing hinting data if any. | Those are broken fonts (they probably ship hinting information only | for | selected glyphs and leave the others entirely unhinted), and we | should force | autohinting manually for those fonts. Yes, I noted that in the contingency plan. it should be a trade-off. if we have a lot of _broken_ fonts, then it would be better doing it in fontconfig and stop using autohinting in the sane fonts then. -- Akira TAGOH -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2012-07-23)
Tomasz Torcz to...@pipebreaker.pl writes: Which is which? There are some example here: http://tagoh.fedorapeople.org/tmp/hints/ *-autohint variants are clearly blurred, while -*hintfull are eligible. As far as I can tell subpixel rendering is disabled in these examples. Is that relevant today, when almost all displays are LCD? /Benny -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2012-07-23)
- Original Message - - 元のメッセージ - | Akira TAGOH wrote: | I admit simply enabling force-auto-hinting isn't enough. we | definitely | need to optimize a lot to make it more better. | | The FreeType autohinter has been developed for years, leading to | what | we | have now. It is totally unreasonable to expect to be able to | optimize it | in the time frame of a single release. | | It should also be quite expected that using the hinting information | provided | by the fonts will necessarily lead to better hinting than not using | it. Well, that's true for proprietary fonts, but not necessarily true for free fonts. I see FreeType upstream is working on ttfautohint, that may implies that there are the case autohinting is better than hinting in the font as it tries to remove the existing hinting data if any. | Those are broken fonts (they probably ship hinting information only | for | selected glyphs and leave the others entirely unhinted), and we | should force | autohinting manually for those fonts. Yes, I noted that in the contingency plan. it should be a trade-off. if we have a lot of _broken_ fonts, then it would be better doing it in fontconfig and stop using autohinting in the sane fonts then. Yep, that's the reason why I ask you to provide the metrics to have an overview of the change (how good/bad it is) and the deadline. No it's more the question how to implement it, to collect the feedback from people etc. R. -- Akira TAGOH -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2012-07-23)
- 元のメッセージ - | On 07/24/2012 11:35 AM, Kevin Kofler wrote: | I don't understand this feature at all! Freetype already uses | auto-hinting | for fonts which do not provide hinting data, in fact that was one | of the | prerequisites for enabling the bytecode interpreter in Fedora, and | I cherry- | picked the relevant change from the huge Infinality patchset and | got it | upstreamed. Forcing auto-hinting for all fonts effectively means | disabling | the bytecode interpreter by default, which is surely not a good | idea. | | It also turns every font into a blurry mess. This is not a subjective | opinion. Run the listed command on the Feature Page for DejaVu and | Liberation fonts (two of the biggest free fonts). With the current | free-type environment you have crisp, clean fonts. Enable | auto-hinting | and every character becomes blurred including a simple exclamation | mark | that is a single line of pixels. I admit simply enabling force-auto-hinting isn't enough. we definitely need to optimize a lot to make it more better. in fact there are the case auto-hinting gives much better than BCI-hinting. that may implies there may be more cases to be improved. as you guys are looking at your monitor daily-basis, if something goes wrong, it's easy to realize what's improved and what's worse. isn't this feature a good idea to get such feedback? If there are any commonly applicable rules, it should be done in the system wide way, I mean in fontconfig. otherwise need to do it in the specific way, in the fonts packages. | | It is unfortunate FESCo members blindly +1'd this feature without a | bit | of evidence or thought. Yes, I read the meeting log. It took just | three | minutes to pass. | | Do I need to file a ticket to get this feature revoked? | -- | devel mailing list | devel@lists.fedoraproject.org | https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2012-07-23)
Akira TAGOH wrote: I admit simply enabling force-auto-hinting isn't enough. we definitely need to optimize a lot to make it more better. The FreeType autohinter has been developed for years, leading to what we have now. It is totally unreasonable to expect to be able to optimize it in the time frame of a single release. It should also be quite expected that using the hinting information provided by the fonts will necessarily lead to better hinting than not using it. in fact there are the case auto-hinting gives much better than BCI-hinting. Those are broken fonts (they probably ship hinting information only for selected glyphs and leave the others entirely unhinted), and we should force autohinting manually for those fonts. that may implies there may be more cases to be improved. as you guys are looking at your monitor daily-basis, if something goes wrong, it's easy to realize what's improved and what's worse. isn't this feature a good idea to get such feedback? NO! We have had autohinting by default for years, back when the BCI was patented. It has NOT lead to the kind of improvements you seem to be expecting, and in fact it was common practice to rebuild FreeType with the BCI enabled (or use the freetype-freeworld package which did that; these days, the only remaining difference between freetype and freetype-freeworld is subpixel rendering). Why should it work any better now? The BCI patent has finally expired, we have finally been able to enable the BCI in Fedora, and now you propose to move back. This is not a constructive proposal. If there are any commonly applicable rules, it should be done in the system wide way, I mean in fontconfig. otherwise need to do it in the specific way, in the fonts packages. Doing it per font is the right solution if individual fonts don't work properly with the BCI. Normally, fonts which provide hinting bytecode expect it to be used! (And for those which don't provide any hinting bytecode, FreeType already automatically falls back to autohinting. I personally ensured this.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2012-07-23)
Matthew Garrett wrote: The feature was +1ed on the assumption that the feature owner, as a maintainer of relevant code, The maintainer of the relevant code (FreeType) is Marek Kasik, has he been consulted? (Those fontconfig files to be changed are just settings, the actual code is all in FreeType.) And the patch which makes FreeType fall back to autohinting for unhinted fonts (which was what allowed the BCI to be enabled in Fedora after the patent had expired) has been upstreamed by me (it originally came from Infinality), yet I definitely haven't been talked to. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2012-07-23)
Le Mar 24 juillet 2012 23:17, Michael Cronenworth a écrit : It also turns every font into a blurry mess. This is not a subjective opinion. Run the listed command on the Feature Page for DejaVu and Liberation fonts (two of the biggest free fonts). With the current free-type environment you have crisp, clean fonts. Enable auto-hinting and every character becomes blurred including a simple exclamation mark that is a single line of pixels. What you call crisp other call distorted windows-like rendering (even Apple does not do it that way, their rendering is closer to freetype autohinting) The change that disabled autohinting for any font with hinting traces was done without even checking our fonts worked well with it (most fonts have some hint traces because most font authors have experimented with them or copied a few glyphs from hinted fonts. That does not mean the hints are complete or usable for the font as a whole) Current in-the-wild font hints are bad enough Werner Lemberg could raise funds to write a windows-oriented executable that does nothing but embed freetype autohinter results in font files (so windows users get the benefit of freetype autohinting) http://www.freetype.org/ttfautohint/ If you look at the Google font directory logs Google is using this tool to add hints to its own files. Using font file hints should definitely be an opt-in (enable in the fontconfig snippet associated with a particular font family, after checking the hints are actually better than autohinting) not an opt-out. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2012-07-23)
On Wed, Jul 25, 2012 at 04:13:54PM +0200, Nicolas Mailhot wrote: Le Mar 24 juillet 2012 23:17, Michael Cronenworth a écrit : It also turns every font into a blurry mess. This is not a subjective opinion. Run the listed command on the Feature Page for DejaVu and Liberation fonts (two of the biggest free fonts). With the current free-type environment you have crisp, clean fonts. Enable auto-hinting and every character becomes blurred including a simple exclamation mark that is a single line of pixels. What you call crisp other call distorted windows-like rendering (even Apple does not do it that way, their rendering is closer to freetype autohinting) Which is which? There are some example here: http://tagoh.fedorapeople.org/tmp/hints/ *-autohint variants are clearly blurred, while -*hintfull are eligible. -- Tomasz Torcz ,,If you try to upissue this patchset I shall be seeking xmpp: zdzich...@chrome.pl an IP-routable hand grenade.'' -- Andrew Morton (LKML) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2012-07-23)
Le Mer 25 juillet 2012 15:34, Kevin Kofler a écrit : It should also be quite expected that using the hinting information provided by the fonts will necessarily lead to better hinting than not using it. Unfortunately, not. This is the classical it's expensive and therefore must be good logic mistake. BCI is not necessarily good because it was patented. BCI is better than no hinting at all, but that does not say much. Most of the fonts we use were developed with windows as a target (OSX tends to attract closed paid-for fonts only) and windows does not do autohinting. So the hints present in most fonts are here to improve the rendering when compared to no hinting at all. That in no way means they improve the rendering when compared to a mature and well-optimised autohinter such as the one used by freetype. In fact ttfautohint development was funded in part by the Google Web Font project, that works on the same set of FLOSS fonts as us, to provide freetype autohinter-like results to windows users. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2012-07-23)
On 07/25/2012 10:21 AM, Tomasz Torcz wrote: On Wed, Jul 25, 2012 at 04:13:54PM +0200, Nicolas Mailhot wrote: Le Mar 24 juillet 2012 23:17, Michael Cronenworth a écrit : It also turns every font into a blurry mess. This is not a subjective opinion. Run the listed command on the Feature Page for DejaVu and Liberation fonts (two of the biggest free fonts). With the current free-type environment you have crisp, clean fonts. Enable auto-hinting and every character becomes blurred including a simple exclamation mark that is a single line of pixels. What you call crisp other call distorted windows-like rendering (even Apple does not do it that way, their rendering is closer to freetype autohinting) Which is which? There are some example here: http://tagoh.fedorapeople.org/tmp/hints/ *-autohint variants are clearly blurred, while -*hintfull are eligible. The eligible bits are the windows-like rendering AIUI. Nicolas's point is that evaluating these results, despite Michael's statement to the contrary, is highly subjective. To me your results look like this: DejaVuSans: 10 pts - pretty much both terrible, but for completely opposite reasons! 11-16 pts - bizarrely thin lines on the -hintful ones, basically okay on -autohint. All readable, but some are just ugly. 17 pts - strange and uncomfortable variances in line thickness on -hintful but basically okay on -autohint 18-25 pts - still some thickness issues but mostly okay on -hintful, but better on -autohint, 26 pts - weirdly bold on -hintful, normal looking on -autohint The liberation screenshots follow much the same way, except the 17 pts one is lumped in with 11-16. But obviously some people have different opinions, and seem to prefer the blockiness of -hintful to the blur of -autohint. -- Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2012-07-23)
Le Mer 25 juillet 2012 16:21, Tomasz Torcz a écrit : Which is which? There are some example here: http://tagoh.fedorapeople.org/tmp/hints/ *-autohint variants are clearly blurred, while -*hintfull are eligible. And -*hintfull variants clearly show massive distortion and sudden thickness jumps when moving from one size to another. So they are not well hinted either. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2012-07-23)
On Tue, Jul 24, 2012 at 11:38:00PM +0100, Matthew Garrett wrote: On Tue, Jul 24, 2012 at 04:17:46PM -0500, Michael Cronenworth wrote: It is unfortunate FESCo members blindly +1'd this feature without a bit of evidence or thought. Yes, I read the meeting log. It took just three minutes to pass. The feature was +1ed on the assumption that the feature owner, as a maintainer of relevant code, is in a better position to judge the impact on the packages they're working on than people who don't have that level of expertise in the area in question. If the change turns out to have a negative effect on the distribution as a whole then that's something that should be discussed. If there's no more reasonable solution then it should be reverted. But at present procedure is working pretty much exactly as expected. While I think that there might be some hyperbole in reaction to this Feature approval, this view of the Feature Approval Process is certainly not how I envisioned it when we initially implemented the Approval Process. FESCo reviews the Features in order to understand and point out how the changes will impact the distribution as a whole. Maintainers *are* better at understanding how their changes affect the code they work on but they aren't always better at seeing how their changes impact other people and the code that they maintain. (Note that if FESCo would rather not be doing that, it probably should be something that gets added to the Fixing Features page so it's an anti-goal of a any new features policy http://fedoraproject.org/wiki/Fixing_features ). -Toshio pgp3gdo5GTZ7q.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2012-07-23)
On Wed, Jul 25, 2012 at 08:34:04AM -0700, Toshio Kuratomi wrote: On Tue, Jul 24, 2012 at 11:38:00PM +0100, Matthew Garrett wrote: The feature was +1ed on the assumption that the feature owner, as a maintainer of relevant code, is in a better position to judge the impact on the packages they're working on than people who don't have that level of expertise in the area in question. If the change turns out to have a negative effect on the distribution as a whole then that's something that should be discussed. If there's no more reasonable solution then it should be reverted. But at present procedure is working pretty much exactly as expected. While I think that there might be some hyperbole in reaction to this Feature approval, this view of the Feature Approval Process is certainly not how I envisioned it when we initially implemented the Approval Process. FESCo reviews the Features in order to understand and point out how the changes will impact the distribution as a whole. Maintainers *are* better at understanding how their changes affect the code they work on but they aren't always better at seeing how their changes impact other people and the code that they maintain. If it's clear to FESCo that the feature is going to have a significant impact on packages outside of those directly affected by the change then FESCo should take that into account when approving the feature. However, if a feature is well-confined to the packages under the maintainer's responsibility then second-guessing the maintainer's judgement is dangerous. Any negative fallout should be dealt with by the maintainer, and unless that fails I don't see any reason for FESCo to be involved. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2012-07-23)
On Wed, Jul 25, 2012 at 05:36:41PM +0100, Matthew Garrett wrote: On Wed, Jul 25, 2012 at 08:34:04AM -0700, Toshio Kuratomi wrote: On Tue, Jul 24, 2012 at 11:38:00PM +0100, Matthew Garrett wrote: The feature was +1ed on the assumption that the feature owner, as a maintainer of relevant code, is in a better position to judge the impact on the packages they're working on than people who don't have that level of expertise in the area in question. If the change turns out to have a negative effect on the distribution as a whole then that's something that should be discussed. If there's no more reasonable solution then it should be reverted. But at present procedure is working pretty much exactly as expected. While I think that there might be some hyperbole in reaction to this Feature approval, this view of the Feature Approval Process is certainly not how I envisioned it when we initially implemented the Approval Process. FESCo reviews the Features in order to understand and point out how the changes will impact the distribution as a whole. Maintainers *are* better at understanding how their changes affect the code they work on but they aren't always better at seeing how their changes impact other people and the code that they maintain. If it's clear to FESCo that the feature is going to have a significant impact on packages outside of those directly affected by the change then FESCo should take that into account when approving the feature. However, if a feature is well-confined to the packages under the maintainer's responsibility then second-guessing the maintainer's judgement is dangerous. Any negative fallout should be dealt with by the maintainer, and unless that fails I don't see any reason for FESCo to be involved. Absolutely. But it is FESCo's responsibility to determine how well confined a feature is. So rather than phrasing this as FESCo should stay out of it unless it's clear that the feature is going to have a significant impact on packages outside of those directly affected by the change I would emphasize that FESCo is supposed to play an active role in discovering and evaluating what hte impact of a feature will be. This is because, as I stated, the feature owners are better are understanding how their changes affect what they are working on. But they aren't always better at seeing the big picture. And if you disagree with that, then I will reiterate that we should add that to the Fixing Features page a an anti-goal for an updated Feature Policy. If it is an anti-goal, it would allow for options where FESCo is not involved in the Feature Process for many features. If FESCo isn't a player in fact finding about how big the impact of a feature is, Features can be processed for whether they should be documentation-only features vs ones that require either approval on whether this is a direction the distro should take and needs coordination among maintainers before they reach FESCo. FESCo would only step in on documentation-only features if someone complains that the feature is more than a documentation-only change. -Toshio pgpBuqqQyafVv.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2012-07-23)
On Wed, Jul 25, 2012 at 7:46 PM, Toshio Kuratomi a.bad...@gmail.com wrote: And if you disagree with that, then I will reiterate that we should add that to the Fixing Features page a an anti-goal for an updated Feature Policy. If it is an anti-goal, it would allow for options where FESCo is not involved in the Feature Process for many features. If FESCo isn't a player in fact finding about how big the impact of a feature is, Features can be processed for whether they should be documentation-only features vs ones that require either approval on whether this is a direction the distro should take and needs coordination among maintainers before they reach FESCo. FESCo would only step in on documentation-only features if someone complains that the feature is more than a documentation-only change. A few of us have discussed some changes that should address the major problems with the features, and would have definitely improved the handling of this feature. Expect a written proposal soonish. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2012-07-23)
onsdagen den 25 juli 2012 16:38:33 skrev Nicolas Mailhot: Le Mer 25 juillet 2012 16:21, Tomasz Torcz a écrit : Which is which? There are some example here: http://tagoh.fedorapeople.org/tmp/hints/ *-autohint variants are clearly blurred, while -*hintfull are eligible. And -*hintfull variants clearly show massive distortion and sudden thickness jumps when moving from one size to another. So they are not well hinted either. Perhaps I can provide some input here? Personally I don't see anything I would call massive distortion in any of those samples. It could be because I'm not all that interested in fonts. I'm used to seeing many different glyph variants and I don't care a lot about the finer details as long as it's clear which letter is which. I think many users are probably like me in that regard. Users don't want to think about the font when they are reading a text; they want to think about the information contained in the text. The font should convey the information without drawing attention to itself. I hope font designers don't take this to mean that their work is unimportant. That's not what I'm saying. Good fonts are very important, but most of the time a good font is one that the users don't notice. Many years ago it would often happen that the line thickness varied so much between individual letters that some of the letters looked like they were bold. That was quite annoying, but I don't see that in these samples. Maybe the w could have been a little thinner in LiberationSans-hintfull.png, sizes 15 to 17, but that's a minor issue compared to how it was back then. I strongly dislike the blurry letters in the autohint samples. I lived with such blurry letters for some time, and I remember how they affected me. They annoyed me and drew my attention away from my reading. I think vertical and horizontal lines should always be a whole number of pixels wide. The thickness jumps between sizes are unfortunate, but they are an inevitable effect of limited screen resolution. I'll choose the thickness jumps over the blurry letters without hesitation. Should we hold a vote to determine how the majority of users like their fonts? Björn Persson -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2012-07-23)
On Wed, 25 Jul 2012, Björn Persson wrote: I'm used to seeing many different glyph variants and I don't care a lot about the finer details as long as it's clear which letter is which. I think many users are probably like me in that regard. Users don't want to think about the font when they are reading a text; they want to think about the information contained in the text. Every single Fedora upgrade in the last few years (with perhaps F17 the exception) surprised me with superior fonts over the previous release. We might not have conveyed that, but I've been pretty happy with what people have done with fonts so far. I did not look at the latest feature proposal or there impact, but I did nwat to say that there are a lot of users out there who care and notice fonts beyond which letter is which. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2012-07-23)
Jóhann B. Guðmundsson (johan...@gmail.com) said: Standardization on the changes so it can be documented in the guidlines so people know what to do in their unit file. (such as around Documentation=, what fields are no longer necessary, etc.) That's just laughable since afaik systemd would be the only program that is forced to go through these change and get the approvals from FPC while others simply get away with mentioning changes in upstream documentation. I don't see this sort of bias that you're implying here. Init script packaging changes went through FPC. Desktop file packaging goes through FPC. Ruby gems packaging changes go through FPC. Why wouldn't something like systemd services that also affects a few hundred packages? Yes, systemd does have a bit higher bar on things than, say, alienblaster, but that's because it's much more important to the overall system. I thought you guys meant the removal of the environment files that resides in /etc/sysconfig/ directory and that was why the feature was being rejected and mentioning that upstream needed some kind of upstream patching was just utter and total bullshit since putting environment files in /etc/sysconfig/$file is Fedora/RHEL specific and is the reason why upstream has been rejected our units when they have been submitted upstream... This was also a concern of FESCo, yes - having a clear migration path for users and administrators, rather than dropping them all and picking up the pieces. Additionally, there was a minor concern about if there are going to be more cleanups that pop up each release, as some of the cleanups (documentation is the obvious one) didn't exist when the units were first written. These sorts of changes are the sort of thing that are great for standardizing in conjunction with FPC guidelines, so others can see how to do it and evangelize the work upstream and possibly even help. Teaching to fish instead of giving fish, more or less. Really, that's all that needs done here - get a standard for what a cleaned up unit should look like, what it should include, etc., and get that through FPC. Essentially, a list of what should be changed in: https://fedoraproject.org/wiki/Packaging:Systemd It's not like the feature was rejected out of hand; it was just redirected. Then you guys started to act like kids in candy store and cherry pick stuff from the feature requests well here's a news flash that wont work with me. When I submit features I will submit them as is, work on them as is and finish them myself as is While I commend your desire on doing the work on features you submit yourself, Fedora *IS* a community project; it's about collaboration, not a collection of individuals all going in different directions. We do have policies and procedures in Fedora for a reason. You may not like them. Heck, I don't like them some of the time either. And some of them can use fixing - we have ongoing work on fixing the feature process as we speak. However, when you say you'll only do the features your way, yourself, and aren't willing to accept alternatives, or work with the community's elected representatives on this (that's how your statements read to me), it seems to the outside world like you don't share the same set of values there. If that's the case, it *is* going to cause repeated friction, and make make it harder for you to effectively and/or happily contribute. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2012-07-23)
On 07/25/2012 09:42 PM, Bill Nottingham wrote: Jóhann B. Guðmundsson (johan...@gmail.com) said: Standardization on the changes so it can be documented in the guidlines so people know what to do in their unit file. (such as around Documentation=, what fields are no longer necessary, etc.) That's just laughable since afaik systemd would be the only program that is forced to go through these change and get the approvals from FPC while others simply get away with mentioning changes in upstream documentation. I don't see this sort of bias that you're implying here. Init script packaging changes went through FPC. Desktop file packaging goes through FPC. Ruby gems packaging changes go through FPC. Why wouldn't something like systemd services that also affects a few hundred packages? Yes, systemd does have a bit higher bar on things than, say, alienblaster, but that's because it's much more important to the overall system. You guys ( FESCO ) seem to have easily dismiss that fact when you accepted the preset feature or when accepting systemd. If you guys FESCO had wanted documentation how to construct units you guys would have asked for one when you guys accepted systemd as the new init system then most certainly this argument would make sense. . If the migration process was not needed to be handled on per initscript bases I would have written one long time ago. I thought you guys meant the removal of the environment files that resides in /etc/sysconfig/ directory and that was why the feature was being rejected and mentioning that upstream needed some kind of upstream patching was just utter and total bullshit since putting environment files in /etc/sysconfig/$file is Fedora/RHEL specific and is the reason why upstream has been rejected our units when they have been submitted upstream... This was also a concern of FESCo, yes - having a clear migration path for users and administrators, rather than dropping them all and picking up the pieces. Again ye had no problem accepting the preset feature Additionally, there was a minor concern about if there are going to be more cleanups that pop up each release, as some of the cleanups (documentation is the obvious one) didn't exist when the units were first written. These sorts of changes are the sort of thing that are great for standardizing in conjunction with FPC guidelines, so others can see how to do it and evangelize the work upstream and possibly even help. Teaching to fish instead of giving fish, more or less. I will be doing the cleanup process one time. After that my systemd involvement will be more or less concluded and I will be returning to QA and continue the work I was doing there and had been doing there for several release cycles before I was asked to handle the migration. Really, that's all that needs done here - get a standard for what a cleaned up unit should look like, what it should include, etc., and get that through FPC. Essentially, a list of what should be changed in: https://fedoraproject.org/wiki/Packaging:Systemd It's not like the feature was rejected out of hand; it was just redirected. ? There is nothing on that page that is mentioned on that page that would get affected by the cleanup process thus nothing is subjected to be changed there. Then you guys started to act like kids in candy store and cherry pick stuff from the feature requests well here's a news flash that wont work with me. When I submit features I will submit them as is, work on them as is and finish them myself as is While I commend your desire on doing the work on features you submit yourself, Fedora *IS* a community project; it's about collaboration, not a collection of individuals all going in different directions. We do have policies and procedures in Fedora for a reason. You may not like them. Heck, I don't like them some of the time either. And some of them can use fixing - we have ongoing work on fixing the feature process as we speak. Yes I saw that effort which still does not seem to make a room for features that span over several release cycles. However, when you say you'll only do the features your way, yourself, and aren't willing to accept alternatives, or work with the community's elected representatives on this (that's how your statements read to me), And my work proves otherwise... it seems to the outside world like you don't share the same set of values there. If that's the case, I personally would choose fewer better maintained components in the distribution then many poorly maintained or not maintained at all and personally I want feature to be actually 100% done instead of just be claimed to be done thus if the outside world wants and accepts half implemented things in the release then sure we do not share the same value. Heck when we in QA miss a serious bug that affects large user base I take that as a personal failure on my behalf as crazy as that is, in the end that's just how I
Re: Summary/Minutes from today's FESCo Meeting (2012-07-23)
Josh Boyer wrote: * #908 F18 Feature: Fontconfig Enable Autohinting - (jwb, 18:03:02) * LINK: https://fedoraproject.org/wiki/Features/FontconfigEnableAutohinting (jwb, 18:03:03) * AGREED: feature Fontconfig Enable Autohinting is approved (+:9, -:0 , 0:0) (jwb, 18:06:07) I don't understand this feature at all! Freetype already uses auto-hinting for fonts which do not provide hinting data, in fact that was one of the prerequisites for enabling the bytecode interpreter in Fedora, and I cherry- picked the relevant change from the huge Infinality patchset and got it upstreamed. Forcing auto-hinting for all fonts effectively means disabling the bytecode interpreter by default, which is surely not a good idea. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2012-07-23)
Jóhann B. Guðmundsson (johan...@gmail.com) said: * #898 F18 Feature: Package Service Presets - (jwb, 17:05:37) * LINK: https://fedoraproject.org/wiki/Features/PackagePresets (jwb, 17:05:37) * AGREED: feature Package Service Presets is approved (+: 5, -: 1 (mitr) 0:0) (jwb, 17:12:59) So you guys actually agreed to this without this A) being implemented for all service related packages within one release cycle B) Done after we have migrated all units thus allowing this to wind up being half implement and at the same time deny me the request of cleaning up existing units in the distribution you guys amaze me some might even come to the conclusion that Red Hat employees get special treatment within FESCO... Both this feature and yours, when first proposed, were suggested that changes go through FPC. For presets, this happened, and it came back to FESCo. For yours, when it was asked, you decided to drop it. I'm sorry that you feel that this is some grand Red Hat conspiracy. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2012-07-23)
On 07/24/2012 11:35 AM, Kevin Kofler wrote: I don't understand this feature at all! Freetype already uses auto-hinting for fonts which do not provide hinting data, in fact that was one of the prerequisites for enabling the bytecode interpreter in Fedora, and I cherry- picked the relevant change from the huge Infinality patchset and got it upstreamed. Forcing auto-hinting for all fonts effectively means disabling the bytecode interpreter by default, which is surely not a good idea. It also turns every font into a blurry mess. This is not a subjective opinion. Run the listed command on the Feature Page for DejaVu and Liberation fonts (two of the biggest free fonts). With the current free-type environment you have crisp, clean fonts. Enable auto-hinting and every character becomes blurred including a simple exclamation mark that is a single line of pixels. It is unfortunate FESCo members blindly +1'd this feature without a bit of evidence or thought. Yes, I read the meeting log. It took just three minutes to pass. Do I need to file a ticket to get this feature revoked? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2012-07-23)
On 07/24/2012 08:49 PM, Bill Nottingham wrote: Both this feature and yours, when first proposed, were suggested that changes go through FPC. What exactly was I supposed to discuss with FPC? JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2012-07-23)
Jóhann B. Guðmundsson (johan...@gmail.com) said: On 07/24/2012 08:49 PM, Bill Nottingham wrote: Both this feature and yours, when first proposed, were suggested that changes go through FPC. What exactly was I supposed to discuss with FPC? Standardization on the changes so it can be documented in the guidlines so people know what to do in their unit file. (such as around Documentation=, what fields are no longer necessary, etc.) Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2012-07-23)
On 07/24/2012 09:29 PM, Bill Nottingham wrote: Jóhann B. Guðmundsson (johan...@gmail.com) said: On 07/24/2012 08:49 PM, Bill Nottingham wrote: Both this feature and yours, when first proposed, were suggested that changes go through FPC. What exactly was I supposed to discuss with FPC? Standardization on the changes so it can be documented in the guidlines so people know what to do in their unit file. (such as around Documentation=, what fields are no longer necessary, etc.) That's just laughable since afaik systemd would be the only program that is forced to go through these change and get the approvals from FPC while others simply get away with mentioning changes in upstream documentation. I thought you guys meant the removal of the environment files that resides in /etc/sysconfig/ directory and that was why the feature was being rejected and mentioning that upstream needed some kind of upstream patching was just utter and total bullshit since putting environment files in /etc/sysconfig/$file is Fedora/RHEL specific and is the reason why upstream has been rejected our units when they have been submitted upstream... Then you guys started to act like kids in candy store and cherry pick stuff from the feature requests well here's a news flash that wont work with me. When I submit features I will submit them as is, work on them as is and finish them myself as is ( although all help is always greatly appreciated and unlike others I give credit where credit is due ) I would be willing to add some other additional work that crosses path with mine to reduce work and speed up implementation of that relevant thing ( like the packaging preset feature does ) . I ain't like so many other feature owners that just tag maintainers components in some bug report expect them do to all the work and then flag the feature 100% done before GA while at best it's half way there leaving someone else in the community to cleanup the remaining mess and us in QA to catch all the fallout from that in the process... With feature process which is as utterly broken like this, when I am forced to resubmit features that span over several release cycle again and again for no other purpose other then to waste people time because our feature process does not expect features to be able to span several release cycle and then you guys wonder why I did not resubmit the feature request lol... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2012-07-23)
On Tue, Jul 24, 2012 at 04:17:46PM -0500, Michael Cronenworth wrote: It is unfortunate FESCo members blindly +1'd this feature without a bit of evidence or thought. Yes, I read the meeting log. It took just three minutes to pass. The feature was +1ed on the assumption that the feature owner, as a maintainer of relevant code, is in a better position to judge the impact on the packages they're working on than people who don't have that level of expertise in the area in question. If the change turns out to have a negative effect on the distribution as a whole then that's something that should be discussed. If there's no more reasonable solution then it should be reverted. But at present procedure is working pretty much exactly as expected. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2012-07-23)
On 07/23/2012 06:56 PM, Josh Boyer wrote: === #fedora-meeting: FESCO (2012-07-23) === Meeting started by jwb at 17:01:18 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2012-07-23/fesco.2012-07-23-17.01.log.html . * #898 F18 Feature: Package Service Presets - (jwb, 17:05:37) * LINK: https://fedoraproject.org/wiki/Features/PackagePresets (jwb, 17:05:37) * AGREED: feature Package Service Presets is approved (+: 5, -: 1 (mitr) 0:0) (jwb, 17:12:59) So you guys actually agreed to this without this A) being implemented for all service related packages within one release cycle B) Done after we have migrated all units thus allowing this to wind up being half implement and at the same time deny me the request of cleaning up existing units in the distribution you guys amaze me some might even come to the conclusion that Red Hat employees get special treatment within FESCO... * #897 https://fedoraproject.org/wiki/Features/AvahiDefaultOnDesktop (jwb, 17:38:20) * AGREED: feature AvahiDefaultOnDesktop is approved (+:7, -:0 , 0:2 (jwb, pjones) ) (jwb, 17:52:17) * FESCo to follow up with twoerner on the opening of the port aspect (jwb, 17:52:36) I assume that this will get tied to the desktop.target only and all avahi aware service ( samba/vsftp/nfs etc ) will be fixed and probably integrated in the process? JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
