[GSoC][PATCH] unit-tests: add tests for oidset.h

[GSoC][PATCH] unit-tests: add tests for oidset.h

[Ghanshyam Thakkar]

Add tests for oidset.h library, which were not previously present using
the unit testing framework.

This imposes a new restriction of running the test from the 't/' and
't/unit-tests/bin' for constructing the path to the test files which
are used by t_parse_file(), which tests the parsing of object_ids from
a file. This restriction is similar to the one we already have for
end-to-end tests, wherein, we can only run those tests from 't/'. The
addition of allowing 't/unit-tests/bin' for allowing to run tests from
is for running individual unit tests, which is not currently possible
via any 'make' target. And 'make unit-tests-test-tool' also runs from
't/unit-tests/bin'

Mentored-by: Christian Couder <chriscool@tuxfamily.org>
Mentored-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
Signed-off-by: Ghanshyam Thakkar <shyamthakkar001@gmail.com>
---
I know there is some hesitance from the community in imposing the
restriction of running the unit tests from certain directories, so
if this case does not justify imposing such a restriction, I am fine
with removing t_parse_file() in the next version.

Thanks.

 Makefile                          |   1 +
 t/unit-tests/lib-oid.c            |   2 +-
 t/unit-tests/lib-oid.h            |   1 +
 t/unit-tests/t-oidset.c           | 222 ++++++++++++++++++++++++++++++
 t/unit-tests/t-oidset/sha1-oids   |  10 ++
 t/unit-tests/t-oidset/sha256-oids |  10 ++
 6 files changed, 245 insertions(+), 1 deletion(-)
 create mode 100644 t/unit-tests/t-oidset.c
 create mode 100644 t/unit-tests/t-oidset/sha1-oids
 create mode 100644 t/unit-tests/t-oidset/sha256-oids

diff --git a/Makefile b/Makefile
index e298c8b55e..5c1762fa1b 100644
--- a/Makefile
+++ b/Makefile
@@ -1338,6 +1338,7 @@ UNIT_TEST_PROGRAMS += t-hash
 UNIT_TEST_PROGRAMS += t-hashmap
 UNIT_TEST_PROGRAMS += t-mem-pool
 UNIT_TEST_PROGRAMS += t-oidmap
+UNIT_TEST_PROGRAMS += t-oidset
 UNIT_TEST_PROGRAMS += t-oidtree
 UNIT_TEST_PROGRAMS += t-prio-queue
 UNIT_TEST_PROGRAMS += t-reftable-basics
diff --git a/t/unit-tests/lib-oid.c b/t/unit-tests/lib-oid.c
index 37105f0a8f..8f0ccac532 100644
--- a/t/unit-tests/lib-oid.c
+++ b/t/unit-tests/lib-oid.c
@@ -3,7 +3,7 @@
 #include "strbuf.h"
 #include "hex.h"
 
