[Beaker-devel] More conservative removal of implicit job sharing

Raymond Mancy rmancy at redhat.com
Mon Aug 26 04:41:05 UTC 2013



----- Original Message -----
> From: "Nick Coghlan" <ncoghlan at redhat.com>
> To: "beaker-devel" <beaker-devel at 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 at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/beaker-devel
> 


More information about the Beaker-devel mailing list