>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. >> >
