> On Apr 1, 2020, at 8:43 AM, Gilles Sadowski <gillese...@gmail.com> wrote: > > Le mer. 1 avr. 2020 à 14:33, Rob Tompkins <chtom...@gmail.com > <mailto:chtom...@gmail.com>> a écrit : >> >> >> >>> On Apr 1, 2020, at 8:22 AM, Stefan Bodewig <bode...@apache.org> wrote: >>> >>> On 2020-04-01, Gary Gregory wrote: >>> >>>> The docs should also make sure that release tags are in the form rel/... >>>> which makes them read-only. >>> >>> So far I've created a new tag under rel/ for the RC tag when the vote >>> has been accepted. So only "real" releases end up there. >>> >>> If we want to create all our tags there, things may look a bit >>> confusing. But I could live with that as well. >> >> I would think we would only want to put tags that have a [VOTE] thread >> associated under rel/ because they are required to remain in the public >> domain. > > A vote that *passed*, you mean (?). > Everything that is not officially released is so-to-speak "internal". > Is there any interest in having failed attempts made read-only? >
Yes, I would think we would want the code on which we voted kept as well as the emails. I agree the commits are kept in the [VOTE] thread, but those are technically mutable. If I understand correctly, [infra] has put a special restriction on our mirrors of GitHub such that tags with the prefix “rel/“ cannot be overwritten. Thus, the only way to ensure the history is permanently retained is to have it be under a tag with a “rel/“ prefix. We otherwise rely on the good will (which I do trust) of our committers to not force push over a branch or delete RC tags. -Rob > The "history" is kept through the ML archives (the "[Vote]" thread > and its corresponding tag/commit). > > Gilles > >> I have, at times, found the need to delete a tag due to mistakes on my part. >> But, I’ve only done so if there has been no email [VOTE]. If there was an >> email [VOTE] in existence, then my move has been to increment the RC version. >> >> My 2 cents, >> -Rob >> >>> >>> Stefan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org
