Re: Release procedure
Hello, On Mon, 6 Jun 2005, Leonard den Ottolander wrote: 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. I second that. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Release procedure
Hello, On Mon, 6 Jun 2005, Roland Illig wrote: 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. ;)) In fact the changes between 4.6.0 and 4.6.1 are not so significant in terms of functionality. I think of 4.6.1 as a bugfix release. Browsing through the NEWS files doesn't indicate the opposite. Having said that - I think we should stick to 4.6.1. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Release procedure
Hello, 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. I second that. Sounds good. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Release procedure
Hello, 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? Make distcheck was broken, look at the dist-hook target, it would not build with VPATH/different prefixes. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Release procedure
hello, I have a tarball made from the branch: http://primates.ximian.com/~miguel/mc/tar.mc-4.6.1-pre5a.tar.gz I can rename this to 4.6.1 if people want. Miguel. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Release procedure
Hello, On Tue, 7 Jun 2005, Miguel de Icaza wrote: hello, I have a tarball made from the branch: http://primates.ximian.com/~miguel/mc/tar.mc-4.6.1-pre5a.tar.gz The right link is: http://primates.ximian.com/~miguel/mc/mc-4.6.1-pre5a.tar.gz ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re[2]: Release procedure
Hello Miguel, Tuesday, June 7, 2005, 5:10:03 PM, you wrote: MdI I have a tarball made from the branch: MdIhttp://primates.ximian.com/~miguel/mc/tar.mc-4.6.1-pre5a.tar.gz MdI I can rename this to 4.6.1 if people want. Miguel, Why 4.6.1-pre5a, not pre4a? Please wait before renaming one day. -- Best regards, Pavelmailto:[EMAIL PROTECTED] ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Release procedure
Hello Leonard, mc-devel,
On Mon, 2005-06-06 at 23:34 +0200, Leonard den Ottolander wrote:
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.
I can confirm that all the signedness gcc4 warnings are now gone in
the current CVS. The only warnings I found were not gcc4 related with
trivial fix, but it would be nice to see it fixed in the next mc
release.
I discussed this with Roland so maybe it's fixed now already. Attaching
the patch anyway.
Cheers,
Jindrich
--
Jindrich Novy [EMAIL PROTECTED], http://people.redhat.com/jnovy/
The worst evil in the world is refusal to think.
--- mc-4.6.1a/src/widget.c.fixes 2005-06-06 15:08:52.202559824 +0200
+++ mc-4.6.1a/src/widget.c 2005-06-06 15:08:29.120068896 +0200
@@ -2363,7 +2363,7 @@ buttonbar_set_label_data (Dlg_head *h, i
void
buttonbar_set_label (Dlg_head *h, int idx, const char *text, void (*cback) (void))
{
-buttonbar_set_label_data (h, idx, text, cback, 0);
+buttonbar_set_label_data (h, idx, text, (buttonbarfn)cback, 0);
}
void
--- mc-4.6.1a/src/command.c.fixes 2005-05-27 05:35:15.0 +0200
+++ mc-4.6.1a/src/command.c 2005-06-06 15:07:38.228805544 +0200
@@ -280,7 +280,7 @@ command_callback (Widget *w, widget_msg_
/* fall through */
default:
- return input_callback (cmd, msg, parm);
+ return input_callback (w, msg, parm);
}
}
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Release procedure
Jindrich Novy wrote:
--- mc-4.6.1a/src/widget.c.fixes2005-06-06 15:08:52.202559824 +0200
+++ mc-4.6.1a/src/widget.c 2005-06-06 15:08:29.120068896 +0200
@@ -2363,7 +2363,7 @@ buttonbar_set_label_data (Dlg_head *h, i
void
buttonbar_set_label (Dlg_head *h, int idx, const char *text, void (*cback)
(void))
{
-buttonbar_set_label_data (h, idx, text, cback, 0);
+buttonbar_set_label_data (h, idx, text, (buttonbarfn)cback, 0);
I will fix this in a minute, but sadly the _correct_ fix is not as
trivial. Here we are converting completely unrelated function pointers,
which is quite dangerous in case the function prototypes change or in
case we use another compiler. The C standard states this as undefined
behavior.
--- mc-4.6.1a/src/command.c.fixes 2005-05-27 05:35:15.0 +0200
+++ mc-4.6.1a/src/command.c 2005-06-06 15:07:38.228805544 +0200
@@ -280,7 +280,7 @@ command_callback (Widget *w, widget_msg_
/* fall through */
default:
- return input_callback (cmd, msg, parm);
+ return input_callback (w, msg, parm);
Fixed. That was trivial.
Roland
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Last TODO items before release [was Re: Release procedure]
On Tue, 2005-06-07 at 20:02, Leonard den Ottolander wrote: Before releasing 4.6.1 there are a few things to be done: - Backporting gcc-4 signedness fixes I understand many of the developers doubt the quality of the warnings from gcc-4, and hence the fixes proski created for them. We can look at them for the next release. - Add match for tab in promptfix patch (I'll do this) I'll commit this with 6 hours from now. Gotta go now ;) . Anything else? ? 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
wget http://primates.ximian.com/~miguel/mc/tar.mc-4.6.1-pre5a.tar.gz --14:28:46-- http://primates.ximian.com/%7Emiguel/mc/tar.mc-4.6.1-pre5a.tar.gz = `tar.mc-4.6.1-pre5a.tar.gz' Resolving primates.ximian.com... 130.57.169.34 Connecting to primates.ximian.com[130.57.169.34]:80... connected. HTTP request sent, awaiting response... 404 Not Found 14:28:49 ERROR 404: Not Found. -- Regards, Scott --- [ Miguel de Icaza ] ===--- hello, I have a tarball made from the branch: http://primates.ximian.com/~miguel/mc/tar.mc-4.6.1-pre5a.tar.gz I can rename this to 4.6.1 if people want. Miguel. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Last TODO items before release [was Re: Release procedure]
Leonard den Ottolander wrote: Roland fixed a memory leak in HEAD but he doesn't know where again g. I have thoroughly check the changes to mcedit, where I assumed the memory leak to have been. The only things I found were two instances where I had replaced use of the catstrs() function with explicit memory management. These places look highly suspicious, but are indeed ok and always have been. Roland ___ 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: 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
