On Tue, Sep 18, 2012 at 9:07 PM, Ben de Groot <yng...@gentoo.org> wrote:
> On 19 September 2012 03:18, Alec Warner <anta...@gentoo.org> wrote:
>> On Tue, Sep 18, 2012 at 12:11 PM, Ulrich Mueller <u...@gentoo.org> wrote:
>>> Readability is more important, and there I still don't buy the
>>> argument that the new syntax is better, and that any gain would
>>> outweigh the cost of changing. After all, the existing variables for
>>> dependency specification won't disappear, so devs would have to
>>> remember both.
>>
>> I agree it is a con, but is it a blocker? I mean basically any change
>> proposed requires know the old way, and the new way..that is how
>> changes work...
>
> Which is why changes need to have clear benefits that outweigh the
> costs of change. In this case the benefits are purely cosmetic, so
> they don't. Change for change' sake is not worth the effort.
>
> --
> Cheers,
>
> Ben | yngwin
> Gentoo developer
> Gentoo Qt project lead, Gentoo Wiki admin
>

I'm sorry. Are you reading the same threads that I am?

>From the other thread ("example conversion of gentoo-x86 current deps
to unified dependencies"):

> 1) This unifies the existing syntax down into a collapsed form.  In
> doing so, there are measurable gains across the board for PM
> efficiency and rsync alone.
>
> 2) In unifying the syntax via reusing our /existing fucking syntax/,
> we formalize the adhoc common dependency assignments devs already are
> doing in the tree.
>
> 3) In moving to a unified syntax, it positions us to easily introduce
> new dependency types without introducing more redundancy.  Easier to
> add new dep types, faster to add new dep types, more efficient in
> doing so in comparison to existing approaches, and done in a fashion
> that devs can reuse existing conditionals.
>
> 4) It is not exherbo's DEPENDENCIES.  Meaning it is not label based.
> Meaning you do not need to knee-jerk attack it because of some notion
> it's ciaran based/related.

I know you must have seen this (and the rest...). You've participated
in that thread.

Reply via email to