Re: [PATCH] Xft patch reloaded, #3

Michael Sperber <[email protected]>
Newsgroups gmane.emacs.xemacs.design
Message-ID <[email protected]>
Stephen, all your points are valid.

The basic problem is this, if I understand you right:

- someone posts a big patch
- it's not quite the end of the line of changes suggested by it
  (probably since it likely contains patches)
- patch introduces maintenance burdens

Still, working on a branch is *completely impractical*, especially
with pervasive changes like this.  Next time Ben merges one of his
workspaces, the work these guys have done will be toast.  Moreover, as
the current line of changes, in your view, should only happen *after
other pervasive changes*, the work on a branch is going to be
completely useless even if this does not happen.

It's also bad for our version history, since CVS isn't really geared
for further active development on a branch.

Still, we need to find a way to make changes that will end up big
happen in an acceptable fashion.  (As we need a number of changes
which end up big to even stay in business.)

So, can you propose a path acceptable to you consisting of smaller
steps that may end up in a proper integration of Xft that can happen
on the trunk?  (Including a list of things that you think we need
resolved before we can think about the end goal.)

If not, we have a very serious general problem.  Moreover, it was,
IMHO, a mistake to not inform Eric and Matthias about the reasons for
your disapproval earlier.  (Maybe I missed it---I didn't see it.)
(Water under the bridge, anyway.)

I have to admit that I lost the thrust of the discussion you were
having.  So maybe both parties can summarize on where they stand and
where they're willing to go.

-- 
Cheers =8-} M.
Friede, Völkerverständigung und überhaupt blabla
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.