[Gluster-devel] Agenda for Nov 15th Maintainers meeting
atumball at redhat.com
Tue Nov 14 16:36:56 UTC 2017
# Meeting date: 11/15/2017 (Nov 15th, 19:30IST, 14:00UTC, 09:00EST)
- Bridge: https://bluejeans.com/205933580
- Download: <Add link here>
- [Sorry Note] misc,
- <Add your name here>
Action items from last meeting:
- [nigelb] Metrics on first-time contributors?
- [nigelb] Cregit run?
Re-visiting closing old reviews [nigelb]
- Using Gerrit to do the initial closing is a bad idea.
- We have a lot of reviews and each abandon triggers an email to
- This means Gerrit server will get greylisted by all providers as we
did for stage recently.
- We have a Jenkins job that will close a few old reviews every day.
Currently thinking of 25 per day. Once we catch up, we can
with the bot or use Gerrit to do this.
Release sanity [nigelb]
- We run regression-test-burn-in for master.
- We don’t for release branches. Seems like a no-brainer to do this.
- However, this will add load onto regression machines 1x number of
active releases per day.
- Options to mitigate
- We will trigger a regression run only if there are changes since
- Shall we move regression-test-burn-in to nightly?
Jeff’s email on Pressing ‘Submit’ if everything is OK?
- What is stopping you from doing it?
- Should author wait for at least one sanity review before running
- Will save some cycles as I have seen authors doing ‘+1’ to verify
immediately, and then they get -1.
- Makes sense if their patch gets reviewed just after smoke (or even
without smoke +1 too)
‘experimental’ branch rebase
- Major conflicts with posix changes :-/
- Other xlator option changes which GD2 was dependent on, is sent to
master with --author set to original authors.
- <Add decisions if any>
Update link if you want to add anything:
Amar Tumballi (amarts)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gluster-devel