Hi Dag,

On 02/23/2011 10:01 AM, Dag Wieers wrote:
> No they can not. The bottom line is, people can try to reverse engineer
> the process CentOS is using, but they may never be sure it's like what
> CentOS did. So your statement is incorrect.

I am not sure how to say this any other way, its been said many times
over and over again : we dont use any super magic juice anywhere, its
mostly just mock in a for loop. Lets assume that there still exists some
fear and doubt somewhere about the process in exact terms.

then lets take up the conversation on list where I said that once 6 is
our of the door, I'll document what and how things worked for the build
process ( including the pause's and why they took place. Would that
remove some of this FUD layers ?

> Hence my joke that the 'C' in CentOS actually means Closed.

I dont agree, if you said 'C' in CentOS is mispelled 'Slower than
ideal', I'd agree

> That said, if CentOS wants it this way they sure have every right to do it
> like this. But it would be nice to state that upfront.

Propose a wording snippet ?

- KB
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel

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
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel

Larry Vaden wrote:
> On Tue, Feb 22, 2011 at 8:19 PM, John R. Dennison <jrd@gerdesas.com> wrote:
>> On Tue, Feb 22, 2011 at 08:17:11PM -0600, Larry Vaden wrote:
>>> At the same time, this sub-thread would have been much shorter if you
>>> had made the pictures much earlier. Private emails from well informed
>>> sources have suggested that _several_ platforms are used).
>> You're another one. You're about as technically competent as a
>> garden gnome. Can you please stop polluting this list with your
>> rampant prattle and noise? Please? I'd even be willing to pay
>> you to just go the hell away.
>>
>>
>>
>>
>> John
>> --
>> We only think when we are confronted with problems.
>>
>> -- John Dewey (1859-1952), American philosopher, educator
>
> John, Will Rogers was right; I think every time you want to call
> someone ignorant, you should point out one of your own ignorances and
> reduce you sig line count by one each time also, so that you are
> eventually in compliance with list guidelines about sig length. e.g.,
> if you could redact/modify the above post, you would only need to
> utter 4 things about which about which you are as ignorant as you
> claim several of us are. Or, maybe you are a little fascist
> practicing to be a big Fascist. In America, the majority (> 50%)
> rules; in Ralph's Germany, you need 5% (as the Green Party knows so
> well) to have representation.

More precise would be to say:

In America, the majority (> 50%) of those voting (36%-56%) rules.

So essentially 18%-28% should rule. When you add that big companies are
allowed to legally lobby (Only in America?) for their profit (and recent
lobbying affairs), and the fact that no one has access to
examine the code of the software calculating votes (so software company
can change the code to show what ever they want and in doing so change
the results of election) and there is no paper trail, it turns out that
in fact tiny minority rules in America. Australia is another matter.
Voting there is compulsory and voter turnout is always ~95%. Sorry to
burst your bubble on this one.

And you are absolutely ignorant (or at least perceived in this way) when
it comes to package/distro building/recompiling. I can understand if you
want to learn, but your way of learning is not productive, just extremly
irritant. You need to burst your bubble of misconceptions and start over
by first questioning every stand you have with thorough research before
you accept it. It can be scary, but also a lot of fun, from first hand
self-questioning experience I've had so far.

Ljubomir
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel

Jeff Johnson wrote:
> On Feb 22, 2011, at 8:56 PM, Morten P.D. Stevens wrote:
>
>> Just take the missing build dependencies from Fedora 12/13. Red Hat has probably done the same.
>>
>> What are you waiting for @ CentOS team??? Until Red Hat released the missing build dependencies?
>>
>
> Please note that I did _NOT_ intend to re-start flames or CentOS bashing.
>
> There is however a logical inconsistency between
> By policy, CentOS changes nothing (but removes trademarks to be legal)
> and
> 1. Make the distro self hosting
> 2. Get rid of hidden build requirements
>
> How does one detect "hidden" if every package is "de facto" and unchangeable by policy?
>
> (aside)
> And there's even reasons to not change dependencies, because that has some
> (modest imho) risk of changing depslover (sic) behavior.
>
> But if you CAN detect "hidden" or "missing" (and I'm quite sure Johnny can),
> then adding a dependency is likely best for everyone involved, policy be damned.
>
> Why re-distribute SRPM's with "hidden" (or missing) dependencies? That
> kinda misses the point of dependencies in package metadata.
>

I'll try to explain the purpose of CentOS project in layman terms.

Many business applications are written for RHEL, some of them
specifically relaying on "bugs" if they could be called that. So if you
want to create the "free" copy of RHEL source code and at the same time
make sure that ALL applications for RHEL will also work for your distro.

This goal of binary compatibility serves multiple purposes:
1. Red Hat has free version of RHEL so vast number of people can educate
on it and if they choose use it for non-time-critical systems.

2. Software developers have wider user base for software
developed/ported for RHEL, making their development more profitable,
with lesser development cost per sold license.

3. User can sleep peacefully knowing that Red Hat is behind the actual
development of their OS, and knowing that, if they choose so (need for
support, their business/systems becoming time/mission critical), they
can CONVERT their CentOS to RHEL by JUST buying subscription license and
changing from where yum gets it's upgrades. There is no need to
reinstall every single system and databases/applications in order to
switch from Open source system to "paid for support" RHEL.
Just think how you would feel if you had to reinstall 20-30 servers in
the middle of production use just because beancounters decided they want
security of 24/7 support.

This last item is why I (and a lot of others) decided to use/learn
CentOS (I actually started experimenting with WhiteBox first). Keeping
CentOS binary and sources SAME (as in ABSOLUTELY THE SAME as much as
possible ) as is in RHEL, makes my knowledge and apps I develop
applicable to RHEL if I even run into situation to maintain it or to
sell some software for RHEL.

If you are not able to wrap your head around this notion and those
purposes are not important to you, then find some other distro or create
tour own RHEL respin where you will change SRPMS at your whim, but do
not be surprised if only small number of people decides to use it
instead of CentOS, since once you start changing SRPMS you will never
ever stop and it will not be RHEL respin any more.

Ljubomir

_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel

On 02/23/2011 04:01 AM, Dag Wieers wrote:
> On Tue, 22 Feb 2011, Johnny Hughes wrote:
>
>> I am aware, but it also is very important that we (the CentOS Project)
>> do not change the SRPMS (or the source tar balls, or any other piece of
>> source) for any reason except to remove trademarks and copyright info.
>> It is the whole purpose of the CentOS Project.
>>
>> The bottom line is, people can figure out how to recompile the packages
>> just like we did ... but we don't change the sources.
>
> No they can not. The bottom line is, people can try to reverse engineer
> the process CentOS is using, but they may never be sure it's like what
> CentOS did. So your statement is incorrect.
>
> Hence my joke that the 'C' in CentOS actually means Closed.
>
> That said, if CentOS wants it this way they sure have every right to do it
> like this. But it would be nice to state that upfront.

W#e did state it up front ... no changes to the SRPMS except for
trademark changes.
================================================== ===================================
We stated here in 2003:

http://www.centos.org/modules/tinycontent/index.php?id=5

"CentOS uses the original sources whenever possible. Under normal
circumstances CentOS will NOT add patches to original upstream source
packages. The vast majority of changes made will be made to comply with
the upstream vendor's re-distribution policies concerning trademarked
names or logos."
================================================== ===================================
We stated it here in 2003:

"CentOS exists to provide a free enterprise class computing platform to
anyone who wishes to use it. CentOS 2, 3, and 4 are built from
publically available open source SRPMS provided by a prominent North
American Enterprise Linux vendor. CentOS conforms fully with the
upstream vendors redistribution policies and aims to be 100% binary
compatible. (CentOS mainly changes packages to remove upstream vendor
branding and artwork.)."

================================================== ===================================
We stated it here in 2004:

http://www.centos.org/modules/smartfaq/faq.php?faqid=11

"Does CentOS change the upstream Source RPMs?

No. CentOS' key mandate for our base and updates repositories is NOT
extending or enhancing packages or features beyond those supplied by the
upstream Source RPM's."
================================================== ===================================

We have stated numerous times over the last 7+ years that we are not
changing that policy.

You have been bellyaching about this for the entire 8 years ... for you
now to come here and say that we should have told you up front is
unbelievably disingenuous. You have been told this dozens of times by
me alone.

So, am I now also a bald-face liar as well as a totally incompetent
maintainer? Haven't been told up front that we don't change sources ...
Really, Dag ... REALLY?

_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel

On Wed, Feb 23, 2011 at 10:59:28AM +0000, Karanbir Singh wrote:
> Hi Dag,
>
> On 02/23/2011 10:01 AM, Dag Wieers wrote:
> > No they can not. The bottom line is, people can try to reverse engineer
> > the process CentOS is using, but they may never be sure it's like what
> > CentOS did. So your statement is incorrect.
>
> I am not sure how to say this any other way, its been said many times
> over and over again : we dont use any super magic juice anywhere, its
> mostly just mock in a for loop. Lets assume that there still exists some
> fear and doubt somewhere about the process in exact terms.
>
> then lets take up the conversation on list where I said that once 6 is
> our of the door, I'll document what and how things worked for the build
> process ( including the pause's and why they took place. Would that
> remove some of this FUD layers ?

A good start for this is available at
http://www.scientificlinux.org/distributions/6x/build/

Some further bits are also available in bugzilla reports at redhat.com,
so this should really be updated to reflectthe complete data, also from
the CentOS project.

>
> > Hence my joke that the 'C' in CentOS actually means Closed.
>
> I dont agree, if you said 'C' in CentOS is mispelled 'Slower than
> ideal', I'd agree
>
> > That said, if CentOS wants it this way they sure have every right to do it
> > like this. But it would be nice to state that upfront.
>
> Propose a wording snippet ?


Having the discussion on how to move between Closed / Slow / Community
is hopefully a good sign for the project. It hurts that rebuilding parts
of e.g. 5.6 is so easy and we seem to spoil any efford to combine forces
for a quick rebuild that also builds up more and more knowledge for a solid
rebuild...

best regards,

Florian La Roche

_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel

On Sun, Feb 20, 2011 at 04:52:47PM -0500, R P Herrold wrote:
> On Sun, 20 Feb 2011, Jeff Johnson wrote:
>
> > CentOS may have lost 1 of its vendor-sec representatioves,
> > but its a role that can be re-filled.
>
> Not sure what is meant there, but the vendor-sec process has
> been relatively quiet of late. Some updates ... thinking here
> of the recent OpenJDK set ... never passed on that list as to
> a co-ordinated release date. The real problem in CentOS'
> presence there is that as the project intentionally 'chases
> the tail-lights' to follow the upstream, warts and all, we
> rarely have anything to offer in the vendor-sec list

The time to exchange on security issues is for sure much higher
than the efford to recompile rpms again for CentOS.

I think having CentOS presence there is still the right thing
as the whole point of vendor-sec is to build a small group where
information is shared, knowing that most people more read from this
than actually contribute.

best regards,

Florian La Roche

_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel

On Wed, 23 Feb 2011, Johnny Hughes wrote:

> On 02/23/2011 04:01 AM, Dag Wieers wrote:
>> On Tue, 22 Feb 2011, Johnny Hughes wrote:
>>
>>> I am aware, but it also is very important that we (the CentOS Project)
>>> do not change the SRPMS (or the source tar balls, or any other piece of
>>> source) for any reason except to remove trademarks and copyright info.
>>> It is the whole purpose of the CentOS Project.
>>>
>>> The bottom line is, people can figure out how to recompile the packages
>>> just like we did ... but we don't change the sources.
>>
>> No they can not. The bottom line is, people can try to reverse engineer
>> the process CentOS is using, but they may never be sure it's like what
>> CentOS did. So your statement is incorrect.
>>
>> Hence my joke that the 'C' in CentOS actually means Closed.
>>
>> That said, if CentOS wants it this way they sure have every right to do it
>> like this. But it would be nice to state that upfront.
>
-snip-
>
> You have been bellyaching about this for the entire 8 years ... for you
> now to come here and say that we should have told you up front is
> unbelievably disingenuous. You have been told this dozens of times by
> me alone.
>
> So, am I now also a bald-face liar as well as a totally incompetent
> maintainer? Haven't been told up front that we don't change sources ...
> Really, Dag ... REALLY?

Johnny, cool down and read what I said. I am not even talking about SRPMS,
you bring that up every single time. I talk about the changes to the
*process* to make packages build and binary compatible.

If it was a simple as rebuilding packages in mock, we wouldn't even be
discussing it here. A bunch of packages don't build cleanly without help,
that's what we've been talking about. (eg. all the stuff Farkas opened
bugzilla entries for)

But for me this is closed now, Karanbir promised to open those bits and I
am sure this will help the community understand and discuss how we can
open the process for a next release.

I wouldn't mind maintaining a list of questions/answers on the wiki,
since I have plenty of those that could shed a light on the process.

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

[Any errors in spelling, tact or fact are transmission errors]
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel

On Wed, 23 Feb 2011, Karanbir Singh wrote:

> On 02/23/2011 10:01 AM, Dag Wieers wrote:
>> No they can not. The bottom line is, people can try to reverse engineer
>> the process CentOS is using, but they may never be sure it's like what
>> CentOS did. So your statement is incorrect.
>
> I am not sure how to say this any other way, its been said many times
> over and over again : we dont use any super magic juice anywhere, its
> mostly just mock in a for loop. Lets assume that there still exists some
> fear and doubt somewhere about the process in exact terms.

The modifications (of the buildsystem/process) per package is the magic
juice.

Again I don't mind if that's the case, but if there's a reason it takes
weeks/months for a release to go into QA, then obviously it doesn't all
build fine in mock.


> then lets take up the conversation on list where I said that once 6 is
> our of the door, I'll document what and how things worked for the build
> process ( including the pause's and why they took place. Would that
> remove some of this FUD layers ?

That would be great. The upside of having all releases in a small
timeframe is that there's more time in between releases ! I don't think
it's about FUD, fact is that people don't understand why it takes so long
and don't understand why they cannot helps speed up the process.

On the other hand some of the developers blame the ignorance of users, so
a clear and transparent process may bring more people up to a higher level
to understand and make better suggestions.


>> Hence my joke that the 'C' in CentOS actually means Closed.
>
> I dont agree, if you said 'C' in CentOS is mispelled 'Slower than
> ideal', I'd agree

Of course, it's not completely closed. Looking in a thesaurus, the only
thing coming close to 'Slow' in there that starts with a C is Constipated
;-)


>> That said, if CentOS wants it this way they sure have every right to do it
>> like this. But it would be nice to state that upfront.
>
> Propose a wording snippet ?

Well, as you promised to open it up after the release, there's no reason
to debate it now. Maybe some of the content of the presentation
(pros/cons) should be on the wiki in an About section, it would at least
change what people expected.

I think the biggest problem is that people expect something else than what
is implied, delivered and/or promised, maybe because in the past releases
were quicker, or communication was different, or because one simply
expects that more is being automated and hence releases are quicker.

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

[Any errors in spelling, tact or fact are transmission errors]
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel

On Wed, Feb 23, 2011 at 7:59 AM, Dag Wieers <dag@wieers.com> wrote:

>>> Hence my joke that the 'C' in CentOS actually means Closed.
>>
>> I dont agree, if you said 'C' in CentOS is mispelled 'Slower than
>> ideal', I'd agree
>
> Of course, it's not completely closed. Looking in a thesaurus, the only
> thing coming close to 'Slow' in there that starts with a C is Constipated
> ;-)

Congealed?

>>> That said, if CentOS wants it this way they sure have every right to do it
>>> like this. But it would be nice to state that upfront.
>>
>> Propose a wording snippet ?
>
> Well, as you promised to open it up after the release, there's no reason
> to debate it now. Maybe some of the content of the presentation
> (pros/cons) should be on the wiki in an About section, it would at least
> change what people expected.
>
> I think the biggest problem is that people expect something else than what
> is implied, delivered and/or promised, maybe because in the past releases
> were quicker, or communication was different, or because one simply
> expects that more is being automated and hence releases are quicker.

For example, I'd appreciate a hint as to which version of mock you're
using. I'd previously suggested upgrading from the CentOS 5 one, but
the latest epel-testing one is giving me problems and spewing errors
when I try to compile *anything*. The epel default one works, but is
relatively slow due to mishandling of bulky and unnecessary files such
as /var/log/lastlog in the cached tarballs.

The one from RPMforge seems to be working well. (Thanks, Dag and your
comrades over at RPMforge!!!!)
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel