There is no release manager! There is no release manager!

paul beard paulbeard at gmail.com
Tue Oct 7 22:02:12 PDT 2008


On Tue, Oct 7, 2008 at 9:35 PM, Ryan Schmidt <ryandesign at macports.org>wrote:

>
> We don't need a roadmap at this time; we just need to release the work that
> has been done on trunk over the past year. After that, I don't think we need
> a roadmap either; we just need to make regular releases when there is new
> work on trunk to release.
>

absent a road map, how to decide what gets worked on, what, if any, features
get added/fixed/removed? Example: a packaging system so people on slow
hardware can stay up to date: important and useful but not to people with
newer/faster hardware. If developers/volunteers set their own priorities, is
it really a project? A community garden makeover has more organization than
that  it doesn't mean everyone gets a rake or watering can: tasks are
assigned based on what needs doing. But as we have seen with this niggly
little .profile issue, if no one owns it, no one fixes it. In a real
software development environment, developers don't always get to pick what
they want to work on: some icky stuff just has to be done. I couldn't get
arrested as a programmer, but even I know that.

To be clear, I'm not saying MacPorts as a project is a waste of time or that
the volunteers are a buncha slackers. But it is a little frustrating to see
so many people come into the community and face the same issues. How long in
actual time would it take for someone with a commit bit to add the fix to
.profile and cut a new release? An hour? Two? 24? Weighing that against the
potential users who have been turned off or frustrated by the experience of
a known issue, simple to fix, left unfixed, and I wonder if MacPorts is just
for the developers who can grope around in its guts.

Do we have any idea how many people have downloaded it? How many sync their
trees and download new portfiles?


> I would be a bit concerned about a newcomer preparing the releases. I would
> hope that the release manager would have an intimate familiarity with
> MacPorts, for which I think you need experience maintaining ports and maybe
> even contributing some patches to base as well. At least, releases would
> have to be tested by people familiar with MacPorts before the final release
> is made. Well, after a year's worth of changes we're going to need some
> release candidates before the final release anyway.


I wasn't considering volunteering ;-)

>
>
> For the next release, I think we need version 1.7.0, not 1.6.1, because
> there are countless new features and a year's worth of bug fixes. That much
> work deserves more than just a bugfix version number increase. That means we
> release from trunk, not the 1.6 branch. A concern of mine is that the 1.6
> branch contains some work that was done only there and not on trunk. I
> believe some of it was done on trunk in a different way, but I don't know if
> all changes from the 1.6 branch got put in trunk. Someone needs to figure
> out whether it was, and if not, identify what needs to be ported from 1.6 to
> trunk. Ideally that would happen before a 1.7.0 release.
>
>
>
No argument there. It does seem like not cutting more regular releases has
created some work there.

-- 
Paul Beard / www.paulbeard.org/
<paulbeard.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/macports-users/attachments/20081007/ac3f3519/attachment.html 


More information about the macports-users mailing list