[Adium-devl] Minor updates

Thu Nov 8 16:46:50 UTC 2007

One thing to keep in mind, and ultimately one of the flaws with a  
hard(er) release schedule is determining where we stop working on the  
next major version. I think one of the problems we face by imposing a  
schedule at the minor level is that we get into a mode where we work  
for N weeks towards a minor release, working on minor release bugs,  
maybe at best getting to tackle one or two major release bugs  
(schoenstorms aside). We kind of lose our ability to effectively  
multitask between the major and minor releases. One of the strengths  
of going at our own pace is that by the time we've collectively  
decided on when we're going to focus on the next major release, we've  
actually got a majority of the work done for it -- because we've been  
able to work on it during the downtime of our minor release schedule.

I don't think we should trying to regulate a schedule from the bottom,  
but rather from the top. I suggest we keep doing minor releases at our  
own pace, and attempt to set a more strict point in time when we stop  
working on minor releases (baring of course, unforeseen circumstances  
which, for the time being, seem to be alright) and start working  
primarily on the major release. Right now, I don't think we have a  
timeframe set for 1.2 to be released (certainly no formal one). I  
think starting there would be a better idea. Let's figure out when we  
want to start seriously pushing on 1.2, feature freeze it (if it isn't  
already, another downside to so many minor releases, I don't think 1.2  
is at the forefront of people's minds), and try to get an idea of  
where we are going with it.

Minor releases are important, but I think scheduling a bugfix release  
is kind of hurting us. I'm not sure how much thought is going into the  
absolute necessity of these releases. I'm not saying we shouldn't be  
releasing often, because it's a very good strategy and has been  
working well for us, however I think when we are focusing on minor  
releases so much, our major releases are going to start to suffer.

In summary, at a certain point we will have spent more effort on  
writing, testing, and releasing all of these minor patches than it  
would have taken to buckle down, push tickets into 1.2, and starting  
working seriously there, if for nothing else than a mindset change. A  
realistic goal to begin working towards. Ticket count starts to drop,  
people get excited, more time is spent on some vital 1.2 patches and  
we begin testing it. Personally, I think we are treating 1.1.x like  
it's going to be our last Tiger release given the amount of work and  
persistent testing we are putting the minor releases through. Last I  
checked, that wasn't the case so maybe it's time to cut off doing  
minor releases after 1.1.5, once again barring unforeseen  
circumstances, and get started on the push for 1.2.

Thoughts?

Cheers,
Elliott

On Nov 8, 2007, at 10:04 AM, Colin Barrett wrote:
>
> On Nov 8, 2007, at 2:11 AM, Evan Schoenberg wrote:
>
>> On Nov 7, 2007, at 8:14 PM, Chris Forsythe wrote:
>>
>>> We're not going to become mozilla, I keep getting the feeling you
>>> want the Adium Project to become that in some fashion.
>>
>> Let's keep in mind that while we're not going to become Mozilla (both
>> because we don't have the human resources to do so and because I  
>> don't
>> believe that's what anyone involved wants  out of their efforts),
>> Mozilla represents a hugely successful (by pretty much any measure  
>> you
>> can pick except 'ease of new developer involvement' in my opinion -
>> resulting product, user base, public appeal, financial success)
>> instantiation of 'open source organization'.  There are without a
>> doubt many lessons to be learned from Mozilla, and a desire not to
>> become that organization shouldn't stop us from cherrypicking
>> knowledge where appropriate.  Colin is in a very unique position to
>> provide relevant insights from within the Mozilla machine.
>
> Thank you, Evan, for yet again saying what I couldn't find the words
> to say.
>
> Firstly, I'm not suggesting we set dates for our major releases (1.x),
> because we can't afford not to be quality focused there. Deadlines
> will not help anyone get things done faster because we're all doing as
> much as we can (and sometimes more than we should) to help move things
> along and get the release out the door ASAP.
>
> However, minor releases are different story. As I mentioned earlier in
> this thread, there is much less churn and we have a good implicit
> understanding of the scope of these dot releases already. Awesome.
>
> We already seem to be releasing roughly every month or two anyway --
> these are minor updates and often the decision to release them is
> largely arbitrary, except when we are fixing some sort of major issue
> (in which case we can rush a release out). This wouldn't be a huge
> change from how we already work, honestly.
>
> I don't know how our release schedule fits in with localizers, we
> don't seem to do string freezes or anything that formal, but I'm
> willing to bet that giving them more notice is a good thing (maybe I
> should join the localizers list?)
>
> Maybe people are envisioning a different future than I, so I'll try
> and describe what I see (please don't get hung up on the details here,
> it's just an example, and we can figure out how this is all going to
> work as we go, largely):
>
> - If things are going normally and people have just been chugging  
> away:
>
> About N weeks after the last release someone will start a thread here
> on devl about a release. Everyone can see what's gone in to the
> release through trac and we'll figure out either there or here or both
> which tickets get punted, ideally almost everything non-critical and
> open at that time (so we can respond to issues we find in the beta,
> which is the whole point of betas). This already happens on trac
> sometimes, but not always and not everyone is always on the same page
> about things and it's kind of confusing (at least to me).
>
> Normally that process will be quick because people are expecting it,
> and the next release has a known date so if it has to wait a couple
> weeks no big deal. Then we do the whole beta dance, get feedback, etc.
> until we get to zero tickets, hopefully like two weeks later, but
> we're at that point focused on quality, not dates. Someone then runs
> the release scripts and everything, and we've got 1.1.x.
>
>  - If there's a critical issue:
>
> Someone will post on devl saying they think that the next release
> should go out once issue X is fixed, ideally we'll all agree, punt as
> much stuff as we can (ideally everything) to the next release and get
> that fix out there for testing and then release ASAP.
>
>
> Remember, the above is only an example of the type of work flow I'm
> envisioning. Is it a little more clear now how this is better than our
> current process? We can definitely be more explicit and regular with
> our release process (which is a Good Thing) without causing additional
> headaches.
>
> -Colin
>
>
> _______________________________________________
> Adium-devl mailing list
> Adium-devl at adiumx.com
> http://adiumx.com/mailman/listinfo/adium-devl_adiumx.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20071108/99ccdf59/attachment-0001.html>