Re: Proposed Freeze Change
Hi! As the proposal above does not mention a date for The Freeze I propose either Feb 20 (current UI Freeze date) or Feb 13. I would propose Feb 20 (or 21) to be able to include some work that might happen at the Brno Hackfest. Writing documentation often means to find small usuability bugs that can be fixed easily and we shouldn't miss that chance. Regards, Johannes ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Proposed Freeze Change
On Tue, 2011-12-20 at 14:45 +0100, Andre Klapper wrote: Personally I prefer Feb 13 as past release cycles experience with last minute API breaks has shown that it's helpful to have the freeze on a Monday that is NOT a Tarballs Due day, so there is one week left to sort out all the stuff that broke. But maybe times have become less rough? Andre, thanks for following up on this. One week in either direction doesn't make a huge difference to me. I think our freezes have always coincided with Tarballs Due Mondays, but I don't have a perspective on how much pain that's cause the release team. I do think doing it on a Tarballs Due Monday make it easier to remember. Tarballs are due. Please make a release and then stop making changes today. -- Shaun ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Proposed Freeze Change
Picking this up again, finally. Sorry that it took so long. On Wed, 2011-09-28 at 13:21 -0400, Shaun McCance wrote: The main problem is developer awareness. Developers don't know exactly what constitutes a change that the documentation team cares about. And it's sometimes hard to keep of which freezes and announcement periods are in effect. Two-fold proposal: 1) Drop the UI change announcement period. It was a nice idea at the time, but it just doesn't help me much. It's not worth the developer mental overhead. 2) Merge the old feature freeze and the UI freeze into one big freeze and call it something that suggests you're not supposed to make changes. I've been calling it THE freeze. I'm not good at naming things. Beta freeze? Software freeze? *** CURRENT SCHEDULE FOR 3.3.x: *** As per https://live.gnome.org/ThreePointThree#Schedule Jan 16: String Change Announcement Period Jan 16: UI Change Announcement Period Feb 06: API/ABI Freeze Feb 06: Feature Freeze Feb 20: UI Freeze Mar 05: String Freeze Mar 19: Hard Code Freeze *** SCHEDULE PROPOSAL: *** The release-team decided to propose the following: * drop UI Change Announcement Period, * merge String Change Announcement Period, API/ABI Freeze, Feature Freeze, and UI Freeze into The Freeze. * keep String Freeze and Hard Code Freeze as is. *** QUESTION 1: INCLUDE STRING FREEZE TOO? *** However several posters in this thread have mentioned that they would also like to see the String Freeze included in The Freeze as a frozen UI also implies mostly frozen strings. However smaller fixes could still be applied easily with the release team's proposal. *** QUESTION 2: DATE FOR THE FREEZE? *** As the proposal above does not mention a date for The Freeze I propose either Feb 20 (current UI Freeze date) or Feb 13. Personally I prefer Feb 13 as past release cycles experience with last minute API breaks has shown that it's helpful to have the freeze on a Monday that is NOT a Tarballs Due day, so there is one week left to sort out all the stuff that broke. But maybe times have become less rough? Comments? andre -- mailto:ak...@gmx.net | failed http://blogs.gnome.org/aklapper ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Proposed Freeze Change
Op Ma, 2011-10-10 om 18:26 -0400 skryf Johannes Schmid: Hi! Consequently the same question goes for String Change Announcement Period - CC'ing gnome-i18n as I'm wondering if translators still consider the String Change Announcement Period useful. I'm all in favour of dropping it, for the following reasons: 1. I doubt it is really useful for translators 2. I think only a minority really announce new strings 3. It would be easy to do something automatic from l10n.gnome.org if needed Agreed, can we just merge the String freeze into the The Freeze, too? Because if you cannot change UI/features it is unlikely that strings will change and if they do, as Shaun pointed out already, you just sent a mail. I18n didn't block many strings the the last cycles and it oftens gives us the oppertunity to fix the string (english, type, whatever) before it is commited. Personally the string announcement period hasn't been something I tracked really, so I'd be fine with dropping it, also for the reasons that Claude mention. To merge everything sounds attractive to some extent, but my impression is that the time after UI/feature freeze is when we change the way we look at our software and some things are more likely to get attention: - old, easy bugs, like strings - typos in new text - disambiguating context needed - things not marked for translation From experience we know that strings are not all that unlikely to change despite UI/feature freeze. So the idea of just send an email doesn't reflect the need we have for a real freeze, which means that there must be some time where people actively look at string related changes to finalise them. If we manage to get people to give attention to that before the freeze, we'll be doing very well. There will always be room for important freeze breaks. But if this becomes a situation where the first half of the string freeze is when strings are fixed, then translators will just be loosing out on half a freeze. Friedel -- Recently on my blog: http://translate.org.za/blogs/friedel/en/content/firefox-maybe-now-most-popular-africa ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Proposed Freeze Change
On Mon, Oct 10, 2011 at 07:29:47PM +0200, Claude Paroz wrote: Le lundi 10 octobre 2011 à 18:17 +0200, Andre Klapper a écrit : (...) Consequently the same question goes for String Change Announcement Period - CC'ing gnome-i18n as I'm wondering if translators still consider the String Change Announcement Period useful. I'm all in favour of dropping it, for the following reasons: 1. I doubt it is really useful for translators 2. I think only a minority really announce new strings 3. It would be easy to do something automatic from l10n.gnome.org if needed That is not the purpose of the string change announcement period. It is to slow down the rate of string changes as manual work is needed. It should *not* be automated, the manual bit is on purpose. -- Regards, Olav ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Proposed Freeze Change
On Mon, 2011-10-10 at 18:26 -0400, Johannes Schmid wrote: Hi! Consequently the same question goes for String Change Announcement Period - CC'ing gnome-i18n as I'm wondering if translators still consider the String Change Announcement Period useful. I'm all in favour of dropping it, for the following reasons: 1. I doubt it is really useful for translators 2. I think only a minority really announce new strings 3. It would be easy to do something automatic from l10n.gnome.org if needed Agreed, can we just merge the String freeze into the The Freeze, too? Because if you cannot change UI/features it is unlikely that strings will change and if they do, as Shaun pointed out already, you just sent a mail. I18n didn't block many strings the the last cycles and it oftens gives us the oppertunity to fix the string (english, type, whatever) before it is commited. I favor moving the string freeze up to The Freeze, because the freeze isn't really the freeze if you can still change strings in the UI. If you change the label on a button, that affects the help. (Yes, OK, things like schema descriptions don't affect the help, but still constitute a string change, but that's the exception.) Olav has a good point that the string change announcement period makes developers think twice about changes. But this would put string freeze up two weeks, which is some consolation. I think it's worth simplifying the schedule, because freezes and change announcement periods don't do us any good if developers can't keep track of them. -- Shaun ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Proposed Freeze Change
El dt 11 de 10 de 2011 a les 13:58 -0400, en/na Shaun McCance va escriure: On Mon, 2011-10-10 at 18:26 -0400, Johannes Schmid wrote: Hi! Consequently the same question goes for String Change Announcement Period - CC'ing gnome-i18n as I'm wondering if translators still consider the String Change Announcement Period useful. I'm all in favour of dropping it, for the following reasons: 1. I doubt it is really useful for translators 2. I think only a minority really announce new strings 3. It would be easy to do something automatic from l10n.gnome.org if needed Agreed, can we just merge the String freeze into the The Freeze, too? Because if you cannot change UI/features it is unlikely that strings will change and if they do, as Shaun pointed out already, you just sent a mail. I18n didn't block many strings the the last cycles and it oftens gives us the oppertunity to fix the string (english, type, whatever) before it is commited. I favor moving the string freeze up to The Freeze, because the freeze isn't really the freeze if you can still change strings in the UI. If you change the label on a button, that affects the help. (Yes, OK, things like schema descriptions don't affect the help, but still constitute a string change, but that's the exception.) Olav has a good point that the string change announcement period makes developers think twice about changes. But this would put string freeze up two weeks, which is some consolation. I think it's worth simplifying the schedule, because freezes and change announcement periods don't do us any good if developers can't keep track of them. +1! Having 4 weeks of THE freeze would be enough for translators. The release notes could also start earlier, etc etc Cheers, -- Shaun ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n -- Gil Forcada [ca] guifi.net - una xarxa lliure que no para de créixer [en] guifi.net - a non-stopping free network bloc: http://gil.badall.net planet: http://planet.guifi.net ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Proposed Freeze Change
[CC'ing release-team and gnome-i18n@.] On Wed, 2011-09-28 at 13:21 -0400, Shaun McCance wrote: In the past, we've had three points in the schedule to help: the UI change announcement period, the feature freeze, and the UI freeze. Feature freeze is gone from the 3.3 schedule, which confused me a bit, but I want to propose something different anyway. The main problem is developer awareness. Developers don't know exactly what constitutes a change that the documentation team cares about. And it's sometimes hard to keep of which freezes and announcement periods are in effect. Two-fold proposal: 1) Drop the UI change announcement period. It was a nice idea at the time, but it just doesn't help me much. It's not worth the developer mental overhead. 2) Merge the old feature freeze and the UI freeze into one big freeze and call it something that suggests you're not supposed to make changes. I've been calling it THE freeze. I'm not good at naming things. Beta freeze? Software freeze? I had wanted to do the freeze with the 3.3.5 release, which is where we would do feature freeze. But I fear it doesn't make sense to do it before the Brno hackfest. When we're in the freeze, you don't make user-visible changes anymore. No new supported formats or protocols or backends. No new UI. No changes to how a user interacts with the UI. You can fix crashes and address performance problems. In case you're worried this will stifle development, remember that you have 21 weeks to go wild. That's 80% of the entire cycle. And all you have to do to make a change is send an email (or if we go with Bastien's proposal, file a bug). In eight years, I only remember blocking one change proposal. For the time being I have added back a Feature Implementation Freeze to https://live.gnome.org/ThreePointThree for 3.3.5 (Feb 06th). I'd like to see a few more people (or at least more r-t folks) agreeing to 1) merge Feature Freeze and UI Freeze (which is at 3.3.90 currently) to UI and Feature Freeze and propose a date, and 2) whether to drop UI change announcement period completely. Consequently the same question goes for String Change Announcement Period - CC'ing gnome-i18n as I'm wondering if translators still consider the String Change Announcement Period useful. andre -- mailto:ak...@gmx.net | failed http://blogs.gnome.org/aklapper | http://www.openismus.com ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Proposed Freeze Change
2011-10-10 19:29 keltezéssel, Claude Paroz írta: Le lundi 10 octobre 2011 à 18:17 +0200, Andre Klapper a écrit : (...) Consequently the same question goes for String Change Announcement Period - CC'ing gnome-i18n as I'm wondering if translators still consider the String Change Announcement Period useful. I'm all in favour of dropping it, for the following reasons: 1. I doubt it is really useful for translators 2. I think only a minority really announce new strings 3. It would be easy to do something automatic from l10n.gnome.org if needed Claude +1 If I'd like to know if there is something new to translate, I go straight to damned-lies. Nothing else is needed. Regards Gabor Kelemen ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Proposed Freeze Change
Hi! Consequently the same question goes for String Change Announcement Period - CC'ing gnome-i18n as I'm wondering if translators still consider the String Change Announcement Period useful. I'm all in favour of dropping it, for the following reasons: 1. I doubt it is really useful for translators 2. I think only a minority really announce new strings 3. It would be easy to do something automatic from l10n.gnome.org if needed Agreed, can we just merge the String freeze into the The Freeze, too? Because if you cannot change UI/features it is unlikely that strings will change and if they do, as Shaun pointed out already, you just sent a mail. I18n didn't block many strings the the last cycles and it oftens gives us the oppertunity to fix the string (english, type, whatever) before it is commited. Regards, Johannes ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
