FAQ
Any updates on progress, either on 5.6 or 6.0?

Bill Sebok Computer Software Manager, Univ. of Maryland, Astronomy
Internet: wls at astro.umd.edu URL: http://furo.astro.umd.edu/

Search Discussions

  • Ljubomir Ljubojevic at Feb 16, 2011 at 2:37 pm
    You can read this interview with Karanbir Singh:
    http://www.oneopensource.it/03/02/2011/centos-6-interview-with-karanbir-singh/

    In short:
    - There is about 2-3 weeks more before 6 is released.
    - CentOS 5.6 should be available for download any day now.

    William L. Sebok wrote:
    Any updates on progress, either on 5.6 or 6.0?

    Bill Sebok Computer Software Manager, Univ. of Maryland, Astronomy
    Internet: wls at astro.umd.edu URL: http://furo.astro.umd.edu/
    _______________________________________________
    CentOS-devel mailing list
    CentOS-devel at centos.org
    http://lists.centos.org/mailman/listinfo/centos-devel
  • Matthew Miller at Feb 16, 2011 at 3:59 pm

    On Wed, Feb 16, 2011 at 08:37:25PM +0100, Ljubomir Ljubojevic wrote:
    You can read this interview with Karanbir Singh:
    http://www.oneopensource.it/03/02/2011/centos-6-interview-with-karanbir-singh/
    - There is about 2-3 weeks more before 6 is released.
    Since that interview was about two weeks ago, I don't think it's
    unreasonable to have a brief status update at this point.


    --
    Matthew Miller mattdm at mattdm.org <http://mattdm.org/>
  • Dag Wieers at Feb 16, 2011 at 5:03 pm

    On Wed, 16 Feb 2011, Matthew Miller wrote:
    On Wed, Feb 16, 2011 at 08:37:25PM +0100, Ljubomir Ljubojevic wrote:

    You can read this interview with Karanbir Singh:
    http://www.oneopensource.it/03/02/2011/centos-6-interview-with-karanbir-singh/
    - There is about 2-3 weeks more before 6 is released.
    Since that interview was about two weeks ago, I don't think it's
    unreasonable to have a brief status update at this point.
    One is not expected to criticize on this list. All is well. Don't ask any
    uncomfortable questions please ! It's normal for a RHEL rebuild to be
    months behind the original. It has never been different for years. Either
    shut up or pay for the real thing. The developers are doing the best they
    can. Again all is well. Don't believe the non-believers.

    --
    -- dag wieers, dag at wieers.com, http://dag.wieers.com/
    -- dagit linux solutions, info at dagit.net, http://dagit.net/

    [Any errors in spelling, tact or fact are transmission errors]
  • Guenther Boelter at Feb 16, 2011 at 9:43 pm

    On 02/17/2011 06:03 AM, Dag Wieers wrote:
    On Wed, 16 Feb 2011, Matthew Miller wrote:
    On Wed, Feb 16, 2011 at 08:37:25PM +0100, Ljubomir Ljubojevic wrote:

    You can read this interview with Karanbir Singh:
    http://www.oneopensource.it/03/02/2011/centos-6-interview-with-karanbir-singh/
    - There is about 2-3 weeks more before 6 is released.
    Since that interview was about two weeks ago, I don't think it's
    unreasonable to have a brief status update at this point.
    One is not expected to criticize on this list. All is well. Don't ask any
    uncomfortable questions please ! It's normal for a RHEL rebuild to be
    months behind the original. It has never been different for years. Either
    shut up or pay for the real thing. The developers are doing the best they
    can. Again all is well. Don't believe the non-believers.
    Are you sure, this answer was ok?

    I can't see any criticism, not in Mathews comment and not in the
    original question. And even if, a fair comment should be ok, or?

    And if you really think, the question is uncomfortable, don't answer.
    But don't tell people, it's not allowed to ask questions ...
  • Johnny Hughes at Feb 18, 2011 at 10:41 am

    On 02/16/2011 04:03 PM, Dag Wieers wrote:
    On Wed, 16 Feb 2011, Matthew Miller wrote:
    On Wed, Feb 16, 2011 at 08:37:25PM +0100, Ljubomir Ljubojevic wrote:

    You can read this interview with Karanbir Singh:
    http://www.oneopensource.it/03/02/2011/centos-6-interview-with-karanbir-singh/
    - There is about 2-3 weeks more before 6 is released.
    Since that interview was about two weeks ago, I don't think it's
    unreasonable to have a brief status update at this point.
    One is not expected to criticize on this list. All is well. Don't ask any
    uncomfortable questions please ! It's normal for a RHEL rebuild to be
    months behind the original. It has never been different for years. Either
    shut up or pay for the real thing. The developers are doing the best they
    can. Again all is well. Don't believe the non-believers.
    You are such a baby Dag.

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 253 bytes
    Desc: OpenPGP digital signature
    Url : http://lists.centos.org/pipermail/centos-devel/attachments/20110218/fabd2fe8/attachment.bin
  • Dag Wieers at Feb 18, 2011 at 11:47 am

    On Fri, 18 Feb 2011, Johnny Hughes wrote:
    On 02/16/2011 04:03 PM, Dag Wieers wrote:

    One is not expected to criticize on this list. All is well. Don't ask any
    uncomfortable questions please ! It's normal for a RHEL rebuild to be
    months behind the original. It has never been different for years. Either
    shut up or pay for the real thing. The developers are doing the best they
    can. Again all is well. Don't believe the non-believers.
    You are such a baby Dag.
    If after so many years we still have the same issues, and the same threads
    and arguments come up, including the promise to fix it after the release
    gets out, but it never does, then yes, I become cynical.

    It's been almost 2 years I left the CentOS team because I couldn't defend
    the CentOS project anymore. The only thing solved was the ownership of
    the CentOS name and domains, but all the other problems regarding code
    transparency, trust-issues, missing or delayed updates, governance,
    adding more people for redundancy, where the considerable ad income is
    going, etc...

    But I am preaching to the wrong choir, because you obviously know all
    this.

    http://dag.wieers.com/blog/leaving-centos-team-not-centos-community

    At least with your involvement I am confident CentOS 4.9 will not be as
    late as CentOS 4.8 was. (And this time I am not being cynical)

    --
    -- dag wieers, dag at wieers.com, http://dag.wieers.com/
    -- dagit linux solutions, info at dagit.net, http://dagit.net/

    [Any errors in spelling, tact or fact are transmission errors]
  • Les Mikesell at Feb 18, 2011 at 12:19 pm

    On 2/18/2011 10:47 AM, Dag Wieers wrote:
    It's been almost 2 years I left the CentOS team because I couldn't defend
    the CentOS project anymore. The only thing solved was the ownership of
    the CentOS name and domains, but all the other problems regarding code
    transparency, trust-issues, missing or delayed updates, governance,
    adding more people for redundancy, where the considerable ad income is
    going, etc...

    But I am preaching to the wrong choir, because you obviously know all
    this.

    http://dag.wieers.com/blog/leaving-centos-team-not-centos-community

    At least with your involvement I am confident CentOS 4.9 will not be as
    late as CentOS 4.8 was. (And this time I am not being cynical)
    Have you attempted the same involvement with SL? Or considered building
    a non-scientific respin of their version? (Basically backing out their
    changes...). Given the economic environment, maybe it would be good if
    they had some volunteer backup.

    --
    Les Mikesell
    lesmikesell at gmail.com
  • Dag Wieers at Feb 18, 2011 at 12:32 pm

    On Fri, 18 Feb 2011, Les Mikesell wrote:
    On 2/18/2011 10:47 AM, Dag Wieers wrote:

    It's been almost 2 years I left the CentOS team because I couldn't defend
    the CentOS project anymore. The only thing solved was the ownership of
    the CentOS name and domains, but all the other problems regarding code
    transparency, trust-issues, missing or delayed updates, governance,
    adding more people for redundancy, where the considerable ad income is
    going, etc...

    But I am preaching to the wrong choir, because you obviously know all
    this.

    http://dag.wieers.com/blog/leaving-centos-team-not-centos-community

    At least with your involvement I am confident CentOS 4.9 will not be as
    late as CentOS 4.8 was. (And this time I am not being cynical)
    Have you attempted the same involvement with SL? Or considered building
    a non-scientific respin of their version? (Basically backing out their
    changes...). Given the economic environment, maybe it would be good if
    they had some volunteer backup.
    Hi Les,

    I recently became a dad, am renovating a house, am involved in a few Open
    Source projects already, so the little time I have left I would like to
    spend wisely ;-) Although I would support any initiative to bring more
    competition into the RHEL rebuild market.

    My opinion has always been that more competition is good for CentOS and
    for its users, compare the current situation with when Whitebox and Tao
    Linux were still around and you could feel the positive influence of the
    competition (the race to be the first to release was one of them).

    That's why more transparency from CentOS regarding to buildtools, changes
    and processes (including an open QA process) would be a much better
    approach in the long run for everyone involved than a closed and protected
    process with less than a handful of people at the center and the large
    community in the dark.

    Although I do understand that some people prefer to keep the control and
    power over things, I just do not agree with it.

    --
    -- dag wieers, dag at wieers.com, http://dag.wieers.com/
    -- dagit linux solutions, info at dagit.net, http://dagit.net/

    [Any errors in spelling, tact or fact are transmission errors]
  • Larry Vaden at Feb 18, 2011 at 12:35 pm

    On Fri, Feb 18, 2011 at 11:19 AM, Les Mikesell wrote:
    Have you attempted the same involvement with SL? Or considered building
    a non-scientific respin of their version? ?(Basically backing out their
    changes...). ?Given the economic environment, maybe it would be good if
    they had some volunteer backup.
    IMHO Dag should _consider_ what centos.alt.ru has done and either vet
    them or do the same thing if they can't be vetted. There's a need for
    current BIND, et al and RH's policy of backporting takes time and puts
    perhaps millions of systems at risk.

    SL could have been named "US Government Linux"; there's nothing
    "scientific" about sl-base and sl-security. It plays well in the same
    environments RH and CentOS play well in, of course, because of the
    charter.

    kind regards/ldv/vaden at texoma.net

    <quote from top management of Internet2 security>
    It's fundamentally wrong for RedHat to attempt to backport security patches
    for such a fundamental service. I'd cuss a blue streak about this point, in
    fact, except that I don't want to trigger the anti-cuss features at
    Dr. Vaughn's place of employment.
    </quote from manager of Internet2 security>
  • Les Mikesell at Feb 18, 2011 at 12:50 pm

    On 2/18/2011 11:35 AM, Larry Vaden wrote:
    There's a need for
    current BIND, et al and RH's policy of backporting takes time and puts
    perhaps millions of systems at risk.
    That's very much a separate issue, and a question of whether you prefer
    old bugs to new ones. Unless you think there are no new bugs.

    --
    Les Mikesell
    lesmikesell at gmail.com
  • Larry Vaden at Feb 18, 2011 at 12:54 pm

    On Fri, Feb 18, 2011 at 11:50 AM, Les Mikesell wrote:
    On 2/18/2011 11:35 AM, Larry Vaden wrote:
    There's a need for
    current BIND, et al and RH's policy of backporting takes time and puts
    perhaps millions of systems at risk.
    That's very much a separate issue, and a question of whether you prefer
    old bugs to new ones. ?Unless you think there are no new bugs.
    New bugs are arguably more difficult to exploit than well known old
    bugs and IMHO the OSS community, in general, moves closer to a
    complete and correct solution with each release.
  • Lamar Owen at Feb 18, 2011 at 1:14 pm

    On Friday, February 18, 2011 12:35:16 pm Larry Vaden wrote:
    There's a need for
    current BIND, et al and RH's policy of backporting takes time and puts
    perhaps millions of systems at risk.
    What exactly is so necessary about having 'current' BIND, and what will break or change in an unexpected way when BIND is brought current?
    <quote from top management of Internet2 security>
    It's fundamentally wrong for RedHat to attempt to backport security patches
    for such a fundamental service. I'd cuss a blue streak about this point, in
    fact, except that I don't want to trigger the anti-cuss features at
    Dr. Vaughn's place of employment.
    </quote from manager of Internet2 security>
    You keep quoting this, but, it seems to me Red Hat has done very well in the market at a time in which the market was difficult. They can't be doing to many things that are 'fundamentally wrong' or they'd go out of business (since they aren't a monopoly). Details, man, details.

    However, the CentOS list is the wrong place to address this; the stated goal of the core CentOS repositories (this excludes CentOSPlus) is to be as close to upstream as is possible in building from the source; bugs and all. Address the bug upstream; it will then come downstream. That is and has been the CentOS credo pretty much as long as there has been a CentOS, as far as I can recall.

    As a further comment, it is not easy to get this close to the upstream at the binary level. Things are better than they used to be back in the days of beehive and highly customized specialized buildhosts (I could find my archived message from Jeff Johnson about it, and I probably could share it here since it's been over ten years, but I have more important things to do after I'm finished with lunch).

    But things are not perfect, and Red Hat does not make public the complete specs on its buildsystems. Like I say, it is better now than in the good old days, thanks in no small part to the Fedora project's open infrastructure, but there are still niggles to do to get things to build.

    Troy has documented on the SL list about some of those niggles; I've been reading the release notes, and they are revealing about the process, and about some fundamental differences between SL and CentOS, both the distributions and the projects. Anyone curious about those differences, read through the archives of all the lists and see them for yourself; I'm not going to summarize here. Suffice to say that I don't think either approach is the One True Way to an EL rebuild; they are just different.

    At one time I thought they should join forces, but even as talented as all the folks involved are, it wouldn't be the greatest of ideas; in a way, thanks to how open the processes of both distributions are (yes, the CentOS process is more open than it could be!), they already have joined forces, just as sovereign allies, instead of parts of one big project.

    Johnny has posted a link to the buildsystem 'things' for C3,4,and 5; 6 isn't up there, probably because it's not finalized.

    I was there in the old days of waiting on a new RHL release; this process is scads more open than the process then was, that is for sure.
  • Les Mikesell at Feb 18, 2011 at 1:30 pm

    On 2/18/2011 12:14 PM, Lamar Owen wrote:
    At one time I thought they should join forces, but even as talented as all the folks involved are, it wouldn't be the greatest of ideas; in a way, thanks to how open the processes of both distributions are (yes, the CentOS process is more open than it could be!), they already have joined forces, just as sovereign allies, instead of parts of one big project.
    In a truly open system, you don't need to 'join forces' to take
    advantage of each others' work. The version control system will tell
    you everything you might need to know, and the fact that it is open
    means that permission to use it is implicit.

    --
    Les Mikesell
    lesmikesell at gmail.com
  • Lamar Owen at Feb 18, 2011 at 1:48 pm

    On Friday, February 18, 2011 01:30:14 pm Les Mikesell wrote:
    In a truly open system, you don't need to 'join forces' to take
    advantage of each others' work. The version control system will tell
    you everything you might need to know, and the fact that it is open
    means that permission to use it is implicit.
    Perhaps the expression 'join forces' isn't quite right.

    The idea wasn't so much sharing information as sharing infrastructure; thus the 'forces' aspect of the 'join' since 'forces' implies infrastructure. At least that was my intent, and what I erroneously thought to be a good idea, as then you can avoid duplication of effort in the infrastructure.

    Since the hard work of integrating the distribution has already been done by Red Hat, and the result of that work is open in terms of the source for the distributed binary RPMs, the work isn't as hard as what the Fedora project or the Debian project does; but it isn't trivial or even easy, either, and much of the effort beyond trademark purging and replacement involves the build and distribution infrastructure.
  • Les Mikesell at Feb 18, 2011 at 2:00 pm

    On 2/18/2011 12:48 PM, Lamar Owen wrote:
    In a truly open system, you don't need to 'join forces' to take
    advantage of each others' work. The version control system will tell
    you everything you might need to know, and the fact that it is open
    means that permission to use it is implicit.
    Perhaps the expression 'join forces' isn't quite right.

    The idea wasn't so much sharing information as sharing infrastructure; thus the 'forces' aspect of the 'join' since 'forces' implies infrastructure. At least that was my intent, and what I erroneously thought to be a good idea, as then you can avoid duplication of effort in the infrastructure.

    Since the hard work of integrating the distribution has already been done by Red Hat, and the result of that work is open in terms of the source for the distributed binary RPMs, the work isn't as hard as what the Fedora project or the Debian project does; but it isn't trivial or even easy, either, and much of the effort beyond trademark purging and replacement involves the build and distribution infrastructure.
    Nobody said it was trivial or easy. No major software project is. But
    the open ones put all their tools in a version control system that
    anyone can access and duplicate. And the successful open ones find that
    some of the people who do access and duplicate their work improve on it
    and make their improvements available. Is anything like that happening
    here?

    --
    Les Mikesell
    lesmikesell at gmail.com
  • Johnny Hughes at Feb 19, 2011 at 5:29 am

    On 02/18/2011 01:00 PM, Les Mikesell wrote:
    On 2/18/2011 12:48 PM, Lamar Owen wrote:

    In a truly open system, you don't need to 'join forces' to take
    advantage of each others' work. The version control system will tell
    you everything you might need to know, and the fact that it is open
    means that permission to use it is implicit.
    Perhaps the expression 'join forces' isn't quite right.

    The idea wasn't so much sharing information as sharing infrastructure; thus the 'forces' aspect of the 'join' since 'forces' implies infrastructure. At least that was my intent, and what I erroneously thought to be a good idea, as then you can avoid duplication of effort in the infrastructure.

    Since the hard work of integrating the distribution has already been done by Red Hat, and the result of that work is open in terms of the source for the distributed binary RPMs, the work isn't as hard as what the Fedora project or the Debian project does; but it isn't trivial or even easy, either, and much of the effort beyond trademark purging and replacement involves the build and distribution infrastructure.
    Nobody said it was trivial or easy. No major software project is. But
    the open ones put all their tools in a version control system that
    anyone can access and duplicate. And the successful open ones find that
    some of the people who do access and duplicate their work improve on it
    and make their improvements available. Is anything like that happening
    here?
    But the VERSION CONTROL SYSTEM would need to be implemented BY upstream
    not us.

    Our stated goal is to NOT change anything that we don't have to change.
    We ONLY make changes to the packages as required to remove trademarks
    ... we add NO CHANGES to fix the packages.

    It is our goal to NOT HAVE ANY CHANGES.

    Therefore a VCS at the package level for our projects is worthless
    (except for the packages that we have to change to remove trademarks).

    That is what no one is understanding here.

    We do NOT change the packages (the SRPMS), therefore there is nothing
    inside the packages to track. If you have the SRPM, you have the source
    code that would get imported into the VCS ... it would then also be
    rebuilt exactly like it was to submit it to the build system.

    For packages that are not changed at all (the VAST MAJORITY in the case
    of CentOS), this splitting of SRPMS into a VCS and then reassembly from
    the VCS into an SRPM adds nothing to the overall process. In fact, it
    only adds a potential spot to do unneeded actions that might introduce
    errors into the packages on reassembly.

    So, this VCS at the CentOS level is extra work for us with no added
    benefit to producing packages.

    The vast majority of the time, we are working directly with SRPMS, and
    not a VCS.






    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 253 bytes
    Desc: OpenPGP digital signature
    Url : http://lists.centos.org/pipermail/centos-devel/attachments/20110219/2fe0843f/attachment.bin
  • Johnny Hughes at Feb 19, 2011 at 5:42 am

    On 02/19/2011 04:29 AM, Johnny Hughes wrote:
    On 02/18/2011 01:00 PM, Les Mikesell wrote:
    On 2/18/2011 12:48 PM, Lamar Owen wrote:

    In a truly open system, you don't need to 'join forces' to take
    advantage of each others' work. The version control system will tell
    you everything you might need to know, and the fact that it is open
    means that permission to use it is implicit.
    Perhaps the expression 'join forces' isn't quite right.

    The idea wasn't so much sharing information as sharing infrastructure; thus the 'forces' aspect of the 'join' since 'forces' implies infrastructure. At least that was my intent, and what I erroneously thought to be a good idea, as then you can avoid duplication of effort in the infrastructure.

    Since the hard work of integrating the distribution has already been done by Red Hat, and the result of that work is open in terms of the source for the distributed binary RPMs, the work isn't as hard as what the Fedora project or the Debian project does; but it isn't trivial or even easy, either, and much of the effort beyond trademark purging and replacement involves the build and distribution infrastructure.
    Nobody said it was trivial or easy. No major software project is. But
    the open ones put all their tools in a version control system that
    anyone can access and duplicate. And the successful open ones find that
    some of the people who do access and duplicate their work improve on it
    and make their improvements available. Is anything like that happening
    here?
    But the VERSION CONTROL SYSTEM would need to be implemented BY upstream
    not us.

    Our stated goal is to NOT change anything that we don't have to change.
    We ONLY make changes to the packages as required to remove trademarks
    ... we add NO CHANGES to fix the packages.

    It is our goal to NOT HAVE ANY CHANGES.

    Therefore a VCS at the package level for our projects is worthless
    (except for the packages that we have to change to remove trademarks).

    That is what no one is understanding here.

    We do NOT change the packages (the SRPMS), therefore there is nothing
    inside the packages to track. If you have the SRPM, you have the source
    code that would get imported into the VCS ... it would then also be
    rebuilt exactly like it was to submit it to the build system.

    For packages that are not changed at all (the VAST MAJORITY in the case
    of CentOS), this splitting of SRPMS into a VCS and then reassembly from
    the VCS into an SRPM adds nothing to the overall process. In fact, it
    only adds a potential spot to do unneeded actions that might introduce
    errors into the packages on reassembly.

    So, this VCS at the CentOS level is extra work for us with no added
    benefit to producing packages.

    The vast majority of the time, we are working directly with SRPMS, and
    not a VCS.
    Something else i want to point out here is that IF you need to adjust a
    build root for a package for version x.y.z-1 ... when x.y.z-2 comes out,
    it may or may not need that same change. And in fact, we try building
    it first with NO changes in the build root to see if it will build, if
    it does not then we would look at what is in (or what is extra in) the
    compare process and add or remove things to get the correct linking.

    There is no magic secret sauce or magic VCS here to be kept over time.
    It is brute force build, compare, adjust, build. It is good only for
    the one iteration for which it is performed. The next time a new
    package is built, we do it in a virgin way to try and reproduce it
    exactly as the SRPM requires.

    It is no harder than build it in mock ... check it ... manually modify
    the build root with some commands ... if required (if the package fails
    the compare).

    You guys act like we are doing magic here, we are not.

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 253 bytes
    Desc: OpenPGP digital signature
    Url : http://lists.centos.org/pipermail/centos-devel/attachments/20110219/a4d09b92/attachment.bin
  • Les Mikesell at Feb 19, 2011 at 11:15 am

    On 2/19/11 4:42 AM, Johnny Hughes wrote:
    Therefore a VCS at the package level for our projects is worthless
    (except for the packages that we have to change to remove trademarks).

    That is what no one is understanding here.
    How do you track the work you do, reproduce it across architectures, and
    duplicate it to spread the load over multiple machines?
    There is no magic secret sauce or magic VCS here to be kept over time.
    It is brute force build, compare, adjust, build. It is good only for
    the one iteration for which it is performed. The next time a new
    package is built, we do it in a virgin way to try and reproduce it
    exactly as the SRPM requires.
    That sounds exactly like a situation where having more people involved could
    help, given the ability to share the state of current work.
    It is no harder than build it in mock ... check it ... manually modify
    the build root with some commands ... if required (if the package fails
    the compare).

    You guys act like we are doing magic here, we are not.
    You really aren't doing those changes by retyping the command lines on every
    machine involved with no automated way to reproduce it or history of what you've
    done, are you?

    --
    Les Mikesell
    lesmikesell at gmail.com
  • Lamar Owen at Feb 19, 2011 at 11:53 am

    On Saturday, February 19, 2011 11:15:39 am Les Mikesell wrote:
    How do you track the work you do, reproduce it across architectures, and
    duplicate it to spread the load over multiple machines?
    I don't know how CentOS the project does this; and that's ok.

    I do know how Fedora does it, and it's called koji. And apparently RHEL6 was created with koji. Koji was built from the ground up to do this, and do it on a large scale.

    For all I know Johnny and Karanbir and whoever else is doing buildsystem work for CentOS may be using koji; but my gut feel is that if they're not using it now it's too late in this cycle to start with it.

    Perhaps in the future; and perhaps not, that's up to the folk doing the actual work of producing the distribution to decide. Not my decision, that much is for sure. Now if I wanted to produce my own dist (LOOSE; Lamar Owen's Operating System - Enterprise) it would be up to me. But this is CentOS, and it isn't up to me. I shouldn't try to be a backseat driver, IOW.
  • Karanbir Singh at Feb 21, 2011 at 9:55 am
    Hi,
    On 02/19/2011 04:53 PM, Lamar Owen wrote:
    For all I know Johnny and Karanbir and whoever else is doing buildsystem work for CentOS may be using koji; but my gut feel is that if they're not using it now it's too late in this cycle to start with it.
    We dont use Koji, there are no plans to use koji or anything like that.
    We have very basic requirements from the buildsystem and we have a lot
    of requirements on the testing side of things. Going with a basic
    process that can work with srpms and work with automated testing at the
    other end is what was decided. Were sticking with that for the near future.
    Perhaps in the future; and perhaps not, that's up to the folk doing the actual work of producing the distribution to decide. Not my decision, that much is for sure. Now if I wanted to produce my own dist (LOOSE; Lamar Owen's Operating System - Enterprise) it would be up to me. But this is CentOS, and it isn't up to me. I shouldn't try to be a backseat driver, IOW.
    the idea of 'version control' is interesting, we publish ( just as we
    work with ) complete, tested srpms as the code-component because it
    helps retain some level of sanity ( even if the idea of sanity is insane
    in cases with builddep's are no longer relevant etc ). However if people
    want to work with a git like repo, I created and pulled in the el6
    codebase into git repo's, hosted at https://nazar.karan.org/cgit/ -
    thats available as a purely side effect resource that people want to
    look at, its not what we work with within centos.

    - KB
  • Lamar Owen at Feb 19, 2011 at 10:44 am

    On Saturday, February 19, 2011 05:29:53 am Johnny Hughes wrote:
    It is our goal to NOT HAVE ANY CHANGES.
    Therefore a VCS at the package level for our projects is worthless [snip]
    We do NOT change the packages (the SRPMS), therefore there is nothing
    inside the packages to track.
    Whew. I understand this, for sure; but I think there is some cross-communication misunderstandings here.

    What I think most people are asking about is not the packages that are being built, and a VCS for the packages (if that's what they are wanting), well, I agree 100% that that is useless, since, as stated, to goal is the rebuild the completely unchanged source RPM and get the binary equivalent RPM out the backend. The SRPMS for the upstream components are already publicly visible at ftp.redhat.com.

    What I think folks are most interested in, and I know this is my case, is the versioning of the packages and changes (custom scripts, etc) to any packages on the buildhost that is doing the mock build itself.

    It's kindof like making sourdough bread (which I've done, using native yeast starter); the same set of ingredients, and the sourdough recipe is a well-known recipe, and pretty consistent from location to location, but yet the same ingredients using the same exact recipe can produce different results; it's all in the particular native yeast used for the starter, and the techniques used to get the starter started. That's why San Francisco sourdough bread tastes different from Western North Carolina sourdough bread; different yeasts.

    The upstream SRPMS are the ingredients, mock is the recipe; but what went into the starter?

    And, yes, sourdough starters are closely guarded secrets at bakeries that have unique products; similar is true for other yeast-driven ferments, including various alcoholic beverages made from fermented starches of various kinds. Which is why you can't make true scotch whisky anywhere but Scotland; it's all in the yeast, which is native.

    That's the part of the process that isn't externally open as far as I can tell. We have quite a bit of scattered documentation on the buildsystem, including mock configs, your scripts you posted a while back, etc. But the versioning of the buildhost (which, in theory shouldn't matter but in practice it does, especially for certain architectures like UltraSPARC) isn't well documented. At least I've not run across it; which is not the same thing as saying that it doesn't exist: it's just saying that I've not yet found it.

    To me, a simple 'rpm -qa|sort' output from the buildhost itself would answer a lot of my questions. I certainly would like to see that output for the IA64 buildhost, and for the last buildhost used for that one alpha SPARC build, as I would like to do those myself (getting C6 on UltraSPARC would be one of my end goals; there is a semi-usable F12-beta for SPARC, even though it's pretty broken for development purposes, meaning that the koji instance on the builder couldn't have been self-hosting and must be running something 'special').

    But without knowing the packages and scripts on the buildhost and external to the SRPM repository to build I don't even know where to start, since I know a buildhost on SPARC requires some deep magic to set up (64-bit kernel but 32-bit userland; the buildhost has to be able to build a 64-bit kernel, and that isn't the easiest of tasks when the whole of userland is 32-bits, which makes sense pretty much only on SPARC, since 64-bit has no performance advantages on SPARC, just memory size advantages). I had a mutt setup on our E6500 at one time that began with Aurora 1.0 and went from there, using yum upgrades..... and replicating it would be a major undertaking. But that was the only SPARC build that I had here that would successfully build a kernel package set.

    So I'm off to investigate the Fedora buildhost documentation that I can find and go from there. (pointer for those who want to see 'square 1' for such:
    http://fedoraproject.org/wiki/Koji/ServerHowTo ) And this is really overkill infrastructure for a buildhost used for special purposes, I know, but at least it's a documented large-scale distributed buildsystem, and perhaps the key to understanding the whole thing resides somewhere in the reams of information out there)....and in no way am I implying that CentOS uses koji, just that a closely related project does (since Fedora is somewhat the upstream for RHEL).

    And, of course, getting an IA64 C6 (which might or might not be possible) would be something I'd love to try out, and is something I would want to do myself and not bother anyone else with; and if the results were something other people would want, then we could look at that when/if that arose.

    And while I may very well have missed what others are interested in, I'm interested mostly in the buildhost magic, and there is magic at the buildhost level in any rebuild. Even if the magic is not automated...... And I'm not at all interested in 'competing' with the CentOS project; I don't have the bandwidth, for one, even if I do have the storage.

    But I certainly reserve the right to be wrong, on all counts.
  • Steve Meyers at Feb 19, 2011 at 11:33 am

    On 2/19/11 8:44 AM, Lamar Owen wrote:
    And while I may very well have missed what others are interested in,
    I'm interested mostly in the buildhost magic, and there is magic at
    the buildhost level in any rebuild. Even if the magic is not
    automated...... And I'm not at all interested in 'competing' with
    the CentOS project; I don't have the bandwidth, for one, even if I do
    have the storage.
    I completely agree. I am interested in duplicating it so I can learn
    more about the process, and through that perhaps be able to contribute
    to the project. I think what would be ideal would be something like a
    kickstart plus a puppet configuration for the buildhost, or at least a
    wiki page documenting the exact steps for setting up a buildhost.

    Steve
  • Karanbir Singh at Feb 21, 2011 at 9:59 am
    Hi,
    On 02/19/2011 04:33 PM, Steve Meyers wrote:
    And while I may very well have missed what others are interested in,
    I'm interested mostly in the buildhost magic, and there is magic at
    the buildhost level in any rebuild. Even if the magic is not
    I completely agree. I am interested in duplicating it so I can learn
    more about the process, and through that perhaps be able to contribute
    to the project. I think what would be ideal would be something like a
    These sort of questions come from the FUD created by the silly people.
    In order to convert a source package to a binary package, you need to
    hit rpmbuild at some stage or the other, the environment it churns in
    can impact the result and these days convention in the
    rhel/fedora/centos areas is to use mock and a defined common buildroot.

    The idea of magic juice used by CentOS is not only stupid its also what
    leads you into believing a lot of the other crap that these people
    shovel out.

    - KB
  • Steve Meyers at Feb 21, 2011 at 12:41 pm

    On 2/21/11 7:59 AM, Karanbir Singh wrote:
    On 02/19/2011 04:33 PM, Steve Meyers wrote:
    And while I may very well have missed what others are interested in,
    I'm interested mostly in the buildhost magic, and there is magic at
    the buildhost level in any rebuild. Even if the magic is not
    I completely agree. I am interested in duplicating it so I can learn
    more about the process, and through that perhaps be able to contribute
    to the project. I think what would be ideal would be something like a
    These sort of questions come from the FUD created by the silly people.
    In order to convert a source package to a binary package, you need to
    hit rpmbuild at some stage or the other, the environment it churns in
    can impact the result and these days convention in the
    rhel/fedora/centos areas is to use mock and a defined common buildroot.

    The idea of magic juice used by CentOS is not only stupid its also what
    leads you into believing a lot of the other crap that these people
    shovel out.
    I was basing my statement on what Johnny had said. He stated that the
    reason it takes so long to do rebuilds is because the build environment
    for some packages is unknown, and it takes some guesswork to figure out
    whether it was built on RHEL 5, Fedora, or whatever.

    Steve Meyers
  • Karanbir Singh at Feb 22, 2011 at 5:26 am

    On 02/21/2011 05:41 PM, Steve Meyers wrote:
    I was basing my statement on what Johnny had said. He stated that the
    reason it takes so long to do rebuilds is because the build environment
    for some packages is unknown, and it takes some guesswork to figure out
    whether it was built on RHEL 5, Fedora, or whatever.
    and so ?

    whats stopping you from trying to get through that stuff like others
    have done ? Timo / Farkas etc have been vocal and been busy in the
    bugzilla.r.c for and with just this sort of an effort.

    Maybe I just fail to see what your point is.

    - KB
  • Larry Vaden at Feb 19, 2011 at 2:25 am

    On Fri, Feb 18, 2011 at 12:14 PM, Lamar Owen wrote:
    But things are not perfect, and Red Hat does not make public the complete specs on its buildsystems. ?Like I say, it is better now than in the good old days, thanks in no small part to the Fedora project's open infrastructure, but there are still niggles to do to get things to build.

    Troy has documented on the SL list about some of those niggles;
    A member of the "information wants to be free club" offers this quote from Troy:

    <quote>
    p.s. Really, we have no "top secret" stuff. High Energy Physics labs
    are very open and willing to share.
    </quote>
  • Karanbir Singh at Feb 21, 2011 at 9:50 am
    Hi
    On 02/18/2011 04:47 PM, Dag Wieers wrote:
    If after so many years we still have the same issues, and the same threads
    and arguments come up, including the promise to fix it after the release
    gets out, but it never does, then yes, I become cynical.
    You will find that its only you who really comes up with these things -
    and since the 6.0 was announced upstream this is the third time you have
    decided to start throwing marbles around a process you neither
    understand nor want to.

    I've read through most of this thread and its all just random stuff
    recycled over and over with zero real value add. You seem to have
    something in your mind as to how a process might work, and are
    completely unable to comprehend any deviations from there. I am no sure
    if there is any other way to put this across.

    - KB
  • Thomas Bendler at Feb 22, 2011 at 11:56 am
    2011/2/21 Karanbir Singh [...]
    I've read through most of this thread and its all just random stuff
    recycled over and over with zero real value add. You seem to have
    something in your mind as to how a process might work, and are
    completely unable to comprehend any deviations from there. I am no sure
    if there is any other way to put this across.
    With other words, what I think that is perfect is really perfect,
    other people are just time consuming idiots without technical
    knowledge. And they don't contribute to the project so they have to
    shut up. Did you ever asked yourself why so less people contribute to
    the CentOS project? Maybe it has something to do with the CentOS
    project and not with the fact that are only idiots out there who can't
    contribute to the project.

    Kind regards, Thomas

    P.S.: I set up a mock/script based infrastructure as a proof of
    concept for a fork in less than four weeks from scratch, so it can't
    be so much rocket science to get C6 up and running if enough people
    sort out the remaining build problems.
  • Larry Vaden at Feb 22, 2011 at 12:22 pm

    On Tue, Feb 22, 2011 at 10:56 AM, Thomas Bendler wrote:
    Maybe it has something to do with the CentOS
    project and not with the fact that are only idiots out there who can't
    contribute to the project.
    1) RHEL is the intellectual property of RedHat, subject to the
    licenses of the work of OSS giants
    2) RH will seek to maximize RH shareholder equity
    ...
    3) RH has hand-selected certain RH employees to perform the CentOS
    project, not more, not fewer
    4) to make it more difficult for competitors, there are in Lamar's
    words, sniggles
    5) RH pays partial lip service to "we stand on the shoulders of OSS giants"
    6) RH looks at CentOS as a farm club of future rate-payers

    IOW, much of this is about #3.
  • David Brian Chait at Feb 22, 2011 at 12:28 pm

    3) RH has hand-selected certain RH employees to perform the CentOS
    project, not more, not fewer
    IOW, much of this is about #3.

    I think you need to lay off the consperacy theories Larry, really. Just because the devs have better things to do right now (like completing 4.9/5.6/6) rather than training a bunch of newbies, that does not automatically mean that they are trying to protect exclusivity...only productivity. IMPO we would all be a lot better off if everyone here would lay off the core team and let them do their work.

    -David
  • Ralph Angenendt at Feb 22, 2011 at 6:48 pm
    Am 22.02.11 18:22, schrieb Larry Vaden:

    Can you please stop your senseless drivel on all kinds of mailing lists
    around the CentOS project? This is the first time that I've been asked
    by *many* members of the community to remove someone from the mailing
    lists, namely you.

    And I must say that I do understand them while trying to catch up on
    mailing list things at the moment.

    Ralph
  • Larry Vaden at Feb 22, 2011 at 7:03 pm

    On Tue, Feb 22, 2011 at 5:48 PM, Ralph Angenendt wrote:

    Can you please stop your senseless drivel on all kinds of mailing lists
    around the CentOS project? This is the first time that I've been asked
    by *many* members of the community to remove someone from the mailing
    lists, namely you.
    Ralph, thanks for your input --- it is fully appreciated.

    I was about to ask Johnny a question, but now I see I probably
    shouldn't unless privacy is irrelevant. If privacy is irrelevant,
    then you can hit DELETE now.

    Did the count of 8 million

    . come from a SWAG
    . came from monitoring installs
    . came from monitoring unique (e.g., mac-based) installs
    . additional choices based on what you know about the count

    ===genesis:
    On Tue, Feb 22, 2011 at 12:36 PM, Johnny Hughes wrote:

    Well Thomas ... when you have a thousand server infrastructure to serve
    6-8 million unique computers with every update then you would rival the
    CentOS project.
  • Johnny Hughes at Feb 22, 2011 at 1:36 pm

    On 02/22/2011 10:56 AM, Thomas Bendler wrote:
    2011/2/21 Karanbir Singh <mail-lists at karan.org>:
    [...]
    I've read through most of this thread and its all just random stuff
    recycled over and over with zero real value add. You seem to have
    something in your mind as to how a process might work, and are
    completely unable to comprehend any deviations from there. I am no sure
    if there is any other way to put this across.
    With other words, what I think that is perfect is really perfect,
    other people are just time consuming idiots without technical
    knowledge. And they don't contribute to the project so they have to
    shut up. Did you ever asked yourself why so less people contribute to
    the CentOS project? Maybe it has something to do with the CentOS
    project and not with the fact that are only idiots out there who can't
    contribute to the project.

    Kind regards, Thomas

    P.S.: I set up a mock/script based infrastructure as a proof of
    concept for a fork in less than four weeks from scratch, so it can't
    be so much rocket science to get C6 up and running if enough people
    sort out the remaining build problems.
    Well Thomas ... when you have a thousand server infrastructure to serve
    6-8 million unique computers with every update then you would rival the
    CentOS project.

    10-15 people on a mailing list continually whining is one thing ... 8
    million machines served is the real thing.

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 253 bytes
    Desc: OpenPGP digital signature
    Url : http://lists.centos.org/pipermail/centos-devel/attachments/20110222/ab209b05/attachment.bin
  • jean-sebastien Hubert at Feb 22, 2011 at 1:50 pm

    Le 22/02/2011 22:36, Johnny Hughes a ?crit :
    On 02/22/2011 10:56 AM, Thomas Bendler wrote:
    2011/2/21 Karanbir Singh <mail-lists at karan.org>:
    [...]
    I've read through most of this thread and its all just random stuff
    recycled over and over with zero real value add. You seem to have
    something in your mind as to how a process might work, and are
    completely unable to comprehend any deviations from there. I am no sure
    if there is any other way to put this across.
    With other words, what I think that is perfect is really perfect,
    other people are just time consuming idiots without technical
    knowledge. And they don't contribute to the project so they have to
    shut up. Did you ever asked yourself why so less people contribute to
    the CentOS project? Maybe it has something to do with the CentOS
    project and not with the fact that are only idiots out there who can't
    contribute to the project.

    Kind regards, Thomas

    P.S.: I set up a mock/script based infrastructure as a proof of
    concept for a fork in less than four weeks from scratch, so it can't
    be so much rocket science to get C6 up and running if enough people
    sort out the remaining build problems.
    Well Thomas ... when you have a thousand server infrastructure to serve
    6-8 million unique computers with every update then you would rival the
    CentOS project.

    10-15 people on a mailing list continually whining is one thing ... 8
    million machines served is the real thing.
    Hello,

    But Thomas is not doing things different from Centos; rpmbuild --rebuild
    (using mock and koji of course) ...
    There is "no magic sauce" as you said, Centos is only rebuilding srpms from
    RHEL.
    So install rpms on One or Millions of computers is the same, after all
    RH does
    the hard work (RH and the "million" of programmers that contribute to
    software under GPL/LGPL/... license).

    ps: long live to puppet / fabric (http://docs.fabfile.org/0.9.4/) ; One,
    One thousand, millions ..;)

    Regards

    js.
  • Thomas Bendler at Feb 22, 2011 at 3:26 pm
    2011/2/22 Johnny Hughes [...]
    Well Thomas ... when you have a thousand server infrastructure to serve
    6-8 million unique computers with every update then you would rival the
    CentOS project.
    10-15 people on a mailing list continually whining is one thing ... 8
    million machines served is the real thing.
    Scaling is something that is part of the architecture of a project,
    technical and functional. Having a major slow down in getting things
    up an running (4.9, 5.6 and 6) means there is a fundamental lack of a
    scalable architecture (and yes, I know about what I'm talking about,
    companies I'm working for are providing services for million of
    peoples without the help of mirrors). It is completely unbelievable
    that the CentOS team still think that is no real problem that releases
    take so much time simply because three releases start at the same
    time. This is something that could happen every time in the future
    again. So it's time to think about the architecture of the project and
    how to spread the load to more people to have three completely
    independent release teams and release cycles in the range of four
    weeks after RHEL GA versions.

    And to make my point clear, I don't believe it is rocket science to
    get such a release cycle established if _more_ skilled people are
    involved in the release creation (beyond translation work).

    Kind regards, Thomas
  • Karanbir Singh at Feb 23, 2011 at 6:39 am

    On 02/22/2011 08:26 PM, Thomas Bendler wrote:
    And to make my point clear, I don't believe it is rocket science to
    get such a release cycle established if _more_ skilled people are
    involved in the release creation (beyond translation work).
    I do believe you dont know what you are talking about, have done no
    research or aware of the CentOS process. You seem to be going on and on
    about getting more eyes on the ball, which is exactly what we attempted
    to do last year, and the option is still open.

    - KB
  • Thomas Bendler at Feb 24, 2011 at 11:59 am
    2011/2/23 Karanbir Singh <mail-lists at karan.org>
    On 02/22/2011 08:26 PM, Thomas Bendler wrote:
    And to make my point clear, I don't believe it is rocket science to
    get such a release cycle established if _more_ skilled people are
    involved in the release creation (beyond translation work).
    I do believe you dont know what you are talking about, have done no
    research or aware of the CentOS process. You seem to be going on and on
    about getting more eyes on the ball, which is exactly what we attempted
    to do last year, and the option is still open.
    Funny to know that I don't know what I'm talking about but maybe you can be
    more specific. As I already pointed out in another mail, for me it look like
    that having more than one release at the same time (4.9, 5.6 and 6) result
    in a major slow down of release cycle time. This means for me, the project
    isn't able to scale (correct me if I'm wrong). When the project can't scale
    it is under normal circumstances a matter of human resources or technical
    boundaries. As you told me already in December, it is not a technical
    problem. So from my point of view it could _only_ be a matter of human
    resources in terms that not enough people working on the release (again,
    correct me if I'm wrong). To offer my help I asked already in December,
    please provide a list of packages that don't compile so that people that are
    willing to help can help getting this packages compiled (i.e. with differnet
    mock settings or whatever needed to get this compiled). If the recompile
    isn't possible because the SRPM is broken they can submit Bugreports to RH.
    But I only saw such a list on the SL website (
    https://www.scientificlinux.org/distributions/6x/build/problembyrpm), not on
    the CentOS website.

    What I heard in the meantime is that CentOS has a policy that the next
    release must be compiled with CentOS what I think is a bit funny simply
    because RedHat don't use a build environment based in RedHat (I read an
    article in the press indicating that they use FC12 koji with some FC13, FC14
    backports, but I can't proof this). But the point is still, if you and your
    team allow skilled people to support you in the release creation (not by
    signing packages or so, but to work out open items, problems, whatsoever) it
    is something that the CentOS project will benefit, specially if you look at
    the mails currently on the list, most mails are from the same type, when is
    CentOS X.X released and why isn't it already released.

    Kind regards, Thomas
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.centos.org/pipermail/centos-devel/attachments/20110224/e93161c9/attachment.html
  • Johnny Hughes at Feb 24, 2011 at 12:11 pm

    On 02/24/2011 10:59 AM, Thomas Bendler wrote:
    2011/2/23 Karanbir Singh <mail-lists at karan.org
    <mailto:mail-lists at karan.org>>
    On 02/22/2011 08:26 PM, Thomas Bendler wrote:
    And to make my point clear, I don't believe it is rocket science to
    get such a release cycle established if _more_ skilled people are
    involved in the release creation (beyond translation work).
    I do believe you dont know what you are talking about, have done no
    research or aware of the CentOS process. You seem to be going on and on
    about getting more eyes on the ball, which is exactly what we attempted
    to do last year, and the option is still open.


    Funny to know that I don't know what I'm talking about but maybe you can
    be more specific. As I already pointed out in another mail, for me it
    look like that having more than one release at the same time (4.9, 5.6
    and 6) result in a major slow down of release cycle time. This means for
    me, the project isn't able to scale (correct me if I'm wrong). When the
    project can't scale it is under normal circumstances a matter of human
    resources or technical boundaries. As you told me already in December,
    it is not a technical problem. So from my point of view it could _only_
    be a matter of human resources in terms that not enough people working
    on the release (again, correct me if I'm wrong). To offer my help I
    asked already in December, please provide a list of packages that don't
    compile so that people that are willing to help can help getting this
    packages compiled (i.e. with differnet mock settings or whatever needed
    to get this compiled). If the recompile isn't possible because the SRPM
    is broken they can submit Bugreports to RH. But I only saw such a list
    on the SL website
    (https://www.scientificlinux.org/distributions/6x/build/problembyrpm),
    not on the CentOS website.

    What I heard in the meantime is that CentOS has a policy that the next
    release must be compiled with CentOS what I think is a bit funny simply
    because RedHat don't use a build environment based in RedHat (I read an
    article in the press indicating that they use FC12 koji with some FC13,
    FC14 backports, but I can't proof this). But the point is still, if you
    and your team allow skilled people to support you in the release
    creation (not by signing packages or so, but to work out open items,
    problems, whatsoever) it is something that the CentOS project will
    benefit, specially if you look at the mails currently on the list, most
    mails are from the same type, when is CentOS X.X released and why isn't
    it already released.
    Why isn't SL released yet ... why did Oracle only release it last week
    ... because it takes time and it is hard.

    If you want to use CentOS, feel free to use it. If you don't, feel free
    to leave.

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 253 bytes
    Desc: OpenPGP digital signature
    Url : http://lists.centos.org/pipermail/centos-devel/attachments/20110224/a56bdb93/attachment.bin
  • Philippe Laurent at Feb 24, 2011 at 12:22 pm
    I do appreciate everyone's efforts!

    I have a few idle servers locally that can be used for compiling, but
    unfortunately cannot make the servers accessible to the outside. If that
    helps, I am willing to toss in CPU cycles.
    On Thu, Feb 24, 2011 at 12:11 PM, Johnny Hughes wrote:
    On 02/24/2011 10:59 AM, Thomas Bendler wrote:
    2011/2/23 Karanbir Singh <mail-lists at karan.org
    <mailto:mail-lists at karan.org>>
    On 02/22/2011 08:26 PM, Thomas Bendler wrote:
    And to make my point clear, I don't believe it is rocket science to
    get such a release cycle established if _more_ skilled people are
    involved in the release creation (beyond translation work).
    I do believe you dont know what you are talking about, have done no
    research or aware of the CentOS process. You seem to be going on and on
    about getting more eyes on the ball, which is exactly what we attempted
    to do last year, and the option is still open.


    Funny to know that I don't know what I'm talking about but maybe you can
    be more specific. As I already pointed out in another mail, for me it
    look like that having more than one release at the same time (4.9, 5.6
    and 6) result in a major slow down of release cycle time. This means for
    me, the project isn't able to scale (correct me if I'm wrong). When the
    project can't scale it is under normal circumstances a matter of human
    resources or technical boundaries. As you told me already in December,
    it is not a technical problem. So from my point of view it could _only_
    be a matter of human resources in terms that not enough people working
    on the release (again, correct me if I'm wrong). To offer my help I
    asked already in December, please provide a list of packages that don't
    compile so that people that are willing to help can help getting this
    packages compiled (i.e. with differnet mock settings or whatever needed
    to get this compiled). If the recompile isn't possible because the SRPM
    is broken they can submit Bugreports to RH. But I only saw such a list
    on the SL website
    (https://www.scientificlinux.org/distributions/6x/build/problembyrpm),
    not on the CentOS website.

    What I heard in the meantime is that CentOS has a policy that the next
    release must be compiled with CentOS what I think is a bit funny simply
    because RedHat don't use a build environment based in RedHat (I read an
    article in the press indicating that they use FC12 koji with some FC13,
    FC14 backports, but I can't proof this). But the point is still, if you
    and your team allow skilled people to support you in the release
    creation (not by signing packages or so, but to work out open items,
    problems, whatsoever) it is something that the CentOS project will
    benefit, specially if you look at the mails currently on the list, most
    mails are from the same type, when is CentOS X.X released and why isn't
    it already released.
    Why isn't SL released yet ... why did Oracle only release it last week
    ... because it takes time and it is hard.

    If you want to use CentOS, feel free to use it. If you don't, feel free
    to leave.


    _______________________________________________
    CentOS-devel mailing list
    CentOS-devel at centos.org
    http://lists.centos.org/mailman/listinfo/centos-devel
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.centos.org/pipermail/centos-devel/attachments/20110224/5128f84b/attachment.html
  • Thomas Bendler at Feb 24, 2011 at 12:33 pm
    2011/2/24 Johnny Hughes [...]

    Why isn't SL released yet ... why did Oracle only release it last week
    ... because it takes time and it is hard.
    A lot of the things take time and a lot of things are hard. And in most
    cases the process could be simplified and the speed could be increased, but
    only if the process, man power, whatsoever is optimized.

    If you want to use CentOS, feel free to use it. If you don't, feel free
    to leave.
    Very constructive! I'm not on this list because I use Oracle, SL or any
    other rebuild of RHEL, I'm using CentOS and I would like to stay with
    CentOS. But if no comment is taken serious I'm not convinced if this is a
    smart decision.

    Kind regards, Thomas
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.centos.org/pipermail/centos-devel/attachments/20110224/bd345f13/attachment.html
  • Dag Wieers at Feb 24, 2011 at 4:34 pm

    On Thu, 24 Feb 2011, Johnny Hughes wrote:

    Why isn't SL released yet ... why did Oracle only release it last week
    ... because it takes time and it is hard.
    Oracle released RHEL 5.6 on january 12th. Scientific Linux has a rolling
    release since early february.

    --
    -- dag wieers, dag at wieers.com, http://dag.wieers.com/
    -- dagit linux solutions, info at dagit.net, http://dagit.net/

    [Any errors in spelling, tact or fact are transmission errors]
  • Karanbir Singh at Feb 24, 2011 at 5:32 pm

    On 02/24/2011 09:34 PM, Dag Wieers wrote:
    On Thu, 24 Feb 2011, Johnny Hughes wrote:

    Why isn't SL released yet ... why did Oracle only release it last week
    ... because it takes time and it is hard.
    Oracle released RHEL 5.6 on january 12th. Scientific Linux has a rolling
    release since early february.
    Given that Red Hat released 5.6 on Jan 13th, its interesting that you
    say Oracle had their build out on the 12th. Also interesting and worth
    noting is that 5.6 sources stock was still making its way to ftp.r.c a
    few days back ( well into second half of Feb ). Its blatantly clear that
    neither Oracle nor SciLinux are operating with the same model as are.
    And I think its also quite clear that we don't really give a rat's ass
    about what Oracle or SciLinux are doing.

    So, can we just give up all this random noise now

    - KB
  • Dag Wieers at Feb 24, 2011 at 5:52 pm

    On Thu, 24 Feb 2011, Karanbir Singh wrote:
    On 02/24/2011 09:34 PM, Dag Wieers wrote:
    On Thu, 24 Feb 2011, Johnny Hughes wrote:

    Why isn't SL released yet ... why did Oracle only release it last week
    ... because it takes time and it is hard.
    Oracle released RHEL 5.6 on january 12th. Scientific Linux has a rolling
    release since early february.
    Given that Red Hat released 5.6 on Jan 13th, its interesting that you
    say Oracle had their build out on the 12th.
    I meant to say january 20th, another lapsus on my part:

    http://blogs.oracle.com/linux/2011/01/oracle_linux_56_now_available.html

    And I think its also quite clear that we don't really give a rat's ass
    about what Oracle or SciLinux are doing.
    Then Johnny shouldn't have brought it up, should he ? I was simply filling
    in the facts.

    For those without a LWN subscription, the discussion was mentioned on LWN:

    http://lwn.net/SubscriberLink/429364/d1bdc6e1e6e58d0b/

    which, incidentally, is where I got that Oracle release date from.

    --
    -- dag wieers, dag at wieers.com, http://dag.wieers.com/
    -- dagit linux solutions, info at dagit.net, http://dagit.net/

    [Any errors in spelling, tact or fact are transmission errors]
  • Karanbir Singh at Feb 24, 2011 at 6:00 pm

    On 02/24/2011 10:52 PM, Dag Wieers wrote:
    For those without a LWN subscription, the discussion was mentioned on LWN:

    http://lwn.net/SubscriberLink/429364/d1bdc6e1e6e58d0b/

    which, incidentally, is where I got that Oracle release date from.
    Quality of lwn.net isnt quite what it used to be :/ there are so many
    factual mistakes in that piece.

    - KB
  • Johnny Hughes at Feb 24, 2011 at 7:01 pm

    On 02/24/2011 03:34 PM, Dag Wieers wrote:
    On Thu, 24 Feb 2011, Johnny Hughes wrote:

    Why isn't SL released yet ... why did Oracle only release it last week
    ... because it takes time and it is hard.
    Oracle released RHEL 5.6 on january 12th. Scientific Linux has a rolling
    release since early february.
    They (SL) do not recommend rolling in production ... we don't release
    things we don't want used in production. There is nothing wrong with
    either approach, but it is not fair to compare a final release to a
    beta/alpha release.

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 253 bytes
    Desc: OpenPGP digital signature
    Url : http://lists.centos.org/pipermail/centos-devel/attachments/20110224/e177c055/attachment.bin
  • Larry Vaden at Feb 18, 2011 at 11:01 am

    On Wed, Feb 16, 2011 at 4:03 PM, Dag Wieers wrote:
    One is not expected to criticize on this list. All is well. Don't ask any
    uncomfortable questions please ! It's normal for a RHEL rebuild to be
    months behind the original. It has never been different for years. Either
    shut up or pay for the real thing. The developers are doing the best they
    can. Again all is well. Don't believe the non-believers.
    Dag,

    One can read that you are very prolific and that there is a community
    of developers who help you with your transparent process.

    What is the URL that describes your process?

    kind regards/ldv/vaden at texoma.net --- Transaction ID: 2V060708WB590000G (2/8/06)
  • Dag Wieers at Feb 18, 2011 at 11:28 am

    On Fri, 18 Feb 2011, Larry Vaden wrote:
    On Wed, Feb 16, 2011 at 4:03 PM, Dag Wieers wrote:

    One is not expected to criticize on this list. All is well. Don't ask any
    uncomfortable questions please ! It's normal for a RHEL rebuild to be
    months behind the original. It has never been different for years. Either
    shut up or pay for the real thing. The developers are doing the best they
    can. Again all is well. Don't believe the non-believers.
    One can read that you are very prolific and that there is a community
    of developers who help you with your transparent process.

    What is the URL that describes your process?
    Hi Larry,

    Everything is available from:

    http://svn.rpmforge.net/svn/

    we have a viewvc front-end and a mailinglist to keep track of changes
    here:

    http://svn.rpmforge.net/viewvc/
    http://lists.rpmforge.net/mailman/listinfo/svn-commits

    And there are mailinglists to suggest changes or discuss packages. But at
    least everything is shared.

    We don't have the community size, nor the infrastructure, nor the
    financial baggage that CentOS has, so it may not be a good comparison.

    --
    -- dag wieers, dag at wieers.com, http://dag.wieers.com/
    -- dagit linux solutions, info at dagit.net, http://dagit.net/

    [Any errors in spelling, tact or fact are transmission errors]
  • . at Feb 19, 2011 at 2:31 am

    On 2/18/2011 8:28 AM, Dag Wieers wrote:
    Everything is available from:

    http://svn.rpmforge.net/svn/

    we have a viewvc front-end and a mailinglist to keep track of changes
    here:

    http://svn.rpmforge.net/viewvc/
    http://lists.rpmforge.net/mailman/listinfo/svn-commits

    And there are mailinglists to suggest changes or discuss packages. But at
    least everything is shared.
    I would like to say that in my opinion the system mentioned above
    sounds better than what there is now, for outsiders.

    Now, I don't want outsiders to have access to the GPG keys, nor the
    ability to push out new versions, but being able to see the source tree
    as it is, and being able to download a mock config + setup instructions
    would go a long way (again in my opinion).

    Forgive my naivete, but what is preventing us from doing such a
    thing? Is this a lack of manpower/resources to set it up, or is this
    more political as in; we don't want other rhel based distros to steal
    our juju?

    For those about to say, help out or don't; I have helped out. I did
    a handful of patches last month after reverse engineering the process
    (http://thread.gmane.org/gmane.linux.centos.devel/6903/). Fast forward a
    month, and none of the bug ids where I posted patches on have had so
    much as their status changed. Before you jump down my throat on that, I
    realize the priority was/is Centos 5.6 etc...

    I do believe that if we had a system similar to what Dag is using;
    someone in the Centos community would have tried the patches I made,
    maybe they didn't work and I needed to fix something or maybe they fix
    it and upload a better version. I think progress would have been made
    that wouldn't have detracted from the centos-devel's focus.
  • Johnny Hughes at Feb 19, 2011 at 5:17 am

    On 02/19/2011 01:31 AM, . wrote:
    On 2/18/2011 8:28 AM, Dag Wieers wrote:
    Everything is available from:

    http://svn.rpmforge.net/svn/

    we have a viewvc front-end and a mailinglist to keep track of changes
    here:

    http://svn.rpmforge.net/viewvc/
    http://lists.rpmforge.net/mailman/listinfo/svn-commits

    And there are mailinglists to suggest changes or discuss packages. But at
    least everything is shared.
    I would like to say that in my opinion the system mentioned above
    sounds better than what there is now, for outsiders.

    Now, I don't want outsiders to have access to the GPG keys, nor the
    ability to push out new versions, but being able to see the source tree
    as it is, and being able to download a mock config + setup instructions
    would go a long way (again in my opinion).

    Forgive my naivete, but what is preventing us from doing such a
    thing? Is this a lack of manpower/resources to set it up, or is this
    more political as in; we don't want other rhel based distros to steal
    our juju?
    We release our SRPMS, that is our juju. Every patch is there for the
    looking.

    I have tried to explain, over and over again. You guys are trying to
    make the process different than it is.

    For most projects where RPMS are produced, you are getting an upstream
    tar ball that may or may not have a spec file ... you are creating spec
    file, you are creating lots of patches to change where WWW pages go or
    what directory things get installed in, etc.

    That is not the case with CentOS ... all of those changes are already in
    the "SRPM Source Tree". Our #1 goal (by far) is to be able to use that
    SRPM package exactly as it is ... to clone it and make our rendering of
    it as identical as possible to the original.

    For the vast majority of packages, we make no changes. We rebuild it
    and test it. If the binary passes the test, we use it. If the binary
    does not pass the test we troubleshoot and figure out why it does not
    pass the test ... and we change things OUTSIDE the SRPM to fix the
    problem.

    For example, here is a problem that I had to solve for 4.9 yesterday.
    There is a hidden build requirement that the package
    gnome-volume-manager requires perl-XML-Parser to be in the mock build
    root for the package to build properly. This is NOT called out in the
    SRPM. We need to add it to the tree to build this package ... BUT, we
    do not modify the SRPM to make this happen, we instead modify the build
    root, and submit a BUG upstream for them to potentially fix this package.

    Since our goal is NOT to change upstream packages at all, this would not
    show up in this "SVN" or "GIT" tree of all the packages ... since we do
    not change (or want to change) the package that upstream has produced.
    In any other project besides CentOS, the fix would take 1 minute, it
    would be to add a "Build Requires: perl-XML-Parser" to the spec file in
    the SVN repo and regenerate the SRPM package.

    So, this time consuming tree that you want guys want us to create is not
    worth a hill of beans and adds nothing for the vast majority of
    packages, since the SRPM is unmodified from upstream.

    You have everything you need already in the SRPM.
    For those about to say, help out or don't; I have helped out. I did
    a handful of patches last month after reverse engineering the process
    (http://thread.gmane.org/gmane.linux.centos.devel/6903/). Fast forward a
    month, and none of the bug ids where I posted patches on have had so
    much as their status changed. Before you jump down my throat on that, I
    realize the priority was/is Centos 5.6 etc...

    I do believe that if we had a system similar to what Dag is using;
    someone in the Centos community would have tried the patches I made,
    maybe they didn't work and I needed to fix something or maybe they fix
    it and upload a better version. I think progress would have been made
    that wouldn't have detracted from the centos-devel's focus.
    What makes you think that we HAVE a "split" source tree?

    CentOS builds someone else's SRPMS ... that IS our source tree, the
    SRPMS that are produced upstream.

    We only change a handful of SRPMS (the ones that are labeled .centos).
    We are not creating these packages, and in fact it is desirable that
    they do not change at all.

    We would be creating extra work to break down the SRPMS into their
    component parts and create this so called source tree.

    What would be the benefit of all this extra work since we do not change
    the vast majority of the packages.


    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 253 bytes
    Desc: OpenPGP digital signature
    Url : http://lists.centos.org/pipermail/centos-devel/attachments/20110219/179746e7/attachment.bin
  • Larry Vaden at Feb 19, 2011 at 7:34 am

    On Sat, Feb 19, 2011 at 4:17 AM, Johnny Hughes wrote:
    For example, here is a problem that I had to solve for 4.9 yesterday.
    There is a hidden build requirement that the package
    gnome-volume-manager requires perl-XML-Parser to be in the mock build
    root for the package to build properly. ?This is NOT called out in the
    SRPM. ?We need to add it to the tree to build this package ... BUT, we
    do not modify the SRPM to make this happen, we instead modify the build
    root, and submit a BUG upstream for them to potentially fix this package.
    Johnny,

    Although one can read on this list that you are no longer with the
    CentOS Team, we are glad to hear that you are still on the CentOS
    Team.

    Is what you describe above what Lamar describes on this list as sniggles?

    What do you think is the root cause of such things @ the upstream?

    kind regards/ldv/vaden at texoma.net

    Following Troy's style manual,

    p.s. In an effort to rid our site of proprietary backup for Windows
    boxen in favor of OSS backup, we ran into more or less the same thing
    with rsync (compilation errors in the BSD environs for revs > 2.6.8).
    This _may_ explain why RH5 uses rsync-2.6.8.

Related Discussions

People

Translate

site design / logo © 2022 Grokbase