On 01/28/2014 11:10 PM, Johnny Hughes wrote: > On 01/28/2014 08:03 PM, Douglas McClendon wrote: >> On 01/28/2014 05:44 PM, Jim Perrin wrote: >>> >>> On 01/28/2014 03:46 PM, Clint Savage wrote: >>>> * Build or maintain tools to ease rebranding of upstream packages as to >>>> ease adoption by companies who build upon and release software based on >>>> CentOS. >>> This would be useful, but could prove to be a Sisyphean task, given that >>> new packages get added, packages get updated, etc. >> To help others not do the legwork I did >> (from en.wiktionary.org://sisyphean) >> >> "Sisyphus was a Greek mythological figure who was doomed to endlessly >> roll a boulder up a hill in Hades." >> >> lol :) >> >> Note, while I worked as Ascendos lead developer for some time, I'm >> speaking now just as a random individual with a past, and possibly >> future interest in rebuilding EL from source on a standalone system. >> Ideally a single outtermost wrapper script command. And ideally with a >> pair of arguments- a new distro name, and a new distro logo. And then, >> the right Sisyphean task completed by the tireless computer system with >> sufficient automating instructions. >> >> To that end, I'd like to say that I think the 'sisyphean' comment >> doesn't fit my picture of where things are. My perception is that >> historically redhat has had a choice. A choice of making the task of >> rebranding drastically more or less sisyphean. While I haven't been >> paying that close attention the last couple years, the general feeling I >> get, is that they want to have a good reputation, and take the >> non-sisyphean track. Note, there are 2 different levels of rebranding >> here. One level, which I've been talking about, is complying with >> redhat on trademarks. The next level is complying with every last >> trademark holder in the distro. Dealing with this latter is/was perhaps >> my sisyphean task. Because ultimately what I wish to empower, is any >> and every single 10 year old computer wiz, being able to trivially have >> in front of them- every line of source of a massive distro like EL, and >> be able to modify any line of that source in any way they want, and with >> a totally tractable trivial minimal effort (15 minutes of active >> participation tops) be able to kick off a rebuild of their own forked >> distro, that they have full rights to redistribute as freely as they >> please. Getting there may be sisyphean, but I really think it is doable >> and worth doing. >> >> But just dealing with the redhat/centos marks should be IMO a totally >> non-sisyphean a task. Given my estimation of redhat's intent and past >> actions on this are accurate. I.e, there is not so much effort with new >> and churning packages as I think you suggest. I posit that most of the >> trouble was with historical packages before people had really spent much >> time thinking about it. Am I wrong on that? Has the amount of >> Redhat->CentOS mark scrubbing not gone down dramatically v4->5->6->7 ?? >> Is it really a 'sisyphean task' to finally get it down to 0 with all >> marks-in-need-of-scrubbing only in a couple packages (redhat-logos, etc)? >> >>>> * Providing tools to help monitor statuses of builds, repositories, >>>> releases, etc. Whether they be part of the CentOS community or otherwise. >>>> >>>> With these goals in mind, we'd like to formally request an Interoperability >>>> Special Interest Group within the CentOS community. Please let us know how >>>> to further proceed. >>> >>> >>> I like the idea, and the fact that it provides independent validation, >>> but I'm not sure this fits with the idea of a SIG. The reason I say this >>> is because for code in the sig/variant model, it needs to live on >>> git.centos.org so that it could be built/signed by the project, which >>> seems counter to the whole 3rd party validation this would provide. >> I think there is a large area for build tools that are the 'blessed way' >> to build the source from scratch. 'blessed' by centos/redhat (are we >> allowed to utter that name more freely on the list these days?). But >> validated by others easily able to fetch them, audit the code and >> configuration to their hearts desire, and rebuild with or without >> enhancements of their own. Probably much of this already exists, I >> think the spirit of this topic is just committing to the whole of the >> picture. Commitment could come in the form of an ongoing SIG, or policy >> statement promoting the creation of some toolset, ... >> >> $0.02... > > If CentOS exists as a rebuild of the EL codebase and if the rebuilt code > works and is tested by the community ... AND if the same source code can > be used as the basis for the addon variant or repos seamlessly (as is > our goal), then why does someone else need to rebuild the rebuilt code > again under another name? My personal answer is about a 50/50 split between a) ego stripping I simply want to take advantage of open source software in that way. Replacing others marks with my own, but keeping all the same utility of the code. As easily/automated as possible, and helping others to be able to do so trivially as well. b) distrust of others compilers and buildsystems I would basically like an alternative to centos, that comes as 99% source, 1% binary, vs the current 50/50. It won't bother me if it takes a week of initial build time to replicate the binary portion on my home system. I also believe putting a and b together will facilitate a more lubricated competitive open source ecosystem. I mentioned clearly the concept of lowering the bar to forking down to 15 minutes of childsplay. > > The goal of this collaboration is to take the need to have other groups > rebuild the same things over and over again away, and have people layer > the things they want on top of what is already built, only adding the > things that are new on top of the base that already exists. Ok then, if the goal of the collaboration is indeed within the scope you described, and I agree what I described above is beyond that scope, then you have convinced me no SIG or policy change should happen. I hope others are more persuaded by the utility of what I described. Or perhaps Clint and Jim will find other common ground to discuss that I may personally be less interested in. -dmc > > They use the SIGs to bring in the things that need to be added in a > separate git branch, then they spend their time adjusting their code > that lives in parallel to the CentOS base. They then do not need to > spend time redoing the same thing that CentOS is already doing. > > CentOS provides a piece, the SIGs provide other pieces, that together > provide the final compilation for that SIG ... that's the point of this > endeavor. It is the whole point of the public build system for SIGs, etc. > > > > > > > > > > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel >