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