On Mon, 2013-12-16 at 09:14 +0100, Robert Helling wrote: > On 16.12.2013, at 00:40, Dirk Hohndel <d...@hohndel.org> wrote: > > Dirk, > > > Something like: a 4 weeks window to merge new features after a release. > > Then 8 weeks of bug fixing, documenting, translating, and finally a week > > to do the release. Which gives us quarterly releases. > > I am a bit hesitant about this. For dynamic people like you and the two > T’s this might work. But for slow people with little continuous time to > contribute this means that two thirds of the time there is only testing > and bug fixing.
I don't think that's really a big issue - if you look at the way this works in other projects, the idea is that you work on the features that you are interested in "whenever you have time" and simply submit them during the next merge window. During the stabilization phase you should have plenty of time to make sure your code applies cleanly (and works) with the latest release and then be able to submit it once that release is out. > On my personal to do list, there are a number of bigger things that I > would like to try to realize or at least get into a working state (e.g. > photo events that link jpegs into into the profile, vpmb, getting the > planner to a state that makes you reconsider, improving printing) that > all have in common that they are impossible for me to realize in a > single afternoon that I can spend on subsurface. I have not touched any > of those in recent times because you made quite clear that you wanted > 4.0 out in a finite time frame. Most of these sound very interesting. So just pick one, work on it, and talk to me when you are ready to submit them. As I said, I want to figure out what works for us - you may have noticed that I didn't suggest a two week merge window... maybe it'll be 6 weeks / 6 weeks or something like that. > I guess I could make significant progress in say a couple of > afternoons. But with your schedule all those afternoons would have to > fall in a four week period until the end of January. And with the > holiday season coming up, miracles can happen but also not. Since then > for the next two months it would be morally forbidden to spend time on > such things that would at least for me mean none of those ideas will > ever happen as I will rather be sending bug reports and maybe to > occasional one line fix. No, you would not be forbidden to spend time on these. They just might not get pulled into master. > I guess this would be totally different if you doubles all the times > and aimed for a release twice a year (or even better two releases per > year each with two months bug fixing and documenting efforts before). Twice a year seems to slow for a project of our size (and given the number of ideas that people are contemplating). The six months since the last released have already lead to a massive drop in visibility of Subsurface for people looking for dive log software... search ranks are brutal :-) > Of course, this is your decision. I think it’s a perfectly fine > decision to stick with the one per three months plan given that the > vast majority comes from the very active people and this schedule fits > them fine. All I am saying is this plan does not fit my personal > situation very well. So let's work on making sure that this works for not only the top three or five developers but for the top 30 :-) /D _______________________________________________ subsurface mailing list subsurface@hohndel.org http://lists.hohndel.org/cgi-bin/mailman/listinfo/subsurface
