Bug 1537253

On 2018-Feb-20, we have reached the Fedora 28 Change Checkpoint: Completion deadline (testable).

At this point, all accepted changes should be substantially complete, and testable. Additionally, if a change is to be enabled by default, it must be enabled at Change Completion deadline as well.

Change tracking bug should be set to the MODIFIED state to indicate it achieved completeness.

Incomplete and non testable Changes will be reported to FESCo for 2018-Feb-23 meeting.

This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle.
Changing version to '28'.

On 2018-Mar-08 we reached the "Change Checkpoint: 100% Code Complete Deadline" milestone for Fedora 28 release. At this point all the Changes not at least in "ON_QA" state should be brought to FESCo for review. Please update the state of this bug to "ON_QA" if it is already 100% completed. Please let me know in case you have any trouble with the implementation and the Change needs any help or review.

Thanks, Jan

Stephen, can you please provide a status update?

Proposed as a Blocker for 28-final by Fedora user jwboyer using the blocker tracking app because:

 Modularity is one of the key features of the Fedora release.  While it is an add-on functionality, it is the representation of the Fedora Council Modularity Objective and thus is likely important enough to hold the release for.

List of criteria proposed in FESCo meeting:

sgallagh> 1) `dnf module list` must display all of the modules and streams from 
          the stable module repository
sgallagh> 2) `dnf module enable name:stream` must enable the module stream such 
          that `dnf install <pkgname>` after that is chosen by the solver
sgallagh> 3) `dnf module install <foo>` must honor specified distribution 
          defaults
sgallagh> 4) it must be possible to build modules with MBS that can be 
          passed to Bodhi and consumed by DNF
sgallagh> 5) Module updates submitted to bodhi must appear in testing 
          and stable repos as appropriate
bowlofeggs> 6) dnf update should use said updates from 5)

7) at least one module is available to ship so we have something to test with (we already have it, but just to formalize it)

As FESCo decided this was a blocker, it is one, per the 'automatic blockers' policy:

* Bugs designated as blockers by FESCo (see Fedora_28_Beta_Release_Criteria#FESCo_blocker_bugs)

https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process#Automatic_blockers

Does FESCo consider Modularity to be blocking the *Beta*, and if so, what are the requirements for that?

(In reply to Adam Williamson from comment #9)
> Does FESCo consider Modularity to be blocking the *Beta*, and if so, what
> are the requirements for that?

The seven points identified above are Beta blocking. We haven't yet determined if there will be additional Final requirements (we discussed requirements around a particular set of blocking modules but came to no conclusion yet).

OK, I was fooled by the bug being proposed as a Final blocker. Moving to Beta.

FESCo log link, for the record: https://meetbot.fedoraproject.org/teams/fesco/fesco.2018-03-16-15.01.log.html

(In reply to Zbigniew Jędrzejewski-Szmek from comment #6)
> List of criteria proposed in FESCo meeting:
> 
> sgallagh> 1) `dnf module list` must display all of the modules and streams
> from 
>           the stable module repository
> sgallagh> 2) `dnf module enable name:stream` must enable the module stream
> such 
>           that `dnf install <pkgname>` after that is chosen by the solver
> sgallagh> 3) `dnf module install <foo>` must honor specified distribution 
>           defaults
> sgallagh> 4) it must be possible to build modules with MBS that can be 
>           passed to Bodhi and consumed by DNF
> sgallagh> 5) Module updates submitted to bodhi must appear in testing 
>           and stable repos as appropriate
> bowlofeggs> 6) dnf update should use said updates from 5)

I would suggest `dnf copr` plugin is used for this.

Install the latest snapshot (remembered repo state) of a COPR repo:

`dnf copr install redara/gluster-collectd`

Install a particular copr snapshot:

`dnf copr install redara/gluster-collectd:1`

Upgrade to the latest snapshot:

`dnf copr upgrade redara/gluster-collectd`

Install unsnapshotted version:

`dnf copr install redara/gluster-collectd:head`

Remove all packages from a particular copr:

`dnf copr remove redara/gluster-collectd`

