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