Lionel Debroux (./10) :
The irrelevant thing is your comment: we're talking precisely about these scripts that build stuff, not about what happens "once you have the stuff built".

But that's precisely why those changes are useless in common usage.

I'd rather say 3. he made a mistake once or twice in the usage of that highly sucky CVS tool, committed the Debian files where he shouldn't have,

Committing the debian directories was not a mistake, it was intentional as per his commit messages. The other unrelated (and even more unwanted) changes he committed at the same time were the mistake. And he managed to do this not once, but twice! (If you screw up once, you need to fix your processes so you don't do it again. He still kept his unsafe practices such as building directly in his checkout rather than in an export.) And this after I told him right from the start that he shouldn't be committing debian directories to the upstream package in the first place (those directories were unwelcome themselves too), and reiterated this after the first accident. He just didn't care.

and you used this as a pretext to remove his commit access (no matter he was already working on TIGCC running on *nix before you came in)

It was not a pretext. He abused his commit privileges to commit unapproved changes, even to KTIGCC which has always been my project and not his. And he hadn't used them for anything other than those unwanted changes for years!

=> no wonder he didn't keep packaging your stuff after that.

I don't see this as "no wonder" at all, but as "my way or the highway" control-freakiness. Packaging metadata does not belong into the upstream SCM, period. But he only cared about what was convenient for him, he didn't give a darn about best practices or about the trouble caused to me (pollution of my cvs2cl-generated KTIGCC changelogs, stale debian directories at release time etc.).

Don't be so centered on yourself. Even in case they'd be useless to you (I can't see how having cross-compilation support built-in the scripts, as opposed to having to run it on a tool-by-tool basis, would not help, but whatever), they're obviously useful to us, and that's what matters.

You can't blame me for not doing changes which are not useful to me to a process only I run (cross-compiling EXE binaries of TIGCC).

If you weren't such a pain to deal with, more people - starting with myself - would still be working with you. It takes years, but people get tired of someone refusing many ideas (technical matters, and life in general, are not black-and-white, they're shades of gray, see http://tichessteamhq.yuku.com/reply/32850/t/ttunpack-decompress-gray.html#reply-32850 ), disregarding user input (removing VTI support...), and otherwise mishandling a project that used to be cooperative.

Yawn, always the same bogus accusations. A maintainer can't say yes to everything, there are often decisions some people do not like, often for irrational reasons (e.g. there's no rational reason to prefer VTI to TiEmu or Emu-TIGCC, as those have all the features VTI had and more, including a C debugger!), but which are necessary for maintaining the project's quality and/or long-term maintainability.