On Wed, Jul 16, 2014 at 11:10 PM, Peter Suter <petsu...@gmail.com> wrote:
> On 17.07.2014 07:06, RjOllos wrote: > >> On Wednesday, July 16, 2014 12:29:43 PM UTC-7, cboos wrote: >> Speaking about that (0.12.6 / 1.0.2 / 1.1.2), I'm ready to give any >> advice or even build the Windows parts, if needed. So Ryan, Jun and >> Peter, don't hesitate to ask me if you need anything. >> >> > Maybe the main question is this: > > > On 14.07.2014 07:43, RjOllos wrote: > >> For the latter we'll certainly need assistance since I'm sure we don't >> have permissions to publish the release in various places. >> > > I.e. at the very end, how would we do the update steps in: > http://trac.edgewall.org/wiki/TracDev/ReleaseChecklist#Finalizetherelease > > > >> Thanks! It would be great to get a release out. >> >> I currently have about a half dozen tickets in progress. What I'm >> thinking is: >> >> - Close out those tickets by Friday 07/25 >> - Spend the next few days reviewing the tickets that were closed in >> the release, testing, trying to catch anything that may have been >> overlooked initially. String freeze on Monday 07/28. >> - Allow the two weeks for translators to update the catalogs. >> - Prepare the release on 08/08 or later. >> >> How does that sound to the other devs? >> > > Sounds ok. > > Though I think tickets should not hold up a release except in rare cases > (e.g. new bug in old functionality). Just move them to the next milestone. > At this point, late/no releases are more damaging to the project than > imperfect releases. > I need to commit a fix for a regression in #11610, and I think there is one other small issue, but I can't recall at the moment. I can accelerate the timeline and wrap things up by this Saturday. That would give us the following timeline, 1. Close out those tickets by Saturday 07/18 2. Spend the next few days reviewing the tickets that were closed in the release, testing, trying to catch anything that may have been overlooked initially. String freeze on Monday 07/20. 3. Allow the two weeks for translators to update the catalogs. 4. Prepare the release on 08/01 or later. I don't know the process well, so I can't comment on whether (3) can be sped up. > I'd also support a much simplified process, if reasonably possible via > automation, otherwise via documentation and reduced flexibility / quality > if needed. > > I'm personally not a user / contributor of translations and have never > looked into that process, so maybe I'm totally wrong, but for example to me > it would be acceptable to drop string freeze delays and force translators > to use SVN etc. (or whatever process reduces complexity the most **for the > release coordinator**). > > > -- > You received this message because you are subscribed to the Google Groups > "Trac Development" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to trac-dev+unsubscr...@googlegroups.com. > To post to this group, send email to trac-dev@googlegroups.com. > Visit this group at http://groups.google.com/group/trac-dev. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to trac-dev+unsubscr...@googlegroups.com. To post to this group, send email to trac-dev@googlegroups.com. Visit this group at http://groups.google.com/group/trac-dev. For more options, visit https://groups.google.com/d/optout.
