Release timing

Albert Ting altlst at
Mon Jan 24 01:43:47 UTC 2005

Luis Villa <luis.villa at> writes:
> if I convince my boss to let me contribute to bugzilla because it'll help
> reduce maintenance costs, and then it is years before my contribution
> actually makes it into a release and helps the company, then I'm going to
> have problems justifying that in the future. Regular, fast releases on a
> pre-determined schedule mean contributors see results quickly, which is a
> big plus.

I'd like to also add fast reviews/critiques goes a long way.  

My company and I had a vested interest in getting some of my larger patches
merged into the bugzilla releases.  Lower maintenance, etc.  

If it wasn't for Joel putting the effort to quickly review/critique my
patches and convince the other reviewers to participate, I'd probably would
have stayed with my custom 2.18, maybe even look at commercial versions.  I
had to put more time to update the patches for the newer stream, 2.19+,
especially the edit*.cgi coding changes.

As a side note, how do people maintain their bugzilla contributions?  It's
not easy given there is such a long lead time in getting contributions
approved.  This is especially true if you're also using other people's
patches.  At the moment, I automatically build my custom bugzilla directory
based on a cvs snapshot and all custom patches.  But it's not perfect.

More information about the developers mailing list