[Adium-devl] Minor updates

Thu Nov 8 17:14:25 UTC 2007

The idea behind scheduling these things, in my mind, though is to make  
them *more* automatic and regular. I don't think hard dates are useful  
and I didn't really ever advocate that (although I was a bit vague).  
I'm thinking more along the lines of something soft that lets people  
*other* than core developers drive the release process for branch, yet  
still keeping everyone in the loop. I think that could be a big win.

I definitely agree that we have been spending too much time on minor  
releases lately, and I think too much stuff is getting backported to  
1.1 from 1.2. Less code going into branch means possibility for  
regressions which means fewer time spent dealing with 1.1. issues.

Some wacky crazy ideas: having only certain (dedicated?) people do the  
merging back from 1.2 to 1.1 or requiring the permissions of some  
person (could change per release, we all take turns) to merge back.  
Gating on people is one way to limit throughput (which minimizes risk.

Good luck getting people to schedule major releases. I think we could  
do with some general discipline about what gets checked in when, for  
sure. We have tried to start conversations like that before but  
nothing ended up coming out of it.

Maybe this time will be different.
-Colin

On Nov 8, 2007, at 8:46 AM, Elliott Harris wrote:

> 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
>
> _______________________________________________
> 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/70ae9a62/attachment-0001.html>