Final steps for 1.6

Juan Manuel Palacios jmpp at macports.org
Fri Dec 7 09:38:09 PST 2007


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 at lists.macosforge.org
>> http://lists.macosforge.org/mailman/listinfo/macports-dev
>



More information about the macports-dev mailing list