Re: [gentoo-dev] Some ideas on how to reduce territoriality

[Luis Francisco Araujo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chris Gianelloni wrote:
> More and more, I am finding developers who are afraid to touch packages
> for even minor things if they're not the maintainer.  This is a sad
> state of affairs and not the reason we have maintainers.  We have
> maintainers to assure that a package is being taken care of, not to
> establish some kind of "territory" over that package.  Because of this
> misconception, I would like to come up with and document a listing of
> things that any ebuild developer can feel free to do to any package
> *without* maintainer consent.  These are generally all minor things, but
> things that I think are important.  I'm going to list off the things
> that I can think of, and encourage everyone else to speak up if I've
> missed something.
>
> - HOMEPAGE changes
> - LICENSE changes
> - arch-specific patches/dependencies - If someone is requesting KEYWORD
> changes on a package and it requires a patch or additional dependencies
> for your architecture, you are not only permitted, but really are
> required to make the necessary changes to add support for your
> architecture.

I am not sure about this last one ... what if for example this patch is
only for supporting a special option of the package for that
architecture, but the maintainer of the package found out that such a
patch is unnecessary and/or will cause other kind of problems in the
package, therefore preferring avoiding such a patch ... or he just
wouldn't like to apply the patch for X or Y; or even further, he just
wouldn't like to have such a package available for that architecture
just yet for Z or W.

> - Typo fixes
> - SRC_URI changes - If the source has moved, feel free to fix it.  We
> shouldn't have to wait on the maintainer to fix something this simple.
> - *DEPEND changes due to changes in your packages - If a package that
> you maintain moves, splits, or otherwise changes in a manner that
> requires dependency changes on any other packages in the tree, you
> should make those changes yourself.  You're free to ask for assistance,
> of course, but you have the power to make the changes yourself without
> asking permission.  After all, you're the one "breaking" the package, so
> you should be the one to "fix" it.
> - Manifest/digest fixes
> - metadata.xml changes
>
> There's a couple more that I wouldn't mind seeing as things developers
> can do without the maintainer, but I can see how these might be a bit
> more controversial, so I'm asking for input.
>
> - Version bumps where the only requirement is to "cp" the ebuild
> - (for arch teams) Stabilization of new revisions of an already stable
> package - An example of this would be being able to stabilize foo-1.0-r2
> if foo-1.0 (or foo-1.0-r1) is already stable, but not if only foo-0.9 is
> stable.
>

I think these two cases should still be handled by the herd or
maintainer of the package.

The stabilization idea sounds good and it could free maintainers from
filing similar bugs over and over ; but wouldn't this be more and harder
work for arch teams?. For example, they should carefully track the
history of all the packages to know when and if they should stabilize it
yet.

> So, what do you guys think?
>

The other list of things look fine and safe to be changed by any maintainer.

Regards,

- --

Luis F. Araujo "araujo at gentoo.org"
Gentoo Linux

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

iD8DBQFGs9KfBCmRZan6aegRAtK7AJ94CDovLQu51QmZy6TW69rMK4Tz1QCgm3C9
tKDsHyNAWsliFCx0MMzcIpA=
=RGhM
-----END PGP SIGNATURE-----
-- 
gentoo-dev@g.o mailing list