Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On 10/06/2015 11:36 PM, Piotr Ożarowski wrote:
> my point is that you could argue that your packages are better
> maintained than ours (less bug reports, wider Python 3 support,
> newest upstream releases, more popcon users, ...) but you choose the
> fact that you maintain more of them... and then admit you cannot keep
> up
You made a point that it was a do-o-cratie earlier, pointing out that
Sandro did so much, and that you did as well, so therefore you had to be
team leader (with the rights to kick anyone?). Therefore, I thought I
had to tell that I do a large chunk of Python packaging work too.
On 10/06/2015 11:36 PM, Piotr Ożarowski wrote:
>> You forced everyone to keep using SVN even after a vote for Git, and
>
> you mean I enforced our policy which clearly mentions SVN only?
You've only enforced *your own* policy, backed-up by only a small vocal
minority, taking the rule to the extreme (ie: a few days before the Git
migration, it's still not ok to start new projects using Git, according
to you...).
> at the very beginning of your membership didn't you use your own
> workflows in DPMT packages (which you later moved to OpenStack)?
I'm sorry, I (honestly) don't remember. Or are you mentioning the fact
that I had to move my packages that were under Git to another team?
Probably... Now, I've followed your orders not to use Git, General
Piotr, so why complaining again?!?
>> workflow I'm using within PKG OpenStack? Let's say that's what you are
>> referring to, then: I'm the one working on these, and (up to very
>> recently) doing it all alone, so why is this a problem to use the
>> workflow I found the most efficient?
>
> you can use whatever you want, but if you want a team to work on these as
> well you need to make it easier to contribute to other team members
> (and use what team agreed to use)
I generally agree with *guidelines*. But they should stay guidelines
only, without restricting too much freedom. Sticking with SVN (and even
complaining about the use of git-svn), because of stupid rules
enforcement, for sure, didn't help to make it easy to gather more
contributors.
>> This was for the workflow, it probably also includes tooling.
>
> yes, especially git-svn was causing pain
>
>> Would you mind telling what you are referring to?
>
> I did some work in alembic package, then you decided to move it out from
> DPMT to OpenStack (where I don't have access) and revert some of my work
> (pybuild stuff) because "you don't understand it" without asking me for
> any help.
Ah... Did it strike you that you could (and still can) apply to be a
member of PKG OpenStack? Did you ever thought that I moved it there
because you (and a small minority in this team) was forbidding the use
of git within DPMT?
As for pybuild, maybe it would help if pybuild was better documented
(yes, I am writing this even if I know the /Python/Pybuild wiki
page...). As it stands, for me, it is as much of a gray area as CDBS. It
is fine with very simple packages, but when it becomes more complicated,
I'm a bit lost with it. Probably I should have try harder, and get out
of my comfort zone.
But why are you complaining about all this just now? I don't remember
you ever did before. This leads me to think you do have a problem
talking to me, despite the fact you wrote you don't have anything
personally against me. Otherwise, you would have simply discuss the
mater with me normally, apply to PKG OpenStack, etc. I was in fact
surprised to see you never discuss anything about alembic, and I regret
I didn't attempt to fix the situation.
Last, is not using/liking pybuild a point of argumentation for this
thread? I really don't think it should. You can't and should not impose
pybuild to everyone doing Python packaging. Nor it should be mandatory
to use it within the DPMT.
Reply to: