Re: DNF5 Blockers
On Tue, Oct 11, 2022 at 7:13 AM Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> wrote: > On Tue, Oct 11, 2022 at 11:48:14AM +0200, Fabio Valentini wrote: > > On Mon, Oct 10, 2022 at 9:15 AM Jaroslav Mracek > wrote: > > > > > > Please can you be more specific which kind of functionality is > required for particular command? Why is it important to know what user case > you want to resolve it? Commands has multiple options and some of them > could be unused. Specially repoquery has tons of options. Knowing critical > usercase will help us a lot to not only provide the same option but to > improve DNF5 behavior in comparison to DNF4. > > > > > > I recommend to create for each user case or command an issue - > https://github.com/rpm-software-management/dnf5/issues. Please provide as > much as possible information to understand the user case to be able to set > a proper priority. > > > > Determining the scope of such big Changes is usually done by the > > person who proposes the change ... > > I think it's safe to assume that most commands / options are used by > > at least some people / tools / scripts, so dropping features is going > > to be painful, and should be avoided, if possible. > > Yes. And looking at this from the other angle: if you ask people what > features they need, the answer will be "yes" ;) Essentially, pretty > much every feature ever created has *some* user, and often people will > only remember about a feature when it turns out that it is missing in > the new implementation. Also, other things being equal, people prefer > that the interface is unchanged. This just makes life easier for them. > I agree with you Zbyszek. OTOH "identical interface" doesn't seem like a fair requirement. (I don't believe you were suggesting it was.) Thus, if we're switching to an entirely new system where > reimplementing every feature and interface of the old system is not > possible, people proposing the change need to figure out what *can* be > implemented, and weigh the efforts required against how needed the > feature really is, This sounds reasonable -- describe what will be provided at a minimum. > propose alternatives for things which are too hard > or too costly to reimplement, This sounds reasonable if all we're asking is to provide suggestions or alternatives for a few things that are more prominent changes. Not alternatives for every possible function. That would divert too much energy from more useful work. > and in the end make some judgement calls. > Are you suggesting the DNF team can make these calls? That sounds like a collegial level of trust and seems okay, if so. But it seems at odds with the original request, so it should be clear who's accountable for making what calls. -- Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_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
Orphaning packages
Hi, I've orphaned the following packages for lack of time: nautilus-search-tool pinpoint They are available for someone to pick up if desired. I'm asking co-maintainers about some other packages I own, and if I get no response, there may be some more to follow (a few minor drupal7 and PHP modules, odfpy, and pioneers). Let me know if any appeal to you: https://src.fedoraproject.org/user/pfrields/projects -- Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_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
Re: CPE Git Forge Decision
On Thu, Apr 2, 2020 at 1:12 PM Robbie Harwood wrote: > Paul Frields writes: > > Neal Gompa wrote: [...snip...] > >> It's also important to note that at the core of GitLab's incentive > >> model is that they want to remove incentives to use FOSS solutions in > >> favor of their unified proprietary solution. They are constantly > >> integrating features and capabilities into the proprietary parts to > >> make it "juicier" for enterprises who don't really have a compunction > >> about whether they are using Free Software solutions or not, or even > >> may not be willing to support them if it was Free Software because of > >> outmoded thinking. > >> > >> The consequence of this is that it starves interest and development in > >> FOSS solutions, and contributes to making the FOSS ecosystem weaker > >> over time. > > > > That statement rings hollow for me, when Github is arguably the single > > biggest vendor of open source in the world, no part of itself is open > > source, > > I assume you didn't mean quite that. Sure, it's not totally open > source, but it's built on and uses open source tools, just like many > other applications. In a personal example, I've fixed something on > github by patching https://github.com/jch/html-pipeline/ . Or more > bulk, there are 340 repos at https://github.com/github . You're absolutely right, my apologies. I should have said it doesn't have a FOSS offering or the like. However, thank you for helping make my point, which is that there are many shades in which open source contribution comes. -- Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CPE Git Forge Decision
On Wed, Apr 1, 2020, 7:53 PM Michael Catanzaro wrote: > On Wed, Apr 1, 2020 at 3:39 pm, Chris Murphy > wrote: > > Is the FOSS position adequately represented on the Council? > > From my reading of [1], the Council decision is that we use FOSS in > our infrastructure except where it is "not viable and not available." > In the case of dist-git, it seems undeniable that FOSS is both viable > and available (whether it's Pagure or GitLab CE). Council hasn't > actually approved a move to a proprietary version of GitLab yet afaik. > > [1] > > https://meetbot-raw.fedoraproject.org/teams/council/council.2020-04-01-14.00.log.html For a solution to be viable it needs to meet requirements. -- Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CPE Git Forge Decision
On Wed, Apr 1, 2020 at 7:03 AM Neal Gompa wrote: > > On Wed, Apr 1, 2020 at 6:52 AM Nicolas Mailhot via devel > wrote: > > > > Le mercredi 01 avril 2020 à 11:30 +0100, Leigh Griffin a écrit : > > > > > > To distill it down: > > > > > > - Gitlab has more features that are needed right now for our > > > stakeholder group > > > - Gitlab has an entire company dedicated to roadmap features, we do > > > not. > > > > Unfortunately, Gitlab’s roadmap is also conflicting with Fedora > > objectives. The bread and butter of Gitlab is intermediating between > > devs and end users, culling free software intermediaries like > > distributions, and positionning itself in their stead. That is unlikely > > to result in any commitment to making distribution workflows work. > > > > That would not be a problem if the disintermediation worked, but like > > many actors Gitlab sees the $$$ and power in being the > > desintermediator, and does not care if the result is deffective, as > > long as $$$ and power flows its way. > > > > It's also important to note that at the core of GitLab's incentive > model is that they want to remove incentives to use FOSS solutions in > favor of their unified proprietary solution. They are constantly > integrating features and capabilities into the proprietary parts to > make it "juicier" for enterprises who don't really have a compunction > about whether they are using Free Software solutions or not, or even > may not be willing to support them if it was Free Software because of > outmoded thinking. > > The consequence of this is that it starves interest and development in > FOSS solutions, and contributes to making the FOSS ecosystem weaker > over time. That statement rings hollow for me, when Github is arguably the single biggest vendor of open source in the world, no part of itself is open source, and thanks to its pervasiveness, open source has won the war of how development should work. > It wouldn't surprise me if not many people at Red Hat sat down and > thought seriously about that particular consequence, because it's not > exactly an obvious one. I don't know how many people do, since it's a growing company. I assure you some of us do. :-) > > At heart, Fedora is a tooling project. It’s a collective of people that > > chose to use a specific integration toolchain. Anything involved in > > creating Fedora packages cuts deep into the project core. (unlike, say, > > calendaring). > > > > It’s easy to forget this when making tooling decisions, > > because it is so pervasive, most do not see it anymore. Tooling is > > anything but accessory to the project. > > > > Exactly. This is a huge part of why people are so upset over this, > because if you take away our tools, you take away the reason to be > passionate about Fedora. And thus, you remove why people use and > contribute to Fedora in the first place. My reason for being passionate about Fedora is mainly about helping people use the software and content we provide in ways that serve their needs and solve their problems. To do that, I use Inkscape[1], Wordpress[2], and Ansible[3] a lot. [1] https://gitlab.com/inkscape/inkscape [2] https://github.com/WordPress/wordpress-develop [3] https://github.com/ansible/ansible -- Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CPE Git Forge Decision
On Tue, Mar 31, 2020 at 5:23 PM Adam Williamson wrote: > > On Tue, 2020-03-31 at 17:06 -0400, Paul Frields wrote: > > > > > Sure. I tend to think of these as 'upstream projects' that we (Fedora) > > > consume as a downstream. Project hosting has always been a kinda > > > optional bolt-on, I think; going back to the days of fedorahosted.org I > > > don't think we've ever hosted everything "Fedora-adjacent" in our own > > > hosting service, it's always been a "use it if you want to" thing, and > > > the rule for using a project in Fedora has always been "is it open > > > source?", not "how is it hosted?". > > > > Although the Council changed that hard line some time ago. > > Someone told me that a few minutes ago; either I wasn't aware at the > time or have forgotten, but my personal opinion is that this was a > mistake. > > > > For that reason, I think the "what to do with Pagure.io?" element of > > > this discussion is less critical than the src.fp.o part. > > > > > > > A critical part of > > > > our infrastructure the NFS shared storage also run an proprietary > > > > software > > > > (NetApp). > > > > > > That's been covered already, and was why I put the "(more or less)" > > > caveat into my quote. Of course, when you're getting to storage > > > appliances, you're getting into pretty fuzzy territory, because we > > > don't worry about the openness of the firmware running on our servers > > > and stuff like that either...we've never quite been at FSF levels of > > > ideological purity. But to me, this is at a different level to that. > > > > I see what we do for a dist-git fronting forge as far less compelling > > for "purity level" tests because nearly all the meaningful content is > > still easily copied and/or forked. Using open source for our specific > > authentication needs (self-service groups, etc.), for instance, is a > > recent example of a more compelling level, and the CPE group is > > putting time into that project accordingly. > > I'm not sure I entirely understand the argument here. Are you saying we > should only care if the specific things we need in Fedora are open > source - like our CLI integrations and so on? If so, isn't that > entirely naturally compatible with using Gitlab CE? After all, if all > you want the external project to be is a generic git forge and you plan > to write all the integration on top of that yourself, Gitlab CE does > that job fine? No, rather what I meant is that since git is git, and I still have my data (and in the cases of all GitLab flavors AFAICT, nearly all the meaningful metadata), I don't find it compelling whether the service itself is fully open source. In fact, I wouldn't be opposed to using GitHub if that were going to gain us some advantage for collaboration that made it worthwhile. -- Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CPE Git Forge Decision
On Tue, Mar 31, 2020 at 3:25 PM Adam Williamson wrote: > > On Tue, 2020-03-31 at 21:18 +0200, Clement Verna wrote: > > On Tue, 31 Mar 2020 at 20:04, Adam Williamson > > wrote: > > > > > On Tue, 2020-03-31 at 13:55 -0400, Matthew Miller wrote: > > > > On Tue, Mar 31, 2020 at 10:44:35AM -0700, Adam Williamson wrote: > > > > > I'm sorry, but I have to agree with Kevin and Michael here to a > > > > > significant extent. Running our own project on open source code has > > > > > always been a very big bright line for Fedora. > > > > > > > > You don't have to be sorry! I think it's very clear that this is the > > > > general > > > > community view. > > > > > > > > > I think Iñaki's take on the "oh, you contribute to Github projects so > > > > > no problem right?" angle is correct. > > > > > > > > Let me be sorry, though. That wasn't mean to be a "oh you..." > > > > statement. It > > > > was that other open source projects are not held to this standard, not > > > > to > > > > "gotcha" Michael or anyone else for their contributions elsewhere. > > > > > > I mean, held by who? This is a standard we have (more or less) held > > > ourselves to. Which, if you think about it, means it's a standard > > > that's in our DNA: we're a group of people who *thought it was > > > important enough to hold ourselves to that standard*. Would it be > > > hypocritical for someone outside of Fedora who happily uses software > > > from other projects that are hosted on Github or whatever to criticize > > > us if we were to do this? Sure, it would be. But this here is not that, > > > it's us holding ourselves to our own standards. > > > > > > Speaking personally, sure, I contribute to Github-hosted projects. I > > > maintain one project on Github (because it's extremely adjacent to > > > another project that's hosted on Github and the maintainers of that > > > project asked me to have it there, so I did). Hell, I send in fixes for > > > entirely proprietary things sometimes...because my overriding itch is, > > > if something is there, at least it had better *work* properly. But I > > > certainly would not consider hosting work that's a fundamental part of > > > Fedora on a proprietary system, I've always seen that as a *complete* > > > non-starter - whether we were considering test automation, result > > > tracking, event organization, anything like that, the very first rule > > > has always been, if it's not open source it's just not on the list at > > > all. And as far as I've noticed, that has been the same for all other > > > core Fedora stuff, for many years. > > > > > > > To add some nuance to stat statement a quite big chunk of the Fedora Infra > > apps are hosted on GitHub (https://github.com/fedora-infra), and relatively > > critical things like Bodhi, FAS, mirrormanager, . As far as I know most > > of Fedora CoreOS (and Silverblue ?) is also on GitHub. > > Sure. I tend to think of these as 'upstream projects' that we (Fedora) > consume as a downstream. Project hosting has always been a kinda > optional bolt-on, I think; going back to the days of fedorahosted.org I > don't think we've ever hosted everything "Fedora-adjacent" in our own > hosting service, it's always been a "use it if you want to" thing, and > the rule for using a project in Fedora has always been "is it open > source?", not "how is it hosted?". Although the Council changed that hard line some time ago. > For that reason, I think the "what to do with Pagure.io?" element of > this discussion is less critical than the src.fp.o part. > > > A critical part of > > our infrastructure the NFS shared storage also run an proprietary software > > (NetApp). > > That's been covered already, and was why I put the "(more or less)" > caveat into my quote. Of course, when you're getting to storage > appliances, you're getting into pretty fuzzy territory, because we > don't worry about the openness of the firmware running on our servers > and stuff like that either...we've never quite been at FSF levels of > ideological purity. But to me, this is at a different level to that. I see what we do for a dist-git fronting forge as far less compelling for "purity level" tests because nearly all the meaningful content is still easily copied and/or forked. Using open source for our specific authentication needs (self-service groups, etc.), for instance, is a recent example of a more compelling level, and the CPE group is putting time into that project accordingly. -- Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
notify-python orphan notice
This package has been orphaned as discussed here: https://bugzilla.redhat.com/show_bug.cgi?id=1738068 -- Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On Tue, Apr 9, 2019 at 12:07 PM Lennart Poettering wrote: [...] > Can we maybe reduce the default set of packages a bit? In particular > the following ones I really don't think should be in our default > install: Although somewhat orthogonal to your notes below, overall there's a lot of package-entangling in the basic platform underlying the Workstation as well. This is something we should look at if we're to make progress in CI and Lifecycle objectives -- i.e. being able to produce basic platform for integration more quickly. I was talking to contyk about this the other day and we are starting to throw some ideas around about that. Again, doesn't solve all your individual concerns below but at least related. A good portion of the other subthread is really about choices made and how we enable bits properly for something like Workstation, which is also valid but a different effort I think. [...] > 3. atd? Do we still need that? Do we have postinst scripts that need >this? If so, wouldn't systemd-run be a better approach for those? >Isn't it time to make this an RPM people install if they want it? Interestingly I think Google Chrome needs this when it installs, though it seems nonsensical to me. (Chrome is installed by about 50% of our users given some informal stats, so writing it off would be shooting ourselves in the foot.) That's something the Workstation folks may want to work with them to fix in a more systemd-ish way. -- Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal: delay F31 release to work out infrastructure and lifecycle challenges
Update: We'll be having discussions over the next few weeks to figure out how we can accommodate Lifecycle work without interrupting the Fedora release cadence. That includes in Brno, where we can meet up f2f with people working on parallel projects in automation, CI, and so on. We may also be able to grab additional people to do work here -- so this doesn't automatically equate to "we have to do more with less/the same people." After talking with the Council as well as some folks who are depending on the cadence, like IoT, it was clear we need to look at this option. For now, I intend to remove the cadence change from the objective requirements, unless more specific reasons why it has to happen become clear. On Wed, Nov 28, 2018 at 1:05 PM Randy Barlow wrote: > > On Wed, 2018-11-28 at 18:19 +0100, Kevin Kofler wrote: > > And why do we need to stop the presses to do that? This is entirely > > orthogonal to distribution development and can be done in parallel. > > The problem is that the people who do the work to get the release done > are the same people who would need to do the retooling work, so there > is a resource conflict. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal: Move to an annual platform release starting at F30
On Wed, Nov 28, 2018 at 7:43 AM Fabio Valentini wrote: > I think the kernel is a bad example here. It's exceedly stable across > releases, so it's probably the one component that's least problematic > to upgrade during a fedora release. The fedora kernel team is already > doing that, and they are doing an excellent job, which they definitely > deserve more praise for than they get. For me, the frequent, > well-executed stable kernel updates are one thing that positively > distinguishes fedora from other non-rolling distros. [...snip...] I wanted to offer a hearty +1 here. I have been thinking more about the optimization needed for a faster release process, which would *not* disadvantage our awesome kernel team. I wouldn't foresee, for example, that we'd freeze on a specific kernel for such a process. On the contrary, the kernel team does an *amazing* job making sure that Fedora is relevant to the upstream kernel community as much as possible. We routinely get fresh kernels with updated hardware support. I wouldn't want to see this stop. I understand the lifecycle goals theoretically also make possible a longer term release. How that would happen should be based on what its consumers need, and (maybe even more importantly) what our maintainers are able to do without each being issued a Fedora Time Turner[1]. I don't want to optimize for that case because a much shorter cycle (even with less fanfare) encourages us to pursue more automation and more contributor empowerment. * * * [1] http://harrypotter.wikia.com/wiki/Time-Turner ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal: Move to an annual platform release starting at F30
On Thu, Nov 29, 2018 at 4:47 AM Miroslav Suchý wrote: > > Dne 27. 11. 18 v 17:04 Josh Boyer napsal(a): > >> In other words, the "technical debt" we are trying to solve here is > >> not project wide and doesn't justify slowing down the whole project > >> permanently. > > I completely disagree. Our release process and tooling is built on > > heroism and tech debt. > > People working on release and people working on packages maintenance are > different group - they are not disjunct, but it > is not the same group. > For example *I* am a maintainer of lots of packages, but the additional works > because of the fedora release is about one > working day per year - and it is mostly because of fedora-upgrade package. > Other packages do not need so much work. I am > more affected by upstream releases. > > Do not forget that annual releases will mean that N-1 release will implicate > 24 months support for packages which will > mean a much more significant impact on us-the maintaners. Let's not get too focused on an annual release (or any specific timeframe for longer release). I know this is something that some people want. I understand that, and it's *possible* to do in a future state where more people are empowered to make releases happen. But a longer release is not the primary goal, merely something that's possible. I'm more interested in a shorter release that implies less added maintainer effort. We already put time into Rawhide, and I would like to see that better leveraged in what we push to consumers. Right now our branch cycle is six months, at which point we have numerous freezes and other operations that consume a lot of manual time. They also bottleneck our pace. I want to increase automation, decrease manual bottlenecks and freezes, and spread out permissions to assemble and push out "ready" content. I would like to optimize for a faster release, making any slower releases possible. Those releases should be based on what the consumers of that release need, as well as the efforts our maintainers have available. -- Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Improving the compose: leave the current compose in place
On Tue, Nov 27, 2018 at 9:59 AM Owen Taylor wrote: > A lot of discussion about improving the compose process seem to end up > with a "reality check" - that ideas have already been tried but don't > work because of requirements a) b) c) d). You can't have the pony, but > maybe if a lot of effort is put into it, you can have a faster rocking > horse. > > If want to fundamentally improve the Fedora workflow we need compose > ponies, we can't just have rocking horses! > > Perhaps it would make sense to leave the current 8-10 hour compose in > place for the forseeable future, and work on a new system in parallel > where the primary constraint is to be as fast as possible. Hopefully > most problems with the slow compose will get sorted out in the fast > composes, and the slow compose will become more reliable. Perhaps in a > distant future, we can make the new system do everything Indeed, this is basically the investigation I've proposed. I also think > I don't know what the system would look like exactly, but you could > imagine things like: > > * Composed of several micro-composes (micro-compose-services?) to > avoid blocking on everything completing successfully. > > * Able to do speculative composes for CI > > * Either x86_64-only, or with decoupled architectures so that we can > throw x86_64 hardware (or cloud resources) at it, and make it super > fast. > > * No IO /mnt/koji during the compose - having a big network share be > central to the process creates a performance bottleneck, makes it hard > to move to the cloud, and potentially adds a lot of "noise" to > figuring out what is going on where things are slow because of some > other entirely different thing is goin gon. > > Add your own bullet points :-) I would like to redefine a couple working assumptions: * Big tools are unwieldy and inevitably silo knowledge. The people behind them are often smart, hard-working, and care about great results. But bedrock FOSS principles say we get more value from rapidly iterating tools to which many people can/do contribute. We should see if we can avoid big tools that solve everything. * Reproducibility is something we can better enforce at development time than use time. It's pretty easy to pick one or more git heads at a certain time (for a tool, a containerized environment, etc.). Let's not get one hand tied behind our back at the outset via outmoded assumptions. Every other bullet point on your list, Owen, I agree with 100%. -- Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal: Move to an annual platform release starting at F30
On Tue, Nov 27, 2018 at 1:40 PM Owen Taylor wrote: > > We can definitely talk about whether moving to a slower cadence for > certain parts of the base platform. But people don't judge Fedora on > how beautifully we maintain glibc and gcc - they mostly judge it by > installing it on a laptop and seeing how well it works. And it doesn't > really matter how reliably we can create minimal container images if > the workstation image doesn't compose or doesn't log in. > > We need clear naming for the workstation releases we do. If we want to > call them F30, F30.1, F31, F31.1 we can, but that doesn't inherently > reduce load on releng or remove the need for infrastructure freezes > ... my assumption was that the idea of delaying F31 is to actually > *not* do an operating system release for a year, and that's something > that I don't think we should do on an ongoing basis. Heard, understood, and agreed. Shortening the compose is a root problem to fix if we want to be able to judge reliability of what we want to release. That way we can test it more or less constantly. As for freezes... right now we freeze for a total of roughly 2-3 months out of 12. We can avoid that with a pause -- at least in part, and maybe in total if we finish enough work to minimize freeze coming out of it. That's why taking the break makes sense. Reclaiming that time, year after year, should be a knock-on effect of being able to release more frequently as a non-event. Then there's less (maybe no) reason to freeze -- the worst thing that happens is we pull the lever the next day. So a healthy part of our investment should be in minimizing recovery time. -- Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal: Move to an annual platform release starting at F30
On Tue, Nov 27, 2018 at 12:19 PM Josh Boyer wrote: > On Tue, Nov 27, 2018 at 11:21 AM Owen Taylor wrote: > > On Tue, Nov 27, 2018 at 11:05 AM Josh Boyer > > wrote: [...snip...] > > > I completely disagree. Our release process and tooling is built on > > > heroism and tech debt. At some point, that is going to cause > > > significant burnout and then people will just wonder what happened > > > when those people stop doing releases. I think it's better to raise > > > awareness at the project level, and build something that is > > > sustainable rather than predicated on "small group of people killing > > > themselves for the greater good". That starts with individual package > > > CI gating, and goes all the way through integration testing between > > > packages in a gated manner, into how we actually *create* all of that > > > plus the things we deem worth of releasing. > > > > I think you are misunderstanding me somehow. I'm 100% on-board with > > improving the processes, catching compose problems in an automated and > > early fashion, making developers fix their own problems, and generally > > making releases a less heroic process. And if that requires a > > temporary cadence chance to get the retooling done, then it's worth > > it. > > Ah, good! > > > But Brendan's proposal to permanently slow down the cadence seems to > > make the assumption that the current release cycle is a heroic effort > > for the entire project - that we're moving too fast to stay on our > > feet. And I don't think that's the case. > > That would be a concern to me as well, assuming we stuck with a > *single* cadence and a *single* platform. With the lifecycle > Objective, aren't we targeting multiple cadences and lifecycles? I > mean, we have this today with Fedora Atomic/CoreOS vs. "regular" > Fedora. Maybe Brendan was thinking singular, but I would very much > like the ability in our tooling a process to have both the faster > moving cadence of today AND a slower moving one. That's another > reason I view a temporary halt as worthwhile. If done correctly, it > enables Fedora to fill more usecases and lifecycles than we could ever > accomplish with a single release. Josh and Owen both have it basically right IMHO. Speeding up the compose, increasing automation, and making it easier for people beyond the core crew to do releases all should allow us to make releases less of a big deal. I would love to get closer to the ostree release (both in terms of content, and cycle) for the majority of current users. That means faster, not slower releases -- and that "release" should be more like a non-event for most people. Not to mention the benefits of being able to revert the platform in case of a problem, etc. But I also agree that a longer cycle can have a place too. The tricky part is to make sure that doesn't turn into multi-stream pain for the proverbial "1000 packagers" group. There should be a way to set the cycle and the overlap to minimize pain. (And I suspect modularity also helps somewhat here.) Take an average packager who cares about long-term. They may have to maintain 5+ streams now if you count EPEL. We want an outcome that is arguably better, or at least no worse. (No, we really want better.) ;-) -- Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal: delay F31 release to work out infrastructure and lifecycle challenges
On Tue, Nov 27, 2018 at 9:50 AM Dennis Gilmore wrote: [...snip...] > > The customers RH serves have specific expectations, and in part that > > dictates how delivery tooling is done. Binding the community to that > > may be counterproductive. This is especially true now that RHEL 8 Beta > > is out -- it's the perfect time for us to be rethinking at that level. > > Compose tooling is largely shared, delivery tooling is not, though > there is room for improvement and convergence on both sides. We should > also consider CentOS and how we can share tooling, process and > resources, they still use something else entirely. Everything used in > Fedora is developed in the open and can be contributed to by anyone. > We have been talking about making the whole process flexible and > dynamic for years. I know internally they would like to have many of > the same things Fedora wants. Yeah, it sounds like we're aiming in the same direction here. This is part of what I mean by "decomposing the compose." We have one rather monolithic process right now, all or nothing. And it does so much that it's impossible to get any fast results from it. That doesn't mean it doesn't work well for what it does. But it's not very flexible, as you pointed out. With a more flexible compose we could choose to do smaller tasks (as well as capitalize on other time savings) for something like a speculative testing build. That kind of build could be used to perform integration testing as well as other tasks (automated, not manual!). We could even potentially test against much of the repetitive, time-consuming matrices manually (and heroically) run by QA. Then only choose to do more extensive tasks based on that being "green." -- Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal: delay F31 release to work out infrastructure and lifecycle challenges
On Tue, Nov 27, 2018 at 4:41 AM Miroslav Suchý wrote: > > Dne 26. 11. 18 v 17:03 Matthew Miller napsal(a): > > * embrace Taiga (an open source kanban tool) for project planning > > * fix the compose speed (target: one hour!) > > * really actually for real gated Rawhide > > * better CI pipeline tests for everything > > * define a base platform -- Red Hat wants to focus resources here > > * better tooling for non-base deliverables > > * better metrics for everything > > My experience is that things are fixed when we are in real time stress. When > we have more time, then people (including > me) are trying to develop/invent new things. > > I have a counter proposal: Make the release every week or month - this will > force us to automate all release processes :) It's funny you mention that, because I could foresee one outcome of focusing on a core platform being that we do a more frequent release. If we can effectively machine-test more of that platform, we could do releases on a timescale of weeks instead of only twice a year. The Atomic WG does this already. This probably makes more sense for an ostree based release than constantly spinning large, multi-GB ISOs. -- Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal: delay F31 release to work out infrastructure and lifecycle challenges
On Mon, Nov 26, 2018 at 5:47 PM Dennis Gilmore wrote: > El lun, 26-11-2018 a las 17:14 -0500, Josh Boyer escribió: > > Because the people that would be tasked with doing the development are > > also tasked with cranking out the release. It's a "need more people > > problem". > > This is no longer entirely true, development of the compose tools is > done entirely by PNT DevOps today. Bodhi and other tools in parts of > the delivery pipeline are developed by people in Fedora Engineering who > also have other tasks to do. > > > > ready to go. Ultimately a lot of those sort of ways of optimising > > > things are things that have been known for some time but no one has > > > actually stepped up to do the dev work and it it into production > > > shape. Stopping the standard distro work won't miraculously make > > > that > > > other work happen and appear. > > > > Well, I kind of disagree. Barring magical people that appear out of > > the woodwork that know how the tools work and how they need to be > > improved, I don't see an alternative. Not doing a release to focus on > > our tech debt seems like a good tradeoff. If there are others that > > really WANT to continue cranking the release with the tools as they > > are today... that might be something that could be pursued. It would > > still require net new contributors to a critical area. > > We would need to engage with the team working on the compose tools and > see what time they can dedicate to meeting Fedora's needs. Likely a > end state needs to be defined. then the work can be scoped. There are a lot of assumptions wrapped up in these statements. I'm not sure we should be assuming that delivery mechanisms ought to all be tied to internal Red Hat teams. This might be a good opportunity for us (meaning people variously assigned in both places) to think about whether we should try to decouple more of our delivery side (compose, push, etc.), while keeping a tight bond at the build/test side. The customers RH serves have specific expectations, and in part that dictates how delivery tooling is done. Binding the community to that may be counterproductive. This is especially true now that RHEL 8 Beta is out -- it's the perfect time for us to be rethinking at that level. -- Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal: delay F31 release to work out infrastructure and lifecycle challenges
On Mon, Nov 26, 2018 at 2:42 PM Adam Williamson wrote: > On Mon, 2018-11-26 at 11:30 -0800, Kevin Fenzi wrote: > > Yeah, I think our goal should be 1 minute... just as realistic as one > > hour. ;) > > > > I have not looked into things recently. However: > > > > * The mock fsync change (https://pagure.io/releng/issue/7909) may help > > some. > > > > * We have plans to redo the setup on the s390x builders, which should > > result in them being much faster. That should help. > > > > * I know pungi maintaienrs have been doing some work to make things > > faster (even in the last release out this morning). > > > > All that said, I am not sure there's going to be a way to get it down to > > an hour. I think getting it down to 3-4hours may be very helpful tho and > > might be possible. > > While we're on the topic of unicorns, if I were the person actually in > charge of this and had the freedom to do it how I wanted, what I'd > really want to do is create a much more *modular* compose process, > where inputs and outputs were defined and associated with each other, > and you could easily define subsets to be produced at different times > for different reasons. Not a compose, but a Compose Construction Kit. A > big chunk of the length of "the compose" is associated with the fact > that we define "the compose" as a single thing which produces (last > time I counted) 70+ deliverables. If we had an easy way to say 'ok, > right now we need a compose which produces A, B, C and D from the > minimum necessary sets of inputs', that would be a massive improvement. > > This hasn't been true for a while (we actually have something like half > a dozen or more different "composes", right now), but the system is > still less flexible and it's still more difficult to configure > different composes than it really ought to be. Adam puts his finger on an important aspect of the work, which is to "decompose the compose" (sorry). We need the ability to produce enough A, B, C and D (abusing his example) to do integration tests for specific inputs, such that maintainers get feedback in a reasonable timeframe on their builds. With that, gating Rawhide can be an actual thing. -- Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal: delay F31 release to work out infrastructure and lifecycle challenges
On Mon, Nov 26, 2018 at 1:59 PM Peter Robinson wrote: > On Mon, Nov 26, 2018 at 6:53 PM Adam Williamson > wrote: > > > > On Mon, 2018-11-26 at 18:44 +, Peter Robinson wrote: > > > On Mon, Nov 26, 2018 at 4:05 PM Matthew Miller > > > wrote: > > > > On Fri, Nov 16, 2018 at 09:50:33AM -0500, Paul Frields wrote: > > > > > Here's the summary from the page, which proposes we pause the release > > > > > after F30 for these efforts: > > > > > > > > I know it was a big time-off holiday week in the US, but I expected a > > > > little > > > > more interest in this post. Perhaps it seemed like too much text to > > > > digest > > > > along with turkey and stuffing. :) I'm highlighting it with a subject > > > > reflecting the big, direct impact, and here's some other top-level > > > > proposals: > > > > > > > > * embrace Taiga (an open source kanban tool) for project planning > > > > * fix the compose speed (target: one hour!) > > > > > > Can I have a unicorn? Everyone wants this bug absolutely no one has > > > done analysis. > > > > I just don't believe this is true. I'm pretty sure Dennis and Kevin > > have both looked into it before. > > Yes, I mean recently, I was involved in the last time we attempted > this, and there was a number of things identified but quite a bit has > changed since that last happened. One of the large factors -- which I think was noted in the page -- was RPM scriptlets. Stephen Gallagher met with WIll Woods and James Antill just recently to talk about this. The time savings was substantial. Combining that with reducing the size of "speculative composes" that could be used for CI and other pre-ship purposes could get us to where we want to be. Stephen's carrying a heavy duty project at the moment but when that's done in a few weeks, this will be getting more attention. > > > The fact of the matter is that the compose has a LOT of > > > I/O and I/O is slow and the cost to upgrade the infrastructure to get > > > high through put I/O is expensive and no one has ever offered the > > > budget to resolve that problem. The fact of the matter with this is > > > that we now produce a lot of release artifacts and that takes time, > > > some of it can probably be run more in parallel, and possibly some > > > things run at different times but without a combination of investment > > > in infrastructure, and maybe even hacking and slashing of components > > > this is not simply a check box. > > > > That's why the proposal is to skip an entire release to give us time to > > work on it. If it was easy, that wouldn't be necessary. > > > > There are of course at least *two* possible solutions to "there's lots > > of I/O". One is "throw money at making the I/O faster", the other is > > "figure out how to do less I/O". > > > > One hour is a *target*, not a *requirement*. I don't think anyone's > > going to consider the time wasted if we wind up getting it down to two > > hours instead of one. > > > > (Though personally I'd like ten minutes. And two unicorns.) Just so. -- Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Lifecycle objective - problems, solutions, and proposal
I worked with FPL Matthew Miller and our engineering manager Jim Perrin, among others, to define the various problems we want to solve in diversifying the Fedora lifecycle. We're seeking review and feedback from community members. The most salient feedback will be from those involved in the efforts we describe, but we welcome all constructive feedback. Here's the summary from the page, which proposes we pause the release after F30 for these efforts: * * * Fedora’s singular lifecycle has been in place for almost a decade and a half. During that time, technology users have changed how they consume platform and applications. Fedora needs to be more toward the forefront of these changes. But more importantly, Fedora needs to be more hospitable to community management of lifecycle. Currently Fedora can’t scale for more community ownership of the things we release: (1) Only a few people can build and push out releases; and (2) we manage releases largely based on that staffing. The Fedora community should be able to run releases of content themselves, using tools that work well, with only minimal oversight, and determine their own schedule for doing so. This implies a great deal of both redesign and reworking of tools and processes. To unblock the community, several things need to happen. We need a faster, more scalable compose to enable CI/CD operations; we need to automate more testing and quality measures; and we need to update our delivery tools and processes. We also need to track and coordinate this work across teams, since it involves collaboration among Fedora infrastructure, QA, applications, release engineering, CentOS CI, maintainers, and more. We should skip the F31 release cycle and leave F30 in place longer in order to focus on improving the tooling and testing changes. These tooling changes will improve the overall reliability of Fedora, and will decrease the manual effort and complexities involved in producing the distribution artifacts. Although we’ve done this before to make “editions” happen, the intent is to track this multi-team effort more actively so we can (1) use the time as well as possible, and (2) give the work maximum transparency. * * * The full page is here, with a set of problems, solutions, and actions proposed. I invite you to take time to read it in detail: https://fedoraproject.org/wiki/Objectives/Lifecycle/Problem_statements I also attached that page to the main Lifecycle objective page here, which was previously approved by the Council: https://fedoraproject.org/wiki/Objectives/Lifecycle Rather than try to spin this one email into a thread of doom that people will give up on reading, I encourage those with feedback to open a thread for any particular topic. That way the community discussion should be more useful for all. I'll collect input and use it both for responses and to help tweak plans for (hopefully) optimal results. I'm on vacation next week, for which timing I apologize. But I'll try to look at mail here from time to time and when I return. -- Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Moving on from Council Engineering role
On Thu, Oct 11, 2018 at 12:54 PM Josh Boyer wrote: > I believe it's time for me to move on from my current role as the > Council Engineering representative. When I resigned from FESCo a bit > ago, I thought I could still fulfill this role. Unfortunately, that > turns out to not be the case. I cannot in good conscience hold a seat > on the Council and be an absentee member. > > As we look to the future for Fedora, we need someone with more active > participation to be present. Fortunately, we have a large set of very > competent people that I believe can step into this role without issue. > While it is only a suggestion, I would like to nominate Petr Šabata as > the new Council Engineering rep. He is more than capable of > discussing the technical implications of Modularity and the newly > proposed Objective from Paul. The decision will ultimately be up to > FESCo and the Council of course. > > These are important times for Fedora and I'm excited for the future! > I will continue to participate as I can and I'm looking forward to > seeing the directions we take as a project and as a distribution. It > has been an honor to be part of the Fedora Council for the past few > years. Thank you to the community for trusting me with that role for > so long. I'm abstaining from weighing in on the nomination for obvious reasons. But I did want to say a huge thank you to Josh for all he's done in these roles over the past years. He was an enormously helpful Board member during my FPL days, and has continued to be a steady guide since then. My blue fedora is off to you, sir! -- Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [modularity] Managing module lifecycles — let's talk!
On Wed, Aug 29, 2018 at 4:35 AM Adam Samalik wrote: > 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 individual >> > packages. This is done when requesting a new stream branch for a package >> > [2] by passing "--sl rawhide:2020-12-01" to fedpkg. This value is stored, >> > but not yet consumed by anything. >> > >> > The next step would be having the build system to be smart enough to: >> > >> > 1) Figure out the module's EOL based on its packages' EOLs. >> > 2) Only build the module for the Fedora releases that have their EOL >> > before the module stream's EOL. >> > >> > There is a caveat, however: Giving dates like this might be hard for the >> > maintainer. The upstream project might not have one, etc. In that case the >> > maintainer needs to come up with a date — even one closer in the future, >> > and increase it gradually (and think about it, and do it for all the >> > packages), or one much further in the future which could imply promises >> > the maintainer had no intention to make. >> > >> > Option 2: More dynamic, based on rawhide >> > >> > Simply put, we wouldn't specify an EOL as a date, but as a Fedora release. >> > And if a maintainer indicates that a certain stream branch of a package is >> > maintained in rawhide, it would mean it's maintained for all active Fedora >> > releases + the next one + potentially forever or until it's retired in >> > rawhide. >> > >> > The build system would then do the same thing as above: >> > >> > 1) Figure out the module's EOL based on its packages' EOLs. >> > 2) Only build the module for the Fedora releases that have their EOL >> > before the module stream's EOL. >> >> 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 >> would resolve to a date. If they pick none, or explicitly choose >> 'rawhide,' then the artifact is essentially on a rolling window. > > > Yeah... that's a good point. Maybe having the ability to specify EOL as a > specific Fedora release or a date could be a good way forward. I like that. > > But apart from the format, we also need to have a good way of managing > changes of it over time. > >> It seems to me this is also an opportunity, through automation, to >> converge some conventional package activities as well. So whether >> dealing with a module or a conventional package, we might have the >> opportunity to set a EOL date, a Fedora release, or nothing/rawhide. >> The work of retiring packages or modules could be automated based on >> specifying a date (with appropriate warnings to the maintainers and >> public). > > > Traditional release branches already have an EOL — the release itself, > encoded in the name of the branch. I think that an EOL of a specific stream > branch vs. retiring an entire package are two separate problems, although we > might have a mechanism of automatically retiring a package when all its > stream branches reach EOL. > > But how would that work for the traditionally-branched packages? It's like > coming up with an EOL of a specific version for stream branches vs. coming up > with en EOL of the whole package which means all it's potential versions, > possibly the whole upstream project, because in traditional branching, any > new release branch can potentially have a new version if either the old EOLs > or a new is stable enough. > > Anyway, I like the idea, and I think we could definitely make it work for > modules and packages in stream branches. I wonder if there are compelling reasons to simplify branch management in such a way it brings us closer to upstream and less bound to the traditional release concept -- i.e. should everything be managed with stream branches? -- Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [modularity] Managing module lifecycles — let's talk!
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 individual > packages. This is done when requesting a new stream branch for a package [2] > by passing "--sl rawhide:2020-12-01" to fedpkg. This value is stored, but not > yet consumed by anything. > > The next step would be having the build system to be smart enough to: > > 1) Figure out the module's EOL based on its packages' EOLs. > 2) Only build the module for the Fedora releases that have their EOL before > the module stream's EOL. > > There is a caveat, however: Giving dates like this might be hard for the > maintainer. The upstream project might not have one, etc. In that case the > maintainer needs to come up with a date — even one closer in the future, and > increase it gradually (and think about it, and do it for all the packages), > or one much further in the future which could imply promises the maintainer > had no intention to make. > > Option 2: More dynamic, based on rawhide > > Simply put, we wouldn't specify an EOL as a date, but as a Fedora release. > And if a maintainer indicates that a certain stream branch of a package is > maintained in rawhide, it would mean it's maintained for all active Fedora > releases + the next one + potentially forever or until it's retired in > rawhide. > > The build system would then do the same thing as above: > > 1) Figure out the module's EOL based on its packages' EOLs. > 2) Only build the module for the Fedora releases that have their EOL before > the module stream's EOL. 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 would resolve to a date. If they pick none, or explicitly choose 'rawhide,' then the artifact is essentially on a rolling window. It seems to me this is also an opportunity, through automation, to converge some conventional package activities as well. So whether dealing with a module or a conventional package, we might have the opportunity to set a EOL date, a Fedora release, or nothing/rawhide. The work of retiring packages or modules could be automated based on specifying a date (with appropriate warnings to the maintainers and public). -- Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: PokerTH orphaned
On Tue, Aug 2, 2011 at 12:32 PM, Ryan Rix wrote: > On Tue 2 August 2011 11:36:20 Hans de Goede wrote: >> Hi, >> >> On 08/01/2011 09:44 PM, Ryan Rix wrote: >> > On Mon 1 August 2011 19:43:37 Tomas Mraz wrote: >> >> On Mon, 2011-08-01 at 10:29 -0700, Ryan Rix wrote: >> >>> On Mon 1 August 2011 11:46:00 Jussi Lehtola wrote: >> Hi, >> >> >> I've just orphaned PokerTH, since I'm trying to free myself some >> time >> and I don't use it myself. >> >> PokerTH does not currently build on rawhide, since OpenSSL support >> has >> been dropped from GnuTLS a week ago (BZ #726697). Getting it to >> build >> again would then require building against OpenSSL (and asking >> upstream >> for a GPL license exception), or shipping a private copy of >> GnuTLS. >> >>> >> >>> I picked up rawhide through F-14. If I cant get this building, I'll >> >>> orphan it again in a week's time. >> >> >> >> Shipping a private copy of GnuTLS would have to get an exception I do >> >> not think such exception should/would be granted. I can only recommend >> >> you to look at the NSS OpenSSL compatibility support library and >> >> patching PokerTH to use it instead of the GnuTLS. >> > >> > I've talked to a few people about this now, including some folks at >> > PokerTH about it, and they're confused as to why this change is >> > happening in GnuTLS at all, and your comment in the bug report did not >> > seem to explain it to them; could you (or anyone) explain better why >> > OpenSSL support in gnutls is a Bad Thing? >> >> Ryan, have you read the initial description of: >> https://bugzilla.redhat.com/show_bug.cgi?id=460310 >> >> ? >> >> The problem is that gnutls's openssl compatibility uses the same symbol >> names as openssl itself thus polluting the dynamic linker symbol namespace. >> So if an application uses a library which is linked against openssl (for >> example ldap libs through pam) and uses gnutls-openssl then the ldap >> libraries will end up calling functions inside gnutls-openssl rather then >> inside openssl, since the gnutls-openssl symbols are already present in the >> dynamic linkers symbol namespace. This then goes boom big time, since the 2 >> are not ABI compatible. >> >> Since gnutls-openssl is not ABI compatible it should not be using the same >> function / variable names. >> >> Tomas has chosen to fix this problem by simply disabling the openssl compat >> part of gnutls (which as the above bug shows is broken by design) given that >> only 3 apps use this, this seems like a sane choice to me. >> >> The best way forward is probably to ask PokerTH upstream to add the >> standard openssl license exception boilerplate to their license, I did >> so successfully with gkrellm and switched to simply using the real openssl. > > Makes sense, thanks Hans. :) > > I actually talked to them, and they say that openssl is pulled in only for > linking libcurl, and that PokerTH itself is using gcrypt for the Big Stuff, so > it should be fairly easy to fix/work around. Had any luck with this, Ryan? (Asked the non-programmer guy who really likes using this package.) -- Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Elections: Nominations open Sat 2010-04-24
With a Fedora release coming soon, it's also time for Fedora Elections. Both the Fedora Project Board and the Fedora Engineering Steering Committee (FESCo) will have open seats during this election cycle. Nominations for these seats open tomorrow, Saturday, April 24, 2010. You can nominate yourself, or someone else. It's recommended if you intend to nominate someone else that you consult with that person first. The entire election schedule, and other important information for all nominees, is posted on the wiki's main Elections page, and the specific nomination pages for the Board and FESCo: https://fedoraproject.org/wiki/Elections https://fedoraproject.org/wiki/Board_nominations https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations You can also find more information about both these at their main wiki pages: https://fedoraproject.org/wiki/Board https://fedoraproject.org/wiki/FESCo Please thoughtfully consider how you can best contribute to Fedora by serving on one of these important committees, or encourage someone you know who can make a difference to serve. Thank you! -- Paul (25 days to Fedora 13!) ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Sat, Feb 27, 2010 at 7:31 AM, Kevin Kofler wrote: > Paul W. Frields wrote: >> How'd it happen? I commented directly in the Bugzilla bugs with the >> link and told the subscribers to the bugs that the package would not >> be issued until some of them tested it and posted feedback to tell me >> their bugs were fixed. > > I see why you're doing it, but still, this is essentially blackmailing > users, I'm not sure it's a good plan to follow. Sorry, I really need to know if my users experience something different than me before I feel comfortable pushing a package update out. This is especially true for a package where I personally am acquainted with a dozen or more users who use it -- meaning there are likely thousands of users out there affected my update. I'm not being pretentious about my or my package's importance to those users, just trying to make sure I don't make things any worse for them if I have an opportunity to do better. Turns out my actual text was a bit less stark: https://bugzilla.redhat.com/show_bug.cgi?id=543278#c53 "The sooner we receive feedback, the sooner we'll know whether we can release this update to the stable distribution. Thanks for participating." But there was a singular goal, which is to encourage people to try out the update so we'd have more assurance the problem was indeed fixed. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Sat, Feb 27, 2010 at 3:45 AM, Camilo Mesias wrote: > On Sat, Feb 27, 2010 at 6:12 AM, Adam Williamson wrote: >> this is a *terrible* idea. We may see users as a 'resource', but they >> don't see themselves this way. We should not interrupt their usage of >> their computer to try and exploit them to our ends. > > What if it was an opt-in scheme? Users would consent to receive a > limited number of contacts about their current packages and for their > trouble would get streamlined access to potential fixes. > > I think there's enough in that for the opt-in scheme to be marketed > successfully, because although some people would see the interactions > as annoying, others would welcome the chance to participate. That was more the idea. I didn't declare any implementation details because I was pretty sure that would be a topic of some contention. Maybe "coerce" was the wrong idea; the idea was not to make involuntary guinea pigs of anyone, but to give people the chance to take an on-ramp to contribution. We're simply not doing that at all right now, which, given the technical process required, is not too much different than erecting a barrier to participation. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to install source packages?
On Sat, Jan 9, 2010 at 12:26 PM, Jud Craft wrote: > I've enabled the updates-source and fedora-source repositories in > PackageKit, but how do I, for example, install the source package for > Cairo? > > A packagekit search for Cairo returns nothing from the updates-source > or fedora-source repositories, and nothing called "cairo-source" or > anything of the like. Just binary cairo and cairo-devel. > > In short, how do I install source packages? Have I missed an obvious > step or is it really unintuitive? The easiest way to do this IME is: 1. Ensure 'yum-utils' is installed 2. Run 'yumdownloader --source cairo' 3. 'rpm -ivh cairo-*.src.rpm' The resulting .spec file and source will be under ~/rpmbuild/ . -- Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
