#1688 Incomplete (non testable) Changes of F26
Closed: Fixed 5 years ago Opened 5 years ago by jkurik.

On Tuesday, February 28th, 2017 we have reached the Change Checkpoint: Completion deadline (testable). At this milestone all the F26 Changes should be in "Testable" state, which is indicated by "MODIFIED" status of a tracking bug. The following link points to Bugzilla to show all the tracking bugs which are not in "MODIFIED" state and are not considered as "Testable". On Friday, March 3rd, 2017, before the planned FESCo meeting, I am going to provide FESCo with an explicit list of Changes which will not be considered as testable to discuss and decide on follow-ups.


Metadata Update from @jkurik:
- Issue tagged with: meeting

5 years ago

Here is the static list of non testable F26 Changes (updated on 2017-Mar-10). I would like to ask FESCo to review these and decide what to do with these Changes:

From today's FESCo meeting, the following changes are deferred to F27:

The rest of the changes will be revisited next week.

"Enable systemd-coredump by default" is now complete and doesn't need to be deferred. I'll leave a comment in the bug.

All the deferred Changes are now removed from the F26 scope. The only exception is the Enable systemd-coredump by default Change due to the comment from @catanzaro above. I would like to ask FESCo to review the Enable systemd-coredump by default Change once more.

I had a discussion with developers from the Modularity team about the two Modularity Changes ( Modular Compose, Modular Server Preview ), and here is my conclusion:

  • Modular Compose needs modification of Pungi (the compose tool). As we are currently in Alpha Freeze the build infrastructure should not be modified, if not really necessary. As such, I propose to defer this Change to F27

  • Modular Server Preview encompasses all the Modularity Changes for F26 and it has Modular Compose as a pre-requisite. Thus this Change should be deferred to F27 as well.

We discussed this today in the modularity WG meeting. In short, we don't think we'll need to defer to F27, but we need to follow up with releng to sort out which parts can be available when. I'll report back here when I have more.

Understand that there are two milestones for us with respect to the compose.

  • Doing a single-module compose, with no included metadata. This can be done with no pungi modifications today. It isn't in place, because it requires content from the base-runtime team that is still being built.
  • Doing a multi-module compose, with included metadata. This requires our pungi change, which is still under review by the pungi maintainers. They tell us it is looking good.

I just met with @ausil to try and understand releng's perspective on this:

  • We don't have any chance of hitting either of those milestones for the Alpha composes. That ship has sailed.
  • There's still plenty of time before the Beta freeze to merge both our simple cronjob change and the more complicated pungi change. @ausil says this is okay to do from a releng point of view. It is up to FESCo whether or not to allow a post-Alpha change like this for the Beta release.

Of the two milestones I mentioned at the top, the first can be merged without risking any impact on the main release. It's just another cronjob that can be easily turned off if it misbehaves (or not).

The second involves changes to code paths in pungi and so at least in theory represents a risk to the main release. Let's try and evaluate how much risk there is. To do this, we need to first understand that pungi internally links together about 15 different phases to produce the compose. Our change touches 3 of those.

  • The createrepo phase is trivially modified with a new condition "if this is a modular compose, include the modulemd file in the repo". Low/no risk.
  • The gather phase has "source" plugins, which tell pungi where to gather content from. We simply add a new source to this phase and do not modify any of the existing sources. Low/no risk.
  • However, the pkgset phase receives a large modification to the populate_global_pkgset function. In the event that this code is somehow buggy or impacts our ability to produce the compose for the main release, note that the changes are largely contained within one file. Backing that out in a controlled way is possible (more possible than, say, some patch peppered across every file in the project). Detecting that something has gone wrong should be straightforward. We can compare the package list from the previous compose with the next one and see if the content is majorly out of alignment.

With FESCo's permission, we would like to pursue getting both changes in before the Beta freeze starting on May 9th.

Beside of the two Modularity Changes above, there is one more Change for FESCo to review:

Given @ausil's okay from a rel-eng point of view, and Ralph's thorough risk assessment, and the strategic importance of this project (it's currently our only Council-level Objective), I strongly support a process exception allowing this change to land post-Alpha.

Beside of the two Modularity Changes above, there is one more Change for FESCo to review:

Fedora 26 C/C++ Compilation Flags Updates
Tracking Bug: #1397147
Status: The first part (about -matom) has been implemented. The second and third part has not. Substantial work is required before the compiler defaults can be changed that way.
Owner: @fweimer

it looks like Florian reduced the scope of the Change itself to just focus on dropping the -matom tuning. If so, I believe that's actually done and testable so we should be OK here.

Given @ausil's okay from a rel-eng point of view, and Ralph's thorough risk assessment, and the strategic importance of this project (it's currently our only Council-level Objective), I strongly support a process exception allowing this change to land post-Alpha.

I agree. From a practical point of view, it seems like it would be unnecessarily cruel to cut off work here just as it is starting to produce real results and show promise. I also support this going in post-Alpha.

  • AGREED: the modular delieverables are okay for Beta delivery (+:8
    0:0 -:0) (dgilmore, 16:17:20)
  • we did not vote on the cflag change but it has been completed in a
    reduced change set and was in place for mass rebuild (dgilmore,
    16:18:08)
  • FESCo needs to ensure the change reflects reality (dgilmore,
    16:18:35)

Metadata Update from @ausil:
- Issue untagged with: meeting
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

5 years ago

Login to comment on this ticket.

Metadata