Many people answered to my previous rant stating that it is upstream's prerogative to refuse integration of external patches. I agree and I never said they must integrate patches if they open their source.
What I find unacceptable, and the only reason for the rant, is the fact that upstream deleted my posts from the forum when it was clear that none of the fake reasons that were given was the real reason, since I answered to all of them with sane, logic and reasonable arguments.
I find acceptable to refuse external patches, although undesirable.
Still, I find it unacceptable to try to erase all tracks of a conversation from which it is clear that you were wrong, and try to keep face by erasing traces.
I would have found it hard to deal with, but still acceptable, if upstream would have said simply "please don't try to make patches for glest with the purpose of integrating them later on, we don't want any patches from outsiders". That would have been a decent thing to do.
Showing posts with label reply. Show all posts
Showing posts with label reply. Show all posts
Wednesday, 11 March 2009
Saturday, 8 March 2008
mistranslations - how to deal with it
Aigars, you could use what I already made for the compedia creation. The code is available on i18n.debian.net in my home dir (I thought I exposed it on alioth, too, but I just checked and is not).
The results for latvian are also present.
The results for latvian are also present.
Saturday, 1 March 2008
Building in a sarge chroot might not always work
Adeodato correctly points out that building under a Sarge chroot, and expecting the package to work on Sid, might not always[1][2] work mainly because of ABI changes and similar changes. Thus, I am forced to clarify this a little.
Generally, the binaries in the packages we produce do not dynamically link to anything other than libc6, libstdc++5 (yes, 5, not 6) or some internal libraries, so we don't have to worry about ABI changes, at least, not yet.
So, a disclaimer is in order: unless you know what you're doing, you probably are better off building packages for each of the supported Debian distros.
Thanks Adeodato for the heads-up.
[1] unless your package is a special case
[2] or, better said, in most cases
udate: fixed the link to dato's post
Generally, the binaries in the packages we produce do not dynamically link to anything other than libc6, libstdc++5 (yes, 5, not 6) or some internal libraries, so we don't have to worry about ABI changes, at least, not yet.
So, a disclaimer is in order: unless you know what you're doing, you probably are better off building packages for each of the supported Debian distros.
Thanks Adeodato for the heads-up.
[1] unless your package is a special case
[2] or, better said, in most cases
udate: fixed the link to dato's post
Subscribe to:
Posts (Atom)