-static int init_hash_algo(void)
+int init_hash_algo(void)
 {
 	static int algo = -1;
 
diff --git a/t/unit-tests/lib-oid.h b/t/unit-tests/lib-oid.h
index 8d2acca768..fc3e7aa376 100644
--- a/t/unit-tests/lib-oid.h
+++ b/t/unit-tests/lib-oid.h
@@ -14,4 +14,5 @@
  */
 int get_oid_arbitrary_hex(const char *s, struct object_id *oid);
 
+int init_hash_algo(void);
 #endif /* LIB_OID_H */
diff --git a/t/unit-tests/t-oidset.c b/t/unit-tests/t-oidset.c
new file mode 100644
index 0000000000..4a63f9ea94
--- /dev/null
+++ b/t/unit-tests/t-oidset.c
@@ -0,0 +1,222 @@
+#include "test-lib.h"
+#include "oidset.h"
+#include "lib-oid.h"
+#include "hex.h"
+#include "strbuf.h"
+
+static const char *const hex_input[] = { "00", "11", "22", "33", "aa", "cc" };
+
+static void strbuf_test_data_path(struct strbuf *buf, int hash_algo)
+{
+	strbuf_getcwd(buf);
+	strbuf_strip_suffix(buf, "/unit-tests/bin");
+	strbuf_addf(buf, "/unit-tests/t-oidset/%s",
+		    hash_algo == GIT_HASH_SHA1 ? "sha1-oids" : "sha256-oids");
+}
+
+static void setup(void (*f)(struct oidset *st))
+{
+	struct oidset st = OIDSET_INIT;
+	struct object_id oid;
+	int ret = 0;
+
+	if (!check_int(oidset_size(&st), ==, 0)) {
+		test_skip_all("OIDSET_INIT is broken");
+		return;
+	}
+
+	for (size_t i = 0; i < ARRAY_SIZE(hex_input); i++) {
+		if ((ret = get_oid_arbitrary_hex(hex_input[i], &oid)))
+			break;
+		if (!check_int((ret = oidset_insert(&st, &oid)), ==, 0))
+			break;
+	}
+
+	if (!ret && check_int(oidset_size(&st), ==, ARRAY_SIZE(hex_input)))
+		f(&st);
+
+	oidset_clear(&st);
+}
+
+static void t_contains(struct oidset *st)
+{
+	struct object_id oid;
+
+	for (size_t i = 0; i < ARRAY_SIZE(hex_input); i++) {
+		if (!get_oid_arbitrary_hex(hex_input[i], &oid)) {
+			if (!check_int(oidset_contains(st, &oid), ==, 1))
+				test_msg("oid: %s", oid_to_hex(&oid));
+		}
+	}
+
+	if (!get_oid_arbitrary_hex("55", &oid))
+		check_int(oidset_contains(st, &oid), ==, 0);
+}
+
+static void t_insert_dup(struct oidset *st)
+{
+	struct object_id oid;
+
+	if (!get_oid_arbitrary_hex("11", &oid))
+		check_int(oidset_insert(st, &oid), ==, 1);
+
+	if (!get_oid_arbitrary_hex("aa", &oid))
+		check_int(oidset_insert(st, &oid), ==, 1);
+
+	check_int(oidset_size(st), ==, ARRAY_SIZE(hex_input));
+}
+
+static void t_insert_from_set(struct oidset *st_src)
+{
+	struct oidset st_dest = OIDSET_INIT;
+	struct oidset_iter iter_src, iter_dest;
+	struct object_id *oid_src, *oid_dest;
+	struct object_id oid;
+	size_t count = 0;
+
+	oidset_insert_from_set(&st_dest, st_src);
+	check_int(oidset_size(st_src), ==, ARRAY_SIZE(hex_input));
+	check_int(oidset_size(&st_dest), ==, oidset_size(st_src));
+	
+	oidset_iter_init(st_src, &iter_src);
+	oidset_iter_init(&st_dest, &iter_dest);
+
+	/* check that oidset_insert_from_set() makes a copy of the object_ids */
+	while ((oid_src = oidset_iter_next(&iter_src)) &&
+	       (oid_dest = oidset_iter_next(&iter_dest))) {
+		check(oid_src != oid_dest);
+		count++;
+	}
+	check_int(count, ==, ARRAY_SIZE(hex_input));
+
+	for (size_t i = 0; i < ARRAY_SIZE(hex_input); i++) {
+		if (!get_oid_arbitrary_hex(hex_input[i], &oid)) {
+			if (!check_int(oidset_contains(&st_dest, &oid), ==, 1))
+				test_msg("oid: %s", oid_to_hex(&oid));
+		}
+	}
+
+	if (!get_oid_arbitrary_hex("55", &oid))
+		check_int(oidset_contains(&st_dest, &oid), ==, 0);
+	oidset_clear(&st_dest);
+}
+
+static void t_remove(struct oidset *st)
+{
+	struct object_id oid;
+
+	if (!get_oid_arbitrary_hex("55", &oid)) {
+		check_int(oidset_remove(st, &oid), ==, 0);
+		check_int(oidset_size(st), ==, ARRAY_SIZE(hex_input));
+	}
+
+	if (!get_oid_arbitrary_hex("22", &oid)) {
+		check_int(oidset_remove(st, &oid), ==, 1);
+		check_int(oidset_size(st), ==, ARRAY_SIZE(hex_input) - 1);
+		check_int(oidset_contains(st, &oid), ==, 0);
+	}
+
+	if (!get_oid_arbitrary_hex("cc", &oid)) {
+		check_int(oidset_remove(st, &oid), ==, 1);
+		check_int(oidset_size(st), ==, ARRAY_SIZE(hex_input) - 2);
+		check_int(oidset_contains(st, &oid), ==, 0);
+	}
+
+	if (!get_oid_arbitrary_hex("00", &oid))
+	{
+		/* remove a value inserted more than once */
+		check_int(oidset_insert(st, &oid), ==, 1);
+		check_int(oidset_remove(st, &oid), ==, 1);
+		check_int(oidset_size(st), ==, ARRAY_SIZE(hex_input) - 3);
+		check_int(oidset_contains(st, &oid), ==, 0);
+	}
+
+	if (!get_oid_arbitrary_hex("22", &oid))
+		check_int(oidset_remove(st, &oid), ==, 0);
+}
+
+static int input_contains(struct object_id *oid, char *seen)
+{
+	for (size_t i = 0; i < ARRAY_SIZE(hex_input); i++) {
+		struct object_id oid_input;
+		if (get_oid_arbitrary_hex(hex_input[i], &oid_input))
+			return -1;
+		if (oideq(&oid_input, oid)) {
+			if (seen[i])
+				return 2;
+			seen[i] = 1;
+			return 0;
+		}
+	}
+	return 1;
+}
+
+static void t_iterate(struct oidset *st)
+{
+	struct oidset_iter iter;
+	struct object_id *oid;
+	char seen[ARRAY_SIZE(hex_input)] = { 0 };
+	int count = 0;
+
+	oidset_iter_init(st, &iter);
+	while ((oid = oidset_iter_next(&iter))) {
+		int ret;
+		if (!check_int((ret = input_contains(oid, seen)), ==, 0)) {
+			switch (ret) {
+			case -1:
+				break; /* handled by get_oid_arbitrary_hex() */
+			case 1:
+				test_msg("obtained object_id was not given in the input\n"
+					 "  object_id: %s", oid_to_hex(oid));
+				break;
+			case 2:
+				test_msg("duplicate object_id detected\n"
+					 "  object_id: %s", oid_to_hex(oid));
+				break;
+			}
+		} else {
+			count++;
+		}
+	}
+	check_int(count, ==, ARRAY_SIZE(hex_input));
+	check_int(oidset_size(st), ==, ARRAY_SIZE(hex_input));
+}
+
+static void t_parse_file(void)
+{
+	struct strbuf path = STRBUF_INIT;
+	struct oidset st = OIDSET_INIT;
+	struct object_id oid;
+	int hash_algo = init_hash_algo();
+
+	if (!check_int(hash_algo, !=, GIT_HASH_UNKNOWN))
+		return;
+
+	strbuf_test_data_path(&path, hash_algo);
+	oidset_parse_file(&st, path.buf, &hash_algos[hash_algo]);
+	check_int(oidset_size(&st), ==, 6);
+
+	if (!get_oid_arbitrary_hex("00", &oid))
+		check_int(oidset_contains(&st, &oid), ==, 1);
+	if (!get_oid_arbitrary_hex("44", &oid))
+		check_int(oidset_contains(&st, &oid), ==, 1);
+	if (!get_oid_arbitrary_hex("cc", &oid))
+		check_int(oidset_contains(&st, &oid), ==, 1);
+
+	if (!get_oid_arbitrary_hex("11", &oid))
+		check_int(oidset_contains(&st, &oid), ==, 0);
+
+	oidset_clear(&st);
+	strbuf_release(&path);
+}
+
+int cmd_main(int argc UNUSED, const char **argv UNUSED)
+{
+	TEST(setup(t_contains), "contains works");
+	TEST(setup(t_insert_dup), "insert an already inserted value works");
+	TEST(setup(t_insert_from_set), "insert from one set to another works");
+	TEST(setup(t_remove), "remove works");
+	TEST(setup(t_iterate), "iteration works");
+	TEST(t_parse_file(), "parsing from file works");
+	return test_done();
+}
diff --git a/t/unit-tests/t-oidset/sha1-oids b/t/unit-tests/t-oidset/sha1-oids
new file mode 100644
index 0000000000..881f45e661
--- /dev/null
+++ b/t/unit-tests/t-oidset/sha1-oids
@@ -0,0 +1,10 @@
+# comments are ignored
+0000000000000000000000000000000000000000
+9900000000000000000000000000000000000000
+dd00000000000000000000000000000000000000
+
+  4400000000000000000000000000000000000000
+
+bb00000000000000000000000000000000000000 # test comment
+cc00000000000000000000000000000000000000
+# 1100000000000000000000000000000000000000
diff --git a/t/unit-tests/t-oidset/sha256-oids b/t/unit-tests/t-oidset/sha256-oids
new file mode 100644
index 0000000000..3c1c687812
--- /dev/null
+++ b/t/unit-tests/t-oidset/sha256-oids
@@ -0,0 +1,10 @@
+# comments are ignored
+0000000000000000000000000000000000000000000000000000000000000000
+9900000000000000000000000000000000000000000000000000000000000000
+dd00000000000000000000000000000000000000000000000000000000000000
+
+  4400000000000000000000000000000000000000000000000000000000000000
+
+bb00000000000000000000000000000000000000000000000000000000000000 # test comment
+cc00000000000000000000000000000000000000000000000000000000000000
+# 1100000000000000000000000000000000000000000000000000000000000000
-- 
2.46.0

Re: [GSoC][PATCH] unit-tests: add tests for oidset.h

[Patrick Steinhardt]

On Sat, Aug 24, 2024 at 10:50:23PM +0530, Ghanshyam Thakkar wrote:
> Add tests for oidset.h library, which were not previously present using
> the unit testing framework.
> 
> This imposes a new restriction of running the test from the 't/' and
> 't/unit-tests/bin' for constructing the path to the test files which
> are used by t_parse_file(), which tests the parsing of object_ids from
> a file. This restriction is similar to the one we already have for
> end-to-end tests, wherein, we can only run those tests from 't/'. The
> addition of allowing 't/unit-tests/bin' for allowing to run tests from
> is for running individual unit tests, which is not currently possible
> via any 'make' target. And 'make unit-tests-test-tool' also runs from
> 't/unit-tests/bin'
> 
> Mentored-by: Christian Couder <chriscool@tuxfamily.org>
> Mentored-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
> Signed-off-by: Ghanshyam Thakkar <shyamthakkar001@gmail.com>
> ---
> I know there is some hesitance from the community in imposing the
> restriction of running the unit tests from certain directories, so
> if this case does not justify imposing such a restriction, I am fine
> with removing t_parse_file() in the next version.

Another option would be to set up a preprocessor define that gives us
the path to the unit test root directory. But I'm also okayish with the
current version. If it turns out to be annoying we can still iterate.

> diff --git a/t/unit-tests/lib-oid.c b/t/unit-tests/lib-oid.c
> index 37105f0a8f..8f0ccac532 100644
> --- a/t/unit-tests/lib-oid.c
> +++ b/t/unit-tests/lib-oid.c
> @@ -3,7 +3,7 @@
>  #include "strbuf.h"
>  #include "hex.h"
>  
> -static int init_hash_algo(void)
> +int init_hash_algo(void)
>  {
>  	static int algo = -1;
>  
> diff --git a/t/unit-tests/lib-oid.h b/t/unit-tests/lib-oid.h
> index 8d2acca768..fc3e7aa376 100644
> --- a/t/unit-tests/lib-oid.h
> +++ b/t/unit-tests/lib-oid.h
> @@ -14,4 +14,5 @@
>   */
>  int get_oid_arbitrary_hex(const char *s, struct object_id *oid);
>  
> +int init_hash_algo(void);
>  #endif /* LIB_OID_H */

Let's add a comment to explain what this does. Also, do we maybe want to
give it a name that ties it to the unit tests? `init_hash_algo()` is
quite generic and may easily lead to conflicting symbol names.

Maybe something like `t_oid_init_hash_algo()`. `t_` to indicate that it
is testing-related, `oid_` indicates that it's part of "lib-oid.h", and
the remainder describes what it does.

> diff --git a/t/unit-tests/t-oidset.c b/t/unit-tests/t-oidset.c
> new file mode 100644
> index 0000000000..4a63f9ea94
> --- /dev/null
> +++ b/t/unit-tests/t-oidset.c
> @@ -0,0 +1,222 @@
> +#include "test-lib.h"
> +#include "oidset.h"
> +#include "lib-oid.h"
> +#include "hex.h"
> +#include "strbuf.h"
> +
> +static const char *const hex_input[] = { "00", "11", "22", "33", "aa", "cc" };

I think we typically write this `const char * const`, with another space
between `*` and `const`.

> +static void strbuf_test_data_path(struct strbuf *buf, int hash_algo)
> +{
> +	strbuf_getcwd(buf);
> +	strbuf_strip_suffix(buf, "/unit-tests/bin");
> +	strbuf_addf(buf, "/unit-tests/t-oidset/%s",
> +		    hash_algo == GIT_HASH_SHA1 ? "sha1-oids" : "sha256-oids");
> +}

I wouldn't prefix this with `strbuf_`, as it is not part of the strbuf
subsystem. The function just happens to use a strbuf.

> +static void setup(void (*f)(struct oidset *st))

I was wondering what `st` stands for. I'd either call it just `s` or
`set`.

> +{
> +	struct oidset st = OIDSET_INIT;
> +	struct object_id oid;
> +	int ret = 0;
> +
> +	if (!check_int(oidset_size(&st), ==, 0)) {
> +		test_skip_all("OIDSET_INIT is broken");
> +		return;
> +	}
> +
> +	for (size_t i = 0; i < ARRAY_SIZE(hex_input); i++) {
> +		if ((ret = get_oid_arbitrary_hex(hex_input[i], &oid)))
> +			break;
> +		if (!check_int((ret = oidset_insert(&st, &oid)), ==, 0))
> +			break;
> +	}

In both of these cases I'd split out the assignment into a separate
line. While the first instance is likely fine, the second instance makes
me a bit uneasy as it is a macro. I generally do not trust macros to do
the correct thing when being passed a statement with side effects.

[snip]
> +static int input_contains(struct object_id *oid, char *seen)
> +{
> +	for (size_t i = 0; i < ARRAY_SIZE(hex_input); i++) {
> +		struct object_id oid_input;
> +		if (get_oid_arbitrary_hex(hex_input[i], &oid_input))
> +			return -1;
> +		if (oideq(&oid_input, oid)) {
> +			if (seen[i])
> +				return 2;
> +			seen[i] = 1;
> +			return 0;
> +		}
> +	}
> +	return 1;
> +}

This function is somewhat confusing. Contains what? What are the
parameters? Is one of them the expectation, the other one the actual
state? What do we compare against?

I think it would help to get it a more descriptive name that says what
we check for and remove the dependence on global state. Also, the `seen`
array does not seem to be used by any caller. So maybe we should
allocate it ourselves in this function such that it is self-contained.
It requires more allocations, sure, but I highly doubt that this is
going to be important in this test.

Patrick

Re: [GSoC][PATCH] unit-tests: add tests for oidset.h

[Christian Couder]

On Sat, Aug 24, 2024 at 7:20 PM Ghanshyam Thakkar
<shyamthakkar001@gmail.com> wrote:
>
> Add tests for oidset.h library, which were not previously present using
> the unit testing framework.

It might be interesting to also say if there are tests for oidset in
the end-to-end tests, not just in the unit test framework. Also I
think oidset.h is more an API than a library.

> This imposes a new restriction of running the test from the 't/' and
> 't/unit-tests/bin'

Either "from 't/' and 't/unit-tests/bin'" or "from the 't/' and
't/unit-tests/bin' directory" would be a bit better.

> for constructing the path to the test files which
> are used by t_parse_file(), which tests the parsing of object_ids from
> a file.

This might be clearer if it mentioned that t_parse_file() actually
tests oidset_parse_file() which is part of the oidset.h API.

> This restriction is similar to the one we already have for
> end-to-end tests, wherein, we can only run those tests from 't/'.

Ok.

> The
> addition of allowing 't/unit-tests/bin' for allowing to run tests from
> is for running individual unit tests,

Maybe: "Allowing to run tests from 't/unit-tests/bin', in addition to
't/', makes it possible to run individual unit tests,"

> which is not currently possible
> via any 'make' target. And 'make unit-tests-test-tool' also runs from
> 't/unit-tests/bin'

It would be nice if you gave a few examples of commands that can be
run after this patch while they didn't work before it.

> Mentored-by: Christian Couder <chriscool@tuxfamily.org>
> Mentored-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
> Signed-off-by: Ghanshyam Thakkar <shyamthakkar001@gmail.com>
> ---
> I know there is some hesitance from the community in imposing the
> restriction of running the unit tests from certain directories, so
> if this case does not justify imposing such a restriction, I am fine
> with removing t_parse_file() in the next version.

My opinion is that it might be good to remove t_parse_file() for now,
as testing oidset_parse_file() might not be so important. Later an
iteration in a separate patch could then perhap add it while better
discussing if the restrictions that come with adding it are worth it.

> diff --git a/t/unit-tests/lib-oid.c b/t/unit-tests/lib-oid.c
> index 37105f0a8f..8f0ccac532 100644
> --- a/t/unit-tests/lib-oid.c
> +++ b/t/unit-tests/lib-oid.c
> @@ -3,7 +3,7 @@
>  #include "strbuf.h"
>  #include "hex.h"
>
> -static int init_hash_algo(void)
> +int init_hash_algo(void)
>  {
>         static int algo = -1;
>
> diff --git a/t/unit-tests/lib-oid.h b/t/unit-tests/lib-oid.h
> index 8d2acca768..fc3e7aa376 100644
> --- a/t/unit-tests/lib-oid.h
> +++ b/t/unit-tests/lib-oid.h
> @@ -14,4 +14,5 @@
>   */
>  int get_oid_arbitrary_hex(const char *s, struct object_id *oid);
>
> +int init_hash_algo(void);
>  #endif /* LIB_OID_H */

It seems that the changes above will go away when some patches you
already sent will be merged, which should happen soon. It might have
been nice to say this in the section after the "---" line.

> +static void t_parse_file(void)
> +{
> +       struct strbuf path = STRBUF_INIT;
> +       struct oidset st = OIDSET_INIT;
> +       struct object_id oid;
> +       int hash_algo = init_hash_algo();
> +
> +       if (!check_int(hash_algo, !=, GIT_HASH_UNKNOWN))
> +               return;

If initializing the hash algo fails here, it is likely because it
already failed when get_oid_arbitrary_hex() (which initializes it) was
called in the tests before this one. So I think it might be even
better to move the above hash algo initialization code to setup() and
make setup() error out in case the initialization fails. Then setup()
could pass 'hash_algo' to all the functions it calls, even if some of
them don't use it.

> +       strbuf_test_data_path(&path, hash_algo);
> +       oidset_parse_file(&st, path.buf, &hash_algos[hash_algo]);
> +       check_int(oidset_size(&st), ==, 6);
> +
> +       if (!get_oid_arbitrary_hex("00", &oid))
> +               check_int(oidset_contains(&st, &oid), ==, 1);
> +       if (!get_oid_arbitrary_hex("44", &oid))
> +               check_int(oidset_contains(&st, &oid), ==, 1);
> +       if (!get_oid_arbitrary_hex("cc", &oid))
> +               check_int(oidset_contains(&st, &oid), ==, 1);
> +
> +       if (!get_oid_arbitrary_hex("11", &oid))
> +               check_int(oidset_contains(&st, &oid), ==, 0);
> +
> +       oidset_clear(&st);
> +       strbuf_release(&path);
> +}

Thanks.

Re: [GSoC][PATCH] unit-tests: add tests for oidset.h

[Junio C Hamano]

Christian Couder <christian.couder@gmail.com> writes:

>> Add tests for oidset.h library, which were not previously present using
>> the unit testing framework.
>
> It might be interesting to also say if there are tests for oidset in
> the end-to-end tests, not just in the unit test framework. Also I
> think oidset.h is more an API than a library.

Thanks for pointing these out; 100% agreed.

>> This imposes a new restriction of running the test from the 't/' and
>> 't/unit-tests/bin'

I thought we just got rid of such an restriction during the review
of another unit-test topic?  If this is a recurring theme, perhaps
we should teach t/unit-test/test-lib.c a few ways to specify where
the auxiliary files for unit-tests are (e.g. "-d <datadir>" command
line option, or $GIT_UNIT_TEST_DATA_DIR environment variable).

Even though the end-to-end tests do not allow you to start them from
an arbitrary directory (it shouldn't be a rocket science to teach
them to do so, though), they can run in an arbitrary place with the
"--root" option without hindering its ability to read its auxiliary
data files, because they can learn where the t/ directory is by
looking at $TEST_DIRECTORY and a few other variables.  A similar
idea should be applicable to the unit-tests framework.

Thanks.

Re: [GSoC][PATCH] unit-tests: add tests for oidset.h

[Junio C Hamano]

Christian Couder <christian.couder@gmail.com> writes:

> On Sat, Aug 24, 2024 at 7:20 PM Ghanshyam Thakkar
> <shyamthakkar001@gmail.com> wrote:
>>
>> Add tests for oidset.h library, which were not previously present using
>> the unit testing framework.
>
> It might be interesting to also say if there are tests for oidset in
> the end-to-end tests, not just in the unit test framework. Also I
> think oidset.h is more an API than a library.
> ...
> If initializing the hash algo fails here, it is likely because it
> already failed when get_oid_arbitrary_hex() (which initializes it) was
> called in the tests before this one. So I think it might be even
> better to move the above hash algo initialization code to setup() and
> make setup() error out in case the initialization fails. Then setup()
> could pass 'hash_algo' to all the functions it calls, even if some of
> them don't use it.
> ...
>
> Thanks.

While reviewing the "What's cooking" list of topics after tagging
-rc0 of this development cycle, I noticed that this topic from late
August has been expecting but not yet seeing an update.

As discussed elsewhere on the "Project Tracking" thread, I am in
favor of formally adopting a policy to discard a topic from 'seen'
after being inactive for 3 weeks, without having seen a clear
consensus that it is good enough to be moved to 'next'.  Interested
parties are still free to revive the topic even after such a discard
event.

    Side note: The definition of being "inactive" for the purpose of
    the policy is that nobody has discussed the topic, no new
    iteration of the topic was posted, and no responses to the
    review comments were given.

I'll discard this one by the end of this week unless the topic sees
any activity.  It looks to me that the project decided that a longer
term direction to adopt "clar" as the unit-tests framework, so this
patch would need to be written even if it were perfect in the old
world order anyway.

Thanks.

[PATCH] howto-maintain-git: discarding inactive topics

[Junio C Hamano]

When a patch series happened to look interesting to the maintainer
but is not ready for 'next', it is applied on a topic branch and
merged to the 'seen' branch to keep an eye on it.  In an ideal
world, the participants give reviews and the original author
responds to the reviews, and such iterations may produce newer
versions of the patch series, and at some point, a concensus is
formed that the latest round is good enough for 'next'.  Then the
topic is merged to 'next' for inclusion in a future release.

In a much less ideal world we live in, however, a topic sometimes
get stalled.  The original author may not respond to hanging review
comments, may promise an update will be sent but does not manage to
do so, nobody talks about the topic on the list and nobody builds
upon it, etc.

Following the recent trend to document and give more transparency to
the decision making process, let's set a deadline to keep a topic
still alive, and actively discard those that are inactive for a long
period of time.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 Documentation/howto/maintain-git.txt | 17 ++++++++++++++++-
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git i/Documentation/howto/maintain-git.txt w/Documentation/howto/maintain-git.txt
index da31332f11..e797b32522 100644
--- i/Documentation/howto/maintain-git.txt
+++ w/Documentation/howto/maintain-git.txt
@@ -67,7 +67,22 @@ the mailing list after each feature release is made:
    before getting merged to 'master'.
 
  - 'seen' branch is used to publish other proposed changes that do
-   not yet pass the criteria set for 'next' (see above).
+   not yet pass the criteria set for 'next' (see above), but there
+   is no promise that 'seen' will contain everything.  A topic that
+   had no reviewer reaction may not be picked up.
+
+   - A new topic will first get merged to 'seen', unless it is
+     trivially correct and clearly urgent, in which case it may be
+     directly merged to 'next' or even to 'master'.
+
+   - If a topic that was picked up to 'seen' becomes and stays
+     inactive for 3 calendar weeks without having seen a clear
+     consensus that it is good enough to be moved to 'next', the
+     topic may be discarded from 'seen'.  Interested parties are
+     still free to revive the topic.  For the purpose of this
+     guideline, the definition of being "inactive" is that nobody
+     has discussed the topic, no new iteration of the topic was
+     posted, and no responses to the review comments were given.
 
  - The tips of 'master' and 'maint' branches will not be rewound to
    allow people to build their own customization on top of them.

Re: [GSoC][PATCH] unit-tests: add tests for oidset.h

[Christian Couder]

On Thu, Sep 26, 2024 at 8:28 PM Junio C Hamano <gitster@pobox.com> wrote:

> I'll discard this one by the end of this week unless the topic sees
> any activity.  It looks to me that the project decided that a longer
> term direction to adopt "clar" as the unit-tests framework, so this
> patch would need to be written even if it were perfect in the old
> world order anyway.

Yeah, unless Ghanshyam or someone else wants to continue working on
it, I think finishing this work should be part of the "Convert unit
tests to use the clar testing framework" Outreachy project that
Patrick and Phillip agreed to co-mentor. This project will only start
next December though (supposing a good Outreachy intern is selected),
so it's fine to discard it in the meantime.

Thanks.

Re: [GSoC][PATCH] unit-tests: add tests for oidset.h

[Junio C Hamano]

Christian Couder <christian.couder@gmail.com> writes:

> On Thu, Sep 26, 2024 at 8:28 PM Junio C Hamano <gitster@pobox.com> wrote:
>
>> I'll discard this one by the end of this week unless the topic sees
>> any activity.  It looks to me that the project decided that a longer
>> term direction to adopt "clar" as the unit-tests framework, so this
>> patch would need to be written even if it were perfect in the old
>> world order anyway.
>
> Yeah, unless Ghanshyam or someone else wants to continue working on
> it, I think finishing this work should be part of the "Convert unit
> tests to use the clar testing framework" Outreachy project that
> Patrick and Phillip agreed to co-mentor. This project will only start
> next December though (supposing a good Outreachy intern is selected),
> so it's fine to discard it in the meantime.

And of course it does not have to wait until December.

If anybody wants to work on adding a unit test for oidset, they can
do so immediately.  A new unit-test, including the oidset one,
should be written using clar framework.

Thanks.

Re: [GSoC][PATCH] unit-tests: add tests for oidset.h

[Patrick Steinhardt]

On Fri, Sep 27, 2024 at 11:47:40AM -0700, Junio C Hamano wrote:
> Christian Couder <christian.couder@gmail.com> writes:
> 
> > On Thu, Sep 26, 2024 at 8:28 PM Junio C Hamano <gitster@pobox.com> wrote:
> >
> >> I'll discard this one by the end of this week unless the topic sees
> >> any activity.  It looks to me that the project decided that a longer
> >> term direction to adopt "clar" as the unit-tests framework, so this
> >> patch would need to be written even if it were perfect in the old
> >> world order anyway.
> >
> > Yeah, unless Ghanshyam or someone else wants to continue working on
> > it, I think finishing this work should be part of the "Convert unit
> > tests to use the clar testing framework" Outreachy project that
> > Patrick and Phillip agreed to co-mentor. This project will only start
> > next December though (supposing a good Outreachy intern is selected),
> > so it's fine to discard it in the meantime.
> 
> And of course it does not have to wait until December.
> 
> If anybody wants to work on adding a unit test for oidset, they can
> do so immediately.  A new unit-test, including the oidset one,
> should be written using clar framework.

I'm also happy to help anybody who wants write such a new unit test
suite.

Let me use this to give a quick status update regarding my upstream
quest to address the feedback I got during reviews on the clar itself:

  - There is a .editorconfig file now.

  - All the cross-platform compatibility fixes have been merged.

  - We have Win32 wired up in CI. Doing so via Makefiles was too much of
    a hassle, so I converted the project to use CMake for easier cross
    platform testability. The fact that the project uses CMake does not
    impact us though, as we wire it up ourselves anyway.

  - All memory allocation errors are now handled consistently.

Currently in review is:

  - Self-tests for the clar, where we use clar to assert that clar
    works.

  - A small memory leak fix, as well as wiring up leak sanitizers in CI.

I've also got a patch series sitting locally that introduces type-safe
wrappers for the assertions that I'll move into review once self-tests
have landed. That would then address the last bit of feedback I got, if
I remember correctly.

Just to let you folks know that I didn't just do nothing after this has
landed in Git.

Patrick

Re: [GSoC][PATCH] unit-tests: add tests for oidset.h

[Junio C Hamano]

Patrick Steinhardt <ps@pks.im> writes:

> Let me use this to give a quick status update regarding my upstream
> quest to address the feedback I got during reviews on the clar itself:
>
>   - There is a .editorconfig file now.
>
>   - All the cross-platform compatibility fixes have been merged.
>
>   - We have Win32 wired up in CI. Doing so via Makefiles was too much of
>     a hassle, so I converted the project to use CMake for easier cross
>     platform testability. The fact that the project uses CMake does not
>     impact us though, as we wire it up ourselves anyway.
>
>   - All memory allocation errors are now handled consistently.
>
> Currently in review is:
>
>   - Self-tests for the clar, where we use clar to assert that clar
>     works.
>
>   - A small memory leak fix, as well as wiring up leak sanitizers in CI.
>
> I've also got a patch series sitting locally that introduces type-safe
> wrappers for the assertions that I'll move into review once self-tests
> have landed. That would then address the last bit of feedback I got, if
> I remember correctly.
>
> Just to let you folks know that I didn't just do nothing after this has
> landed in Git.

;-)

Nice to see that the code is improved not just for us but for other
consumers.

Thanks.

Notes from the Git Contributor's Summit, 2024

[Taylor Blau]

It was great to see folks at the Contributor's Summit today during Git
Merge!

The notes are available (as read-only) in Google Docs, too, for folks
who prefer to view them there are the following link:

    https://docs.google.com/document/d/1IZvW1_pnkrMMWnBmZO2MbT4QCjIPJBWNJg_shYqSnrE/edit

At the Contributor's Summit, we discussed the following topics:

  - Rust (Kyle)
  - Top-level lib/ directory (Patrick)
  - Structured Error Handling (brian)
  - Platform Support Policy (Emily)
  - SHA-256 / Git 3.0 (Patrick)
  - Git / Conservancy Stuff (Taylor)
  - How to attract new contributors? + Community Discord (Jonathan N. /
      Calvin Wan)
  - Modern Build System (Patrick)
  - Bundle-URI on fetch / resumable clone (Toon)
  - Project Tracking (Emily / Patrick)
  - git-scm.com state of the site (Johannes)

I'll send the broken-out notes for each topic in a response to this
message for posterity, and so folks can continue the discussion on the
list.

Like in previous years, if you have any feedback on how the
Contributor's Summit went please feel free to share it with me here, or
off-list.

I hope to see everybody in person next year!

Thanks,
Taylor

[TOPIC 01/11] Rust

[Taylor Blau]

Rust
=====

(moderator: Kyle; notetaker: Taylor)

* Kyle: Rust code in the Git project; do we want it? Why would we want
  it?
* Elijah: Anybody other than Randall that objects to it?
* Peff: I don't object, but what does it mean for existing developers?
  Will non-Rust developers need to start learning?
* Emily: The avenue for introducing Rust is replacing low-level C
  libraries that are complicated and un-maintainable.
* Peff: What's low-level? Peff considers strbuf to be low-level, but
  Emily considers merge-ort.
* Kyle: Anything dealing with untrusted inputs would be a good spot to
  start.
* Patrick: Instead: take a system like reftables that is already
  self-contained.
* Jonathan: Another nice thing: if someone is on a platform without good
  Rust support, then they could stll use Git without reftables.
* brian: Rust is optional, can we add small new features and performance
  improvements that replace existing code, but it's not required.
* Emily: are we then carrying parallel versions of the same thing? What
  does that mean for the C version?
* Taylor: I don't want to double our vulnerable surface area.
* Patrick: Right, either you go all in or don't.
* Taylor: I don't want to give too much stock to a small number of
  people/platforms and hold the project hostage.
* Emily: old versions aren't going away.
* Patrick: Those could be maintenance releases.
* Do we need to support an older maint version in pure C
* Backport security fixes? Would issues be in both implementations?
* Do we want to encourage those without Rust support to maintain a
  friendly fork C version
* Johannes: Transpile C to Rust?
* Elijah: Does that presume we're not using Rust libraries, or are those
  transpile-targets as well.
* brian: We are going to have to use 'std', the question is what
  versions of Rust are we going to support? Can't be the latest version,
  since it only lives for six weeks.
* Taylor: vague idea of why we would want to use rust, but what are the
  concrete benefits of moving to rust?
   * brian: increased parallelization, can't write unsafe code,
     incremental parsing of objects. When it fails, you get a panic
     instead of a segfault.
   * Patrick: clear ownership semantics, was a huge problem with the
     memory leak work that they have been doing, it's not clear who owns
     what at what time.
   * Jonathan: 3 things; (a) user-facing benefit of memory safety, (b)
     productivity benefit to ourselves to have better architecture makes
     it easier to make changes, (c) would attract new contributors to
     the project.
   * Kyle: that's what I was going to say on (c), writing C is daunting.
   * Patrick: I'm in the opposite camp, I'm scared of Rust!
* Why not move over to the gitoxide project? Probably not realistic
  within the next 10 years, though Sebastian is doing great work.
* Taylor: great, what's the transition plan?
* Patrick: can't start until libification makes progress.
* Elijah: what about a low-enough level function that we can start with?
* Patrick: Still not work-able, there are too many global variables that
  we need to contend with.
* Taylor: IMO better to port to rust first from an implementation that
  we know, then libify in a language that has better support for
  refactoring.
* Jonathan: likes what Patrick was saying about having modularization
  make this easier. The other obstacle is that if we want to use any
  Rust at all, we need to have a POLICY on how we use Rust.
* brian: C shared library built in Rust, or top-level build with cargo?
* Have had experience with a previous C-to-rust migration! C FFI to call
  into Rust from C until everything is ported over.
* Patrick: modularization should be the first step, otherwise we're
  going to have the same architecture that we have now. If we inherit it
  now, it'll never get fixed.
* Mark: need Git to continue to be relevant in 10 years, making this
  kind of change is part of that
* Maintainability is something we can invest in.
* Emily: governance can help corporate contributors behave better. Say
  "your contributions have to meet this standard"
* Patrick: meanwhile I don't want to push away drive-by contributors
* Elijah: if someone wants to contribute a specific component in Rust,
  such as a replacement builtin, they need to call C, what happens to
  infrastructure such as option parsing?
* Emily: I really like the idea of starting with reftable
* Patrick: I was going to make a Rust implementation of reftable anyway

RE: [TOPIC 01/11] Rust

[rsbecker]

On September 20, 2024 10:18 AM, Taylor Blau wrote:
>* Kyle: Rust code in the Git project; do we want it? Why would we want
>  it?
>* Elijah: Anybody other than Randall that objects to it?

To be honest, I do not fundamentally object to Rust. My problem is that the
Rust team is not supporting including NonStop as a platform. I would love
to be able to do the port, but it is not up to me - it is up to Rust's permission
(or lack of in this case) to support NonStop, and I do not see this changing
in my life-time. Depending on a piece of technology where control of where
it runs is outside of git's control is not responsible, in my view. It restricts
where git can run, and excludes platforms that currently use a critical piece
of infrastructure (git). I have tens of thousands of people in my community
who depend on git on a daily basis, and simply kicking them off because
of a decision, or lack of decision, that some unrelated dependency controls
should be (unfortunately does not appear to be for git) a showstopper.

I am just the vocal one who is paying attention to the issue.

Sincerely,
Randall

Re: [TOPIC 01/11] Rust

[Sean Allred]

Hi Randall,

This ended up being pretty long, so I apologize in advance for 'not
having the time to make it shorter' (if you'll permit a small amount of
plagiarism there). These are just my thoughts on this topic that have
been cooking for a long time. I've been following this conversation
closely, and for the first time, I thought I might have something small
to add. Unfortunately, it's taken a lot of words to say it!

<rsbecker@nexbridge.com> writes:
> On September 20, 2024 10:18 AM, Taylor Blau wrote:
>>* Kyle: Rust code in the Git project; do we want it? Why would we want
>>  it?
>>* Elijah: Anybody other than Randall that objects to it?
>
> To be honest, I do not fundamentally object to Rust.

I don't think anybody (or at least, I hope nobody) thinks so; this is
absolutely a conversation we can and should (and I believe do) have in
good faith :-)

I've not contributed to this conversation much so far -- not out of lack
of interest, but out of respect:

1. While I've been using Git for many, many years, I'm a pretty new face
   on this list. I'm still working on making a good first impression :-)

2. I know absolutely _nothing_ about NonStop, but I do know what it's
   like to feel like you're a member of an invisible set of users. There
   are significant aspects of my $DAYJOB where that is absolutely the
   case, so I want to leave room for what I know that I don't know. I
   know your customers are important, and (I think I know) you
   supporting your customers requires the tools being used to be
   supported.

3. I don't even know _that_ much about Git's implementation compared to
   the experts on this list, so I feel ill-equipped to judge personally
   whether Rust is a good fit for the project to begin with -- thus I
   don't feel I have much to contribute to that conversation over what
   the experts have already said.

Putting my own cards on the table -- I'd be in favor of introducing Rust
into Git's codebase for many of the reasons cited elsewhere. Based on my
naive understanding of the codebase and the types of bug fixes I've seen
come in during my time paying attention to this list, it does seem like
rustc would add the value for which it was designed. I say this not to
'upvote' the idea of including Rust, but to be transparent about the
context from which I'm speaking.

So, in good faith, here goes :-)

