Hi Harry, Harry van der Wolf wrote: > I'm still lost.
sorry for the confusion. my fault, I have not made the official announcement yet (waiting for Bruno to confirm). > To what branch do I now have to apply patches/changes? > 2009.2 has been created a couple of days ago (or so). > Thereby, the standard trunk has become 2009.3 being the unstable development > trunk. 2009.2 was created nine hours ago. the how and why is all explained at [0]. The only thing I did not do yet is announce because I want my tarball to be verified by Bruno who is mentoring me in the process. > Now, when I apply patches I will do that to the trunk, thereby to the > unstable development version (do I?). I've seen your commits to trunk. trunk is development, so yes, you committed to the "unstable development version" which is synonymous to trunk. With the new release process there is no trunk freeze. Committer need not worry about release branches. In fact, now that 2009.2 is branched out, one of our GSoC students could start integrating their code in trunk. Any volunteers? > Is there now a "super admin" who decides what goes into 2009.2 (being the > stable one). If so: Is there a planning when we going life with this stable > one and "what's in it"? there is no "super admin", or at least we have not discussed it. there is a "release manager", and for 2009.2 I am that person. I took ownership/responsibility for the release by branching out. The plan is to go live with this stable ASAP, with what is in it now. the mandatory condition to go live is: 1. it builds on the main supported platforms (Linux/Windows/OSX) 2. it does not break existing functionality from the previous release (unless the breakage is intentional) nice to have: 1. fixes for the priority 9 open bugs in the tracker [1] 2. other bug fixes 3. translations > W.r.t. to the stable one and when not having a super admin: Do I have to > apply "stable" changes like the dutch translation from this morning and a > Xcode related Hugin version upgrade to both trunks? use common sense: if it is a bug fix or a translation, doing it to both is nice. if it is a feature, add it to trunk only. part of my responsibility as release manager is to make sure that changes applied to trunk only and that are relevant for the release are applied to the release branch as well. and after the release i will make sure that changes applied to the release branch only and that are relevant to trunk will be applied there too. > W.r.t. the latter: I set versioning for XCode to 2009.3 (the trunk): I now > see that this patch has also been applied to the stable trunk 2009.2, but > that's not correct, which means it's not a stable change. oh, stupid me. I just blindly copy/pasted the change without thinking. Fixed it. > Please give some advice. I see the changes you did and tried to document them (steps 3.c / 4.c in [2]). I have no Mac, so I can't verify if I am correct or if other things need to be done. Feel free to update the wiki document. > A completely and utterly lost, > Harry I apologize again for the confusion. If you have specific questions, ask. The goal is to document everything in [0] so that nobody gets lost in the future. Yuv [0] <http://wiki.panotools.org/Development_of_Open_Source_tools#Release_Cycle> [1] <http://sourceforge.net/tracker/?func=&group_id=77506&atid=550441&status=1> [2] <http://wiki.panotools.org/Development_of_Open_Source_tools#Branching_Out_For_Release> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/hugin-ptx -~----------~----~----~----~------~----~------~--~---
