Unfixed bugs because the release needs to be pushed out of the door before a bug fix is in and tested, just because it is time to release. As opposed to delaying the release by however long it takes in order to incorporate an important bug fix and not release a buggy version.

Instead of fixing four release dates a year, take things one step at a time. Once a release is out of the door, fix a future feature freeze day. After that has passed, fix a release date. Any feature patches that arrive after the freeze date go into the next release, unless they're really important, in which case the release gets pushed back by however long it takes to incorporate. The release happens whenever the code is sufficiently bug-free to satisfy the project manager(s). Yes, you need to draw the line somewhere and say this patch goes in and that one doesn't, but that's just a management issue. It means you make the cut based on a technical evaluation, which is surely superior to making the decision based on the time that has passed since a certain Middle-Eastern man was (or was not, whichever your persuasion may be) born.

Besides, "sending in their patches early" doesn't really happen very much, does it? Most patches are submitted just before the code freeze date. As a project manager you need to deal with that issue.

I personally really like the new Linux kernel method of having extremely short windows between a project release and a feature freeze (currently two weeks), but there are bound to be different time scales which are ideal for different projects.


Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan

In reply to Re^5: what happened to regular releases by tirwhan
in thread what happened to regular releases by audiovolume

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.