On 2013-02-12 6:30 PM, (Nuno Silva) <<nunojsi...@ist.utl.pt (Nuno
Silva)> wrote:
I have no doubts that devs have lots of work to do, but it's a rather
serious situation if the difference between unstable and stable land is
*not* used as an advantage when it comes to deal with situations like
this and udev's kernel requirements and network rules.
I guess a good rule of thumb would be: if a stabilization/profile change
or introduced error message will require users to change their settings
by hand, change their kernel config to match new requirements in order
to have an usable system or to treat some packages/flags in a different
way, this should not go forward until a news item has been prepared to
notify users about it.
Add "with an appropriate bake-in time *after* the news item is released
to provide time for stable users to digest and understand the
implications, and for unstable users to thrash out any issues before
pushing it s-to stable." before the period at the end of that last
sentence and I agree wholeheartedly.
Question:
Is there a well defined 'bake-in' time for things like this?
If not, there should be.
