You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@grails.apache.org by Paul King <pa...@asert.com.au> on 2025/02/21 06:14:04 UTC
[DISCUSS] Mailing list selection
Hi folks,
Currently Grails has private and dev mailing lists created. Folks
interested in the development of Grails should subscribe to the dev
list. Folks on the PPMC (podling project management committee) should
subscribe to the private list. Typically projects have additional
lists.
The most common one is "users" for users of Grails to ask questions.
**It is recommended you have a users mailing list.**
The next most common ones are commits/notifications. There are lots of
potential sources of information that can provide insight into changes
made in the project. The ASF strongly recommends that you send those
to a mailing list. You will have numerous options to configure what
goes where (it can be changed over time and you don't need to decide
that now). For now you just need to decide if you want one or both of
those lists. You can send some of the sources of notifications to the
dev list but it can soon become swamped, so you'd typically only want
a select subset to go there.
Geb just has notifications. It sends a few select sources of info to
geb-dev and everything else (includes commits, discussions, issues, GH
action status, PR comments; about 100/month) goes to
geb-notifications. The advantage of having one list is that there is
just one place to look but there might be more noise if you are
browsing through looking for something.
Groovy has both commits (all commits/code changes from all repos;
about 200/month) and notifications (PR status changes, issue tracking
comments; 300+/month). The advantage of splitting the two is that if
you are searching for a code change, commits is likely where you'll
find luck. If you remember something someone said (maybe in an issue
comment), notifications might be the better place to look. I encourage
bigger projects to go down this path since you have a bit more
flexibility, but I wouldn't call it a super strong preference.
You could also go more fine grained and have "issues", "discussions"
and so forth. I don't have a lot of experience with this approach.
Some aspects would be simpler but if you can't remember where a
discussion took place, as a discussion, in a mailing list, on an
issue, a comment on a GitHub commit, etc, you might have more places
to look.
**It is recommended you have a commits mailing list.**
**It is recommended have a notifications mailing list.**
There are other possibilities, e.g. "security". For now you can just
use "private" and if you end up responding to lots of security
aspects, you can create a special one later.
In terms of process, if you are happy with my suggestions, you can
respond +1 to this whole email or +1 to the specific lists you are
happy with. We should discuss as long as needed. After discussion dies
down (or around 72 hrs have passed), if it looks like there is general
consensus, I'll go ahead and create the lists. We should iterate if
discussions head us in a slightly different direction.
If it looks like we need any further clarity, I'll create a [VOTE]
thread separate to this [DISCUSS] thread and we can vote and gain
consensus that way. PPMC votes are binding but, as a general rule,
you'd typically want to take votes from all community members into
account in such discussions/votes.
Cheers, Paul.
Re: [DISCUSS] Mailing list selection
Posted by Eric Kinsella <er...@gmail.com>.
I am aware, I was at the committers meeting yesterday. While mailing lists
are nice for historical reasons, they aren't great for community building
in today's world but that's a different problem than we are trying to solve
here.
/Eric
On Fri, Feb 21, 2025 at 8:58 AM Søren Berg Glasius <so...@glasius.dk>
wrote:
> We are not talking about shutting down the Grails Slack, but discussions
> about dev and direction of Grails needs to be done "the Apache way" through
> a dev mailing list.
>
> /Søren
>
> Den fre. 21. feb. 2025 kl. 15.56 skrev Eric Kinsella <
> erickinsella@gmail.com
> >:
>
> > +1 to proposed users, commits, and notifications mailing lists
> >
> > I agree with Soren about cleaning up previous mailing lists/google groups
> > ie grails@googlegroups.com to point to users@grails.
> >
> > I do believe there is some benefit to new users having Slack/Discord for
> > "getting-started" questions and hopefully quicker turnaround than
> > StackOverflow or mailing lists.
> >
> > Thanks,
> > Eric
> >
> >
> > On Fri, Feb 21, 2025 at 7:18 AM James Daugherty
> > <jd...@jdresources.net.invalid> wrote:
> >
> > > +1 to proposed users, commits, and notifications mailing lists.
> > >
> > > On Fri, Feb 21, 2025 at 5:27 AM Søren Berg Glasius <so...@glasius.dk>
> > > wrote:
> > >
> > > > +1 to proposed users, commits and notifications mailing lists
> > > >
> > > > I propose that grails@googlegroups.com should be decommissioned (or
> > made
> > > > read only) with a final message encouraging members to join
> > > > users@grails.apache.org instead.
> > > >
> > > > Den fre. 21. feb. 2025 kl. 07.15 skrev Paul King <paulk@asert.com.au
> >:
> > > >
> > > > > Hi folks,
> > > > >
> > > > > Currently Grails has private and dev mailing lists created. Folks
> > > > > interested in the development of Grails should subscribe to the dev
> > > > > list. Folks on the PPMC (podling project management committee)
> should
> > > > > subscribe to the private list. Typically projects have additional
> > > > > lists.
> > > > >
> > > > > The most common one is "users" for users of Grails to ask
> questions.
> > > > >
> > > > > **It is recommended you have a users mailing list.**
> > > > >
> > > > > The next most common ones are commits/notifications. There are lots
> > of
> > > > > potential sources of information that can provide insight into
> > changes
> > > > > made in the project. The ASF strongly recommends that you send
> those
> > > > > to a mailing list. You will have numerous options to configure what
> > > > > goes where (it can be changed over time and you don't need to
> decide
> > > > > that now). For now you just need to decide if you want one or both
> of
> > > > > those lists. You can send some of the sources of notifications to
> the
> > > > > dev list but it can soon become swamped, so you'd typically only
> want
> > > > > a select subset to go there.
> > > > >
> > > > > Geb just has notifications. It sends a few select sources of info
> to
> > > > > geb-dev and everything else (includes commits, discussions, issues,
> > GH
> > > > > action status, PR comments; about 100/month) goes to
> > > > > geb-notifications. The advantage of having one list is that there
> is
> > > > > just one place to look but there might be more noise if you are
> > > > > browsing through looking for something.
> > > > >
> > > > > Groovy has both commits (all commits/code changes from all repos;
> > > > > about 200/month) and notifications (PR status changes, issue
> tracking
> > > > > comments; 300+/month). The advantage of splitting the two is that
> if
> > > > > you are searching for a code change, commits is likely where you'll
> > > > > find luck. If you remember something someone said (maybe in an
> issue
> > > > > comment), notifications might be the better place to look. I
> > encourage
> > > > > bigger projects to go down this path since you have a bit more
> > > > > flexibility, but I wouldn't call it a super strong preference.
> > > > >
> > > > > You could also go more fine grained and have "issues",
> "discussions"
> > > > > and so forth. I don't have a lot of experience with this approach.
> > > > > Some aspects would be simpler but if you can't remember where a
> > > > > discussion took place, as a discussion, in a mailing list, on an
> > > > > issue, a comment on a GitHub commit, etc, you might have more
> places
> > > > > to look.
> > > > >
> > > > > **It is recommended you have a commits mailing list.**
> > > > >
> > > > > **It is recommended have a notifications mailing list.**
> > > > >
> > > > > There are other possibilities, e.g. "security". For now you can
> just
> > > > > use "private" and if you end up responding to lots of security
> > > > > aspects, you can create a special one later.
> > > > >
> > > > > In terms of process, if you are happy with my suggestions, you can
> > > > > respond +1 to this whole email or +1 to the specific lists you are
> > > > > happy with. We should discuss as long as needed. After discussion
> > dies
> > > > > down (or around 72 hrs have passed), if it looks like there is
> > general
> > > > > consensus, I'll go ahead and create the lists. We should iterate if
> > > > > discussions head us in a slightly different direction.
> > > > >
> > > > > If it looks like we need any further clarity, I'll create a [VOTE]
> > > > > thread separate to this [DISCUSS] thread and we can vote and gain
> > > > > consensus that way. PPMC votes are binding but, as a general rule,
> > > > > you'd typically want to take votes from all community members into
> > > > > account in such discussions/votes.
> > > > >
> > > > > Cheers, Paul.
> > > > >
> > > >
> > > >
> > > > --
> > > >
> > > > Med venlig hilsen,
> > > > Søren Berg Glasius
> > > >
> > > > Hedevej 1, Gl. Rye, 8680 Ry
> > > > Mobile: +45 40 44 91 88
> > > > --- Press ESC once to quit - twice to save the changes.
> > > >
> > >
> >
>
>
> --
>
> Med venlig hilsen,
> Søren Berg Glasius
>
> Hedevej 1, Gl. Rye, 8680 Ry
> Mobile: +45 40 44 91 88
> --- Press ESC once to quit - twice to save the changes.
>
Re: [DISCUSS] Mailing list selection
Posted by Søren Berg Glasius <so...@glasius.dk>.
We are not talking about shutting down the Grails Slack, but discussions
about dev and direction of Grails needs to be done "the Apache way" through
a dev mailing list.
/Søren
Den fre. 21. feb. 2025 kl. 15.56 skrev Eric Kinsella <erickinsella@gmail.com
>:
> +1 to proposed users, commits, and notifications mailing lists
>
> I agree with Soren about cleaning up previous mailing lists/google groups
> ie grails@googlegroups.com to point to users@grails.
>
> I do believe there is some benefit to new users having Slack/Discord for
> "getting-started" questions and hopefully quicker turnaround than
> StackOverflow or mailing lists.
>
> Thanks,
> Eric
>
>
> On Fri, Feb 21, 2025 at 7:18 AM James Daugherty
> <jd...@jdresources.net.invalid> wrote:
>
> > +1 to proposed users, commits, and notifications mailing lists.
> >
> > On Fri, Feb 21, 2025 at 5:27 AM Søren Berg Glasius <so...@glasius.dk>
> > wrote:
> >
> > > +1 to proposed users, commits and notifications mailing lists
> > >
> > > I propose that grails@googlegroups.com should be decommissioned (or
> made
> > > read only) with a final message encouraging members to join
> > > users@grails.apache.org instead.
> > >
> > > Den fre. 21. feb. 2025 kl. 07.15 skrev Paul King <pa...@asert.com.au>:
> > >
> > > > Hi folks,
> > > >
> > > > Currently Grails has private and dev mailing lists created. Folks
> > > > interested in the development of Grails should subscribe to the dev
> > > > list. Folks on the PPMC (podling project management committee) should
> > > > subscribe to the private list. Typically projects have additional
> > > > lists.
> > > >
> > > > The most common one is "users" for users of Grails to ask questions.
> > > >
> > > > **It is recommended you have a users mailing list.**
> > > >
> > > > The next most common ones are commits/notifications. There are lots
> of
> > > > potential sources of information that can provide insight into
> changes
> > > > made in the project. The ASF strongly recommends that you send those
> > > > to a mailing list. You will have numerous options to configure what
> > > > goes where (it can be changed over time and you don't need to decide
> > > > that now). For now you just need to decide if you want one or both of
> > > > those lists. You can send some of the sources of notifications to the
> > > > dev list but it can soon become swamped, so you'd typically only want
> > > > a select subset to go there.
> > > >
> > > > Geb just has notifications. It sends a few select sources of info to
> > > > geb-dev and everything else (includes commits, discussions, issues,
> GH
> > > > action status, PR comments; about 100/month) goes to
> > > > geb-notifications. The advantage of having one list is that there is
> > > > just one place to look but there might be more noise if you are
> > > > browsing through looking for something.
> > > >
> > > > Groovy has both commits (all commits/code changes from all repos;
> > > > about 200/month) and notifications (PR status changes, issue tracking
> > > > comments; 300+/month). The advantage of splitting the two is that if
> > > > you are searching for a code change, commits is likely where you'll
> > > > find luck. If you remember something someone said (maybe in an issue
> > > > comment), notifications might be the better place to look. I
> encourage
> > > > bigger projects to go down this path since you have a bit more
> > > > flexibility, but I wouldn't call it a super strong preference.
> > > >
> > > > You could also go more fine grained and have "issues", "discussions"
> > > > and so forth. I don't have a lot of experience with this approach.
> > > > Some aspects would be simpler but if you can't remember where a
> > > > discussion took place, as a discussion, in a mailing list, on an
> > > > issue, a comment on a GitHub commit, etc, you might have more places
> > > > to look.
> > > >
> > > > **It is recommended you have a commits mailing list.**
> > > >
> > > > **It is recommended have a notifications mailing list.**
> > > >
> > > > There are other possibilities, e.g. "security". For now you can just
> > > > use "private" and if you end up responding to lots of security
> > > > aspects, you can create a special one later.
> > > >
> > > > In terms of process, if you are happy with my suggestions, you can
> > > > respond +1 to this whole email or +1 to the specific lists you are
> > > > happy with. We should discuss as long as needed. After discussion
> dies
> > > > down (or around 72 hrs have passed), if it looks like there is
> general
> > > > consensus, I'll go ahead and create the lists. We should iterate if
> > > > discussions head us in a slightly different direction.
> > > >
> > > > If it looks like we need any further clarity, I'll create a [VOTE]
> > > > thread separate to this [DISCUSS] thread and we can vote and gain
> > > > consensus that way. PPMC votes are binding but, as a general rule,
> > > > you'd typically want to take votes from all community members into
> > > > account in such discussions/votes.
> > > >
> > > > Cheers, Paul.
> > > >
> > >
> > >
> > > --
> > >
> > > Med venlig hilsen,
> > > Søren Berg Glasius
> > >
> > > Hedevej 1, Gl. Rye, 8680 Ry
> > > Mobile: +45 40 44 91 88
> > > --- Press ESC once to quit - twice to save the changes.
> > >
> >
>
--
Med venlig hilsen,
Søren Berg Glasius
Hedevej 1, Gl. Rye, 8680 Ry
Mobile: +45 40 44 91 88
--- Press ESC once to quit - twice to save the changes.
Re: [DISCUSS] Mailing list selection
Posted by Eric Kinsella <er...@gmail.com>.
+1 to proposed users, commits, and notifications mailing lists
I agree with Soren about cleaning up previous mailing lists/google groups
ie grails@googlegroups.com to point to users@grails.
I do believe there is some benefit to new users having Slack/Discord for
"getting-started" questions and hopefully quicker turnaround than
StackOverflow or mailing lists.
Thanks,
Eric
On Fri, Feb 21, 2025 at 7:18 AM James Daugherty
<jd...@jdresources.net.invalid> wrote:
> +1 to proposed users, commits, and notifications mailing lists.
>
> On Fri, Feb 21, 2025 at 5:27 AM Søren Berg Glasius <so...@glasius.dk>
> wrote:
>
> > +1 to proposed users, commits and notifications mailing lists
> >
> > I propose that grails@googlegroups.com should be decommissioned (or made
> > read only) with a final message encouraging members to join
> > users@grails.apache.org instead.
> >
> > Den fre. 21. feb. 2025 kl. 07.15 skrev Paul King <pa...@asert.com.au>:
> >
> > > Hi folks,
> > >
> > > Currently Grails has private and dev mailing lists created. Folks
> > > interested in the development of Grails should subscribe to the dev
> > > list. Folks on the PPMC (podling project management committee) should
> > > subscribe to the private list. Typically projects have additional
> > > lists.
> > >
> > > The most common one is "users" for users of Grails to ask questions.
> > >
> > > **It is recommended you have a users mailing list.**
> > >
> > > The next most common ones are commits/notifications. There are lots of
> > > potential sources of information that can provide insight into changes
> > > made in the project. The ASF strongly recommends that you send those
> > > to a mailing list. You will have numerous options to configure what
> > > goes where (it can be changed over time and you don't need to decide
> > > that now). For now you just need to decide if you want one or both of
> > > those lists. You can send some of the sources of notifications to the
> > > dev list but it can soon become swamped, so you'd typically only want
> > > a select subset to go there.
> > >
> > > Geb just has notifications. It sends a few select sources of info to
> > > geb-dev and everything else (includes commits, discussions, issues, GH
> > > action status, PR comments; about 100/month) goes to
> > > geb-notifications. The advantage of having one list is that there is
> > > just one place to look but there might be more noise if you are
> > > browsing through looking for something.
> > >
> > > Groovy has both commits (all commits/code changes from all repos;
> > > about 200/month) and notifications (PR status changes, issue tracking
> > > comments; 300+/month). The advantage of splitting the two is that if
> > > you are searching for a code change, commits is likely where you'll
> > > find luck. If you remember something someone said (maybe in an issue
> > > comment), notifications might be the better place to look. I encourage
> > > bigger projects to go down this path since you have a bit more
> > > flexibility, but I wouldn't call it a super strong preference.
> > >
> > > You could also go more fine grained and have "issues", "discussions"
> > > and so forth. I don't have a lot of experience with this approach.
> > > Some aspects would be simpler but if you can't remember where a
> > > discussion took place, as a discussion, in a mailing list, on an
> > > issue, a comment on a GitHub commit, etc, you might have more places
> > > to look.
> > >
> > > **It is recommended you have a commits mailing list.**
> > >
> > > **It is recommended have a notifications mailing list.**
> > >
> > > There are other possibilities, e.g. "security". For now you can just
> > > use "private" and if you end up responding to lots of security
> > > aspects, you can create a special one later.
> > >
> > > In terms of process, if you are happy with my suggestions, you can
> > > respond +1 to this whole email or +1 to the specific lists you are
> > > happy with. We should discuss as long as needed. After discussion dies
> > > down (or around 72 hrs have passed), if it looks like there is general
> > > consensus, I'll go ahead and create the lists. We should iterate if
> > > discussions head us in a slightly different direction.
> > >
> > > If it looks like we need any further clarity, I'll create a [VOTE]
> > > thread separate to this [DISCUSS] thread and we can vote and gain
> > > consensus that way. PPMC votes are binding but, as a general rule,
> > > you'd typically want to take votes from all community members into
> > > account in such discussions/votes.
> > >
> > > Cheers, Paul.
> > >
> >
> >
> > --
> >
> > Med venlig hilsen,
> > Søren Berg Glasius
> >
> > Hedevej 1, Gl. Rye, 8680 Ry
> > Mobile: +45 40 44 91 88
> > --- Press ESC once to quit - twice to save the changes.
> >
>
Re: [DISCUSS] Mailing list selection
Posted by James Daugherty <jd...@jdresources.net.INVALID>.
+1 to proposed users, commits, and notifications mailing lists.
On Fri, Feb 21, 2025 at 5:27 AM Søren Berg Glasius <so...@glasius.dk>
wrote:
> +1 to proposed users, commits and notifications mailing lists
>
> I propose that grails@googlegroups.com should be decommissioned (or made
> read only) with a final message encouraging members to join
> users@grails.apache.org instead.
>
> Den fre. 21. feb. 2025 kl. 07.15 skrev Paul King <pa...@asert.com.au>:
>
> > Hi folks,
> >
> > Currently Grails has private and dev mailing lists created. Folks
> > interested in the development of Grails should subscribe to the dev
> > list. Folks on the PPMC (podling project management committee) should
> > subscribe to the private list. Typically projects have additional
> > lists.
> >
> > The most common one is "users" for users of Grails to ask questions.
> >
> > **It is recommended you have a users mailing list.**
> >
> > The next most common ones are commits/notifications. There are lots of
> > potential sources of information that can provide insight into changes
> > made in the project. The ASF strongly recommends that you send those
> > to a mailing list. You will have numerous options to configure what
> > goes where (it can be changed over time and you don't need to decide
> > that now). For now you just need to decide if you want one or both of
> > those lists. You can send some of the sources of notifications to the
> > dev list but it can soon become swamped, so you'd typically only want
> > a select subset to go there.
> >
> > Geb just has notifications. It sends a few select sources of info to
> > geb-dev and everything else (includes commits, discussions, issues, GH
> > action status, PR comments; about 100/month) goes to
> > geb-notifications. The advantage of having one list is that there is
> > just one place to look but there might be more noise if you are
> > browsing through looking for something.
> >
> > Groovy has both commits (all commits/code changes from all repos;
> > about 200/month) and notifications (PR status changes, issue tracking
> > comments; 300+/month). The advantage of splitting the two is that if
> > you are searching for a code change, commits is likely where you'll
> > find luck. If you remember something someone said (maybe in an issue
> > comment), notifications might be the better place to look. I encourage
> > bigger projects to go down this path since you have a bit more
> > flexibility, but I wouldn't call it a super strong preference.
> >
> > You could also go more fine grained and have "issues", "discussions"
> > and so forth. I don't have a lot of experience with this approach.
> > Some aspects would be simpler but if you can't remember where a
> > discussion took place, as a discussion, in a mailing list, on an
> > issue, a comment on a GitHub commit, etc, you might have more places
> > to look.
> >
> > **It is recommended you have a commits mailing list.**
> >
> > **It is recommended have a notifications mailing list.**
> >
> > There are other possibilities, e.g. "security". For now you can just
> > use "private" and if you end up responding to lots of security
> > aspects, you can create a special one later.
> >
> > In terms of process, if you are happy with my suggestions, you can
> > respond +1 to this whole email or +1 to the specific lists you are
> > happy with. We should discuss as long as needed. After discussion dies
> > down (or around 72 hrs have passed), if it looks like there is general
> > consensus, I'll go ahead and create the lists. We should iterate if
> > discussions head us in a slightly different direction.
> >
> > If it looks like we need any further clarity, I'll create a [VOTE]
> > thread separate to this [DISCUSS] thread and we can vote and gain
> > consensus that way. PPMC votes are binding but, as a general rule,
> > you'd typically want to take votes from all community members into
> > account in such discussions/votes.
> >
> > Cheers, Paul.
> >
>
>
> --
>
> Med venlig hilsen,
> Søren Berg Glasius
>
> Hedevej 1, Gl. Rye, 8680 Ry
> Mobile: +45 40 44 91 88
> --- Press ESC once to quit - twice to save the changes.
>
Re: [DISCUSS] Mailing list selection
Posted by Søren Berg Glasius <so...@glasius.dk>.
+1 to proposed users, commits and notifications mailing lists
I propose that grails@googlegroups.com should be decommissioned (or made
read only) with a final message encouraging members to join
users@grails.apache.org instead.
Den fre. 21. feb. 2025 kl. 07.15 skrev Paul King <pa...@asert.com.au>:
> Hi folks,
>
> Currently Grails has private and dev mailing lists created. Folks
> interested in the development of Grails should subscribe to the dev
> list. Folks on the PPMC (podling project management committee) should
> subscribe to the private list. Typically projects have additional
> lists.
>
> The most common one is "users" for users of Grails to ask questions.
>
> **It is recommended you have a users mailing list.**
>
> The next most common ones are commits/notifications. There are lots of
> potential sources of information that can provide insight into changes
> made in the project. The ASF strongly recommends that you send those
> to a mailing list. You will have numerous options to configure what
> goes where (it can be changed over time and you don't need to decide
> that now). For now you just need to decide if you want one or both of
> those lists. You can send some of the sources of notifications to the
> dev list but it can soon become swamped, so you'd typically only want
> a select subset to go there.
>
> Geb just has notifications. It sends a few select sources of info to
> geb-dev and everything else (includes commits, discussions, issues, GH
> action status, PR comments; about 100/month) goes to
> geb-notifications. The advantage of having one list is that there is
> just one place to look but there might be more noise if you are
> browsing through looking for something.
>
> Groovy has both commits (all commits/code changes from all repos;
> about 200/month) and notifications (PR status changes, issue tracking
> comments; 300+/month). The advantage of splitting the two is that if
> you are searching for a code change, commits is likely where you'll
> find luck. If you remember something someone said (maybe in an issue
> comment), notifications might be the better place to look. I encourage
> bigger projects to go down this path since you have a bit more
> flexibility, but I wouldn't call it a super strong preference.
>
> You could also go more fine grained and have "issues", "discussions"
> and so forth. I don't have a lot of experience with this approach.
> Some aspects would be simpler but if you can't remember where a
> discussion took place, as a discussion, in a mailing list, on an
> issue, a comment on a GitHub commit, etc, you might have more places
> to look.
>
> **It is recommended you have a commits mailing list.**
>
> **It is recommended have a notifications mailing list.**
>
> There are other possibilities, e.g. "security". For now you can just
> use "private" and if you end up responding to lots of security
> aspects, you can create a special one later.
>
> In terms of process, if you are happy with my suggestions, you can
> respond +1 to this whole email or +1 to the specific lists you are
> happy with. We should discuss as long as needed. After discussion dies
> down (or around 72 hrs have passed), if it looks like there is general
> consensus, I'll go ahead and create the lists. We should iterate if
> discussions head us in a slightly different direction.
>
> If it looks like we need any further clarity, I'll create a [VOTE]
> thread separate to this [DISCUSS] thread and we can vote and gain
> consensus that way. PPMC votes are binding but, as a general rule,
> you'd typically want to take votes from all community members into
> account in such discussions/votes.
>
> Cheers, Paul.
>
--
Med venlig hilsen,
Søren Berg Glasius
Hedevej 1, Gl. Rye, 8680 Ry
Mobile: +45 40 44 91 88
--- Press ESC once to quit - twice to save the changes.
Re: [DISCUSS] Mailing list selection
Posted by Mattias Reichel <ma...@apache.org>.
+1 to proposed users, commits and notifications mailing lists
On 2025/02/21 06:14:04 Paul King wrote:
> Hi folks,
>
> Currently Grails has private and dev mailing lists created. Folks
> interested in the development of Grails should subscribe to the dev
> list. Folks on the PPMC (podling project management committee) should
> subscribe to the private list. Typically projects have additional
> lists.
>
> The most common one is "users" for users of Grails to ask questions.
>
> **It is recommended you have a users mailing list.**
>
> The next most common ones are commits/notifications. There are lots of
> potential sources of information that can provide insight into changes
> made in the project. The ASF strongly recommends that you send those
> to a mailing list. You will have numerous options to configure what
> goes where (it can be changed over time and you don't need to decide
> that now). For now you just need to decide if you want one or both of
> those lists. You can send some of the sources of notifications to the
> dev list but it can soon become swamped, so you'd typically only want
> a select subset to go there.
>
> Geb just has notifications. It sends a few select sources of info to
> geb-dev and everything else (includes commits, discussions, issues, GH
> action status, PR comments; about 100/month) goes to
> geb-notifications. The advantage of having one list is that there is
> just one place to look but there might be more noise if you are
> browsing through looking for something.
>
> Groovy has both commits (all commits/code changes from all repos;
> about 200/month) and notifications (PR status changes, issue tracking
> comments; 300+/month). The advantage of splitting the two is that if
> you are searching for a code change, commits is likely where you'll
> find luck. If you remember something someone said (maybe in an issue
> comment), notifications might be the better place to look. I encourage
> bigger projects to go down this path since you have a bit more
> flexibility, but I wouldn't call it a super strong preference.
>
> You could also go more fine grained and have "issues", "discussions"
> and so forth. I don't have a lot of experience with this approach.
> Some aspects would be simpler but if you can't remember where a
> discussion took place, as a discussion, in a mailing list, on an
> issue, a comment on a GitHub commit, etc, you might have more places
> to look.
>
> **It is recommended you have a commits mailing list.**
>
> **It is recommended have a notifications mailing list.**
>
> There are other possibilities, e.g. "security". For now you can just
> use "private" and if you end up responding to lots of security
> aspects, you can create a special one later.
>
> In terms of process, if you are happy with my suggestions, you can
> respond +1 to this whole email or +1 to the specific lists you are
> happy with. We should discuss as long as needed. After discussion dies
> down (or around 72 hrs have passed), if it looks like there is general
> consensus, I'll go ahead and create the lists. We should iterate if
> discussions head us in a slightly different direction.
>
> If it looks like we need any further clarity, I'll create a [VOTE]
> thread separate to this [DISCUSS] thread and we can vote and gain
> consensus that way. PPMC votes are binding but, as a general rule,
> you'd typically want to take votes from all community members into
> account in such discussions/votes.
>
> Cheers, Paul.
>
Re: Publishing combined grails-forge CLI and grails-shell CLI graalvm native binaries
Posted by James Fredley <ja...@apache.org>.
Actually it is the flip, building the grails-shell CLI from the grails-forge CLI project.
On 2025/02/25 16:39:32 James Fredley wrote:
> https://github.com/grails/grails-forge/issues/496
>
> For this issue I need input on the right way to approach building the grails-forge CLI from the grails-shell CLI project and including it in the graalvm native binaries. My experience is limited in these areas and if I can get a running head start, it would save a lot time.
>
Publishing combined grails-forge CLI and grails-shell CLI graalvm native binaries
Posted by James Fredley <ja...@apache.org>.
https://github.com/grails/grails-forge/issues/496
For this issue I need input on the right way to approach building the grails-forge CLI from the grails-shell CLI project and including it in the graalvm native binaries. My experience is limited in these areas and if I can get a running head start, it would save a lot time.
Re: [DISCUSS] Mailing list selection
Posted by Paul King <pa...@asert.com.au>.
Added.
----
How Søren and I can manage now and your PMC members will manage
mailing lists later:
You can find members of project and their email addresses from whimsy, e.g.:
https://whimsy.apache.org/roster/ppmc/grails (ppmc will change to pmc
upon graduation)
https://whimsy.apache.org/roster/committer/jamesfredley
You can manage mailing lists with webmod, the easiest way to find is
through selfserve:
https://selfserve.apache.org/ has links to:
* Create a mailing list
* Manage mailing lists (takes you to https://webmod.apache.org/)
Both selfserve and whimsy are links under "Resources & Tools" on the
main www.apache.org page.
Info for this was from:
https://infra.apache.org/mailing-list-moderation.html
(You can get to that via "Developer Information" also under "Resources
& Tools" and then "mailing lists")
On Wed, Feb 26, 2025 at 1:26 AM James Fredley <ja...@apache.org> wrote:
>
> You can add me to the moderators list.
>
> James
>
> On 2025/02/24 23:58:20 Paul King wrote:
> > I created (still pending with a 12-24 hr delay) the lists with the
> > default list behavior which lets subscribers post but others are
> > moderated.
> >
> > It would be good to have a few PPMC folks to help moderate the list.
> > Let me know if you are happy to help and I'll add you.
> >
> > What's involved? Emails from non-subscribers go to moderators. There
> > is a link to accept, another to reject. There is an optional place to
> > give a reason but it's rarely used since most rejections are spam
> > bots. If you see a legitimate email, just click accept and it will
> > appear on the list. You can hit reject on spam but it will just sit in
> > a queue and eventually time out if you ignore it (i.e., no need to
> > worry if it ends up in your spam folder and you ignore it).
> >
> > Paul.
> >
> > On Tue, Feb 25, 2025 at 9:41 AM Paul King <pa...@asert.com.au> wrote:
> > >
> > > It looks like there is consensus, so I'll go ahead and create those lists.
> > >
> > > Does someone want to create an issue to make the old lists read-only
> > > once the new lists are up and running? At least for users.
> > >
> > > On Fri, Feb 21, 2025 at 4:14 PM Paul King <pa...@asert.com.au> wrote:
> > > >
> > > > Hi folks,
> > > >
> > > > Currently Grails has private and dev mailing lists created. Folks
> > > > interested in the development of Grails should subscribe to the dev
> > > > list. Folks on the PPMC (podling project management committee) should
> > > > subscribe to the private list. Typically projects have additional
> > > > lists.
> > > >
> > > > The most common one is "users" for users of Grails to ask questions.
> > > >
> > > > **It is recommended you have a users mailing list.**
> > > >
> > > > The next most common ones are commits/notifications. There are lots of
> > > > potential sources of information that can provide insight into changes
> > > > made in the project. The ASF strongly recommends that you send those
> > > > to a mailing list. You will have numerous options to configure what
> > > > goes where (it can be changed over time and you don't need to decide
> > > > that now). For now you just need to decide if you want one or both of
> > > > those lists. You can send some of the sources of notifications to the
> > > > dev list but it can soon become swamped, so you'd typically only want
> > > > a select subset to go there.
> > > >
> > > > Geb just has notifications. It sends a few select sources of info to
> > > > geb-dev and everything else (includes commits, discussions, issues, GH
> > > > action status, PR comments; about 100/month) goes to
> > > > geb-notifications. The advantage of having one list is that there is
> > > > just one place to look but there might be more noise if you are
> > > > browsing through looking for something.
> > > >
> > > > Groovy has both commits (all commits/code changes from all repos;
> > > > about 200/month) and notifications (PR status changes, issue tracking
> > > > comments; 300+/month). The advantage of splitting the two is that if
> > > > you are searching for a code change, commits is likely where you'll
> > > > find luck. If you remember something someone said (maybe in an issue
> > > > comment), notifications might be the better place to look. I encourage
> > > > bigger projects to go down this path since you have a bit more
> > > > flexibility, but I wouldn't call it a super strong preference.
> > > >
> > > > You could also go more fine grained and have "issues", "discussions"
> > > > and so forth. I don't have a lot of experience with this approach.
> > > > Some aspects would be simpler but if you can't remember where a
> > > > discussion took place, as a discussion, in a mailing list, on an
> > > > issue, a comment on a GitHub commit, etc, you might have more places
> > > > to look.
> > > >
> > > > **It is recommended you have a commits mailing list.**
> > > >
> > > > **It is recommended have a notifications mailing list.**
> > > >
> > > > There are other possibilities, e.g. "security". For now you can just
> > > > use "private" and if you end up responding to lots of security
> > > > aspects, you can create a special one later.
> > > >
> > > > In terms of process, if you are happy with my suggestions, you can
> > > > respond +1 to this whole email or +1 to the specific lists you are
> > > > happy with. We should discuss as long as needed. After discussion dies
> > > > down (or around 72 hrs have passed), if it looks like there is general
> > > > consensus, I'll go ahead and create the lists. We should iterate if
> > > > discussions head us in a slightly different direction.
> > > >
> > > > If it looks like we need any further clarity, I'll create a [VOTE]
> > > > thread separate to this [DISCUSS] thread and we can vote and gain
> > > > consensus that way. PPMC votes are binding but, as a general rule,
> > > > you'd typically want to take votes from all community members into
> > > > account in such discussions/votes.
> > > >
> > > > Cheers, Paul.
> >
Re: [DISCUSS] Mailing list selection
Posted by James Fredley <ja...@apache.org>.
You can add me to the moderators list.
James
On 2025/02/24 23:58:20 Paul King wrote:
> I created (still pending with a 12-24 hr delay) the lists with the
> default list behavior which lets subscribers post but others are
> moderated.
>
> It would be good to have a few PPMC folks to help moderate the list.
> Let me know if you are happy to help and I'll add you.
>
> What's involved? Emails from non-subscribers go to moderators. There
> is a link to accept, another to reject. There is an optional place to
> give a reason but it's rarely used since most rejections are spam
> bots. If you see a legitimate email, just click accept and it will
> appear on the list. You can hit reject on spam but it will just sit in
> a queue and eventually time out if you ignore it (i.e., no need to
> worry if it ends up in your spam folder and you ignore it).
>
> Paul.
>
> On Tue, Feb 25, 2025 at 9:41 AM Paul King <pa...@asert.com.au> wrote:
> >
> > It looks like there is consensus, so I'll go ahead and create those lists.
> >
> > Does someone want to create an issue to make the old lists read-only
> > once the new lists are up and running? At least for users.
> >
> > On Fri, Feb 21, 2025 at 4:14 PM Paul King <pa...@asert.com.au> wrote:
> > >
> > > Hi folks,
> > >
> > > Currently Grails has private and dev mailing lists created. Folks
> > > interested in the development of Grails should subscribe to the dev
> > > list. Folks on the PPMC (podling project management committee) should
> > > subscribe to the private list. Typically projects have additional
> > > lists.
> > >
> > > The most common one is "users" for users of Grails to ask questions.
> > >
> > > **It is recommended you have a users mailing list.**
> > >
> > > The next most common ones are commits/notifications. There are lots of
> > > potential sources of information that can provide insight into changes
> > > made in the project. The ASF strongly recommends that you send those
> > > to a mailing list. You will have numerous options to configure what
> > > goes where (it can be changed over time and you don't need to decide
> > > that now). For now you just need to decide if you want one or both of
> > > those lists. You can send some of the sources of notifications to the
> > > dev list but it can soon become swamped, so you'd typically only want
> > > a select subset to go there.
> > >
> > > Geb just has notifications. It sends a few select sources of info to
> > > geb-dev and everything else (includes commits, discussions, issues, GH
> > > action status, PR comments; about 100/month) goes to
> > > geb-notifications. The advantage of having one list is that there is
> > > just one place to look but there might be more noise if you are
> > > browsing through looking for something.
> > >
> > > Groovy has both commits (all commits/code changes from all repos;
> > > about 200/month) and notifications (PR status changes, issue tracking
> > > comments; 300+/month). The advantage of splitting the two is that if
> > > you are searching for a code change, commits is likely where you'll
> > > find luck. If you remember something someone said (maybe in an issue
> > > comment), notifications might be the better place to look. I encourage
> > > bigger projects to go down this path since you have a bit more
> > > flexibility, but I wouldn't call it a super strong preference.
> > >
> > > You could also go more fine grained and have "issues", "discussions"
> > > and so forth. I don't have a lot of experience with this approach.
> > > Some aspects would be simpler but if you can't remember where a
> > > discussion took place, as a discussion, in a mailing list, on an
> > > issue, a comment on a GitHub commit, etc, you might have more places
> > > to look.
> > >
> > > **It is recommended you have a commits mailing list.**
> > >
> > > **It is recommended have a notifications mailing list.**
> > >
> > > There are other possibilities, e.g. "security". For now you can just
> > > use "private" and if you end up responding to lots of security
> > > aspects, you can create a special one later.
> > >
> > > In terms of process, if you are happy with my suggestions, you can
> > > respond +1 to this whole email or +1 to the specific lists you are
> > > happy with. We should discuss as long as needed. After discussion dies
> > > down (or around 72 hrs have passed), if it looks like there is general
> > > consensus, I'll go ahead and create the lists. We should iterate if
> > > discussions head us in a slightly different direction.
> > >
> > > If it looks like we need any further clarity, I'll create a [VOTE]
> > > thread separate to this [DISCUSS] thread and we can vote and gain
> > > consensus that way. PPMC votes are binding but, as a general rule,
> > > you'd typically want to take votes from all community members into
> > > account in such discussions/votes.
> > >
> > > Cheers, Paul.
>
Example of Apache release voting process with Groovy 4.0.26.
Posted by James Fredley <ja...@apache.org>.
Example of Apache release voting process with Groovy 4.0.26.
3 days min, unless there are pressing circumstances, such as security patches for an exploit.
https://lists.apache.org/thread/v31c42n66zkq9bo654bsw01xrf56nhby
Re: Add new Gradle DuplicatesStrategy.OVERWRITE strategy, which always results in the last file/entry copied to the destination
Posted by James Fredley <ja...@apache.org>.
https://github.com/gradle/gradle/issues/32558#issuecomment-2697007695
Update from Gradle team on this issue: "This issue needs a decision from the team responsible for that area. They have been informed. Response time may vary."
On 2025/02/26 22:38:26 James Fredley wrote:
> I submitted an issue (feature request) to add a new strategy to resolve duplicates consistently for zip/jar/war destinations: https://github.com/gradle/gradle/issues/32558
>
>
Add new Gradle DuplicatesStrategy.OVERWRITE strategy, which always results in the last file/entry copied to the destination
Posted by James Fredley <ja...@apache.org>.
I submitted an issue (feature request) to add a new strategy to resolve duplicates consistently for zip/jar/war destinations: https://github.com/gradle/gradle/issues/32558
Re: [DISCUSS] Mailing list selection
Posted by Mattias Reichel <ma...@gmail.com>.
>
> Does someone want to create an issue to make the old lists read-only
> once the new lists are up and running? At least for users.
>
> https://github.com/grails/grails-core/issues/14040
Den ons 26 feb. 2025 kl 21:56 skrev Paul King <pa...@asert.com.au>:
> Added.
>
> On Thu, Feb 27, 2025 at 5:44 AM Mattias Reichel <ma...@apache.org> wrote:
> >
> > I can be a moderator on the users list 🙋
> >
> > On 2025/02/24 23:58:20 Paul King wrote:
> > > I created (still pending with a 12-24 hr delay) the lists with the
> > > default list behavior which lets subscribers post but others are
> > > moderated.
> > >
> > > It would be good to have a few PPMC folks to help moderate the list.
> > > Let me know if you are happy to help and I'll add you.
> > >
> > > What's involved? Emails from non-subscribers go to moderators. There
> > > is a link to accept, another to reject. There is an optional place to
> > > give a reason but it's rarely used since most rejections are spam
> > > bots. If you see a legitimate email, just click accept and it will
> > > appear on the list. You can hit reject on spam but it will just sit in
> > > a queue and eventually time out if you ignore it (i.e., no need to
> > > worry if it ends up in your spam folder and you ignore it).
> > >
> > > Paul.
> > >
> > > On Tue, Feb 25, 2025 at 9:41 AM Paul King <pa...@asert.com.au> wrote:
> > > >
> > > > It looks like there is consensus, so I'll go ahead and create those
> lists.
> > > >
> > > > Does someone want to create an issue to make the old lists read-only
> > > > once the new lists are up and running? At least for users.
> > > >
> > > > On Fri, Feb 21, 2025 at 4:14 PM Paul King <pa...@asert.com.au>
> wrote:
> > > > >
> > > > > Hi folks,
> > > > >
> > > > > Currently Grails has private and dev mailing lists created. Folks
> > > > > interested in the development of Grails should subscribe to the dev
> > > > > list. Folks on the PPMC (podling project management committee)
> should
> > > > > subscribe to the private list. Typically projects have additional
> > > > > lists.
> > > > >
> > > > > The most common one is "users" for users of Grails to ask
> questions.
> > > > >
> > > > > **It is recommended you have a users mailing list.**
> > > > >
> > > > > The next most common ones are commits/notifications. There are
> lots of
> > > > > potential sources of information that can provide insight into
> changes
> > > > > made in the project. The ASF strongly recommends that you send
> those
> > > > > to a mailing list. You will have numerous options to configure what
> > > > > goes where (it can be changed over time and you don't need to
> decide
> > > > > that now). For now you just need to decide if you want one or both
> of
> > > > > those lists. You can send some of the sources of notifications to
> the
> > > > > dev list but it can soon become swamped, so you'd typically only
> want
> > > > > a select subset to go there.
> > > > >
> > > > > Geb just has notifications. It sends a few select sources of info
> to
> > > > > geb-dev and everything else (includes commits, discussions,
> issues, GH
> > > > > action status, PR comments; about 100/month) goes to
> > > > > geb-notifications. The advantage of having one list is that there
> is
> > > > > just one place to look but there might be more noise if you are
> > > > > browsing through looking for something.
> > > > >
> > > > > Groovy has both commits (all commits/code changes from all repos;
> > > > > about 200/month) and notifications (PR status changes, issue
> tracking
> > > > > comments; 300+/month). The advantage of splitting the two is that
> if
> > > > > you are searching for a code change, commits is likely where you'll
> > > > > find luck. If you remember something someone said (maybe in an
> issue
> > > > > comment), notifications might be the better place to look. I
> encourage
> > > > > bigger projects to go down this path since you have a bit more
> > > > > flexibility, but I wouldn't call it a super strong preference.
> > > > >
> > > > > You could also go more fine grained and have "issues",
> "discussions"
> > > > > and so forth. I don't have a lot of experience with this approach.
> > > > > Some aspects would be simpler but if you can't remember where a
> > > > > discussion took place, as a discussion, in a mailing list, on an
> > > > > issue, a comment on a GitHub commit, etc, you might have more
> places
> > > > > to look.
> > > > >
> > > > > **It is recommended you have a commits mailing list.**
> > > > >
> > > > > **It is recommended have a notifications mailing list.**
> > > > >
> > > > > There are other possibilities, e.g. "security". For now you can
> just
> > > > > use "private" and if you end up responding to lots of security
> > > > > aspects, you can create a special one later.
> > > > >
> > > > > In terms of process, if you are happy with my suggestions, you can
> > > > > respond +1 to this whole email or +1 to the specific lists you are
> > > > > happy with. We should discuss as long as needed. After discussion
> dies
> > > > > down (or around 72 hrs have passed), if it looks like there is
> general
> > > > > consensus, I'll go ahead and create the lists. We should iterate if
> > > > > discussions head us in a slightly different direction.
> > > > >
> > > > > If it looks like we need any further clarity, I'll create a [VOTE]
> > > > > thread separate to this [DISCUSS] thread and we can vote and gain
> > > > > consensus that way. PPMC votes are binding but, as a general rule,
> > > > > you'd typically want to take votes from all community members into
> > > > > account in such discussions/votes.
> > > > >
> > > > > Cheers, Paul.
> > >
>
Re: [DISCUSS] Mailing list selection
Posted by Paul King <pa...@asert.com.au>.
Added.
On Thu, Feb 27, 2025 at 5:44 AM Mattias Reichel <ma...@apache.org> wrote:
>
> I can be a moderator on the users list 🙋
>
> On 2025/02/24 23:58:20 Paul King wrote:
> > I created (still pending with a 12-24 hr delay) the lists with the
> > default list behavior which lets subscribers post but others are
> > moderated.
> >
> > It would be good to have a few PPMC folks to help moderate the list.
> > Let me know if you are happy to help and I'll add you.
> >
> > What's involved? Emails from non-subscribers go to moderators. There
> > is a link to accept, another to reject. There is an optional place to
> > give a reason but it's rarely used since most rejections are spam
> > bots. If you see a legitimate email, just click accept and it will
> > appear on the list. You can hit reject on spam but it will just sit in
> > a queue and eventually time out if you ignore it (i.e., no need to
> > worry if it ends up in your spam folder and you ignore it).
> >
> > Paul.
> >
> > On Tue, Feb 25, 2025 at 9:41 AM Paul King <pa...@asert.com.au> wrote:
> > >
> > > It looks like there is consensus, so I'll go ahead and create those lists.
> > >
> > > Does someone want to create an issue to make the old lists read-only
> > > once the new lists are up and running? At least for users.
> > >
> > > On Fri, Feb 21, 2025 at 4:14 PM Paul King <pa...@asert.com.au> wrote:
> > > >
> > > > Hi folks,
> > > >
> > > > Currently Grails has private and dev mailing lists created. Folks
> > > > interested in the development of Grails should subscribe to the dev
> > > > list. Folks on the PPMC (podling project management committee) should
> > > > subscribe to the private list. Typically projects have additional
> > > > lists.
> > > >
> > > > The most common one is "users" for users of Grails to ask questions.
> > > >
> > > > **It is recommended you have a users mailing list.**
> > > >
> > > > The next most common ones are commits/notifications. There are lots of
> > > > potential sources of information that can provide insight into changes
> > > > made in the project. The ASF strongly recommends that you send those
> > > > to a mailing list. You will have numerous options to configure what
> > > > goes where (it can be changed over time and you don't need to decide
> > > > that now). For now you just need to decide if you want one or both of
> > > > those lists. You can send some of the sources of notifications to the
> > > > dev list but it can soon become swamped, so you'd typically only want
> > > > a select subset to go there.
> > > >
> > > > Geb just has notifications. It sends a few select sources of info to
> > > > geb-dev and everything else (includes commits, discussions, issues, GH
> > > > action status, PR comments; about 100/month) goes to
> > > > geb-notifications. The advantage of having one list is that there is
> > > > just one place to look but there might be more noise if you are
> > > > browsing through looking for something.
> > > >
> > > > Groovy has both commits (all commits/code changes from all repos;
> > > > about 200/month) and notifications (PR status changes, issue tracking
> > > > comments; 300+/month). The advantage of splitting the two is that if
> > > > you are searching for a code change, commits is likely where you'll
> > > > find luck. If you remember something someone said (maybe in an issue
> > > > comment), notifications might be the better place to look. I encourage
> > > > bigger projects to go down this path since you have a bit more
> > > > flexibility, but I wouldn't call it a super strong preference.
> > > >
> > > > You could also go more fine grained and have "issues", "discussions"
> > > > and so forth. I don't have a lot of experience with this approach.
> > > > Some aspects would be simpler but if you can't remember where a
> > > > discussion took place, as a discussion, in a mailing list, on an
> > > > issue, a comment on a GitHub commit, etc, you might have more places
> > > > to look.
> > > >
> > > > **It is recommended you have a commits mailing list.**
> > > >
> > > > **It is recommended have a notifications mailing list.**
> > > >
> > > > There are other possibilities, e.g. "security". For now you can just
> > > > use "private" and if you end up responding to lots of security
> > > > aspects, you can create a special one later.
> > > >
> > > > In terms of process, if you are happy with my suggestions, you can
> > > > respond +1 to this whole email or +1 to the specific lists you are
> > > > happy with. We should discuss as long as needed. After discussion dies
> > > > down (or around 72 hrs have passed), if it looks like there is general
> > > > consensus, I'll go ahead and create the lists. We should iterate if
> > > > discussions head us in a slightly different direction.
> > > >
> > > > If it looks like we need any further clarity, I'll create a [VOTE]
> > > > thread separate to this [DISCUSS] thread and we can vote and gain
> > > > consensus that way. PPMC votes are binding but, as a general rule,
> > > > you'd typically want to take votes from all community members into
> > > > account in such discussions/votes.
> > > >
> > > > Cheers, Paul.
> >
Re: [DISCUSS] Mailing list selection
Posted by Mattias Reichel <ma...@apache.org>.
I can be a moderator on the users list 🙋
On 2025/02/24 23:58:20 Paul King wrote:
> I created (still pending with a 12-24 hr delay) the lists with the
> default list behavior which lets subscribers post but others are
> moderated.
>
> It would be good to have a few PPMC folks to help moderate the list.
> Let me know if you are happy to help and I'll add you.
>
> What's involved? Emails from non-subscribers go to moderators. There
> is a link to accept, another to reject. There is an optional place to
> give a reason but it's rarely used since most rejections are spam
> bots. If you see a legitimate email, just click accept and it will
> appear on the list. You can hit reject on spam but it will just sit in
> a queue and eventually time out if you ignore it (i.e., no need to
> worry if it ends up in your spam folder and you ignore it).
>
> Paul.
>
> On Tue, Feb 25, 2025 at 9:41 AM Paul King <pa...@asert.com.au> wrote:
> >
> > It looks like there is consensus, so I'll go ahead and create those lists.
> >
> > Does someone want to create an issue to make the old lists read-only
> > once the new lists are up and running? At least for users.
> >
> > On Fri, Feb 21, 2025 at 4:14 PM Paul King <pa...@asert.com.au> wrote:
> > >
> > > Hi folks,
> > >
> > > Currently Grails has private and dev mailing lists created. Folks
> > > interested in the development of Grails should subscribe to the dev
> > > list. Folks on the PPMC (podling project management committee) should
> > > subscribe to the private list. Typically projects have additional
> > > lists.
> > >
> > > The most common one is "users" for users of Grails to ask questions.
> > >
> > > **It is recommended you have a users mailing list.**
> > >
> > > The next most common ones are commits/notifications. There are lots of
> > > potential sources of information that can provide insight into changes
> > > made in the project. The ASF strongly recommends that you send those
> > > to a mailing list. You will have numerous options to configure what
> > > goes where (it can be changed over time and you don't need to decide
> > > that now). For now you just need to decide if you want one or both of
> > > those lists. You can send some of the sources of notifications to the
> > > dev list but it can soon become swamped, so you'd typically only want
> > > a select subset to go there.
> > >
> > > Geb just has notifications. It sends a few select sources of info to
> > > geb-dev and everything else (includes commits, discussions, issues, GH
> > > action status, PR comments; about 100/month) goes to
> > > geb-notifications. The advantage of having one list is that there is
> > > just one place to look but there might be more noise if you are
> > > browsing through looking for something.
> > >
> > > Groovy has both commits (all commits/code changes from all repos;
> > > about 200/month) and notifications (PR status changes, issue tracking
> > > comments; 300+/month). The advantage of splitting the two is that if
> > > you are searching for a code change, commits is likely where you'll
> > > find luck. If you remember something someone said (maybe in an issue
> > > comment), notifications might be the better place to look. I encourage
> > > bigger projects to go down this path since you have a bit more
> > > flexibility, but I wouldn't call it a super strong preference.
> > >
> > > You could also go more fine grained and have "issues", "discussions"
> > > and so forth. I don't have a lot of experience with this approach.
> > > Some aspects would be simpler but if you can't remember where a
> > > discussion took place, as a discussion, in a mailing list, on an
> > > issue, a comment on a GitHub commit, etc, you might have more places
> > > to look.
> > >
> > > **It is recommended you have a commits mailing list.**
> > >
> > > **It is recommended have a notifications mailing list.**
> > >
> > > There are other possibilities, e.g. "security". For now you can just
> > > use "private" and if you end up responding to lots of security
> > > aspects, you can create a special one later.
> > >
> > > In terms of process, if you are happy with my suggestions, you can
> > > respond +1 to this whole email or +1 to the specific lists you are
> > > happy with. We should discuss as long as needed. After discussion dies
> > > down (or around 72 hrs have passed), if it looks like there is general
> > > consensus, I'll go ahead and create the lists. We should iterate if
> > > discussions head us in a slightly different direction.
> > >
> > > If it looks like we need any further clarity, I'll create a [VOTE]
> > > thread separate to this [DISCUSS] thread and we can vote and gain
> > > consensus that way. PPMC votes are binding but, as a general rule,
> > > you'd typically want to take votes from all community members into
> > > account in such discussions/votes.
> > >
> > > Cheers, Paul.
>
Re: [DISCUSS] Mailing list selection
Posted by Paul King <pa...@asert.com.au>.
I created (still pending with a 12-24 hr delay) the lists with the
default list behavior which lets subscribers post but others are
moderated.
It would be good to have a few PPMC folks to help moderate the list.
Let me know if you are happy to help and I'll add you.
What's involved? Emails from non-subscribers go to moderators. There
is a link to accept, another to reject. There is an optional place to
give a reason but it's rarely used since most rejections are spam
bots. If you see a legitimate email, just click accept and it will
appear on the list. You can hit reject on spam but it will just sit in
a queue and eventually time out if you ignore it (i.e., no need to
worry if it ends up in your spam folder and you ignore it).
Paul.
On Tue, Feb 25, 2025 at 9:41 AM Paul King <pa...@asert.com.au> wrote:
>
> It looks like there is consensus, so I'll go ahead and create those lists.
>
> Does someone want to create an issue to make the old lists read-only
> once the new lists are up and running? At least for users.
>
> On Fri, Feb 21, 2025 at 4:14 PM Paul King <pa...@asert.com.au> wrote:
> >
> > Hi folks,
> >
> > Currently Grails has private and dev mailing lists created. Folks
> > interested in the development of Grails should subscribe to the dev
> > list. Folks on the PPMC (podling project management committee) should
> > subscribe to the private list. Typically projects have additional
> > lists.
> >
> > The most common one is "users" for users of Grails to ask questions.
> >
> > **It is recommended you have a users mailing list.**
> >
> > The next most common ones are commits/notifications. There are lots of
> > potential sources of information that can provide insight into changes
> > made in the project. The ASF strongly recommends that you send those
> > to a mailing list. You will have numerous options to configure what
> > goes where (it can be changed over time and you don't need to decide
> > that now). For now you just need to decide if you want one or both of
> > those lists. You can send some of the sources of notifications to the
> > dev list but it can soon become swamped, so you'd typically only want
> > a select subset to go there.
> >
> > Geb just has notifications. It sends a few select sources of info to
> > geb-dev and everything else (includes commits, discussions, issues, GH
> > action status, PR comments; about 100/month) goes to
> > geb-notifications. The advantage of having one list is that there is
> > just one place to look but there might be more noise if you are
> > browsing through looking for something.
> >
> > Groovy has both commits (all commits/code changes from all repos;
> > about 200/month) and notifications (PR status changes, issue tracking
> > comments; 300+/month). The advantage of splitting the two is that if
> > you are searching for a code change, commits is likely where you'll
> > find luck. If you remember something someone said (maybe in an issue
> > comment), notifications might be the better place to look. I encourage
> > bigger projects to go down this path since you have a bit more
> > flexibility, but I wouldn't call it a super strong preference.
> >
> > You could also go more fine grained and have "issues", "discussions"
> > and so forth. I don't have a lot of experience with this approach.
> > Some aspects would be simpler but if you can't remember where a
> > discussion took place, as a discussion, in a mailing list, on an
> > issue, a comment on a GitHub commit, etc, you might have more places
> > to look.
> >
> > **It is recommended you have a commits mailing list.**
> >
> > **It is recommended have a notifications mailing list.**
> >
> > There are other possibilities, e.g. "security". For now you can just
> > use "private" and if you end up responding to lots of security
> > aspects, you can create a special one later.
> >
> > In terms of process, if you are happy with my suggestions, you can
> > respond +1 to this whole email or +1 to the specific lists you are
> > happy with. We should discuss as long as needed. After discussion dies
> > down (or around 72 hrs have passed), if it looks like there is general
> > consensus, I'll go ahead and create the lists. We should iterate if
> > discussions head us in a slightly different direction.
> >
> > If it looks like we need any further clarity, I'll create a [VOTE]
> > thread separate to this [DISCUSS] thread and we can vote and gain
> > consensus that way. PPMC votes are binding but, as a general rule,
> > you'd typically want to take votes from all community members into
> > account in such discussions/votes.
> >
> > Cheers, Paul.
Re: [DISCUSS] Mailing list selection
Posted by Paul King <pa...@asert.com.au>.
It looks like there is consensus, so I'll go ahead and create those lists.
Does someone want to create an issue to make the old lists read-only
once the new lists are up and running? At least for users.
On Fri, Feb 21, 2025 at 4:14 PM Paul King <pa...@asert.com.au> wrote:
>
> Hi folks,
>
> Currently Grails has private and dev mailing lists created. Folks
> interested in the development of Grails should subscribe to the dev
> list. Folks on the PPMC (podling project management committee) should
> subscribe to the private list. Typically projects have additional
> lists.
>
> The most common one is "users" for users of Grails to ask questions.
>
> **It is recommended you have a users mailing list.**
>
> The next most common ones are commits/notifications. There are lots of
> potential sources of information that can provide insight into changes
> made in the project. The ASF strongly recommends that you send those
> to a mailing list. You will have numerous options to configure what
> goes where (it can be changed over time and you don't need to decide
> that now). For now you just need to decide if you want one or both of
> those lists. You can send some of the sources of notifications to the
> dev list but it can soon become swamped, so you'd typically only want
> a select subset to go there.
>
> Geb just has notifications. It sends a few select sources of info to
> geb-dev and everything else (includes commits, discussions, issues, GH
> action status, PR comments; about 100/month) goes to
> geb-notifications. The advantage of having one list is that there is
> just one place to look but there might be more noise if you are
> browsing through looking for something.
>
> Groovy has both commits (all commits/code changes from all repos;
> about 200/month) and notifications (PR status changes, issue tracking
> comments; 300+/month). The advantage of splitting the two is that if
> you are searching for a code change, commits is likely where you'll
> find luck. If you remember something someone said (maybe in an issue
> comment), notifications might be the better place to look. I encourage
> bigger projects to go down this path since you have a bit more
> flexibility, but I wouldn't call it a super strong preference.
>
> You could also go more fine grained and have "issues", "discussions"
> and so forth. I don't have a lot of experience with this approach.
> Some aspects would be simpler but if you can't remember where a
> discussion took place, as a discussion, in a mailing list, on an
> issue, a comment on a GitHub commit, etc, you might have more places
> to look.
>
> **It is recommended you have a commits mailing list.**
>
> **It is recommended have a notifications mailing list.**
>
> There are other possibilities, e.g. "security". For now you can just
> use "private" and if you end up responding to lots of security
> aspects, you can create a special one later.
>
> In terms of process, if you are happy with my suggestions, you can
> respond +1 to this whole email or +1 to the specific lists you are
> happy with. We should discuss as long as needed. After discussion dies
> down (or around 72 hrs have passed), if it looks like there is general
> consensus, I'll go ahead and create the lists. We should iterate if
> discussions head us in a slightly different direction.
>
> If it looks like we need any further clarity, I'll create a [VOTE]
> thread separate to this [DISCUSS] thread and we can vote and gain
> consensus that way. PPMC votes are binding but, as a general rule,
> you'd typically want to take votes from all community members into
> account in such discussions/votes.
>
> Cheers, Paul.
Re: [DISCUSS] Mailing list selection
Posted by James Fredley <ja...@apache.org>.
+1 to proposed users, commits and notifications mailing lists
And I agree with Soren that we send details to the Google groups directing subscribers on how to join the Apache Grails mailing lists.
On 2025/02/21 06:14:04 Paul King wrote:
> Hi folks,
>
> Currently Grails has private and dev mailing lists created. Folks
> interested in the development of Grails should subscribe to the dev
> list. Folks on the PPMC (podling project management committee) should
> subscribe to the private list. Typically projects have additional
> lists.
>
> The most common one is "users" for users of Grails to ask questions.
>
> **It is recommended you have a users mailing list.**
>
> The next most common ones are commits/notifications. There are lots of
> potential sources of information that can provide insight into changes
> made in the project. The ASF strongly recommends that you send those
> to a mailing list. You will have numerous options to configure what
> goes where (it can be changed over time and you don't need to decide
> that now). For now you just need to decide if you want one or both of
> those lists. You can send some of the sources of notifications to the
> dev list but it can soon become swamped, so you'd typically only want
> a select subset to go there.
>
> Geb just has notifications. It sends a few select sources of info to
> geb-dev and everything else (includes commits, discussions, issues, GH
> action status, PR comments; about 100/month) goes to
> geb-notifications. The advantage of having one list is that there is
> just one place to look but there might be more noise if you are
> browsing through looking for something.
>
> Groovy has both commits (all commits/code changes from all repos;
> about 200/month) and notifications (PR status changes, issue tracking
> comments; 300+/month). The advantage of splitting the two is that if
> you are searching for a code change, commits is likely where you'll
> find luck. If you remember something someone said (maybe in an issue
> comment), notifications might be the better place to look. I encourage
> bigger projects to go down this path since you have a bit more
> flexibility, but I wouldn't call it a super strong preference.
>
> You could also go more fine grained and have "issues", "discussions"
> and so forth. I don't have a lot of experience with this approach.
> Some aspects would be simpler but if you can't remember where a
> discussion took place, as a discussion, in a mailing list, on an
> issue, a comment on a GitHub commit, etc, you might have more places
> to look.
>
> **It is recommended you have a commits mailing list.**
>
> **It is recommended have a notifications mailing list.**
>
> There are other possibilities, e.g. "security". For now you can just
> use "private" and if you end up responding to lots of security
> aspects, you can create a special one later.
>
> In terms of process, if you are happy with my suggestions, you can
> respond +1 to this whole email or +1 to the specific lists you are
> happy with. We should discuss as long as needed. After discussion dies
> down (or around 72 hrs have passed), if it looks like there is general
> consensus, I'll go ahead and create the lists. We should iterate if
> discussions head us in a slightly different direction.
>
> If it looks like we need any further clarity, I'll create a [VOTE]
> thread separate to this [DISCUSS] thread and we can vote and gain
> consensus that way. PPMC votes are binding but, as a general rule,
> you'd typically want to take votes from all community members into
> account in such discussions/votes.
>
> Cheers, Paul.
>