Tony Houghton writes: > On Fri, 25 Jun 2010 21:23:46 +0300 Hi, > George Danchev <danchev@spnet.net> wrote: > > Tony Houghton writes: > > > However, due to a bug which can cause roxterm to crash unpredictably > > > (very serious because it can take any number of child processes with > > > it), discussed at > > > <http://sourceforge.net/projects/roxterm/forums/forum/422638/topic/3711 > > > 088> , I think replacement of 1.18.2-1 should be given fairly high > > > priority. > > > > It took me some time, and as I understand it, it is rev763, which > > fixes the above mentioned issue, thus wouldn't be safer to just > > backport that change (just reflecting connected/disconnected state) to > > the version in sid? It should also be fairly easy. I should also admit > > that the subsequent COLORTERM changes look trivial, and very low risk, > > thus these should also be acceptable, but if you ask me I'd still go > > for former (rev763 only), unless you have a better reason for the > > latter (more verbose changlogs are generally more helpful;-), so > > please let me know. > > You're quite right, I need to get in a habit of being more verbose in my > commit messages to generate a better ChangeLog. Reviewing the other > changes myself: > > I've improved the documentation, including changing a bit about how to > enable configurable keyboard shortcuts in GNOME, which had become out of > date. Documentation changes shouldn't give cause for concern about > stability? > > Looking at r747 again, I can't find the bug report which triggered that, > but ISTR there was a visible problem. I think there's the possibility of > a divide by zero error, and it's a one line fix, so I really think I > should include that. > > r746 is a one-liner which fixes two "not quite correct behaviour" bugs > <https://sourceforge.net/tracker/?func=detail&aid=2997666&group_id=124080&a > tid=698428> and > <https://sourceforge.net/tracker/?func=detail&aid=2997661&group_id=124080&a > tid=698428>. > > r745 is more complicated and most people wouldn't notice the problem > <https://sourceforge.net/tracker/?func=detail&aid=2999166&group_id=124080&a > tid=698428> so I'm happy to leave that out. > > But with all the above that I think should go in, plus you accepting the > new *TERM feature, it seems like we might just as well release 1.18.4-1. After thinking about it for a while, I decided to agree with your recommendation, and uploaded 1.18.4-1 as is. Let's hope it brings more benefits to the users, than eventual regressions. > If you disagree and just want the important fixes, do you suggest > merging them into one "backported-bugfixes" patch or use a separate one > for each feature? If something goes wrong (i.e. regression is found) with 1.18.4-1, I'd appreciate if separate bug fixes (against that same version) are splitted in separate patches. > > P.S. I no longer intend to use that package, thus you will need > > another sponsor for it or alternatively complete the DM-state. However > > I intend to review and upload your urgent 'fixes' until after release > > of squeeze. > > Can I ask why you no longer intend to use it? It shouldn't matter if you Well, it is no longer the lightweight terminal emulator, as it used to be, its ldd score is basically the same as the one of gnome-terminal or konsole. I also consider 'no dbus support' a feature. However, these are really a matter of personal preferences, both as: package already has its user base and tons of other software uses dbus, so it is already useful for someone else. This basically leads us to the consequence that someone else using it should take care of reviewing and uploading. However, as an interim solution, I intend to spend few of my time uploading it, until you manage to find another sponsor or complete the DM. It is worth, since your efforts/time won't be left unaddressed/wasted, and hopefully roxterm users won't be left in the cold. > stop sponsoring it, because at least one other DD has expressed > interest, and I am going to apply for DM. I've already had my key signed > but the signer is soon going to replace his key with a more secure one > and I thought maybe I should wait until he's signed mine with his new > key. Or does that not really matter at all and I should forge ahead > ASAP? Well, you should wait for him to sign your key with his newer one and then proceed with DM. Take your time, I don't intend to vanish abruptly, especially in the case of any hypothetical regressions being found. -- pub 4096R/0E4BD0AB <people.fccf.net/danchev/key pgp.mit.edu>
Attachment:
signature.asc
Description: This is a digitally signed message part.