Re: [gentoo-dev] Re: Changing order of default virtual/udev provider

2016-02-13 Thread Joshua Kinard
On 02/10/2016 20:15, Ian Stakenvicius wrote: > On 10/02/16 12:09 PM, Brian Dolbec wrote: >> On Wed, 10 Feb 2016 10:26:12 -0600 William Hubbs >> wrote: > > Often the decision to procrastinate is a decision that is rewarded. That should be considered carefully. >>> >>> + 1. >>> >>> I

Re: [gentoo-dev] Uncoordinated changes

2016-02-13 Thread Raymond Jennings
Speaking of which is there a bug filed for that? On Sat, Feb 13, 2016 at 5:16 PM, Rich Freeman wrote: > On Sat, Feb 13, 2016 at 7:58 PM, Raymond Jennings > wrote: > > So what do you guys think of leaving behind empty stubs for compatibility > > and then simply filing a tracking bug blocked by a

Re: [gentoo-dev] Uncoordinated changes

2016-02-13 Thread Rich Freeman
On Sat, Feb 13, 2016 at 7:58 PM, Raymond Jennings wrote: > So what do you guys think of leaving behind empty stubs for compatibility > and then simply filing a tracking bug blocked by any packages that removing > herds broke? It isn't entirely clear that anything is actually broken at the moment,

Re: [gentoo-dev] Uncoordinated changes

2016-02-13 Thread Raymond Jennings
So what do you guys think of leaving behind empty stubs for compatibility and then simply filing a tracking bug blocked by any packages that removing herds broke? On Sat, Feb 13, 2016 at 2:44 PM, Rich Freeman wrote: > On Sat, Feb 13, 2016 at 4:47 PM, Raymond Jennings > wrote: > > The guys makin

[gentoo-dev] Planet Gentoo / Gentoo Blogs - Announce

2016-02-13 Thread Yury German
== Announcement Gentoo Blogs: == We have upgraded the WordPress install, the themes and the plugins for the blogs.gentoo.org. There are a few announcements as some things have changed with the latest version: 1. "Twenty Fifteen" Theme. "Twenty Fifteen" was the theme for the previous version of w

Re: [gentoo-dev] Uncoordinated changes

2016-02-13 Thread Rich Freeman
On Sat, Feb 13, 2016 at 4:47 PM, Raymond Jennings wrote: > The guys making the API change bear the burden of fixing anything it breaks, > however, if something gets officially deprecated, don't go out of your way > to support continued use. We tend to do this already for things like PMS, which is

Re: [gentoo-dev] Uncoordinated changes

2016-02-13 Thread Raymond Jennings
My two cents: Do it like in linux kernel. The guys making the API change bear the burden of fixing anything it breaks, however, if something gets officially deprecated, don't go out of your way to support continued use. I for one would consider "ok, this method is not working, deprecate it so tha