New MacPorts release and immediate future plans

[Ryan Schmidt]

Welcome back, jmpp. I'm quite relieved to hear from you!

I don't believe in these .5 releases for the sake of .5 releases...  
especially in the third digit. ("System 7.5" sounds cooler than  
"System 7.2" but "System 7.1.5" doesn't sound that much more  
impressive than "System 7.1.2".) Either call it 1.7.0 since it  
includes so much new stuff, or call it 1.6.1 since we're probably  
releasing from the 1.6 branch.

The new release should include the greatly enhanced port lint code  
which is already trunk, and we should also resolve this port lint  
ticket before the release:

http://trac.macosforge.org/projects/macports/ticket/14799

I would be happy to commit the three patches I attached there if you  
approve.

\r


On Apr 26, 2008, at 10:03 PM, Juan Manuel Palacios wrote:

>
> 	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