-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 23/11/12 09:28 AM, Rich Freeman wrote:
> On Fri, Nov 23, 2012 at 9:15 AM, Ian Stakenvicius <[email protected]>
> wrote:
>> ..  For certain things, I think it would be very beneficial for
>> this to be true (other dev's welcome to touch) across the tree.
>> Maybe if there is enough general support for it, we should change
>> our default of "never touch a maintainer's package without
>> permission of the maintainer/herd", to "OK to touch unless
>> package metadata explicitly requests not to" ...?  And we can put
>> a tag in the metadata to indicate this (or even to indicate what
>> other dev's can and can't touch -- ie, can touch *DEPEND, can
>> bump EAPI, cannot add features, cannot bump)?
> 
> Honestly, I like the maintainer/herd system - it promotes some kind
> of consistency and accountability.  If everybody just goes poking
> at random ebuilds anytime they want to then that will tend to lead
> to chaos.
> 

I'm not suggesting to abandon that, just augment it a little.  There
are dev's that want strict do-not-touch-my-stuff control, and dev's
that don't really care.  Defining as such in metadata would keep a
persistent record.

I can think of two specific examples where this would be an advantage:

#1 - the init-script-license issue.  When I filed all of those bugs,
there were a few dev's that said to me "Do what you want to fix the
LICENSE= on your own", many others didn't but i'm guessing that didn't
mean they actually explicitly desired to control LICENSE=.  Similarly,
I have absolutely no problem at all of someone fixes LICENSE= in any
of my packages -- I set them properly as best I could and I try and
watch out for changes, but if there's someone that knows better I say
"just do it."

#2 - sub-slots and slot-operators.  Adoption of this will go a lot
faster if the maintainers of libraries had free reign to update
*DEPEND in rdeps when necessary.  Some of this already happens, but
having permission to adjust *DEPEND be explicitly listed would make it
go quicker still and not cause the inevitable arguments that it always
seems to..


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlCvivYACgkQ2ugaI38ACPCSxwEAhudOC/pqJhcDPj1LErF8C2f1
bPAYrfcdNRCnovPSS2sA/jhkGjgkPcBFIM/m4uMKq8hVmHqw5RDb86pljpJz+37P
=ihwa
-----END PGP SIGNATURE-----

Reply via email to