[PATCH][Fwd: Re: Xterm window title enhancement to hostname:/path II.]
Hello mc-devel,
I haven't noticed any objection against this patch and many people
consider it helpful. Any chance to see it committed?
Thanks,
Jindrich
--
Jindrich Novy [EMAIL PROTECTED], http://people.redhat.com/jnovy/
The worst evil in the world is refusal to think.
---BeginMessage---
Hello Pavel,
here is the patch where both hostname and username are printed in the
xterm window title.
Cheers,
Jindrich
--
Jindrich Novy [EMAIL PROTECTED], http://people.redhat.com/jnovy/
--- mc-4.6.1a/src/main.c.hostname 2005-03-23 13:59:31.198747928 +0100
+++ mc-4.6.1a/src/main.c 2005-03-23 16:00:49.13592 +0100
@@ -32,6 +32,7 @@
#include sys/types.h
#include sys/stat.h
#include unistd.h
+#include pwd.h
#include global.h
#include tty.h
@@ -1612,9 +1613,22 @@ void
update_xterm_title_path (void)
{
unsigned char *p, *s;
+char h[64];
+struct passwd *pw;
if (xterm_flag xterm_title) {
p = s = g_strdup (strip_home_and_password (current_panel-cwd));
+ if ( !gethostname (h, 64) ) {
+ h[63] = '\0'; /* Be sure the hostname is NUL terminated */
+ s = g_strdup_printf (%s:%s, h, s);
+ g_free (p);
+ p = s;
+ }
+ if ( (pw = getpwuid(getuid())) ) {
+ s = g_strdup_printf ([EMAIL PROTECTED], pw-pw_name, s);
+ g_free (p);
+ p = s;
+ }
do {
if (*s ' ')
*s = '?';
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
---End Message---
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
Release procedure
To prepare the upcoming release of mc, I reviewed the file
maint/RELEASE_PROCEDURE and complete rewrote it. The main changes are:
* Translations are updated _before_ a release
* The CVS gets tagged with a release
* A new CVS branch is created for the release
The CVS branch will be used to support the released version, where the
CVS tag will only mark the point where the release has been forked from
the CVS HEAD.
Let's discuss it and then have a release.
Roland
This document describes step by step the release procedure of GNU
Midnight Commander.
${dotted_version} shall be replaced by something like 4.6
${underscore_version} shall be replaced by something like 4_6
day 0 (translator's prerelease)
* Check out a fresh copy from the CVS repository.
* Set the version number in configure.ac to
${dotted_version}-translators.
DON'T commit configure.ac.
* Update the translation files NOT to contain line number information.
Commit them.
* Tag the CVS tree as MC_${underscore_version}_translators.
* Update the translation files to contain line number information.
DON'T commit them.
* Run make dist.
* Upload the distribution tarballs and the individual translation files
somewhere where the translators can download it.
* Announce the availibility of a translator prerelease on mc-devel.
Inform the translators of the prerelease.
Inform the developers of a fourteen-day feature-freeze.
day 11
* announce a remainder on mc-devel that the release will occur in
three days.
day 14
* Review the English version of the manual and fix it if necessary.
Update the date in the .TH macro of the English manual.
* Update the NEWS file to contain all user-visible changes.
* Fix wrong formatting in the ChangeLog files.
* Set the version number in configure.ac to ${dotted_version}.
Commit it.
* Update the translation files NOT to contain line number information.
Commit them.
* Run the test suites maint/mctest and maint/mc-test and make sure
all warnings are ok.
* Tag the CVS tree as MC_${underscore_version}_release.
* Create a CVS branch MC_${underscore_version}.
* Run make dist.
* Upload the resulting tarballs to the Savannah repository.
* Announce the new release on the mc-devel and mc mailing lists.
* Update the homepage.
after that
* Create binary packages from the uploaded tarballs as necessary.
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
RE: Release procedure
___ Join Excite! - http://www.excite.com The most personalized portal on the Web! ---BeginMessage--- Hmm, I hope to have the Spanish translation up to date by now. I think that most translator are part time or even little time collaborators and some/most of them may have problems with this tight scheduling. On the other hand, I know that scheduling is a must. Is it possible to open the 10 days translation period making sort of an interface freeze where no translatable strings may be changed? Any sort of pre-warning such as be ready for next release in 1 month? I know that lately we've had too many of these warnings :). So, my feelings: - Short Time - I'm not sure if I would manage to deal with CVS branches. I've always done updates to the HEAD. Some help may be needed at this point (at least for me), or even open an alternate channel for sending translations (mc-devel?, direct e-mail?). An off-topic: I joined this thing with Miguel so that's all I have to say about recent flames. David --- On Mon 06/06, Roland Illig [EMAIL PROTECTED] wrote: From: Roland Illig [mailto: [EMAIL PROTECTED] To: mc-devel@gnome.org Date: Mon, 06 Jun 2005 17:01:34 +0200 Subject: Release procedure ___ Join Excite! - http://www.excite.com The most personalized portal on the Web! ---End Message--- ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: New Maintainer for MC Project?
Hi! * Tell the Leadership that thanks, but no thanks. ... If meritocracy is the rule I think we should decide this on merits, don't you? Which means you shouldn't decide this all by yourself. I would like to get some input from others as well. I agree with Miguel here... Pavel ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: New Maintainer for MC Project?
Since it is not my policy to argue with fools, that's all I will say along those lines. Learn to use email, thanks. Pavel ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: New Maintainer for MC Project?
Miguel de Icaza wrote: * You exhibit the behavior of many people who have no ideas whatsoever about the project but like big titles. Public Relations Coordinator, the leadership, and Project Manager. * Tell the Leadership that thanks, but no thanks. I completely agree with these points. Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Release procedure
Hello, Roland, I like your proposal, for a major release version. But I got the feeling that we could go back to bi-weekly releases, so with a quick release schedule, translators just need to make sure they can catch the next train if their translations are not available. I have made a tarball of the current trunk release and fixing a few issues in make distcheck, the question that remains is: what version should we use? We continue to use the 4.6.xx family name. I think it might be time to change one of those numbers to identify the changes done since the 4.6.0 release in a more significant way. Once we agree on that, I can upload the tarball. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Release procedure
Roland Illig wrote:
day 0 (translator's prerelease)
* Set the version number in configure.ac to
${dotted_version}-translators.
DON'T commit configure.ac.
I have removed this item from my local copy. There's no need to have a
version number in a translator's prerelease.
I have also added a back to work section with a single item:
* Discuss milestones for the next release on the mc-devel list.
Roland
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
RE: Release procedure
Hello David, On Mon, 2005-06-06 at 17:55, David Martin wrote: I think that most translator are part time or even little time collaborators and some/most of them may have problems with this tight scheduling. On the other hand, I know that scheduling is a must. ... Is it possible to open the 10 days translation period making sort of an interface freeze where no translatable strings may be changed? MC_4_6_1_PRE has been mostly unchanged since december 2004. Isn't that enough of an interface freeze ;-) ? Any sort of pre-warning such as be ready for next release in 1 month? This is why I propose to have *1* release candidate, and the upcoming release about 2 weeks after. I hope this release will indeed be done from the PRE branch, *not* HEAD! I know that lately we've had too many of these warnings :). Well, yeah, developers proposing a release asap. - I'm not sure if I would manage to deal with CVS branches. Just use the -r switch to your cvs update command. You don't need that switch once you've setup separate local trees for HEAD and other branches. Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Release procedure
Miguel de Icaza wrote: Hello, Roland, I like your proposal, for a major release version. But I got the feeling that we could go back to bi-weekly releases, so with a quick release schedule, translators just need to make sure they can catch the next train if their translations are not available. bi-weekly releases? You're kidding, aren't you? I think this would be too much work for us. What about bi-monthly? There are many big projects waiting to be addressed, like extended character support, a uniform and simple pathname scheme. These projects will take much more time than two weeks to be finished. I have made a tarball of the current trunk release and fixing a few issues in make distcheck, the question that remains is: what version should we use? What did you fix? We continue to use the 4.6.xx family name. I think it might be time to change one of those numbers to identify the changes done since the 4.6.0 release in a more significant way. I would prefer 4.7. (Just to leave the long past of 4.6.* pre-releases behind us. ;)) Roland ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Release procedure
Hello Miguel, On Mon, 2005-06-06 at 22:58, Miguel de Icaza wrote: I have made a tarball of the current trunk release and fixing a few issues in make distcheck, the question that remains is: what version should we use? Please use MC_4_6_1_PRE for the release of 4.6.1. Then we can use HEAD for 4.6.2 and onwards. All we need for PRE is possibly the fixes that proski introduced for gcc-4 warnings and some translations. That should suffice for 4.6.1. I would say you can call that code very stable. Many of the changes in HEAD are hardly tested. So let's please use HEAD for upcoming release. We continue to use the 4.6.xx family name. sigh Good. Let's not jump to anything above that yet. I think it might be time to change one of those numbers to identify the changes done since the 4.6.0 release in a more significant way. Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
