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
!!