#1140 F20 Self Contained Changes - week 2013-07-10 - 2013-07-17
Closed None Opened 10 years ago by jreznik.

Self Contained Changes for 2013-07-24 meeting.

The ntpdate Change should be part Self Contained changes block but mitr requested more details
* Remove deprecated calls of using ntpdate in favor of ntpd - http://fedoraproject.org//wiki/Changes/ntpdate discussed on https://lists.fedoraproject.org/pipermail/devel/2013-July/185805.html


To perhaps speed up the meeting:

Replying to [ticket:1140 jreznik]:

I'd like us to reiterate something along the F19 decision:

Feature is accepted under the condition that the conflicts must be worked out. openoffice and libreoffice packagers get to work them out. There is no fesco mandate that libreoffice must change to accomodate openoffice at this time. alternatives is not the way to resolve the conflicts but environment-modules may be looked at as a similar means to achieve that.
though not necessarily micromanaging the technology that prescriptively.

The ntpdate Change should be part Self Contained changes block but mitr requested more details
* Remove deprecated calls of using ntpdate in favor of ntpd - http://fedoraproject.org//wiki/Changes/ntpdate discussed on https://lists.fedoraproject.org/pipermail/devel/2013-July/185805.html
Yes, it's not really clear to me that there is a shared understanding on what is being proposed (or maybe even what the current situation is).

Gnome, Ruby on Rails, and Sugar are all platforms. Should those be system-wide changes because of that? (Gnome has in the past required updated libraries that cause changes to other desktops; the ruby on rails thread notes that there are programs in Fedora that use it.)

In terms of approving them, I think I'd still approve them all; just a question of whether they belong in the other category for additional information.

Replying to [comment:2 toshio]:

Gnome, Ruby on Rails, and Sugar are all platforms. Should those be system-wide changes because of that? (Gnome has in the past required updated libraries that cause changes to other desktops; the ruby on rails thread notes that there are programs in Fedora that use it.)

In terms of approving them, I think I'd still approve them all; just a question of whether they belong in the other category for additional information.

Well, then the question is the same for already approved KDE... What we wanted to achieve was - to get the overhead from FESCo to groups working on the change - as a coordinated effort within SIGs. If Sugar does not need any changes in different parts of system - it should be covered by Sugar guys. GNOME is bit more on the edge - if change in underlying technology is needed (new new udisks) - then it's definitely system wide. If it's limited update, then self contained just done by the team. It's hard to tell - there's the Other developers item in Scope section and it's all about trust if the information provided is correct. And for that, we have announcements so anybody can raise objections.

Okay... then from the available information, I would say that Ruby on Rails should be a system wide change but GNOME and Sugar are self-contained this release cycle. Do I need to say this on the mailing list or is here sufficient?

Apache Openoffice -- after concerns raised on ml, I am on the fence about this being a system-wide change. It seems like it should be mostly self-contained but it does have an area that needs coordination with one of our large, important, defaults. It does not appear from the information given to us that that coordination and communication has been initiated. (In terms of the feature being finished, it also needs to get rid of some bundled libraries or go through FPC for an exception.... there's no review bug for the package for me to examine that yet.)

AGREED: ntpdate submittor has to rework the proposal and resubmit to list with describing new scope and changes (+6,-0)

ACTION: jreznik will contact ntpdate owner

AGREED: apache openoffice approved as is, but with mitr's addendum (+7,-0)

mattdm wants this to be perfectly clear: FESCo does not grant automatic exceptions to our processes on any basis.

ACTION: mitr will ask for actions related to thinp on fedora-devel

AGREED: accept LVM thinp as a features and treat usability issues as bugs to be worked out, change documentation from N/A to 'please document in install guide' and speak to maintainers of tools like coreutils (+9,-0)

https://lists.fedoraproject.org/pipermail/devel/2013-July/186016.html <nod>

AGREED: Rails feature will be changed to system wide. It will be needed cooperation at least with OpenShift (+9,-0)

ACTION: jreznik Rails must be changed to system wide
https://wiki.gnome.org/Terminal/FAQ

AGREED: GNOME 3.10 feature is approved as it is proposed (+6,-0)

AGREED: following features are approved: Vagrant, GNOME 3.10, DNSSec for FreeIPA, snapshot/rollback, transitive trusts, Enlightenment, X12go, sugar, sssd smart card, acpica, devassistant GUI, RBAC with libvirt, CIFS plugin, FreeIPA OTP, Ryu, plasma-nm (+9,-0)

No answer from ntpdate Change owner so far to the FESCo request.

Rails Change has been updated to System Wide category, cooperation with OpenShift stated in Dependencies section. I'm going to create ticket after a few days on the list.

  • AGREED: drop the ntpdate Change from Fedora 20 due to maintainer
    unresponsiveness (+8, 0, -0) (sgallagher, 17:52:28)

Reopening for the OS Installer Support for LVM Thin Provisioning Change as Fedora QA would like to propose to Anaconda team and/or FESCo that Anaconda and F20 marketing be modified to put LVM thinp in 'feature preview mode': the installer should hide it or warn that it is unsupported, and marketing materials should either leave it out or list it as a preview due to many issues found during F20 validation.

Replying to [comment:9 jreznik]:

Reopening for the OS Installer Support for LVM Thin Provisioning Change as Fedora QA would like to propose to Anaconda team and/or FESCo that Anaconda and F20 marketing be modified to put LVM thinp in 'feature preview mode'

"Fedora QA would like to propose" - has this been discussed with the feature owner? Does FESCo need to start that discussion, or will Fedora QA take care of this?

Replying to [comment:10 mitr]:

"Fedora QA would like to propose" - has this been discussed with the feature owner? Does FESCo need to start that discussion, or will Fedora QA take care of this?

One thing is - in Fedora, we have never used anything like technology preview/feature preview mode and it's unsure how we should treat it. Especially in the installer, where such functionality is release blocking if it matches release criteria. On the other hand, for a new technology test coverage is desired but without the reason to block release. The similar situation but more difficult was raised for brtfs support.

Anaconda developers were contacted regarding what should be supported - one possibility is to hide some functionality behind boot parameter. But discussion is still ongoing and we would like to see some guidance from FESCo, especially for tech preview question.

  • AGREED: leave the decision of whether to hide or fix thinp to anaconda. We're also okay with QA's interpretation of the criteria which may lead to release slippage if some thinp bugs are considered blockers (+7, 0 -0) (sgallagh, 18:52:07)

Login to comment on this ticket.

Metadata