On Dec 7, 2007, at 12:26 AM, Jordan K. Hubbard wrote:
I'm just curious, and I hope you'll pardon my attack of manager- ness here, but what [hopefully documented] list of objectives drives each release? In other words, how do you know when you're "done" for 1.6 or, perhaps more importantly, 1.7? Is it your personal TODO list, as you note below, or is there a more global project TODO list driving the release parameters?
Thanks,
- Jordan
It is no secret that our releases don't follow a documented plan and/ or set of goals, but I still defend what they add to our final product (because it's also no secret that you've adversed us doing releases in the first place ;-), even if only on the organizational front. Projects usually cut releases of their products because: a) They need to break backwards compatibility in some way. This is not our case nor is there anything in our sources currently pressing us to do something like that. Nevertheless, the 1.6.0 release will contain a small but important API change I introduced to make MacPorts scripting much much easier; now, writing a script for the macports1.0 API is as easy as loading the appropriate TCL package and then calling "mportinit", nothing more. That paved the way for the revival of the regularly updated http://www.macports.org/ports.php page, but this time round *way* improved with proper error detection and reporting for the DB updating job (precisely why I introduced the API changes, cf. http://trac.macports.org/projects/macports/browser/ trunk/base/portmgr/jobs/PortIndex2MySQL.tcl , which will not work with pre-1.6 sources). I hope it'll also pave the way for many more and simpler scripts that will help us achieve more things (hint: build farms!). b) A documented plan and/or set of goals has been completed, which probably can't be applied to us under strict formality either. This is likely why a set of Trac milestones to organize our "base" development on our Roadmap has hitherto been less than satisfactory, I know. This would, I agree, basically render our releases (and release numbers, for that matter) as largely arbitrary. Nevertheless, it is still not a personal TODO list of mine what has been driving each release to this moment, but rather public discussion on this list that I always try to encourage. Every so often after a release has been put out the door, we gather here to discuss the code delta existing between the latest release and trunk, and based on that we decide as a group what should be handed out to users and what should be kept in for further testing and polishing. It was my feeling that a lot of already-well-tested code and resulting improvements to MacPorts on many many fronts (cf. http:// trac.macports.org/projects/macports/browser/trunk/base/NEWS , all of it pertaining to the 1.6.0 release) had accumulated in trunk since the 1.5.2 release, and therefore I pushed for 1.6.0. Added to that, but certainly by no means "least" as they say, is our 100% refreshed website (which drives us back to point a) above) and our new guide at http://geeklair.net/macports_guide/ , next to be moved to Mac OS Forge servers with automatic regen in place (just as the new website). All these new goodies seemed to me like a good set of things to package with a new release, even if the release itself has been delayed due to testing and polishing. So, all in all, do we have an official and formal roadmap driving the planning and putting together of our releases? Certainly not. On the other hand, are our releases little more than self-indulging treats....? The above explanations help me say "certainly not" too ;-) I do hope to improve the current situation, however, and will try to put a more formal roadmap for 1.7. After reviving our website and documentation, which was my number 1 *top* priority, I plan to devote to logging support in port(1) and/or macports1.0 (cf. http:// trac.macports.org/projects/macports/wiki/LoggingProposal) and based on that start the work on automated builds that can be properly traced and logged (worth also mentioning too is that 1.6.0 will contain Eugene Pimenov's GSoC work on a much improved trace mode, which will help us even further in creating clean builds in automated fashion). So, here's hoping this reply didn't come off as much of a retort but rather an explanation of what we're doing... ;-) Regards,... -jmpp
On Dec 6, 2007, at 8:17 PM, Juan Manuel Palacios wrote:
My list of outstanding TODOs for the 1.6 release is almost empty after finishing what I committed in r31774, directly to the release branch: a rethought and rewritten postflight script to add PATH and MANPATH settings as appropriate to the user's shell configuration file. Please read the commit log and test the script, reporting any findings you have.
The only things that remain are selectively resyncing the branch with trunk and updating the proper License.html, ReadMe.rtf and postflight files in the files dir of the MacPorts port dir, for pkg installer creation. I plan to use svn:externals off of the release tag (once I create it) for the latter, rather than needlessly keep on duplicating those files across the repo. As for the former, selectively resyncing the release branch and trunk, I think there's nothing outstanding other than working out the differences between the postfight script on release and its trunk guise: on release we're still tweaking user shell configuration files and in trunk we're discussing James' additions to the /etc/ [man]paths.d/ directories, so those two fronts will likely remain decoupled for the time being. There's also James' "load" & "unload" new port(1) targets, which James explicitly requested remain only in trunk until further tested (which rules out the merger of Ryan's r31771, which if I understand correctly is a regression fix against the new targets). Am I correct? Anything I'm missing?
Thanks for your help in getting 1.6 out ASAP (it's been delayed enough already ;-). Regards,...
-jmpp
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev