On Sat, Apr 30, 2016 at 10:00:15AM -0700, Bradley M. Kuhn wrote:
I'm somewhat confused by what you're doing with drafts in the
copyleft-next Git repository. I see you did most of the drafting on
0.3.1 as a copy of 0.3.0 in the file
Drafts/copyleft-next-0.3.1-SNAPSHOT, and the main Drafts/copyleft-next
has a separate history. The latter's text of it doesn't match 0.3.1 at
the moment, which seems odd and counter-intuitive given that you just
released 0.3.1. i.e., I was surprised at this:
$ git checkout -q v0.3.1 && diff -u Drafts/copyleft-next
copyleft-next-0.3.1 | 433 +++++++++++++++++++++++-----------------------------
1 file changed, 196 insertions(+), 237 deletions(-)
... compared to previous release ...
$ git checkout -q v0.3.0 && diff -u Drafts/copyleft-next
Releases/copyleft-next-0.3.0 | diffstat
copyleft-next-0.3.0 | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
....where the only change was the release number and date, as expected.
ISTR that you and discussed a long time ago using tags and branches,
Actually I don't remember having such a discussion, but it's possible
we did. I used tags with numbered releases from (I think) the earliest
keeping all drafting done in one single file was not what you wanted,
but I don't recall your reasons. Is that still what you want?
I have never felt that the approach taken was above criticism but the
idea was to keep Drafts/copyleft-next as a kind of single evolving
version. What happened here was I think unprecedented. copyleft-next
0.3.0 was released a long time ago, and the evolution of
Drafts/copyleft-next in the master branch since that time was
considerable (particularly when you consider that work on
copyleft-next was dormant most of the time). But prompted by some
questions from mcgrof, I realized that it was important to make some
minor improvements in a successor release to copyleft-next 0.3.0 in
the short term. So I decided to call that version "0.3.1". The current
Drafts/copyleft-next is more like something that is evolving towards
0.4.0. (Though as I recently noted this is kind of a nonsensical
application of the idea of semantic versioning.)
There's probably a much better way.
Regardless of how the repository is organized, the real problem is
'git log' became a much less useful tool in figuring out the history of
copyleft-next between 0.3.0 and 0.3.1, and the project IMO has the
beginnings of some serious repository history bitrot.
I think the repository needs reconstruction to clean up this and
problems I discovered today. I'd suspect this is would be 3-4 hour task
if done as a hackfest with a few people coordinated in real time on IRC.
I have various ideas on how we do it, and I have two separate proposals
for some basic repository disciplines that could be used going forward
to make sure we don't get this kind of history bitrot again.
Specifically, I have two parallel incompatible proposals that I'll pitch
if you're interested. The first would use the branch/tag structure I
proposed in the past, and reapply existing history. If you still don't
like that structure, I also devised in recent years a (complicated)
method that could keep your basic Drafts/ and Releases/ directory
structure on master branch and still preserve history properly.
I am interested in such proposals.
But if you don't have time/interest right now in reengineering
repairing the repository history, there is no need to have this broader
discussion. In that case, the minimal action that I request at this
time is to either update the docs or otherwise explain what file in
copyleft-next one ought to be looking at as the current draft, and some
documentation on how that relates to other files in the repository.
Once you clarify that, I can make a suggestion on future editing based
on my ideas above that can prevent future bitrot.
My time is limited but my interest is there.
To make a strong plea for my point, though, I felt the whole reason
do copyleft-next in the way that you did was to make the first truly
transparently designed license drafting project by using Free Software
development tools. Right now, the tools are being used but the
transparency is not complete.
Well, it's still better than any previous major license drafting
effort I believe. But I accept this criticism and am eager to learn
your suggestions for improvements.