You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by sebb <se...@gmail.com> on 2019/09/06 09:01:39 UTC
Fwd: Git status update
[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 <ke...@apache.org>
Date: Sun, 10 Jan 2016 at 18:00
Subject: Git status update
To: infrastructure@apache.org <in...@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
Re: Git status update
Posted by sebb <se...@gmail.com>.
On Thu, 24 Oct 2019 at 12:54, Emmanuel Bourg <eb...@apache.org> wrote:
>
> Le 24/10/2019 à 12:54, sebb a écrit :
>
> > Without a fixed tag pointing to a commit, AIUI the commit can be
> > eliminated through a force push.
>
> Force pushing a branch doesn't erase the tags along it nor its parent
> commits. The commit and the tag still exist in the repository.
>
>
> > That is deliberate, to avoid the lost commit issue.
>
> Git commits aren't easily lost. They can be recovered from ASF backups,
> GitHub, developers working repositories and from the affected repository
> itself until it's garbage collected.
>
AFAIK all of the above eventually expire, so the commit can only be
recovered if its loss is noticed soon enough.
Provenance is far too important to have to rely on such time-consuming
and non-guaranteed methods.
> > It's standard within the ASF now.
>
> It's a feature provided by the ASF infrastructure if we are interested
> in using it, not a mandatory policy. I'm not interested in more complexity.
But you don't seem to mind if someone else has the complex job of
recovering a commit?
>
> >> * it doesn't solve any actual issue
> >
> > Yes, it does solve an issue - see above.
>
> Sorry but no, it never happened in Commons, this is purely theoretical.
How do you know if a commit has been lost?
Commons was using SVN until recently; SVN does not have the issue.
Also force pushes have only been enabled recently.
AIUI the point of the rel/* tags is to guard against misuse
(accidental or otherwise) of force-push.
> And should it happen anyway it's trivial to restore the original branch
> from a developer repository.
Assuming that the missing commit is noticed before the developer resyncs.
>
> >> * we want fewer steps to our release process, not more
> >
> > No, we want as few as possible, but no fewer.
>
> It's possible to work without read-only tags, so let's not overload our
> processes even more please.
Of course it's possible, but is it sensible?
> Emmanuel Bourg
>
> ---------------------------------------------------------------------
> 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
Re: Git status update
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 24/10/2019 à 12:54, sebb a écrit :
> Without a fixed tag pointing to a commit, AIUI the commit can be
> eliminated through a force push.
Force pushing a branch doesn't erase the tags along it nor its parent
commits. The commit and the tag still exist in the repository.
> That is deliberate, to avoid the lost commit issue.
Git commits aren't easily lost. They can be recovered from ASF backups,
GitHub, developers working repositories and from the affected repository
itself until it's garbage collected.
> It's standard within the ASF now.
It's a feature provided by the ASF infrastructure if we are interested
in using it, not a mandatory policy. I'm not interested in more complexity.
>> * it doesn't solve any actual issue
>
> Yes, it does solve an issue - see above.
Sorry but no, it never happened in Commons, this is purely theoretical.
And should it happen anyway it's trivial to restore the original branch
from a developer repository.
>> * we want fewer steps to our release process, not more
>
> No, we want as few as possible, but no fewer.
It's possible to work without read-only tags, so let's not overload our
processes even more please.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Git status update
Posted by sebb <se...@gmail.com>.
On Thu, 24 Oct 2019 at 09:28, Emmanuel Bourg <eb...@apache.org> wrote:
>
> Le 09/09/2019 à 17:29, Gary Gregory a écrit :
>
> > 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.
>
> If the vote mail mentions the tag name and the commit hash I don't see
> the need to use read-only tags. The mail is archived all around the net
> and the commit isn't going away. The risk of losing a release is zero.
That disagrees with the statement made by David Nalley:
"thus any tags under rel, will have their entire commit history."
Without a fixed tag pointing to a commit, AIUI the commit can be
eliminated through a force push.
> I can see the downsides of using rel/ tags though:
> * it can't be reverted and errors can't be corrected (without bugging
> the infra team I guess, but they've more important things to do)
That is deliberate, to avoid the lost commit issue.
> * it's inconsistent with past releases and we probably don't want to
> retag all our repositories
> * it doesn't look great, shorter tags look nicer
> * it's longer to type when checking out tags from the command line
> * it's non standard (never seen that anywhere)
It's standard within the ASF now.
> * it doesn't solve any actual issue
Yes, it does solve an issue - see above.
> * we want fewer steps to our release process, not more
No, we want as few as possible, but no fewer.
> Emmanuel Bourg
>
> ---------------------------------------------------------------------
> 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
Re: Git status update
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 09/09/2019 à 17:29, Gary Gregory a écrit :
> 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.
If the vote mail mentions the tag name and the commit hash I don't see
the need to use read-only tags. The mail is archived all around the net
and the commit isn't going away. The risk of losing a release is zero.
I can see the downsides of using rel/ tags though:
* it can't be reverted and errors can't be corrected (without bugging
the infra team I guess, but they've more important things to do)
* it's inconsistent with past releases and we probably don't want to
retag all our repositories
* it doesn't look great, shorter tags look nicer
* it's longer to type when checking out tags from the command line
* it's non standard (never seen that anywhere)
* it doesn't solve any actual issue
* we want fewer steps to our release process, not more
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Git status update
Posted by Gary Gregory <ga...@gmail.com>.
On Mon, Sep 9, 2019 at 10:42 AM sebb <se...@gmail.com> wrote:
> On Mon, 9 Sep 2019 at 14:00, Gary Gregory <ga...@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 <se...@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 <ke...@apache.org>
> > > Date: Sun, 10 Jan 2016 at 18:00
> > > Subject: Git status update
> > > To: infrastructure@apache.org <in...@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
>
>
Re: Git status update
Posted by sebb <se...@gmail.com>.
On Mon, 9 Sep 2019 at 14:00, Gary Gregory <ga...@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.
> 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 <se...@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 <ke...@apache.org>
> > Date: Sun, 10 Jan 2016 at 18:00
> > Subject: Git status update
> > To: infrastructure@apache.org <in...@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
Re: Git status update
Posted by Gary Gregory <ga...@gmail.com>.
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 <se...@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 <ke...@apache.org>
> Date: Sun, 10 Jan 2016 at 18:00
> Subject: Git status update
> To: infrastructure@apache.org <in...@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
>
>