Junio C Hamano <gitster@xxxxxxxxx> writes: > Emily Shaffer <nasamuffin@xxxxxxxxxx> writes: > >> ...but this seems harder to keep track of. Where are we remembering >> these "due dates" and remembering to break them on purpose? I'm not >> sure that there's a good way to enforce this. > > If you come up with a good way, let me know. We have a few "test > balloons" in the code base and a due date that allows us to say "now > it is 18 months since this test balloon was raised, and nobody > complained, so we can safely assume that all compilers that matter > to users of this project support this language construct just fine" > would be a wonderful thing to have. Or, just set up a calendar reminder or an entry in an issue tracker that are accessible publicly, only to ease the "keeping track of" part? As an open source public project, we would not want to depend too heavily on a single vendor's offering for anything that is essential to run the project, but as long as we make sure that: - the authoritative due date is in the commit log message that introduces something, e.g., "we add this limitation, which we will revisit and reconsider in 6 months", but - if any hosting, cloud, or any other service providers, be they commercial or run by volunteers, offer a way for us to make it easier to keep track of that authoritative due date established above, without additional strings attached, we may freely take it (in other words, we are not free-software-socialists against commercial services). then the "reminder" part would not be something essential to run the project, so ...
