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
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
