Clarification on requirements for a release

Tue Jul 4 15:01:31 UTC 2017

Hi all,

I would like everybody to take a step back and relax. There is no point 
in ripping our heads over it.

I'm quite sure that everybody here only wants the best for KDE, 
sometimes this is conflicting.

@sysadmins: I understand that you need policies and rules on how to 
handle things. But please understand that you are not the ones doing the 
rules. If you see something missing like the fact that applications are 
releasing out from playground, please raise a discussion on the 
community mailing list, let the community agree on it and then codify 
the rule at a place where it can be found by the devs. In this case 
application life cylce management might be the appropriate one.

As the rule you implied does not exist yet, I would like to ask you to  
no longer apply it and instead participate in the thread Johnathan 
started on the community mailing list.

Thanks all for calming down in advance :-)

Cheers
Martin

Am 2017-07-04 15:04, schrieb Harald Sitter:
> On Tue, Jul 4, 2017 at 1:45 PM, Luigi Toscano 
> <luigi.toscano at tiscali.it> wrote:
>> On Tuesday, 4 July 2017 12:29:14 CEST Harald Sitter wrote:
>>> 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.
>> 
>> What I wanted to say is that
>> 
>> 
>>> 
>>> > 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.
>> 
>> The analogy is incorrect and does not answer the questions: what are 
>> the
>> complicated steps that the policy would make it more complicated?
>> 
>>> 
>>> > 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.
>> 
>> I can totally handle you being pissed off. But you stepped out of the 
>> lines of
>> the code of conduct in your email.
> 
> How's that?
> 
>>> 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.
>> 
>> The existing policy does not say that you can't release from 
>> playground. The
>> existing policy says that you should use playground for the initial
>> development, and when you start feeling like having a stable release, 
>> you are
>> not playground material anymore. I find this perfectly fine.
> 
> I agree. I didn't imply the current policy disallows releases from
> playground. Ben did that.
> 
>> Regarding the specific problem, I think (if we can open the ticket to 
>> the
>> public it would be better) that Ben read the policy incorrectly in 
>> this case.
>> End of the line, assume good intentions. The tone of the ticket was 
>> pretty
>> plain.
> 
> Assume? What?
> 
> "I was the one who made that decision, and it was done because there
> were quite a few projects who had been making releases from playground
> for well over a year." said Ben himself.
> 
> That's not mis-reading the policy, that's establishing the rule that
> if you have been releasing for a year you need to get out of
> playground or get exceptions to get your tarballs published. In my
> original reply I've said this claim is bullshit, I since perused the
> policy again. The claim continues to be bullshit. And as per the quote
> above the bullshitting was intentional. Well-intentioned, I am sure,
> but bullshit none the less. As I've said, had this been brought up for
> discussion or heck even RFC I'd be in agreement that after a while
> there should be a subtle (or not so subtle) reminder that playground
> is not meant for stable software and one should review the stability
> of one's software and maybe move it. The intention is not what I take
> issue with. The establishment of rules and threatening to hold
> tarballs hostage behind our backs is.
> 
>> So, what do you find it incorrect in the current policy; not what 
>> happened to
>> the bug, where I think the policy was read incorrectly, but in the 
>> policy
>> itself? Do you think that stable from playground? Do you want to make 
>> sure
>> that people read it correctly, as it?
> 
> If I was to bring improvements up I'd argue that there needs to be a
> reasonable metric for maturity such as the outline of a checklist, as
> I've mentioned, that helps devs decide when they need to get out of
> playground. To the creator the software rarely ever is good enough,
> which I imagine is why projects tend to stay too long in playground to
> begin with.
> 
> HS