Rufus wrote:
4) adopt a schedule for release and release fewer changes per cycle -
this could be done on a shorter cycle, allowing for more releases.
5) adopt a longer release cycle for major changes to allow user polling
and beta test of (all) pending implementations prior to formal release -
this would fit a longer cycle with fewer releases.
Longer or shorter? Is three years for really major changes such as what
we did with 1.x -> 2.0 with 1.5 years of releasing Alphas and Betas too
little in the moving-fast Internet world?
7) discarding old features just because they are old doesn't even enter
into the equation
OK, now you revealed that you don't have a clue about development. The
reason is never just because "it's old", it's usually because "there's
nobody any more who can maintain this f***ing piece of sh*t for its
security vulnerabilities because nobody who is around does understand
the code or even tries to". And then, remember, around here you can't
hire anyone to do that, you can just beg people to please look at it.
And if that doesn't help, it's always better to ship the code you trust
only and omit the parts you cannot trust or maintain any more.
That a REALLY short treatise on how I've done it...and a fair start for
anyone else.
Feel free to manage your own project if you think it's really that easy.
I have explained in the post before why it isn't for us.
Oh, and just imagine your whole world falls apart and you need to
completely rebuild it with a team of maximum 10-20 people who only can
invest their free time. How would you do that? Do your utopical
guideline still work there?
Robert Kaiser
_______________________________________________
support-seamonkey mailing list
[email protected]
https://lists.mozilla.org/listinfo/support-seamonkey
