[Adium-devl] [Bulk] Re: Adium 1.2.1 and beyond

[Carlos Morales]

I'll like to add my two cents too.
I have noticed that there are many of us following the development of  
the app very closely, but not actually writing code.
I guess that those of us could improve the workflow of things, taking  
responsibility for some of the non-coding-stuff that current devs are  
doing.
We could make teams for example, to manage new tickets at trac, and  
to write the press releases of the adium team.This way, current  
developers could focus on that they do better: writing code.

What do you think?

On Jan 9, 2008, at 7:05 PM, shawn khan wrote:

> Hey,
>
> I am not an active developer on adium, but I would like to leave a
> comment on this, because this concerns everyone who uses Adium.  I
> think that the ideas to move tickets from 1.2.1 to over more releases
> is a good idea.  There are just too many bugs that are being fixed in
> 1.2.1 that would make the release take longer then should.
>
> One thing I see is that we should fix bugs that are serious in major
> and minor releases.  If new bugs come up that are major, we should fix
> them before the release, this way we are fixing bugs that are going to
> be good for everyone.
>
> How do we know when a release is ready to go out?  This way if
> developers have finished a bug and want to work on another one for
> that minor release, they should be able to.
>
> Thanks,
> Shawn
>
> On Jan 9, 2008 4:49 PM, Jordan Schelew <jas8522 at gmail.com> wrote:
>> Perhaps we should have milestones up to 1.2.5 or 1.2.6 and spread  
>> some of
>> those tickets across them, with the regressions set to nearer  
>> releases and
>> everything else in further ones. There are also many issues (such as
>> crashes) that have been reported recently, along with tickets with  
>> debug
>> logging included that are 'ready' to be analysed by someone who  
>> knows how to
>> handle them.
>>
>> I'm curious as to how the applescript 'regressions' are to be  
>> handled...
>> since I never used AS (other than the built in scripts) in any  
>> previous
>> version of Adium, I can't tell what is a regression and what is  
>> not, and
>> where they should be placed (in terms of Milestones). djmori was also
>> commenting on this fact on IRC a couple days ago. Perhaps those  
>> should be
>> resolved prior to 1.2.1 as well? Should we assign all of those to  
>> applemack?
>> (Sorry if I spelled that wrong).
>>
>> Jordan
>>
>>
>>
>> On 9-Jan-08, at 7:22 PM, Evan Schoenberg wrote:
>>
>>
>> I'd like to release Adium 1.2.1 in the near future, preferably  
>> this weekend
>> some time.  We introduced more than a couple bugs and leaks in 1.2  
>> which
>> have been fixed for 1.2.1.
>>
>> After that, we have some decisions to make.  Milestone Adium 1.2.1  
>> currently
>> has a ginormous hodgepodge of tickets, far beyond the scope I'd  
>> like to set
>> for future releases.  The open tickets on that milestone will  
>> shift to 1.2.2
>> (and the existing 1.2.2 to 1.2.3) once we release 1.2.1.
>>
>> Here's what I propose for releases moving forward:
>>  - Regressions should always be targeted for the next minor  
>> version.  We'll
>> try to fix all known regressions before releasing the next minor  
>> version.
>>  - We'll assign no more than 15 bugs and/or minor enhancements to  
>> each minor
>> revision.  Anyone choosing to accept a ticket -- that is, declare  
>> themselves
>> to be working on it -- can do so and move a ticket to the next minor
>> revision beyond that number.
>>  - I'd like for each person who considers himself an active  
>> developer to
>> have a hand in each release.  You all know that despite my  
>> insanity I know
>> as well as anyone the demands of Real Life; let's not make a  
>> stressful or
>> problematic change in that direction. How about we say that each  
>> active
>> developer should try to have accepted and truly be working on (or  
>> completed)
>> at least one ticket in a given milestone?
>>  - We'll release when a milestone is completed with no known  
>> regressions or
>> 1 month has passed since the previous release, whichever comes first.
>>  - Major new features and significant rewrites (such as the buddy  
>> icon
>> management rewrite I recently did) should end up in the trunk for  
>> release as
>> the next major version.  When feasible, use microbranches for work  
>> which you
>> expect to break trunk while it is in progress.  (That last bit, of  
>> course,
>> will be likely be easier when we resolve the DVCS question.)
>>
>> What do y'all think about this, in general and in specific?
>>
>> Cheers,
>> Evan_______________________________________________
>> 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
>>
>>
>
>
>
> -- 
> Thanks,
> Shawn
> 780 604-4999
>
> _______________________________________________
> Adium-devl mailing list
> Adium-devl at adiumx.com
> http://adiumx.com/mailman/listinfo/adium-devl_adiumx.com