search

exercism / free-pascal

Exercism exercises in Free Pascal.
https://exercism.org/tracks/free-pascal
MIT License
5 stars 7 forks source link

🤖 Sync org-wide files to upstream repo #2

Closed exercism-bot closed 2 years ago

exercism-bot commented 2 years ago

ℹ More info: https://github.com/exercism/org-wide-files/commit/f346087d1d295687a2556710cb7936ee63b7bcda 👁 Tracking issue: https://github.com/exercism/org-wide-files/issues/132

SaschaMann commented 2 years ago

Yes, don't merge it, this needs to be fixed in org-wide-files.

ErikSchierboom commented 2 years ago

@SaschaMann @kotp If we make it © 2022 in the org-wide-files repo, all tracks would have that license date. Having just discussed this in problem-specifications, this is not necessarily the right approach I think, as there we chose to keep the older data but to add the newer date. Should we also do that in org-wide-files?

kotp commented 2 years ago

I thought that this track was authored this year though. But if it was started last year before June, then 2021 fits, with an addition of this year.

Mai-Lapyst commented 2 years ago

Only the request to add this track was made last year in November; finally decided & created was this repo this year in February, so I think that 2022 is a better fit.

SaschaMann commented 2 years ago

@Mai-Lapyst Yep, it's a bug with some tooling we use to keep files across tracks in sync.

kotp commented 2 years ago

So the question then is where is the track specific copyright notice, if any?

ErikSchierboom commented 2 years ago

Yes, so we have this file that is automatically PR-ed to all tracks whenever it changes: https://github.com/exercism/org-wide-files/blob/main/tracks-files/LICENSE Currently, there is no way to modify it without it applying to all tracks. Not sure what we want here.

kotp commented 2 years ago

The maintainer could choose to just not merge it and close it, until such time that the information is correct, leaving the track specific date intact.

But yeah, not optimal, and likely to have someone forget to not merge it so it eventually slips.

Another way might be to refer to the a copyright file for copyright notification, and let the tracks maintain the per track copyright. The wording on the master copy might be something like:

Copyright (c) 2022 Exercism, see COPYRIGHT file for additional copyrights.

And then tracks can place notice for their tracks.

SaschaMann commented 2 years ago

The maintainer could choose to just not merge it and close it, until such time that the information is correct, leaving the track specific date intact.

This won't work, any sync will overwrite it again.

Currently, there is no way to modify it without it applying to all tracks. Not sure what we want here.

We can apply some changes based on the track with a script if that's necessary. However, I'm not sure what the actual outcome should look like. In the past Katrina semi-manually bumped the years anyway.

ErikSchierboom commented 2 years ago

In the past Katrina semi-manually bumped the years anyway.

Maybe this is also what we should be doing.

kotp commented 2 years ago

@SaschaMann I am not sure that is how it works, if a maintainer chooses to not merge it and closes it instead, it should not overwrite it in the first place, much less again. Unless things have changed. For example, if I close this, then nothing should be overwritten. However, yes, eventually someone is probably going to accept it and merge it, forgetting that we have chosen a social solution to not merge it.

I do agree it is not the best solution, because, yes, it will show up again and someone will have to remember why we are not merging them.

kotp commented 2 years ago

I think that the manual updates shows the purpose and intent, and that it is hard to know the right thing to do otherwise. It will avoid accidentally giving notice before things are really published for a track as well. But I think that there is a difference between the copyright overall, versus specific publications for the tracks. Or accidentally and wrongfully giving notice later than it should be for content in a specific track.

SaschaMann commented 2 years ago

@SaschaMann I am not sure that is how it works, if a maintainer chooses to not merge it and closes it instead, it should not overwrite it in the first place, much less again.

That is how it should work because maintainers aren't meant to modify synced files at all. The original intention was to auto-merge all of these and lock them behind codeowners.

Maybe this is also what we should be doing.

This is what we would be doing by changing the org-wide file to 2022. (We could skip CI on it so that it's distributed with the next regular sync to avoid spamming fwiw)

kotp commented 2 years ago

I would think instead of syncing the files, if there is one source of truth, then perhaps that one source should be referenced, rather than copied and synced. Also, then, that one source of truth only need to be accurate and no sync has to happen.

Then we would have one file that is referenced org-wide, rather than needing to sync it.

Mai-Lapyst commented 2 years ago

Closing this PR since a new sync-PR was opened by the exercism bot: https://github.com/exercism/free-pascal/pull/3 . The copyright change will be merged in this new one, since it would break the sync. If this should be changed, we should change the tooling or discuss it further upstream.