On 12/01/2010 08:29 PM, Karanbir Singh wrote: > On 11/30/2010 02:33 AM, Douglas McClendon wrote: >> "And you can still file such issues against centos-5, its an ongoing >> effort not a open/shut situation. So we can still fix stuff in the next >> version" >> Note my very intentional use of the phrase "good-faith". It's as >> legaleze as I get, but I think that is the heart of it. > > ah ok, what I meant to say was that if someone finds an issue even after > release, we would try and fix that right away. Didnt mean to imply that > we're lax or dont take the initial audit seriously. And that's what I thought you meant, and what I meant as well. Perhaps the illustration of our disagreement, is my belief that upstream legal would indeed be more forgiving of packages 'published' to the development community, as development packages, versus packages published as a product for end users. I.e. that it is not necessary for legal purposes to keep development behind closed doors _as long as a good-faith effort is made_. > >>> http://wiki.centos.org/QaWiki/6/AuditStatus is a brief report I put >>> together yesterday, I will try and get it finished up in a few hours time. >> Looks good, though as with the method of gleaming the progress-meter >> number via the bug system, it is the closed section of that list that I >> would get excited about seeing growing day by day. > > There are a few more additions to the page i need to roll out, will try > and do that in the morning. Ok. What I couldn't understand before (and now), is whether or not a package being on the closed list (which is currently still at 0/XXXX) can be inferred from a state in the bug system. I.e. was a single bug created by default for every package? > >> source control tree somewhere? Or I'm just being stupid and lazy and >> for the majority of cases your srpms are literally renames of binary >> srpms that have no branding to strip even in the specfile because that >> all gets added to the binary rpm during build. > > not at all sure what you mean by 'srpms are literally renames of binary > srpms'. I did read it a few times :) > > Think about this : > > Patches for branding issues need to be done at the srpm payload level, > and not as a patch in the .spec Yeah I could have been clearer. I understand this. My question would be- Suppose package xyz requires 3 text changes to the specfile, 2 images removed from the srpm payload, 2 images added to the srpm payload, and 1 extra patch to source with accompanying specfile application. That set of things is the delta from upstream. Is that set of things stored in source control? Or is the only place it is stored in the srpm that you publish in your repository? As a person with an esoteric interest in forking of distros, I've often considered such systems. I.e. I imagine it might be useful to encode the above in a kind of .dsrpm, i.e. 'delta srpm', which could be applied to an srpm, and then in the best case, when an upstream update comes to that srpm, can be trivially reapplied via some utility, as opposed to a person doing a manual rpm -i .srpm, commands on commandline, rpmbuild -bs ... > >> But even so, I think you weren't seeing that I was talking about going >> beyond auditing, and toward fixing. I.e. someones first pass at a fix >> needs to be visible to a second person to do a second check of it. > > but isnt all that public in the bugs.c.o interface ? We just havent had > too many patches :) Where/how would one submit a candidate package? And continuing what I said above, it seems it would be better to submit some kind of standardized delta instead of a package. Realize I do know how noob those questions sound. And how passive-agressive that sounds. I guess what is missing is the wiki walkthrough description of how brandstripping one example package goes. And you've mentioned I think why you don't want to invest time in such a tutorial, though I suspect you've wasted more time discussing it with me already :) > >> I guess seems odd asking for work from contributors, and giving them >> less 'inside access' than the qa team. I posit that perhaps your > > One of the main things that the QA team needs to work with is > whitelisting for release, the branding stuff. That intself means the qa > team needs to stay small, non public access to early code builds. Right there you draw a conclusion in the second sentence from the first. But I don't follow the reasoning. I would even reach the opposite conclusion, but I do defer to your authority and experience. Also > the QA team are small, perhaps 10 people in all. Which means we find the > main issues quickly and can work on very basic communication means. > >> so all you have in source control is srpms? > > pretty much > >> are many of them 100% unmodified from upstream other than renaming the >> file (if that)? > > renaming what file ? Again, a noob question. (from rhel5server) anaconda-11.1.2.209-1.src.rpm to (centos5) anaconda-11.1.2.209-1.el5.centos.src.rpm i.e. in what percent of these instances, do these two files not contain identical bits? My first presumption would have been 0%, but then I started thinking maybe it was 90%. (obviously anaconda would have brand to strip, or at least I strongly presume so) -dmc