Request to be made maintainer of ant-plugin

69 views
Skip to first unread message

Jesse Glick

unread,
Aug 13, 2019, 12:17:07 PM8/13/19
to Jenkins Dev, armf...@gmail.com

Oleg Nenashev

unread,
Aug 16, 2019, 8:37:21 AM8/16/19
to Jenkins Developers
I am +1 about it.
Taking the state of the plugin, I would not expect any issues with the transfer. 
But we still need an approval

On Tuesday, August 13, 2019 at 6:17:07 PM UTC+2, Jesse Glick wrote:
See: https://github.com/jenkins-infra/repository-permissions-updater/pull/1240

Mark Waite

unread,
Aug 16, 2019, 9:13:14 AM8/16/19
to jenkinsci-dev
+1 from me as well.  I assume the approval that is needed is from the current maintainer, or we wait the two week expiration period.  Is that correct?

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/47f1a82a-512d-431d-9ce5-bb30b6fa82aa%40googlegroups.com.


--
Thanks!
Mark Waite

Jesse Glick

unread,
Aug 16, 2019, 10:37:58 AM8/16/19
to Jenkins Dev
On Fri, Aug 16, 2019 at 9:13 AM Mark Waite <mark.ea...@gmail.com> wrote:
> I assume the approval that is needed is from the current maintainer, or we wait the two week expiration period. Is that correct?

That is the rule, yes.

Oleg Nenashev

unread,
Aug 23, 2019, 4:05:03 AM8/23/19
to Jenkins Developers
Will transfer ownership on Aug 27 if there is no response from the maintainer

On Friday, August 16, 2019 at 4:37:58 PM UTC+2, Jesse Glick wrote:

Francisco Javier Fernandez

unread,
Aug 23, 2019, 5:25:40 AM8/23/19
to Jenkins Developers
I would be interested in becoming co-maintainer if possible

Jesse Glick

unread,
Aug 23, 2019, 1:21:22 PM8/23/19
to Jenkins Dev
On Fri, Aug 23, 2019 at 5:25 AM Francisco Javier Fernandez
<fjfer...@cloudbees.com> wrote:
> I would be interested in becoming co-maintainer if possible

+1 as far as I am concerned.

Oleg Nenashev

unread,
Aug 27, 2019, 8:54:04 AM8/27/19
to Jenkins Developers
Permissions have been transferred.
Jesse and Francisco, could you please agree about a default assignee for the component?

Jesse Glick

unread,
Aug 27, 2019, 9:14:52 AM8/27/19
to Jenkins Dev
On Tue, Aug 27, 2019 at 8:54 AM Oleg Nenashev <o.v.ne...@gmail.com> wrote:
> a default assignee for the component

As always, I prefer there to be no default assignee for a JIRA
component. It is not a helpful concept IMO. If and when I decide to
tackle an issue, I will assign it to myself.

Baptiste Mathus

unread,
Sep 5, 2019, 5:31:59 AM9/5/19
to Jenkins Developers
I fully agree with Jesse's take. IMO for most plugins where the maintainer is not going to have time to jump on new reports right away, this sends a wrong message that issues will be analyzed and fixed by the assignee.
This sends a second bad message: that an issue being already assigned, this is not necessary that someone steps up to work on a fix proposal.

AIUI, the default assignee is often used by maintainers as a nice way to be notified when a new issue arises, but on average not meaning that that given maintainer will commit to address in a timely manner anything new that comes in.

IOW, my main point is that I think we should allow maintainers to be made default assignee, but we should default to having no default assignee.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

Matt Sicker

unread,
Sep 5, 2019, 2:35:25 PM9/5/19
to jenkin...@googlegroups.com
That makes tons of sense to me. You should only assign tickets to
yourself that you're currently working on or at least intend to work
on in the near future.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS7J1661hacPVP9rMN5sK%2Bz_Hsos28Bd8N%2BNbxwxMouWNA%40mail.gmail.com.



--
Matt Sicker
Senior Software Engineer, CloudBees

Gavin

unread,
Sep 5, 2019, 2:36:42 PM9/5/19
to jenkin...@googlegroups.com
Does jira have a concept of auto watch like GitHub does? So an issue could still notify people but not be claimed?

Slide

unread,
Sep 5, 2019, 2:40:47 PM9/5/19
to Jenkins Developer List
We should add a field in the HOSTING Jira that allows people to specify if they want to be set as the default assignee, then the bot can check that field before setting up the default assignee for the component. We would need someone with admin access on Jira to add the field. I can create a PR for the bot once the field is setup.

Jesse Glick

