commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: Git status update
Date Mon, 09 Sep 2019 15:29:49 GMT
On Mon, Sep 9, 2019 at 10:42 AM sebb <sebbaz@gmail.com> wrote:

> On Mon, 9 Sep 2019 at 14:00, Gary Gregory <garydgregory@gmail.com> wrote:
> >
> > It seems like we really should put future release tags under 'rel/'
>
> Yes and no.
>
> I don't think the tag should be created before the release vote has
> succeeded.
>

What I meant is that, when we successfully create a release, then the
release tag should go under 'rel/' instead of ''. Sorry for the
misunderstanding.

Gary


>
> > It's too bad it can't simply be 'releases/' to make it clearer.
> >
> > Then there is the issue of moving all of our past release tags under
> > 'rel/', another thing we should do...
>
> I don't think there is any question of *moving* tags.
>
> AIUI the point is to create a reference to the commit as a tag under rel/
> This should ensure that the commit that was voted on cannot be dropped
> from the repo.
>
> > Gary
> >
> >
> > On Fri, Sep 6, 2019 at 5:02 AM sebb <sebbaz@gmail.com> wrote:
> >
> > > [This was sent to private@commons, but does not seem to have been
> > > forwarded to the dev@ list.]
> > >
> > > Please note the penultimate paragraph about tagging successful
> > > releases under rel/
> > >
> > > AFAICT, we have not been doing that, so our release tags are not
> > > automatically protected against deletion.
> > >
> > > We should probably start doing this going forward.
> > >
> > > Note that the rel/ tags cannot be deleted, so this needs to be done
> > > very carefully.
> > >
> > > I think the only change we need to make to the release process is to
> > > add a new step at the end to create the rel/tag from the commit SHA.
> > >
> > > We should be very careful about changing anything in the POM, lest it
> > > causes the rel/tag to be created before the RC has been approved.
> > >
> > > Thoughts?
> > >
> > > S.
> > > ---------- Forwarded message ---------
> > > From: David Nalley <ke4qqq@apache.org>
> > > Date: Sun, 10 Jan 2016 at 18:00
> > > Subject: Git status update
> > > To: infrastructure@apache.org <infrastructure@apache.org>
> > >
> > >
> > > Greeting PMCs:
> > > (bcc to pmcs@apache.org)
> > >
> > > Following direction from the Board, Infrastructure has modified git to
> > > permit force pushes, and branch/tag deletion.
> > >
> > > In accordance with the guidance that the Board we've implemented a few
> > > changes you should be aware of:
> > >
> > > First, If a forced commit is pushed, the subsequent commit email will
> > > contain '[Forced Update!]' in the subject line. The hope here is that
> > > it draws extra attention to the situation for a project community to
> > > be aware, and take appropriate action if needed.
> > >
> > > Second, we've changed the 'protected' portions of git to primarily
> > > focus on refs/tags/rel - thus any tags under rel, will have their
> > > entire commit history. This provides the provenance that the ASF needs
> > > for releases, while still giving projects the ability to mold their
> > > repository in the way they see fit.
> > >
> > > Thus when a release vote is successful - part of the release process
> > > should become tagging the voted upon commit SHA under rel/ to make it
> > > indelible. ('# git tag rel/v15.4.2 ' or something similar.)
> > >
> > >
> > > If you have questions, please feel free to email
> infrastructure@apache.org
> > >
> > >
> > > --David
> > > on behalf of Apache Infrastructure
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message