Stefano Zacchiroli <[email protected]> writes: > I totally agree with you, Antonio. And I do *not* mean to imply that > moving the spec under the debian-policy umbrella equates to *freezing* > the spec. For me it is just an attempt to have the spec in a place that > is more tool-neutral, and where we can actually edit stuff (once a DEP > gets ACCEPTED, it ceases to be such a place).
> But you're right that we should better clarify what would be the editing > process for sub-policies that get integrated into the debian-policy > package. > Can someone, maybe with past experience on other sub-policies (e.g. the > perl one), comment on what are the recommended work-flows for > maintaining sub-policies under the debian-policy umbrella? I'm personally fairly unhappy with the degree to which things tend to stagnate in Policy-land. In the past, adopted sub-policies have used the same criteria as Policy itself, but I think it would be very interesting as an experiment to adopt a sub-policy, give the relevant maintainers direct commit access to the Policy repository, and let them maintain it however they see fit. I think it would be good for Debian if, in the long run, all the various sub-policies were collected together in one place. (I'm thinking here of the Python policy, the Emacs policy, and so forth.) However, I don't think they should all use the same editing criteria, and I think that's been a barrier in achieving this goal. I'd rather see there be dedicated maintenance teams for the sub-policies that use the criteria that makes sense for their area of expertise, all of whom have direct Git commit access to the Policy repository for that purpose. -- Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/[email protected]
