Re: [Python-apps-commits] r9456 - in packages/pyflakes/trunk/debian (7 files)
On 25 February 2013 20:29, Sandro Tosi <sandro.tosi@gmail.com> wrote:
> On Mon, Feb 25, 2013 at 8:15 PM, Dmitrijs Ledkovs <xnox@debian.org> wrote:
>> On 25 February 2013 19:03, Sandro Tosi <sandro.tosi@gmail.com> wrote:
>>> hey, can you stop committing huge changes without asking to uploaders
>>> first? I've already contacted you when you un-coordinately upload
>>> pyflakes to experimental, ans you hadn't reply - it's time to give it
>>> a stop now
>>>
>>
>> I'm sorry for missing your previous email, due to a filtering mistake
>> on my side.
>>
>> My understanding was that package has Debian Python Team set as
>> maintainer, such that improvements and co-maintainership is welcomed.
>
> and they are, but switching python helper or introducing a new package
> are huge changes enough to require a consultation with the people that
> are responsible for the package (the uploaders), which didn't happen.
>
In my view they aren't, since -support is deprecated in the team and
many pyflakes reverse-build-dependencies are being ported to python3.
But point taken.
I'm not sure I agree with consultation "who are responsible for the
package" in the context of python-team & uploaders field usage as done
in pyflakes.
But I am fine with your interpretation, I shall consult you from now
on, when I notice you in the maintainer/uploaders/who-uploads fields.
>> Newer packages in experimental require/need/want pyflakes support
>> specifically python3 support.
>
> explicit is better than implicit: file a bug against pyflakes,
> explaining why you need a new package and what's the tool requiring it
> - that's what I'd expected.
>
ack.
>> Do you disagree with proposed changes? If yes, please comment and
>> revert relevant pieces.
>
> I'm disagreeing with the *way* you're doing such changes.
>
ok. Thanks for explaining it as well.
>> Or is this just a concern over my lack of courtesy? If you feel the
>> need to ack every commit of pyflakes, you should consider moving
>> python team to uploads and setting yourself as maintainer and/or
>> removing the package from the team all together. In either of those
>> cases, I typically file wishlist bugs with a patch attached.
>
> see above: team maintenance (even with team set to maintainer) doesn't
> mean you can do whatever changes you see fit for the moment (and them
> maybe disappear because you lost interest). small changes doesn't
> require any ack from my side; adding new bin packages or changing
> helper do.
>
Ok. I do wonder where the line of small vs not-so-small changes lies,
but I guess it will often be different on per-package specific
factors/basis.
Point taken.
Regards,
Dmitrijs.
Reply to: