On Mon, Oct 21, 2019, 15:17 Stephen John Smoogen <smo...@gmail.com> wrote:
> On Mon, 21 Oct 2019 at 01:55, Zbigniew Jędrzejewski-Szmek > <zbys...@in.waw.pl> wrote: > > > > On Sun, Oct 20, 2019 at 09:30:52PM -0400, Stephen John Smoogen wrote: > > > If I were to start from scratch on this, I would look at the simplest > > > solution I would want from Boltron. I want to make it so a package > team can > > > make a set of packages in a repository and work out how I can interact > with > > > other repositories. I also want to easily build that package set in > ways to > > > work on different versions of an operating system. > > > > The question is whether this team wants to do the "heavy lifting" > > (which might or might not actually be very heavy), of integrating with > > the rest of the distro. If they don't, then Copr is the answer: it > > provides all the answers, including automatic rebuilds. > > > > The problem is that COPRs do not have any way of communicating with > each other. If I grab from copr-A and it has libfoo-2.3.1-1 and I grab > from copr-B and it has libfoo-2.3.2-2 then I am going to replace > copr-A's packages which may break what I wanted from there. I am > saying that if we look at a way that they can clearly communicate > these problems to the user then we have fixed that. > Why not specify those requirements in RPM Requires? That's what they are for. > Also there needs to be a way to communicate that an upgrade from F32 > to F33 will break a system because copr-B has no F-33 packages. > This already works somewhat, the only change that would be needed is setting skip_if_unavailable = false for COPR repos (I think they're set to true right now). > > If they do, and they invest in following the packaging guidelines and > > and the release cycles and whatever we say makes the package suitable > > for users and other packagers to build on, they get to put the package > > in the distro. > > > > From what I have heard over and over is that it isn't the packaging > guidelines which are a problem.. it is dealing with threads like this > or the continual drama churn we have. Investing in the OS means a lot > of emotional energy which a lot of people have no room for in our > current world. In some ways I see being able to bolt things into Coprs > as an escape from dealing with constant absolutes of 'your wrong!' > which most of our messages devolve to. > > The problem is that our current 20,000 packages is a LOT and most > software needs more than we actually have packaged. That means > continual growth, but our other needs of 'I need this as quickly as > possible', 'I expect you to have fixed all these things', etc are more > than most volunteers can deal with at this size. We end up shutting > down and yelling at each other because deep down we just want the > noise to stop. > Yes, I agree, the current growth of the package set isn't sustainable if we don't also scale up the contributor base. I suspect that there are a few handfuls of packagers who maintain hundreds of packages, while the majority only maintains only a handful of packages. And relying on the "overcommitters" (pun intended) to keep the distro running isn't working so well. Fabio > > > > -- > Stephen J Smoogen. > _______________________________________________ > 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 >
_______________________________________________ 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
