Clarification on requirements for a release

[Harald Sitter]

On Tue, Jul 4, 2017 at 12:01 PM, Luigi Toscano <luigi.toscano at tiscali.it> wrote:
> On Tuesday, 4 July 2017 11:55:24 CEST Harald Sitter wrote:
>> On Tue, Jul 4, 2017 at 9:41 AM, Ben Cooksley <bcooksley at kde.org> wrote:
>> > On Tue, Jul 4, 2017 at 7:20 PM, Harald Sitter <sitter at kde.org> wrote:
>> >> On Tue, Jul 4, 2017 at 2:49 AM, Ben Cooksley <bcooksley at kde.org> wrote:
>> >>> I was the one who made that decision
>> >>
>> >> Cool
>> >>
>> >> You are not my supervisor.
>> >
>> > Please bear in mind you were the one (if my memory is correct) who
>> > pushed for everyone to include *.asc signatures with every released
>> > tarball
>>
>> You mean the one I *discussed* with the plasma release manager? Then
>> *announced* our *intention* on this very mailing list inviting others
>> to follow suit. Then proceeded to argue why we need it and why we need
>> it the way we intend to do it. Then helped figure out a workflow that
>> will work for how frameworks and apps are released.
>>
>> No, I will not have this bullshit.
>>
>> Had you had a problem with how the tarball signing implementation went
>> down, then you would have been welcome to shout at me for being a
>> douchebag THEN AND THERE. You even replied to the friggin tarball
>> signing thread. You could literally have thrown in a PS: harald you
>> suck. You did not. You absolutely do not get to defend your shady
>> background rule-making crap this way.
>
> And this is not the point.

Well, it's my point. But thanks for telling me what my point needs to be.

> The point was this sentence:
> - "releasing tarballs is enough of a chore as it is."
>
> Ben described that the requirements for the release are not heavey at all, let
> me quote the part that you cut out from the answer:
>
> On Tuesday, 4 July 2017 09:41:56 CEST Ben Cooksley wrote:
>> In terms of the "chore" of releasing tarballs, the only part we
>> require is two things which aren't exactly time consuming: upload to
>> incoming, create ticket with the destination and a list of files and
>> hashes.
>
> Translated this means: the process is not complicated on the sysadmin side.
> The biggest requirement (without any judgement about it, it was just a
> description of it) is the signing process, added recently.

Yeah, taking out the trash is also not complicated, it is a chore. Had
I have to go through 100 doors to take the trash out it'd still not be
complicated it would be objectively a worse chore compared to having
to open and close a mere 2 doors.

> So I suggest to calm down, probably open up the ticket at the beginning of the
> discussion to show everyone what was written there. And calm down again, and
> re-read the code of conduct

I am sorry if I have hurt anyones feeling, but this entire thing is
crap, this thread even existing is pissing me off to no end, the
ignorance to the fact that people are making up rules is pissing me
off even more. If you can't handle me being pissed off then tell me to
shove off and I'll show myself out not looking back.

See. Had there been a thread "oi, let's fix up our playground policy"
I'd have taken all the arguments raised here and applauded them and
agreed with them and pointed out that we have never defined what
exactly constitutes a release and also no guidelines as to when a
project really ought to (or must if you will) move on from playground.
A simple checklist, another chore for sure, but one you don't have to
do continiously. Instead, here is a thread with a confused developer
who wants to release their software but got told that this ain't
happening because the software he is developing is not meant to be
released short of getting an exception (from whom? I do not know. no
one here is my or Christian's supervisor here either and we have no
central release authority). And so yeah, if you do not agree that this
is shady nonesense, I am sorry to say but I find myself in
considerable disagreement with our community here. And am quite
frankly outraged by others not being outraged by this way of policy
making.