Hi George, David,
It looks like you regenerated the whole practracker file in #30381: https://trac.torproject.org/projects/tor/ticket/30381 https://github.com/torproject/tor/commit/53ac9a9a91a8f2ab45c7555045671607491...
But we usually just add exceptions for the files that we modified.
When we do a full regeneration, we lose a whole lot of warnings that tell us where our code quality is getting worse.
Do you mind if I revert the unrelated changes?
T
On 27 Nov (10:50:50), teor wrote:
Hi George, David,
It looks like you regenerated the whole practracker file in #30381: https://trac.torproject.org/projects/tor/ticket/30381 https://github.com/torproject/tor/commit/53ac9a9a91a8f2ab45c7555045671607491...
But we usually just add exceptions for the files that we modified.
When we do a full regeneration, we lose a whole lot of warnings that tell us where our code quality is getting worse.
Do you mind if I revert the unrelated changes?
No problem!
David
teor teor@riseup.net writes:
Hi George, David,
It looks like you regenerated the whole practracker file in #30381: https://trac.torproject.org/projects/tor/ticket/30381 https://github.com/torproject/tor/commit/53ac9a9a91a8f2ab45c7555045671607491...
But we usually just add exceptions for the files that we modified.
When we do a full regeneration, we lose a whole lot of warnings that tell us where our code quality is getting worse.
Do you mind if I revert the unrelated changes?
No problem either! Sorry for the trouble.
FWIW, what happened there is that when I need to rebase an old dev branch to master (because of revisions etc.), there are almost always multiple conflicts with practracker. Resolving these manually is very annoying (they are many and confusing), so sometimes I have ditched the exceptions.txt completely and just regenerated practracker exceptions from scratch. That's what happened in that case. If someone has a tip for this situation, it would be cool :)
Hi,
On 27 Nov 2019, at 22:34, George Kadianakis desnacked@riseup.net wrote:
teor teor@riseup.net writes:
It looks like you regenerated the whole practracker file in #30381: https://trac.torproject.org/projects/tor/ticket/30381 https://github.com/torproject/tor/commit/53ac9a9a91a8f2ab45c7555045671607491...
But we usually just add exceptions for the files that we modified.
When we do a full regeneration, we lose a whole lot of warnings that tell us where our code quality is getting worse.
Do you mind if I revert the unrelated changes?
No problem either! Sorry for the trouble.
FWIW, what happened there is that when I need to rebase an old dev branch to master (because of revisions etc.), there are almost always multiple conflicts with practracker. Resolving these manually is very annoying (they are many and confusing), so sometimes I have ditched the exceptions.txt completely and just regenerated practracker exceptions from scratch. That's what happened in that case. If someone has a tip for this situation, it would be cool :)
I think the best way to fix this issue is to stop creating code that requires practracker exceptions :-)
If that's not possible, we should: 1. use the master copy of practracker/exceptions.txt 2. re-run practracker 3. ignore warnings 4. fix any new errors
T
Hi,
On 28 Nov 2019, at 15:43, teor teor@riseup.net wrote:
On 27 Nov 2019, at 22:34, George Kadianakis desnacked@riseup.net wrote:
teor teor@riseup.net writes:
It looks like you regenerated the whole practracker file in #30381: https://trac.torproject.org/projects/tor/ticket/30381 https://github.com/torproject/tor/commit/53ac9a9a91a8f2ab45c7555045671607491...
But we usually just add exceptions for the files that we modified.
When we do a full regeneration, we lose a whole lot of warnings that tell us where our code quality is getting worse.
Do you mind if I revert the unrelated changes?
No problem either! Sorry for the trouble.
I had a think about this overnight.
Since we've been adjusting exceptions constantly, I don't think reverting to a particular instant in time is actually helpful.
practracker is meant to help us improve our code quality, and maintain that code quality once it has been improved.
Here's how we're doing that right now: 1. For large changes, require new or modified code to use best practices 2. Allow small changes, without requiring big refactors
I think that's ok, but let's talk about how we could make it better at the next roadmap / retrospective?
T
-
David Goulet -
George Kadianakis -
teor