Re: Read this if your package includes a status notifier / system tray icon

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dan Williams wrote:
> "obvious to everyone" - assuming that everyone understands something the
> same way is about the worst way to write a specification.  You need to
> explicitly state what that understanding is, otherwise it's not a
> specification, it's a vague idea and everyone will have a different
> understanding of that idea.  And a different, potentially incompatible
> implementation of.

I'm sure the Plasma and Unity developers behind the spec would have accepted 
(and in fact would still accept!) clarifications added by those who think 
the spec is too vague as is. If it's obvious to them, why should they be the 
ones to spend the time to write more details?

Try understanding what the authors probably meant (putting yourselves in 
their position), then writing it up, and sending the patch to the spec for 
review to them.

Since one principle of the spec is to not set rendering details in stone 
forever (which is very reasonable), that kind of clarifications should be 
presented like, e.g., the suggested glyph shapes in the Unicode standard, 
which are not normative. If they are written like that, I don't think the 
spec authors will have any reason to reject them.

> So just because something is in use, but hasn't been standardized or
> been through any kind of standardization discussion, it should
> automatically be adopted as-is?  I think not...

For a specification already in wide use (it had already been used by Plasma 
for years and Unity for months when the changes were requested), you have to 
weigh any proposed changes against the impact on the existing 
implementations. Nitpicks on method names that are not user-visible are NOT 
productive change requests. Changing those names breaks all the existing 
implementations and does not bring the end user anything. It's as if you 
proposed to fix the "Referer" typo in the HTTP standard, it is just not 
practical.

        Kevin Kofler

-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux