Robert Kaiser wrote:
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?
A two year cycle is about standard for what I do, and what I manage is
WAY more complex than something like SM...the short cycle model works
just fine for security and "under the hood" fixes, the long cycle model
works better for major interface changes.
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.
It's not about trusting code - greatest thing about code is that you can
re-write it. So if you don't "trust" something, redraft it into
something you do trust and maintain the functionality for the end user.
That's such a common requirement for system software development in my
industry that we don't even bat an eye at it.
Like I mentioned previously - if we applied your above approach with
airplanes, we'd risk killing people. We don't like killing people.
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.
...I NEVER said it was easy. I said it's possible.
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
Well...yeah...we do that weekly. In fact, we've just been fighting a
HUGE issue with a system which may put a possible year slip in our
production. There is no utopia. But there IS getting the job done.
And yeah - that's about how many people we have on our teams as well for
an integration effort on a complex system - sometimes it's just one guy
for a piece of software for a particular box. Discipline, configuration
control, small increments - that's how we do it. For the last 25 years
that I've been doing it. So I'm not much discouraged by the SM team's
sitch.
--
- Rufus
_______________________________________________
support-seamonkey mailing list
[email protected]
https://lists.mozilla.org/listinfo/support-seamonkey
