[bt-devel] next release, releases, project management

Gary Holmlund gary.holmlund at gmail.com
Wed Sep 1 10:20:11 MST 2010


  Martin,

I guess I have been to busy lately. I missed reading this email 
earlier.  See comments below.

On 8/29/2010 12:19 PM, Martin Gruner wrote:
> Hi all,
>
> I'd like to address several topics. After a private discussion with
> Jaak, I'd like to make several proposals.
>
> Next Release
> ##########
>
> We should release a 2.7 release with selected backported bugfixes and
> features. Separately, I will release a 2.8+gitXYZ release as a MacOS
> .dmg file for mac users to test. Ok?
Agreed.

> Release Cycle
> ###########
>
> We should decide on a new release cycle and document the agreement in
> the wiki. Jaak suggested a fixed schedule of 2 feature releases per
> year. Here's his suggestion:
>
> How about something like this (a very rough sketch):
>    Month 0   - Full release + formal start of development cycle
>    Month 3   - Release beta 1
>    Month 4   - Release beta 2 + Feature freeze
>                  (+ maybe branch stable-2.#)
>    Month 4,5 - String freeze (notifying translators)
>    Month 5   - Release release candidate 1
>    Month 5,5 - Release release candidate 2
>    Month 6   - Full 2.#.0 release + formal start of new development cycle
>
> I'd personally prefer 3 releases per year, but 2 is also ok with me. IMO
> it is important to have a fix, time-based release policy though, so
> releases would be made even if only few new features are available. What
> do you think? Should the cycle be longer, shorter, or should we use
> something else? I'm especially interested in opinions of people who
> actively contributed in the past, or will do so in the near future.
> Let's try to get a consensus soon.
Releases twice a year is reasonable to me with a couple of strong 
suggestions:
   1. Also recognize that bug fixes for the previous release are 
important and may cause a formal release.
   2. Ubuntu and Fedora are on a 6 month release cycle. Fedora is a 
little later than Ubuntu. I would like to time the formal releases so 
they are  in time for inclusion in the next release. I am not sure of 
those dates, but it probably means June and December. Perhaps Jonathan 
Marsden could confirm this.
> Release Manager
> ##############
>
> If we can agree on a new release policy, I want to suggest that Jaak
> will take on the responsibilities of the Release Manager. He already
> agreed to take this responsibility if we have a consensus.
This is fine with me.
> Project Management
> #################
>
> In the past months, I was not able to contribute to BibleTime's codebase
> substantially, and I expect this situation not to change any time soon.
> In the discussions we had about release cycle and Git migration, we had
> differences of opinion, and I feel that it is no longer the time for my
> opinion to be weighed in a special way regarding BibleTime as a project.
> Gary and Jaak have been the people contributing most substantially in
> the recent months, so in my opinion their voices should be heard in the
> first place regarding strategic, technical and other decisions about
> BibleTime. I don't know if we need a formal project manager, but if we
> do, I suggest that one of them (or both together) take that
> responsibility. What do you think?
The issues with release management and project management seem to 
overlap a lot and I think a single person would be better than more than 
one. I would be happy if Jaak wants to do this.

I must say that I have been very busy with work in recent months and 
this has limited my development on Bibletime. We have passed our 
"Implementation Complete" milestone now and the pressure is off. I can 
probably make some bigger contributions now, but I don't have a strong 
sense of what should be done next. Perhaps we could have some planning 
discussions in the near future.
> This does not mean that I want to retire from BibleTime, but I need to
> draw the consequences of what is. My hope is that BibleTime will be
> developed with a strong vision, motivation and strategic leadership, and
> I'm not the person to provide all that at this point. I hope to keep
> working on MacOS support and, if time permits, also contribute new
> features and bugfixes. Maybe also advice on why things were done the way
> they are, or special problems that I know or solved in the past.
>
> Let me also say thank you for the great spirit of cooperation and
> fellowship that you all contributed towards at BibleTime, and for all
> contributions and time spent working on BibleTime. And for the respect
> that you showed to me when we had disagreements, even if there is
> nothing a project manager can do to enforce their decision in an
> OpenSource project (as opposed to a boss at work). I hope and pray that
> it will stay like this with new people being responsible as well.
>
> May God bless you all,
> best regards,
>
> mg
Martin, thanks for all your work over the years.

Gary



More information about the bt-devel mailing list