Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
Hi,
Le mardi 29 sept. 2015 à 09:48:16 (-0400), Barry Warsaw a écrit :
> 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?
I'm just a DM, but I'm still in the team, so I think I can state my
opinion, and explain how I would do things.
First thing, report a bug on the package (request for a new version, for
example). Wait. Provide patches. Wait.
Second, contact the maintainer off list&bug. Wait.
Third, contact the list and put the maintainer in CC, stating that
things don't get further fast enough and you would like the team to get
involved. Wait.
Fourth, if the maintainer hasn't answered, then proceed with an RFS or
upload (depending on whether one is DD or DM).
> (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.)
I create all my packages in git -- that's what the debian-science team
uses. And I consider the fact that a package is subversion-maintained a
hindrance.
> 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.
Oh dear, another lintian output to bother me! And don't call that a
"warning", some sensitive people prefer the word "tag" :-P
> 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.
I definitely didn't really understand the implications. I put the DPMT
as maintainer and myself as uploader because :
- I want lintian not to bug me about NMU ;
- I want to make clear I won't consider people are stepping on my toes if
they start helping with a package.
Cheers,
Snark on #debian-python
Reply to: