On Mon, 2018-01-08 at 09:01 -0500, Matthew Miller wrote: > On Mon, Jan 08, 2018 at 07:04:31AM -0500, Martin Kolman wrote: > > Yep - basically, there will be no "old" and "new, DBUS/modular" > > Anaconda, the plan is to turn the current Anaconda to the new one one > > step at a time. > > > > This should allow us to fix bugs as usual and handle any unforeseen > > modularization issues early on one-by-one as they show up. > > It sounds like there actually isn't a contingency plan as such. Do you > think that this could all be reverted on Final Freeze day if we would > decide it's not working out? If not, let's not call that a contingency. > > I'm not saying we shouldn't do this, but let's be honest with > ourselves. If the contingency plan is "None: we'll have to hold up the > release for fixes if it's not ready", the Change plan should say that. As mentioned by jkonecny, we have updated the change page, including the contingency plan. The idea is that we will kreate a fallback branch just before we enable the first modularization changes and keep the fallback branch functional by backporting critical fixes and blockers. The master branch (and after branching the f28-branch) will host the incremental modularization work and will be used for Rawhide/F28 Anaconda builds. If everything works fine, the fallback branch will not be needed and will be discontinued after F28 GA. If we need to activate the contingency plan, we will switch F28 Anaconda builds to the fallback branch, effectively falling back to the non-modularized code for the F28 timeframe. > > -- > Matthew Miller > <mattdm@xxxxxxxxxxxxxxxxx> > Fedora Project Leader > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx