[CentOS] How to Contribute to CentOS was: CentOS Project Infrastructure

Axel Thimm Axel.Thimm at ATrpms.net
Mon Aug 10 21:12:56 UTC 2009


On Mon, Aug 10, 2009 at 04:04:10AM -0500, Johnny Hughes wrote:
> Axel Thimm wrote:
> > On Sat, Aug 08, 2009 at 06:52:09AM -0400, R P Herrold wrote:
> >> Here as well, we differ -- CentOS at its core is about boring, and
> >> stable and conservative as a core value.  You are in the wrong place
> >> if you think otherwise.  It makes a fine BASE to build on, as Dag's
> >> archive has long demonstrated, but there is NOT a good fit for a
> >> beginner to start doing invasive changes to get 'the latest and
> >> greatest' to compile.  That is the 'rap' as to Axel's archive, and
> >> why people end up frustrated using it and moan and groan about their
> >> ignorance and NOT READING our clear warnings on the wiki's
> >> Repositories page
> > 
> > I'm not sure I understand correctly, does that mean that you imply
> > ATrpms is doing invasive changes to CentOS/RHEL and people using it
> > end up frustrated while ATrpms is showing ignorance towards them?
> 
> I don't want to speak for Russ here, but what I think he means is that
> ATrpms allows things to be added to CentOS/RHEL that require a lot more
> attention because of the parts the core OS some things replace,
> especially things outside the Stable branch.

Actually all bits that would replace RHEL/CentOS even if rock
solid/stable have been moved out of the stable branch to allow CentOS
to claim that ATrpms *stable* is not replacing any CentOS parts.

I agree that the name "testing" is being badly abused at ATrpms for
harboring "package-that-replace-vendor-packages", at least for the
RHEL/CentOS/SL packages.

> Personally, I don't think this is unexpected, as ATrpms also adds lots
> of functionality ... much like our CentOS Plus repos.
> 
> So there is much flexibility (a good thing), but also the possibility to
> break your install if you don't know what you are doing.

Nobody should even blindly enable (sub)repos that are labeled
"testing" or "bleeding". Even though even for CentOS the "testing"
repo would be rather stable, people should feel intimidated not to
taint their systems with "testing" w/o asking first. I do get a lot of
queries of why for example the dovecot packages are marked "testing"
for that long although they have proven very stable over several
years.

> Of course, this is also very true of the CentOS Plus repo too ... if you
> add everything willie nillie, then it can also cause issues.

Everything I think ATrpms could potentially break lands in "bleeding",
and especially for RHEL/CentOS/SL takes a while to be granted testing
or even stable status.

I really don't get much negative input from RHEL/CentOS folks due to
that. I usually only get complians of "the latest RHEL/CentOS kernel
has no blah-kmdl support, why?" when usually the kernel changes from
5.x to 5.x+1 break the kernel module builds.

> Certainly I think ATrpms is a great resource and I use it where I need
> it.  I would recommend caution where things outside the Stable branch
> are used (just like I recommend for CentOS Plus or the CentOS Testing
> repos).

On Mon, Aug 10, 2009 at 01:05:55PM -0400, R P Herrold wrote:
> I attribute no bad intent or action to you, nor ATrpms, and indeed
> both have mirrored your SRPMs, and build and use from it and have
> for years
> 
> As my initial post pointed, some people complaining are people
> blindly mashing archives together, who will never read the clear use
> case advisories in the CentOS wiki, at your site, or anywhere else,
> so far as I can tell from experience, anyway

I think we should get rpmrepo.org running and make an end with any
motivation to mix archives on RHEL/CentOS/SL/Fedora land.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.centos.org/pipermail/centos/attachments/20090811/6b4fddb4/attachment.sig>


More information about the CentOS mailing list