|
From: Poor Y. <org...@po...> - 2023-05-11 08:34:33
|
On 2023-05-11 03:16, Steve Landers wrote: ... > We could explicitly to allow TIPs to be voted on without an > implementation (as happens now) but there is a risk this will be seen > as a “Feature Request” and not a commitment to implement if > approved. > ... > > Looking at the process for approving a merge, it needn't be onerous. > Even a single reviewer signing-off on a merge would be better than the > current situation. That means a single positive code review is > sufficient but if someone objects then a 2/3 vote is needed to > integrate. ... Many successful open source projects are driven by pull requests. Linux is the prime example. This is the modern low-friction way. In the case of Linux, there is one individual at the top of the hierarchy of pull requests, whereas in the case of Tcl there is a committee. The process should attempt to compensate for the "design-by-committee" effect. A vote could be not on a formal TIP, but on a request to merge a particular commit (not a branch, but a specific commit), complete with correct documentation relevant to the change. The TIP itself would not be normative, but just explain the rationale for merging the branch, and could also be a living document, i.e. subject to updates that increase its value to the reader. Often, the rationale for a commit is obvious, and all that is needed is proper documentation, not an extra document in the form of a TIP. If a vote is on merging a commit, and the documentation rather than the TIP is normative, then there is no reason for a rule artificially limiting a TIP to one branch. A vote on new commit can replace a vote on a previous commit at any time during the voting process, and voters can cast a new vote accordingly. Voting on the merge of a commit rather than on the TIP would lead to more votes on smaller merges. This would give others more opportunity to review progress in a certain direction "in real time", and also motivate the contributor to make their work in the source code more modular. The merge of a commit is a more concrete thing than approval of a TIP, making it possible to reject a merge due to specific defects or even stylistic shortcomings. Merge requests that contain changes that are not on topic would be more easily rejected, with newer requests that address the issues taking their place. If the vote is on merging a commit, then the vote itself is the formal sign-off that has been proposed. There would be more votes, but an individual commit is easier to assess, and the voting process could happen more fluidly and with lower latency. In summary, altering the TIP process as described above brings it more in line with proven modern practices employed by projects like Linux, and widely-standardized on development platforms like like GitLab and Github. It also lightens the workload for both the contributor and the voters, and lends itself to the development of guidelines on the criteria for accepting a certain commit for merging. It would also be easy to implement even before addressing more thorny questions like the makeup of the TCT or the procedural rules for a vote. Even if this idea is adopted, it should only pertain to commits that would according to current rules require a TIP. It would be too burdensome on continuing development to expand the scope of what requires a vote. -- Yorick |