Re: [TCLCORE] TCT/TIP reform

[Poor Y. <org...@po...>]

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