> My problem is that the Rust team is not supporting including NonStop
> as a platform. I would love to be able to do the port, but it is not
> up to me - it is up to Rust's permission (or lack of in this case) to
> support NonStop, and I do not see this changing in my life-time.

Is this just regarding the GCC dependency I've seen you reference
elsewhere[1] or is there something else? I just want to make all the
cards are on the table here -- particularly I want to make sure you're
not referencing some licensing incompatibility or project policy that
could be (even) more challenging than porting GCC to NonStop. An
uneducated search of rustc's book[2] for 'gcc' didn't yield anything
immediately interesting, but there are call-outs for not supporting
platforms that introduce license incompatibilities or 'onerous legal
terms'.

If not, is this about (what I assume to be the) 'tier 3' platform
support policy mentioned at [2]? In some respects, it seems like this is
similar to the status of NonStop as a supported platform in the Git
project already, though I suppose that's also a main topic of
conversation for the 'supported platform' thread elsewhere. It does seem
in line with what you already do, though, which is to provide patches to
Git when something merges that breaks tests on NonStop. It seems it
would be similar in a Rust world, though patches would 'just' be sent to
the Rust maintainers instead. (I say that knowing that it would be an
entirely foreign codebase and set of concerns for submitting correct
patches -- so the two are not at all similar in effort, just in
behavior.)

> Depending on a piece of technology where control of where it runs is
> outside of git's control is not responsible, in my view. It restricts
> where git can run, and excludes platforms that currently use a
> critical piece of infrastructure (git).

I think this is going to be true of any platform that the Git project
chooses to continue to build upon, isn't it? Any platform-specific bugs
in the various C compilers used are not in this project's control,
either, nor OpenSSL, cURL, PCRE, gettext, etc., etc. that are already
essential to Git's main functions when it's being used by a human (i.e.,
not as part of a larger automated system).

Any added dependency will run the risk of not being buildable on every
platform out there -- even if it's included in the standard library,
potentially -- and I don't believe it's a sustainable practice to never
add any dependencies.

> I have tens of thousands of people in my community who depend on git
> on a daily basis, and simply kicking them off because of a decision,
> or lack of decision, that some unrelated dependency controls should be
> (unfortunately does not appear to be for git) a showstopper.

I'd like to understand this a little better.

First, from the original notes:
>> Emily: old versions aren't going away.
which I mention only to supply the obvious counterpoint. I believe
you've said in the past (sorry that I can't find the specific link) that
you'd like to see Git continue to receive improvements and enhancements
that you can forward onto your customers. This is great! I understand
this perfectly. I have the very same desire for my users (which number
in the 3-4k range). I look forward to every performance improvement and
revamped workflow with bated breath -- wondering how/when it can be
incorporated into our system to give our folks the best experience they
can possibly have as direct users of Git in a heavily automated system.

It stands to reason that your users wouldn't see such improvements if
incompatible technologies like Rust are adopted into the codebase and
those features were written using this incompatible technology. This is
understandably a frustrating prospect! Previously, you would have been
able to get even more value out of all the open-source effort (and your
own effort as a maintainer keeping it compatible) -- and now it's not
really feasible. I do understand this sentiment. (Regardless of how much
I understand it, if this is not _your_ sentiment, please let me know!)

Here's where I'm struggling a bit. From what I see, I understand two
contradictory points:

1. To continue building Git on every platform where it builds today, the
   project must either

   a) not add any new incompatible dependencies or
   b) put any such dependencies behind a feature flag (e.g. NO_CURL) so
      that Git may continue to be built without that dependency.

   Great, no harm -- no foul. But...

2. If you continue building without that dependency, you don't get that
   feature, so the original purpose of enhancing Git -- to pass that
   benefit on to users -- is lost.

So it would seem that this leaves us with only option (a) to not add any
new incompatible dependencies -- which is what I understand you've been
proposing. Certainly reasonable. But then how do you build cool new
stuff? Well, build it yourself, I guess.

There's been a _lot_ of cool new stuff lately. This is great! But this
does seem to be spearheaded by the work (and thus funding) of companies
like GitLab, Microsoft, and Google (and these are just the ones I
recognize either by contributor name or by email domain). I'm incredibly
thankful for the work and expertise these folks add to the project on an
ongoing basis.

I worry though that the 'cool new stuff' seems to require such
investment. It is _hard_ to write correct, safe C. I worry that this
difficulty will eventually translate to significant, safe contributions
coming only from those with the resources to create them and not from a
more diverse pool of contributors. As grateful as I am to large
companies who fund Git contributions, I don't think those companies,
given the choice in and of themselves, would think twice about dropping
support for a platform they don't use -- and that is probably a much
smaller set than 'does the platform have GCC'. I don't think this is a
danger today or tomorrow, but it _is_ a danger of not having a diverse
group of contributors -- and that is the danger posed by not allowing
yourself to use any of the 'cool new stuff' _other_ people have written.

--

I don't have a satisfying response to what to do for NonStop in a world
where Rust enters the Git codebase. I really don't, and that frustrates
me for you. I hope that there's a solution out there (maybe from your
vendors, maybe from the storied halls of GCC maintainers, who knows),
but I'll echo (more earnestly this time):
>> Emily: old versions aren't going away.
Nobody has the power to 'kick users off' a project such as Git -- not
even if everyone somehow miraculously agreed to port the entire thing to
something hot off the presses at /r/programminglanguages :-) Ultimately,
your systems will continue to function regardless of what happens
upstream. Of course I can't speak to support contracts, but I assume
neither can anyone on this list.

That said, I also don't know how a project can continue to thrive
without the (occasional, thoughtful, and deliberate) introduction of new
technologies, new contributors excited and emboldened by those
technologies, and new ideas from those contributors.

Change is essential to growth. Like I mentioned at the outset, I'll let
the true experts on this list speak to whether _this_ change is
essential for growth, but I hope I've at least made some points that
were worth reading.

[1]: https://lore.kernel.org/git/007c01da4420$10a7b700$31f72500$@nexbridge.com/
[2]: https://doc.rust-lang.org/rustc/target-tier-policy.html

-- 
Sean Allred

RE: [TOPIC 01/11] Rust

[rsbecker]

On September 22, 2024 10:26 PM, Sean Allred wrote:
>This ended up being pretty long, so I apologize in advance for 'not having
the time
>to make it shorter' (if you'll permit a small amount of plagiarism there).
These are
>just my thoughts on this topic that have been cooking for a long time. I've
been
>following this conversation closely, and for the first time, I thought I
might have
>something small to add. Unfortunately, it's taken a lot of words to say it!
>
><rsbecker@nexbridge.com> writes:
>> On September 20, 2024 10:18 AM, Taylor Blau wrote:
>>>* Kyle: Rust code in the Git project; do we want it? Why would we want
>>>  it?
>>>* Elijah: Anybody other than Randall that objects to it?
>>
>> To be honest, I do not fundamentally object to Rust.
>
>I don't think anybody (or at least, I hope nobody) thinks so; this is
absolutely a
>conversation we can and should (and I believe do) have in good faith :-)
>
>I've not contributed to this conversation much so far -- not out of lack of
interest,
>but out of respect:
>
>1. While I've been using Git for many, many years, I'm a pretty new face
>   on this list. I'm still working on making a good first impression :-)
>
>2. I know absolutely _nothing_ about NonStop, but I do know what it's
>   like to feel like you're a member of an invisible set of users. There
>   are significant aspects of my $DAYJOB where that is absolutely the
>   case, so I want to leave room for what I know that I don't know. I
>   know your customers are important, and (I think I know) you
>   supporting your customers requires the tools being used to be
>   supported.
>
>3. I don't even know _that_ much about Git's implementation compared to
>   the experts on this list, so I feel ill-equipped to judge personally
>   whether Rust is a good fit for the project to begin with -- thus I
>   don't feel I have much to contribute to that conversation over what
>   the experts have already said.
>
>Putting my own cards on the table -- I'd be in favor of introducing Rust
into Git's
>codebase for many of the reasons cited elsewhere. Based on my naive
>understanding of the codebase and the types of bug fixes I've seen come in
during
>my time paying attention to this list, it does seem like rustc would add
the value for
>which it was designed. I say this not to 'upvote' the idea of including
Rust, but to be
>transparent about the context from which I'm speaking.
>
>So, in good faith, here goes :-)
>
>> My problem is that the Rust team is not supporting including NonStop
>> as a platform. I would love to be able to do the port, but it is not
>> up to me - it is up to Rust's permission (or lack of in this case) to
>> support NonStop, and I do not see this changing in my life-time.
>
>Is this just regarding the GCC dependency I've seen you reference
elsewhere[1] or is
>there something else? I just want to make all the cards are on the table
here --
>particularly I want to make sure you're not referencing some licensing
>incompatibility or project policy that could be (even) more challenging
than porting
>GCC to NonStop. An uneducated search of rustc's book[2] for 'gcc' didn't
yield
>anything immediately interesting, but there are call-outs for not
supporting
>platforms that introduce license incompatibilities or 'onerous legal
terms'.

The GCC dependency, which does not currently exist in git, is independent of
Rust.
Rust has its own rules and runtime. The issue here is that the Rust team
gets to
decide what platforms can participate, NOT the platform maintainers. No
matter
what my intent, or resources, I cannot get the Rust team to "Allow" a port.
In
many ways, this is egregious and is a policy issue entirely on Rust, not us.
We
want to do a Rust port but are simply not allowed/approved. It is their
policy.

>If not, is this about (what I assume to be the) 'tier 3' platform support
policy
>mentioned at [2]? In some respects, it seems like this is similar to the
status of
>NonStop as a supported platform in the Git project already, though I
suppose that's
>also a main topic of conversation for the 'supported platform' thread
elsewhere. It
>does seem in line with what you already do, though, which is to provide
patches to
>Git when something merges that breaks tests on NonStop. It seems it would
be
>similar in a Rust world, though patches would 'just' be sent to the Rust
maintainers
>instead. (I say that knowing that it would be an entirely foreign codebase
and set of
>concerns for submitting correct patches -- so the two are not at all
similar in effort,
>just in
>behavior.)

This is not a tier 3 policy with regards to Rust. It is exclusionary.
 
>> Depending on a piece of technology where control of where it runs is
>> outside of git's control is not responsible, in my view. It restricts
>> where git can run, and excludes platforms that currently use a
>> critical piece of infrastructure (git).
>
>I think this is going to be true of any platform that the Git project
chooses to
>continue to build upon, isn't it? Any platform-specific bugs in the various
C
>compilers used are not in this project's control, either, nor OpenSSL,
cURL, PCRE,
>gettext, etc., etc. that are already essential to Git's main functions when
it's being
>used by a human (i.e., not as part of a larger automated system).
>
>Any added dependency will run the risk of not being buildable on every
platform
>out there -- even if it's included in the standard library, potentially --
and I don't
>believe it's a sustainable practice to never add any dependencies.

I agree that it is not a good policy to never add new dependencies. However,
Dependencies must be reasonable and give the platforms a chance, at least,
to adapt. We cannot in the case of Rust. The problem is not actually that we
can
do without new features that are in Rust but not C. The problem is when
there
are CVEs. Suppose a severe CVE happens that is fixed in a Rust component but
referenced by a C component or somehow intertwined. The fix to the CVE
becomes unavailable and git gets thrown off the platform. That is the
reality
of how insidious CVEs are when it meets corporate policy. I am primarily
trying
to protect from that.

If git was a toy or an experiment, this would not be an issue. But git is
core
Infrastructure for managing and deploying customer facing functionality now,
more than any other single piece of code on any platform. It my hope that
the
git team will finally and eventually understand this, and act accordingly.

If the component in Rust is a toy or non-core, like Git LFS in GO, it can
sometimes
be worked around. Git LFS was something we wanted to port, but it turns out
to
be irrelevant as restrictions in Cloud GitHub and BitBucket make it pretty
much
worthless looking into the future.

>> I have tens of thousands of people in my community who depend on git
>> on a daily basis, and simply kicking them off because of a decision,
>> or lack of decision, that some unrelated dependency controls should be
>> (unfortunately does not appear to be for git) a showstopper.
>
>I'd like to understand this a little better.

Telling 10-20000 users that their core bit of infrastructure is insecure and
not fixable
is not a tenable position. However, it is hard to defend the community when
the git
team is hell-bent on this particular decision. What do you need to
understand here?
It is a small community with a large number of users in key financial
institutions that
have a very conservative adoption policy and an even more conservative
hardware
vendors.

>First, from the original notes:
>>> Emily: old versions aren't going away.
>which I mention only to supply the obvious counterpoint. I believe you've
said in
>the past (sorry that I can't find the specific link) that you'd like to see
Git continue to
>receive improvements and enhancements that you can forward onto your
>customers. This is great! I understand this perfectly. I have the very same
desire for
>my users (which number in the 3-4k range). I look forward to every
performance
>improvement and revamped workflow with bated breath -- wondering how/when
>it can be incorporated into our system to give our folks the best
experience they can
>possibly have as direct users of Git in a heavily automated system.

What I should have said was that I have no problem with git adding new
portable
dependencies. Rust is fundamentally unportable given the policy restrictions
Imposed by that team.

>
>It stands to reason that your users wouldn't see such improvements if
incompatible
>technologies like Rust are adopted into the codebase and those features
were
>written using this incompatible technology. This is understandably a
frustrating
>prospect! Previously, you would have been able to get even more value out
of all
>the open-source effort (and your own effort as a maintainer keeping it
compatible) -
>- and now it's not really feasible. I do understand this sentiment.
(Regardless of how
>much I understand it, if this is not _your_ sentiment, please let me know!)
>
>Here's where I'm struggling a bit. From what I see, I understand two
contradictory
>points:
>
>1. To continue building Git on every platform where it builds today, the
>   project must either
>
>   a) not add any new incompatible dependencies or
>   b) put any such dependencies behind a feature flag (e.g. NO_CURL) so
>      that Git may continue to be built without that dependency.
>
>   Great, no harm -- no foul. But...
>
>2. If you continue building without that dependency, you don't get that
>   feature, so the original purpose of enhancing Git -- to pass that
>   benefit on to users -- is lost.
>
>So it would seem that this leaves us with only option (a) to not add any
new
>incompatible dependencies -- which is what I understand you've been
proposing.
>Certainly reasonable. But then how do you build cool new stuff? Well, build
it
>yourself, I guess.
>
>There's been a _lot_ of cool new stuff lately. This is great! But this does
seem to be
>spearheaded by the work (and thus funding) of companies like GitLab,
Microsoft,
>and Google (and these are just the ones I recognize either by contributor
name or
>by email domain). I'm incredibly thankful for the work and expertise these
folks add
>to the project on an ongoing basis.
>
>I worry though that the 'cool new stuff' seems to require such investment.
It is
>_hard_ to write correct, safe C. I worry that this difficulty will
eventually translate to
>significant, safe contributions coming only from those with the resources
to create
>them and not from a more diverse pool of contributors. As grateful as I am
to large
>companies who fund Git contributions, I don't think those companies, given
the
>choice in and of themselves, would think twice about dropping support for a
>platform they don't use -- and that is probably a much smaller set than
'does the
>platform have GCC'. I don't think this is a danger today or tomorrow, but
it _is_ a
>danger of not having a diverse group of contributors -- and that is the
danger posed
>by not allowing yourself to use any of the 'cool new stuff' _other_ people
have
>written.
>
>--
>
>I don't have a satisfying response to what to do for NonStop in a world
where Rust
>enters the Git codebase. I really don't, and that frustrates me for you. I
hope that
>there's a solution out there (maybe from your vendors, maybe from the
storied
>halls of GCC maintainers, who knows), but I'll echo (more earnestly this
time):
>>> Emily: old versions aren't going away.

Again, it is not the gcc dependency. We have been coping with c99 and will
have c11
shortly. It is Rust itself that is exclusionary. It might be easier to write
new
functionality in Rust - it is easier in Java, Perl, and Python too. Why
Rust? Because
someone wants it, not because you cannot implement the functionality.

I do not see giving up on git is an option, but if that is what ultimately
happens,
I think it will be embarrassing and expensive in the extreme for large
numbers
of users. Considering that 90% of all financial transactions quietly and
without
fanfare touch NonStop hardware at some point, the impact should be obvious
but not initially apparent.

>Nobody has the power to 'kick users off' a project such as Git -- not even
if
>everyone somehow miraculously agreed to port the entire thing to something
hot
>off the presses at /r/programminglanguages :-) Ultimately, your systems
will
>continue to function regardless of what happens upstream. Of course I can't
speak
>to support contracts, but I assume neither can anyone on this list.
>
>That said, I also don't know how a project can continue to thrive without
the
>(occasional, thoughtful, and deliberate) introduction of new technologies,
new
>contributors excited and emboldened by those technologies, and new ideas
from
>those contributors.
>
>Change is essential to growth. Like I mentioned at the outset, I'll let the
true experts
>on this list speak to whether _this_ change is essential for growth, but I
hope I've at
>least made some points that were worth reading.
>
>[1]:
>https://lore.kernel.org/git/007c01da4420$10a7b700$31f72500$@nexbridge.co
>m/
>[2]: https://doc.rust-lang.org/rustc/target-tier-policy.html
>
>--
>Sean Allred

Re: [TOPIC 01/11] Rust

[Phillip Wood]

Hi Randall

On 23/09/2024 13:17, rsbecker@nexbridge.com wrote:
> On September 22, 2024 10:26 PM, Sean Allred wrote:
> 
> The GCC dependency, which does not currently exist in git, is independent of
> Rust. > Rust has its own rules and runtime. The issue here is that the Rust team
> gets to
> decide what platforms can participate, NOT the platform maintainers. No
> matter
> what my intent, or resources, I cannot get the Rust team to "Allow" a port.
> In
> many ways, this is egregious and is a policy issue entirely on Rust, not us.
> We
> want to do a Rust port but are simply not allowed/approved. It is their
> policy.

I'm hearing that there is a fundamental incompatibility between some 
aspect of the NonStop platform and rust's requirements for supported 
platforms. Does that mean it is likely that rust will never be available 
on NonStop?

> I agree that it is not a good policy to never add new dependencies. However,
> Dependencies must be reasonable and give the platforms a chance, at least,
> to adapt. We cannot in the case of Rust. The problem is not actually that we
> can
> do without new features that are in Rust but not C. The problem is when
> there
> are CVEs. Suppose a severe CVE happens that is fixed in a Rust component but
> referenced by a C component or somehow intertwined. The fix to the CVE
> becomes unavailable and git gets thrown off the platform. That is the
> reality
> of how insidious CVEs are when it meets corporate policy. I am primarily
> trying
> to protect from that.

In that scenario there is nothing preventing a different fix being 
implemented for an older version of git running on a platform that does 
not support rust. It's likely that such a fix would need to come from 
the community using that platform rather than upstream which would 
represent an additional cost for users that have previously been relying 
on the upstream to provide security updates.

> Telling 10-20000 users that their core bit of infrastructure is insecure and
> not fixable
> is not a tenable position. However, it is hard to defend the community when
> the git
> team is hell-bent on this particular decision. What do you need to
> understand here?
> It is a small community with a large number of users in key financial
> institutions that
> have a very conservative adoption policy and an even more conservative
> hardware
> vendors.

I'm struggling to understand why such a conservative community needs 
access to the latest version of git. I'd have thought that key financial 
institutions should be able to fund someone to backport security updates 
to their critical systems.

> Again, it is not the gcc dependency. We have been coping with c99 and will
> have c11
> shortly. It is Rust itself that is exclusionary. It might be easier to write
> new
> functionality in Rust - it is easier in Java, Perl, and Python too. Why
> Rust? Because
> someone wants it, not because you cannot implement the functionality.

It may be true in theory that anything one can write in rust could be 
written in C instead but in I'm not sure it is true in practice. In 
previous discussions multi-threading has been mentioned as an example of 
something that is sufficiently difficult to get right in C that 
contributors are not willing to implement whereas they would be happy to 
do so in rust.

I believe that those advocating for using rust are doing so because they 
believe it will benefit both contributors and users. The problem we have 
to wrestle with is whether those benefits outweigh the cost to the 
relatively small proportion of users who do not have access to rust on 
their platform.

Best Wishes

Phillip

RE: [TOPIC 01/11] Rust

[rsbecker]

On September 24, 2024 11:30 AM, Phillip Wood wrote:
>On 23/09/2024 13:17, rsbecker@nexbridge.com wrote:
>> On September 22, 2024 10:26 PM, Sean Allred wrote:
>>
>> The GCC dependency, which does not currently exist in git, is
>> independent of Rust. > Rust has its own rules and runtime. The issue
>> here is that the Rust team gets to decide what platforms can
>> participate, NOT the platform maintainers. No matter what my intent,
>> or resources, I cannot get the Rust team to "Allow" a port.
>> In
>> many ways, this is egregious and is a policy issue entirely on Rust, not us.
>> We
>> want to do a Rust port but are simply not allowed/approved. It is
>> their policy.
>
>I'm hearing that there is a fundamental incompatibility between some aspect of the
>NonStop platform and rust's requirements for supported platforms. Does that
>mean it is likely that rust will never be available on NonStop?

I do not know whether Rust will never be available. The policy is that the Rust
maintainers must sanction and approve any ports. I have tried to get approval
and have not been able to do so. It is not for a lack of trying. To me, this is a
serious problem because there is no "community" concept for Rust. It is either
sanctioned or denied, regardless of the desire of someone to port the code.

>> I agree that it is not a good policy to never add new dependencies.
>> However, Dependencies must be reasonable and give the platforms a
>> chance, at least, to adapt. We cannot in the case of Rust. The problem
>> is not actually that we can do without new features that are in Rust
>> but not C. The problem is when there are CVEs. Suppose a severe CVE
>> happens that is fixed in a Rust component but referenced by a C
>> component or somehow intertwined. The fix to the CVE becomes
>> unavailable and git gets thrown off the platform. That is the reality
>> of how insidious CVEs are when it meets corporate policy. I am
>> primarily trying to protect from that.
>
>In that scenario there is nothing preventing a different fix being implemented for an
>older version of git running on a platform that does not support rust. It's likely that
>such a fix would need to come from the community using that platform rather than
>upstream which would represent an additional cost for users that have previously
>been relying on the upstream to provide security updates.

This means that the community is responsible separate for CVE security fixes.
I have a major problem with that. It means that there will be separate NIST
and Mitre reports for security issues for the same case. The code will then
forever deviate and git will no longer be one product. It also means that
customers can no longer consider the official git to be available on NonStop
but will have to come from an unsanctioned community edition that will
lag behind all security fixes associated with Rust code.

>
>> Telling 10-20000 users that their core bit of infrastructure is
>> insecure and not fixable is not a tenable position. However, it is
>> hard to defend the community when the git team is hell-bent on this
>> particular decision. What do you need to understand here?
>> It is a small community with a large number of users in key financial
>> institutions that have a very conservative adoption policy and an even
>> more conservative hardware vendors.
>
>I'm struggling to understand why such a conservative community needs access to
>the latest version of git. I'd have thought that key financial institutions should be
>able to fund someone to backport security updates to their critical systems.

The community does not need access to the latest version. It *does* need
access to security fixes made in response to CVE reports. As above, being
able to backport security fixes means that git is no longer officially the
same, nor can be verified as legitimate once this is done.

>
>> Again, it is not the gcc dependency. We have been coping with c99 and
>> will have c11 shortly. It is Rust itself that is exclusionary. It
>> might be easier to write new functionality in Rust - it is easier in
>> Java, Perl, and Python too. Why Rust? Because someone wants it, not
>> because you cannot implement the functionality.
>
>It may be true in theory that anything one can write in rust could be written in C
>instead but in I'm not sure it is true in practice. In previous discussions multi-
>threading has been mentioned as an example of something that is sufficiently
>difficult to get right in C that contributors are not willing to implement whereas they
>would be happy to do so in rust.

My position, as a professional product manager, is that such changes should not
be approved.

>
>I believe that those advocating for using rust are doing so because they believe it will
>benefit both contributors and users. The problem we have to wrestle with is
>whether those benefits outweigh the cost to the relatively small proportion of users
>who do not have access to rust on their platform.

I would be very happy to have Rust on the platform. I do not control the situation
even if I have the skill to do the port. This is entirely unfair, in my opinion, to the
community maintainers, (me for one) who are going to end up doing far more
work for free than anyone else.

I am sorry to disagree, but I cannot see any way around the problem that makes
sense. I have been the NonStop maintainer since 2016, and feel like I am being
now being thrown under a bus outside of any of my control. If there is a way to
solve this, without this becoming my full time (for free) job, I would consider it.
(Note that the git license (GPL) requires me to contribute my changes, so it is
being done for free even if I find a way to charge for it.) Honestly, is that
reasonable?

Re: [TOPIC 01/11] Rust

[Sean Allred]

<rsbecker@nexbridge.com> writes:
> I do not know whether Rust will never be available. The policy is that the Rust
> maintainers must sanction and approve any ports. I have tried to get approval
> and have not been able to do so. It is not for a lack of trying.

I do not see a proposal for "NonStop" in a pull request filed against
rust-lang/rust[2] per the process laid out by [1]; can you point me to
where you submitted this request?

[1]: https://doc.rust-lang.org/rustc/target-tier-policy.html
[2]: https://github.com/rust-lang/rust/pulls?q=is%3Apr+nonstop

-- 
Sean Allred

RE: [TOPIC 01/11] Rust

[rsbecker]

On September 27, 2024 5:38 AM, Sean Allred wrote:
><rsbecker@nexbridge.com> writes:
>> I do not know whether Rust will never be available. The policy is that
>> the Rust maintainers must sanction and approve any ports. I have tried
>> to get approval and have not been able to do so. It is not for a lack of
trying.
>
>I do not see a proposal for "NonStop" in a pull request filed against rust-
>lang/rust[2] per the process laid out by [1]; can you point me to where you
>submitted this request?
>
>[1]: https://doc.rust-lang.org/rustc/target-tier-policy.html
>[2]: https://github.com/rust-lang/rust/pulls?q=is%3Apr+nonstop

I will investigate where this went.

RE: [TOPIC 01/11] Rust

[rsbecker]

On September 27, 2024 8:24 AM, I wrote:
>On September 27, 2024 5:38 AM, Sean Allred wrote:
>><rsbecker@nexbridge.com> writes:
>>> I do not know whether Rust will never be available. The policy is
>>> that the Rust maintainers must sanction and approve any ports. I have
>>> tried to get approval and have not been able to do so. It is not for
>>> a lack of
>trying.
>>
>>I do not see a proposal for "NonStop" in a pull request filed against
>>rust- lang/rust[2] per the process laid out by [1]; can you point me to
>>where you submitted this request?
>>
>>[1]: https://doc.rust-lang.org/rustc/target-tier-policy.html
>>[2]: https://github.com/rust-lang/rust/pulls?q=is%3Apr+nonstop
>
>I will investigate where this went.

I have taken this up with the platform vendor. Any request of this sort
needs to come from them, in my opinion, even if I do the port.

I will advise the list if I get anywhere.

[TOPIC 02/11] Top-level lib/ directory

[Taylor Blau]

Top-level lib/ directory
========================

(moderator: Patrick, notetaker: brian)

* Patrick: Difficult to find stuff (README, etc); top-level directory is
  cluttered
* J6t: Clarifies that this is the C and H files
* Emily: Originally the plan was to move libified files into lib once
  libified
* Jonathan:
   * Discussion has been present on the list before (in Git 2.0
     discussion)
   * Bikehedding on the list (more difficult to blame)
   * Differences of opinion about lib and include and naming
   * Blame problems, but this is an opportunity to fix that
   * Heart of it: has nonzero costs, needs to have enough benefit to
     offset it
* Elijah: git apply doesn't handle directory rename
* Patrick: Bikeshedding not a problem; can be handled
* brian: Not really hearing an objection
* Peff: Not a problem for him, but not a really big objection
* Kyle: Not sure the value here
* Jonathan: I really love what Patrick said about "I can handle
  bikeshedding", I think it's great if you can guide a discussion
  on-list toward a decision on what we want for source layout, how we
  structure code, etc. Exciting!
* Taylor: improves things, makes it more maintainable/discoverable, but
  takes time away from other things like security/performance bugs.
  Should be done with a healthy balance.

[TOPIC 03/11] Structured Error Handling

[Taylor Blau]

Structured Error Handling
=========================

(moderator: brian, notetaker: jrnieder)