There might be also default namespace setting like e.g. default_namespace="@fedora" in config file so that you will be able to do only:

`dnf copr install lamp:head`

@fedora copr can contain content exclusively from Fedora DistGit so that it can be automatically more trusted.

There is some work to be done on COPR side but it should be very straightforward.

It would be nice to be able to take a particular copr snapshot and put it in Bodhi as an update but I don't know Bodhi that well and cannot really do much about this here.

It should still be possible to install snapshots that didn't pass as an Bodhi update but a warning will be displayed (which a user can disable in copr config file).

Whether the content is verified or not will be stored directly in repodata.

This way we can distinguish verified from non-verified COPR content.

I am not sure what problem you're trying to solve here, but this is not the right venue for it. This bug simply tracks the current state of the Add-On Modularity Change Proposal.

If you have suggestions on how to change or improve Modularity in Fedora, a message on the devel.org mailing list would probably be a better way to go about it.

So we need to verify the items from comments 6 and 7. We should probably, for the long term, turn them into release criteria, test cases and automated tests, but for now, we need to sign off on them specifically for F28 Beta.

Sumantro, can you take the task of verifying that the things listed in comments 6 and 7 work for Beta-1.1? Thanks.

Geoff, you could also work on this.

I will verify this right away and update the bug

Verified: 
1) working (minor bug w/ no sudo/root, reported[1]) 
2) working
3) working, however there are no defaults (is that a bug?)
4) n/a
5) n/a
6) working including switching streams nodejs:6->9->8
7) n/a 

all tests performed on a fresh install (not per step) of 
https://kojipkgs.fedoraproject.org/compose/28/Fedora-28-20180326.0/compose/Server/x86_64/iso/Fedora-Server-netinst-x86_64-28_Beta-1.1.iso in kvm

[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1561182

Checked as per comment 15:

1) working - sudo/root bug seems fixed
2) working
3) working
4) n/a
5) n/a
6) working - tested switching streams, works
7) n/a

Verified:

1. working with a bug [1] 
2. working 
3. working
4. n/a
5. n/a
6. working 
7. n/a

[1]https://bugzilla.redhat.com/show_bug.cgi?id=1561303

ested on Raspberry Pi 3 (AArch64) Server Beta 1.1 image

1) Working
2) Working
3) Working
4) N/A
5) N/A
6) Testing with Django, hit this bug - https://bugzilla.redhat.com/show_bug.cgi?id=1561209
7) N/A

(In reply to Stephen Gallagher from comment #13)
> I am not sure what problem you're trying to solve here, but this is not the
> right venue for it. This bug simply tracks the current state of the Add-On
> Modularity Change Proposal.
> 
> If you have suggestions on how to change or improve Modularity in Fedora, a
> message on the devel.org mailing list would probably be
> a better way to go about it.

Yes, you are right. Sorry for interrupting here.

Discussed at 2018-03-29 go/no-go meeting, acting as a blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-meeting/2018-03-29/f28-beta-go-no-go-meeting.2018-03-29-16.04.html . We affirmed that the requirements stated in comment #6 seem to be fully met for the Beta, per current testing, thus this bug is no longer blocking the Beta release. I'm kicking it up to proposed Final blocker so we can decide how to define / check requirements for the Final release.

Can FESCo please advise us of any additional requirements for Final? Thanks!

Discussed during the 2018-04-02 blocker review meeting: [1]

The decision to classify this bug as an AcceptedBlocker was made as FESCo had decided that this was worthy of a blocker, and we back their decision. We will use this bug to check that the criteria that the FESCo team decides on for F28 Final are met.

[1] https://meetbot.fedoraproject.org/fedora-blocker-review/2018-04-02/f28-blocker-review.2018-04-02-16.00.txt

I've tested all of the criteria above on RC 1.1 and it's working as expected. Marking VERIFIED.

Seconds with sgallagh, tested and everything works as expected with 1.1

sgallagh> With both me and sumantro reporting it as passing the criteria, I'd say this is CLOSED CURRENTRELEASE