Mats Lidell writes:
>>>>> Stephen wrote:
Stephen> Requires a release manager, but given a release manager we
Stephen> can do that.
Note that we also need to think about promotion to stable; I don't
know if Vin would consider 21.5 something he's willing to take on.
Stephen> I think [GPLv3] is actually the highest priority, as it
Stephen> prevents most people from doing any GNU syncing.... It's
Stephen> something that somebody other than Ben Wing can do.
can or can't?
*Can* do. To relicense to GPLv3 in principle is just a global
substitution, and exchanging the license text in COPYING. We should
also make sure we have the FSF's address right everywhere. Finally,
there is a small number of files that either have no permissions
notice or lack the "or later" clause, and we need to decide what to do
Larry Rosen told me that it's not a crime to violate copyright unless
you do it willfully to make a profit. It follows, he said, that as
long as you do nothing that upsets a copyright holder, anything else
is "legal". Even if a copyright holder objects, the worst that can
happen is we have to take out his content, or revert to the previous
license. (The latter may be possible for documentation files and
freestanding helper applications like etags -- not that etags could be
a problem, it's just an example of "freestanding".)
So it seems to me that to satisfy both the law and ourselves that
we're making the license change in good faith, we need to
(1) identify "problem" files (this is done or at least there's a
script to do it, I think)
(2) find the relevant authors (reading the file and grepping
ChangeLogs and CVS history)
(3) write them an email, and wait a month
(4) if there are no objections, change the license
For any file where there's an objection, we'd need to decide how to
deal with it. In cases of no answer, IMO we made a good faith effort,
and then we decide if the risk of having to rip it out is worth it.
This is one reason I think a release of 21.5 is a good thing. It
will be a good starting point for the GPLv3 version.
I don't understand why you think we need to wait. It's a basically
mechanical process, and one that a non-technical volunteer can do
everything except assess the risk and cost of "rip outs" of code whose
owner refuses to change license. That should be doable concurrently
with the technical stuff that needs to be done.
["Portable" window system needs] to be investigated of
have, as you might guessed, not wished this based on technical
considerations. I look at it from the perspective that it seems
hard to support so many different window systems.
Actually, supporting the window systems is not so hard. Very few of
the problems come from the window systems themselves as far as I know.
The problems with display that I know of are due to (1) the as-yet
unstable move of window configuration code to Lisp, which has little
to do with redisplay and window systems, (2) font-related stuff which
we must handle ourselves (unless we want to change redisplay to
something like Gecko; the hideous state of Xft is one example), and
(3) interactions with garbage collection.
The reason that GTK or wxWindows really doesn't help that much is that
in order to do things like faces, invisible text, wrapping or
truncation of lines, etc, we need to handle text redisplay ourselves.
That's the complex stuff, and Pango goes partway to handling
Mule-related font stuff, but none of the windowing systems support a
text widget with the capabilities we need. Unless you think an XEmacs
where Emacs windows have the enormous power we've come to associate
with browser text-entry boxes is sufficient!<wink>
If it is in conflict with XEmacs basic architecture we need to live
with that of course (or change it).
I believe it's in conflict with the basic architecture of *any* Emacs-
So my short revised plan is this: do everything that _must_ be done
to make 21.5 a new release,
Well, five of my candidates are
1. straightfoward configuration of Xft fonts from resources or Lisp
(unification to Lisp only can come later; we really should provide
an X-resource-file-to-Lisp translator),
2. general improvement of face and other customization,
3. Xft font turds,
4. fix window configuration management (VM at least suffers horribly), and
5. SUMO-in-source distribution (at least a simple version).
XEmacs-Beta mailing list