On Mon, Dec 5, 2011 at 5:48 PM, Timothy Pearson <kb9vqf@...> wrote: > > That would be much more managable. As you said it won't work for this > cycle, but it is a possibility for future releases. > > Tim > > Hi! By "this cycle" you mean the current 3.5.13 or else? I really didn't understand why the Nikolaus suggestion could not be done, i.e., only release some bug fixing packages in January, after the move to GIt and the renaming is completed?? I think that after the patches there are waiting now are integrated into trunk, it will not take more than a few days to do some proper QA before releasing the packages. So, it will be a 3.5.14 release, yes, but in fact it will not be a full release, only with some updated packages. As I said before, I think this approach has a few great advantages: - testing building and releasing from Git as early as possible - testing the first steps towards serious QA testing and assurance - no need to do much about release notes, etc., because it will be a minor release - it will look like Trinity is a dynamic project - and, more important, _looking more dynamic_ means much more community involvement and voluntary help, in many ways (take my word, I know what I'm talking about) If none of the above arguments works, then there is this: - it cannot get bad or be worse ! ;-) Another thing: " I don't want to place that kind of demand on our volunteer staff during the Christmas season " Ok, but maybe they will not be worried to do that extra effort?? So, yes it will mean some effort, but in the end, the outcome could only be good for the Trinity project. Or so I think. Jorge PS: Tim, one other suggestion: If you start talking that you can not do a release because "is not cheap, in terms of (...) money (to feed everyone's build computers with electricity)." then you can be sure no one will ever take the Trinity project seriously and believe Trinity could grow up by itself !!