comment

diff --git a/doc/todo/onlyingroup_preferred_content_expression/comment_2_b1a22e4fbc594c3085e7fbc6fbaab69a._comment b/doc/todo/onlyingroup_preferred_content_expression/comment_2_b1a22e4fbc594c3085e7fbc6fbaab69a._comment
new file mode 100644 (file)
index 0000000..1f5658d
--- /dev/null
+++ b/doc/todo/onlyingroup_preferred_content_expression/comment_2_b1a22e4fbc594c3085e7fbc6fbaab69a._comment
@@ -0,0 +1,34 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2023-07-31T17:12:52Z"
+ content="""
+This seems like a pretty good idea. In particular, I think that the
+`not onlyingroup=offline-backup` example is persuasive. The
+`field` group example might be able to be dealt with by having
+a `collected` group and using `copies=collected:1` in repositories
+that only want a copy of data once it's been collected from the field.
+
+Hmm, one problem is that if you have 2 groups that you are using
+onlyingroup with, eg
+`(not onlyingroup=offline-backup) and (not onlyingroup=offline-archive)`.
+A file that is in two repositories, one for each group, will not match.
+
+One way to address that would be something like
+`onlyingroups=offline-backup,offline-archive` which would match
+on presence in any listed groups. I don't really like that this has
+its own ANDing happening inside a term of a preferred content expression
+though.
+
+What is onlyingroup supposed to do when a repository is in the
+specified group, but also in another group? My first reaction was that
+it should never match when content is in such a repository, since the
+content is indeed present in another group. 
+But that doesn't really seem useful.
+
+If it treated a repository that's in the specified group, but also is 
+in other groups, as matching, then it would be possible to put a repository
+in groups offline and backup and match on `not onlyingroup=offline`.
+I like this better than the `onlyingroups=offline-backup,offline-archive`
+because it's simpler and more composable.
+"""]]