New MacPorts release and immediate future plans

[Juan Manuel Palacios]

On Apr 27, 2008, at 3:01 AM, Ryan Schmidt wrote:

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


	Hi Ryan, it's good to be back!

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


	As said, release numbers are mostly arbitrary, so we can go with  
whatever we want. And by popular demand, lets indeed make it a 1.6.1  
release (still), 'cause even though much has happened since 1.6.0 it's  
all been about bug fixing.


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


	Gattaca-like Portfile cleanness is absolutely a maintainer's choice  
(one that I'd make, but on a personal basis), so I agree we shouldn't  
waste people's time with such pedantry and thus deter them from  
reading what would otherwise be a useful report on real warnings. On  
this note, I second moving to:

-) warning of trailing whitespace only when the last line character is  
a backslash (http://trac.macports.org/attachment/ticket/14799/portlint.tcl.trailing-whitespace.diff 
), as these are mostly unnoticeable to humans and could lead to real  
problems with the Portfile;

-) not advising how the Portfile should look like, i.e. blank lines,  
as this is easily one of the most personal things of all and we have  
no business dictating it (http://trac.macosforge.org/projects/macports/attachment/ticket/14799/portlint.tcl.blank-lines.diff 
);

-) not advising on patchfile naming in any way (either if that's patch- 
*.diff, patch-*, *.diff or *.patch) at the lint level. From the very  
beginning this was only a suggestion that most of us agreed on, so we  
can still keep it in the guide and elsewhere as such, a suggestion;  
but it was just that, a suggestion, so I really don't think we have  
any business annoying a maintainer who, after reading the guide and  
what-not, has still chosen to name his patches in whatever other way.  
So my take on this particular issue is that we should remove all patch  
naming checks from lint, and as a direct result any [file exists foo]  
checks, which would instantly resolve Bill's comments at the very end  
of that ticket.

	So, all in all, I'm seconding the first two patches and vote for a  
reworked third one per my comments, even though my personal taste  
would be against them (I'm not trying to say I'm special or anything,  
but rather emphasizing that our personal tastes are just that,  
personal).

	Regards,...

-jmpp

PS: The 1.6.1 milestone has been created, http://trac.macports.org/milestone/MacPorts%201.6.1 
  (bit woot to Bill for our new URLs!). Tomorrow I'll work on filing  
1.6.1 relevant tickets into it, getting a ChangeLog together and  
addressing some other comments in this thread, but my schedule  
shouldn't keep anyone else from doing any legwork if you already have  
some tickets handy.


> 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