[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Basics of packaging with the new workflow



On Sat, Feb 29, 2020 at 6:35 AM Dmitry Smirnov <onlyjob@debian.org> wrote:
>
> On Friday, 28 February 2020 3:24:50 AM AEDT Martina Ferrari wrote:
> > Dmitry has been refusing to accept the team's agreements for as long as
> > we have been discussing about it, and so far I have never seen him
> > contribute anything more than "I don't like it" to the discussion.
>
> I want to explain why even "I don't like it" should be enough without any
> further details.
>
> We may be using different tools, approaches, methodology and having our own
> preferences. Pragmatic or ideological. We don't have to agree on how to do
> things in order to respect each others work.
>
> There is no problem if you produce meaningful _recommendations_ and let the
> new team policy to win hearts and minds of maintainers who might eventually
> be convinced of its superiority, if it is really that good.
>
> But when you try to _demand_ everyone to comply with your policy, accuse them
> for non-compliance and use coercive rhetoric like "we've already decided
> everything without you", it creates unwelcoming and hostile environment.
>
> In the spirit of diversity statement we can and should appreciate our
> differences as it is the very principle that is largely responsible for
> Debian success. "One workflow fits all" is a naive approach so let's not
> force it for whatever reason.
>

I share some packaging preference with you, for example, I like
1. keep only debian directory in debian branch
2. not choose dep14 layout

But I only apply these in my own packages, more specifically in
salsa.d.o/zhsj namespace.

I acknowledge that it's hard to reach consensus for a big team like pkg-go.
But when I do work inside the team, I want to follow a simple
workflow, not with lots of options.

Because when I put the package in the team, I want others can team
upload when I'm not available.
I don't want others to take time to figure out what I preferred.
If they can read a single workflow guidance to fix my packages, I
would be happy not to follow my own preference.

-- 
Shengjing Zhu


Reply to: