Hi,
I checked the website http://wiki.centos.org/QaWiki/6/AuditStatus so far only one package was centosified.
So I wonder what are the chances of seeing CentOS6 in 2011. Or perhaps a more realistic date is 2012? (Maybe you are waiting for the release of DNF?)
Micha? Piotrowski wrote:
Hi,
I checked the website http://wiki.centos.org/QaWiki/6/AuditStatus so far only one package was centosified.
So I wonder what are the chances of seeing CentOS6 in 2011. Or perhaps a more realistic date is 2012?
Including sarcasm in a mail sent to the -devel list will surely not help to push the wheel a little bit further ...
(Maybe you are waiting for the release of DNF?)
On Sun, 26 Dec 2010, Michał Piotrowski wrote:
So I wonder what are the chances of seeing CentOS6 in 2011. Or perhaps a more realistic date is 2012? (Maybe you are waiting for the release of DNF?)
The choice always comes down to ship less well vetted content fast; or a full set of which one may be proud, less quickly
My last post here noted that Red Hat ran a four month beta program, AFTER their internal stabilization. My blog post crossing 'planet.centos.org' made it clear that the CentOS team simply are not much driven to respond to 'popular demand' or press pressure, and more motivated to produce a durable product. Before that my post here noted that it was unlikely that few oterh than hard core developers who enjoyed pain would ever be able to do a yum transition from 5 to 6, as 6 is rather radically different 'under the hood' as to SELinux model
When people are inclined to carp about release pace, they might find it more profitable to look through the open wiki page on the release, or the open bugtrackker bugs, and document a solution for an unresolved issue, if they wanted to get a release sooner
... just a wild idea
-- Russ herrold
2010/12/26 R P Herrold herrold@centos.org:
<snip>
... just a wild idea
-- Russ herrold
I would say that is a perfectly reasonable idea.
Alan.
On Sun, 26 Dec 2010 14:38:29 -0500 (EST) R P Herrold herrold@centos.org wrote:
When people are inclined to carp about release pace, they might find it more profitable to look through the open wiki page on the release, or the open bugtrackker bugs, and document a solution for an unresolved issue, if they wanted to get a release sooner
Does anyone have links available for either of those locations? There may be a way to search the mail list archives for that information, but I didn't see a readily available search option on the archive page http://lists.centos.org/pipermail/centos-devel/ or the 'about the list' page. Neither is there any search option on the archives for the generic CentOS list.
2010/12/26 R P Herrold herrold@centos.org:
When people are inclined to carp about release pace, they might find it more profitable to look through the open wiki page on the release, or the open bugtrackker bugs, and document a solution for an unresolved issue, if they wanted to get a release sooner
can you show me one such example? when any outsider's help was accepted?
On Sun, 26 Dec 2010, Farkas Levente wrote:
can you show me one such example? when any outsider's help was accepted?
Certainly, first specific as to you, Levente, and then generally as to the project receiving 'outsider's' help
I _know_ you received a detailed private email from me in my @owlriver.com context, addressing your rebuild problems just last week; they are, so far as I know, when taken with the public comment from an @redhat that they see the problem of PTYs in local mock instances, but not under koji, a complete solution
As to public input (an outsider) in eliding both trade marked content, and non-mandatory branding design concerns, Stephen Smoogen's efforts spearheading the elidement effort (before he went back to Red Hat) are a clear and extended effort by a non-CentOS insider, which greatly improved C5. If it was not publicly recognized at the time, I assure you I noticed. Let me say it again: Thanks, Smooge
Similarly the work of Akemi Yagi particularly on the -plus kernels, and the work on AMD K6-II capable kernels was of a non-insider and is greatly appreciated by me. Thanks, Akemi
later:
From: Michal Piotrowski
My last post here noted that Red Hat ran a four month beta program, AFTER their internal stabilization.
Yeah, but I don't expect from CentOS any stabilization - only rebuild of packages.
Then your expectations of what CentOS provides are naiive and inaccurate
My blog post crossing 'planet.centos.org' made it clear
Sorry, but I did not even realize that such thing as planet.c.o exist. Also I did not realize that you and your blog exist.
This behavior, for want of a more charitable way to characterize it, is simply insulting: to NOT do research, and to NOT read back freely open archive
Folks -- this is not rocket science, in the most part, but just laborious; add a chorus of enough whiners and leeches, and the 'desire to scratch' an itch lessens that much more.
Take: rpm -qlp redhat-logos.whatever.rpm from upstream, and note all files, their forms, and their sizes; every one needs to be replaced, or be decided to be dropped (some side languages). Anaconda-images seems to be gone still, merged into -logos, although is still referred to in Red Hat's trademark guidance page when I checked this last week
For each of those files, write the necessary code to emit replacements bearing CentOS branding and trademarks, in the place of that from the upstream
Rebuild all packages, and file bugs in the CentOS tracker when problems are encountered, and initially don't worry about the art
Solve additional packages needed to make it self-hosting if possible. I've mentioned here before that my lead workstation has something over 1000 local custom packages of the roughly 3000 on it. I'm sorry, but it will be a cold, cold day before I spend my spare time to document something to satisfy idle curiosity of passive onlookers here
Then take another pass, and look at branding art and text, but not restricted trademark usage. The art which remains is (should) not be encumbered; cross check the package license details to be sure. That said, if as a matter of branding, but not trade mark elidement, one feels a need to remove such, note it in the bug tracker, and the wiki page for 6
When replacements are completed, note solutions in the tracker
I am in restricted bandwidth, but from memory, the bug tracker is at: http://bugs.centos.org/ and is a Mantis instance, converted from Bugzilla in the project's past. If there is a true interest in ARBT automated filings, it would be easy enough to resurrect a bugzilla, but it is not clear who would tend it. I've not seen a groundswell for such, and I don't see why we would add doing a task poorly to the project
No doubt someone will chime in with the CentOS wiki 6 candidate link; as I say I am in poor bandwidth, and cannot search it out conveniently
As to searching CentOS specific answers, Google heavily indexes the project, and using a search argument like: site:centos.org project bug tracker will work, and is my usual approach
I omit discussion of package manifest, ldd library, and build environment verifications here. I don't much care for exactitude on my local efforts as they will not become the CentOS 6 fruit, and slight variances which I see will be addressed locally post official CentOS release. Also, I just do not care much about GUI package complete coverage, and so do not spend effort there
Next to install testing, automated install image makeup for anaconda for a 6 remains a problem for my efforts, and that is where I am working presently. I remain convinced that upstream makes a great mistake (perhaps market demand driven, perhaps for other reasons such as getting out of the anaconda tweaking business [a sound goal]) in doing install time repository merging, as it makes the install much more fragile at least in a CentOS like context; perhaps when in an environment with a formal and commercial, SLA backed, error reporting CDN (content distribution network) behind it and a customer facing compensated support team, it makes sense
As I say, I am not convinced install time wire repodata and package retrieval works well for a CentOS model [I note there is a report seemingly with this as well in the testing of the SL alpha]. Performance is poor, the memory footprint is too large, and even in a local network environment, installs 'take too long'. When we add the mirror network redirect model, we are going to see lots of complaints, I think, if we do not take steps to 'nail' an install to a single mirror result set for a complete install
We'll see, but I presently think it should be disabled, and left for a later yum pass. This may cause problems in later point releases, however, as the merged package set of local base, optional local media archive updates, and remote archive updates at a point release may make some features non-directly installable in the future, of the upstream slip-streams in some new group overlays
Please note that I post from a non-@centos.org email address, and these are just my thought
-- Russ herrold
W dniu 26 grudnia 2010 20:38 użytkownik R P Herrold herrold@centos.org napisał:
On Sun, 26 Dec 2010, Michał Piotrowski wrote:
So I wonder what are the chances of seeing CentOS6 in 2011. Or perhaps a more realistic date is 2012? (Maybe you are waiting for the release of DNF?)
The choice always comes down to ship less well vetted content fast; or a full set of which one may be proud, less quickly
My last post here noted that Red Hat ran a four month beta program, AFTER their internal stabilization.
Yeah, but I don't expect from CentOS any stabilization - only rebuild of packages.
My blog post crossing 'planet.centos.org' made it clear
Sorry, but I did not even realize that such thing as planet.c.o exist. Also I did not realize that you and your blog exist.
The only thing that I see is that after a month and half only one package has changed graphics/strings etc. Because I do not see any progress on http://wiki.centos.org/QaWiki/6/AuditStatus I'm wondering if CentOS team wants to release this OS this year, next year or anytime in the near future.
that the CentOS team simply are not much driven to respond to 'popular demand' or press pressure, and more motivated to produce a durable product. Before that my post here noted that it was unlikely that few oterh than hard core developers who enjoyed pain would ever be able to do a yum transition from 5 to 6, as 6 is rather radically different 'under the hood' as to SELinux model
When people are inclined to carp about release pace, they might find it more profitable to look through the open wiki page on the release, or the open bugtrackker bugs, and document a solution for an unresolved issue, if they wanted to get a release sooner
... just a wild idea
-- Russ herrold _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
2010/12/27 Michał Piotrowski mkkp4x4@gmail.com
W dniu 26 grudnia 2010 20:38 użytkownik R P Herrold herrold@centos.org napisał:
On Sun, 26 Dec 2010, Michał Piotrowski wrote:
So I wonder what are the chances of seeing CentOS6 in 2011. Or perhaps a more realistic date is 2012? (Maybe you are waiting for the release of DNF?)
The choice always comes down to ship less well vetted content fast; or a full set of which one may be proud, less quickly
My last post here noted that Red Hat ran a four month beta program, AFTER their internal stabilization.
Yeah, but I don't expect from CentOS any stabilization - only rebuild of packages.
My blog post crossing 'planet.centos.org' made it clear
Sorry, but I did not even realize that such thing as planet.c.o exist. Also I did not realize that you and your blog exist.
The only thing that I see is that after a month and half only one package has changed graphics/strings etc. Because I do not see any progress on http://wiki.centos.org/QaWiki/6/AuditStatus I'm wondering if CentOS team wants to release this OS this year, next year or anytime in the near future.
that the CentOS team simply are not much driven to respond to 'popular demand' or press pressure, and more motivated to produce a durable product. Before that my post here noted that it was unlikely that few oterh than hard core developers who enjoyed pain would ever be able to do a yum transition from 5 to 6, as 6 is rather radically different 'under the hood' as to SELinux model
When people are inclined to carp about release pace, they might find it more profitable to look through the open wiki page on the release, or the open bugtrackker bugs, and document a solution for an unresolved issue, if they wanted to get a release sooner
... just a wild idea
-- Russ herrold _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
-- Best regards, Michal
Sent from my fscking awesome Black Hole Generator _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
i believe ,they will release version 6 within months.
On Mon, Dec 27, 2010 at 11:15:42AM +0800, Max Haann wrote:
i believe ,they will release version 6 within months.
69 lines of crap removed.
Is trimming replies so very difficult for people to do properly? Are you that selfish that you think that wading through all the extra noise should be a cost born by the readers of this list? Especially for a single-line reply?
John
John:
sorry for my mistake. i didnt mean to do that, usually my mail client does that automatically. i have got to sync my reply settings globly.
Max
On Mon, Dec 27, 2010 at 11:31 AM, John R. Dennison jrd@gerdesas.com wrote:
On Mon, Dec 27, 2010 at 11:15:42AM +0800, Max Haann wrote:
i believe ,they will release version 6 within months.
69 lines of crap removed. Is trimming replies so very difficult for people to do properly? Are you that selfish that you think that wading through all the extra noise should be a cost born by the readers of this list? Especially for a single-line reply? John
2010/12/26 R P Herrold herrold@centos.org:
My last post here noted that Red Hat ran a four month beta program, AFTER their internal stabilization. My blog post crossing 'planet.centos.org' made it clear that the CentOS team simply are not much driven to respond to 'popular demand' or press pressure, and more motivated to produce a durable product. Before that my post here noted that it was unlikely that few oterh than hard core developers who enjoyed pain would ever be able to do a yum transition from 5 to 6, as 6 is rather radically different 'under the hood' as to SELinux model
Mind you, CentOS is not building a new OS from scratch. It's a rebuild, so it's reasonable to assume that most of the painful work has already been done.
That said, the subtle and unpredictable pains of SELinux and the trade-offs of simply disabling it and spending your security time on more gaping vulnerabilities, such as Subversion clients storing passwords in clear-text and SSH keys without passphrases, has been the subject of a lot of other threads.
2010/12/26 Michał Piotrowski mkkp4x4@gmail.com
So I wonder what are the chances of seeing CentOS6 in 2011. Or perhaps a more realistic date is 2012? (Maybe you are waiting for the release of DNF?)
You certainly do not have to wait for CentOS. The SRPMS are available from the upstream vendor. Why not start your own rebuild project?
gd
2010/12/27 Garry.Dale garry.dale@gmail.com:
2010/12/26 Michał Piotrowski mkkp4x4@gmail.com
So I wonder what are the chances of seeing CentOS6 in 2011. Or perhaps a more realistic date is 2012? (Maybe you are waiting for the release of DNF?)
You certainly do not have to wait for CentOS. The SRPMS are available from the upstream vendor. Why not start your own rebuild project?
Perhaps because I have better things to do in my life? :)
gd _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On Mon, 27 Dec 2010 20:00:54 +0100, Michał Piotrowski mkkp4x4@gmail.com wrote:
Perhaps because I have better things to do in my life? :)
Then be so kind as to stand aside and let the people actually doing the work do their work.
Hugo.
Do not feed the Troll! (I thought the "troll day" was Friday only...)
Best Regards,
js.
Le 28/12/2010 12:22, Hugo van der Kooij a écrit :
On Mon, 27 Dec 2010 20:00:54 +0100, Micha?? Piotrowski mkkp4x4@gmail.com wrote:
Perhaps because I have better things to do in my life? :)
Then be so kind as to stand aside and let the people actually doing the work do their work.
Hugo.
Micha? Piotrowski wrote: <snip>
You certainly do not have to wait for CentOS. The SRPMS are available from the upstream vendor. Why not start your own rebuild project?
Perhaps because I have better things to do in my life? :)
That's a beautiful and useful answer ... (not joking) so why not considering that CentOS developers (who are not paid for that and still do that on their free time , when they are not busy with their jobs) can also have sometimes priorities ? Can't they be sick/ill ? Can't they spend time with their kids/family during Xmas time ? Sorry but i've never read somewhere on the CentOS website that devteam members are 'slave' from centos users :-) I personally prefer an 'happy' centos contributor/developer who will spend a reasonable time on CentOS on a long run than a dev spending all his time on centos and breaking relationship with his family (don't get me wrong, i've never said that it was the case here either !) and/or having a 'burn out' effect on a short run ...
The real question that people wanting a CentOS 6 release should ask to themselves is : "What have I personally done to help ?" There was a public call to help producing CentOS 6 .. Look at the result : only *one* person (out of the 'usual suspects' to use Karanbir's words) spent one or two hours to reviewed those branding issues bug filed on bugs.centos.org.
What do people from the CentOS devteam have to conclude ? I let you answer yourself ...:-)
On Tue, 2010-12-28 at 10:08 +0100, Fabian Arrotin wrote:
The real question that people wanting a CentOS 6 release should ask to themselves is : "What have I personally done to help ?" There was a public call to help producing CentOS 6 .. Look at the result : only *one* person (out of the 'usual suspects' to use Karanbir's words) spent one or two hours to reviewed those branding issues bug filed on bugs.centos.org.
Who was that to be exact that did that? IE, filed a bug...
John
On 12/27/2010 07:00 PM, Michał Piotrowski wrote:
You certainly do not have to wait for CentOS. The SRPMS are available from the upstream vendor. Why not start your own rebuild project?
Perhaps because I have better things to do in my life? :)
classic. Given that sort of an attitude, I guess the you think the rest of us are just wasting our time ?
- KB
2010/12/26 Michał Piotrowski mkkp4x4@gmail.com:
So I wonder what are the chances of seeing CentOS6 in 2011. Or perhaps a more realistic date is 2012? (Maybe you are waiting for the release of DNF?)
The problem with this kind of question is the closed development process of CentOS.
Even Microsoft's development process (public beta, rc, roadmap, release date) is more open than in CentOS.
A good example of a transparent development process is Scientific Linux.
Best regards,
Morten
On 12/27/10 1:10 PM, Morten P.D. Stevens wrote:
2010/12/26 Michał Piotrowskimkkp4x4@gmail.com:
So I wonder what are the chances of seeing CentOS6 in 2011. Or perhaps a more realistic date is 2012? (Maybe you are waiting for the release of DNF?)
The problem with this kind of question is the closed development process of CentOS.
Even Microsoft's development process (public beta, rc, roadmap, release date) is more open than in CentOS.
A good example of a transparent development process is Scientific Linux.
The price is right - use both if you want. The SL alphas are out now and should be close enough for testing purposes.
On 12/27/2010 09:29 PM, Les Mikesell wrote:
On 12/27/10 1:10 PM, Morten P.D. Stevens wrote:
2010/12/26 Michał Piotrowskimkkp4x4@gmail.com:
So I wonder what are the chances of seeing CentOS6 in 2011. Or perhaps a more realistic date is 2012? (Maybe you are waiting for the release of DNF?)
The problem with this kind of question is the closed development process of CentOS.
Even Microsoft's development process (public beta, rc, roadmap, release date) is more open than in CentOS.
A good example of a transparent development process is Scientific Linux.
The price is right - use both if you want. The SL alphas are out now and should be close enough for testing purposes.
Actually I switched my RHEL6b2 to current SL and it works perfectly so far.
2010/12/27 Manuel Wolfshant wolfy@nobugconsulting.ro:
On 12/27/2010 09:29 PM, Les Mikesell wrote:
On 12/27/10 1:10 PM, Morten P.D. Stevens wrote:
2010/12/26 Michał Piotrowskimkkp4x4@gmail.com:
So I wonder what are the chances of seeing CentOS6 in 2011. Or perhaps a more realistic date is 2012? (Maybe you are waiting for the release of DNF?)
The problem with this kind of question is the closed development process of CentOS.
Even Microsoft's development process (public beta, rc, roadmap, release date) is more open than in CentOS.
A good example of a transparent development process is Scientific Linux.
The price is right - use both if you want. The SL alphas are out now and should be close enough for testing purposes.
Actually I switched my RHEL6b2 to current SL and it works perfectly so far.
Did you go down the package list and do "yum re-install" of all the packages which have identical names in both? It's potentially helpful to avoid confusion about subtly different "foo-release-version.arch.rpm" packages from each repository, which can happen when both repositories publish new releases as increments of a single digit from the previous release.
2010/12/27 Nico Kadel-Garcia nkadel@gmail.com:
2010/12/27 Manuel Wolfshant wolfy@nobugconsulting.ro:
Actually I switched my RHEL6b2 to current SL and it works perfectly so far.
Did you go down the package list and do "yum re-install" of all the packages which have identical names in both? It's potentially helpful to avoid confusion about subtly different "foo-release-version.arch.rpm" packages from each repository, which can happen when both repositories publish new releases as increments of a single digit from the previous release.
I know this is not a SL mailing list ... :-)
SL goes through alphas, betas, RCs before the GA (scheduled for March 2011). The SL developers recommend a fresh install for each test release. For example, during the alpha release, they did a massive rebuild (>200 packages). The version number remained the same, so 'yum update' will not get the rebuilt packages.
Right, this is not a SL mailing list ...
Akemi
The problem with this kind of question is the closed development process of CentOS.
Even Microsoft's development process (public beta, rc, roadmap, release date) is more open than in CentOS.
A good example of a transparent development process is Scientific Linux.
So why is CentOS development so closed? Why users can't have alphas, or betas of this distro and must use some other rebuild as Scientific Linux? If you release this development versions than more people can make tests or can send patches-
Thank's for your answer Filip Bartmann
Am 28.12.10 10:37, schrieb Filip Bartmann:
So why is CentOS development so closed? Why users can't have alphas, or betas of this distro and must use some other rebuild as Scientific Linux?
One of the reasons is the sheer volume. CentOS is in use (wild educated guess here) on a massively larger scale than SL is. Just getting out the isos for an alpha or beta or whatever will take at least a day to two for getting on all mirror servers. If you also want to have the packages, it even might take longer.
Ralph
On 12/31/2010 02:44 PM, Ralph Angenendt wrote:
Am 28.12.10 10:37, schrieb Filip Bartmann:
So why is CentOS development so closed? Why users can't have alphas, or betas of this distro and must use some other rebuild as Scientific Linux?
One of the reasons is the sheer volume. CentOS is in use (wild educated guess here) on a massively larger scale than SL is. Just getting out the isos for an alpha or beta or whatever will take at least a day to two for getting on all mirror servers. If you also want to have the packages, it even might take longer.
Ralph
In case the pressure for people to test CentOS6 pre releases wouldn't be a torrent sufficient?
Just thinking.
Timo
On Fri, 31 Dec 2010, Ralph Angenendt wrote:
Am 28.12.10 10:37, schrieb Filip Bartmann:
So why is CentOS development so closed? Why users can't have alphas, or betas of this distro and must use some other rebuild as Scientific Linux?
One of the reasons is the sheer volume. CentOS is in use (wild educated guess here) on a massively larger scale than SL is. Just getting out the isos for an alpha or beta or whatever will take at least a day to two for getting on all mirror servers. If you also want to have the packages, it even might take longer.
Please explain the logic. Why does the volume imply that CentOS development must be closed? Why does the volume imply that there cannot be alphas or betas? Do Fedora and Debian not also have large volume?
Are there any plans to tackle the human bottleneck issues within the CentOS development process?
It seems to me that the rebranding process did not start during the upstream beta period. If so, was that a conscious decision by the CentOS team?
--- Charlie
Charlie Brady wrote:
Please explain the logic. Why does the volume imply that CentOS development must be closed? Why does the volume imply that there cannot be alphas or betas? Do Fedora and Debian not also have large volume?
Are there any plans to tackle the human bottleneck issues within the CentOS development process?
The invitation to contribute to the CentOS Project (aka those who *build* CentOS) is out there [1].
And CentOS is not "about" being on the cutting edge; it's provided free "to anyone who wishes to use it" [2].
I see no issues.
gd
[1] http://wiki.centos.org/Contribute [2] http://wiki.centos.org/FAQ/General
On Sat, 1 Jan 2011, Garry Dale wrote:
Charlie Brady wrote:
Are there any plans to tackle the human bottleneck issues within the CentOS development process?
I see no issues.
Which makes you a suitable candidate to join the development team :-)
Happy new year !
Hi Charlie.
On 12/31/2010 06:54 PM, Charlie Brady wrote:
Please explain the logic. Why does the volume imply that CentOS development must be closed? Why does the volume imply that there cannot be alphas or betas? Do Fedora and Debian not also have large volume?
The development for CentOS is no more open or closed than anything that can and should be reasonably expected from what the input to the process and the output from the process is. Also think about exactly 'what' the testing could and should entail, how it might run w.r.t timescales and what the feedback loop should be. Feel free to elaborate and quantify that. eg. Having been on the QA team for 'years', how many patches did you send through ?
Are there any plans to tackle the human bottleneck issues within the CentOS development process?
Absolutely, but tackle them by doing the right thing - and finding people who both (a) know what they are doing, (b) understand the CentOS process and (c) are able to bring a certain trust level to the community of users.
It seems to me that the rebranding process did not start during the upstream beta period. If so, was that a conscious decision by the CentOS team?
The aim was to focus people's attention to the upstream beta, better product and that loop etc. We could have started earlier, sure. But now that we have started 2 months back and your own contribution status stays at nil, why are you interested ?
- KB
Hi Karanbir,
2011/1/5 Karanbir Singh mail-lists@karan.org
[...] The development for CentOS is no more open or closed than anything that can and should be reasonably expected from what the input to the process and the output from the process is. Also think about exactly 'what' the testing could and should entail, how it might run w.r.t timescales and what the feedback loop should be. Feel free to elaborate and quantify that. eg. Having been on the QA team for 'years', how many patches did you send through ? [...]
the process could be more open, see SL i.e., but regardless how open the process is, due to the fact that no alpha, beta whatever relaeases are in the wild it is not possible to test the current state, check for errors and report these to some point like a Bugzilla. As far as I understood from the website, this is only possible for QA members, not normal users. The next thing is that I can't start testing CentOS in live environments before the final version is out (which is odd for things like Puppet, Cobbler or so).
Are there any plans to tackle the human bottleneck issues within the CentOS development process?
Absolutely, but tackle them by doing the right thing - and finding people who both (a) know what they are doing, (b) understand the CentOS process and (c) are able to bring a certain trust level to the community of users.
Why not an open approach. I'm pretty sure there are a lot of people outside with a lot of knowledge who are able to support the rebuild of RHEL6 with patches, reports or whatever if there is a simple an fast way to send these information to some point (at least I can do such things but I don't have the time to be a full QA member).
[...] The aim was to focus people's attention to the upstream beta, better product and that loop etc. We could have started earlier, sure. But now that we have started 2 months back and your own contribution status stays at nil, why are you interested ?
How and what should be contributed if the normal user didn't even know what problems remains?
Kind regards, Thomas
Hi,
On 01/05/2011 11:56 AM, Thomas Bendler wrote:
the process could be more open, see SL i.e., but regardless how open the
Couple of things worth clearing up:
CentOS is not SL CentOS and SL target a very different Goal Set ( there is user end overlap, which imho is good )
process is, due to the fact that no alpha, beta whatever relaeases are in the wild it is not possible to test the current state, check for
When we asked around for help from people, the *currnet* state of CentOS was a bunch of srpms that needed to be looked at for content audits. These srpms are widely available. What do you want to do with these sources that would imply to you a beta or an alpha state ? as far as I am concerned those sources represent the final product pretty much.
> Are there any plans to tackle the human bottleneck issues within the > CentOS development process? Absolutely, but tackle them by doing the right thing - and finding people who both (a) know what they are doing, (b) understand the CentOS process and (c) are able to bring a certain trust level to the community of users.Why not an open approach.
Can you quantify what you mean by 'open approach' ( basically, what steps and what gains those steps would bring about )
The aim was to focus people's attention to the upstream beta, better product and that loop etc. We could have started earlier, sure. But now that we have started 2 months back and your own contribution status stays at nil, why are you interested ?How and what should be contributed if the normal user didn't even know what problems remains?
Problems remain where ? in CentOS or RHEL ? It was RHEL6 that had a public beta, for issues that should have been reported against bugzilla.r.c; or am I misunderstanding what you said ?
Don't get me wrong, I am well aware of the fact that there are issues and situations that need looking at and changing. But lets do the right thing rather than just doing something. Going by the popularist current mood of people on this list, I think people just want early access to a codebase they can start using for their own use rather than actually working towards building CentOS-6. Which makes me fear that the only way we are going to get C6 out of the door in the next few weeks is by clamping up, talking to the usual-suspects and just going back to the CentOS-5 process. And to be honest, I don't really think these conversations over the past two months have been wasted; but in the grant scheme of things - getting 6.0 out of the door might be a better target for now - as long as we can somehow agree that we get back to this process engineering immediately after so as to not be in the same situation, come 6.1.
Also, failback to the CentOS-5 process isn't necessarily a bad thing - we know it works :)
- KB
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
thus Karanbir Singh spake:
Hi,
Hi,
I really didn't want to jump into this discussion, but...
On 01/05/2011 11:56 AM, Thomas Bendler wrote:
the process could be more open, see SL i.e., but regardless how open the
Couple of things worth clearing up:
CentOS is not SL CentOS and SL target a very different Goal Set ( there is user end overlap, which imho is good )
process is, due to the fact that no alpha, beta whatever relaeases are in the wild it is not possible to test the current state, check for
When we asked around for help from people, the *currnet* state of CentOS was a bunch of srpms that needed to be looked at for content audits. These srpms are widely available. What do you want to do with these sources that would imply to you a beta or an alpha state ? as far as I am concerned those sources represent the final product pretty much.
I think the OP didn't have the general availability of SRPMs in mind, but rather an open development/building process. To see where the problems and bugs are hidden, and not to re-invent the wheel a thousand times (or, each time a new individual tries to build stuff).
In comparison to other distributions and especially the BSDs (which almost 'define' 'openness' IMHO) CentOS' development process is a black box to the majority of the community, regardless of the use of $searchengine or subscriptions to mailing lists.
Furthermore -- again, I don't want to cause any bad blood here -- I *heard* from people involved or at least informed in the building process that there *are* 'special scripts' (involved in the build process) that are kept secret.
IMHO the problem is not the existence of such scripts (if they exist), but rather the secret even about their (non) existence. A statement like "yes, we have things we don't want to share due to this or that reason but you are welcome to join us in IRC or somewhere else to see how we can get you involved helping CentOS" would be a signal. YMMV.
> Are there any plans to tackle the human bottleneck issues within the > CentOS development process? Absolutely, but tackle them by doing the right thing - and finding people who both (a) know what they are doing, (b) understand the CentOS process and (c) are able to bring a certain trust level to the community of users.Why not an open approach.
Can you quantify what you mean by 'open approach' ( basically, what steps and what gains those steps would bring about )
Just have a look at other projects like FreeBSD, or even OpenBSD. Yes, I think one should use this as a reference. Not the bad or mediocre ones.
The CentOS wiki is a good starting point. But at the moment it's not in the best state, AFAICS. Yes, I know everybody can help here -- but why not attracting people by creating more openness?
The aim was to focus people's attention to the upstream beta, better product and that loop etc. We could have started earlier, sure. But now that we have started 2 months back and your own contribution status stays at nil, why are you interested ?How and what should be contributed if the normal user didn't even know what problems remains?
Problems remain where ? in CentOS or RHEL ? It was RHEL6 that had a public beta, for issues that should have been reported against bugzilla.r.c; or am I misunderstanding what you said ?
As this is a CentOS list, I'm pretty sure that it's about CentOS and especially about the build process (of CentOS 6).
Don't get me wrong, I am well aware of the fact that there are issues and situations that need looking at and changing. But lets do the right thing rather than just doing something. Going by the popularist current mood of people on this list, I think people just want early access to a codebase they can start using for their own use rather than actually working towards building CentOS-6.
What's the problem? Opening the code base (or build process, scripts, etc), so that anyone can 'try it at home' will not hurt the project. Not doing so, however, does hurt.
Its simple maths: Open it, have 9,382 people try it, 43 fixing bugs, 23 reporting back to you. (However, I doubt that in case 43 people applied working patches only 23 would report back -- that really would be a waste of time and energy.) You win 23 developers.
Do not open it, nobody reports back; maybe even worse, people interested in the project get annoyed and more inactive than they wanted to.
Which makes me fear that the only way we are going to get C6 out of the door in the next few weeks is by clamping up, talking to the usual-suspects
By not opening the process the count of those 'usual suspects' will at best remain at the current level.
and just going back to the CentOS-5 process. And to be honest, I don't really think these conversations over the past two months have been wasted; but in the grant scheme of things - getting 6.0 out of the door might be a better target for now - as long as we can somehow agree that we get back to this process engineering immediately after so as to not be in the same situation, come 6.1.
Also, failback to the CentOS-5 process isn't necessarily a bad thing - we know it works :)
- KB
No pun intended,
Timo
On 01/05/2011 01:19 PM, Timo Schoeler wrote:
Furthermore -- again, I don't want to cause any bad blood here -- I *heard* from people involved or at least informed in the building process that there *are* 'special scripts' (involved in the build process) that are kept secret.
erm, where did you hear about this ? Red Hat dont publish their build scripts for the distro - but we very much use the anaconda included scripts for the isos. Is there anything else that you are referring to ? for the buildsystem for rpms, c4/5 are built in a plague-server hosted setup, its patched up in quite a few places but there is nothing 'special' about it. Most of the patching is to handle the odd build distribution process that we have to work with.
The keysign and move to release process is not public, it never will be. Buildsystem services are not public, they never will be. And just to be clear, the 'never will be' is subject to situations, resources and target goals. If you want to send over ~ 90k GBP to setup a homogeneous buildservice - and then offer to pay for a person's full time salary while they work with this system - let me know and we can work something out.
"yes, we have things we don't want to share due to this or that reason but you are welcome to join us in IRC or somewhere else to see how we can get you involved helping CentOS" would be a signal. YMMV.
Can you point me at the place where you saw this ?
Just have a look at other projects like FreeBSD, or even OpenBSD. Yes, I think one should use this as a reference. Not the bad or mediocre ones.
why ? neither of them do anything like centos ?
The CentOS wiki is a good starting point. But at the moment it's not in the best state, AFAICS. Yes, I know everybody can help here -- but why not attracting people by creating more openness?
that's just very abstract and generic stuff. Can we please focus on specifics. eg. you dont want to spend anytime looking at the wiki because you cant see the script used to convert bash-foo.src.rpm into bash-foo.i386.rpm ??? I must be missing something here, otherwise that sounds quite mad. Specially when that script is hosted in a binary ( rpm-build ) included in the distro.
What's the problem? Opening the code base (or build process, scripts, etc), so that anyone can 'try it at home' will not hurt the project. Not doing so, however, does hurt.
Timo, i suggest you look around a bit. The mock ver we use, the scripts everything are already included in the publicly available stuff. I can only guess here that you havent actually made any effort to either look or even understand what it is that CentOS does.
Its simple maths: Open it, have 9,382 people try it, 43 fixing bugs, 23 reporting back to you. (However, I doubt that in case 43 people applied working patches only 23 would report back -- that really would be a waste of time and energy.) You win 23 developers.
erm, I guess you need to go back and look at what CentOS is and what we do. Because that process you just outlined would be a massive waste of everyone's time.
By not opening the process the count of those 'usual suspects' will at best remain at the current level.
I disagree. How do you think the usual suspects got to being the usual suspects ?
- KB
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
thus Karanbir Singh spake:
On 01/05/2011 01:19 PM, Timo Schoeler wrote:
Furthermore -- again, I don't want to cause any bad blood here -- I *heard* from people involved or at least informed in the building process that there *are* 'special scripts' (involved in the build process) that are kept secret.
erm, where did you hear about this ?
Somewhere.
Red Hat dont publish their build scripts for the distro - but we very much use the anaconda included scripts for the isos. Is there anything else that you are referring to ? for the buildsystem for rpms, c4/5 are built in a plague-server hosted setup, its patched up in quite a few places but there is nothing 'special' about it. Most of the patching is to handle the odd build distribution process that we have to work with.
Sure. But it's not open. So when someones wanting to help, he'd have to build the stuff himself, run into problems you (and surely others) ran into ages ago, re-invents the wheel a dozen times, gives up or does not give up and then, maybe in some bright future time, may become a contributor...?
The keysign and move to release process is not public, it never will be.
Details. This stuff is details.
Buildsystem services are not public, they never will be. And just to be clear, the 'never will be' is subject to situations, resources and target goals. If you want to send over ~ 90k GBP to setup a homogeneous buildservice - and then offer to pay for a person's full time salary while they work with this system - let me know and we can work something out.
Let me know what's the difference between sending 90k GBP and setting up a community that's strong (and open :) enough to set up a homogeneius buildservice? I guess there's more than enough people here that would happily donate a build server in their location -- just have a look at the massive amount of mirrors available. Compared to running a mirror, I guess setting up a host that 'donates' CPU cycles/storage/RAM/network to a distributed buildservice would be a minor hassle.
Well, I could and would provide at least one (modern) build host. That said, just as a hint: It'd be much easier for people doing so using an open documentation/howto...
"yes, we have things we don't want to share due to this or that reason but you are welcome to join us in IRC or somewhere else to see how we can get you involved helping CentOS" would be a signal. YMMV.
Can you point me at the place where you saw this ?
That's the problem: Nowhere.
Just have a look at other projects like FreeBSD, or even OpenBSD. Yes, I think one should use this as a reference. Not the bad or mediocre ones.
why ? neither of them do anything like centos ?
No. They do even more. They develop a whole OS, whereas CentOS has the luck of relying on a proven, enterprise-class basis that surely needs lots of hard work to become CentOS; nevertheless, everyone can build his own NetBSD isos just following the guide:
http://www.netbsd.org/docs/guide/en/part-compile.html
The CentOS wiki is a good starting point. But at the moment it's not in the best state, AFAICS. Yes, I know everybody can help here -- but why not attracting people by creating more openness?
that's just very abstract and generic stuff. Can we please focus on specifics. eg. you dont want to spend anytime looking at the wiki because you cant see the script used to convert bash-foo.src.rpm into bash-foo.i386.rpm ???
I never said that. I guess you get bogged down in details. It's about 'the whole process of building a CentOS release'.
I must be missing something here, otherwise that sounds quite mad. Specially when that script is hosted in a binary ( rpm-build ) included in the distro.
I'm aware of that.
What's the problem? Opening the code base (or build process, scripts, etc), so that anyone can 'try it at home' will not hurt the project. Not doing so, however, does hurt.
Timo, i suggest you look around a bit. The mock ver we use, the scripts everything are already included in the publicly available stuff. I can only guess here that you havent actually made any effort to either look or even understand what it is that CentOS does.
Karanbir, I'm pretty sure that I have at least something like an idea what CentOS is. Please re-read my email -- it's about the work actually being done by the developers, it's not about the tools.
Imagine ancient times: Man discovers fire. There's wood in many many places on earth (this is 'the tools'), but fire only in certain (rare) places (this is 'the work being done building CentOS').
Nobody's interested in wood here. That's just plain downloading the SRPMs. The fire is interesting -- what to do to get your CPU cycles burnt finally give birth to an ISO. :)
Its simple maths: Open it, have 9,382 people try it, 43 fixing bugs, 23 reporting back to you. (However, I doubt that in case 43 people applied working patches only 23 would report back -- that really would be a waste of time and energy.) You win 23 developers.
erm, I guess you need to go back and look at what CentOS is and what we do. Because that process you just outlined would be a massive waste of everyone's time.
Yupp, I'll search the interwebz for that 'CentOS' thingie... *sigh
By not opening the process the count of those 'usual suspects' will at best remain at the current level.
I disagree. How do you think the usual suspects got to being the usual suspects ?
By the way they became the 'usual suspects', I guess. But the way may change or might have changed. I don't know.
- KB
Timo
On 01/05/2011 02:19 PM, Timo Schoeler wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Furthermore -- again, I don't want to cause any bad blood here -- I *heard* from people involved or at least informed in the building process that there *are* 'special scripts' (involved in the build process) that are kept secret.
erm, where did you hear about this ?
Somewhere.
you better take your conversation there then.
bye
- KB
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
thus Karanbir Singh spake:
On 01/05/2011 02:19 PM, Timo Schoeler wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Furthermore -- again, I don't want to cause any bad blood here -- I *heard* from people involved or at least informed in the building process that there *are* 'special scripts' (involved in the build process) that are kept secret.
erm, where did you hear about this ?
Somewhere.
you better take your conversation there then.
bye
Karanbir,
I won't say any names here -- that's a question of honor.
And furthermore, I'm a bit confused about your style of discussing things. I had to check the sender of the mail to see I'm not on an OpenBSD mailing list, reading Theo's crap.
So, people want to help *you* (as being the main representor of the CentOS project).
That's the thing. It's very simple.
- KB
Best regards,
Timo
On Wed, Jan 5, 2011 at 14:19, Timo Schoeler timo.schoeler@riscworks.net wrote:
Don't get me wrong, I am well aware of the fact that there are issues and situations that need looking at and changing. But lets do the right thing rather than just doing something. Going by the popularist current mood of people on this list, I think people just want early access to a codebase they can start using for their own use rather than actually working towards building CentOS-6.
What's the problem? Opening the code base (or build process, scripts, etc), so that anyone can 'try it at home' will not hurt the project. Not doing so, however, does hurt.
Its simple maths: Open it, have 9,382 people try it, 43 fixing bugs, 23 reporting back to you. (However, I doubt that in case 43 people applied working patches only 23 would report back -- that really would be a waste of time and energy.) You win 23 developers.
Do not open it, nobody reports back; maybe even worse, people interested in the project get annoyed and more inactive than they wanted to.
i agree with you Timo. that's my problems too. actually we already rebuild rhel-6. i fill about 80% of those bugreport in bugzilla.r.c which is related to rhel-6 rebuild. what's more not just report them but send the bugfix patches or solutions too. so i hope no one like to said that i'm not willing to help. when you wrote Karanbir, that the first round of rebuild run without issue, i even ask you about it. you don't tell anything. that's what we can't call open process. since it's obvious you can't rebuild all packages without issue (rh also confirm most of the bugfix). you don't even response me when i wrote that building rhel-6 on centos-5 host is not advised. we also don't know what's the current state of centos-6? where the centos-6 stay today? what's missing? is there any open source control system for centos patches? where the open not referring to the source control code:-) can anybody review the current patches _before_ the final release of centos-6? can anybody easily browse the patches and can send fixes or should open all src.rpm and copy out from them. can anybody easily browse the build system? can anybody easily browse the build log files like in case of fedora koji very useful when someone like to debug a build or find a problem and even try to fix it. etc...
On 01/05/2011 02:20 PM, Farkas Levente wrote:
i agree with you Timo. that's my problems too. actually we already rebuild rhel-6. i fill about 80% of those bugreport in bugzilla.r.c which is related to rhel-6 rebuild. what's more not just report them but send the bugfix patches or solutions too. so i hope no one like to said that i'm not willing to help.
I am sure that helps
when you wrote Karanbir, that the first round of rebuild run without issue, i even ask you about it. you don't tell anything. that's what we can't call open process. since it's obvious you can't rebuild all packages without issue (rh also confirm most of the bugfix).
I find this very strange, are you saying that the packages cant be built at all ? I am fairly sure things build. What / if they build to the spec and required configs I've not looked at this point.
you don't even response me when i wrote that building rhel-6 on centos-5 host is not advised.
by whom ? and why ?
we also don't know what's the current state of centos-6? where the centos-6 stay today? what's missing?
did you check the audit status ? what / how much of that is done you think ?
is there any open source control system for centos patches? where the open not referring to the source control code:-)
no there isnt, we dont use a vcs for those - we track in srpms, thats been made clear a few dozen times now - I suggest you start reading this list since you are on it.
can anybody review the current patches _before_ the final release of centos-6?
how many patches have you submitted ? what part of the process did you fail at ?
can anybody easily browse the patches and can send fixes or should
sure
open all src.rpm and copy out from them.
all srpms built so far are available on ftp.redhat.com.
can anybody easily browse the build system? can anybody easily browse the build log files like in case of fedora koji very useful when someone like to debug a build or find a problem and even try to fix
the buildsystem isnt public, its not going to be. As I had said a few months back we can work on some process to make some info from the system available publicly - but thats not something we want to look at before c6 is out of the door. There is a fair bit of work needed to make that happen, and I feel spending the open-source time we all have ( remember that none of us do this as a day job ) is better spent working on that target at this time.
Farkas, the point that you seem to prefer to always ignore is that there is a process in place, and we would really like to stick with that. If you want an upstream you can track and work inside, checkout Fedora that might be more to your liking.
- KB
On 01/05/2011 09:42 PM, Karanbir Singh wrote:
you don't even response me when i wrote that building rhel-6 on centos-5 host is not advised.
by whom ? and why ?
i assume you read this list and read my reply too: http://lists.centos.org/pipermail/centos-devel/2010-November/006035.html http://lists.centos.org/pipermail/centos-devel/2010-December/006285.html imho Jakub is the most knowledgeable man in this subject, so i believe him, but may be you know it better. and that's the point. we (and here many people wrote the same) really like to help, but you (since you alone make all decision) do not accept any help. the problem here is not that you don't know about it, the problem is that we don't know anything about: - what are the buildsystem (os, env, scripts etc) - how do you build the rpms and in this case even if someone like to help or can recognize any kind of bug, problem or fault there is no chance for this. the problem here is that you build a buggy centos-6 and nobody even can recognize it. you'd read the cathedral and bazar. nobody tell that "i can do it better" even we believe you are the most knowledgeable among us i'm sure more people can do it better.
is there any open source control system for centos patches? where the open not referring to the source control code:-)
no there isnt, we dont use a vcs for those - we track in srpms, thats been made clear a few dozen times now - I suggest you start reading this list since you are on it.
that's make it easy to track who made what, who modify what and why and made it easy for anyone to help.
can anybody review the current patches _before_ the final release of centos-6?
how many patches have you submitted ? what part of the process did you fail at ?
how can i submit? is there any docs about it? how can i see other patch? ohh yes there are the srpms and i can look into the ~2000 srpm for centos patches...
can anybody easily browse the patches and can send fixes or should
sure
open all src.rpm and copy out from them.
all srpms built so far are available on ftp.redhat.com.
we talk about here centos patches. does the ftp.redhat.com srpms contains the centos patches?
can anybody easily browse the build system? can anybody easily browse the build log files like in case of fedora koji very useful when someone like to debug a build or find a problem and even try to fix
the buildsystem isnt public, its not going to be. As I had said a few months back we can work on some process to make some info from the system available publicly - but thats not something we want to look at before c6 is out of the door. There is a fair bit of work needed to make that happen, and I feel spending the open-source time we all have ( remember that none of us do this as a day job ) is better spent working on that target at this time.
Farkas, the point that you seem to prefer to always ignore is that there is a process in place, and we would really like to stick with that. If you want an upstream you can track and work inside, checkout Fedora that might be more to your liking.
there is a typo above s/we/i/ :-)
open all src.rpm and copy out from them.
all srpms built so far are available on ftp.redhat.com.
can anybody easily browse the build system? can anybody easily browse the build log files like in case of fedora koji very useful when someone like to debug a build or find a problem and even try to fix
the buildsystem isnt public, its not going to be. As I had said a few months back we can work on some process to make some info from the system available publicly - but thats not something we want to look at before c6 is out of the door. There is a fair bit of work needed to make
Hello KB,
could the build logs be made available to look at? That way people with knowledge could look if the builds look sane that you want to include within C6, but still no binary rpms would get out if you (or some unknown CentOS board) want to keep it that way for the release process.
I'd be especially interested to hear how you want to set the perl vendor path within C6. Scientific Linux stays very close to upstream and depends on each upstream rpm on how that is set. Do you change rpms that don't rebuild cleanly or also stay as close as possible on upstream rpms plus also their binary rpms?
that happen, and I feel spending the open-source time we all have ( remember that none of us do this as a day job ) is better spent working on that target at this time.
Farkas, the point that you seem to prefer to always ignore is that there is a process in place, and we would really like to stick with that. If you want an upstream you can track and work inside, checkout Fedora that might be more to your liking.
Are all items besides the branding issues set in stone and finished already?
regards,
Florian La Roche
Hi Florian,
On 01/05/2011 10:18 PM, Florian La Roche wrote:
could the build logs be made available to look at? That way people with
Yes, that can happen. As promised way back in Nov - we should all get together and thrash out how as-much-as-possible can be public with some sort of queue visibility. But at the moment, I feel its important to crack on with the major agenda of getting C6 out of the door.
I'd be especially interested to hear how you want to set the perl vendor path within C6. Scientific Linux stays very close to upstream and depends on each
Well, we try and match what Red Hat puts out ( has been argued in the past that we are more pedantic about that than anyone else around, not sure if that situation has changed recently ).
Are all items besides the branding issues set in stone and finished already?
no, not as yet. The actual distro compile ( iso build / install tree build ) has not happened as yet. Given that we do actually have a fair few people working through the code at this moment, I think its important we give them a few days to get through that. Depending on what the situation is, lets play for a distro build early next week.
- KB
On Wed, Jan 5, 2011 at 7:45 AM, Karanbir Singh mail-lists@karan.org wrote:
Can you quantify what you mean by 'open approach' ( basically, what steps and what gains those steps would bring about )
The aim was to focus people's attention to the upstream beta, better product and that loop etc. We could have started earlier, sure. But now that we have started 2 months back and your own contribution status stays at nil, why are you interested ? How and what should be contributed if the normal user didn't even know what problems remains?
Problems remain where ? in CentOS or RHEL ? It was RHEL6 that had a public beta, for issues that should have been reported against bugzilla.r.c; or am I misunderstanding what you said ?
Don't get me wrong, I am well aware of the fact that there are issues and situations that need looking at and changing. But lets do the right thing rather than just doing something. Going by the popularist current mood of people on this list, I think people just want early access to a codebase they can start using for their own use rather than actually working towards building CentOS-6. Which makes me fear that the only way we are going to get C6 out of the door in the next few weeks is by clamping up, talking to the usual-suspects and just going back to the CentOS-5 process. And to be honest, I don't really think these conversations over the past two months have been wasted; but in the grant scheme of things - getting 6.0 out of the door might be a better target for now - as long as we can somehow agree that we get back to this process engineering immediately after so as to not be in the same situation, come 6.1.
Also, failback to the CentOS-5 process isn't necessarily a bad thing - we know it works :)
As a fairly new subscriber, I've not really found anything technically wrong with the process. Mostly because I have no idea what the process is. From what I can tell, the CentOS developers pick up SRPMS, debrand, "magically" build them somehow, and then publish them when done.
There probably isn't anything wrong at all with that, but since it's not documented anywhere and the buildsystem being used isn't documented either, it's sort of a big black box. So to me, a more "open" process could start with simply documenting the actual process, including the buildsystem and/or build order of the packages. Maybe I've missed this somewhere in the wiki already, but if I have it's because it's hard to find (at least in my looking).
FWIW, I rather liked the call-for-help on debranding, even if it had limited participation. I think it's exactly the kind of task that can be distributed to relative new-comers and might lead to further participation.
josh
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
thus Josh Boyer spake:
On Wed, Jan 5, 2011 at 7:45 AM, Karanbir Singh mail-lists@karan.org wrote:
Can you quantify what you mean by 'open approach' ( basically, what steps and what gains those steps would bring about )
The aim was to focus people's attention to the upstream beta, better product and that loop etc. We could have started earlier, sure. But now that we have started 2 months back and your own contribution status stays at nil, why are you interested ?How and what should be contributed if the normal user didn't even know what problems remains?
Problems remain where ? in CentOS or RHEL ? It was RHEL6 that had a public beta, for issues that should have been reported against bugzilla.r.c; or am I misunderstanding what you said ?
Don't get me wrong, I am well aware of the fact that there are issues and situations that need looking at and changing. But lets do the right thing rather than just doing something. Going by the popularist current mood of people on this list, I think people just want early access to a codebase they can start using for their own use rather than actually working towards building CentOS-6. Which makes me fear that the only way we are going to get C6 out of the door in the next few weeks is by clamping up, talking to the usual-suspects and just going back to the CentOS-5 process. And to be honest, I don't really think these conversations over the past two months have been wasted; but in the grant scheme of things - getting 6.0 out of the door might be a better target for now - as long as we can somehow agree that we get back to this process engineering immediately after so as to not be in the same situation, come 6.1.
Also, failback to the CentOS-5 process isn't necessarily a bad thing - we know it works :)
As a fairly new subscriber, I've not really found anything technically wrong with the process. Mostly because I have no idea what the process is. From what I can tell, the CentOS developers pick up SRPMS, debrand, "magically" build them somehow, and then publish them when done.
There probably isn't anything wrong at all with that, but since it's not documented anywhere and the buildsystem being used isn't documented either, it's sort of a big black box. So to me, a more "open" process could start with simply documenting the actual process, including the buildsystem and/or build order of the packages.
Something like Fedora's koji would be nice:
http://koji.fedoraproject.org/koji/index
Maybe I've missed this somewhere in the wiki already, but if I have it's because it's hard to find (at least in my looking).
FWIW, I rather liked the call-for-help on debranding, even if it had limited participation. I think it's exactly the kind of task that can be distributed to relative new-comers and might lead to further participation.
josh
Timo
Hi Karanbir,
2011/1/5 Karanbir Singh mail-lists@karan.org
[...] Couple of things worth clearing up:
CentOS is not SL CentOS and SL target a very different Goal Set ( there is user end overlap, which imho is good )
I know but the source is equal.
When we asked around for help from people, the *currnet* state of CentOS
was a bunch of srpms that needed to be looked at for content audits. These srpms are widely available. What do you want to do with these sources that would imply to you a beta or an alpha state ? as far as I am concerned those sources represent the final product pretty much.
I'm seeking for two different things, one thing is an alpha or beta ISO (which gives you at least the ability to install a minimal CentOS 6) two check if procedures like Cobbler or Puppet or ... are still functional or if things need to be changed. Using SL6 or RHEL6 didn't help much because facter return different values (i.e. facter operatingsystem gives RedHat instead of CentOS which brake all operating system selectors). The second thing is a built environment that help me to find bugs in the build process and gives me the ability to fix them. It would also be sufficient for me to only have the built environment to create my own ISOs and use them for testing (if there are too many concerns about offering alpha or beta ISO officially).
Can you quantify what you mean by 'open approach' ( basically, what
steps and what gains those steps would bring about )
See above, this is my motivation for having access to earlier releases where not everything is already compiling and working.
[...] Problems remain where ? in CentOS or RHEL ? It was RHEL6 that had a public beta, for issues that should have been reported against bugzilla.r.c; or am I misunderstanding what you said ?
A bit, I mean problems remaining in the current CentOS 6 built process. I would like to help sorting problems out to get CentOS6 as soon as possible, but I don't know what problems are still blocking CentOS 6 from being ready to distribute. I checked the archives of the mailing lists as well as the website but didn't find things in this area. Maybe a link on the CentOS entry page: "Help making CentOS 6 ready to release" would be helpful.
Don't get me wrong, I am well aware of the fact that there are issues
and situations that need looking at and changing. But lets do the right thing rather than just doing something. Going by the popularist current mood of people on this list, I think people just want early access to a codebase they can start using for their own use rather than actually working towards building CentOS-6. Which makes me fear that the only way we are going to get C6 out of the door in the next few weeks is by clamping up, talking to the usual-suspects and just going back to the CentOS-5 process. And to be honest, I don't really think these conversations over the past two months have been wasted; but in the grant scheme of things - getting 6.0 out of the door might be a better target for now - as long as we can somehow agree that we get back to this process engineering immediately after so as to not be in the same situation, come 6.1.
Also, failback to the CentOS-5 process isn't necessarily a bad thing - we know it works :)
I don't get you wrong (hopefully) and I really appreciate the work that is done from the CentOS team, I just want to figure out if there are possibilities to speed up the process to release CentOS 6 by helping with bug reports or patches to have CentOS 6 up in the air soon.
Kind regards, Thomas
Hi Thomas, I seem to have missed your email yesterday.
On 01/05/2011 01:37 PM, Thomas Bendler wrote:
CentOS is not SLI know but the source is equal.
Not really. They do things to the distro that we dont - and we work towards different(ish ?) goals. A bulk of the work is shared and perhaps overlaps, which is why having them do their thing on a different track is good - for us and for them.
I'm seeking for two different things, one thing is an alpha or beta ISO (which gives you at least the ability to install a minimal CentOS 6) two
This is the bit that I dont understand. If there is an ISO set, why would it be Alpha or Beta ? if the iso sets are complete - we release that stuff as gold.
check if procedures like Cobbler or Puppet or ... are still functional or if things need to be changed. Using SL6 or RHEL6 didn't help much because facter return different values (i.e. facter operatingsystem
That is a good point - and something that is worth looking into. But I think you have the stick facing the wrong way. What we could potentially do is isolate what contents in the distro impact these tools and then talk to the project upstreams to make sure we are all in the same boat. However, the focus isnt working with these tools - the idea of these tools working is upto them doing whats needed to work with CentOS. The CentOS focus is and must remain upstream compatible.
Perhaps more thought is needed on how we can make things be more other-project compatible. Or, looking at this from a different angle, help / facilitate other projects be compatible with CentOS.
gives RedHat instead of CentOS which brake all operating system selectors). The second thing is a built environment that help me to find bugs in the build process and gives me the ability to fix them. It would also be
The idea of sekreet-sauce is completely unfounded. And therein lies the issue. Too many people think that we bless the stuff with some holy water from somewhere to magically churn out packages. Its simply not true. At best a rpmbuild -ba <foo.spec>; should give you a usable result, at worst a mock rebuild. As for documenting things - so many people are using bugs.c.o already, why do you find that unsuitable ?
A bit, I mean problems remaining in the current CentOS 6 built process. I would like to help sorting problems out to get CentOS6 as soon as possible, but I don't know what problems are still blocking CentOS 6
....
I don't get you wrong (hopefully) and I really appreciate the work that is done from the CentOS team, I just want to figure out if there are possibilities to speed up the process to release CentOS 6 by helping with bug reports or patches to have CentOS 6 up in the air soon.
havent we already been over this ground repeatedly a few times on the list already ?
- KB
Hi Karanbir,
2011/1/7 Karanbir Singh mail-lists@karan.org
Hi Thomas, I seem to have missed your email yesterday.
no problem, happens to me quite often :).
On 01/05/2011 01:37 PM, Thomas Bendler wrote:
CentOS is not SL I know but the source is equal.
Not really. They do things to the distro that we dont - and we work towards different(ish ?) goals. A bulk of the work is shared and perhaps overlaps, which is why having them do their thing on a different track is good - for us and for them.
What I mean is that both flavors are build out of RHEL sources with more or less work on the original sources.
I'm seeking for two different things, one thing is an alpha or beta ISO (which gives you at least the ability to install a minimal CentOS 6) two
This is the bit that I dont understand. If there is an ISO set, why would it be Alpha or Beta ? if the iso sets are complete - we release that stuff as gold.
That is exactly the point, it's released when it's ready. So looking at the current situation, RHEL6 was released early November, now it's early January and I still can't start with reworking my puppet installation to match CentOS6 (I did it with RHEL6 and SL6, but I need to check it for CentOS as well). So when CentOS6 is released (maybe this month, maybe next month, maybe even later) I can start working on Puppet to get it ready for this release (which may also take a month or so until everything is in production). This means, when CentOS6 is released I have the upgrade work as well as the configuration management work at the same time, I would like to do the configuration work before CentOS6 is released. Simply because when CentOS6 is released and it's in the press that it's released a lot of people stand in front of my desk asking me when they can use the new release because of feature xyz ... :).
[...] However, the focus isnt working with these tools - the idea of these tools working is upto them doing whats needed to work with CentOS. The CentOS focus is and must remain upstream compatible.
Yes, but this is the problem, CentOS identify itself as CentOS. When I check the configuration management with original RHEL6 it identify itself as RedHat. There are some ways working around that issue (i.e. patch facter or changing redhat-release), but I would prefer having something like download the RHEL Source RPMs, integrate CentOS modifications (in a state as it currently is) and have it run with whatever tool to get an ISO image as the result. This also show me if there are still build errors which I can report to bugs.c.o or where I can send a patch to bugs.c.o so that the build team can fix it as well.
[...] The idea of sekreet-sauce is completely unfounded. And therein lies the issue. Too many people think that we bless the stuff with some holy water from somewhere to magically churn out packages. Its simply not true. At best a rpmbuild -ba <foo.spec>; should give you a usable result, at worst a mock rebuild. As for documenting things - so many people are using bugs.c.o already, why do you find that unsuitable ?
It's not an idea, it's how people recognize the current situation. Make a simple test, forget for an hour all things you know about CentOS (will be hard in your case, I know) and go to http://centos.org/. Check out if you find something like build logs, some state how far the process of creating CentOS6 is, what packages still need to be reworked, how someone can help reworking these packages, ... and you will see that these informations are not visible. They might exist but they are not visible for someone going to the web page and try to get these informations. So if there is a link on the front page pointing to a guide how to setup a build environment for CentOS6 locally and how to report issues and patches to bugs.c.o and how you can get build logs of the current rebuild process, everything is fine because anyone can start working on open items and contribute to the project to make things happen faster. To make it clear, I think bugs.c.o is a good thing but useless for anyone who don't have a local build environment.
[...] havent we already been over this ground repeatedly a few times on the list already ?
No, nothing changed till now, the only statement so far was something like this can be discussed when CentOS6 is out. So the problems still exist and the question is, will the problems be really solved when CentOS6 is out? If so, I will shut my mouth and we can follow up with the discussion when CentOS6 is out. If everything stays as it is, I have to rethink if CentOS is the best solution for my needs.
Kind regards, Thomas
On 1/5/2011 6:45 AM, Karanbir Singh wrote:
But lets do the right thing rather than just doing something. Going by the popularist current mood of people on this list, I think people just want early access to a codebase they can start using for their own use...
I thought that was the very definition of an open process...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
thus Les Mikesell spake:
On 1/5/2011 6:45 AM, Karanbir Singh wrote:
But lets do the right thing rather than just doing something. Going by the popularist current mood of people on this list, I think people just want early access to a codebase they can start using for their own use...
I thought that was the very definition of an open process...
What came to my mind on my way home from the office: Maybe Karanbir has a different definition of 'community' (wasn't that what the 'C' in 'CentOS' was for?) in mind...?
Timo
On 1/5/2011 9:34 AM, Timo Schoeler wrote:
thus Les Mikesell spake:
On 1/5/2011 6:45 AM, Karanbir Singh wrote:
But lets do the right thing rather than just doing something. Going by the popularist current mood of people on this list, I think people just want early access to a codebase they can start using for their own use...
I thought that was the very definition of an open process...
What came to my mind on my way home from the office: Maybe Karanbir has a different definition of 'community' (wasn't that what the 'C' in 'CentOS' was for?) in mind...?
I do understand the conflict, just pointing out the other side. The goal for Centos isn't so much to build a 'better' distro by accumulating fixes that make it better for particular purposes as it is to build as nearly exact a copy of RHEL as legally permitted. But community involvement happens because people need to fix something for their own use.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
thus Les Mikesell spake:
On 1/5/2011 9:34 AM, Timo Schoeler wrote:
thus Les Mikesell spake:
On 1/5/2011 6:45 AM, Karanbir Singh wrote:
But lets do the right thing rather than just doing something. Going by the popularist current mood of people on this list, I think people just want early access to a codebase they can start using for their own use...
I thought that was the very definition of an open process...
What came to my mind on my way home from the office: Maybe Karanbir has a different definition of 'community' (wasn't that what the 'C' in 'CentOS' was for?) in mind...?
I do understand the conflict, just pointing out the other side. The goal for Centos isn't so much to build a 'better' distro by accumulating fixes that make it better for particular purposes as it is to build as nearly exact a copy of RHEL as legally permitted.
Sure, this is what I understand. However, does this exclude people willing to help (read: raising the manpower of the project rebuilding RHEL)? If so, yes, I misunderstood.
But community involvement happens because people need to fix something for their own use.
So, the mirrors exist because nobody fixes things? ;)
Timo
On 1/5/2011 10:03 AM, Timo Schoeler wrote:
But community involvement happens because people need to fix something for their own use.
So, the mirrors exist because nobody fixes things? ;)
No, that's a case of fixing something - bandwidth. And it probably wouldn't be done if the contributor couldn't use it themselves or it didn't improve their own use.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Les Mikesell wrote:
On 1/5/2011 10:03 AM, Timo Schoeler wrote:
But community involvement happens because people need to fix something for their own use.
So, the mirrors exist because nobody fixes things? ;)
No, that's a case of fixing something - bandwidth.
True.
And it probably wouldn't be done if the contributor couldn't use it themselves or it didn't improve their own use.
So, this is exactly what CentOS itself is and does: They use it themselves, it improves their experience of computing. So they're willing to help.
Timo
On 01/05/2011 04:03 PM, Timo Schoeler wrote:
Sure, this is what I understand. However, does this exclude people willing to help (read: raising the manpower of the project rebuilding RHEL)? If so, yes, I misunderstood.
Thats bonkers. There *was* a specific callout for help, how many patches did you submit ?
- KB
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
thus Karanbir Singh spake:
On 01/05/2011 04:03 PM, Timo Schoeler wrote:
Sure, this is what I understand. However, does this exclude people willing to help (read: raising the manpower of the project rebuilding RHEL)? If so, yes, I misunderstood.
Thats bonkers. There *was* a specific callout for help, how many patches did you submit ?
I have three here, that are waiting to be submitted. They are not artwork/logo related, it was a bit more work. However, they won't be submitted.
I'm not going to contribute to this 'cult', where there's a whole univserse rotating around exact one single person that has weird definitions (e.g. of 'community') and a massive lack of soft skills. In case I feel the need to do take part in a cult, I could spend (less than 90k GBP) buying Apple stuff and become a Jobs fanboi or keep my money and become a de Raadt fanboi.
Nothing like this is ever going to happen.
@ the wiki guys: Could somebody please delete my user page
http://wiki.centos.org/TimoSchoeler
Thanks.
Timo
- KB
On Thu, Jan 6, 2011 at 3:48 AM, Timo Schoeler timo.schoeler@riscworks.net wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
thus Karanbir Singh spake:
On 01/05/2011 04:03 PM, Timo Schoeler wrote:
Sure, this is what I understand. However, does this exclude people willing to help (read: raising the manpower of the project rebuilding RHEL)? If so, yes, I misunderstood.
Thats bonkers. There *was* a specific callout for help, how many patches did you submit ?
I have three here, that are waiting to be submitted. They are not artwork/logo related, it was a bit more work. However, they won't be submitted.
Well, I might like to see them. Please submit them anyway: I submit patches to RHEL and CentOS at the same time sometimes.
Good patches are valuable even if they're published in a socially awkwrd mailing list or wiki.
Dne 6.1.2011 14:03, Nico Kadel-Garcia napsal(a):
I have three here, that are waiting to be submitted. They are not artwork/logo related, it was a bit more work. However, they won't be submitted.
Well, I might like to see them. Please submit them anyway: I submit patches to RHEL and CentOS at the same time sometimes.
Good patches are valuable even if they're published in a socially awkwrd mailing list or wiki.
Yes, I second that. There is a lot of rebuild "groups" which might find it very interesting. DH
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
thus David Hrbáč spake:
Dne 6.1.2011 14:03, Nico Kadel-Garcia napsal(a):
I have three here, that are waiting to be submitted. They are not artwork/logo related, it was a bit more work. However, they won't be submitted.
Well, I might like to see them. Please submit them anyway: I submit patches to RHEL and CentOS at the same time sometimes.
Good patches are valuable even if they're published in a socially awkwrd mailing list or wiki.
Yes, I second that. There is a lot of rebuild "groups" which might find it very interesting.
Hi,
I'm sorry, but I have to iterate that I'm *not* going to publish the patches. They'd be used by a non-open project, and I don't want that, at least not at the moment.
However, I would be willing to contribute them to a really open project.
Interested people in creating a similar project (also a clone of RHEL), but really *open*, are welcome to PM me for further information of what already happened on this topic.
DH
Best regards,
Timo
Hi,
On 01/06/2011 02:42 PM, Timo Schoeler wrote:
However, I would be willing to contribute them to a really open project.
So these are non branding related patches, with functional changes. Given that you have been around in the centos community for a while now, I am sure you would already know that these would be unsuitable for the centos distro process. For the Plus/ repo - perhaps, but you have never shown any interest there nor brought up any proposal to manage packages there.
Anyway, all the best.
- KB
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
thus Karanbir Singh spake:
Hi,
On 01/06/2011 02:42 PM, Timo Schoeler wrote:
However, I would be willing to contribute them to a really open project.
So these are non branding related patches, with functional changes. Given that you have been around in the centos community for a while now, I am sure you would already know that these would be unsuitable for the centos distro process. For the Plus/ repo - perhaps, but you have never shown any interest there nor brought up any proposal to manage packages there.
Any interest was poisoned. It's as simple as that.
Anyway, all the best.
- KB
Best regards,
Timo
On 6 January 2011 08:48, Timo Schoeler timo.schoeler@riscworks.net wrote:
@ the wiki guys: Could somebody please delete my user page
Timo,
Your request has been actioned.
Regards & best wishes, Alan.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
thus Alan Bartlett spake:
On 6 January 2011 08:48, Timo Schoeler timo.schoeler@riscworks.net wrote:
@ the wiki guys: Could somebody please delete my user page
Hi Alan,
Timo,
Your request has been actioned.
thank you very much.
Regards & best wishes, Alan.
Best regards,
Timo
2011/1/5 Les Mikesell lesmikesell@gmail.com
[...] I do understand the conflict, just pointing out the other side. The goal for Centos isn't so much to build a 'better' distro by accumulating fixes that make it better for particular purposes as it is to build as nearly exact a copy of RHEL as legally permitted. But community involvement happens because people need to fix something for their own use.
It's not that much fixing to make a better distribution, to do this kind of work an own repository is in 99% sufficient. It's more a question of how can people help to make an earlier CentOS 6 release date happen. But this means somehow access to the current build process or at least access to the logs to see what packages still make problems for what reason. Otherwise help from other people is impossible ...
Kind regards, Thomas
On 01/05/2011 04:57 PM, Les Mikesell wrote:
On 1/5/2011 9:34 AM, Timo Schoeler wrote:
thus Les Mikesell spake:
On 1/5/2011 6:45 AM, Karanbir Singh wrote:
But lets do the right thing rather than just doing something. Going by the popularist current mood of people on this list, I think people just want early access to a codebase they can start using for their own use...
I thought that was the very definition of an open process...
What came to my mind on my way home from the office: Maybe Karanbir has a different definition of 'community' (wasn't that what the 'C' in 'CentOS' was for?) in mind...?
I do understand the conflict, just pointing out the other side. The goal for Centos isn't so much to build a 'better' distro by accumulating fixes that make it better for particular purposes as it is to build as nearly exact a copy of RHEL as legally permitted. But community involvement happens because people need to fix something for their own use.
no. if centos would be so simple rhel rebuild then centos-6 could be released 3 days after rhel-6. there are many different things that should have to be done. and currently everything depend on one single man. that's the main reason why it's takes many months.
On 1/5/2011 1:04 PM, Farkas Levente wrote:
On 1/5/2011 6:45 AM, Karanbir Singh wrote:
But lets do the right thing rather than just doing something. Going by the popularist current mood of people on this list, I think people just want early access to a codebase they can start using for their own use...
I thought that was the very definition of an open process...
What came to my mind on my way home from the office: Maybe Karanbir has a different definition of 'community' (wasn't that what the 'C' in 'CentOS' was for?) in mind...?
I do understand the conflict, just pointing out the other side. The goal for Centos isn't so much to build a 'better' distro by accumulating fixes that make it better for particular purposes as it is to build as nearly exact a copy of RHEL as legally permitted. But community involvement happens because people need to fix something for their own use.
no. if centos would be so simple rhel rebuild then centos-6 could be released 3 days after rhel-6. there are many different things that should have to be done. and currently everything depend on one single man. that's the main reason why it's takes many months.
But the changes to make it legally permitted are what they've said they would accept help on. Without any real guidance on what that means or how to verify correctness.
On Wed, Jan 5, 2011 at 1:04 PM, Farkas Levente lfarkas@lfarkas.org wrote:
<snip> ...and currently everything depend on one single man. that's the main reason why it's takes many months.
Is it possilble to declare this thread officially ridiculous? And shut it down?
gd
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Garry.Dale wrote:
On Wed, Jan 5, 2011 at 1:04 PM, Farkas Levente lfarkas@lfarkas.org wrote:
<snip> ...and currently everything depend on one single man. that's the main reason why it's takes many months.
Is it possilble to declare this thread officially ridiculous? And shut it down?
gd
Why is it ridiculous? Different people asked what facts there might be against opening the development process of CentOS, and mainly those questions where based on the fact that people wanted to *help*. That was their intention.
It was not whining about "when is bla available" etc, like the usual stuff. So, basically, it was a bunch of *valid* questions.
However, all that was replied was "it's never gonna happen" (to be more open) -- why not? -- and "give me 90k GBP and all will be fine" -- what for, salary? Why not purchasing a RHEL license, then?
This was inadequate pseudo answers.
This sounds more like a discussion of a sect or cult than a mailing list of 'the *C*ommunity *ENT*erprise OS. Sorry, but that's more than evident, see the list archive if needed.
Timo
The thread has become acrid and non-productive. Maybe start the thread again, only this time without a subject line that implies incompetence and laziness.
On Wed, Jan 5, 2011 at 2:26 PM, Timo Schoeler timo.schoeler@riscworks.netwrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Garry.Dale wrote:
On Wed, Jan 5, 2011 at 1:04 PM, Farkas Levente lfarkas@lfarkas.org
wrote:
<snip> ...and currently everything depend on one single man. that's the main reason why it's takes many months.
Is it possilble to declare this thread officially ridiculous? And shut
it
down?
gd
Why is it ridiculous? Different people asked what facts there might be against opening the development process of CentOS, and mainly those questions where based on the fact that people wanted to *help*. That was their intention.
It was not whining about "when is bla available" etc, like the usual stuff. So, basically, it was a bunch of *valid* questions.
However, all that was replied was "it's never gonna happen" (to be more open) -- why not? -- and "give me 90k GBP and all will be fine" -- what for, salary? Why not purchasing a RHEL license, then?
This was inadequate pseudo answers.
This sounds more like a discussion of a sect or cult than a mailing list of 'the *C*ommunity *ENT*erprise OS. Sorry, but that's more than evident, see the list archive if needed.
Timo
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with CentOS - http://enigmail.mozdev.org/
iD8DBQFNJMXwO/2mgkVVV7kRAgJzAJ0YboC6ThJFoZb2CmwJYHNh0PA6kgCfUVMe l1q8srI1jpeCbyjsKjjXOqo= =EBi6 -----END PGP SIGNATURE----- _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
What qualifications does it take to help? In my case, I have been a linux contributer in various ways since 1992. I am a retired Computer Engineer. I have a working RHEL-6 build cluster. Personally, I do not believe in modifying code/specs etc. unless I can personally perform a build to verify correctness. I can consistently provide 10hrs per week and on occasion up to 60Hr. I did not step up during the initial request since I did not have my build cluster performing to my satisfaction. Other conflicts also prevented me from committing to a scheduled amount of time.
If you think I can help, please let me know how.
Hubert Bahr
On 01/05/2011 08:32 PM, Hubert Bahr wrote:
What qualifications does it take to help?
Mostly just common sense and a good understanding about CentOS and how things work. If you have tracked a few releases like 5.4 / 5.5, and know how things fall into place and where - thats about all the qualification one *needs*. But you will be more productive with rpm knowledge.
If you think I can help, please let me know how.
I am sure you can - there are a fair few request for patchs' in the bugs.c.o interface, those pkgs are going to need patches :) I am going to start from one end, if you want to pickup any specific ones, feel free to do so. Also the code / branding audit isnt really quite done as yet. So thats another option to start with
- KB
Karanbir Singh wrote:
I am sure you can - there are a fair few request for patchs' in the bugs.c.o interface, those pkgs are going to need patches :) I am going to start from one end, if you want to pickup any specific ones, feel free to do so.
I assume you are referring to bugs.centos.org. I have created an account there and set my preferences to centos 6 and I see 47 entries with status entries of confirmed, feedback, acknowledge, new, assigned. I assume assigned are indeed that and don't need to be looked at. I guess the most of rest still need patches. I assume these are patches against the redhat source rpms. How do you want them submitted? I also assume severity "block" are first priority. Which end are you starting from. I assume numerical bug ID# tracker order. In building from Red Hat sources we also needed to patch several specs plus a couple of source files. Frakus submitted them upstream but they have not migrated through their process. Do you want those submitted? I think this is the area I prefer to work. I guess I will start at the high end and work backwards.
Also the code / branding audit isnt really quite done as yet. So thats another option to start with
- KB
Hubert
__ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On Wed, 2011-01-05 at 17:52 -0600, Hubert Bahr wrote:
How do you want them submitted?
Make sure the "patch" will actually apply to the RH 6 SRPM. Folder/Bog level is my way of doing so with "diff -uNr f1 f2". If there is something wrong or your not sure ask an some fine sole will send you the right way, Last make sure they rebuild before submitting the patch.
John
I second that notion.
On Wed, Jan 5, 2011 at 2:18 PM, Garry.Dale garry.dale@gmail.com wrote:
On Wed, Jan 5, 2011 at 1:04 PM, Farkas Levente lfarkas@lfarkas.orgwrote:
<snip> ...and currently everything depend on one single
man. that's the main reason why it's takes many months.
Is it possilble to declare this thread officially ridiculous? And shut it down?
gd
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 01/05/2011 07:04 PM, Farkas Levente wrote:
no. if centos would be so simple rhel rebuild then centos-6 could be released 3 days after rhel-6. there are many different things that
funny... given it takes 6 days just to get the mirror's seeded once the move-to-release takes place.
- KB
On 01/05/2011 03:34 PM, Timo Schoeler wrote:
What came to my mind on my way home from the office: Maybe Karanbir has a different definition of 'community' (wasn't that what the 'C' in 'CentOS' was for?) in mind...?
wow, that is so stupid.
What do you think you are doing here on this list ? what do you think is your association with CentOS ? do you use it ? if so, you are a part of the community already. None ever said it was BUILT by a bunch of random driveby community members. Its built for a community and around a community.
Timo, I suggest you take a step back - the idea and process of CentOS clearly eludes you. Its worth getting in touch with those, specially if you want to be constructively contributing.
I'm starting to think that asking for specific help and actually wanting to work with a faster and broader process for CentOS-6 might have been a mistake to start with. Perhaps we should have just gone ahead, used the c5 process and gotten c6 done.
- KB
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
thus Karanbir Singh spake:
On 01/05/2011 03:34 PM, Timo Schoeler wrote:
What came to my mind on my way home from the office: Maybe Karanbir has a different definition of 'community' (wasn't that what the 'C' in 'CentOS' was for?) in mind...?
wow, that is so stupid.
Karanbir, your soft skills are just phantastic! That's what I call 'art of debating things'. I hope you can see the irony in these lines.
What do you think you are doing here on this list ? what do you think is your association with CentOS ?
In the past I was hoping to 'help', as I started a decade ago on NetBSD, especially the macppc port.
do you use it ?
No, I just sit here and stare at hundreds of hosts running CentOS. I don't use it.
if so, you are a part of the community already.
You definition of 'community' is rather interesting. I found that even what wikipedia quotes is more realistic:
"(...) In human communities, intent, belief, resources, preferences, needs, risks, and a number of other conditions may be present and common, affecting the identity of the participants and their degree of cohesiveness. (...)"
So, from your point of view, you use water (as you drink it). Welcome to the water community. That's hilarious.
None ever said it was BUILT by a bunch of random driveby community members. Its built for a community and around a community.
Timo, I suggest you take a step back - the idea and process of CentOS clearly eludes you. Its worth getting in touch with those, specially if you want to be constructively contributing.
Karanbir, you still didn't get the point.
People were asking about the very principle of development of open source software.
Waste of time, that is.
I'm starting to think that asking for specific help and actually wanting to work with a faster and broader process for CentOS-6 might have been a mistake to start with. Perhaps we should have just gone ahead, used the c5 process and gotten c6 done.
- KB
Hello,
Just a question:
If the problem is about lack of openness in Centos project, why don't "fork" it? ok, Centos is already a "fork" of RHEL
(Yes, it is), Scientific linux too (with some special packages for lab etc...):
A fork is simple to do and maybe the community behind will be more open, more reactive ?
Just a question ... not a troll (we are not Friday :)
Best regards,
js
-----Message initial----- À:The CentOS developers mailing list. centos-devel@centos.org; De:Timo Schoeler timo.schoeler@riscworks.net Envoyé:jeu. 06-01-2011 12:40 Sujet:Re: [CentOS-devel] are there any chances to see finished CentOS6 in2011? -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
thus Karanbir Singh spake:
On 01/05/2011 03:34 PM, Timo Schoeler wrote:
What came to my mind on my way home from the office: Maybe Karanbir has a different definition of 'community' (wasn't that what the 'C' in 'CentOS' was for?) in mind...?
wow, that is so stupid.
Karanbir, your soft skills are just phantastic! That's what I call 'art of debating things'. I hope you can see the irony in these lines.
What do you think you are doing here on this list ? what do you think is your association with CentOS ?
In the past I was hoping to 'help', as I started a decade ago on NetBSD, especially the macppc port.
do you use it ?
No, I just sit here and stare at hundreds of hosts running CentOS. I don't use it.
if so, you are a part of the community already.
You definition of 'community' is rather interesting. I found that even what wikipedia quotes is more realistic:
"(...) In human communities, intent, belief, resources, preferences, needs, risks, and a number of other conditions may be present and common, affecting the identity of the participants and their degree of cohesiveness. (...)"
So, from your point of view, you use water (as you drink it). Welcome to the water community. That's hilarious.
None ever said it was BUILT by a bunch of random driveby community members. Its built for a community and around a community.
Timo, I suggest you take a step back - the idea and process of CentOS clearly eludes you. Its worth getting in touch with those, specially if you want to be constructively contributing.
Karanbir, you still didn't get the point.
People were asking about the very principle of development of open source software.
Waste of time, that is.
I'm starting to think that asking for specific help and actually wanting to work with a faster and broader process for CentOS-6 might have been a mistake to start with. Perhaps we should have just gone ahead, used the c5 process and gotten c6 done.
- KB
_______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
thus jean-sebastien Hubert spake:
Hello,
Just a question:
If the problem is about lack of openness in Centos project, why don't "fork" it? ok, Centos is already a "fork" of RHEL
(Yes, it is), Scientific linux too (with some special packages for lab etc...):
A fork is simple to do and maybe the community behind will be more open, more reactive ?
Just a question ... not a troll (we are not Friday :)
Honestly, I was thinking about it, but my levels of misanthropy raised to high during the thread consisting of people not really reading the other people's emails and not willing to understand their point of view.
In case people decide to fork (forking from CentOS is pointless; it'd had to be a fork from RHEL, as you said above, but 'done right'), please PM me. Resources shouldn't be the problem (speaking of servers, housing them, etc).
Best,
Timo
Best regards,
js
On Thu, Jan 06, 2011 at 09:55:23AM +0100, Timo Schoeler wrote:
In case people decide to fork (forking from CentOS is pointless; it'd had to be a fork from RHEL, as you said above, but 'done right'), please PM me. Resources shouldn't be the problem (speaking of servers, housing them, etc).
You do realize that there are many respins of CentOS, some of which are commercial products? In that light forking directly from CentOS isn't "pointless" as others are doing so successfully. I do agree that working directly from upstream source streams offers many more benefits.
And do you realize that there are quite a few people already working on their own repackaging and re-branding projects? This thread has identified some of these people. If you were wanted to contribute to one (or more) of the on-going projects it might be more effective than starting from scratch.
As far as infrastructure goes... I'm not privy to any more information than any other project outsider, but just poking around and you can get a relative feel for the size and scope of the CentOS project's infrastructure. While a new fork/respin wouldn't require the resources that a firmly established project like CentOS requires, the undertaking still isn't trivial; if the new project grows to any size the infra requirements jump up quickly.
If you do take this route, please keep us informed as to your progress and I wish you good luck in your endeavor.
John
On Wednesday, January 05, 2011 05:31:48 am Karanbir Singh wrote:
Absolutely, but tackle them by doing the right thing - and finding people who both (a) know what they are doing, (b) understand the CentOS process and (c) are able to bring a certain trust level to the community of users.
Good morning, Karanbir.
I've watched this thread, but kept my mouth shut since like many I just don't have time to help like I would like to; and I'm not going to criticise the development or the development process if I'm not able to help, obviously. I'm just thrilled and thankful you guys are doing this, and doing great work doing it.
I would, however, add an item to your list, having said that: (d) have sufficient and reliable time availability to help. Although that is somewhat implied by your item (c) above, I believe anyone that plans to really get their hands dirty and help out needs a realistic expectation of the time commitment that is involved (when I maintained the PostgreSQL RPMs, I found that, even with just one package set to maintain, the time commitment was substantial, and was mostly spent doing user support....).
Just my twopence.
On Jan 5, 2011, at 10:23 AM, Lamar Owen wrote:
Good morning, Karanbir.
I've watched this thread, but kept my mouth shut since like many I just don't have time to help like I would like to; and I'm not going to criticise the development or the development process if I'm not able to help, obviously. I'm just thrilled and thankful you guys are doing this, and doing great work doing it.
+1
Karanbir, I've been using CentOS for years and have always been pleased with the product and the process. I've heard you speak on various podcasts about CentOS' development processes and project ethos so I fully understand your goals and reasoning. When I have a project that falls those goals and the CentOS ethos, I use a different distro. I know that I do not have enough time to contribute but more importantly I recognize how much your and the CentOS team's contributed time has helped myself and the companies I've worked for by providing a very stable platform that I trust to build on.
Keep up the great work and I'll contribute in my own way by patiently waiting for CentOS6 and not spamming this list any more then I just did.
Regards, Chris
Chris Murphy Senior Systems Administrator Castle Branch
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments may contain private, confidential, and privileged information for the restricted use of the intended recipient(s). If you are not the intended recipient(s). You may NOT use, disclose, copy, or disseminate this information. Please notify the sender by return e-mail of this misdirected correspondence and destroy all copies of the original message including all attachments. Your cooperation is appreciated.
Hi Lamar,
On 01/05/2011 03:23 PM, Lamar Owen wrote:
I would, however, add an item to your list, having said that: (d) have sufficient and reliable time availability to help. Although that is somewhat implied by your item (c) above, I believe anyone that plans to really get their hands dirty and help out needs a realistic expectation of the time commitment that is involved (when I maintained the PostgreSQL RPMs, I found that, even with just one package set to maintain, the time commitment was substantial, and was mostly spent doing user support....).
The time concern is an interesting one. My commitment average is between 25 to 30 hrs a week, pretty much every week of the year.
But step aside from that idea for a minute. The way things look from my end of the spectrum is if someone was to not take on a single package, but an entire role. Pgsql would be a good example, another might be LAMP or 'ruby'. As an example, Pasi is looking at the Virt stack. In some cases the role would be a single package, eg. Akemi's work with the plus kernel.
Coming back to your question : if I was to pick a number out of thin air, based on weather conditions and what I *feel*, 5 - 8 hrs a week during 'not release time' would / should be plenty for someone looking at a few packages - remember that given the upstream code churn rate, its not many weeks where one would need to look at updates. And package-set movement is purely limited to new-point-release time anyway, so is not something one would need to worry about too much. Also, checking email more than once a day might be a good idea ( and keeping up with atleast the mailing lists ).
While we are on the subject - its worth noting that a *lot* of the dev / admin / infra / management stuff around CentOS is done on IRC, not in the lists. So anyone wanting to get involved should really consider parking there ( the not-for-end-user channels are extremely low traffic ).
Just my thoughts.
- KB
On Thursday, January 06, 2011 05:22:44 am Karanbir Singh wrote:
Hi Lamar,
Good evening, Karanbir.
The time concern is an interesting one. My commitment average is between 25 to 30 hrs a week, pretty much every week of the year.
That's actually lower than I suspected, honestly.
But step aside from that idea for a minute. The way things look from my end of the spectrum is if someone was to not take on a single package, but an entire role.
Useful indeed, and a good thought.
Coming back to your question : if I was to pick a number out of thin air, based on weather conditions and what I *feel*, 5 - 8 hrs a week...
[snip]
That's useful information, and about what I expected. That's approximately what I did between major releases of PostgreSQL; a major version bump usually meant more work.
While we are on the subject - its worth noting that a *lot* of the dev / admin / infra / management stuff around CentOS is done on IRC, not in the lists. So anyone wanting to get involved should really consider parking there ( the not-for-end-user channels are extremely low traffic ).
For those that, for one reason or another, don't do IRC, are those channels logged, and are those logs published anywhere? That by itself may inject some transparency (as opposed to openness; they are different things, and I'm more interested in transparency than openness, as I suspect some others are as well). That is if those IRC logs *can* be published, or if it's desired and allowed for them to be published. One other project I was involved in, where I helped maintain the PostgreSQL database backend driver for the AOLserver multithreaded application/webserver, also did much work over chat, but it was AIM instead of IRC; the logs were archived and browseable/searchable. With the developers spread over multiple timezones it wasn't the most productive thing in the world.
For all I know the logs are already published, but, just in case they're not.... for all I know there may some automated way of doing that that I'm not aware of (since I don't do IRC, and for that matter can't do IRC at this location). I think the word is 'bot' for an automatic chat attendee that does things in proxy for a user, no? IRC noob here... I can count on one hand the number of chats I've participated in, and on two fingers the number of channels I've logged into (fedora-astronomy was one, and I think I attended another fedora-related chat, but I don't recall).
For that matter, if logs were periodically sent to a mailing list, or an RSS feed.... :-) If someone can point me to the tools I could set that up, and learn something in the process. Comments?
Hi Lamar,
On 01/06/2011 11:08 PM, Lamar Owen wrote:
The time concern is an interesting one. My commitment average is between 25 to 30 hrs a week, pretty much every week of the year.
That's actually lower than I suspected, honestly.
There is still the 40hrs/week day job to think about.. gota eat :)
While we are on the subject - its worth noting that a *lot* of the dev / admin / infra / management stuff around CentOS is done on IRC, not in
For those that, for one reason or another, don't do IRC, are those channels logged, and are those logs published anywhere? That by itself may inject some transparency (as opposed to openness; they are different things, and I'm more interested in transparency than openness, as I suspect some others are as well). That is if those IRC logs *can* be published, or if it's desired and allowed for them to be published. One other project I was involved in, where I helped maintain the PostgreSQL database backend driver for the AOLserver multithreaded application/webserver, also did much work over chat, but it was AIM instead of IRC; the logs were archived and browseable/searchable. With the developers spread over multiple timezones it wasn't the most productive thing in the world.
Traditionally the view taken for channel loggers has been that there are people who spend time there, are well known and dont want logs kept. So it was advised that use irssi in screen, lurk and build your own logs;
Also, the infra channel is not public, for obvious reasons. All security, setup and donor specific conversations take place there - and making that public is going to be extremely hard.
- KB
Hi Karanbir,
On Wed, 5 Jan 2011, Karanbir Singh wrote:
It seems to me that the rebranding process did not start during the upstream beta period. If so, was that a conscious decision by the CentOS team?
The aim was to focus people's attention to the upstream beta, better product and that loop etc.
I can't quite parse that sentence, but I think you are implying "yes"; it was a conscious decision.
We could have started earlier, sure. But now that we have started 2 months back and your own contribution status stays at nil, why are you interested ?
I am a busy person, including contributing daily to other free software projects. Without visibility of what has been done already, and what remains to be done, it's not obvious to me which particular contribution you'd like me to make. Are you not nearly finished?
If there is a rebuild issue you would like me to help debug, or some package you'd like help with rebranding, then please let me know.
On Wednesday, January 05, 2011 03:53:02 pm Charlie Brady wrote:
On Wed, 5 Jan 2011, Karanbir Singh wrote:
The aim was to focus people's attention to the upstream beta, better product and that loop etc.
I can't quite parse that sentence, but I think you are implying "yes"; it was a conscious decision.
FWIW, I had no difficulty with Karanbir's sentence. It's simple: the goal was for folks to test and use the upstream beta, since any and all bugs worked in that loop would trickle into the source rpms from which CentOS would be built. While the rebuild itself, and the packaging, rebranding, etc, itself are not trivial tasks, they are much smaller than QA'ing the actual packages; since CentOS tries to be as close to upstream as possible it is a highly useful (to CentOS) activity to beta test the upstream distribution. So as to not dilute that effort, work on the CentOS-specific parts (rebranding, etc) was intentionally delayed (as implied by the word 'aim' in his sentence).
At least that's how I parsed it. I can do a full Reed-Kellogg diagram if you wish; taught English for eight years.
Ralph Angenendt wrote on 12/31/2010 08:44 AM:
Am 28.12.10 10:37, schrieb Filip Bartmann:
So why is CentOS development so closed? Why users can't have alphas, or betas of this distro and must use some other rebuild as Scientific Linux?
One of the reasons is the sheer volume.
The sheer volume would seem to be a good enabler and reason to have a more robust and open development process.
CentOS is in use (wild educated guess here) on a massively larger scale than SL is. Just getting out the isos for an alpha or beta or whatever will take at least a day to two for getting on all mirror servers. If you also want to have the packages, it even might take longer.
No reason I can see that alpha/beta releases should have to go to all the mirrors, nor even that it would be desirable. Torrents for the ISOs (as Timo Schoeler suggested) and perhaps a one or a few servers for direct ISO downloads (and possibly packages trees) would suffice.
Phil
On Fri, Dec 31, 2010 at 02:44:00PM +0100, Ralph Angenendt wrote:
Am 28.12.10 10:37, schrieb Filip Bartmann:
So why is CentOS development so closed? Why users can't have alphas, or betas of this distro and must use some other rebuild as Scientific Linux?
One of the reasons is the sheer volume. CentOS is in use (wild educated guess here) on a massively larger scale than SL is. Just getting out the
For RHEL5 I have preferred CentOS as it stays more closely to upstream, but given the number of very special cases that need to be considered for the rebuild, I hope CentOS will catch all items that get reported by the open Sientific Linux devel/test cycle. (This won't be too easy...)
regards,
Florian La Roche
Yes, it was another successful New Year's party at Lorri's house.
I'm back home now. I'm ready for a long nap. :)
- Mike
On Sat, Jan 1, 2011 at 1:04 PM, Florian La Roche Florian.LaRoche@gmx.netwrote:
On Fri, Dec 31, 2010 at 02:44:00PM +0100, Ralph Angenendt wrote:
Am 28.12.10 10:37, schrieb Filip Bartmann:
So why is CentOS development so closed? Why users can't have alphas, or betas of this distro and must use some other rebuild as Scientific Linux?
One of the reasons is the sheer volume. CentOS is in use (wild educated guess here) on a massively larger scale than SL is. Just getting out the
For RHEL5 I have preferred CentOS as it stays more closely to upstream, but given the number of very special cases that need to be considered for the rebuild, I hope CentOS will catch all items that get reported by the open Sientific Linux devel/test cycle. (This won't be too easy...)
regards,
Florian La Roche
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
hi Morten,
On 12/27/2010 07:10 PM, Morten P.D. Stevens wrote:
2010/12/26 Michał Piotrowskimkkp4x4@gmail.com:
So I wonder what are the chances of seeing CentOS6 in 2011. Or perhaps a more realistic date is 2012? (Maybe you are waiting for the release of DNF?)
The problem with this kind of question is the closed development process of CentOS.
Funny you say that - given that you offered to help, and when asked to look at something completely turned around and said you dont have time to do anything or will think about it or something such. Yet you seem to be quite visible here in the list and always ready to offer an opinion - mostly wrong at that.
So what is your aim in being on this list and wasting everyone else's time ?
I am not sorry if this comes across as harsh - but realistically, if you don't really want to do anything to help - shutup and move along.
- KB
2011/1/5 Karanbir Singh mail-lists@karan.org:
The problem with this kind of question is the closed development process of CentOS.
Funny you say that - given that you offered to help, and when asked to look at something completely turned around and said you dont have time to do anything or will think about it or something such. Yet you seem to be quite visible here in the list and always ready to offer an opinion - mostly wrong at that.
This is not quite right.
I offered my help for testing pre-CentOS6 alpha/beta versions. Furthermore, my company could help with the infrastructure for CentOS6. (mirror and build server for a fast and open development process of CentOS6)
You have offered me to help with packages that need upstream branding removed.
This is very difficult to realize when the primary mailing list (centos-qa) is completely closed to outsiders.
Apparently you misunderstood my offer to help. I'm sorry.
I am not sorry if this comes across as harsh - but realistically, if you don't really want to do anything to help - shutup and move along.
Without access to beta versions, RPMS and the important qa-mailinglist... How can we help?
This is not my view of community and Open source.
Best regards,
Morten
On 01/05/2011 04:34 PM, Morten P.D. Stevens wrote:
I offered my help for testing pre-CentOS6 alpha/beta versions. You have offered me to help with packages that need upstream branding removed.
I retract my statement in that case.
This is very difficult to realize when the primary mailing list (centos-qa) is completely closed to outsiders.
There is nothing on the centos-qa list, the whole point of moving these discussions to the centos-devel list was to reduce traffic there. Have more people involved at and from an early stage.
- KB
-
Akemi Yagi -
Alan Bartlett -
Charlie Brady -
Chris Murphy -
Cia Watson -
Dag Wieers -
David Hrbáč -
Fabian Arrotin -
Farkas Levente -
Filip Bartmann -
Florian La Roche -
Garry Dale -
Garry.Dale
-
Hubert Bahr -
Hugo van der Kooij -
jean-seb -
jean-sebastien Hubert
-
John R. Dennison -
JohnS -
Josh Boyer -
Karanbir Singh -
Lamar Owen -
Les Mikesell -
Manuel Wolfshant -
Max Haann -
Michael Paska -
Michał Piotrowski -
Morten P.D. Stevens -
Nico Kadel-Garcia -
Phil Schaffner -
Philippe Laurent -
R P Herrold -
R P Herrold -
Ralph Angenendt -
Thomas Bendler -
Timo Schoeler