[CentOS-devel] Reality V/s Fantasy

Douglas McClendon dmc.centos at filteredperception.org
Mon Nov 29 21:33:41 EST 2010


On 11/29/2010 06:50 AM, Karanbir Singh wrote:
> On 11/26/2010 08:04 PM, Douglas McClendon wrote:
>> I get this, or its essence.  But I think the visceral accomplishment
>> from seeing the absolute minimal round1 packages becoming visible is
>> vital to motivating people.
>
> Round1 packages are never public visible. They wont be this time either.
>
>> I think an important distinction exists between the work the QA team
>> does to make the packages 'centos quality', versus 'legally
>> publishable'.
>
> humm. no.To be fair you did say you were new to CentOS :)
>
>   >  In other words, I think there should be a wiki page, few
>> paragraphs at least, outlining the requirements for what it takes to
>> convert an upstream srpm, into one that is legally publishable.  And I
>
> what bits are missing from the page already there ?

Just looked at the SanityTests page, which either wasn't on the Round1 
page before, or I was lazy and didn't click through to it.  Looks good.

>
>>     From what I understand, and my knowledge of upstream.  Specifically
>> your/someones comments about how this needn't be a flawless endeavor and
>> that branding fixes can slip and be fixed later without being legally
>> catastrophic (upstream has a reputation in FOSS to maintain, and don't
>> seem remotely inclined to go scorched-earth if centos is clearly making
>> a good-faith effort).
>
> this is about as far away from the truth as can be, so do tell me where
> you saw this or who's comments made you think that it was ok for us to
> release some stuff, in whatever state, and take remedy later - specially
> when it comes to legal and trademark stuff. if you believe that, you are
> about as far away from CentOS as can be.

Ok, to quote you from 5 days ago where my impression stems from-

"
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.





>
>> - not looked at
>> - candiate package ready and blessed by 1 (name here)
>> - candidate package ready and blessed by 2nd (name here)
>> - round1 package blessed by QA/Core and round1 .el.srpm available here
>
> you don't need whitelisted srpms published by centos, you can get them
> directly at ftp.r.c; for the rest,
> 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.

>
>> Which now begs the question, how does 2nd person get to see package if
>> it can't yet be legally published?
>
> You lost me there, whats wrong with the ftp.r.c site ? remember its the
> 'source' that needs auditing, not the binary. Usually we would have had
> a centos-6/beta in the public but in this case upstream put a beta out
> directly.

Here, as below, there is some disconnect, and it is probably me 
completely oblivious to some obvious piece of centos development 
infrastructure.  Your srpm specfiles, for c5, (c6?)- are they in a 
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.

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.


>> Likewise, I think then those first publically available round1 srpms
>> should go through the build system and be publically available in binary
>> form ASAP.  Again, if for no utility reason other than the visceral
>> satisfaction and motivation they give the initial brand-strippers and
>> blessers.
>
> No, that's a serious waste of time and effort. the first set of binaries
> are released to the qa team, and qateam only - once they have cleared it
> out we move to pretty much release.

I guess seems odd asking for work from contributors, and giving them 
less 'inside access' than the qa team.  I posit that perhaps your 
opinion of it being wasted effort, and your opinion that there are 
surprisingly few people who both want to help and then actually help, 
are related.  But I admit I'm probably just wasting your and everyone's 
time with this conversation, and as mentioned I do have ulterior motives 
for having early access to the packages that probably color my logic. 
Though after 2 or 3 weeks RH did finally get me my 30day trial, though I 
still would rather use (and therefore test) your earliest first pass build.

>
> Most people would rather see release in 10 days, rather than a beta for
> 2 weeks, followed by release in a further 10 days. Besides this is a
> onetime effort. from here on all point releases are just rolling builds
> with no beta's etc.
>
>> Also, I think the bar should be set very, very, very low for the
>> brand-stripping on round1 packages.  It should be ok to very sloppily
>> replace strings and images with simple blank images.  The emphasis being
>> on get the round1 package out, and let the much slower QA process for
>> true quality happen after a round1 package is out.
>
> I completely disagree. In our context that sort of a process will just
> not work. If there were 100+ contributors and 24+ qa people, we can
> think of something like that. But for now, it needs to be people who
> know what they are doing and can help in a constructive manner.

I can accept that, it makes sense in the present context.

>
>> What isn't clear to me is how your deltas from upstream are maintained.
>
> in srpms. Whats so hard to understand about that ?

so all you have in source control is srpms?

are many of them 100% unmodified from upstream other than renaming the 
file (if that)?

If these questions are answered by a wiki page, by all means point me to 
where I should have seen the answer if I'd done my homework.


>
>> Thanks, and you seem reasonable here as well.  Maybe I don't know some
>> history on the other thread, but if so, you should realize that other
>> new comers to the community don't know the history, and will perhaps
>> come to the same conclusions I did.
>
> erm, winning popularity contests is way lower on the agenda than doing
> the right thing.

Sometimes the right thing is being less pedantic, and more agreeable and 
constructive.  IMO.  (and I say this feeling personally guilty about 
having in the past, and still falling on I suspect the wrong side this 
fence)

-dmc



More information about the CentOS-devel mailing list