[CentOS-devel] Reality V/s Fantasy
mail-lists at karan.org
Mon Nov 29 12:50:33 UTC 2010
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
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 ?
> 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.
> - 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.
> 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
> 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
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.
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.
> What isn't clear to me is how your deltas from upstream are maintained.
in srpms. Whats so hard to understand about that ?
> 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.
More information about the CentOS-devel