On Sat, Nov 30, 2019 at 9:28 PM Kevin Fenzi <kevin@xxxxxxxxx> wrote: > > 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. IMO we should be building and testing all commits automatically unless maintainer put some comment like "[skip ci]" in the commit message. > ...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? I think we still should create BZ (or have it opt-out and have issues on pagure?) because it is useful to get bugreports about some CVE and whatnot. > ...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 > _______________________________________________ > 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 _______________________________________________ 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
