I need to start my server in Janurary 2011, so I need to know when it's planned to release CentOS 6 to make decisiion if I use current CentOS 5 or CentOS 6 on this server. Plan you release CentOS 6 to January 2011?
Thank's for your response
Filip Bartmann
Greetings, a couple weeks ago I sent an email to Ralph and he pointed me to
the dev list.
Long story short, I would like to help with the Centos 6 release any way I
can and was told that you are currently working on rebranding. And that this
is the process I needed to follow:
http://wiki.centos.org/QaWiki/6/Round1
I've been reading through the wiki on how to get started but honestly I
don't know where to start and I'm asking for some direction. Is their a dev
repo where I can download the current version of "Centos 6" or do I simply
download RHEL 6 and look through the bug list and try to find more
packages/man pages/etc that need to be rebranded??
Some direction would be great. If I can help out in any way please let me
know. If their are any documents/processes I need to review please let me
know.
I don't have any programming experience but I can do some minor scripting.
I'm familiar with Red Hat/Fedora/Centos and currently Admin a handful of
boxes.
Thanks for the help and direction.
--James
Seems this email didn't go through to the mailinglist, so
I'll resend it now.
regards,
Florian La Roche
----- Forwarded message from Florian La Roche <Florian.LaRoche(a)gmx.net> -----
From: Florian La Roche <Florian.LaRoche(a)gmx.net>
To: "The CentOS developers mailing list." <centos-devel(a)centos.org>
Date: Thu, 2 Dec 2010 10:31:55 +0100
Subject: Re: [CentOS-devel] Reality V/s Fantasy
Hello KB,
> 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
Red Hat distributes the source without restrictions and e.g. kernel.org
is mirroring it out on all its mirror systems, so there is no requirement
to keep the CentOS source hidden due to branding/whitelisting issues AFAIK.
I agree that binaries should maybe be kept until the branding and major
patching items are resolved, but clearly all this is a chicken-egg situation
on how to grow the participation for CentOS, right?
regards,
Florian La Roche
----- End forwarded message -----
Hi Florian,
On 11/26/2010 10:41 AM, Florian La Roche wrote:
> you should make sure to grow the CentOS development to a
> bigger group and make it more stable. AKAIK this is the
> goal of this list and there should be plenty of work to
> distribute and get done.
I am not sure where that came from - there is some level of fantasy that
some of you guys seem to live with. Lets take for example the request
for help with branding and trademark searches in the el6 source base.
Then look at the people who really did anything to help, take the usual
suspects out of the loop, and then see what the number reduces to..
Consider this : the distro was ready to QA in 72 hrs from when upstream
dropped all srpms into the right places. I actually requested the 'usual
suspects'[1] to not get involved with the branding issues, we all have
quite a bit going on and adding onto that at release time usually means
slowing down or dropping other efforts; the intention was to not do
that, and to bring in a larger user base who can help cover issues that
don't need specific centos resources. Also, the QA effort tends to be
exceptionally manic, with things changing on an hourly basis, and some
of us pushing for testing, results quite aggressively.
Besides that, new release, new buildsys, new repo structure and new
process meant that this would be fantastic time for a larger number of
people to get involved, and stay involved. Starting from the root of
what we do, and having a good understanding of context around it, why
its a big deal and appreciate it in specific terms by working on it.
The original email asking for help on this was posted on the 12th Nov.
Its the 26th now. Check https://bugs.centos.org/ to see what level of
participation has been forthcoming.
Lots of people will argue that open source works in a way where people
do what they want to do, so you cant tell them what needs doing - and
they will do what they want, when they want. Its what many imagine is
the 'fun' in the open source way. Fortunately, or unfortunately we dont
have that luxury. What comes down the pipe needs to be addressed,
sometimes its what we want to do - and sometimes its what needs doing
because that's the issue on hand. The process we have in place is mostly
finite, with a specified origin and a specified delivery expectation. We
need to join those dots. And if people don't want to help with that
joining-the-dots effort, they are never going to be a part of the process.
So when people imply that there are lots of potential-contributers who
would want to get involved and help etc : What fantasy world are they
looking at ? I, or one, would like to get in on that action please.
> No fights please, CentOS has such a wonderful source
> base to extend upon...
If we cant get traction to get on with just doing what our primary aim
is, extending the code base looks to be a bit of another fantasy world.
Slightly frustrating ? Absolutely.
- KB
[1]: The usual suspects being the people already doing quite a bit, the
core/dev team, the qa guys, artwork effort. And I am truly grateful for
their support.
hi,
EL6 now includes abrt ( https://fedorahosted.org/abrt/ ), which is setup
to talk with bugzilla.r.c and comes with a plugin that allows details
passed to rhsupport. We dont really want either of those two things to
happen. So we can either :
- Remove abrt completely ( might not be the best overall solution, but
it would surely be the fastest short term target )
- Leave abrt in the distro, but disable chatter abilities with anything
*.r.c; and *.fedoraproject.org ( that leaves functionality partially
intact, but local implementations would need to adopt and go with
whatever they want / need; this solution might not be as nice as the
last option)
- Last option: get a plugin together that can do what's needed to file
at bugs.c.o ( we might need a few more people to get involved with
triage and handling of issues via that route! )
Who wants to take on the task of handling abrt, getting the work done
and driving this issue into CentOS-6 ? Being able to code in python
might not be optional..
- KB
On 11/13/2010 02:17 PM, Karanbir Singh wrote:
> On 11/13/2010 08:25 AM, Farkas Levente wrote:
>>/ - what os, version do you use on build hosts?
/>
> CentOS-5.5
>>/ - which version of mock and ccache do you use?
/
> no ccache, mock-0.6.3
>/ - and what mock config do you use?
/
> nothing interesting in the mock configs.
If there is nothing interesting in the mock configs why not share them.
The config really defines the build environment not the host and not necessarily
the version of mock. It is the default installs + the packages to meet dependancies
and where they come from.
>>/ since it's well known that there are some packages (like bash, nss)
/
? because you have those problems, does not mean everyone else will.
>>/ which can not be build in mock on rhel-6:
/>>/ https://bugzilla.redhat.com/show_bug.cgi?id=613392
/>>/ https://bugzilla.redhat.com/show_bug.cgi?id=609201
/>>/ so it's rather strange that build complete without issues.
/
> Speak to the people who have the problems ? These packages have all
> clearly built not only for fedora, but also for red hat - and going by
> the changelogs, quite a few times.
> - KB
Since I have built all but 36 packages on both 1686 and x86_64 with rpmbuild
I am very interested in resolving the differences in build environments.
Once I too have a stable build environment I would be interested in working on the
rebranding etc. But I would like to be able to test and make sure my changes are
not causing the problems not the Build environment. I am building on RHEL6 + updates.
Hubert