= phenomenon = While discussing some of the deliverables of the releng FAD that is coming up, it became clear to me that we have not really ever addressed the issue of update deliverables. I laid out some of my thoughts https://lists.fedoraproject.org/pipermail/rel-eng/2015-May/020200.html but Fedora as a whole really needs to look at what we make as updates, in addition to release deliverables. I think short term we setup a fortnightly or weekly process to make some additional things. but longer term we need to revamp things entirely. the cloud WG wants updated cloud images. and we have made some for f21 but they have never been pushed out due to a lack of QA sign off from the WG.
= background analysis = Fedora releases are not just the static things they once were, we need to be more dynamic in how we deliver and update pieces of the release.
= implementation recommendation = I would like FESCo to lay out what things should be considered part of the updates pushes and the frequency that we push them out. I think in addition to the list of release deliverables we at the least need to list if they are to be updated as a release goes on.
off the top of my head we should frequently update the atomic installer, Docker base image, cloud images, and maybe the livecds. Idealy I think we would make an update for an item when something inside of it changes, so a bash or python update we would rebuild everything, while a update for docker would be just the atomic images. that does require us having toolinga nd apis to know what is inside each of the deliverables.
I agree this is something we should look into. I would caution against tying it directly to existing deliverables though. Today we have atomic, docker, and the editions. Who knows what we'll ship in 2 years.
It might be better to classify things at a bit broader generalization instead. Packages get updates at an individual level. Containers (e.g. atmoic/docker) and virtual machine images (e.g. pre-installed Workstation live images) get an update of their contents based on some set of criteria. Install deliverables aren't updated (e.g. no DVD or live ISO respins), though that is mostly because we can't scale to do release-level testing continuously.
The tooling to know the contents is indeed important, and is probably the first thing that needs to be done before we can really discuss frequency or criteria for updating. Without it, we're either stuck with "update at a fixed interval" or "update manually case-by-base", neither of which are great policies.
Adding meeting keyword.
Not much discussion in response to dgilmore's mailing list post. We decided to wait for dgilmore to return from the rel-eng FAD.
Looking at this from a high level QA perspective [0] I had a couple thoughts:
Replying to [comment:1 jwboyer]:
Something like a "product update" for each of the products could work. Keeping in line with the scopes jwboyer laid out, it would become more manageable. For instance, if Cloud wanted an updated image or Workstation wanted a Live respun, they'd go through a process like this: Once they have a build of a image they want to release, the WG runs through the testing, submit results to the QA team who can then sign off on the image. The onus for testing updated products should be on the WG to get done (as QA will be busy testing the next release).
I think this should be able to scale out to Live images as well for Workstation. Aside from tooling, we'll need to define a clear process and ensure we get the word out (marketing, docs) about how this "product update" process works. Once all that's ironed out, then websites can make the changes they need in order to make things clear on the getfedora site.
Today we have atomic, docker, and the editions. Who knows what we'll ship in 2 years.
I think this "product update" should be easy enough to scale as the project grows and evolves. Having WGs doing the work they're currently doing and being the driving force behind building the updates and testing them makes it a lot more feasible.
Overall, it puts more strain on the WGs to test their products - but I think it's a decent compromise between what QA needs to sign off on and the WGs want to get pushed out.
--
[0] This is all meant to be very handwavey, high level stuff. I'm ignoring any technical debt or additional pressure this might put on infra and releng (as I'm not familiar enough to really speak to either).
Dennis want to see reply from adamw on this ticket.
I am not picking this for Today's FESCo meeting but anyone want to discuss about this, we can discuss in Open Floor topic.
I like Josh's take here - I'd be with him against respinning lives officially at least at first. Perhaps we need a functional definition of the deliverables that need respinning as 'those that are expected to be deployed to production without an immediate subsequent package-based update', or something along those lines?
It strikes me that we may want to walk before we can run and, for a first cut, just try and do a few ad hoc or calendar-based respins of the deliverables that most clearly need it - Atomic etc - and just see how that process works out and what bear traps we trigger before we start getting too ambitious in terms of tying rebuilds to deliverable contents and so forth? Maybe just say 'for F22 or F23 we will provide Atomic respins every two weeks / every month' or similar?
As a Glorious Future Vision I like the idea of an automatic respin tied to changes in the deliverable's contents, but as well as actually determining what's in the deliverable that would need to be tied to some form of QA to be practical, whether that's a pure automated CI-type system or simply some kind of mechanism requiring manual test and signoff before the respun images are actually shipped.
We agreed to defer and revisit it next week. Keeping the meeting keyword.
We deferred again. We likely will until people start commenting here.
We should really work on some proposal here... not adding meeting keyword, just noting people might look at this and propose something.
I'm not adding this ticket to tomorrow's agenda, since it seems that nothing happened.
However I think we could put together at least some proposal based on the comments from Josh and Adam.
I'm going to put this on the agenda for this week mostly to discuss in the context of https://fedoraproject.org/wiki/Changes/Pungi_Refactor
Do anyone knows if this ticket is related to https://pdc.fedoraproject.org/product app? I mean does above agreed information be available in this pdc webapp? When should this ticket be closed?
Replying to [comment:14 pnemade]:
it is not related to PDC at all. It is still valid and needs answering.
I should say we have not fully answered what is going to delivered as updated artifacts.
Replying to [comment:16 ausil]:
Well, https://fedorahosted.org/fesco/ticket/1444?replyto=16#comment:13 had a pretty specific list:
"updated RPM repos, atomic repos, atomic installer, cloud base image, cloud base vagrant image, cloud atomic image, cloud atomic vagrant image, docker base image."
We do still need to pick a date to set the list immutable though?
One of the outcomes from [https://meetbot.fedoraproject.org/teams/fesco/fesco.2016-04-15-17.00.log.html FESCo meeting on 2016-04-15] was to add a new milestone to the schedule requesting review of Updates Deliverables for the currently active release. This milestone is scheduled to the same date as "Beta Freeze" (which is today for Fedora 24).
I can request the review in a separate ticket, however, as this is the first time FESCo will be doing this review, we can IMO use this ticket to go through initial steps, to have all in one place.
So, please consider this comment just as a reminder the "Updates Deliverables review for Fedora 24" is already needed.
I created: https://fedoraproject.org/wiki/Fedora_Program_Management/Updating_deliverables/Fedora24
and maxamillion was going to talk to various groups and gather information from them on what deliverables would need updating after release and with what frequency.
maxamillion: Any status here?
will check back on this next week to gather info about last deliverable
I think its better we remove "meeting" keyword from this ticket and wait for final update on wiki page created by nirik.
We have discussed on this "Updates Deliverables review for Fedora 24" ticket and can be closed. Soon jkurik need to report a similar ticket for Fedora 25.
Can we close this or we still need some discussion here? Also reading back comment:19 here, should we actually add new key milestone "Review Updates Deliverables" with "Beta Freeze" in F25 release schedule? I can't find somewhere written that at the every Fedora Beta Freeze, FESCo need to review updates deliverables.
Name of the task is ''"Open ticket to FESCo requesting review of deliverables"'' and you can find it on the [https://fedorapeople.org/groups/schedule/f-25/f-25-pm-tasks.html detailed PM schedule]. This task is currently scheduled on 2016-09-27 for F25.
jkurik, Thanks, I forgot to check detailed PM schedule and was just thinking to have that task/milestone be added on [https://fedoraproject.org/wiki/Releases/25/Schedule main schedule] page.
I do not think we will ever get this answered properlly and given the direction we are taking its likely not relevant any longer
@ausil changed the status to Closed
Closed
Login to comment on this ticket.