----- Original Message -----
From: "Nick Coghlan" <ncoghlan(a)redhat.com>
To: "beaker-devel" <beaker-devel(a)lists.fedorahosted.org>
Sent: Monday, August 26, 2013 11:56:50 AM
Subject: [Beaker-devel] More conservative removal of implicit job sharing
I've been pondering the removal of the old implicit job sharing model
from Beaker 0.15, and I'm concerned that it may break existing
installations in a way that won't be uncovered until a site upgrades to
0.15 and their users complain about not being able to update jobs any
more. At the moment, the only way for installation admins to cope with
such complaints is to roll back to 0.14 (a non-trivial exercise).
That's not quite right. The users can create the correct job permission models.
That will fix the issue, and they will have to do that eventually anyway.
Since we don't track job activity the way we do system activity
(as
described in bug 995012), installation admins also can't easily check if
their users are relying on the feature before they do the upgrade.
Accordingly, I think a slight reworking of our approach to this
deprecation may be in order:
- in 0.15, implicit job sharing remains enabled by default, but can be
switched off through a config option
- in the subsequent release, it is off by default, but the config option
can still be used to turn it back on
- only in the release after *that* (and assuming we don't have users
complaining about the "off by default" release) do we remove the feature
entirely
This change is now covered in
https://bugzilla.redhat.com/show_bug.cgi?id=1000861, and I'd like to
make that a blocker for 0.15.
I'd also like to make this our general policy for any future backwards
incompatible changes without a simple workaround:
- release N adds a config option to turn off the deprecated feature
- release N+1 changes the config option to being off by default
- release N+2 (at the earliest) actually removes the feature
Yes, it's more work for us, but I really want new Beaker releases to be
something that users look forward to, rather than something they fear as
"What did they break this time?" :)
Have we actually had feedback that expresses an inability to cope with changes that
we make within the space of a single release (or any other time frame for that matter)?
If we're expecting people to not be able to actually change their
scripts/behaviour/settings
etc within the space of one release, then it makes perfect sense to me to keep the
deprecated code around longer.
I fear it is still going to be "What did they break this time?", it's just
that
it will be said at N+2 release, rather than N+1, and all this babying inattentive/busy
users
will end up with the same result except more work for the developers, and confusion for
users as
deprecated code is enabled/disabled halfway through a release.
Cheers,
Nick.
--
Nick Coghlan
Red Hat Infrastructure Engineering & Development, Brisbane
Testing Solutions Team Lead
Beaker Development Lead (
http://beaker-project.org/)
_______________________________________________
Beaker-devel mailing list
Beaker-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/beaker-devel