Re: The future Fedora Copr "rolling" chroot cleanup policy

g_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Adam Samalik --- Principal Software Engineer Red Ha

Re: aarch64 iso images - can we link the Everything installer?

On Tue, 16 Jul 2024 at 17:19, Adam Williamson wrote: > On Tue, 2024-07-16 at 09:28 +0200, Adam Samalik wrote: > > I noticed we're no longer link to aarch64 isos: > > https://fedoraproject.org/spins/kde/download > > Not even for Workstation: https://fedoraprojec

aarch64 iso images - can we link the Everything installer?

r an option. Even though it is and works perfectly fine. The Everything installer, in my opinion, is the superior one anyway because it lists all the options and is smaller. And the installed system is up-to-date right away. But that's a different conversation. :-) -- Adam Samalik --

Re: [ELN] Missing /usr/bin/bzr in ELN (solved, but open questions)

On Thu, 22 Oct 2020 at 01:46, Miro Hrončok wrote: > On 10/21/20 10:10 PM, Neal Gompa wrote: > > On Wed, Oct 21, 2020 at 3:00 PM Miro Hrončok > wrote: > >> 1) Why is breezy not in the ELN compose, but is in the Koji buildroot? > > > > It's defined as a buildroot only package: > > > https://github

Re: [ELN] Opt out python2.7 from ELN

On Sat, 8 Aug 2020 at 01:12, Miro Hrončok wrote: > On 08. 08. 20 1:03, Miro Hrončok wrote: > > On 08. 06. 20 16:49, Miro Hrončok wrote: > >> Hello, > >> > >> as a maintainer of the python2.7 package I was surprised to see it > being built > >> for ELN and I like to start a discussion on whether a

Re: How to invite others to projects on Taiga?

It's a bit clunky, but the following works for me: 1/ Ask them to log in to Taiga first — they need to do that so Taiga creates an account for them internally 2/ Add them by their FAS (Fedora Account System) email — you can use zodbot on irc, asking it "fas THEIR_FAS" or "fasinfo THEIR_FAS" ... t

Re: Alternative buildroot as a development tool

I really like this proposal. I feel like it's something we needed for a long time. More comments inline! On Mon, Jan 13, 2020 at 5:45 PM Aleksandra Fedorova wrote: > Hi, all, > > This topic goes along the lines of Matthew’s Operating System Factory > discussion[1], but with a slightly different

Re: [minimization] Feedback Pipeline feedback wanted

On Fri, Dec 13, 2019 at 8:20 PM Adam Williamson wrote: > On Fri, 2019-12-13 at 09:19 -0800, Kevin Fenzi wrote: > > It would be great if they could include the size +/- of all the images. > > Of course the most important ones would be boot.iso, workstation and > > server, but labs and spins could

[minimization] Feedback Pipeline feedback wanted

The Minimization Objective[1] has been going on for a while. There are two high-level goals: making things smaller, and keeping things smaller. On the keeping smaller side, the team prototyped a service called Feedback Pipeline [2] that monitors use cases for their installation size and dependencie

Re: Minimization Objective report

On Tue, Nov 19, 2019 at 8:22 PM Adam Jackson wrote: > On Fri, 2019-11-15 at 23:38 +0100, Kevin Kofler wrote: > > Adam Samalik wrote: > > > 1/ A history chart for base images [2] is now being generated — > includes > > > data since 25 September. It's a bit rough

Re: Minimization Objective report

On Fri, Nov 15, 2019 at 11:42 PM Kevin Kofler wrote: > Adam Samalik wrote: > > 1/ A history chart for base images [2] is now being generated — includes > > data since 25 September. It's a bit rough initial implementation, but > it's > > there! > > Almost 2

Re: Minimization Objective report

On Fri, Nov 15, 2019 at 7:16 PM Robbie Harwood wrote: > Adam Samalik writes: > > > This is the Minimization Objective [0] update. > > > > Status: Discovery phase > > > > == Next phase approval == > > > > Next phase proposal [1] is being voted on

Minimization Objective report

This is the Minimization Objective [0] update. Status: Discovery phase == Next phase approval == Next phase proposal [1] is being voted on by the Council — only positive votes so far! == Feedback Pipeline == A few new features developed! 1/ A history chart for base images [2] is now being gen

Minimization Objective report

