Wikipedia describes the situation like this:īefore the 2.6 series, there was a stable branch (2.4) where only relatively minor and safe changes were merged, and an unstable branch (2.5), where bigger changes and cleanups were allowed. To make things more unclear, the development branch is often declared “stable” by its developers, before most of the libraries or applications have been ported to it.įirst, in the Linux 2.4 / 2.5 era. This situation can grow up to a quasi-deadlock, with people questioning whether it was a good idea to do such a massive fork in the first place, and if it is a good idea to even spend time switching to the new branch. Since users continue to use the stable branch, it is tempting for developers to spend time backporting new features to the stable branch instead of improving the development branch to get it stable.The development branch lacks user testing, and tends to make slower progress towards stabilization.However at the same time, the users’ focus stays on the stable branch. Most of the developers’ focus moves to the development branch. To allow for big, disruptive changes, a new development branch is created. There’s a pattern that comes up from time to time in the release management of free software projects. I would like a solution where I would write the email, add a header (or maybe manually add a Date: header - in all cases that header should reflect the time the mail was sent, not the time it was written), send the email, and have nullmailer or the remote server queue it until the appropriate time is reached (e.g., delaying while “current_time fp, "%s", mutt_make_date (buf, sizeof (buf))) Ģ3 February 2017 à 07:26 26 December 2016 Lucas Nussbaum The Linux 2.5, Ruby 1.9 and Python 3 release management anti-pattern
But that’s not really nice, because it requires going back to the email at the appropriate time. Of course the fallback solution would be to use mutt’s postponing feature. I write email using mutt on my laptop, then push it locally to nullmailer, that then relays it, over an SSH tunnel, to a remote server (running Exim4). I wonder how I could make this fit into my email workflow. However, I tend to do email at random times, and I would rather continue doing that, but just delay the actual sending of the email to the appropriate time (e.g., when I do email in the evening, it would actually be sent the following morning at 9am). The idea of not sending professional emails when people are not supposed to read them in order to protect their private lifes, is a pretty good one, especially when hierarchy is involved. France passed a law about “right to disconnect” (more info here or here).
0 kommentar(er)