* brian: idea for structured error handling!
   * Very little needed - pointer to error string, uint64_t error code,
     and ??  (third thing I didn't hear). Return it on the stack. Rust
     does this kind of thing all the time.
   * Having that structured return value lets a caller decide what to do
     with it
     - print a message, decide whether to exit or recover, etc.
* Patrick: a few requirements
   * want to attach arbitrary metadata to an error (e.g. "I had a
     conflict between that file and that file for this revision").
     Especially useful on the server side.
   * avoid having to parse error messages. Gitaly runs into this. Can
     imagine setting an envvar to get json or some other parsable format
     instead of human-consumable error messages.
* brian: sounds doable. GitHub also has the same hassle with parsing
  error messages.
* Peff: in your proposal, low-level code produces the error struct which
  is consumed at a higher level. Sometimes, though, you have many errors
  that are related.
   * "I couldn't merge these files because I couldn't open this file,
     because of this errno".
* One thing we've considered is having a callback to decide what to do
   * - print the error, collect into a tree of errors, etc.
   * The point is to keep what's happening in the generators of errors
     as simple as possible - I have this type of error and maybe some
     kind of context strings. That context could be owned by the caller,
     the callee can be responsible for copying it, etc. Inversion of
     control.
* Patrick: I like the way Go does things, can wrap errors or append
  messages, return up the stack until someone handles the error. Why are
  we afraid of allocations?
   * Peff: What do you do when the allocation fails?
   * Patrick: can handle allocation failure by having a special error
     that has a statically allocated string.
   * Peff: sounds good, getting rid of die() on alloc failure is okay
   * brian: Rust panics on out-of-memory anyway
   * Peff: there are two different cases - small allocations are "you're
     in trouble anyway", big allocation of user-supplied length is
     something else
   * Carlos: Rust has a "try to allocate memory", relatively new
* Calvin: how do you propagate up the call stack?
   * Peff: in my proposal, every function would take an error context
     struct, call the callback when there's an error, and keep the
     integer function returns. In brian's proposal, we instead return
     the struct.
   * Emily: Are we comfortable with the amount of churn that generates
     in the codebase?
   * Patrick: my inspiration is Subversion in that respect. It has nice
     error handling in C, they're a role model for me in how to do a
     library. It has nice error types that aren't a hassle to use.
   * J6t: if you compile in C++ and use exceptions, the problem has been
     solved 25 years ago.
   * brian: allocating strings for errors and then freeing them is a
     hassle in C. Versus Rust where that's handled automatically.
   * Emily: so it sounds like this is temporary pain
* Jonathan: I like Patrick's description of requirements. One thing that
  would make me more comfortable with the churn is when we get benefit
  even from partial conversion
   * E.g. could say we get structured error messages for the call sites
     that have been converted and not from others. And when I go on a
     debugging quest and wish I had a machine-readable structured error
     message, I can send a patch to convert more call sites
   * Peff: Refs code uses its own strbuf based error handling which is
     worse in every way than the options we've been discussing. :) That
     can be a good playground to try things out.
   * Patrick: +1, seems like a good place to start.

[TOPIC 04/11] Platform Support Policy

[Taylor Blau]

Platform Support Policy
=======================

(moderator: Emily; notetaker: Calvin)

* Emily: if you want Git to support your platform, you have to provide
  your tests (e.g. provide your own CI test runner)
   * Should we be more explicit about, for example, the version of C
     that one must support.
* Brian: less-common architectures (e.g. MIPS) sometimes can catch
  problems (e.g. unaligned access) that are not a good practice anyway
   * qemu based CI is so slow
   * netbsd, openbsd, freebsd, probably solaris are up to date with
     modern standards, probably supportable
   * I'm more comfortable with "you have to have threading and POSIX
     2008" than with "you have to provide a CI runner"
* Peff: I'm not sure what people have been counting on
   * Do we have a way to find out what people are using?
   * "Take a little risk, see who screams" has worked okay in the past
     but takes a while
   * Rust is probably a big change
* Patrick: keep in mind that we're at the core of the whole operating
  system, part of the bootstrapping path
   * Emily: yes and no - Git is not just the client, but Git is a
     standard. You can use older versions of Git and clone things from
     GitHub. If we still support the same protocols, I don't think
     needing native git.git CLI support to run on your platform is as
     compelling as new Git being able to support these older standards.
   * brian: OpenBSD doesn't like the GPL, has a project for getting
     trees called "got", it's in C and supportable. It can be a valid
     bootstrapping tool.
   * Patrick: The user experience there is a little closer to CVS. But
     it's still an option.
* Jrnieder: looking from user perspective, Git is the tool people are
  used to for day to day development
   * Emily: There's a difference between using "a git" vs using the
     latest version.
   * Jnieder: telling users to use an older version might result in
     users asking questions on the mailing list about those older
     versions, it's also not free.
   * Peff: to be fair, HP Nonstop support hasn't been a matter of
     "please support me for free" - the maintainer there has been active
     in helping test and debug things. The question here is not about
     whether to continue that but rather about whether we're willing to
     increase the platform dependencies when it breaks such a use case.
   * Peff: Are we okay with dropping NO_PTHREADS support?
   * Brian: POSIX 2008 shouldn't be that controversial. Neither C11
     should be.  We shouldn't take it too far like POSIX 2024, but we
     have to set "some" standards.
   * Emily: So next week when we come home we update the "minimum
     requirements" on the mailing list, and everybody upvotes?
   * Jonathan: we live in the real world - the spirit of "let's require
     POSIX 2008" sounds right, but real-world considerations should
     matter more than the exact text of the standard
   * Peff: example: Android is missing pthread_setcanceltype, which
     leads to Git on Android using NO_PTHREADS
   * brian: it can be enough to pretend to support (compatibility shim)
* Calvin: is there a threshold % of users for "unimportant enough to
  break"?
* Jrnieder: it depends on the platform. Do the requirements that a given
  platform imposes push us in a good direction in general as a project?
   * For example, Windows is a very non-POSIXy platform, but it has
     nudged us toward thinking about subprocesses in a different way,
     and I think that's been really healthy
   * brian: As another example, Plan 9 is really difficult to support,
     it won't pass the test suite
   * z/OS patches originally came in and were gross. I saw a patch come
     in recently that was more acceptable.

[TOPIC 05/11]: SHA 256 / Git 3.0

[Taylor Blau]

SHA-256 / Git 3.0
=================

(moderator: Patrick, notetaker: Taylor)

* Patrick: some of you may have seen some patches from a few months ago
  to start thinking about this, and we now have a "deprecations" doc of
  things that we plan to get rid of.
   * One thing going away is grafts
   * Another thing is git pack-redundant
* Patrick: SHA-256 will become the default object hash, but is
  contingent on major platforms supporting SHA-256.
* Emily: this helps us too, because it provides some motivation that
  this is going to happen.
* Patrick: having it in the 3.0 document makes it easier to push at
  large organizations.
* Jonathan: with partial clones if I understand correctly users were
  already trying it and complained to GitHub about it not being turned
  on.
   * Taylor: not really…
   * Peff: I was embarrassed, so I wrote the bitmap support for
     filtering objects
   * Taylor: yeah, and turning it on was easier, but didn't require
     updating database columns, etc. so the transition period here would
     be much more expensive.
   * brian: "can you put it in the customer feedback repo" is something
     customers can ask for
* Jonathan: could use interop as a way for Git to default to sha256 with
  the only harm to end users being that clones and fetches get slower
  until servers support it
* brian: not planning on working on it unless their employer pays for
  them to do it.
* Mark: customers wanting to start with SHA256 so they don't have to
  migrate later
* Patrick: GitLab never really wanted SHA-256 until it was done on the
  Gitaly side.
* brian: has definitely seen it on StackOverflow as something that
  customers want. Not a huge selling point right now, but will become a
  humongous selling point at some point (beyond >2030).
* Peff: if the proposal is to make SHA-256 the default, then we need to
  be developing with it now, and we're not because there is no interop.
* Taylor: we should do it via interop, (a) because GitHub could not host
  it, but (b) because we would introduce the same lack of testing just
  with the interop code, not the SHA-256 code. So it must be done via
  interop.
* Patrick: OK, but why do we care about SHA-256 locally if they're using
  SHA-1 on the remote? The remote could be compromised
* Jonathan: You can verify things locally. This is the core idea of
  distributed version control.
* Patrick: Oh, I see.
* brian: Signatures work with both hash functions, you can sign with
  both.
* Peff: It does not feel right to me to set the user default until we
  the project are using it, and that the interop code is a part of that
  story.  (back to Git 3.0, we combined the SHA-256 and Git 3.0
  discussions into one)
* Peff: I have a proposal for Git 3.0, maybe this has been discussed?
  Can we get rid of some of the older protocols (dumb HTTP)?
* Patrick: Lots of esoteric things, like show-branch, which apparently
  nobody uses.
* Elijah: not just removals, but changing defaults, etc.
* Emily: are we interested in non-backwards compatible changes, like
  adding multi-Author fields to commits?
* Peff: I think that's a bad example, it can be done without breaking
  compatibility, but it was decided to not to do it. You're welcome to
  resurrect the discussion.
* Patrick: … but it's a different question of whether or not that would
  end up in the document.
* brian: multi-signatures
* Jonathan: Two questions I'm hearing:
   * Should we include things that haven't been implemented yet?
     Probably not.
   * What do we think about this major version as a way to break
     interoperability with older versions of Git?
* Patrick: I would not be in favor of breaking something, at least in
  cases where we can add a protocol extension and/or new capabilities.
  Intentionally breaking interoperability with an older version does not
  seem like the right way to go.
* brian: I agree, but for the dumb HTTP protocol, C git uses it, Eric
  Wong is really into it (lore.kernel.org supports it), etc.
* Emily: Bundle URIs and resumable clones, could in theoretically work
  for resumable clones, but we don't have client-side support.
* Peff: Pretty sure that this isn't the case.
* Mark: can I ask a "dumb" question? What would it take to get a
  schedule for 3.0?
   * Patrick: Junio says not too often, maybe only breaking releases
     every 5-10 years, which means 3.0 would come in 1-2 years.
   * Peff: 1-2 years is what is in my mind.
   * Taylor: I think that whatever answer we come to agreement here will
     not be satisfying for you.
   * Taylor: the items on that document aren't a checkbox list of things
     to do before Git 3.0, but isn't a "let's get all of these things
     done and then we'll release Git 3.0".
      * More that we'll all wake up one day, realize that we've done all
        or enough of what would go into Git 3.0, then remove a bunch of
        code, and ship it.
* Jonathan: collecting breaking changes and aggregating them so users
  can prepare for them together is helpful, but it's not the only way
  that breaking changes will happen, especially if there is something
  that needs to go away.
* Patrick: I want three things from this document:
   * Reminder / documented intent.
   * User feedback to hear things like "this is important to me, what is
     (if any) the replacement?"
   * ???
* brian: changing the default branch name?
   * Taylor: I would be in favor of doing it sooner
   * (some discussion)
   * Taylor: We should consider doing it for git.git as well.
* Peff: we might write a bunch of those patches, move them into 'next'.
  Could we have a Git 3.0 pseudo-maintainer.
* Jonathan: I have a naive question: why wouldn't it look like turning
  on a single Makefile variable?
* Emily: and then we go and delete the code inside of the #ifdefs
* Taylor: whoever is the maintainer at that point in time could consider
  a double-wide release cycle, where we delete that code, implement new
  things, and then at the end of that cycle the artifact is called Git
  3.0.
* Peff: very few people run "next"
   * Jonathan: True. Could imagine some % of GitHub Actions runners
     automatically running "next", that's the kind of thing that gets a
     more representative workload.
* Toon: do we want to have maintenance releases?
* Emily: if we're dropping support for earlier versions, we should just
  do it.
* Taylor: we should probably have a few supported release tracks that we
  designate as LTS releases.
* Patrick: For security issues only, probably for a period of 1-2 years.
* Peff: Should we write this up as a plan for the person who actually
  does release engineering?
   * Taylor: I can write up that plan, and be the point person for the
     LTS releases.
   * Jonathan: the Linux kernel has dedicated maintainers for LTS
     releases, which seems to work well.
* brian: we can certainly tell that to Junio, but it's also ultimately
  their decision.

Re: [TOPIC 05/11]: SHA 256 / Git 3.0

[Junio C Hamano]

Taylor Blau <me@ttaylorr.com> writes:

> * Peff: I have a proposal for Git 3.0, maybe this has been discussed?
>   Can we get rid of some of the older protocols (dumb HTTP)?

Please discuss these on list.  Removal of http walker (both for
fetching and pushing) you have my blessing ;-)

> * Patrick: Lots of esoteric things, like show-branch, which apparently
>   nobody uses.

You remove show-branch and you will stop seeing "What's cooking"
("git show-branch master $branch1 $branch2 ..."  is used as a way to
find the commits on each topic branch in flight, instead of running
"git log master..$branch" N times).

> * Elijah: not just removals, but changing defaults, etc.

Yes.

> * Emily: are we interested in non-backwards compatible changes, like
>   adding multi-Author fields to commits?
> * Peff: I think that's a bad example, it can be done without breaking
>   compatibility, but it was decided to not to do it. You're welcome to
>   resurrect the discussion.

Good.

>    * Taylor: the items on that document aren't a checkbox list of things
>      to do before Git 3.0, but isn't a "let's get all of these things
>      done and then we'll release Git 3.0".

Yes.

>       * More that we'll all wake up one day, realize that we've done all
>         or enough of what would go into Git 3.0, then remove a bunch of
>         code, and ship it.

Not exactly (see my recent comment on feature.git3 on the list---we
need a good transition plan and early adopter opt-in mechanism).

[TOPIC 06/11] Git and Software Freedom Conservancy

[Taylor Blau]

Git and Software Freedom Conservancy
====================================

(moderator: Taylor; notetaker: Patrick)

* Taylor: Sent out new mail to the list with SFC activities.
   * https://lore.kernel.org/git/Zusxcweod1O88h7j@nand.local/T/#t
      * LOTS_OF_MONEY spam alert
   * Generally have more money in our account than we know what to do
     with.
   * SFC consists of 4 persons: Junio, Taylor, Ævar, Christian
* Taylor: Trademark discussion
   * Enforcing the trademark is untenable because there are so many
     projects out there using "Git". We cannot go after those to defend
     our trademark, and would also not be in the spirit of the Git
     project.
* Taylor: Money
   * We've got a large amount of money for an OSS project with few
     expenses, $90k USD.
   * Heroku is our biggest expense at $60 USD/mo.
   * What can we do with this money?
* Chris: Mentor Outreachy this year, we'll likely have to sponsor them.
   * $8,000 USD/student. GitHub can probably cover one or two such
     students.
   * GitLab sponsored last year, but getting funding was taking a very
     long time on their side. John probably doesn't want to repeat the
     process again due to the hassle.
* Jonathan: Git gets money due to GSoC, too. These kinds of mentoring
  projects are things where it's easy for donors to justify giving.
* Chris: We do get money indeed due to the GSoC mentoring.
* Chris: We have tried to sponsor travels for GSoC students in the past
  to come to Git Merge. Was quite easy to do that with our funds. Covid
  restricted that somewhat.
   * Students used to have problems acquiring a visa, creating a catch
     22 because we had to book the flight up front, but it wasn't yet
     clear whether they'd get the visa. BUt without the flight, they
     wouldn't get the visa, either.
* Peff: THe wasted money on that is probably small enough compared to
  how much funds we have, so the risk is comparatively small.
* Jonathan: Do we have a rough estimate around how big yearly influx
  minus expenses is?
* Taylor: The exact year is $93k USD. It's hard to tell exactly due to
  changes in reporting by SFC. Last year it was roughly $89k USD, so
  only up ~$4k.  Typically we have a yearly income of around $10k-$20k
  USD/yr.
* Peff: if you want something, would be relatively easy to run a
  fundraising campaign for Git
* brian: I'm sure that we can easily raise additional money via
  individual contributors, too.
* Jonathan: If we have the money for it, I think it might be relatively
  easy to justify hiring a full-time community manager for the Git
  project, for example.
* Peff: 90k is a high amount of money to do small things, but it's not
  really enough to actually sponsor full positions for an extended
  period of time.
* brian: True. Nobody is going to work for you without insurance, so it
  indeed isn't all that much money indeed.
* Jonathan: Edward Thomson also mentioned that libgit2 passed on some
  money to other projects that can use it better
* Emily: also wanting to spend money on contracting on particular
  projects
* Brian: there are people who do contractor work like this. I just don't
  know whether we can find somebody who is willing to accept taht little
  money.
* Emily: Developers are expensive, tech writers are a lot cheaper. Would
  that be a viable option? They could for example rewrite lots of our
  documentation.
* Johannes: We could delete obsolete documentation!
* Patrick: I tried to do this on the GitLab side, but it never really
  worked out. They didn't want to join the Git mailing list.
* Emily: Same.
* Mark: There would be some concern about having tech writers interact
  with the mailing list flow.
* Peff: Ævar is not active on the PLC anymore for a long time. Should he
  be removed?
* Taylor: We've been talking about that in the PLC. There are two
  options:
   * EIther remove him without replacement, such that we have three
     people on it. That would also make it less awkward when it comes to
     voting ties.
   * If we replace him, it would almost happen to have to come from
     someone who isn't affiliated with a large forge / company. We
     already have representation from GitHub, Git Lab, and Google, so
     would want an OSS contributor not affiliated with a major company.
   * Ideally I would like him to come back, but haven't been able to
     hear from him whether or not he is interested in doing so.
* Michael: The trademark was originally owned by GitHub?
* Peff: The git-scm.com web site was originally owned by Scott, was then
  moved over to SFC. The SFC applied for the Git trademark, came to an
  agreement with GitHub about details of how it would relate to the
  GitHub trademark.
* Michael: Is there any obligation of Conservancy to GitHub that the
  trademark is enforced?
* Peff: No.
* Michael: Background is that the proposal was to stop enforcing it. SO
  the question is whether we have to due to an agreement.
* Johannes: You lose the trademark if you don't enforce it in many
  different countries, so we either have to or don't and may thus lose
  it.
* Chris: We mostly enforce it by privately emailing e.g. website owners
  that use Git in a way we don't agree with. So we do enforce it as
  necessary, even if it only happens very infrequently. Some companies
  do not register a trademark that's conflicting, but they still try to
    use it.
* Jonathan: I think it would not be a good choice to not be assertive
  about the trademark at all. On the other hand, filing lawsuits against
  low-harm cases doesn't seem like a great use of time and money. So I
  feel like the current balance is sensible.
* Peff: SFC's lawyers might disagree with that assessment.
* Taylor: They want to see some new version of the trademark where we
  e.g. only enforce our trademark on the logo.
* Chris: We raised the question a couple years ago of what to do about
  the trademark, and folks basically agreed with the current way of how
  we handle it.
* Brian: Debian has a trademark policy that might be sensible to have a
  look at for inspiration. It e.g. says that you have to communicate
  truthfully.
* Peff: We have similar stuff like that in our policy. The problem is
  that back when writing it we had another company that was trying to
  use the trademark for a "shitty" reimplementation of GIt, and we
  didn't want that. We don't really care for "git-foo". Dashed commands
  are explicitly allowed. GitOxide is e.g. technically against the
  trademark policy due to being CamelCased, but we are fine with it.
* Taylor: We cannot do that, we have to consistently enforce the
  trademark. It needs to be very strictly defined what is and is not
  okay.
* brian: it needs to be definitive whether you're doing the "good" or
  "bad" thing.
* Jonathan: It might be interesting to tie this to compatibility with
  the Git test suite. SO if you pass it you are allowed to use it,
  otherwise not.
* Jonathan: So IIUC, we have questions for the SFC lawyers because we
  canot really answer a lot of the questions?
* Chris/Taylor: We can do that.
   * Taylor: We will talk offline to figure out who does what.

[TOPIC 07/11] New Contributors and Discord

[Taylor Blau]

How to attract new contributors? + Community Discord
=====================================================

(moderator: Jonathan N + Calvin Wan, notetaker: Emily)

* jonathan: we talk about this a lot 🙂 let's avoid the common pitfall
  of catering to the tiktokkers and the youths (hypothesizing about
  "current generation"):
* but, our contributor base isn't representative of our user base
* and our current contributor base doesn't reflect exactly the skills
  needed to improve git - like interface design is not our strong suit.
  how to attract people who are better at our weak spots?
   * taylor: this weakness is an existential problem for Git. jj,
     gitbutler, gitkraken, etc
   * mark: +1
   * peff: one size doesn't fit all, us deciding not to include a GUI is
     understandable, but workflow improvements like jj's are pretty
     interesting
   * jonathan: ex. in hg there's someone very involved in UX review. we
     don't have someone like that
* missing other disciplines - tech writing, product management, UX
  research, etc.
   * common problem in open source but would be cool if we could get
     good at attracting/retaining these people - and cool for the
     not-eng-discipline people
   * patrick: we could adopt a style guide or guideline but we still
     wouldn't be good at enforcement
   * john: people need to know what they can contribute to - cf. project
     tracking discussion later on
* jonathan: instead of trying to guess - can we think generally, how do
  we make work easier to approach? how can we lower the barrier to
  entry?
* patrick: someone is writing third-party rewrite of gitglossary. huge
  improvement over what we have, well made, but the person didn't want
  to come back to contribute. was afraid of the community giving
  pushback
   * patrick was willing to handhold this potential contributor, but it
     didn't seem like enough to make this person comfortable
* jonathan: related to community discord server - what does it mean to
  function better as a community?
* calvin: the entry point doesn't need to be discord, but we should pick
  some entry point that lets users contribute other than mailing list
  participation
   * and need to be able to navigate new contributions comfortably
* brian: how to write text that's accessible to non-native english
  speakers, for example? the mailing list isn't great for these kinds of
  changes.
* discord is proprietary, that is sometimes an issue
* moderation on discord is an issue - having an unmoderated discord will
  actually drive away contributors. that means actual dedicated
  moderation
   * balancing between sufficient moderation (list) and ease of use
     (discord)
* patrick: new contributors sending changes but the changes being
  ignored
* brian: git-send-email is a barrier, but so are PRs/MRs in some cases
* jonathan: the localization example is a good one - the translation
  layer is in github, uses a very typical dev workflow, and that's
  working well. there's a strong community there. are there other places
  we can do something similar?
* peff: can we do that with documentation?
   * jonathan: can we have a documentation maintainer? hypothetically:
     we hire a tech writer, and that tech writer acts as the
     documentation maintainer only. curating existing docs, making sure
     docs changes get good reviews, how to attract new tech writer
     contributors, etc
   * peff: can we manage documentation as a subproject that doesn't use
     the mailing list, and make tech writers' lives easier?
      * how to negotiate that with code changes that require doc changes
        is trickier, we'd have to figure out how to do it, but doable
      * jonathan: readthedocs
* jonathan: we don't advertise well that we can accept contributions in
  a different way if people are committed to the improvement
   * peff: sometimes a mentor can "translate" a contribution. Individual
     contributors are already interested in mentoring, do we need
     more/different mentoring?
   * mentoring list isn't working well yet - maybe it's too faceless?
     should we get a list of individuals who want to mentor?
   * taylor: should we literally put photos of the people on the
     mentoring list up somewhere? "here are real humans, they will reply
     to you on git-mentoring@"?
   * jonathan: in-person meetups help with this. emailing is
     transactional, but e.g. python meetups are interactive
* patrick: we had the git berlin meetup a few months ago, lot of people
  came, we did lightning talks and user conversations. it worked well -
  let's use that model more
   * taylor: hey, we can help spend money on that
   * brian: those are cool but for example, houston linux users group is
     quite small. meetups like this can be helpful, but it's not the
     only source.
   * peff: it doesn't really scale up. python users group are
     user-to-user, doesn't necessarily draw python project contributors.
   * nasamuffin: Gerrit has a community meeting once/month, should we
     use discord for f2f video meetups?
   * peff: if people want to do big group meetups great. we could also
     use it for 1:1 meetups that way, and advertise that it's an option

Re: [TOPIC 07/11] New Contributors and Discord

[Junio C Hamano]

Taylor Blau <me@ttaylorr.com> writes:

> * and our current contributor base doesn't reflect exactly the skills
>   needed to improve git - like interface design is not our strong suit.
>   how to attract people who are better at our weak spots?
>    * taylor: this weakness is an existential problem for Git. jj,
>      gitbutler, gitkraken, etc
>    * mark: +1
>    * peff: one size doesn't fit all, us deciding not to include a GUI is
>      understandable, but workflow improvements like jj's are pretty
>      interesting
>    * jonathan: ex. in hg there's someone very involved in UX review. we
>      don't have someone like that
> * missing other disciplines - tech writing, product management, UX
>   research, etc.
>    * common problem in open source but would be cool if we could get
>      good at attracting/retaining these people - and cool for the
>      not-eng-discipline people
>    * patrick: we could adopt a style guide or guideline but we still
>      wouldn't be good at enforcement
>    * john: people need to know what they can contribute to - cf. project
>      tracking discussion later on

Would money solve these, e.g., by hiring somebody?

The issue would be how to find somebody good ("known to be good with
past track record" would be a bonus) and ensure that the community
trusts the choice they make and the output they produce, in the
areas like UI design or tech writing, that we know are not our
strong points.  Would we be able to give them enough freedom to
produce their best product, yet be able to stop them if needed when
their output turns out not so good as we hoped initially?  Are we
equipped to fairly evaluate their output?

> * jonathan: instead of trying to guess - can we think generally, how do
>   we make work easier to approach? how can we lower the barrier to
>   entry?
> ...
> * moderation on discord is an issue - having an unmoderated discord will
>   actually drive away contributors. that means actual dedicated
>   moderation

It is not "discord" per-se, but lowering the barrier to entry would
mean you'll get more people with different background and different
idea of what is normal to deal with.

> * patrick: new contributors sending changes but the changes being
>   ignored

Paraphrase.  More patches written, not enough are reviewed.

> * jonathan: the localization example is a good one - the translation
>   layer is in github, uses a very typical dev workflow, and that's
>   working well. there's a strong community there. are there other places
>   we can do something similar?
> * peff: can we do that with documentation?
>    * jonathan: can we have a documentation maintainer? hypothetically:
>      we hire a tech writer, and that tech writer acts as the
>      documentation maintainer only. curating existing docs, making sure
>      docs changes get good reviews, how to attract new tech writer
>      contributors, etc
>    * peff: can we manage documentation as a subproject that doesn't use
>      the mailing list, and make tech writers' lives easier?
>       * how to negotiate that with code changes that require doc changes
>         is trickier, we'd have to figure out how to do it, but doable
>       * jonathan: readthedocs

There needs to be a mechanism to ensure the technical correctness of
the result to replace the public reviewing on the mailing list for
the above model to work.

>    * nasamuffin: Gerrit has a community meeting once/month, should we
>      use discord for f2f video meetups?
>    * peff: if people want to do big group meetups great. we could also
>      use it for 1:1 meetups that way, and advertise that it's an option

Sounds like a good way to make it easier to link names with faces.

Re: [TOPIC 07/11] New Contributors and Discord

[Kousik Sanagavarapu]

Taylor Blau <me@ttaylorr.com> writes:

> How to attract new contributors? + Community Discord
> =====================================================
> 
> (moderator: Jonathan N + Calvin Wan, notetaker: Emily)
> 
> * jonathan: we talk about this a lot 🙂 let's avoid the common pitfall
>   of catering to the tiktokkers and the youths (hypothesizing about
>   "current generation"):

I guess I would fall into the "youths" category ;)

I started contributing about a year ago although most of my activity was
during the GSoC'23 period.

> * jonathan: related to community discord server - what does it mean to
>   function better as a community?
> * calvin: the entry point doesn't need to be discord, but we should pick
>   some entry point that lets users contribute other than mailing list
>   participation
>    * and need to be able to navigate new contributions comfortably
> * brian: how to write text that's accessible to non-native english
>   speakers, for example? the mailing list isn't great for these kinds of
>   changes.
> * discord is proprietary, that is sometimes an issue
> * moderation on discord is an issue - having an unmoderated discord will
>   actually drive away contributors. that means actual dedicated
>   moderation
>    * balancing between sufficient moderation (list) and ease of use
>      (discord)

I don't know if we get new contributors complaining about our workflow
being centered on the mailing list but I personally find the list really
intuitive to work with.

Even if we do eventually move towards a more "user-friendly" interface
_for_ new contributors, they may still need to read through history for
certain changes they maybe working on, ON the list.

> * patrick: new contributors sending changes but the changes being
>   ignored

I do remember the time when I first contributed and was anxious about
the reply but I guess even if someone else doesn't review a particular
patch, Junio gets around to it eventually (which is not ideal, we want
more reviewers...) so they are not completely lost... everytime.

Although it would be great if there was some kind of an interface to say
that this patch is a new contribution to anyone going through the
messages similar to what Calvin said above.  So that if the patch were
simple enough then maybe some of the newer contributors may also have a
go at reviewing the patch.

> * brian: git-send-email is a barrier, but so are PRs/MRs in some cases

I think the main barrier is the configuration of git-send-email rather
sending the patches themselves.  Since most people have gmail accounts,
the setup becomes a pain because of the two-factor-auth and creating app
passwords and for someone who is mailing a minor change, this indeed
feels like a lot of effort not worth the time or energy.

> * jonathan: we don't advertise well that we can accept contributions in
>   a different way if people are committed to the improvement
>    * peff: sometimes a mentor can "translate" a contribution. Individual
>      contributors are already interested in mentoring, do we need
>      more/different mentoring?

I think having mentors would be great thing.  Even if it is not 1:1.

Another thing that would be great is having a list of things on which a
new contributor could work on.  GitGitGadget's issues used to do this by
tagging the appropriate issues "good-first-issue" but I guess it is not
properly maintained anymore.

I know there is also searching for "#leftoverbits" or "low hanging fruit"
on the list but the "good-first-issue" tagged issues on GitGitGadget are
probably more new-contributor-friendly than whole email threads.

>    * nasamuffin: Gerrit has a community meeting once/month, should we
>      use discord for f2f video meetups?
>    * peff: if people want to do big group meetups great. we could also
>      use it for 1:1 meetups that way, and advertise that it's an option

I think we hit on this topic last year too in the virtual contributor's
summit and I agree that having a regular meetup would be great and
something I personally would very much look forward to.  This would also
help put faces to names.

Not exactly a regular community meeting but Review Club was kind of a
large step towards this I guess.  I was exactly in one review club
meeting and it sadly got shutdown right after that :').

Re: [TOPIC 07/11] New Contributors and Discord

[Junio C Hamano]

Kousik Sanagavarapu <five231003@gmail.com> writes:

> Another thing that would be great is having a list of things on which a
> new contributor could work on.  GitGitGadget's issues used to do this by
> tagging the appropriate issues "good-first-issue" but I guess it is not
> properly maintained anymore.

True.

> I know there is also searching for "#leftoverbits" or "low hanging fruit"
> on the list but the "good-first-issue" tagged issues on GitGitGadget are
> probably more new-contributor-friendly than whole email threads.

Yes, even with these search terms, finding an issue to work on from
the mailing list archive would not be suited for an absolute newbie
for four reasons.

 * Anybody can write "low hanging fruit" in their message.  Such a
   label added by somebody without understanding the issue would
   lead readers in a wrong direction.  These phrases need to be
   reserved for a case where the person who adds _know_ they can
   solve it themselves fairly easily if they dedicated time on it
   for a few days but deliberately chooses to leave it on the table
   unsolved.

 * "#leftoverbits" is just that---a direction we could explore in
   the future, and the journey that goes in the direction is limited
   to a short and trivial one.

 * Both labels are opinions of the author at the time of writing.
   It may turn out that what was thought of as a "low hanging fruit"
   is not all that easy, and it may turn out that what was labeled
   with "#leftoverbits" would not lead to a productive direction
   after somebody actually tries.

 * And the list archive by its nature will show hits for ideas
   marked with "#leftoverbits" and/or "low hanging fruit" that have
   already been fully explored, and those who completed the task may
   not reference to the original message that inspired them in the
   References: header, so the archive search cannot show that the
   task is completed already.

We could improve the situation for all of the above four downsides
by making it a collective habit to follow-up these messages with
"#leftoverbits" or "low hanging fruit" in it, if the situation
changes, but your "whole email threads" comment still applies.

Unless we make a habit of sending a separate message with such
markings in which we summarize the discussion, that is.

#leftoverbit.  Perhaps one of the how-to documents that describe the
project workflow (i.e. my first contribution, how to review patches,
etc.) can mention the best-current-practice to encourage such use of
these tags?  Something like

 - When you mention a good idea that is not squarely inside the
   theme of the current discussion, instead of adding "#leftoverbit"
   mark in the message, write a separate message as a follow-up to
   the message and summarize the issues and idea in such a way that
   people who later looks for a message with such a mark can grok
   the idea by the message alone, while still allowing them to learn
   more about the backstory by going back in the discussion thread.

 - After you find "#leftoverbit" message and worked on it (either
   you produced a patch series, or you failed and know why the idea
   described in the #leftoverbit message does not work), make sure
   you mention the original "#leftoverbit" message's message-id in
   such a way that a person who found the "#leftoverbit" message can
   find your message.  Sending your patch series as a reply to such
   a message would be the easiest way to achieve it.

or somesuch, perhaps.

> Not exactly a regular community meeting but Review Club was kind of a
> large step towards this I guess.  I was exactly in one review club
> meeting and it sadly got shutdown right after that :').

Anybody motivated enough can take initiative to reignite the Review
Club; you do not need permissions from past hosts to do so.

Quite honestly, I sometimes failed to find much value in the review
these meetings produced, and I suspect it was not due to lack of
preparation on participants' side, but was largely due to the fact
that the face-to-face meetings cannot go to sufficient depth in
technical conversion in a single sitting.

It might have been more productive format if it weren't "let's
critique this series on the fly".  For example, it could instead
have been "There is an excellent reviewer-contributor exchange
thread on the list.  Let's read these exchanges together and learn
how to effectively convey the idea from the original author's side,
and idea for improvements from the reviewer's side".  I dunno.

There however was a lot of value in the mere fact that people had a
face-to-face discussion on something, anything, that was related to
the project.

Thanks.

Re: [TOPIC 07/11] New Contributors and Discord

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

>  * "#leftoverbits" is just that---a direction we could explore in
>    the future, and the journey that goes in the direction is limited
>    to a short and trivial one.

Correction.  "is limited" -> "is not limited".

> Quite honestly, I sometimes failed to find much value in the review
> these meetings produced, and I suspect it was not due to lack of
> preparation on participants' side, but was largely due to the fact
> that the face-to-face meetings cannot go to sufficient depth in
> technical conversion in a single sitting.

Correction.  "conversion" -> "conversation".

> There however was a lot of value in the mere fact that people had a
> face-to-face discussion on something, anything, that was related to
> the project.
>
> Thanks.

Re: [TOPIC 07/11] New Contributors and Discord

[Konstantin Ryabitsev]

On Sun, Sep 22, 2024 at 12:15:22PM GMT, Junio C Hamano wrote:
> > I know there is also searching for "#leftoverbits" or "low hanging fruit"
> > on the list but the "good-first-issue" tagged issues on GitGitGadget are
> > probably more new-contributor-friendly than whole email threads.
> 
> Yes, even with these search terms, finding an issue to work on from
> the mailing list archive would not be suited for an absolute newbie
> for four reasons.

I can chime up and offer bugspray bot integration for the list. This is a new
tool I've been developing for integrating the mailing list with bugzilla. I've
been using it on the tools mailing list over the past year with reasonable
success.

It works something like this:

- a mailing list thread can be turned into a bugzilla entry by saying a
  trigger phrase like "bugspray track" or "bugspray tag <person>". This
  converts the entire existing thread into a bugzilla bug entry and makes the
  bot follow the conversation, adding any new mailing list messages to the
  bug. This is a two-way bridge, so someone can add things like large debug
  dumps or other files to the bug and have a notification about that go to the
  thread participants. Here's an example of a bug created from a thread using
  the "bugbot assign to me" trigger phrase:
  https://bugzilla.kernel.org/show_bug.cgi?id=219230

- the opposite also works: a bug created in bugzilla becomes a mailing list
  thread. Here's an example:
  https://bugzilla.kernel.org/show_bug.cgi?id=218821
  and here's a thread it created:
  https://lore.kernel.org/linux-mmc/20240922-b218821c6-a6dc79e2a03f@bugzilla.kernel.org/T/#t

- git commits are also able to close bugs via the Closes: trailer. E.g. here's
  one example:
  https://bugzilla.kernel.org/show_bug.cgi?id=217359

The bugspray bot integration is significantly different from Bugzilla's native
email support. The goal was specifically to not require bug participants from
creating a bugzilla account in order to be able to participate in the
discussion.

Bugs can, of course, be easily queried, assigned, and tagged with keywords
that can be filtered.

Bugspray is still in early development, but I plan to continue expanding its
set of features, because we hope to make bugzilla actually useful for kernel
bug reports.

-K

Re: [TOPIC 07/11] New Contributors and Discord

[Junio C Hamano]

Konstantin Ryabitsev <konstantin@linuxfoundation.org> writes:

> I can chime up and offer bugspray bot integration for the list. This is a new
> tool I've been developing for integrating the mailing list with bugzilla. I've
> been using it on the tools mailing list over the past year with reasonable
> success.

Intriguing.  Everybody loves to hate bugzilla, but would bugzilla
become less smelly with bugspray enough to make it palatable to all
of us?

> Bugs can, of course, be easily queried, assigned, and tagged with keywords
> that can be filtered.
>
> Bugspray is still in early development, but I plan to continue expanding its
> set of features, because we hope to make bugzilla actually useful for kernel
> bug reports.

;-)

Re: [TOPIC 07/11] New Contributors and Discord

[Konstantin Ryabitsev]

On Mon, Sep 23, 2024 at 02:31:07PM GMT, Junio C Hamano wrote:
> > I can chime up and offer bugspray bot integration for the list. This is a new
> > tool I've been developing for integrating the mailing list with bugzilla. I've
> > been using it on the tools mailing list over the past year with reasonable
> > success.
> 
> Intriguing.  Everybody loves to hate bugzilla, but would bugzilla
> become less smelly with bugspray enough to make it palatable to all
> of us?

I'm happy to enable it for this list if you'd like to try this out. It doesn't
really create any obligation to use it, but it may end up being something
useful.

To enable it, I only need a list of people who are allowed to trigger bugspray
via the "bugspray track" trigger phrase. I assume it's going to be more than
just you?

-K

Re: [TOPIC 07/11] New Contributors and Discord

[Junio C Hamano]

Konstantin Ryabitsev <konstantin@linuxfoundation.org> writes:

> On Mon, Sep 23, 2024 at 02:31:07PM GMT, Junio C Hamano wrote:
>> > I can chime up and offer bugspray bot integration for the list. This is a new
>> > tool I've been developing for integrating the mailing list with bugzilla. I've
>> > been using it on the tools mailing list over the past year with reasonable
>> > success.
>> 
>> Intriguing.  Everybody loves to hate bugzilla, but would bugzilla
>> become less smelly with bugspray enough to make it palatable to all
>> of us?
>
> I'm happy to enable it for this list if you'd like to try this out. It doesn't
> really create any obligation to use it, but it may end up being something
> useful.
>
> To enable it, I only need a list of people who are allowed to trigger bugspray
> via the "bugspray track" trigger phrase. I assume it's going to be more than
> just you?

Now we'll have to come up with and maintain an official list of
trusted contributors.  Which at first may sound like such a list may
alianate those who did not make the list, but when deciding which
topics are ready to hit 'next', such a "selection" is implicitly
made to choose whose opinion weigh more anyway.

It might make the process more transparent to formalize the "more
trusted contributors" list.

I suspect that the list of folks who can operator bugspray do not
necessarily have to be with deep technical knowledge of the innards
of Git.  They have to be able to dedicate the time to read and
understand what was said in the discussion threads, recognise when a
problem is identified ("bugspray track"), have been long enough to
know or able to use "git blame / git log" to see who likely has
useful insight into the issue than others ("bugspray tag"?), and
have good enough taste to recognise irrelevant "bugs" that are
opened by those with worse taste.  In a sense, it is very different
from the earlier "list of those whose opinion weigh more in
assessing topic's doneness".  Competent "project secretaries" are
the kinds of people we want.

If I misunderstood the nature of "allow-list" for trigger phrase,
please correct me.  Also it would be very welcome to hear from those
listening in from the sidelines who want to see different kinds of
people to be on the trigger phrase list.

Thanks.

Re: [TOPIC 07/11] New Contributors and Discord

[Konstantin Ryabitsev]

On Tue, Sep 24, 2024 at 12:15:13PM GMT, Junio C Hamano wrote:
> > To enable it, I only need a list of people who are allowed to trigger bugspray
> > via the "bugspray track" trigger phrase. I assume it's going to be more than
> > just you?
> 
> Now we'll have to come up with and maintain an official list of
> trusted contributors.  Which at first may sound like such a list may
> alianate those who did not make the list, but when deciding which
> topics are ready to hit 'next', such a "selection" is implicitly
> made to choose whose opinion weigh more anyway.

Yeah, you're overthinking this. :) I literally just want to restrict the
ability to invoke bugspray to a limited number of people, at least for the
time being -- to avoid a situation like a troll sending "bugspray track" to
every possible thread. 

The people on this list don't have to have any kind of official standing with
the git project itself.

> I suspect that the list of folks who can operator bugspray do not
> necessarily have to be with deep technical knowledge of the innards
> of Git.  They have to be able to dedicate the time to read and
> understand what was said in the discussion threads, recognise when a
> problem is identified ("bugspray track"), have been long enough to
> know or able to use "git blame / git log" to see who likely has
> useful insight into the issue than others ("bugspray tag"?),

FYI, "bugspray tag" assigns the bug in bugzilla to a specific person. If you
don't intend to use bugzilla to this degree, you can ignore this aspect of it
entirely and never use the tag command.

> and have good enough taste to recognise irrelevant "bugs" that are
> opened by those with worse taste.  In a sense, it is very different
> from the earlier "list of those whose opinion weigh more in
> assessing topic's doneness".  Competent "project secretaries" are
> the kinds of people we want.
> 
> If I misunderstood the nature of "allow-list" for trigger phrase,
> please correct me.  Also it would be very welcome to hear from those
> listening in from the sidelines who want to see different kinds of
> people to be on the trigger phrase list.

Hopefully, I clarified it a bit. Also, bugspray is still an early model, so I
am happy to add functionality based on the feedback I receive.

-K

Re: [TOPIC 07/11] New Contributors and Discord

[Phillip Wood]

On 23/09/2024 22:31, Junio C Hamano wrote:
> Konstantin Ryabitsev <konstantin@linuxfoundation.org> writes:
> 
>> I can chime up and offer bugspray bot integration for the list. This is a new
>> tool I've been developing for integrating the mailing list with bugzilla. I've
>> been using it on the tools mailing list over the past year with reasonable
>> success.
> 
> Intriguing.  Everybody loves to hate bugzilla, but would bugzilla
> become less smelly with bugspray enough to make it palatable to all
> of us?

If it's easy to set up it might be worth a try. My memories of using 
bugzilla in the past are that it wasn't too bad for issue tracking. Most 
of the pain came from trying to use it to review patches which we 
wouldn't be doing.

Best Wishes

Phillip

>> Bugs can, of course, be easily queried, assigned, and tagged with keywords
>> that can be filtered.
>>
>> Bugspray is still in early development, but I plan to continue expanding its
>> set of features, because we hope to make bugzilla actually useful for kernel
>> bug reports.
> 
> ;-)
> 

