Open foolip opened 1 year ago
The other potential option here would be to use a different namespace for the epoch refs, such as pushing them into refs/epochs/*
.
This has the upside that omits them from the default refspec, which means normally users won't constantly see the branches/tags used for them. (We could also do likewise with the merge
tags.)
I still rely on this tags when there is a issue with WebKitGTK on the CI that needs to be investigated.
Can you describe how you use the existing tags? Is it to figure out which runs have been triggered in order to find the CI runs in the first place, or is it when you're already looking at a failed CI run and want to find some previous run? Or something else?
I don't believe we rely on this for anything, so no objections on that front, but the RFC doesn't seem to set out the case for the change, only that there are alternative ways to get the same information.
My motivation is to make git fetch
and git log
less noisy. We've already accumulated 6500 of these tags, and they lump up on certain commits in git log
and make the output less regular. So line noise, really.
We could also do likewise with the merge tags.
That would be a ~breaking change for the gecko sync (we use the tags in the first instance to associate a commit on master with a PR). Not impossible to update ofc, but not something we should just blindly change.
My motivation is to make git fetch and git log less noisy.
Can you update the RFC with this reasoning?
We could also do likewise with the merge tags.
That would be a ~breaking change for the gecko sync (we use the tags in the first instance to associate a commit on master with a PR). Not impossible to update ofc, but not something we should just blindly change.
We also need regular tags to create releases, and release artifacts is how we store the manifests.
I would like to get rid of those tags (and lots of branches) too but that's not for this RFC.
My motivation is to make git fetch and git log less noisy.
Can you update the RFC with this reasoning?
Will do after I've heard from @clopez. It's still possible I've misunderstood what these tags are for.
We could also do likewise with the merge tags.
That would be a ~breaking change for the gecko sync (we use the tags in the first instance to associate a commit on master with a PR). Not impossible to update ofc, but not something we should just blindly change.
We also need regular tags to create releases, and release artifacts is how we store the manifests.
I would like to get rid of those tags (and lots of branches) too but that's not for this RFC.
ah, that's true; yeah, probably worthwhile as a separate discussion
Can you describe how you use the existing tags? Is it to figure out which runs have been triggered in order to find the CI runs in the first place, or is it when you're already looking at a failed CI run and want to find some previous run? Or something else?
I use them to find the commit that triggered the runs on a given day, so I can check the CI.
epochs/daily/2022-07-11_02H
And I open that commit on the github UI: https://github.com/web-platform-tests/wpt/commit/d3422cc02be67fe0eaf5fe9df4c105a592d0d71cSo I use this tags to map a run on a given day to a commit hash (step 3).
If this tags are gone then I would have to rely instead on this command
$ ./wpt rev-list --epoch 1d --max-count=4
52b3307a5be5a03c10df2d96c96191575386be7b
d3422cc02be67fe0eaf5fe9df4c105a592d0d71c
7bb97b8a57ca84a972b7f34611fa73778adaf84d
824d27822a6c110981a6bbb99dddbcdf8455f56a
And pick the second entry (d3422cc02be67fe0eaf5fe9df4c105a592d0d71c) that would be the one mapping the run for the 12th of July.
So, not a big issue for me if this tags get removed as the ./wpt rev-list
command is a good substitute
However my preference would be to automatically purge old tags (to avoid ending with thousands of tags) rather than stop tagging since I find convenient this tags.
But is not a strong preference in any case, feel free to push this if you think is better to remove the tags.
The other potential option here would be to use a different namespace for the epoch refs, such as pushing them into
refs/epochs/*
.
That would be also a good option, i like it. It keeps the info for those interested on it (via git show-ref
) meanwhile it hides this info from the default view of git log
/ git tag
.
I still rely on this tags when there is a issue with WebKitGTK on the CI that needs to be investigated. However, that issue is 100% of the times some weeks old as much. So an alternative to this would be to automatically remove tags older than X (being X a few months)
That would be my preferred option (purge automatically old tags), but I'm a sporadic user of this feature, so I'm fine relying instead on the command
./wpt rev-list
if you feel is better to get rid completely of this tags.