-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Up to now, all of our release criteria for FreeIPA have been in terms of fresh installations on a newly-installed system. However, there are numerous individuals out there who are running FreeIPA on Fedora systems and who would suffer greatly if an upgrade from the previous version did not work.
I propose that the following release criterion be added for Fedora 24 and onwards:
Beta Criterion: * For any system with a configured and enabled FreeIPA server (or Domain Controller Role powered by the same), it must be possible to upgrade from Fedora N to Fedora N+1 and have the same set of domain controller services available after upgrade.
As a secondary criterion, I'd also like to recommend that we add:
Final Criterion: * For any system with a configured and enabled FreeIPA server (or Domain Controller Role powered by the same), it must be possible to upgrade from Fedora N to Fedora N+1 and have the same set of domain controller services available after upgrade without manual intervention.
(Note, that secondary criterion is not currently possible; there is a manual upgrade script that must be run post-distro-upgrade). See https://fedorahosted.org/freeipa/ticket/5373 for more details.
On Mon, Nov 02, 2015 at 10:02:32AM -0500, Stephen Gallagher wrote:
I propose that the following release criterion be added for Fedora 24 and onwards:
I'm not opposed to this, but I also don't want to pile up the possibilities of things which grind the release to a halt. It'd be nice if any new criterion also come with some plan to help ensure that the thing is likely to be working long before the release validation, and then the release validation is just that - validation.
On Mon, 2015-11-02 at 10:02 -0500, Stephen Gallagher wrote:
Up to now, all of our release criteria for FreeIPA have been in terms of fresh installations on a newly-installed system. However, there are numerous individuals out there who are running FreeIPA on Fedora systems and who would suffer greatly if an upgrade from the previous version did not work.
I propose that the following release criterion be added for Fedora 24 and onwards:
Beta Criterion:
- For any system with a configured and enabled FreeIPA server (or
Domain Controller Role powered by the same), it must be possible to upgrade from Fedora N to Fedora N+1 and have the same set of domain controller services available after upgrade.
As a secondary criterion, I'd also like to recommend that we add:
Final Criterion:
- For any system with a configured and enabled FreeIPA server (or
Domain Controller Role powered by the same), it must be possible to upgrade from Fedora N to Fedora N+1 and have the same set of domain controller services available after upgrade without manual intervention.
I have three issues with this:
1. The addition of the Final criterion rather explicitly implies that the Beta criterion allows for 'manual intervention', and you can fix just about anything with 'manual intervention' - by that standard the current situation wouldn't fail the test, arguably, as you *can* make FreeIPA work on upgrade, you just have to hand-edit the LDAP server config and run the Tomcat migration script and tweak an SELinux boolean, simples!
I know we fuzz this a bit in other cases, but I'm worried about the implications of making it super explicit like that. I'd rather qualify the level of 'manual intervention' that's acceptable.
2. I'm not sure this approach of specifying individual bits of functionality that must work is gonna scale. It would make more sense to me to require instead that upgrade must work for the 'featured' roles.
3. More fundamentally, I don't think the release criteria is the place to be doing this *at all*. One of the things on my list for post-F23 process tasks is to propose an alternative system for handling stuff we've been treating as 'special blockers' lately, and this kind of upgrade payload stuff is likely to fall into that category. I don't like the 'special blocker' (lack of a) process at all, really, as it has no teeth: we just say 'oh, this must happen' and then assume it magically will. Which is not a great way to go about stuff.
On Mon, Nov 02, 2015 at 08:19:30AM -0800, Adam Williamson wrote:
- More fundamentally, I don't think the release criteria is the place
to be doing this *at all*. One of the things on my list for post-F23 process tasks is to propose an alternative system for handling stuff we've been treating as 'special blockers' lately, and this kind of upgrade payload stuff is likely to fall into that category. I don't like the 'special blocker' (lack of a) process at all, really, as it has no teeth: we just say 'oh, this must happen' and then assume it magically will. Which is not a great way to go about stuff.
Yeah. Leads to overnight/weekend demands for both developers and QA, and ends up with people tired, sad, and angry. This is clearly not the best.
server@lists.fedoraproject.org