Re: [TOPIC 07/11] New Contributors and Discord

[Junio C Hamano]

Phillip Wood <phillip.wood123@gmail.com> writes:

> On 23/09/2024 22:31, Junio C Hamano wrote:
>> Konstantin Ryabitsev <konstantin@linuxfoundation.org> writes:
>> 
>>> I can chime up and offer bugspray bot integration for the list. This is a new
>>> tool I've been developing for integrating the mailing list with bugzilla. I've
>>> been using it on the tools mailing list over the past year with reasonable
>>> success.
>> Intriguing.  Everybody loves to hate bugzilla, but would bugzilla
>> become less smelly with bugspray enough to make it palatable to all
>> of us?
>
> If it's easy to set up it might be worth a try. My memories of using
> bugzilla in the past are that it wasn't too bad for issue
> tracking. Most of the pain came from trying to use it to review
> patches which we wouldn't be doing.

The biggest pain point I remember with bugzilla was to find bugs
that are still relevant to make sure they are assigned to somebody.
IOW, curating the collection to make sure false alarms are marked as
such quickly enough.

Thanks.

Re: [TOPIC 07/11] New Contributors and Discord

[Phillip Wood]

On 27/09/2024 20:22, Junio C Hamano wrote:
> Phillip Wood <phillip.wood123@gmail.com> writes:
> 
>> If it's easy to set up it might be worth a try. My memories of using
>> bugzilla in the past are that it wasn't too bad for issue
>> tracking. Most of the pain came from trying to use it to review
>> patches which we wouldn't be doing.
> 
> The biggest pain point I remember with bugzilla was to find bugs
> that are still relevant to make sure they are assigned to somebody.
> IOW, curating the collection to make sure false alarms are marked as
> such quickly enough.

