Rewriting ancient code

Posted Feb 9, 2023 18:01 UTC (Thu) by cyperpunks (subscriber, #39406)
In reply to: Rewriting ancient code by abacus
Parent article: The future of Thunderbird

For me the required feature set in a MUA was completed at least 15 years ago, still TB need to change each month going forward?
Why?

Rewriting ancient code

Posted Feb 10, 2023 11:30 UTC (Fri) by bluss (guest, #47454) [Link] (1 responses)

Isn't it a quite superficial question?

It's their software project and this is how they want to structure it, it's the process they want to use. It suggests a type of continuous delivery model instead of working up to big releases, missing deadlines, and moving release dates. Nothing says that there needs to be big changes every six weeks, it's just a new release, big or small.

It sounds like they were inspired by Rust, which has been running on a six week release schedule since 2015(!), and not every Rust release brings anything major. Nothing in programming languages says it's important to have a new change out quickly. It's just a productive and useful process to follow.

Rewriting ancient code

Posted Feb 23, 2023 13:10 UTC (Thu) by mrugiero (guest, #153040) [Link]

Isn't it quite a superficial answer, too?

More seriously, the question is not whether or not the team has the right to do so, but whether or not it is a good idea. Which the 6 weeks release model is (not so a rewrite, IMO). Even if the MUA feature set is complete (which it isn't, as standards have changed), bugs will always exist. Because they exist, you as a maintainer are left with three choices:
- Do a release whenever a bug is fixed. Impractical for most people, not limited to dev but also packagers and users.
- Do a big release whenever you have a big batch of fixes. Practical for the dev, but annoying for the people waiting on a fix.
- Do time based releases, preferably at what you consider a sweet spot between your own effort and the UX in terms of how much I need to wait to see my problem fixed.

On the rewrite, it's most often a bad idea to do a big rewrite, specially if the reason is just tech debt. Your rewrite will also have tech debt while also losing treatment of many edge cases you and others found along the way. Plus, it may never ship or just come late to the party when everybody already moved on. Some people in my environment actually think both divesting effort into Rust and trying to gradually rewrite Gecko is what lead to the big loss of market share for Firefox in the past. I only partially agree, but it's true it was a little too late for some things and it may have been more pragmatic to focus on fixing existing code instead.
Improving and modernizing the UI, on the other hand, is sensible. Focusing in what the user will perceive is most often the right approach, and we geeks and people with engineering/programmer mindsets tend to forget it. The whole point of software is to satisfy the user, not to make code pretty.