unread,
Sep 5, 2019, 6:56:45 PM9/5/19
to Jenkins Dev
On Thu, Sep 5, 2019 at 2:36 PM Gavin <hal...@gmail.com> wrote:
> Does jira have a concept of auto watch like GitHub does? So an issue could still notify people but not be claimed?

Good question. That would be very useful.

Oleg Nenashev

unread,
Sep 5, 2019, 7:01:55 PM9/5/19
to JenkinsCI Developers
There are ways to do so. The most straightforward way is to create a filter (or to use a public one), go to "Details" and then to subscribe to notifications there.
E.g. this is how I get notifications about INFRA, Java 11 and JCasC compatibility issues nowadays

image.png


--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/sl9eTjIA8F0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3SkUwcr4D4mDfqgF2axjWFv42J-2_zRcBgF%2BNOXsK%3DLQ%40mail.gmail.com.

Ullrich Hafner

unread,
Sep 5, 2019, 7:37:56 PM9/5/19
to Jenkins Developers
Making it an optional field in the HOSTING report seems to be a good compromise, so +1 from me for such a change.

(I understand that developers do not want to be assignee for issues they are never going to fix. On the other hands, for a user that reports an issue it is somewhat disappointing that no one actually cares about his new issue. This will indicate that it is not worth to report an issue at all.)
 

domi

unread,
Sep 6, 2019, 1:39:06 AM9/6/19
to Jenkins Developers
My first thought was that I would like to keep the default assignee - but after reading all the comments, I have to agree, that my only reason for this is so that I get notified by new issues. Although Oleg shoed it is possible to create a filter and get notified about this things, It seems quite complicated and many maintainers will not do it and therefore not get any info about new issues. So I think there should be some kind of easy way to at least inform the official maintainer - maybe we can even create these filters automatically…
/Domi


Olblak

unread,
Sep 6, 2019, 4:35:32 AM9/6/19
to 'Gavin Mogan' via Jenkins Developers
I totally agree with the general opinion that an issue should only be assigned to someone if that person is effectively ready to work on it otherwise it just bring confusion about either the assignee will effectively works on it or not.
And I also understand that people use default assignee to get notify when a new issue is created.

What I propose is to set 'default assignee' to 'unassigned' by default and add a notification rule saying each time a ticket is (re)-open, or close, we notify component lead. (btw I just created that rule now :p)

Regarding filters, I think it really depends how much time we spend on Jira, personally I heavily rely on them but I don't expect every contributor to configure their own filters

---
-> gpg --keyserver keys.gnupg.net --recv-key 52210D3D
---


Gavin

unread,
Sep 6, 2019, 6:00:17 PM9/6/19
to jenkin...@googlegroups.com
Filterers can be saved and shared, and so a default search could be setup with https://confluence.atlassian.com/jira063/advanced-searching-functions-683542527.html#AdvancedSearchingFunctions-componentsLeadByUser() and then any custom requirements could be forked and tweaked per user.


Jesse Glick

unread,
Sep 6, 2019, 9:52:50 PM9/6/19
to Jenkins Dev
On Thu, Sep 5, 2019 at 7:01 PM Oleg Nenashev <o.v.ne...@gmail.com> wrote:
> create a filter (or to use a public one), go to "Details" and then to subscribe to notifications there.

I tried this, but it does not do what I need: it just sends, say, a
daily list of all issues matching that filter. To replace the
notification function of default assignee, I would want something that
only send me _changes_ in issues matching the filter.

I suppose a workaround would be to create a filter matching all issues
from some component which I am not watching, and then send a digest of
that; then I would need to click on everything newly appearing and
watch it, and rely on the watches for notifications. Seems pretty
clumsy though.

Daniel Beck

unread,
Sep 7, 2019, 7:41:49 AM9/7/19
to Jenkins Developers

> On 7. Sep 2019, at 03:52, Jesse Glick <jgl...@cloudbees.com> wrote:
>
> I tried this, but it does not do what I need: it just sends, say, a
> daily list of all issues matching that filter. To replace the
> notification function of default assignee, I would want something that
> only send me _changes_ in issues matching the filter.

`createdDate > -1d` (or updatedDate) might work for daily notifications from subscriptions, perhaps in conjunction with `watcher != currentUser()`. But still not a great replacement (and misses issues whose component gets changed to yours).

FWIW I like being default assignee for matrix-auth-plugin and being informed of new issues quickly. Granted, it's a very low volume of notifications, but I expect that to apply to most plugins in the "long tail". It's the top 10-20% of plugins that presumably have a very high volume of new and updated issues, making having a default assignee impractical.

Reply all
Reply to author
Forward
0 new messages