Fwd: Git status update

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Fwd: Git status update

sebb-2-2
[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 <[hidden email]>
Date: Sun, 10 Jan 2016 at 18:00
Subject: Git status update
To: [hidden email] <[hidden email]>


Greeting PMCs:
(bcc to [hidden email])

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 [hidden email]


--David
on behalf of Apache Infrastructure

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Git status update

garydgregory
It seems like we really should put future release tags under 'rel/'

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...

Gary


On Fri, Sep 6, 2019 at 5:02 AM sebb <[hidden email]> 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 <[hidden email]>
> Date: Sun, 10 Jan 2016 at 18:00
> Subject: Git status update
> To: [hidden email] <[hidden email]>
>
>
> Greeting PMCs:
> (bcc to [hidden email])
>
> 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 [hidden email]
>
>
> --David
> on behalf of Apache Infrastructure
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Git status update

sebb-2-2
On Mon, 9 Sep 2019 at 14:00, Gary Gregory <[hidden email]> 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.

> 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 <[hidden email]> 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 <[hidden email]>
> > Date: Sun, 10 Jan 2016 at 18:00
> > Subject: Git status update
> > To: [hidden email] <[hidden email]>
> >
> >
> > Greeting PMCs:
> > (bcc to [hidden email])
> >
> > 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 [hidden email]
> >
> >
> > --David
> > on behalf of Apache Infrastructure
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Git status update

garydgregory
On Mon, Sep 9, 2019 at 10:42 AM sebb <[hidden email]> wrote:

> On Mon, 9 Sep 2019 at 14:00, Gary Gregory <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> > > Date: Sun, 10 Jan 2016 at 18:00
> > > Subject: Git status update
> > > To: [hidden email] <[hidden email]>
> > >
> > >
> > > Greeting PMCs:
> > > (bcc to [hidden email])
> > >
> > > 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
> [hidden email]
> > >
> > >
> > > --David
> > > on behalf of Apache Infrastructure
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>