[cmucl-imp] Reverting changes to listen (Fixes #143)
I understand the rationale for reverting the merge associated with closing Issue #143 — Listen doesn’t signal error when given more than one argument ( gitlab.common-lisp.net/cmucl/cmucl/-/issues/143). I’m hoping we can articulate some prioritized principles for the project to assist folks such as myself who are interested in participating in the project. Is this a topic that has been discussed before? — jb — jb
Hi Jon, I do not recall there ever being a discussion about this. Small projects tend to be less structured so that might not be a surprise What are your interests? Carl On Mon, May 29, 2023 at 11:37 AM Jon Boone <ipmonger@delamancha.org> wrote:
I understand the rationale for reverting the merge associated with closing Issue #143 — Listen doesn’t signal error when given more than one argument ( gitlab.common-lisp.net/cmucl/cmucl/-/issues/143).
I’m hoping we can articulate some prioritized principles for the project to assist folks such as myself who are interested in participating in the project.
Is this a topic that has been discussed before?
— jb
— jb _______________________________________________ cmucl-imp mailing list cmucl-imp@cmucl.cons.org https://lists.zs64.net/mailman/listinfo/cmucl-imp
Thanks for the response, Carl. I’m struggling to build the appropriate context in which to understand a number of things about this particular project, such as: • Who are the known user communities? • What are their primary use cases? • What platform(s) do they use? • What is the most important principle to consider in attempting to fix a reported bug? • What is the most important principle to consider in attempting to add a feature? • What is the most important principle to consider when proposing an architectural change to the project? — jb On May 29, 2023 at 15:26 -0400, Carl Shapiro <carl.shapiro@gmail.com>, wrote:
Hi Jon,
I do not recall there ever being a discussion about this. Small projects tend to be less structured so that might not be a surprise
What are your interests?
Carl
On Mon, May 29, 2023 at 11:37 AM Jon Boone <ipmonger@delamancha.org> wrote:
I understand the rationale for reverting the merge associated with closing Issue #143 — Listen doesn’t signal error when given more than one argument ( gitlab.common-lisp.net/cmucl/cmucl/-/issues/143).
I’m hoping we can articulate some prioritized principles for the project to assist folks such as myself who are interested in participating in the project.
Is this a topic that has been discussed before?
— jb
— jb _______________________________________________ cmucl-imp mailing list cmucl-imp@cmucl.cons.org https://lists.zs64.net/mailman/listinfo/cmucl-imp
On Mon, May 29, 2023 at 1:08 PM Jon Boone <ipmonger@delamancha.org> wrote:
I’m struggling to build the appropriate context in which to understand a number of things about this particular project, such as:
- Who are the known user communities? - What are their primary use cases? - What platform(s) do they use?
These are all very good questions to ask. However, I am not sure anyone has the data to answer them definitively. At least for the last bullet the answer is probably a subset of the platforms that we provide binaries.
- What is the most important principle to consider in attempting to fix a reported bug? - What is the most important principle to consider in attempting to add a feature? - What is the most important principle to consider when proposing an architectural change to the project?
These are also very good questions to ask. Do you know of a project that
provides principles for contributors to follow?
I understand not having the definitive answers for the user-centric questions, which is tough even when you proactively attempt to gather the information so it doesn’t surprise me that it’s unknown for CMUCL. Regarding the principles, I don’t remover off hand any particular FOSS projects that I’ve used that do have them articulated, but I always try to have them defined for my teams at work so we have some basis for relatively objective decision making. I did do a quick search and stumbled across this: https://github.com/readme/featured/oss-decision-making — jb On May 29, 2023 at 16:45 -0400, Carl Shapiro <carl.shapiro@gmail.com>, wrote:
On Mon, May 29, 2023 at 1:08 PM Jon Boone <ipmonger@delamancha.org> wrote:
I’m struggling to build the appropriate context in which to understand a number of things about this particular project, such as:
• Who are the known user communities? • What are their primary use cases? • What platform(s) do they use?
These are all very good questions to ask. However, I am not sure anyone has the data to answer them definitively. At least for the last bullet the answer is probably a subset of the platforms that we provide binaries.
• What is the most important principle to consider in attempting to fix a reported bug? • What is the most important principle to consider in attempting to add a feature? • What is the most important principle to consider when proposing an architectural change to the project?
These are also very good questions to ask. Do you know of a project that provides principles for contributors to follow?
On Mon, May 29, 2023 at 1:45 PM Carl Shapiro <carl.shapiro@gmail.com> wrote:
On Mon, May 29, 2023 at 1:08 PM Jon Boone <ipmonger@delamancha.org> wrote:
- What is the most important principle to consider in attempting to fix a reported bug?
Because we're small, it's whatever you feel like fixing, because it affects you, you think you know how to fix it, or you want to learn more about that particular area. We're all volunteers; we do what we want.
- What is the most important principle to consider in attempting to add a feature?
I suppose that it's genuinely useful in some way, hopefully to more than just you, but that's not really necessary, I suppose. The best thing is to file an issue and we can discuss it there.
- What is the most important principle to consider when proposing an architectural change to the project?
I suppose it should end up simplifying things in some way. One thing that Carl and I have talked about is simplifying/removing things from src/code/unix.lisp to make the interface to the C function simpler from a Lisp interface viewpoint. There are some others that have been filed as issues. These are relatively small. Ray
participants (3)
-
Carl Shapiro -
Jon Boone -
Raymond Toy