4:34 p.m.
On Fri, May 25, 2018 at 3:23 PM, Adam Williamson
<adamwill(a)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.
--
Chris Murphy