If you trust a committer enough to do release management, why are they not on the PMC?
On 2020/08/13 22:52:55, Francis Chuang <francischu...@apache.org> wrote: > +1 from me as well. From our side, the risk is minimized as the process > to move the artifacts on SVN is automated using Vladimir's gradle > plugin, so there shouldn't be any manual intervention on the part of the RM. > > Francis > > On 14/08/2020 8:34 am, Ruben Q L wrote: > > +1 > > > > Apart from the reasons already mentioned, if we want committers (not just > > PMC) to get involved in the release management process, I think this step > > would go in the right direction. > > > > Best regards, > > Ruben > > > > > > Le jeu. 13 août 2020 à 23:18, Rui Wang <amaliu...@apache.org> a écrit : > > > >> +1 > >> > >> if well used/tested svn commands for releasing are documented, committers > >> without experience on release or svn can still use those properly. > >> > >> > >> -Rui > >> > >> On Thu, Aug 13, 2020 at 3:09 PM Stamatis Zampetakis <zabe...@gmail.com> > >> wrote: > >> > >>> +1 > >>> > >>> I always thought that committers had access to the dist repo and I was > >>> completely fine with it. > >>> > >>> Everybody makes mistakes no matter if it is a committer or PMC so I don't > >>> see a reason to have different read/write access to the repo. > >>> > >>> Best, > >>> Stamatis > >>> > >>> On Fri, Aug 14, 2020 at 12:17 AM sebbaz <s...@apache.org> wrote: > >>> > >>>> > >>>> > >>>> On 2020/08/13 18:47:54, Julian Hyde <jhyde.apa...@gmail.com> wrote: > >>>>> +1 > >>>>> > >>>>> Clearly committers should have read and write access to all > >> non-private > >>>> information in a project. I don’t even think this needs a vote. If this > >>>> discussion quickly reaches consensus, as I assume it will, let’s just > >>> make > >>>> it so. > >>>>> > >>>>> The hypothetical risk that a committer would (accidentally or > >>>> deliberately) cause damage is a non-issue. In source control systems > >> such > >>>> as SVN or Git, any change can be rolled back. > >>>> > >>>> Please note that the dist.apache.org release directory is very > >> different > >>>> in this regard. > >>>> > >>>> If artifacts are published by moving them to the release directory, it > >> is > >>>> *not* easily possible to revert publication > >>>> > >>>> This is because the release directory is used to distribute the files > >> to > >>>> the world-wide mirror system. > >>>> And to the ASF archive system, which would require Infra assistance to > >>>> revert. > >>>> > >>>> Mistakes are not easily recovered. > >>>> > >>>> This is why the default is for PMC members only. > >>>> > >>>>> Julian > >>>>> > >>>>> > >>>>>> On Aug 13, 2020, at 8:07 AM, Andrei Sereda <and...@sereda.cc> > >> wrote: > >>>>>> > >>>>>> Hello, > >>>>>> > >>>>>> For the last two releases ([1] and [2]) committers were not able to > >>>>>> finalize the release due to SVN restrictions. One of the PMC > >> members > >>>> had to > >>>>>> step in order to distribute the artifacts. > >>>>>> > >>>>>> By default, only PMCs are allowed to make changes to dist > >>>>>> <https://dist.apache.org/repos/dist/release/calcite/> SVN > >>> repository. > >>>>>> > >>>>>> This can be changed > >>>>>> < > >>>> > >>> > >> https://issues.apache.org/jira/browse/INFRA-20681?focusedCommentId=17177075&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17177075 > >>>>> . > >>>>>> According to INFA: > >>>>>> > >>>>>>> A link on this Jira to an email discussion where it is approved > >> will > >>>> be > >>>>>> fine > >>>>>> > >>>>>> PMCs please vote on this proposal. > >>>>>> > >>>>>> Thanks, > >>>>>> Andrei. > >>>>>> > >>>>>> [1] > >>>>>> > >>>> > >>> > >> https://lists.apache.org/thread.html/rbd84cf78ef250685a05fdb9c70708daa6558619093f510d27aabc1af%40%3Cdev.calcite.apache.org%3E > >>>>>> [2] > >>>>>> > >>>> > >>> > >> https://lists.apache.org/thread.html/ra180b94d785d5575558ab10d919521a6395fcce8899ed1dcda78d004%40%3Cdev.calcite.apache.org%3E > >>>>> > >>>>> > >>>> > >>> > >> > > >
