On Sat, 11 Jan 2020 at 16:57, Gordon Messmer <gordon.messmer at gmail.com> wrote: > > On 1/11/20 1:12 PM, Brian Stinson wrote: > > I think the pattern is different with CentOS Linux though. There isn't really much 'contribution' to be done because the idea is to match what comes from RHEL sources as closely as possible. We don't have individual package maintainers in CentOS because 99% of the time we can get builds through > > > I think the frustrating thing about CentOS is that when users ask why > delays are so long, the maintainers say "producing CentOS is't just a > matter of rebuilding Red Hat sources" and when users ask why there isn't > a process to contribute the maintainers say "we're just rebuilding Red > Hat sources, and we don't need help with that." > I think that the problem is that re-building an OS is a very very complicated problem and everyone doesn't expect it to be. The only way I have found to get a real idea of the amount of work is to actually set up your own build system and go through what is needed to rebuild the OS during the X.0 -> X.4 stage. You can get some set of packages built without problems and then you find that they don't have some feature that was expected. Then you have to work out the reorder of the builds to get that feature in the various tools. Then you figure out that you need to actually build the OS in multiple steps: 1. Take X.Y-1 and rebuild some of the packages from X.Y 2. Rebuild some of X-Y.1+new packages with that. 3. Rebuild X.Y packages with the set 4. Find out that a buildroot package (a package which isn't shipped by Red Hat but used to build the OS) isn't working. Figure out that they used a different version than what you have. 5. Go through that package docs and figure out which version/patch you did or did not need. 6. Rebuild X.Y packages 7. Re order some of the builds (but not all of them) and rebuild a couple more 8. Rebuild more of X.Y 9. Make a compose 10. Find out that the compose fails because X.Y used some new features. 11. Go back to 3 with a couple of other items. After a couple of iterations you get an OS working and the QA people can do installs. There they find that something was wrong in X.Y-1 which causes updates to X.Y to break. Come up with new package fixes for that. Spend each day getting pinged at least 3*Ndays (since X.Y release) times on IRC, personal email and mailing lists by users wanting to know why they can't update to the latest package yet. At times you will try giving out some packages before you have the entire compose, and then find out that email is flooded with broken systems which needed some soft dependency you haven't gotten done yet. Or you might think you got all of them and find out that you had to go back to 3 but someone who put X.Y-beta in production on 4000 servers is spamming every list about how your OS is crap... and lots of people add on to it that they found the software was broken too. [You might get some people who point out that it was not ready and then you get slammed with people saying if it wasn't ready why did you even let anyone get it.] Pretty much everyone I know who has done a rebuild of RHEL or CentOS or the clone of CentOS they found.. ends up finding this is what a release is like. -- Stephen J Smoogen.