What Fedora makes sucking for me - or why I am NOT Fedora

Mat Booth fedora at matbooth.co.uk
Wed Dec 10 17:06:40 UTC 2008


On Wed, Dec 10, 2008 at 4:49 PM, David Malcolm <dmalcolm at redhat.com> wrote:
> On Wed, 2008-12-10 at 08:36 -0800, Jesse Keating wrote:
>> On Tue, 2008-12-09 at 18:22 -0600, Les Mikesell wrote:
>> > One way or another, if I were building a distribution that wanted to
>> > simultaneously claim that it is both new code and 'tested and working',
>> > I'd try to plan in a way that it wasn't a flip of the coin on every
>> > machine which you'll get today.
>>
>> Now here's a crazy idea, that nobody seems to want to follow:
>>
>> Treat rawhide as your 'new code' land, leave the release trees as your
>> 'testing and working' code.  That is don't be so goddamn eager to push
>> new packages and new upstream releases to every freaking branch in
>> existence.
>>
>> Of course, when I make suggestions like these, I become extremely
>> unpopular.
>
> I've only partly followed this discussion, but one simple implementation
> idea, if this hasn't been thought of/implemented:
> - have bodhi detect if the version part of the NVR is being changed; if
> so, raise the karma level needed to push the package.
>

There is nothing to stop breaking changes sneaking into revision bumps
only. Especially when the package is a source control snapshot of some
future version. Version numbers mean different things to different
upstream projects anyway, so I don't think anybody (anybodhi?) here
should be defining what a version bump signifies.


> Rationale: it's my belief that a rebase to a different upstream version
> typically carries greater risk of destabilization than targeted
> patching.  Thus, a bump to a more recent upstream should receive more
> testing than a packaging/patch change.
>
>
> Hope this helps
> Dave
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



-- 
Mat Booth
www.matbooth.co.uk




More information about the devel mailing list