Date: Thu, 20 Apr 2017 21:57:12 +0200 From: Kurt Jaeger <lists@opsec.eu> To: freebsd-ports@freebsd.org Subject: Re: Is pkg quarterly really needed? Message-ID: <20170420195712.GK74780@home.opsec.eu> In-Reply-To: <127a5f89-93ba-aee4-14d3-41e2f2d71892@gjunka.com> References: <58F61A8D.1030309@a1poweruser.com> <CALfReyctL3vTt756oyh1ZTf%2BkgpAOHwp_SUZQCFQiZDccFNMow@mail.gmail.com> <ljhffcphq3bqr8dk2lrlld11ola28b7gqp@4ax.com> <29e44642-e301-f07c-afe3-bad735d8ee5e@freebsd.org> <20170420053722.GD31559@lonesome.com> <b9d24938-5502-cc69-30ed-1941c2517849@gjunka.com> <20170420084452.GH74780@home.opsec.eu> <99a57878-ae39-d2a4-fe35-023dae8b320b@gjunka.com> <20170420171119.GJ74780@home.opsec.eu> <127a5f89-93ba-aee4-14d3-41e2f2d71892@gjunka.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi! > I understand that the main problem with quarterly branches is that they > start from an unstable edge and mature with time, then after three > months at the most mature point they are being deleted and replaced with > a new unstable edge. So, there is no good point of reference to use as a > source of packages. First, let me say that for my use cases, the pkg tree is in consistent state most of the time. We have a set of approx. 2500 pkg's build etc, so roughly 10% of the full repo. We update the ports tree and build the repo every week, just to see if all is fine, and we update and build, if we need a package we do not yet have in our repo. For the thrills, look at our repo at https://repo.nepustil.net Hmm, let's try this thought experiment. For each package, keep the whole repo when it was last build sucessfully (Note: we're not yet discussing whether it runs!) Worst case: We have n ports and n repos. The question is: what would be the average case ? Would that be a sustainable model ? Now, the next question: Even if we have all the repos, would we find *one* repo where *two* packagew we'd like to have are in a consistent (build-!)state ? What about the 250+ that are normally needed for a small server ? Or the 1200+ for a multi-role server (some will say: "nah, don't do it, use container/jails/ whatever virtualisiation"). > What I described is taking the good points (maturing the code through > progressing version upgrades from CURRENT, through STABLE to RELEASE) Now, if we have ports-HEAD, and changes to that (especially fixes and features to the ports infrastructure), it's getting more and more difficult to backport fixes from ports-HEAD to the ports-STABLE versions, because those do not contain dependencies and infrastructure changes. If we backport those, we have to roll forward some other changes. This gets out of hand very quickly. Do we need frequent infrastructure changes ? Yes, because right now we would not be able to build the tree, if we did not change some knobs to cope with the newest craziness that upstreams throw at us. We repeatedly needed relevant infrastructure changes just to keep up with that outside world. I'm still speechless that tz@ got php71 into the tree without so few defects. Or the parallel mysql-variants. We still fail to provide a working maven-mechanism. Or go-dependencies. Think of it, go apps more and more bring their own dependencies, because that is somehow unsolved in the go world. Some folks worked wonders with the multi-arch and cross-build things. I can build ARM pkg repos on my amd64, that is unheard of in most parts of the IT universe 8-} We are almost tracking firefox, even after they added a new language (rust) to their infrastructure. So: If we take the sum of the brain time our maintainers and committers deliver to keep HEAD in a moving (different from a stagnating) state, and try to estimate how much *more* time would be needed to keep additional trees in working conditions, only updating what is needed, under the assumption that infrastructure changes *need* to happen ? What would that additional brain time be ? My inituition tells me that it would probably break the model. Now, if someone wants to *experiment* with that, we already have quite a few people doing that: By setting up our own repo boxes, where we build the trees to our liking. The FreeBSD svn commits are public. So, if someone wants to use it, and select and pick to provide a stable repo, we would all welcome the effort. If it's a sustained effort over some time, clusteradm etc would probably add that repo to the infrastructure. We can even call it the 'caveat'-repo. It's just that asking the team that's barely keeping up to do that *on top*, that will probably not work. [...] > From that short description it should be more or less > obvious if that approach is better/doable when opposed to quarterly > branches? There's a way to find out: Try it. -- pi@opsec.eu +49 171 3101372 3 years to go !
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170420195712.GK74780>