Re: BTS cleaning, seconded patches, and conversion of the Policy to DocBook.

[Jonathan Nieder <jrnieder@gmail.com>]

Hi Charles,

Charles Plessy wrote:

> I am reading http://wiki.debian.org/PolicyChangesProcess and
> http://wiki.debian.org/Teams/Policy to see how I can help to go forward with
> the Policy bugs.  Not only for the patches that I sent in 2010 and 2011, but
> more in general for all the patches that are potentially ready for an
> inclusion.
>
> One of my motivations is that I promised to help to convert the Policy to
> DocBook, and that it looks more efficient to apply the pending patches before
> the conversion, rather than rewrite them.

Thanks much for this!  I started working through old bugs and am
ashamed to have dropped the ball a bit --- in particular, your patch
to add the machine-readable copyright format probably could use some
reviewing.

> I read on the wiki that:
>
>   “The Policy delegates are responsible for managing the tags on bugs and will
>   update tags as new bugs are submitted or as activity happens on bugs. All
>   Debian Developers should feel free to add the seconded tag as described below.
>   Other tags should be changed with the coordination of the Policy Team.”

Hmm, that text seems lousy.  For example, I am not a Debian Developer,
but I never had the impression that correctly documenting when a bug
has the right number of seconds is unwelcome.

Would anyone mind if that paragraph is replaced with something along
these lines?

    “The Policy delegates are responsible for managing the tabs on bugs and will
    update tags as new bugs are submitted or as activity happens on bugs. Others
    should feel free to help out, especially by adding the seconded tag as
    described below, but only the Policy delegates can mark a change as accepted
    (pending) or rejected (wontfix).”

> Shall I for instance send a proposed BTS command and ask for approval here ?
>
> Also, I was wondering what is the most convenient: patches or Git branches ?
> Would it make sense to have a clone in collab-maint ?

As far as I can tell, what Russ has been doing is to maintain a branch
for each policy bug he has proposed text for, and to send the output
of "git diff master...bugnnnn-rra" to the BTS when seeking review.

Perhaps you could maintain a debian-policy clone in ~/public_git on
Alioth?  I would certainly find that convenient to work with (and less
confusing than one repo in dbnpolicy and another in collab-maint).

I also do not know what conventions are used by the central policy
repo itself --- do non-delegates ever maintain branches there?

Hope that helps,
Jonathan