I'm forking this thread from -core, so we can have some useful
discussion about the idea, and then somebody can take it to the
This needs a lot more polishing still, and I'm not happy with some of
the semantics (esp. "policy" is too harsh a word for what we are trying
Metadata.xml should allow use of a <changepolicies> element. Within the
element, package maintainers should be able to describe how
non-maintainer changes to the package are handled.
The changepolicy element should contain zero or more <change> elements,
each of which present a tuple of the type of change ("type" attribute)
and the policy ("policy" attribute) for that type.
TODO: I'm not sure what we'd put into some of these type at this point.
One dimension of split would be things that require a revbump vs. those
that don't. trivial-version-bump is probably the easiest one to handle,
simply copying the ebuild with changes to HOMEPAGE/SRC_URI/KEYWORDS.
- file-bug: A bug (ideally with patch) should be filed only.
- review-requested: Discuss the change with a maintainer via ANY means,
get a +1 for it, and then you can commit it.
- notify: Do the change AND notify the maintainer.
- allowed: Do the change, no notification required.
TODO: I can see a lot of value in motivating developers by declaring the
defaults for change policies shall be that all types are "notify".
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : email@example.com
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85