New MacPorts release and immediate future plans

[Juan Manuel Palacios]

	Evening all developers!

	First off, I'd like to apologize for being so inactive lately, a  
somewhat forced hiatus has kept me away from MacPorts, and most of my  
online life for that matter, for the last couple of months. I  
understand how that may seem like I've lost interest in the project,  
and in my PortMgr position, but I can assure you that's not the case.  
The issues that were holding me back have now been cleared to a large  
extent so I should be considerably more available from now on.

	I am glad to tell you that we've had some interesting activity  
lately, even though it may seem to most of you like things have  
largely stalled. I can assure you that's not the case either. In the  
past month those of us who volunteered to be GSoC08 mentors have been  
working hard to put together our summer plans, and I'm glad to say  
that things are looking interesting.

	I am most proud to inform that we received not only a high number of  
applications (always a good thing), but also some very solid ones from  
more capable students than we could harbor. As a result will be  
conducting development with our four alloted students on key areas of  
the mid to long term future of MacPorts:

1) Logging support, per my proposal at http://trac.macports.org/projects/macports/wiki/LoggingProposal 
  (hopefully, as it is explicitly stated in the proposal itself, this  
work will help open up the doors to binary packaging done the right  
way, something that's been debated here quite a bit lately);

2) MacPorts Web Application (a.k.a. MPWA), which among other things  
will hopefully evolve to process the result of log submissions (task 1  
above) to provide real time information of the status of our ports tree;

3) MacPorts Framework, an initiative to endow MacPorts with a high  
level API written in Cocoa to open up the doors to a myriad of  
possibilities, including things like a Cocoa GUI

4) Root privileges, to make safer and better use of the powers we're  
granted through sudo to run in a more secure environment

	We learned quite a bit from last year's GSoC experience, so this time  
round we're taking the necessary steps to ensure a proper use of  
resources and that the deliverables of this work are properly seen  
through to completion and integration into our shipping product.

	Now, as for the immediate future of MacPorts, I think we all agree  
the time is ripe (or more than) for a new quick release that'll  
incorporate many of the recent enhancements and bug fixes trunk has  
seen recently. I've been collecting ideas and roadmap suggestions for  
what should go into this new issue of MacPorts, but I have been away  
for a while and therefore it's easy for me to miss a thing or to. So  
I'd love to hear what any of you has to say about a still theoretical  
1.6.5 release (what should go in, what should not, etc).

	And about the release number: I was originally aiming for a small  
1.6.1 which never took place, and a lot has happened since but maybe  
not enough for a 1.7.0. The main issue with these numbers is that  
we're still not working on a release driven cycle; for that reason  
mostly, our release numbers are mostly meaningless at present and only  
indicative of where we feel we are on a very subjective timeline. This  
is something many have pointed out as in need of fixing, and I'd just  
like to say that I'm strongly seconding that initiative.

	We're not making any API incompatible changes at present, so our  
numbers will still be arbitrary to certain degree. But hopefully the  
work that will be put into GSoC and other initiatives too will give us  
enough material to at least conduct a feature-driven release cycle.

	In any case, I propose that from now on we also try to adopt a  
schedule for minor, bug fixing releases, even if a loose one, so that  
after a given number of weeks/months we force ourselves to re-evaluate  
the state of trunk and the current release branch to asses what is  
ready for general consumption and/or in need of a broader testing  
audience. This will also help us fight the perception of a stale  
project.

	What should that schedule be? What new features will go into major  
releases and which ones into minor releases? Hopefully answering those  
questions will encourage us to put our Trac roadmap to better use,  
something that has been criticized lately too.

	For the moment, I propose we do 1.6.5 with bug fixes against what's  
currently shipping in 1.6.0, including (but not limited to):

-) my postflight installer bug (already fixed in the release_1_6  
branch);
-) what's been done on universal building and choosing of SDK && MDT;
-) improved fetching code;
-) improved dependency handling;
-) improved selfupdate target (my part on this work is done).

	I'd love to hear feedback on any and all of the topics touched in  
this mail, but at least on what's relevant for 1.6.5. I'll create an  
appropriate milestone for this new release so that we can start  
classifying tickets accordingly.

	And this is already a bit of a long mail, as usual for me, so I'll  
cap it here and wait for your feedback, hoping you're not still soar  
at me for having disappeared!

	Regards,...


-jmpp