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
