On Sun, 12 Jan 2020 at 00:58, Stephen John Smoogen <smooge at gmail.com> wrote: > 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. > > Great, this sounds like the process of building an OS in multiple steps that I am familiar with; Is there any way to make this process more transparant? Letting the community know what step in the process you are at, what is failing, what patches have been tried, and when you are sleeping let people build some packages on top of your work, find out what works and contribute that back to you so in the morning when you wake up the entire process is a few steps further along? I have some experience in building a build system/framework (and community of people contributing patches to this framework in parallel) that methodically keeps track of every package build and what dependencies work and don't work in different stages of the build. We accept input from people who tried builds that failed, figured out the problem and submitted a patch to the build process to us using this framework, in the end we can automatically generate a complete reproducible build with the press of a button, that can be rebuild on the machine of everyone involved. Does this sound like anything you would want to have in the future? Or are you happy with doing the above process behind closed doors with just a few people in control? > > > > -- > Stephen J Smoogen. > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > https://lists.centos.org/mailman/listinfo/centos-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200112/d0b9ab78/attachment-0007.html>