Just - note that the 72 hrs are specifically designed to cover the weekend. So when there are such - rather insignificant - issues, I think we should be ok. We have had many of our votes - including the absolutely most important - releases - lasting 72 hours over weekend and it has never been a problem, we only extended it including weekends where the matters were really important and we expected them to be contentious (this one was not).
Does it mean Ash that we propose extending all kinds of consensus and voting in this way ? It's the first time it has been raised, so maybe that's a good idea to make it longer now when we are all additionally busy with Airflow 3, but I don't see any reason why it should be a problem "in general". WDYT? Note that your objection is also 5 days after the initial message, so even if it would be 2 days more, that would not change anything. IMHO the consensus is reached. and If you want to revert that you should start a new thread Ash. J. On Thu, Feb 6, 2025 at 3:35 PM Ash Berlin-Taylor <a...@apache.org> wrote: > Please be aware of time when you are proposing this. 48 out of the 72 > hours your had here were over the weekend which doesn’t give many people > adequate time to read and think upon this. > > > Because I’m -1 on this as I don’t have enough info (see my other email) to > understand why this change makes the first bit of difference. > > > On 4 Feb 2025, at 22:38, Buğra Öztürk <ozturkbugr...@gmail.com> wrote: > > > > Hey all, > > > > The consensus has been reached. > > > > Regards, > > > > On Sat, Feb 1, 2025 at 5:38 PM Buğra Öztürk <ozturkbugr...@gmail.com> > wrote: > > > >> Hello everyone, > >> > >> There have been recurring discussions about minimizing the usage of > caplog > >> in unit tests. If logs are necessary for a test, we should mock them > unless > >> the test strictly requires actual log output. Otherwise, the caplog > tests > >> should be removed and logs should be mocked. > >> > >> During recent large migrations, changes and ongoing CI/CD efforts, > caplog > >> has proven to be flaky in unit tests. They frequently cause red > pipelines > >> in PRs and scheduled CI/CD runs. There have been local discussions on > >> removing caplog from unit tests. To formalize this, I propose a lazy > >> consensus to remove and prevent caplog usage in unit tests, ensuring > logs > >> are mocked when needed and disallowing caplog without mocking unless > >> explicitly approved. > >> > >> *Why should caplog be avoided?* > >> > >> - Big maintenance effort on CI/CD > >> - Instability > >> > >> > >> *What should we do instead if we use caplog in a unit test?* > >> > >> - Mocking the Log > >> > >> *In the Scope of this consensus* > >> > >> - Remove caplog usage from unit tests if possible > >> - Mock logs and remove caplog from unit tests if possible > >> - Exceptional cases will be subject to maintainer approval > >> - Prevent caplog to be included in unit tests without explicitly > >> mocking the log > >> > >> *Action Items related to the above Scope:* > >> > >> - Scan and replace caplog tests with mocking where possible > >> - Scan and remove caplog tests where possible > >> - Include CI check to prevent adding additional caplog tests without > >> Mocking and/or without approval from a maintainer to allow > flexibility in > >> some exceptional cases > >> - Create documentation with examples for implementing tests using logs > >> without caplog (e.g., using mocking or avoiding logs entirely) > >> > >> > >> The lazy consensus will be reached on 2025-02-04, (unless someone > surfaces > >> an objection). > >> -- > >> Bugra Ozturk > >> > > > > > > -- > > Bugra Ozturk > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org > For additional commands, e-mail: dev-h...@airflow.apache.org > >