This is the Minimization Objective [0] update. Status: Discovery phase == Next phase approval == Next phase proposal [1] to be voted on by Council, starting tomorrow. Feedback still collected in the PR [2]. == Polkit and Mojzs == Finished investigation and send recommended changes to postgres

Re: Minimization Objective report

On Thu, Oct 17, 2019 at 10:50 AM Miro Hrončok wrote: > On 16. 10. 19 20:14, Adam Samalik wrote:> == PostgreSQL == > > > > Started talking to the maintainers about removing systemd, python2, and > to > > consider skipping weak dependencies in the container use case.

Minimization Objective report

This is the Minimization Objective [0] update. Status: Discovery phase == Next phase proposed == The next phase has been proposed [1] [2] to the Council and feedback is being collected. A formal vote happens in two weeks. == PostgreSQL == Started talking to the maintainers about removing syste

Re: Modularity and the system-upgrade path

I think we've already discussed and documented [1] this — although we haven't discussed module dependencies back then. A) If user selects a default (or doesn't do any selection), default is followed. B) If user selects a specific stream, that stream is followed. So, basically, respecting user cho

Minimization Objective report

This is the Minimization Objective [0] update. Status: Discovery phase == Next phase definition == I'm putting together a proposal for the next phase approval. I've made a Logic Model [1] so far, more is coming soon. See the issue [2] to get more updates and to give feedback which is very welcom

Minimization Objective report

This is the Minimization Objective [0] update. Status: Discovery phase == Regular meeting canceled == We have decided to cancel the regular Minimization Team Meeting [1] as we prefer async discussions on #fedora-devel and de...@lists.fp.o. This makes it more inclusive to people with other commit

The last regular Minimization Team Meeting notes 2019-09-25

Minutes: https://meetbot.fedoraproject.org/fedora-meeting-1/2019-09-25/minimization.2019-09-25-15.00.html Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting-1/2019-09-25/minimization.2019-09-25-15.00.txt Log: https://meetbot.fedoraproject.org/fedora-meeting-1/2019-09-25/minimization.2

Minimization Objective report

This is the Minimization Objective [0] update. Status: Discovery phase == systemd-sysusers == Many packages pull in Systemd because of systemd-sysusers to create new users. This is fine in traditional setups where there already is Systemd, but for containers, that means pulling additional 60MB j

Minimization Team Meeting notes 2019-09-18

Minutes: https://meetbot.fedoraproject.org/fedora-meeting-1/2019-09-18/minimization.2019-09-18-15.01.html Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting-1/2019-09-18/minimization.2019-09-18-15.01.txt Log: https://meetbot.fedoraproject.org/fedora-meeting-1/2019-09-18/minimization.2

Re: [Fedocal] Reminder meeting : Minimization Team Meeting

Agenda item: #13 systemd-sysusers versus containers https://pagure.io/minimization/issue/13 On Tue, Sep 17, 2019 at 5:00 PM wrote: > Dear all, > > You are kindly invited to the meeting: >Minimization Team Meeting on 2019-09-18 from 15:00:00 to 16:00:00 GMT >At fedora-meetin...@irc.freeno

Minimization Objective report

This is the Minimization Objective [0] update. Status: Discovery phase == Use case analysis == Removing Systemd dependency from container use cases: -- nginx -- * Pull request to drop systemd as a runtime requirement [1] -- httpd -- * Pull request to drop systemd as a runtime requirement [2] *

Minimization Team Meeting notes 2019-09-11

Minutes: https://meetbot.fedoraproject.org/fedora-meeting-1/2019-09-11/minimization.2019-09-11-15.00.html Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting-1/2019-09-11/minimization.2019-09-11-15.00.txt Log: https://meetbot.fedoraproject.org/fedora-meeting-1/2019-09-11/minimization.2

Re: What projects can we highlight for Hacktoberfest?

What about the Feedback Pipeline service [1] I'm working on for minimization? The code [2] is on GitHub and I even have a few issues with things to do. [1] https://minimization.github.io/reports/ [2] https://github.com/minimization/feedback-pipeline On Mon, Aug 26, 2019 at 10:47 PM Ben Cotton wr

Minimization Objective report

This is the Minimization Objective [0] update. Status: Discovery phase == Feedback Pipeline == A prototype is live [1]! It shows packages and an overall size of use cases we are focusing on, installed on top of various Fedora bases. In addition to showing the current status, it will be also pu

Minimization Team Meeting notes 2019-09-04

Minutes: https://meetbot.fedoraproject.org/fedora-meeting-1/2019-09-04/minimization.2019-09-04-15.00.html Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting-1/2019-09-04/minimization.2019-09-04-15.00.txt Log: https://meetbot.fedoraproject.org/fedora-meeting-1/2019-09-04/minimization.2

Minimization Team Meeting notes 2019-08-28

Minutes: https://meetbot.fedoraproject.org/fedora-meeting-1/2019-08-28/minimization.2019-08-28-15.00.html Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting-1/2019-08-28/minimization.2019-08-28-15.00.txt Log: https://meetbot.fedoraproject.org/fedora-meeting-1/2019-08-28/minimization.2

Minimization Objective report

This is the Minimization Objective [0] update. Status: Discovery phase == Toolbox == The 'showme' tool got renamed to 'rpm-showme' to make it more discoverable. It has been also moved to a new repository of the same name [1]. New features: * report — generates an html report [2] [3] comparing

Re: 'showme' RPM dependency visualizer (was: Minimization Objective report)

Moved: https://pagure.io/minimization/rpm-showme I'm now updating all the references. On Fri, Aug 23, 2019 at 2:12 PM Adam Samalik wrote: > Yeah, that's a good point. I might rename the repo as well. Thanks for the > suggestion! > > On Fri, Aug 23, 2019 at 1:1

Re: 'showme' RPM dependency visualizer (was: Minimization Objective report)

Yeah, that's a good point. I might rename the repo as well. Thanks for the suggestion! On Fri, Aug 23, 2019 at 1:15 PM Dusty Mabe wrote: > > > On 8/23/19 6:35 AM, Dominik 'Rathann' Mierzejewski wrote: > > Hi, Adam. > > > > On Wednesday, 2

Minimization Team Meeting notes 2019-08-21

Minutes: https://meetbot.fedoraproject.org/fedora-meeting-1/2019-08-21/minimization.2019-08-21-15.00.html Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting-1/2019-08-21/minimization.2019-08-21-15.00.txt Log: https://meetbot.fedoraproject.org/fedora-meeting-1/2019-08-21/minimization.2

Minimization Team Meeting notes 2019-08-14

Minutes: https://meetbot.fedoraproject.org/fedora-meeting-1/2019-08-14/minimization.2019-08-14-15.00.html Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting-1/2019-08-14/minimization.2019-08-14-15.00.txt Log: https://meetbot.fedoraproject.org/fedora-meeting-1/2019-08-14/minimization.2

Minimization Objective report

This is the Minimization Objective [0] update. == Regular meeting == Team meeting every Wednesday 15:00 GMT (find it in the SIGs calendar [1]). == Discoveries == A new discoveries page [2] created that will contain random useful discoveries. It'll get structured as it fills up. Potential areas

Re: Join the new Minimization Team

On Wed, Aug 14, 2019 at 8:49 PM Robbie Harwood wrote: > > Here's the scriptlet: > > > > %triggerun libs -- krb5-libs < 1.15.1-5 > > if ! grep -q 'includedir /etc/krb5.conf.d' /etc/krb5.conf ; then > > sed -i '1i # To opt out of the system crypto-policies > > configuration of krb5, > > remove

Re: [Fedocal] Reminder meeting : Minimization Team Meeting

This will be our very first meeting! I'll prepare some agenda before the meeting, but I mostly expect quick introductions, our long-term goals or things we're interested in, ideas, and ideally a plan for everyone for the upcoming week. See you there! Adam On Tue, Aug 13, 2019 at 5:02 PM wrote:

Re: New graphical dependency visualiser prototype

I've just added support for weak dependencies. On Mon, Aug 5, 2019 at 3:38 PM Adam Samalik wrote: > > > On Sun, Aug 4, 2019 at 8:16 PM Igor Gnatenko < > ignatenkobr...@fedoraproject.org> wrote: > >> How does it deal with rich dependencies? Does it take conflicts

Re: Join the new Minimization Team

oji builds for example, consuming content that's not been released yet (part of CI?), that would give us much more useful data. > > On Wed, Aug 7, 2019, 11:58 Adam Samalik wrote: > >> >> >> On Mon, Aug 5, 2019 at 1:30 PM Zbigniew Jędrzejewski-Szmek < >> zbys

Re: Join the new Minimization Team

On Mon, Aug 5, 2019 at 1:30 PM Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> wrote: > On Sun, Aug 04, 2019 at 05:27:21PM +0200, Christian Glombek wrote: > > Whoop this is great! > > But I wonder why the scratch build sizes have gone up this dramatically > in > > f31? > > Also, there are still s

Re: Join the new Minimization Team

On Tue, Aug 6, 2019 at 1:34 PM Martin Kolman wrote: > On Sun, 2019-08-04 at 16:18 +0100, Peter Robinson wrote: > > > > On Sat, 3 Aug 2019 at 20:34, Zbigniew Jędrzejewski-Szmek > > > > wrote: > > > > > On Thu, Aug 01, 2019 at 10:25:55AM +0200, Adam Sa

Re: New graphical dependency visualiser prototype

conflict nor multiple provides into account. That said, in the future updates, I can see it taking repositories into account and based on that offering alternative options to some packages, even showing the potential impact or even making suggestions. > > On Sun, Aug 4, 2019, 19:41 Adam Sama

New graphical dependency visualiser prototype

I wrote a script to visualise dependencies of RPM installations [1]. It supports file paths and container images as an input. The script generates a graph of packages and their relations including sizes of all individual packages and some basic clustering. Clicking on a package highlights its rela

Re: Join the new Minimization Team

On Sat, Aug 3, 2019 at 11:24 PM Clement Verna wrote: > On Sat, 3 Aug 2019 at 20:34, Zbigniew Jędrzejewski-Szmek > wrote: > > > > On Thu, Aug 01, 2019 at 10:25:55AM +0200, Adam Samalik wrote: > > > I've already done some experiments with that. I used multi-sta

Minimization Objective report

Congratulations! You're reading the very first Minimization Objective [1] update. == New Minimization Team == A new team is being formed, having 9 members already! Read the team page [2] for more information, including how to join. Welcome, everyone! == Communication channels == Following are

Re: Join the new Minimization Team

Geschäftsführer: Charles Cachera, Michael O'Neill, Tom Savage, Eric Shander > > > > On Tue, Jul 30, 2019 at 5:24 PM Neal Gompa wrote: > >> On Tue, Jul 30, 2019 at 10:58 AM Adam Samalik >> wrote: >> > >> > Hi everyone! >> > >> &

Re: Join the new Minimization Team

https://docs.fedoraproject.org/en-US/minimization/team/ On Tue, Jul 30, 2019 at 3:20 PM Adam Samalik wrote: > Hi everyone! > > I'm starting a Minimization Objective [1] focusing on minimising the > installation size of some of the popular apps, runtimes, and other pieces > of so

Join the new Minimization Team

Hi everyone! I'm starting a Minimization Objective [1] focusing on minimising the installation size of some of the popular apps, runtimes, and other pieces of software in Fedora. And there is a new Minimization Team [2] forming. Members of the team will consult and work with Fedora maintainers, d

Re: Modularity vs. libgit

On Fri, Jun 21, 2019 at 5:47 PM Adam Williamson wrote: > On Fri, 2019-06-21 at 13:28 +0200, Adam Samalik wrote: > > To keep the expectations of Fedora's stable ABI within a release, we > can't > > change the default stream of a module mind-release. I know, that'

Re: Modularity vs. libgit

On Fri, Jun 21, 2019 at 1:28 PM Adam Samalik wrote: > > > On Fri, Jun 21, 2019 at 12:08 AM Adam Williamson < > adamw...@fedoraproject.org> wrote: > >> On Thu, 2019-06-20 at 23:48 +0200, Igor Gnatenko wrote: >> > Hello, >> > >> > I just wa

Re: Modularity vs. libgit

On Fri, Jun 21, 2019 at 12:08 AM Adam Williamson wrote: > On Thu, 2019-06-20 at 23:48 +0200, Igor Gnatenko wrote: > > Hello, > > > > I just wanted to give you an update from my last discussions on > > #fedora-modularity and other places. > > > > # Problems definition > > > > * Default modules can

Modularity vs. libgit

So, I'd like to discuss the libgit issue [1] [2] we're experiencing. With a help of a few people, I've put together this post to get us on common ground: https://communityblog.fedoraproject.org/modularity-vs-libgit/ There are few ideas about solving the issue right now. But we might be able to thi

Re: Modularity tooling intro?

The local module builds we have documented at the moment [1] should work if you have an access to the Fedora infrastructure (==internet connection) and your packages are in the Fedora dist-git. I know that Merlin (merlinm) is working on tooling that allow you to do local module builds without rely

Re: Fedora modularity and cyclic dependencies

On Tue, Apr 16, 2019 at 3:14 PM Robert-André Mauchin wrote: > On Tuesday, 16 April 2019 02:46:49 CEST Mat Booth wrote: > > > > Yes, there is a buildopts section in the yaml file where you can specify > > rpm macros. > > > > Here is the documentation: > > > > > https://docs.fedoraproject.org/en-US

Re: Modularity question for packagers about rolling/latest/stable/master streams

On Thu, Apr 4, 2019 at 3:59 PM Matthew Miller wrote: > On Thu, Apr 04, 2019 at 09:24:13AM -0400, Stephen Gallagher wrote: > > > Without naming them, I see two different use cases: > > > 1/ "for end users" — rolling stream meant for end users to consume, > likely used in projects without tradition

Re: Modularity question for packagers about rolling/latest/stable/master streams

On Thu, Apr 4, 2019 at 3:55 PM Matthew Miller wrote: > On Thu, Apr 04, 2019 at 09:25:36AM -0400, Stephen Gallagher wrote: > > > > So the question is, do people agree there are two? Or just one? Or > more? > > > Upstreams aren't consistent. There's a good argument for making our > branches > > > m

Modularity question for packagers about rolling/latest/stable/master streams

Some modules now use "latest", "stable", or "master" as stream names for various different things. It's quite confusing and I want to fix that. Without naming them, I see two different use cases: 1/ "for end users" — rolling stream meant for end users to consume, likely used in projects without t

Re: Modularity UX Questions

On Tue, Apr 2, 2019 at 2:50 PM Stephen Gallagher wrote: > On Tue, Apr 2, 2019 at 3:36 AM Adam Samalik wrote: > > > When a packager doesn't provide the YAML defaults file at all, I'd > assume it could have been unintentional and notified them about that fact. > How

Re: [Fedocal] Reminder meeting : Modularity Team (weekly)

Today we'll discuss: #128 Discussion: naming common streams and profiles [asamalik] https://pagure.io/modularity/issue/128 * Last call to make changes in the proposal before it goes to the docs * Ideas about how to align existing modules — renaming streams and profiles will potentially break thing

Re: Modularity UX Questions

On Mon, Apr 1, 2019 at 6:58 PM Stephen Gallagher wrote: > Last month, we had a Modularity Hackfest in Boston. I wrote up a > hackfest report at the Community Blog[1] back then, which included > several open questions related to how to handle stream and profile > defaults. I'm reprinting them here

Re: [modularity] Bringing order to the confusing module stream and profile names

r 14, 2019 at 4:39 PM Adam Samalik wrote: > > > On Thu, Mar 14, 2019 at 4:35 PM Alexander Bokovoy > wrote: > >> On to, 14 maalis 2019, Stephen Gallagher wrote: >> >On Thu, Mar 14, 2019 at 9:41 AM Alexander Bokovoy >> wrote: >> >> >> >>

Re: [modularity] Bringing order to the confusing module stream and profile names

On Thu, Mar 14, 2019 at 4:35 PM Alexander Bokovoy wrote: > On to, 14 maalis 2019, Stephen Gallagher wrote: > >On Thu, Mar 14, 2019 at 9:41 AM Alexander Bokovoy > wrote: > >> > >> On to, 14 maalis 2019, Stephen Gallagher wrote: > >> >On Thu, Mar 14, 2019 at 1:58 AM Alexander Bokovoy > wrote: > >

[modularity] Bringing order to the confusing module stream and profile names

There are module streams named 'latest', 'stable', or 'master', but it's not quite clear what exactly those mean. Some modules even have the 'master' and the 'latest' streams at the same time which feels quite confusing. In a similar manner, there are various unclear profile names, too. Especially

Re: modular repositories in mock configs: please don't

On Mon, Mar 4, 2019 at 10:26 PM Michael Cronenworth wrote: > On 3/4/19 3:04 AM, Petr Šabata wrote: > > You can view them as virtual repositories with dependencies. I > > think that might be the simplest way to put it. > > > > You can try playing with fedmod to generate your modulemd file or > >

Re: modular repositories in mock configs: please don't

On Mon, Mar 4, 2019 at 11:13 AM Pavel Raiskup wrote: > On Monday, March 4, 2019 10:46:45 AM CET Petr Šabata wrote: > > On Mon, Mar 04, 2019 at 10:22:05AM +0100, Pavel Raiskup wrote: > > > On Monday, March 4, 2019 10:01:14 AM CET Petr Šabata wrote: > > > > Replying in general. > > > > > > > > Whil

Re: modular repositories in mock configs: please don't

I'm glad Modularity is getting popular, however, we should coordinate such big changes so we keep consistency among various build environments. The ability to enable modules in a Koji buildroot is being discussed in a FESCo ticket [1] — although that discussion is a bit longer than initially antic

Re: Proposal: Stewardship Group / SIG for taking care of otherwise "module-only" packages

On Tue, Feb 12, 2019 at 12:15 PM Fabio Valentini wrote: > On Tue, Feb 12, 2019 at 12:09 PM Adam Samalik wrote: > > > > The Modularity Team works on enabling default modules to be present in > the traditional buildroot. The work is tracked here: > https://tree.taiga.io/proje

Re: Orphaned packages that will be retired (and everything will most likely burn)

On Tue, Feb 12, 2019 at 11:54 AM Tom Hughes wrote: > On 12/02/2019 10:43, Adam Samalik wrote: > > > I might be missing something here, so excuse me if that's obvious, but > > wouldn't this happen without Modularity anyway? I mean, how does > > Modularity relate

Re: Proposal: Stewardship Group / SIG for taking care of otherwise "module-only" packages

The Modularity Team works on enabling default modules to be present in the traditional buildroot. The work is tracked here: https://tree.taiga.io/project/modularity-wg/epic/12 We would love to contributions towards that. I'm willing to mentor anyone interested regarding Modularity. However, we mig

Re: Orphaned packages that will be retired (and everything will most likely burn)

On Tue, Feb 12, 2019 at 11:03 AM Miro Hrončok wrote: > On 12. 02. 19 10:47, Brian (bex) Exelbierd wrote: > > > > > > On Tue, Feb 12, 2019 at 10:17 AM Tom Hughes > > wrote: > > > > So basically the module squad have managed to ensure that everything > > that relies

Re: F30 Self-Contained Change proposal: Bash 5.0

On Thu, Jan 31, 2019 at 6:19 PM Neal Gompa wrote: > On Thu, Jan 31, 2019 at 6:07 AM Matthew Miller > wrote: > > > > On Tue, Jan 29, 2019 at 11:06:25PM -0500, Neal Gompa wrote: > > > Please don't do that. You'll basically break the distribution for all > > > third-party packagers. Modules are not

[modularity] Policy change: module defaults changes & Fedora Changes

The Modularity Team has published an updated policy regarding changing module defaults and submitting Fedora Changes [1]. Simplified summary: instead of: "Packagers must submit a Fedora Change when changing module defaults." it now says: "Packagers should submit a Fedora Change when changing modul

[modularity] Querying modular content — workaround

I've just published a blog post about querying modular content [1] which might be useful if you maintain modules. It should help you, at least partly, in the following example scenarios: Rebuilding dependencies after major changes * A new version of an interpreted language lands in Fedora as a se

Re: [Modularity] Working Group IRC meeting minutes (2018-12-04)

On Tue, Dec 4, 2018 at 5:14 PM Nils Philippsen wrote: > = > #fedora-meeting-3: Weekly Meeting of the Modularity Working Group > = > > > Meeting started by nils at 15:02:

[modularity] Topics for the Modularity WG meeting today

Sorry for the last-minute email. There are two things I'd like to discuss today in the Modularity WG meeting [0]: I'd like to get the "Stream default changes & Fedora Changes" [1] issue voted on and hopefully off the table — there are already two +1s in the ticket, and it doesn't introduce any sig

Re: Fedora Lifecycles: imagine longer-term possibilities

Do we have any user data about what "stability" means to users and on what different levels that can be achieved? Is it about app versions such as MariaDB? is it about language runtime versions such as Node.js? is it about things like glibc? or kernel? Or does it need to be the whole distro as we h

[modularity] Contribute to Modularity architecture discussions

Just to make sure this reaches all interested parties, we have some important discussions about Modularity going on in Pagure tickets: Distribution Upgrades (reaching decision) — Handling modules, streams, and defaults during major distribution upgrades. * Tracker: https://tree.taiga.io/project/mo

Fedora Modularity Classroom for packagers next Tuesday

Hey all, I'll be hosting a Fedora Modularity Classroom targeted at packagers who want to build multiple versions of software on independent lifecycles for Fedora. When: Tuesday, October 09 at 1400 UTC How: Bluejeans https://bluejeans.com/6638527489 (or simply dial MODULARITY) More details: https

Re: Fedora Packaging Guidelines on docs.fedoraproject.org

On Fri, 28 Sep 2018 at 16:27, Igor Gnatenko < ignatenkobr...@fedoraproject.org> wrote: > Hello everyone, > > We have moved packaging guidelines onto docs.fedoraproject.org[0]. > If you find any error or would like to change something, don't hesitate to > open ticket or submit pull request for pack

Re: Managing stream (arbitrary) branch and module lifecycles

I thought about this for a while, and I can see some conceptual similarities between upgrading a major Fedora release and changing a module stream. I tried to think about major Fedora releases (I mean f28, f29, etc) as "streams" of Fedora, the same way as streams of modules, with stable API. Until

Re: Managing stream (arbitrary) branch and module lifecycles

On Thu, Sep 20, 2018 at 4:17 PM Stephen Gallagher wrote: > On Thu, Sep 20, 2018 at 10:16 AM Matthew Miller > wrote: > > > > On Thu, Sep 20, 2018 at 03:58:20PM +0200, Petr Šabata wrote: > > > > Is there a way for users to say "keep me on whatever module is the > default" > > > > when upgrading? >

Re: Managing stream (arbitrary) branch and module lifecycles

On Mon, Sep 17, 2018 at 12:20 PM Petr Šabata wrote: > On Mon, Sep 03, 2018 at 03:35:50PM +0200, Adam Samalik wrote: > > This is a summary of a recent thread [1]. > > > > Traditional branches (such as "f29") have their EOL (end of life) encoded > > in the na

Re: Managing stream (arbitrary) branch and module lifecycles

On Wed, Sep 12, 2018 at 10:19 PM Matthew Miller wrote: > On Mon, Sep 03, 2018 at 03:35:50PM +0200, Adam Samalik wrote: > > There would be a policy that a module can reach its EOL in the middle of > a > > Fedora release to prevent madness. > > Can or can't? I assume y

Re: Managing stream (arbitrary) branch and module lifecycles

On Wed, Sep 12, 2018 at 10:54 AM Dominik 'Rathann' Mierzejewski < domi...@greysector.net> wrote: > On Tuesday, 11 September 2018 at 21:43, Richard Shaw wrote: > [...] > > This would take care of most of the complains about people using "git > merge > > master" across release branches (even though

Re: Managing stream (arbitrary) branch and module lifecycles

On Tue, Sep 11, 2018 at 10:08 PM Richard Shaw wrote: > On Tue, Sep 11, 2018 at 2:30 PM Adam Samalik wrote: > >> On Wed, Sep 5, 2018 at 3:43 PM Richard Shaw wrote: >> As a packager, what is your experience with lifecycles of your packages? >> Do you get a specific EOL da

Re: [modularity] Removing obsolete github repositories with module definitions

gt; +1 > > +1 as well. > > P > > > > > On Tue, Sep 11, 2018 at 3:04 PM Adam Samalik > wrote: > > > > > >> We have some obsolete github repositories [1] from the f26 and f27 > period > > >> we are no longer using. I feel like i

Re: [modularity] Recommended platform: [] and version 2 format

That's right! This and more is documented in the Modularity section of Fedora Docs: https://docs.fedoraproject.org/en-US/modularity/making-modules/defining-modules/ On Wed, Sep 12, 2018 at 10:56 AM Jun Aruga wrote: > Just sharing information. > > When talking with a person in modularity team, I

Re: Managing stream (arbitrary) branch and module lifecycles

On Wed, Sep 5, 2018 at 3:43 PM Richard Shaw wrote: > On Mon, Sep 3, 2018 at 8:36 AM Adam Samalik wrote: > >> >> So... any comments to the concept? Any ideas about workflows or processes >> of managing the EOL values? >> > > Looking forward to this but I w

[modularity] Removing obsolete github repositories with module definitions

We have some obsolete github repositories [1] from the f26 and f27 period we are no longer using. I feel like it might be confusing to people. So I'd like to remove them all. Any objections? [1] https://github.com/modularity-modules/ -- Adam Šamalík --- Software Engineer

Re: Building multiple version of a package from same dist-git repo

On Mon, Sep 3, 2018 at 3:02 PM Neal Gompa wrote: > On Mon, Sep 3, 2018 at 8:02 AM Adam Samalik wrote: > > > > > > > > On Mon, Sep 3, 2018 at 1:57 PM Richard Shaw > wrote: > >> > >> On Mon, Sep 3, 2018 at 1:32 AM Adam Samalik > wrote: > &

Managing stream (arbitrary) branch and module lifecycles

This is a summary of a recent thread [1]. Traditional branches (such as "f29") have their EOL (end of life) encoded in the name. But what about stream branches [2] (such as "2.4" or "latest")? Stream branches of RPM packages would always have an EOL associated with them. The format would be on of

Re: Building multiple version of a package from same dist-git repo

On Mon, Sep 3, 2018 at 1:57 PM Richard Shaw wrote: > On Mon, Sep 3, 2018 at 1:32 AM Adam Samalik wrote: > >> >> I thought that Arbitrary Branching (now referred to as Stream Branching) >> was initially developed for Modularity only. >> >> Were there any pla

Re: Building multiple version of a package from same dist-git repo

On Sun, 2 Sep 2018 at 18:21, Adam Williamson wrote: > On Sun, 2018-09-02 at 17:51 +0200, Igor Gnatenko wrote: > > Hello, > > > > is it possible to build packages like foo0.6 from dist-git repo with name > > foo and not foo0.6? > > > > Since in Rust ecosystem from time to time we need to build mul

Re: [modularity] Managing module lifecycles — let's talk!

On Fri, Aug 31, 2018 at 5:01 PM Matthew Miller wrote: > On Wed, Aug 29, 2018 at 10:26:29AM +0200, Adam Samalik wrote: > > > Would it be necessary for us to pick one or the other here? IOW, > > > whether the maintainer picked a specific date or a release, the EOL > > &g

Re: Buildroot-only modules

On Tue, Aug 28, 2018 at 1:23 AM Mikolaj Izdebski wrote: > Some modules are built in MBS/Koji but are never released to users. > Currently such modules can only be used as build dependencies of other > modules. In future, if solution like "ursa-major" [1] is implemented, > such modules could also

Re: [modularity] Managing module lifecycles — let's talk!

On Tue, Aug 28, 2018 at 6:44 PM Paul Frields wrote: > On Wed, Aug 22, 2018 at 7:26 AM Adam Samalik wrote: > > == Approaches > > > > Option 1: The current, yet unfinished approach > > > > We specify an EOL (end of life) date for each stream branch of > in

Re: Idea: let's use Pagure to track Changes

I would definitely love that! Having the ability to list all changes at a single place, comment, and even organise them by tags seems like a way forward. BTW I know that Pagure stores issues in git, so that could solve the history problem, although I don't know how exactly is that implemented. O

Re: [modularity] Managing module lifecycles — let's talk!

endencies and components, but that would just be > used to flag problems. > Something like this was one of my initial thoughts as well, glad you brought it up. Having a "forced module EOL", maybe as an optional override could be a good idea. > > Owen > > > On Wed,

[modularity] Managing module lifecycles — let's talk!

During the Modularity WG meeting yesterday [1], we've touched the topic of module lifecycles. Even though there are some ideas in the air as well as some code written, we haven't reached a state in which we would know how exactly to deal with it. So I'd like to discuss it here with a wider audience

[modularity] Creating modules — docs updates

There have been some recent updates to the Making Modules section in Fedora Docs [1], especially Adding new Modules [2] and Defining Modules in modulemd [3] which will guide you through the whole process of creating a new module in Fedora. So I thought it's worth pointing out here. Also, let me kno

  1   2   >