Re: Regarding copyright assignment to FSF
Maxime Devos writes: > Upgrading the GPLv2-only code might be dificult if multiple people hold > the copyright, so for the GPLv2-only code, it might be a good idea to still > require copyright assignment. When we did it for Mercurial, going from GPLv2 only to or later took years and a *lot* of work. That’s why I consider copyright assignment to the FSF as a good idea. They still get restricted to only use that to further Free Software (if they violate that, the assignment loses the reliablility that they need). >> Even if you do keep it yourself, it makes it more difficult for anyone to >> enforce >> the GPL for that project. > > A fair point, though I don't know how accurate that is. From what I read, it’s the most important point, because the first answer the other sides lawyers always give is „you’re not authorized by *all* authors to enforce the GPL, so you lose.“ Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken signature.asc Description: PGP signature
Re: Regarding copyright assignment to FSF
Maxime Devos, le ven. 13 août 2021 15:42:37 +0200, a ecrit: > so for the GPLv2-only code, it might be a good idea to still > require copyright assignment. The GPLv2-only code is essentially the pfinet stack from Linux, for which we don't have any assignment anyway. But again, this is getting replaced by lwip. Samuel
Re: issue tracking in git
Hi Adriano and Ricardo, I'm also _very_ interested in keeping issues in the same repo as code and I'm really envious of Fossil users [1] :-D Ricardo Wurmus writes: [...] > Many years ago I used Bugs Everywhere > (https://bugs-everywhere.readthedocs.io/en/latest/) for my > personal projects. I really quite liked it, not least because you > can close a bug right as you fix the issue — it’s part of the same > commit. I've still not tested it but there is also git-issue (https://github.com/dspinellis/git-issue), there's also a Guix patch [bug#49581] > I have no idea how well it works when there’s a lot of “traffic” > in a distributed project, e.g. when there are several comments to > the same issue by different people. Having merge conflicts in the > issue tracker is a headache I’d like to avoid. Each issue and issue comment is a file named with a SHA, see https://github.com/dspinellis/git-issue#internals for details; issues and comments can be edited, so coordination and contribution guidelines (also) for issues and comments are still needed. There's no other interface than the CLI, so no email based workflows. An interesting workflow could be to use emails as a "side-channel" for discussions /about/ issues (and issue comments), and maintainers could provide a public-inbox [2] of the "issues-discussion" messages; email discussions can be linked with the git-issue managed issues (and comments) by the maintainers of the project, in order to keep track of the discussions while maintaining them separated from issues (and issue comments). This way, issues should be considered more like (meta-)code than out-of-channel-text, from a maintainers POV. :-D Last, AFAIK Diomidis Spinellis have compiled the most updated list of tools for issue tracking "embedded" in git: https://github.com/dspinellis/git-issue#related-work Best regards, Gio' [1] https://fossil-scm.org/home/doc/trunk/www/bugtheory.wiki [2] that in turn creates a git repo of the messages, and provides a read-only web view of all the archived messages -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
Re: PackaginCon
On Fri, 13 Aug 2021, jbra...@dismail.de wrote: Hey Guix, Apparently there is going to be a virtual Packaging Conference this year: https://packaging-con.org/ […] * Submissions close: 31 August 2021 Thanks to you and Dong Carl on IRC for sharing! This looks like a very interesting event. I'm working on a talk submission focused on the anatomy of a build system using my work-in-progress janet-build-system [0] as an example. I picked this topic because I think it will be a good way to incentivize me to finish the work, show how Guix can abstract over different build systems, and show how Guix collaborates with languages' build tools. [0] https://git.hcoop.net/jackhill/guix/guix.git/shortlog/refs/heads/wip-janet Of course, there are many different parts of our work on Guix that would be relevant for this event, so I'm sure they would welcome many submissions from us. I'm happy to collaborate on something or help brainstorm as desired. I believe that Ludo’ is also working on a submission. (All that said, I am fearful that it may not be possible to participate in this event using Free Software. I hope that my fear is unfounded.) Best, Jack
Re: Regarding copyright assignment to FSF
Damien Zammit schreef op do 12-08-2021 om 12:18 [+1000]: > Hi Ludo, I'm not Ludo, but here's my response anyway. (I'm interested in doing some small and larger things with the Hurd, but I keep being occupied by other things and I'm having a hard time understanding the inner workings ...) > On 11/8/21 11:01 pm, Ludovic Courtès wrote: > > It would be interesting to consider dropping the copyright assignment > > requirement for Hurd/Mach/MiG. For what remains primarily a hobby > > project, this looks to me like a hindrance more than anything else. > > I imagine it is slightly inconvenient for new contributors, but not a > hindrance in my opinion. > It ensures that FSF has complete control of the licensing. > For example, how will FSF upgrade the project to GPLv3 if multiple people > hold the copyright? > (There are plans to remove the GPLv2-only code btw, as Samuel said). When the code is GPLv2-or-later, replace v2 with v3 in the license notices. If the code uses GPLv2-only code, first upgrade the GPLv2-only code to GPLv3-or-later. Upgrading the GPLv2-only code might be dificult if multiple people hold the copyright, so for the GPLv2-only code, it might be a good idea to still require copyright assignment. > PS: Why are you promoting a widespread drop of FSF copyright assignment > anyway? > In my opinion, FSF is a better steward for copyright authorship than any > company > would be assuming you are working on free software on an employer's time and > don't > mutually agree with your employer to keep your own authorship. FWIW, Ludovic does not seem to be promoting assigning copyright to employers. > Even if you do keep it yourself, it makes it more difficult for anyone to > enforce > the GPL for that project. A fair point, though I don't know how accurate that is. Greetings, Maxime. signature.asc Description: This is a digitally signed message part
Re: issue tracking in git
Hi Adriano, some time ago, in the context of an on line conference about Guix, someone suggested me that the bitcoin community had run a survey about available solutions for issue tracking in git Was it perhaps Carl Dong? I don't remember the name of such person and I am wondering if amy progress has been achieved on that front I don’t think there was a decision to do issue tracking in git. Many years ago I used Bugs Everywhere (https://bugs-everywhere.readthedocs.io/en/latest/) for my personal projects. I really quite liked it, not least because you can close a bug right as you fix the issue — it’s part of the same commit. I have no idea how well it works when there’s a lot of “traffic” in a distributed project, e.g. when there are several comments to the same issue by different people. Having merge conflicts in the issue tracker is a headache I’d like to avoid. -- Ricardo
Re: branch master updated: services: cuirass: Add a no-publish argument.
Hey, > So I’d suggest turning that into ‘publish?’, defaulting to #t. Yeah, you're completely right, I reversed the logic with: cfd2442488971420289a12d5ca8f07816e1149bf. Thanks, Mathieu
issue tracking in git
Hello some time ago, in the context of an on line conference about Guix, someone suggested me that the bitcoin community had run a survey about available solutions for issue tracking in git I don't remember the name of such person and I am wondering if amy progress has been achieved on that front So if they're reading, please, chime in I looked on line and found nothing Thanks
