Nir Soffer <nsof...@redhat.com> writes: > On Mon, Jun 21, 2021 at 12:09 PM Milan Zamazal <mzama...@redhat.com> wrote: >> >> Nir Soffer <nsof...@redhat.com> writes: > >> >> > On Mon, Jun 21, 2021 at 11:35 AM Milan Zamazal <mzama...@redhat.com> wrote: >> >> >> >> Edward Haas <edwa...@redhat.com> writes: >> > >> >> >> >> > On Sun, Jun 20, 2021 at 11:29 PM Nir Soffer <nsof...@redhat.com> wrote: >> >> > >> >> >> On Mon, Dec 2, 2019 at 4:27 PM Adam Litke <ali...@redhat.com> wrote: >> >> >> >> >> >>> I also agree with the proposal. It's sad to turn in my keys but I'm >> >> >>> likely unable to perform many duties expected of a maintainer at this >> >> >>> point. I know that people can still find me via the git history :) >> >> >>> >> >> >>> On Thu, Nov 28, 2019 at 3:37 AM Milan Zamazal <mzama...@redhat.com> >> >> >>> wrote: >> >> >>> >> >> >>>> Dan Kenigsberg <dan...@redhat.com> writes: >> >> >>>> >> >> >>>> > On Wed, Nov 27, 2019 at 4:33 PM Francesco Romani >> >> >>>> > <from...@redhat.com> >> >> >>>> wrote: >> >> >>>> >> >> >> >>>> >> On 11/27/19 3:25 PM, Nir Soffer wrote: >> >> >>>> > >> >> >>>> >> > I want to remove inactive contributors from >> >> >>>> >> > vdsm-master-maintainers. >> >> >>>> >> > >> >> >>>> >> > I suggest the simple rule of 2 years of inactivity for removing >> >> >>>> >> > from >> >> >>>> >> > this group, >> >> >>>> >> > based on git log. >> >> >>>> >> > >> >> >>>> >> > See the list below for current status: >> >> >>>> >> > https://gerrit.ovirt.org/#/admin/groups/106,members >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> No objections, keeping the list minimal and current is a good >> >> >>>> >> idea. >> >> >>>> > >> >> >>>> > >> >> >>>> > I love removing dead code; I feel a bit different about removing >> >> >>>> > old >> >> >>>> > colleagues. Maybe I'm just being nostalgic. >> >> >>>> > >> >> >>>> > If we introduce this policy (which I understand is healthy), let us >> >> >>>> > give a long warning period (6 months?) before we apply the policy >> >> >>>> > to >> >> >>>> > existing dormant maintainers. We should also make sure that we >> >> >>>> > actively try to contact a person before he or she is dropped. >> >> >>>> >> >> >>>> I think this is a reasonable proposal. >> >> >>>> >> >> >>>> Regards, >> >> >>>> Milan >> >> >>>> >> >> >>> >> >> >> I forgot about this, and another year passed. >> >> >> >> >> >> Sending again, this time I added all past maintainers that may not >> >> >> watch >> >> >> this list. >> >> >> >> >> > >> >> > Very sad, but it makes total sense. +1 >> >> > Note that other projects move past maintainers to a special group named >> >> > "emeritus_*". >> >> >> >> Not a bad idea, I think we could have such a group in Vdsm too. >> > >> > It would be nice but not part of gerrit permission configuration. >> > >> > We have an AUTHORS file, last updated in 2013. We can use this file >> > to give credit to past maintainers. >> >> AUTHORS is a better place to give credits, but the group could be also >> useful as a more reliable tracking past maintainers and in case of >> restoring maintainer rights, if such a need ever occurs. (Yes, no way >> necessary for that but maybe nice to have.) > > Gerrit has an audit log: > https://gerrit.ovirt.org/admin/groups/106,audit-log
Ah, that looks good enough, I don't think anything more is needed. > If you don't trust it, we can add a file with this info in the project. > > If we look at other projects, qemu has this file: > https://github.com/qemu/qemu/blob/master/MAINTAINERS _______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/VU4BNKXBE2VWWAYACAXG34UGYENNOBSS/
