[Libre-soc-dev] activity log

[Luke Kenneth Casson Leighton]

On 11/29/20, Alexandre Oliva <oliva at gnu.org> wrote:
> On Nov 29, 2020, Luke Kenneth Casson Leighton <lkcl at lkcl.net> wrote:
>
>> insn-histogram.py was a duplicate (out-of-date)
>
> I saw your comments and commits; indeed, that's what prompted me to add
> the original version I'd written in the git revision history,

i'm not keen on file duplication, it causes confusion.

> since
> AFAICT only modified versions had been committed.

i believe i committed the original then edited it.

> I've learned the
> painful way that these things can sometimes be important much later,
> when involved people are no longer around but questions need to be
> answered about provenance, authorship, copyright titles and licensing.

indeed.

> I've now added licensing and authorship information, but not copyright
> notices: because the files have been modified, I don't feel entitled to
> claim full copyrights over those versions.  How should I proceed?
> Should I put in my own copyright notice, and let you put in yours, or
> would you like me to put in both, or what?

happy for you to add it.

>
> I'd also appreciate if stuff under lxo/ was regarded as a personal
> sandbox.

mmm... ok...  except when it ends up being used outside of personal context.

so ChangeLog, no problem.  things being developed that aren't ready
(missing code, syntax errors) no problem.

the moment it works i would much rather it was in the location it's to be used.

basically if any public page has to cross-reference to a sandbox with
a link, "this page was autogenerated by code that is in a sandbox"
that's bad.

> Feel free to copy, but please don't delete without checking
> with me, unless I'm gone.
>
>
> Indeed, I expect an eventual removal of
> openpower/sv/estimate-compression.py, tuned for the now-abandoned
> 8-bit-nop mode switching.  I wanted it to be preserved in my sandbox,
> but even with my readded symlink, the preservation is not quite
> achieved.  So, if/when it's to be removed, I'd appreciate if it was
> instead added back to where I put it to preserve it.  Thanks in advance.

yes makes sense to me.

>
>> in comp16-v1-skel.py i renamed "next" to "nexti" because "next" is a
>> python keyword.
>
> It was fine.  It's not a keyword, just a built-in function, that was not
> used in that scope, so not a problem.  But thanks, I suppose; I don't
> mind the change, I'll just have to change prev to previ and cur to curi
> because I find the asymmetry too distracting.

:)