On Tue, Nov 26, 2019 at 05:35:27PM +0000, Zbigniew Jędrzejewski-Szmek wrote: > As a meta-goal, we should break up "Modularity" into a number of > separate components, some build-side, some client-side. Modularity > suffers greatly from trying to encode everything into one document. > This greatly raises the complexity of the task and makes it hard to > consider alternative proposals for various parts. > > Let's consider them separately: > > 1. what to build against what branches > > You said: > > * each has package.cfg or some alternative which specifies what is the > > EOL and/or for which releases to build > > Right now we use dist-git branches for this. Having a package.cfg > might sound easier , but the caveat is that building against different > branches requires tweaks sometimes. So we immediately hit a choice: do > we want a single branch and the %ifdef mess, or multiple branches and > the cherry picking troubles. Yeah, this is a difficult thing to answer, since there's people in both camps right now happy with either end, and lots in between. > > Right now, big disadvantage of multiple branches is that %changelogs > and Release bumps introduce trivial conflicts. I think we should > explore the proposals (incl. your and Neal's) to make this better. > Fixing this would be good also for normal packaging, because it'd remove > one or two more steps that need to be done every time. +1 > We should explore both directions, i.e. package.conf and easier branches. > > We should experiment with better/easier control of what to build > where. This would benefit normal packaging too. Right now our tooling > is just hard to use, with multiple commands in different tools needed > to start builds, schedule updates, control koji status, etc. We need > changes for "normal" packages as much as for "streams". I wonder if we couldn't explore using tags for this. ie, if you tag a commit in a specific way it tells the system what to build, what to run ci on, etc. ...snip... > > A different proposal: we add a new rpm flag (maybe as a special > Requires: line) that specifies that a package is only supported as a > build-time dependency. DNF could then gain a trivial patch that > it would ask the user "Do you want to install those unsupported packages? > If you do, please do not file bugs, because ...". > The advantages: > a) packages are available for local builds and downstream rebuilds > b) no problem with mock and koji being different > c) we avoid any perception of "welding down the engine hood". > > This would just acknowledge the truth that there are many packages > in Fedora that are not supported beyond an occasional version bump > and rebuild, giving better transparency for the users in general. Well, if we are doing that, couldn't we just not add bugzilla components for them? But perhaps we do want the bugs, even if the package isn't 'maintained' wouldn't it still be good to know about bugs? ...snip... > I think we should allow "rolling" versions more widely, like we do with > firefox, the kernel, spam blockers, and probably some other things. > As long some piece software is most backwards compatible, I think we'd > be better of abandoning the strict guidelines we have now. > This depends on each specific package though. Yes, I think this very much depends on the package. kevin
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
