>You are correct its not my process, but I am still curious as to the
>rationale which is just a question that was not answered. Nowhere did I
>suggest, or imply, that it should be changed.
>
>And how do you define crappier releases? If something is stable enough
>that the development team decide to mark a release that is up to them,
>not you which is similar to what you noted about this being *your*
>process, that is *theirs*.
Wow you sure are opinionated.
We as a team make releases every 6 months like clockwork.
Anything else is none of your business. Your line of commentary is
showing a distinct lack of respect, and I kindly propose you get
stuffed.
>Edward Lopez-Acosta
>
>On 4/5/19 7:08 AM, Theo de Raadt wrote:
>>> Could you please explain the logic behind this as I am confused. Is this
>>> due to an inefficient process, technical limitation, or other reason
>>> (lack of manpower doesn't qualify as that seems self inflicted by the
>>> project)? Are you somehow tracking submissions to take care of when this
>>> unlocked so people don't waste their time needing to resubmit them?
>>
>> Our process. *OUR* process. This is not your process. Meaning it
>> isn't your decision.
>>
>>> While they may exist I know of no other project, including OS, that halt
>>> development like this for long, if at all, to do a release. Again, they
>>> may exist I just don't know of any and find the process awkward and
>>> confusing.
>>
>> Other projects split their developers between "making the release" and
>> "working on the future", and as a result they take a long time to make
>> crappier releases.
>>
>> That's their choice.
>>
>> It is not our choice.
>>
>> It is *NOT YOUR CHOICE*, and you don't have standing to comment.
>>
>
No comments:
Post a Comment