CentOS - Jun 2017 - test builds on private server updates (kernel)

Sorry Hughes,

got some questions. 

I have the feeling that I do a lot wrong. Today I sent a mailing post
at fedora where it is also about btrfs under fedora.

In time when i write the mail i forward it my patch for fedora 25
pretransaction & snapper.yp, with the hope of feedback.

https://lists.fedoraproject.org/archives/list/devel at lists.fedoraproject
.org/thread/NLFYHW3IEJHSFBUOEAVHDHBVTL7TOHYZ/

Sometimes I don't know where to push the information.

on https://copr.fedorainfracloud.org/coprs/andybe/CentOS7Python34/

I release a ticket because snapper gui do not build on there repo.
Local with mock or without it never fails. No response.

Since yesterday learned how to use snapper against the dbus api. What
is the better way in my opinion. After some rest i will do it first on
centos and it back into fedora "dnf" later on.

It looks to me as if in a Fedora release little movement. If someone
wants to upgrade something you simply move it there gladly times on the
next release. This generates a high unwilling something at all a
working release to submit an improvement. This is a lot better under
Centos, although Redhat is very slow with its update cycles.

Too bad the feedback is not as good as under Centos.

In principal there are to many ways to push errors or improvments on
each (centos, redhat, fedora) distros.

Or am I doing something wrong. Is there anything I can do better?

It is hopefully not that I care 3 various Linux (This time
Arch/Manjaro, Fedora, Centos). It helps to get ideas.

Thanks for advice.

Sincerely

Andy

On 06/26/2017 02:02 PM, Andreas Benzler wrote:
> Sorry Hughes,
> 
> got some questions. 
> 
> I have the feeling that I do a lot wrong. Today I sent a mailing post
> at fedora where it is also about btrfs under fedora.
> 
> In time when i write the mail i forward it my patch for fedora 25
> pretransaction & snapper.yp, with the hope of feedback.
> 
> https://lists.fedoraproject.org/archives/list/devel at lists.fedoraproject
> .org/thread/NLFYHW3IEJHSFBUOEAVHDHBVTL7TOHYZ/
> 
> Sometimes I don't know where to push the information.
> 
> on https://copr.fedorainfracloud.org/coprs/andybe/CentOS7Python34/
> 
> I release a ticket because snapper gui do not build on there repo.
> Local with mock or without it never fails. No response.
> 
> Since yesterday learned how to use snapper against the dbus api. What
> is the better way in my opinion. After some rest i will do it first on
> centos and it back into fedora "dnf" later on.
> 
> It looks to me as if in a Fedora release little movement. If someone
> wants to upgrade something you simply move it there gladly times on the
> next release. This generates a high unwilling something at all a
> working release to submit an improvement. This is a lot better under
> Centos, although Redhat is very slow with its update cycles.
> 
> Too bad the feedback is not as good as under Centos.
> 
> In principal there are to many ways to push errors or improvments on
> each (centos, redhat, fedora) distros.
> 
> Or am I doing something wrong. Is there anything I can do better?
> 
> It is hopefully not that I care 3 various Linux (This time
> Arch/Manjaro, Fedora, Centos). It helps to get ideas.
> 
Well .. CentOS Linux (The os/, cr/ , fasttrack/ , and updates/ repos)
are exact rebuilds of upstream RHEL source code with only branding
changes.  We do no technical changes to this sorce code at all.  We
build it .. end of story.

If something does not work in CentOS Linux and it also does not work in
RHEL .. then great.  We want CentOS Linux to work exactly that way .. so
we will NOT make technical changes to get it to work in CentOS Linux.
The only exception:  if the CentOS team introduced a bug in our rebuild
that is not present in RHEL source code, we will not fix it.  That is
just what CentOS Linux is.

If you want to get something fixed in CentOS that is also broken in
RHEL, you must submit the changes to Red Hat via either the Fedora or
RHEL bug processes.  Once those changes are in released into RHEL (and
therefore into the public RHEL source code) they will rolled into CentOS
Linux.

For other CentOS repositories where we actually manage the content and
DO make technical changes (extras/ , centosplus/ any of the SIG repos,
etc), you can submit changes to CentOS to get things fixed.

Hopefully this clears up what CentOS Linux is defined as and why we
don't make technical changes.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.centos.org/pipermail/centos/attachments/20170627/d4b26b9d/attachment-0001.sig>

On 06/27/2017 11:06 AM, Johnny Hughes wrote:
> The only exception:  if the CentOS team introduced a bug in our rebuild
> that is not present in RHEL source code, we will not fix it.  That is
> just what CentOS Linux is.
I obviously meant if we introduced the issue, and it is NOT an issue in
RHEL, we WILL fix it :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.centos.org/pipermail/centos/attachments/20170627/518e58b4/attachment-0001.sig>