[CentOS-devel] Updates from today

On Thu, Mar 10, 2011 at 7:18 PM, Johnny Hughes <johnny at centos.org> wrote:

> Why do you keep talking about a SCM system.  Everything you want to know
> is in the SRPMS.  If you want to create a git repo of them, have at it.
>  You like SVN better, use it.  CVS your thing, use that.  Look for
> .centos files and pull them in (that and the kernel is all we change).
>
> I work with SRPMS, not with an SCM system.  I like SRPMS, they are a SCM
> system of their own.

Because they're really not. Patches can be altered, and .spec files
altered, without any logging or notification of the change. Release
numbers and revision numbers are hard-coded, not trackable.

> We do not change what upstream has in their SRPMS (except when we have
> to) ... we don't even unpack them unless we need to change them.  We
> submit them to mock to build.  Every patch we create, every change we
> make, it is in the SRPM.

That's..... a pretty odd approach. Not inconceivable, but *exactly*
the sort of informaiton not in the "do it yourself, it's easy"
approach.

> Why is this so hard to understand?

Because it's amazingly poor software management. SRPM's are binaries
and make change tracking quite awkward, and rely entirely on the
developer to consistently report changes in the %changelog.
That's..... really awkward.

> If we were maintaining changes in 2500 SRPMS per distribution (times 3
> or 4 distributions), we would do it in an SCM program, but since we just
> BUILD the vast majority of these packages without changes, maintaining
> an SCM of 10,000 packages when we change less than 1% of them does not
> make much sense.

No, no, you'd just SCM the ones  you alter, and the build system
(which needed design to provide a bootstrappable environment.)

> You have the SRPMS, you have example config files, you have the mock
> that we use, you have the script that we build the software tree with,
> you have the file that we use to compare RPMs with upstream.  Those are
> what we use.
>
>> I've really been hoping for public access to the build structure. "You
>> can do it yourself" is not as helpful as the kind of public access to
>> build structures that Dag publishes, and has been suggesting.
>
> The build structure is NOT necessarily a public machine.  The machines
> that get built on do not necessarily belong to CentOS.  My company, for
> example, provides some resources that I build on.  You can not have
> access to my company's internal network or their machines.

Excuse me, I didn't say it should be. But access to the /etc/mock
files, *in the SCM I just described*, would be helpful.

> Dag changes SRPMS and source code ... we rebuild someone else's source
> code.  That is why we don't maintain an SCM.

But you do change them! By your own admission above, you've altered
100 packages. That's plenty to justify an SCM.