2 Nov
2011
2 Nov
'11
11:10 a.m.
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(a)lists.pearsoncomputing.net
For additional commands, e-mail:
trinity-devel-help(a)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