On Wed, Jul 16, 2014 at 11:10 PM, Peter Suter <[email protected]> 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 [email protected]. > To post to this group, send email to [email protected]. > 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/trac-dev. For more options, visit https://groups.google.com/d/optout.
