On Fri, May 25, 2018 at 3:23 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Fri, 2018-05-25 at 20:31 +0000, Alexander Bokovoy wrote:
Jonathan,
your point 3 is not going to work. As I outlined in that email, so many component literally broke FreeIPA in Fedora 28 development timeline, that keeping Fedora 27's 4.6.x series was not possible.
I'm sorry for not putting out the message to more generic lists. I assumed wrongly that people interested in FreeIPA deployments would be on freeipa-users@ mailing list already.
I spent last four months trying to communicate the dire state FreeIPA will be in the Fedora 28 release to Fedora people. I failed, perhaps my style of "everything is on fire" was less than convincing.
To be totally honest, I did not get this message either, Alex - my understanding was that once we finally got all the intended packages landing and the automated tests worked, you actually thought FreeIPA was in acceptable shape fore real use. If it was known that it was not, we absolutely ought to have communicated this *far* more widely than on a niche mailing list: FreeIPA is supposed to be a key feature of Fedora Server which is itself a key edition of Fedora. This should have been up-front in the release notes and the release announcement, or frankly, should've caused us to rethink the release plans.
Obviously there was some sort of significant communication fail if enough people missed the message that this got totally whiffed on, so we should absolutely figure out what we can do better there.
Perhaps this also suggests our existing release criteria and test cases for FreeIPA are insufficient: if it can pass our existing tests and thus appear to meet our existing criteria, yet be in your judgment "not ready for production", that seems fundamentally wrong. How do you we think we could address that? Can you give some kind of summary of the issues here, which we can use to think about how to extend the test cases and criteria?
For now I'd highly recommend we do our best to cut any losses here, but perhaps we should ask Matt to figure out the best way to do that? CCing Matt, in case he hasn't seen this - Matt, see Jonathan Dieter's initial post on server@ for context. Thanks!
Spitball flinger here...
What's the easiest way to quickly (today or tomorrow) prevent dnf system-upgrade from working for Fedora 26/27 -> 28? i.e. to just gracefully fail? Is there a way to insert some bogus dependency so that the upgrade fails, that could then be manually added to --exclude= if the user wants to proceed with the upgrade knowing the consequences to FreeIPA (or they don't use FreeIPA)?
I'm just wondering what the least bad option is here. And it sounds like a bunch of user@ messages that dnf system-upgrade isn't working for server is bad, but less bad than blowing up people's FreeIPA setups. But I'm not sure.