Harmless KDE feature upgrades - yeah right

Peter Jones pjones at redhat.com
Thu Mar 4 21:43:37 UTC 2010


On 03/04/2010 04:36 PM, Adam Williamson wrote:
> On Thu, 2010-03-04 at 13:28 -0800, Adam Williamson wrote:
> 
>>> As a little gedankenexperiment, let's explore for a second a 4th option:
>>> Fedora-blessed/hosted/sponsored/whatever repos for things that we don't
>>> feel should be mandated on users, but which some users may want and some
>>> maintainers want to be able to provide. A little bit of all three -
>>> including a built-in need to be minimalist in construction, so as to
>>> avoid conflict nightmares, but at the same time freedom to say "here's
>>> a new major version of this, since we _know_ that's what you're looking
>>> for if you've got this repo enabled".
>>>
>>> Obviously this would require some tools work, but isn't it worth
>>> considering?
>>
>> What does option 4 provide over option 2?
>>
>> In fact, how is it even functionally different? 'Fedora' repositories
>> are effectively nothing more than 'blessed' repositories anyway, given
>> the considerable powers granted to maintainers.
> 
> To expand a bit, my personal opinion is that a single 'blessed'
> repository makes more sense than a framework for the provision of
> multiple 'semi-blessed' repositories; the latter provides no significant
> benefit over the former, while making it much harder to ensure adherence
> to basic guidelines, and repository coherence.

To expand a bit, that's the point - we don't necessarily have to ensure
such strict adherence to (some) guidelines or repository coherence. 
Obviously responsible maintainers/SIGs need to do so, but it isn't
necessarily something Fedora the organization needs to do for every repo
relating to every other repo.  Whereas right now, it is something we
must guarantee strongly (and haven't always done a great job of.)

> We already have systems for checking common guideline compliance
> problems and things like dependency issues within a single
> repository; we don't have tools for doing this across a bunch of
> separate quasi-independent repos.

Do you really think making repoclosure do its thing over a group of
repos instead of a single repo is a mountainous task? Yes, obviously
we'd have to change some tools. That's why I said "Obviously this would
require some tools work".

-- 
        Peter

Old MacDonald had an agricultural real-estate tax abatement.


More information about the devel mailing list