That's certainly a pain, but I don't think it's specific to bugzilla 
though. I agree that to be useful the list of bugs needs curating.

Best Wishes

Phillip

[TOPIC 08/11] Modern Build Systems

[Taylor Blau]

Modern Build System
===================

(moderator: Patrick; notetaker: brian)

* Patrick: three different build system; should get rid of at least one
  of them
  * Should delete autoconf because it's not really maintained
  * Think about a proper build system
  * Obvious choice: cmake
* Taylor: What's the problem with Makefiles
* Patrick: Non-standard
  * Meson is nicer than cmake as an alternative
* Jonathan: xz compromise shows autoconf is a risk
* Autoconf isn't a problem for distro
* Taylor: distro builds that can't handle "make" without configure are a
  distro problem
* Jonathan: Modern build system can reflect the structure of how your
  code is set up
  * Declared dependencies
* Brian: Rust will make the decision for us: cargo
  * BSDs use Make (granted, not GNU make) for building
* Patrick: Is anyone else in favour of a proper build system
  * Ninja is way faster than make to build the projects
* Taylor: Feels odd to build with a fancy tool that might have a
  dependency on Git
* Dscho: --help is a autoconf feature and removed features are detected
* Patrick: Isn't that an argument for cmake over autoconf? Dscho: yes
* Kyle: Editor integration is useful
* brian: standard structure is helpful for LSPs
* Emily: libification has shown that makefile is cumbersome
* Jonathan: Should we do a comparison of build systems in terms of what
  we need from them on the list? Similar to
  Documentation/technical/unit-tests.txt
  * Patrick: I can write such a thing.
* Patrick: Are their any features we need to consider?
* Johannes Sixt: Consider supported platforms
* Patrick: Want to verify that cmake is up to the task by testing in CI?
  * Will volunteer to post something to the list

Re: [TOPIC 08/11] Modern Build Systems

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 5945 bytes --]

On 9/20/24 10:21 AM, Taylor Blau wrote:
> Modern Build System
> ===================
> 
> (moderator: Patrick; notetaker: brian)
> 
> * Patrick: three different build system; should get rid of at least one
>   of them
>   * Should delete autoconf because it's not really maintained
>   * Think about a proper build system
>   * Obvious choice: cmake
> * Taylor: What's the problem with Makefiles
> * Patrick: Non-standard
>   * Meson is nicer than cmake as an alternative


I suppose I'm pretty biased but yes, I do feel we (meson) have managed
to make some great workflow improvements here. :)

Please do feel free to ask me questions about it.


> * Jonathan: xz compromise shows autoconf is a risk
> * Autoconf isn't a problem for distro
> * Taylor: distro builds that can't handle "make" without configure are a
>   distro problem


Anyone can handle "make" without configure without breaking a sweat,
that isn't even remotely challenging, and every distro already does it.
The problem is that "make" is stateless, which is another way of saying
it has amnesia. By that token, everyone cobbles together their own state
system on top of "make".

Admittedly, once set up it doesn't require much maintenance from version
bump to version bump.


> * Jonathan: Modern build system can reflect the structure of how your
>   code is set up
>   * Declared dependencies
> * Brian: Rust will make the decision for us: cargo


I would just like to note that this is not really true. There is one
other build system that supports rust and its name is... meson. :)

Meson supports rust as a language for creating libraries (cdylib or
rlib) and executables. You can import a crate from crates.io and meson
will synthesize the build system from the existing Cargo.toml to expose
it as an rlib dependency.

You still get full build script option parsing, system probing, control
flow etc using the meson.build DSL, you can freely mix libraries or
executables in any of meson's supported languages (C, C++, Cython, C#,
D, Fortran, java, ObjC, Rust, swift, Vala...), process custom commands
for data files, run gettext on translations, and more. Meson is designed
to be a polyglot build system in ways that cargo will probably never be.

Cargo is probably best thought of as a compiler wrapper: it can spit out
an executable if you run it on *.rs sources, but it doesn't replace most
of the interesting parts of a build system and it doesn't even provide
an "install" rule. No, `cargo install` does not count unfortunately as
it has a nasty habit of recompiling the binaries you already compiled,
but now with the wrong options.

You really want something that provides a project lifecycle workflow for
building, testing, installing, and making dist tarballs with integrated
distcheck. The current Makefiles mostly kind of work, given sufficient
care, but cargo provides exactly zero of anything so you're back to
cobbling together your entire workflow using Makefiles wrapped around
cargo. I would call that the very furthest opposite from "make the
decision for us".


>   * BSDs use Make (granted, not GNU make) for building
> * Patrick: Is anyone else in favour of a proper build system
>   * Ninja is way faster than make to build the projects


It is! Yes. Mostly because it does very, very little other than execute
a precalculated build graph, whereas the current Makefile runs a bunch
of stateless external commands each time in order to calculate top-level
Make variables.


> * Taylor: Feels odd to build with a fancy tool that might have a
>   dependency on Git
> * Dscho: --help is a autoconf feature and removed features are detected
> * Patrick: Isn't that an argument for cmake over autoconf? Dscho: yes


cmake does not have an equivalent of ./configure --help. The best you
can get is to try to somehow successfully configure cmake once, and then
run a cmake command that prints every internal control flow variable
used by cmake, then hope that the ones you care about include descriptions.

(Say what you will about GNU autotools but they knew very well how to
write good interaction standards, as evidenced by all the Makefile
variables git.git already uses from the GNU Coding Standards docs on how
to architect a release process.) It is fundamental to the UX design of
./configure that a user may query the build system to find out what
choices they can / are expected to make, before committing to those choices.

cmake is actively a severe regression compared to autoconf for these
purposes.


> * Kyle: Editor integration is useful
> * brian: standard structure is helpful for LSPs


These tend to mostly be solved by compile_commands.json, which most
modern build systems can produce. In particular, anything that creates a
ninja file essentially gets you this for free, because ninja can create
one for you.

Plain Makefiles, and GNU automake, don't do very well at this at all,
since Make has too irregular a build graph to reliably compute any such
thing. Same reason why there isn't much in the way of dedicated editor
integration (both cmake and meson have introspection APIs which editor
plugins can use to directly query info from the build system, to provide
finer-grained control than what compile_commands.json can do).


> * Emily: libification has shown that makefile is cumbersome
> * Jonathan: Should we do a comparison of build systems in terms of what
>   we need from them on the list? Similar to
>   Documentation/technical/unit-tests.txt
>   * Patrick: I can write such a thing.
> * Patrick: Are their any features we need to consider?
> * Johannes Sixt: Consider supported platforms
> * Patrick: Want to verify that cmake is up to the task by testing in CI?
>   * Will volunteer to post something to the list
> 

-- 
Eli Schwartz
Gentoo Developer and Meson Build maintainer

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: [TOPIC 08/11] Modern Build Systems

[Patrick Steinhardt]

