Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On Sep 29, 2015, at 12:26 PM, Sandro Tosi wrote:
>Once again, the python policy about Maintainer/Uploaders has been ignored
>
>either policy changes or this has to stop at some point.
A few observations.
The policy should perhaps be better promoted or more explicitly written. The
links you provided are useful, but I wonder whether they are easily
overlooked, forgotten, or misinterpreted.
Policy doesn't really spell out the operational differences for when the team
is Maintainer vs. Uploader, and the wiki page explicitly says it's an
*unwritten* policy (despite the fact that putting it in the wiki probably
qualifies as "written" :). How should the change be acknowledged by the
maintainer? Should I Cc the mailing list when I contact the maintainer? Is
it okay to commit to vcs but not upload? How long do you wait for feedback
before you can do the upload?
(Aside: git! I would love to be able to commit and push a branch and then ask
for the maintainer to review, merge, and upload - or give me the green light
to go ahead.)
Should we have some automated tools to help out here? I'm not sure where to
hook in such a tool, but if for example when I build a source package, I got a
nice little lintian-like warning saying "The package is team uploadable but
not team maintained, did you give the maintainer time to respond to your
issue?" Something like that would go a long way toward mitigating accidental
or careless toe-stepping.
Do all team members understand the implications when they set the two fields?
Some maintainers may not really care and may have been less conscientious
about setting the fields.
The wiki says that the general rule of thumb is to set the team as Maintainer,
to which I agree. I may not have been as deliberate about my own packages, so
I plan on reviewing them, and will fix any that aren't "special".
Cheers,
-Barry
Reply to: