The Trinity Paper Cut project never got officially launched after 3.5.12. I would like to see that project receive official attention. Many bugs were quashed for 3.5.13, but I can't test any bug reports I filed until I build and install packages. I have received only a few notices that any of the bug reports I filed received attention.
 
Dealing with bugs is one of the main priorities for this release. Sadly the last release was rushed out the door. While something like 40+ bugs were squashed, there are many more to deal with.

I would like to see a relatively dependable 6 month release cycle. Maybe even one or two 3 month cycles until the Paper Cut project significantly reduces the bug list. That means biting only what can be chewed.

3 Month cycles are no feasible. It takes 6 weeks to do testing and QA, not much time to deal with anything improvement wise.

6 months seems to be the generally accepted release schedule, and it fits in similarly with the release schedule of other projects in the F/OSS ecosystem. Planning for a 6 month release gives us time to do what we need to do and have a good release
 
The cmake port was unexpected and caused a long delay in the 3.5.13 release. That kind of regular delay will be bad for public relations. If 3.5.14 and 3.5.15 focused on bug quashing and each was released in a 3 month cycle, that keeps Trinity in the news and shoDarrell


---------------------------------------------------------------------
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net
For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net
Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/
Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
ws potential users that developers are serious.

 
We veered off the 6 month cycle one time, I think it would not be good to do 3 month releases.

I am not asking for a rapid release cycle. Only to consider a couple of quick releases that focus entirely on serious bug quashing.

Lets have one really good release and squash them all :)
 
The 3.5.14 road map implies about 30 days of bug quashing before migrating to GIT. That's good.

I imagine the shift from SVN to GIT will require a one-time massive download to create and initialize a local GIT tree. I imagine the new GIT tree will be about the same size as the SVN tree and will be 4 to 5 GB in size. That translates into a long download session for many people. Is there a way to convert a local SVN tree to GIT without the long download?

you'll probably have to just download it, sorry :[


Calvin Morrison