search

squeak-smalltalk / squeak-object-memory

Issues and assets related to the Squeak object memory.
https://bugs.squeak.org
MIT License
11 stars 1 forks source link

Copy JSON ancestry to Trunk #43

Closed LinqLover closed 1 year ago

LinqLover commented 2 years ago

@tonyg kindly already copied the latest JSON version to the Trunk repository (JSON-ul.56). Next we should discuss whether we can copy over the entire ancestry as well, or whether there are unexpected problems with this. It would be helpful to have all ancestry available in source.squeak.org.

tonyg commented 2 years ago

No problems on my side! There should be no licencing problems either as contributions to the squeaksource repo are implicitly MIT.

LinqLover commented 1 year ago

Done, so all the tools like browse revisions are now available for the JSON package, too. :-)

image

One more note: There are several contributors to this package that are not listed in the "About" page (aesp, dkb, klub, ...). Is there anything we should do with that?

j4yk commented 1 year ago

Depending on the license statement of the JSON package, we may be obliged to add their names to the distribution. Apart from it being a nice thing to do. Although GDPR sometimes has me wonder whether attributions are still as permitted as they are required by some licenses, haha.

Half off-topic: Adding the ancestry versions caused some noise on the mailing list. It did not bother me, but some were bothered by that recent incident where old versions were posted again to the list. Would it be worthwhile to let Squeaksource filter out ancestors of versions that were already in the repository before sending these mails?

LinqLover commented 1 year ago

Depending on the license statement of the JSON package, we may be obliged to add their names to the distribution. Apart from it being a nice thing to do. Although GDPR sometimes has me wonder whether attributions are still as permitted as they are required by some licenses, haha.

Complicated topic. Need to escalate to the board? One might argue that the author initials/author field in each MCVersionInfo already constitutes an attribution. Would it make sense in mentioning all unmatched initials in the contributors list as well? Some of them even contain a full name. Should we write a general reminder to squeak-dev?

Adding the ancestry versions caused some noise on the mailing list. It did not bother me, but some were bothered by that recent incident where old versions were posted again to the list. Would it be worthwhile to let Squeaksource filter out ancestors of versions that were already in the repository before sending these mails?

I don't think so, such a heuristic would rather create confusion IMHO. For instance, SIT is currently limited to displaying inbox/trunk versions that were announced on the list ... (By the way, this "noise" could actually have documented all the diffs of the JSON package on the list, but unfortunately, I uploaded the versions in the reverse order. :D)

j4yk commented 1 year ago

(By the way, this "noise" could actually have documented all the diffs of the JSON package on the list, but unfortunately, I uploaded the versions in the reverse order. :D)

Better luck next time ;-)