[Adium-devl] Minor updates

Thu Nov 8 18:03:34 UTC 2007

What I'm really favor of is two things. I think we can all get behind  
them.

1. A general timeframe, agreed upon by everyone where development on  
minor releases stops in favor of full focus on a major release. This  
should be agreed upon when the previous release is made. So for  
instance, under this new system we might have picked a general  
timeframe of end of October to finish up minor releases on 1.1 (This  
would have been a rough 2-2 1/2 months of work), and then from that  
point on, work solely on the next major release until it was done. At  
this point it would enter beta, go through testing, etc. etc. just as  
we do it now. I don't expect this timeframe to be completely set in  
stone, it's most assuredly flexible depending on whether we mess  
something up righteously enough, but a general timeframe to look  
forward to making the mode switch from bugfixes to working on bigger  
components would be an excellent addition to our current strategy.

2. As Colin said, a much stricter stance on back-porting non-essential  
changes, especially as we move forward. I think that from a certain  
point in the milestone, say, once we cross 60% completion for a major  
release, and 50% for a minor release that any changes to be back- 
ported need to be discussed and approved by devl. That means if we are  
either half-way done with a minor release, or slightly more than half- 
way done with a major release, we need to seriously consider the  
severity of the bug we want to merge back. This not only guards  
against non-severe bugs being back-ported, but also starts us down the  
path to more code review, which is something I think everyone can  
benefit from. Obviously, this presents some more devl overhead, but  
hey, that's what it's there for! Depending on how well this works out,  
experimenting with all out code review at a certain point (85-90% or  
so) in the milestone could help on multiple levels. First, it lets us  
finish our releases very strongly -- by bringing remaining bugs to the  
limelight for discussion we can collectively solve problems much more  
efficiently. Once those fixes are agreed upon and implemented, we gain  
added benefit of group review of code we've already all discussed and  
talked about. This gets everyone involved in the process of working on  
various parts of code, ensures that we guard against regressions near  
the end of the development process for a particular release, and gets  
us working more with each other -- especially core developers.

I think with both of those strategies in place, we could make some  
strong strides in improving the development process. This doesn't set  
anything in stone except for when our focus changes, versus when we  
are releasing anything. We can never predict how long a release might  
take, but sometimes we need a fire lit under us to move on to the next  
major releases. We have a lot of excellent code in 1.2, that is more  
or less rotting right now because we are poring over 1.1.x.

As a tentative proposal, I say that we switch full focus, barring any  
show-stopping bugs in 1.1.5 to 1.2 immediately after it's release. We  
will consolidate all bugs filed against 1.1.5 to 1.2, and work against  
that milestone full time. As far as I know, almost all the devs were  
running trunk until we stopped for a bit to work on and test 1.1.4.  
Let's push that again and get everyone back on trunk until we need to  
do testing for 1.1.5. Let's assume for a second that 1.2 releases in  
mid-January, which seems realistic from where we're at right now and  
the pace at which we are going. I propose that by early March we  
should be looking ahead to 1.3 for a release at the beginning of the  
summer. These are not exact dates. I'm trying to give you an idea of  
the kinds of goals we are trying to set. The actual releases are  
impossible to pinpoint, but that shouldn't stop us from having a semi- 
firm date for a focus change.

I really think what Colin and I are saying goes hand and hand. We both  
want to see a bit more structure and professional techniques being  
leveraged in our development process. Mentally, we are tired of  
working on 1.1.x, much as we were tired when working on 1.0, and  
subsequent 1.0.x releases. We've had our nice long "Leopard" style  
development cycle, but now we need to get back to a bit more  
aggressive cycle to build up activity and get the ole brains churning  
again. Ambitious? Certainly! But isn't that what we are know for?

-Elliott

On Nov 8, 2007, at 11:14 AM, Colin Barrett wrote:

> 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
>
> _______________________________________________
> 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/2862d98b/attachment-0001.html>