Release timing
Albert Ting
altlst at sonic.net
Mon Jan 24 01:43:47 UTC 2005
Luis Villa <luis.villa at gmail.com> 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