On Tue, 11 Aug 2009 17:14:45 +0200
Till Maas <opensource(a)till.name> wrote:
On Wed, Aug 05, 2009 at 12:41:30PM -0600, Kevin Fenzi wrote:
> Dealing with incompatible upgrades. (any new ideas or suggestions?)
> (smooge-21:01:29) Wiki pages cleanup. (smooge-21:14:01)
There is some information missing about how it will be dealt with
incompatible upgrades. Afaics they should be avoided, but if they
can't, they should be announced, pushed to testing, announced again
and then pushed to stable. I am not sure, whether there are any
recommendations, about which pain is acceptable until an incompatible
Yeah, sadly, I was busy during this meeting so didn't get to provide
much input. ;)
If however we want to allow incompatible upgrades like that in some
cases we should establish a procedure to doing so. (with a wiki page
explaining each step in detail). Perhaps something like:
- Announce to epel-announce the reason for the upgrade, what the impact
is and when the update will go to testing.
- Wait for feedback. Perhaps each upgrade like this should require a
bug to be filed to collect feedback and bugs/issues that can be
worked around with the update.
- Build incompatible version and push to testing.
- Perhaps wait longer than normal in testing for feedback.
- Announce again to epel-announce that the incompatible upgrade is
coming, urge people to test with the version in testing.
- Push to stable.
I think it's important to try and notify users, but also important to
get feedback from other developers who might see whats to mitigate the
issues with the upgrade.