On Mon, Sep 12, 2011 at 11:26 AM, Alex Hudson <fedora@xxxxxxxxxxxxxx> wrote:
> I view this as entirely equivalent to having a rule about not breaking
> trunk in version control: I don't know anyone who seriously argues that
> breaking a project compile is a good thing. Breaking the OS should be
> culturally identical - that it's a "development branch" or whatever is
> totally irrelevant.
I'm afraid this just doesn't work at this scale. It works very well
in a small project with a good test suite - where everyone commits to
the master branch (directly or by merging) and the responsibility to
"not break stuff" is well-defined by "test suite passes". We can't do
this in rawhide for three reasons:
* We don't have a good test suite for the whole system
* Even if we had one, it would take too long (days) to run.
* In rawhide, there is no single master branch. In git terms, every
package is a feature branch of the project and the master branch is
automatically created at the time of the compose by merging from all
feature branches - in other words, only a program, not a person,
commits to the master branch. We can't yell at a program for doing
the merge...
So yes, rawhide will be broken. We might hope for a future in which
individual broken packages will not be committed into rawhide, but
incompatible changes that affect other packages can't be avoided.
And as for individual broken packages... That can only be helped by
automated tests - that are thorough enough, but at the same time quick
enough that maintainers won't try to avoid them. The sad truth is
that many upstreams don't have such tests, and writing them is much
more than what Fedora can ask from its package maintainers.
Mirek
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
