[Adium-devl] Minor updates

Chris Forsythe chris at adiumx.com
Thu Nov 8 01:14:53 UTC 2007


On Nov 7, 2007, at 11:21 AM, Colin Barrett wrote:

> On Nov 7, 2007, at 8:25 AM, Eric Richie wrote:
>
>> On 11/7/07, Colin Barrett <timber at lava.net> wrote:
>> Just got an email on feedback complaining that we're updating too
>> frequently.
>>
>> BFD?  I realize from a lifecycle perspective it's probably too  
>> often, but otherwise this sounds to me like complaining because  
>> we're fixing things (and thus quite silly).  I know scheduled  
>> releases can be convenient but I don't see an issue with our  
>> standard "when it's ready" release schedule.  I don't know that  
>> I'd be inclined to think about it longer than the time it took to  
>> write this, simply because people complain when we don't release  
>> soon enough and they have to wait for fixes as well.  Therefore  
>> I'm tempted to just ignore it as not being able to please everyone.
>>
>> But those are just my initial thoughts.  Maybe someone can present  
>> a "compelling why" and change my opinion.
>
> Sure. Scheduled releases assume two things:
>
> 	1) branch is generally stable enough to release off of (or at  
> least ship a beta for testing)

Hopefully the branch is always like this.


> 	2) Enough work will accumulate over N weeks (N=6?) that assuming  
> no problems there will be enough bug fixes and improvements to  
> warrant a release.
>

Typically this value would change during different parts of the year  
though. Which is why I'm having difficulty coming up with a good  
number. For instance, when school is in session, we shouldn't even  
try to put pressure on people for a release when finals are foo weeks  
away. Meanwhile, during the summer, that's different, but people need  
to have their own time, so it's very much a play by ear type  
situation in my opinion.


> I think both of those are Good Things and view moving to scheduled  
> releases as a cultural tweak we can make to ensure both of those  
> stay that way, and to help us grow & mature as a project.

I think we're pretty mature as a project honestly. We need to get  
stuff done, but we're operating very well. We're not going to become  
mozilla, I keep getting the feeling you want the Adium Project to  
become that in some fashion. Am I mistaking the tone/content of your  
posts for the last couple of months?


>
> Note that it doesn't have to be "we will release in exactly 6  
> weeks" or anything. For example, the amount of informality in the  
> meeting schedule is pretty high, but we try to have one every two  
> weeks or so because it makes scheduling them easier for everyone.
>

I think meetings are completely different than scheduled releases.  
Scheduled releases mean a concerted effort to work on the project  
with a different amount of work perhaps, whereas the meetings don't  
require everyone to attend, and are only a couple of hours a month.

>
> I hope nobody interpreted my original mail as "A user complained.  
> We have a problem!!! MUST FIX." I've been thinking about this issue  
> and have brought it up before, and that email seemed like a good  
> way to bring the topic up again.

I didn't interpret it as that, I interpreted it as you meant it. I  
just don't like the idea honestly for the reasons I've outlined.

I couldn't say much about the monotone one because I don't really use  
svn much anymore to checkin (like I ever did? hehe), but I was  
concerned about the maintenance ramifications due to the changes  
proposed. This proposal, however, scares me to be blunt. Stuff like  
changing source repositories and changing how you release stuff and  
things like that could very well cause some developers to drop off.  
We can't afford that right now. How do you view these changes as  
affecting the project 3/6/9/12 months down the road, with both  
positive and negative consequences taken into account?

Chris



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20071107/0dabe0b1/attachment-0001.html>


More information about the devel mailing list