but we know you are not just a "user" so i specifically chosen to get an answer from you.
here is the subtle point.
Your point is not subtle. Look up the definition of subtle.
if there is a RC available next week with unchanged code viewable (consensus AND LOCAL) available for a weeks prior.
should there be a 12 month coding delay just so that the opposition can code something equivalent.
then after 12 months. get to 95%. and then after 95% have 6 months grace
even when the code has been viewable weeks before RC release 18 months earlier then when you finally want it activated.
give yourself an answer and hold that answer and dont change it.
The opposition? As in Classic and BU? Or do you mean other wallets like Armory and Electrum?
Either way, no, that time frame is way too long, for both hard and soft forks. Technology moves quickly, that timeframe is much too long.
If we assume that the changes were implemented and the only time that those changes were seen are after the release has been made, I would say that 1 month is probably sufficient to fully implement and test a large code change such as segwit assuming that the released version of the reference implementation has no major bugs, is well documented, and the devs actively answer questions and comments (which means that they extensively tested the change prior to the release).
With the code available beforehand but still somewhat WIP (as with the case of segwit where the vast majority of the code was already finalized and merged with just some local stuff that was being changed), then I would say that 2 weeks are sufficient. This is because the devs can work on their implementations at the same time as or immediately after the main code change was implemented and merged. Any following changes can also be implemented relatively quickly. It is much easier to implement something when there is an existing codebase that you can reference.
A 6 month grace period is too long. I would say 4 weeks at most, 2 weeks is fine, for both hard and soft forks (keep in mind that previous soft forks except CSV have had no grace period whatsoever).
And I know you are going to say that those other devs did not test the change itself. But in actuality, they do. When they implement the change using the existing reference implementation as a reference, they are essentially doing code review on that. If they find any bugs during that review, they are reported and fixed. Those devs will also be running their own tests on their implementation of the software. If they find any issues there and it is related to the change itself and not the implementation, then those are reported too. Having the devs work on different implementation simultaneously allows for more robust code as each dev will have their own set of tests that will catch issues in the entire change itself and not just their implementation.
now then lets add an extra dimension to the question
if there is a RC available months ago with unchanged code (consensus AND LOCAL) available even before that.
blah blah same timescale 12month 95% 6 months grace
blah blah code available before RC
I don't see how that changes anything.
if the answer is no. then you will see the issue in a minute
however lets continue
if devs have not coded a diverse implementation by the time a RC is released. it is the devs own fault .. right??
Yes. However it is their choice whether to make an implementation or not.
devs should instead not give own timescales to then make their own equivalent as its deemed delaying.. but just run the RC ... right??
No. Devs should still take their time to carefully implement the changes even after the official release has already been made. This is the case for Armory because we started work on segwit a few months following the merge of the code change instead of working on it simultaneously. It is unlikely that we will have the segwit stuff released by November 15th.
they should not test the RC because its their fault and treated as delaying if making a request for time. and trust the RC works... right??
No. When they are doing the code review during their own implementations, any critical issues with the implementation of the rc can and should be reported. These can be blockers and delay the official release, but it is all needed and welcomed in order to produce code that is as secure as possible.
think long and hard about the subtle point.
now if you still think there is no reason for 12 months coding and 6 months grace after a RC, anyone asking for time should be disregarded..right?
Given that segwit is a soft fork, anyone asking for time should be disregarded unless they find a critical bug. If it is just a request for a delay because they want to have a release out for segwit at the same time, then that can be disregarded. Their software's current state will continue to function following activation. They can still take their time to implement segwit properly. Note that this is only because segwit is a soft fork.
For hard forks, anyone asking for time should not be disregarded so that everyone on the network can upgrade at around the same time to avoid chain splitting.
now explain the last year of civil war.
where core agreed to flex caps. a RC was released. but then core backtracked.
When did Core agree to flex caps? When was a release made with flex caps?
oh wait i can predict you flip flopping your answers while reading this to protect your interests
Oh wait, I can predict you cherry-picking my answers so it seems like they flip flop to you so you can further attack me.
