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

[Ryan Schmidt]

On Oct 8, 2008, at 00:02, paul beard wrote:

> On Tue, Oct 7, 2008 at 9:35 PM, Ryan Schmidt 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.

The .profile issue has been fixed for a long time on trunk. We just  
need to make a new release so new users can get their hands on it.  
Having never done a release before is what's keeping me and I imagine  
everyone else from attempting to do so. Juan, who previously did our  
releases, doesn't have time to do it anymore. I have not yet myself  
attempted to follow all the steps in the release document to see how  
hard it would really be, hence I can't tell you how long it would take.

I'd also like to confirm that MacPorts is really a project, and that  
this is a real software development environment. :) But since the  
developers aren't getting paid for it, I still say they will work on  
whatever they want, or even nothing at all when other  
responsibilities take priority. If a feature is important enough to  
someone, they will fix it, or motivate someone else to fix it, or try  
to help it along in some way. For example, most features need to be  
planned and thought out ("exactly how will this work?") before any  
programming can begin. Even non-programmers could do some of that  
planning, or help drive a discussion that leads to a design proposal,  
etc.

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

I don't know if we track that information. I haven't seen any  
statistics.

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

Yes, but Julio Biason did volunteer, but I haven't seen his name on  
the lists before and I can't find any ports he maintains, hence I  
don't know his qualifications. Though he did volunteer, which is an  
important qualification in itself. :)

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

Yes. Once we get 1.7.0 out, hopefully more regular releases can  
follow again, bringing us back into the "release early release often"  
strategy so popular with most open source projects.