On Sun, Sep 22, 2024 at 10:01:32PM -0400, Eli Schwartz wrote:
> On 9/20/24 10:21 AM, Taylor Blau wrote:
> > Modern Build System
> > ===================
> > 
> > (moderator: Patrick; notetaker: brian)
> > 
> > * Patrick: three different build system; should get rid of at least one
> >   of them
> >   * Should delete autoconf because it's not really maintained
> >   * Think about a proper build system
> >   * Obvious choice: cmake
> > * Taylor: What's the problem with Makefiles
> > * Patrick: Non-standard
> >   * Meson is nicer than cmake as an alternative
> 
> 
> I suppose I'm pretty biased but yes, I do feel we (meson) have managed
> to make some great workflow improvements here. :)
> 
> Please do feel free to ask me questions about it.
> 
> 
> > * Jonathan: xz compromise shows autoconf is a risk
> > * Autoconf isn't a problem for distro
> > * Taylor: distro builds that can't handle "make" without configure are a
> >   distro problem
> 
> 
> Anyone can handle "make" without configure without breaking a sweat,
> that isn't even remotely challenging, and every distro already does it.
> The problem is that "make" is stateless, which is another way of saying
> it has amnesia. By that token, everyone cobbles together their own state
> system on top of "make".
> 
> Admittedly, once set up it doesn't require much maintenance from version
> bump to version bump.
> 
> 
> > * Jonathan: Modern build system can reflect the structure of how your
> >   code is set up
> >   * Declared dependencies
> > * Brian: Rust will make the decision for us: cargo
> 
> 
> I would just like to note that this is not really true. There is one
> other build system that supports rust and its name is... meson. :)
> 
> Meson supports rust as a language for creating libraries (cdylib or
> rlib) and executables. You can import a crate from crates.io and meson
> will synthesize the build system from the existing Cargo.toml to expose
> it as an rlib dependency.
> 
> You still get full build script option parsing, system probing, control
> flow etc using the meson.build DSL, you can freely mix libraries or
> executables in any of meson's supported languages (C, C++, Cython, C#,
> D, Fortran, java, ObjC, Rust, swift, Vala...), process custom commands
> for data files, run gettext on translations, and more. Meson is designed
> to be a polyglot build system in ways that cargo will probably never be.
> 
> Cargo is probably best thought of as a compiler wrapper: it can spit out
> an executable if you run it on *.rs sources, but it doesn't replace most
> of the interesting parts of a build system and it doesn't even provide
> an "install" rule. No, `cargo install` does not count unfortunately as
> it has a nasty habit of recompiling the binaries you already compiled,
> but now with the wrong options.
> 
> You really want something that provides a project lifecycle workflow for
> building, testing, installing, and making dist tarballs with integrated
> distcheck. The current Makefiles mostly kind of work, given sufficient
> care, but cargo provides exactly zero of anything so you're back to
> cobbling together your entire workflow using Makefiles wrapped around
> cargo. I would call that the very furthest opposite from "make the
> decision for us".
> 
> 
> >   * BSDs use Make (granted, not GNU make) for building
> > * Patrick: Is anyone else in favour of a proper build system
> >   * Ninja is way faster than make to build the projects
> 
> 
> It is! Yes. Mostly because it does very, very little other than execute
> a precalculated build graph, whereas the current Makefile runs a bunch
> of stateless external commands each time in order to calculate top-level
> Make variables.
> 
> 
> > * Taylor: Feels odd to build with a fancy tool that might have a
> >   dependency on Git
> > * Dscho: --help is a autoconf feature and removed features are detected
> > * Patrick: Isn't that an argument for cmake over autoconf? Dscho: yes
> 
> 
> cmake does not have an equivalent of ./configure --help. The best you
> can get is to try to somehow successfully configure cmake once, and then
> run a cmake command that prints every internal control flow variable
> used by cmake, then hope that the ones you care about include descriptions.
> 
> (Say what you will about GNU autotools but they knew very well how to
> write good interaction standards, as evidenced by all the Makefile
> variables git.git already uses from the GNU Coding Standards docs on how
> to architect a release process.) It is fundamental to the UX design of
> ./configure that a user may query the build system to find out what
> choices they can / are expected to make, before committing to those choices.
> 
> cmake is actively a severe regression compared to autoconf for these
> purposes.
> 
> 
> > * Kyle: Editor integration is useful
> > * brian: standard structure is helpful for LSPs
> 
> 
> These tend to mostly be solved by compile_commands.json, which most
> modern build systems can produce. In particular, anything that creates a
> ninja file essentially gets you this for free, because ninja can create
> one for you.
> 
> Plain Makefiles, and GNU automake, don't do very well at this at all,
> since Make has too irregular a build graph to reliably compute any such
> thing. Same reason why there isn't much in the way of dedicated editor
> integration (both cmake and meson have introspection APIs which editor
> plugins can use to directly query info from the build system, to provide
> finer-grained control than what compile_commands.json can do).
> 
> 
> > * Emily: libification has shown that makefile is cumbersome
> > * Jonathan: Should we do a comparison of build systems in terms of what
> >   we need from them on the list? Similar to
> >   Documentation/technical/unit-tests.txt
> >   * Patrick: I can write such a thing.
> > * Patrick: Are their any features we need to consider?
> > * Johannes Sixt: Consider supported platforms
> > * Patrick: Want to verify that cmake is up to the task by testing in CI?
> >   * Will volunteer to post something to the list

Thanks for your input, Eli, I highly appreciate it to get feedback from
a distro maintainer's point of view! I'm not going to answer here,
because there already is an ongoing thread at [1].

So I'd propose to consolidate it into that thread. I've put you into Cc
there.

Patrick

[1]: <GV1PR02MB848925A79A9DD733848182D58D662@GV1PR02MB8489.eurprd02.prod.outlook.com>

[TOPIC 09/11] Bundle-URI on fetch / resume-able clone

[Taylor Blau]

Bundle-URI on fetch / resume-able clone
=======================================

(moderator: Toon; notetaker: Taylor)

* Toon: we have bundle-uris, which allow us to download bundles before
	cloning. What would it take to do them on fetch, too?
* Toon: Complex; you might end up downloading a lot of bundles that you
	don't need.
* Toon: there was a bundle token that could be used by the client to
	determine whether or not it needs the bundle. Unfortunately, since you
	don't know what amount of history you're missing, the bundle in and of
	itself may not be sufficient.
* Toon: How do we make bundles more efficient on fetch and aware of what
	the clients do and don't have.
* Johannes: In VFS for Git, the set of bundles is "opinionated" and
	regenerated often (e.g., weekly, daily, hourly, etc.). We don't really
	care about oversharing, because it's fast enough to download those
	static files.
* Toon: That's true for the server, not for a singular client.
* Johannes: right, but it's to protect the server. If you don't care
	about having too-big of a bundle, it's OK because you can just fetch
	the last hour and then see what you still need on top of that.
* Johannes: there is logic to determine what you need to download based
	on the time that you last fetched, etc.
* Elijah: are they thin packs? Yes.
* Patrick: the heuristics that we have to advertise what kind of bundles
	are on the server is not sufficient enough to determine which bundles
	the client may or may not want to download. The client must guess.
* Jonathan: ISTM that the property list for the bundles as they are
	today should probably be considered a starting point (as in "part of a
	feature"). The heuristics need to be extended.
* Jonathan: at Google we use packfile-URIs, and one of the advantages of
	how that works is that since the packfiles are advertised after the
	normal fetch negotiation, you get a curated list. For bundle-uris,
	need something analogous to the fetch negotiation for the client to be
	able to make a similar decision of which bundle to download.
* brian: extending the feature to store timestamps, then you could store
	the last fetch on the system would inform some better selection of
	which bundles to clone down during a fetch.
* brian: Would make a big difference for folks in environments which do
	not benefit from reliable Internet connections.
* Toon: Sure... but you have to put a lot of pressure to keep those
	bundles up-to-date on the server side.
* Jonathan: one of the advantages of bundles over packs is that they
	have information about the references. One potential property could be
	"here's the length of this header" and then having the client download
	it to examine whether or not it wants such a bundle.
* Patrick: probably would want to cache those on the client so that
	we're able to avoid re-downloading these every single time.
* Toon: resumability
* Jonathan: protocol supports it, just hasn't been implemented. Someone
	needs to just get it done. :)
* Beyond that, the main complication is how you store the state and what
	the UX is for resuming. But a person implementing it can figure those
	things out.
* Brian: broken-proxy situations require some configurability of where
	your bundles can be downloaded from.

[TOPIC 10/11] Project Tracking

[Taylor Blau]

Project Tracking
================

(moderator: Emily, Patrick; notetaker: Taylor)

* Emily: Patrick and I were talking about roadmap-like things sometimes
  this week. It would be nice if we had a list of projects that the
  community has agreed are good ideas. For e.g., “generally we are
  working on getting rid of ‘the_repository’”.
* Emily: We have agreed that libification is a good thing, so anytime
  that someone sends a patch in that area it isn’t up for discussion
  whether or not the patch is fundamentally going in the right
  direction.
* Emily: It would be cool to have a list of agreed-upon things. I also
  think that we should get better at figuring out what we agree on.
  I.e., the status-quo is argument on the list until quorum, and would
  like some kind of more structured way to determine when we are in
  agreement.
* Jonathan: When you say “predictable process”, what does that actually
  mean? Python has PEPs, they have a very clear state machine that
  stringently dictates the process.
* Emily: probably not something that strict, but would like to generally
  be able to tell “is it going in the right direction?” And
  approximately, “Approximately when will we be able to tell when it’s
  done?”
* Taylor: how do we quantify that? A lot of what developing consensus
  looks like is developing patches and then sometimes throwing them away
  if/when we find a fundamental design bug, etc.
* Patrick: “Are we going to do it?” is when something like a brief RFC
  is merged.
* Taylor: Is the Git 3.0 deprecation doc a good example?
* Patrick: Yeah.
* Patrick: We would also want to have a document with a little check
  mark indicating when we are going to do small things like clean up
  memory leaks.
* Jrn: The pain point is being able to know when making a proposal how
  much support they have.
* Taylor: Sometimes implementation clarifies one’s thinking.
* John: We have some tribal knowledge on what is accepted in which
  areas. Can we codify that?
* Patrick: The BreakingChanges statement says that we can change things
  on the document if there is new information. I’d like to see that this
  statement is echoed elsewhere.
* Taylor: It feels like it would be more useful to have a discussion
  based on a WIP or PoC (e.g. UNLEAK() and FREE_AND_NULL()).
* Peff: I don’t want people to produce patches, say, if we blessed unit
  tests, and then consider that discussion immutable. That doesn’t give
  us the opportunity to make changes to the fundamental design. I don’t
  want to use it as a cudgel to shut further discussion down.
* Jonathan: “I guess I am going to argue in favor of cudgel.” Taking
  unit tests as an example, if someone later says “I don’t see any value
  in unit tests”, that’s not very productive. If they say “I see the
  value of unit tests, but not at this cost”, it’s a more worthwhile
  conversation.
* brian: Maybe we can only use that as an argument for 4-5 weeks. Having
  some disagreement is fine, just don’t want to make it indefinite.
* Peff: On PEPs. Often someone will say “I’m going to go in this
  direction”, and I’ll feel mildly negative about it. That’s very
  different from voting against something.
* Emily: Sure, there can be more voting options than just
  yes/no/abstain.
* Jonathan: Apache does a nice job with +/- 0, +/- 1
  (https://www.apache.org/foundation/voting.html#expressing-votes-1-0-1-and-fractions)
* Emily: we should be better about saying generally how we feel about
  things at the end of the series).
* Taylor: Taking a step back for a moment, what are some examples of
  things that are going wrong that need to be changed? What is wrong
  with the project here?
* Emily: things are taking too long.
* Emily: Goal-posting moving, etc.
* Johannes: Yes, that can be very frustrating and cause a lot of
  friction.
* brian: When you do creative work, you get feedback and sometimes you
  take it and sometimes you don’t.
* Taylor: at the risk of repeating what brian said, it’s hard/impossible
  to please 100% of reviewers on 100% of series. At some point you have
  to step back and let the maintainer evaluate.
* Jonathan: I think the point of Patrick’s proposal is “how do you go
  about navigating this with a 10-series long project?” Then you’re in
  trouble. The proposal would allow you to check in a bullet point, or a
  design doc, and go through that process and navigate to the point
  where you get the maintainer’s blessing and the conclusion is checked
  in.
* brian: Maybe a bullet point is too small for some things.
* Taylor: so it’s a continuum, sometimes you are going to save time by
  just writing the patches, sometimes you are going to save time by
  writing out what you are doing (over a multi-series effort) first.
* Patrick: discoverability!
* Mark: could we encourage newcomers to email one of a few people for a
  particular effort (like libification) and have them comment on it?
* Taylor: you might not want to centralize that much power.
* Toon: How about structured errors? We agree it’s a good idea, but not
  on the mechanism of implementation.
* Patrick: Sure, sometimes that just takes time. We don’t have to
  document how to fix them (maybe how to find them, but I digress).
* Patrick: For structured error handling, it should be more involved. It
  makes sense to have an RFC or design document that documents how it’s
  supposed to look like.
* brian: or an initial patch series that comes up with a design.
* Peff: In our project, the formalism of voting is “is it merged to
  ‘master’ in Junio’s tree”.
* Emily: I want to have the process of getting from discussion to merge
  be less fuzzy.
* Peff: So in brian’s example, let’s take SHA-256. The process by which
  the maintainer decides that is inherently fuzzy.
* Emily: Sure, but I would like to be obvious to someone besides the
  maintainer.
* Jonathan: (to Peff) you mentioned sometimes you have a mild negative
  feeling about something and you’re good about expressing it on-list,
  but for a lot of contributors that will cause some discomfort and it
  will cause them to stay away from that thread. If we’re a little more
  clear about what’s expected, then conversations can get stalled less
  often - e.g. when a thread needs a comment from a refs expert, getting
  that comment that supports forward progress.
* brian: I just gave Taylor feedback on the SHA-1 series that he wrote,
  saying that I didn’t love it. But others felt OK about it, so we moved
  forward.
* Emily: strawman doc:
  https://github.com/nasamuffin/git/commit/54079ab00002c6dfa7ac1a33d9810792978d2cce
  - maybe it's bad enough we can poke holes and salvage something we do
  like
* Peff: it’s important to leave at the end of your review the way you
  feel about something instead of just having a few comments.

Re: [TOPIC 10/11] Project Tracking

[Junio C Hamano]

Taylor Blau <me@ttaylorr.com> writes:

> * Peff: In our project, the formalism of voting is “is it merged to
>   ‘master’ in Junio’s tree”.

Graduation from 'next' to 'master' is mostly mechanical "spend 1
calendar week and you are done", so 'next' matters a lot more.

> * Emily: I want to have the process of getting from discussion to merge
>   be less fuzzy.
> * Peff: So in brian’s example, let’s take SHA-256. The process by which
>   the maintainer decides that is inherently fuzzy.
> * Emily: Sure, but I would like to be obvious to someone besides the
>   maintainer.

FWIW, this also is fuzzy for the maintainer, especially when not
many people who ought to know a lot more than the maintainer are
staying silent.

> * Jonathan: (to Peff) you mentioned sometimes you have a mild negative
>   feeling about something and you’re good about expressing it on-list,
>   but for a lot of contributors that will cause some discomfort and it
>   will cause them to stay away from that thread. If we’re a little more
>   clear about what’s expected, then conversations can get stalled less
>   often - e.g. when a thread needs a comment from a refs expert, getting
>   that comment that supports forward progress.

Yes, either forward or backward.  Having to keep a series that looks
potentially worth doing for weeks on 'seen' without getting any
movement is *VERY* painful.  Would it motivate more experienced
contributors to review and express either support or refusal if I
more frequently, say after 20 days since its latest round got queued
on 'seen', a topic that does not seem to get enough support to be
merged to 'next' and is not getting rerolled?

> * brian: I just gave Taylor feedback on the SHA-1 series that he wrote,
>   saying that I didn’t love it. But others felt OK about it, so we moved
>   forward.

For this particular one, I consider it is not "we moved forward", by
the way.  Please do not consider anything that is not marked with
"Will merge to 'next'?" (with or without the final '?') moving
forward.

> * Peff: it’s important to leave at the end of your review the way you
>   feel about something instead of just having a few comments.

Yup, that would clarify area experts' position on topics and would
help everybody a lot.  It would also help me when updating the
"What's cooking" draft, which is how the topics currently in-flight
are getting tracked.

Thanks.

Re: [TOPIC 10/11] Project Tracking

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> Yes, either forward or backward.  Having to keep a series that looks
> potentially worth doing for weeks on 'seen' without getting any
> movement is *VERY* painful.  Would it motivate more experienced
> contributors to review and express either support or refusal if I
> more frequently, say after 20 days since its latest round got queued
> on 'seen', a topic that does not seem to get enough support to be
> merged to 'next' and is not getting rerolled?

Missing verb was "discard".  Instead of keeping the stalled topic,
perhaps I should more actively discard them (people are allowed to
send in a fresh iteration if they care enough)?

Sorry for the noise.

Re: [TOPIC 10/11] Project Tracking

[Phillip Wood]

On 20/09/2024 20:41, Junio C Hamano wrote:
> Taylor Blau <me@ttaylorr.com> writes:

Taylor - thanks for posting these discussions

>> * Jonathan: (to Peff) you mentioned sometimes you have a mild negative
>>    feeling about something and you’re good about expressing it on-list,
>>    but for a lot of contributors that will cause some discomfort and it
>>    will cause them to stay away from that thread. If we’re a little more
>>    clear about what’s expected, then conversations can get stalled less
>>    often - e.g. when a thread needs a comment from a refs expert, getting
>>    that comment that supports forward progress.
> 
> Yes, either forward or backward.  Having to keep a series that looks
> potentially worth doing for weeks on 'seen' without getting any
> movement is *VERY* painful.  Would it motivate more experienced
> contributors to review and express either support or refusal if I
> more frequently, say after 20 days since its latest round got queued
> on 'seen', a topic that does not seem to get enough support to be
> merged to 'next' and is not getting rerolled?

I think that sounds reasonable. Sometimes I'm quite slow to review but 
if I haven't managed to do it within 3 weeks I'm unlikely to get round 
to it. I'm also sometimes slow to re-roll if I'm ruminating on the best 
way forward, but even if a patch series gets dropped there is nothing 
stopping the contributor from re-rolling.

Best Wishes

Phillip

[TOPIC 11/11] git-scm.com state of the site

[Taylor Blau]

git-scm.com state of the site
=============================

* Johannes: worked on a static site version of git-scm.com.

(Johannes: demonstration)

* Peff: let’s move it over.
* Taylor: AGREED

Re: [GSoC][PATCH] unit-tests: add tests for oidset.h

[Crystal M Baker]

Sent from my iPhone

Re: [GSoC][PATCH] unit-tests: add tests for oidset.h

[Crystal M Baker]

Sent from my iPhone