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.
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.
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
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 :)
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. 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 ?
- KB