| Thread Previous • Date Previous • Date Next • Thread Next |
jp.charras@xxxxxxxxxx wrote:
Dick Hollenbeck a écrit :Alain Portal wrote:Hi,My kicad installation failed because INSTALL.txt was remove from repository and not fron the cmake files list.Here is the patch to fix. Regards, AlainJean-Pierre,1) How did this happen that file /INSTALL.txt is not in stable but is in testing?Sorry. This was a too zealous cleanup.removing notes_about_pcbnew_new_file_format.odt file in the stable version is enough.I commited the fix.My original plan was that stable was simply going to be a periodic snapshot of testing. With that strategy it would never be possible for stable to be ahead of testing. Periodic merges would be done from testing into stable.Therefore I am confused as to how a file could be deleted from stable and not from testing.This sounds good.
My point remains. I am still confused how a file could be deleted from stable and not from testing: notes_about_pcbnew_format.odt should also be in stable IMO.
But bug fixes could create (temporary) some differences between branches between 2 merges. This is because some bugs must be immediately fixed, but testing branch can have features that cannot be immediately merged in the stable branch.
My opinion:Agreed, bugs should be immediately fixed, but they do NOT have to be immediately put into stable. If stable was updated once per month, that would be good enough for the project. Developers need to use the testing branch, otherwise they are not really developers, they are users lurking as developers. *We should never accept a patch against the stable branch*.
Here is how I think of the the two branches, using a metaphor for the two branches:
Think of an analog feedback loop with a setpoint, and the feedback loop is subject to disturbances (other than the setpoint, i.e. non-setpoint disturbances). The disturbances are analogous in the metaphor to new code, bringing in bugs with each piece of new code. The output of the loop is the "product", and is the measured variable. We need to think of the testing branch as the feedback loop, and the stable branch as a bucket or tank of (chemical?) product. We should only capture product when the output is near the setpoint. That is if the feedback loop is still oscillating, we don't capture product. Wait a month, who cares, for the bugs to be found and wrung out, reaching setpoint again.
Again developers should ALL be using the testing branch, this tightens up the feedback loop's responsiveness. When that loop is responsive, then this means we stay nearer to setpoint more often. Again, in this metaphor, the testing branch is a feedback loop, and the stable branch is simply a tank of product which is captured only when we think we are near setpoint (bug free).
The metaphor is not an exact match. In particular we will not run out of product, meaning anybody can build the stable branch at any time. But we have to lower expectations about it being "current". How can it be both current and stable?
If you want to hand pick individual patches that go into stable, this is your choice. It would not be my choice, because it is too labor intensive. Instead I would simply delay snapshotting testing until I suspect that most bugs have been wrung out of testing, even if this means waiting a month between snapshots. If developers think testing is more current, this will also incentivize them to USE testing on a daily basis. The more folks that use testing, the more feedback we get, and the faster bugs can be wrung out and the loop becomes more responsive (higher gain in the metaphor). You can always choose to stabilize the testing feedback loop by slowing down the rate at which you add disturbances. This is possible by queuing up patches in the developer's local repo copy, delaying submission, etc. We could make it a practice to issue a monthly "stable" snapshot, and proclaim that testing patch submission in week four of every month will be delayed for a week except for bug fix patches only. Only bug fixes in week 4, then at the end of the month another full snapshot is made. This is how I would want to spend my time orchestrating the two branches, if I had time in the same quantities that you do. It would start by lowering expectations with respect to the current-ness of the stable branch.
Currently, the internat directory in stable branch is the same as in docs repo. It can be deleted in the stable tree (in fact I did not noticed it was still in the stable branch until now).2) Also, I think it is harmful to have the internat directory tree present in stable. It is now in the docs, repo. Any objections if I delete it from stable?Dick
This deletion has been done by me this evening. Dick
| Thread Previous • Date Previous • Date Next • Thread Next |
