On 26 October 2012 23:38, Marcus (OOo) <marcus.m...@wtnet.de> wrote: > Am 10/26/2012 11:20 PM, schrieb jan iversen: > > On 26 October 2012 23:06, Marcus (OOo)<marcus.m...@wtnet.de> wrote: >> >> Am 10/26/2012 07:43 PM, schrieb Andrea Pescetti: >>> >>> Rob Weir wrote: >>> >>>> >>>> 1) release new languages via lang packs only for now >>>>> 2) release full installs, but for only these new languages >>>>> >>>>> >>>> I don't see a big difference between a langpack and a full install in >>>> this case, so I'd go for full installs, unless releasing langpacks helps >>>> in communicating that these are "late" additions and that full installs >>>> will come with the next release. >>>> >>>> Can we really skip the release process? PO files == source, right? >>>> >>>>> >>>>> >>>> Yes, not exactly but quite (PO files are not taken verbatim into source, >>>> but they are imported and influence resource files which are in the >>>> source tree). >>>> >>>> Maybe a question for legal-discuss if we're not certain. >>>> >>>>> >>>>> >>>> If in the end we have consensus on releasing new languages for 3.4.1 >>>> instead of making a new release, indeed we will ask. >>>> >>>> How do we want to handle this on an ongoing basis? New point release >>>> >>>>> for every new language? Every 5 new languages? It is certainly good >>>>> for volunteers to get the encouragement of a fast turnaround for their >>>>> work. But this is the same for a C++ programmer. >>>>> >>>>> >>>> There are big differences here, that are also the reason for me to >>>> consider releasing these new languages as soon as possible: >>>> - A translation is often done by a team; if we can publish it >>>> immediately, the team can the be involved in other activities like >>>> revamping the N-L website, local promotion and so on; if we wait too >>>> much, we risk to have no volunteers for the following release. >>>> >>>> >>> Really? I'm not that convinced that this would happen. When we >>> communicate >>> from the beginning when new loalizations will be released then everybody >>> should be able to understand and handle this. >>> >>> >>> - Releasing a new language is totally risk-free: a new language can't >>> >>>> break functionality in OpenOffice, while any feature could have bugs and >>>> needs more qualified testing. >>>> >>>> >>> Besides the comment from Jan I remember a case from the old OOo project. >>> There were some translations for the names of Calc functions that got the >>> same name but had to get (slightly) different names. The result was that >>> there were 2-3 sum, 2-3 average, etc. functions. This was also - more or >>> less the only - reason for another respin for a OOo RC; 3.2.1, 3.3.0, I >>> don't remember anymore. >>> >>> So, the risk of new languages may not be high but I wouldn't say it's >>> totally risk-free. >>> >>> >>> In the end, I wonder whether the best solution is to get into a steady >>> >>>> release cycle of quarterly releases (every 3 or 4 months)? >>>>> >>>>> >>>> +1 >>> >>> IMHO a regular release schedule is a very good idea. Then everybody can >>> cope with this, can see when the next version will come and we can plan >>> with a regular release plan (when to branch, freeze, localize, etc.). >>> >>> Of course the timeframe will need some discussions to find the right one. >>> >>> Previously it was tried to release every 6 months a new major release and >>> every 6 months a point release. So, with overlapping there was a new >>> release every 3 month. Maybe a good timeframe to continue? >>> >> >> +1 to a relatively fixed time frame for new releases. Not only developers >> benefit from that but also end-users ! >> > > Right > > > However do we have the logistic in place to handle ideas/request/bug fixes >> with these short intervals. It would mean (in my opinion) that we have an >> > > OK, maybe the following fitts better to our current situation. Every 6 > months a new major release and a point release on demand - enough new > languages, urgent/severe bugfixes; that means outside a regular release > plan.
+1 > > > open catalog (new development) for 2-3 releases and have to prioritize >> within a limited timeframe what goes where ? We should also consider to >> apply a field in bugzilla, "targeted for version". >> > > That's already existing. Just look for the "Target Milestone" field. I think it is not really used (I might be wrong) but with frequent releases we should use it intensively, because today those who submit a bug must be pretty disappointed, I looked at a bug the other day, dated 2007 which are still a bug. > > > I really like the idea, but it has a tendency of killing long term >> developments, because they are hard to put into this framework, so we need >> something in the middle. >> > > When we plan which new and planned feature goes into what release should > work. > I think I did not express it correctly, resources tend to be used for short term targets (next release, high motivation, lets make it folks, and after that we do all the rest). > > Marcus > > > > > This could be a solution too. In this case we would have the problem of >>> >>>> choosing what to translate (3.4 or 3.5? probably we would ask new >>>> volunteers to focus on strings that will be in the next release, even >>>> though they aren't frozen yet). >>>> >>>> >>> In any case we should continue to release new languages; regardless if >>> major or point versions. >>> >> +1 THAT IS IMPORTANT...that is to me a major difference to commercial products !!!! > >>> Marcus >>> >>
