>
> Possibly could give maintainers team maintainer permission to help with
> that if the person they want to add is a member of the org
>
>
We usually grant Admin permissions to new teams so that they can manage
their GitHub apps & Co.
We started doing that before Maintainer permissions were
Possibly could give maintainers team maintainer permission to help with
that if the person they want to add is a member of the org
On Mon, 13 Jan 2020 at 13:37, Daniel Beck wrote:
> How do you plan to address issues in plugins whose maintainers are largely
> (or even completely) managed outside
I love deleting deprecated code, so big +1 from me. I especially like
the emphasis on always using an encrypted+authenticated connection for
remoting to ensure that users will have a properly secure experience
out of the box.
On Sat, Jan 11, 2020 at 2:27 PM Oleg Nenashev wrote:
>
> Thanks a lot
Hi all,
Nearly a month ago I raised [PR
#124|https://github.com/jenkinsci/s3-plugin/pull/124] on the S3 plugin. It
has not been reviewed or merged yet. I also noticed that there are quite a
lot of open PRs and that the plugin hasn’t been released for more than a
year and half.
Possibly it is
> Am 13.01.2020 um 14:18 schrieb Andreas Sieferlinger
> :
>
> Hey,
>
> i'm currently working on extending the Amazon ECS plugin a little bit to add
> some information about the agent the job is run on the the builds log in the
> UI.
> For example the assumption was that the following line
On Mon, Jan 13, 2020 at 2:43 PM 'Gavin Mogan' via Jenkins Developers <
jenkinsci-dev@googlegroups.com> wrote:
> I think blueocean should always be treated as the exception not the rule.
>
There are currently around 300 outside collaborators to jenkinsci
repositories (compared to 2000 members),
I think blueocean should always be treated as the exception not the rule. I
tried to do the codeowners for it and didn't realize the privacy thing.
https://github.com/jenkinsci/blueocean-plugin/blob/master/CODEOWNERS
Codeowners would be opt in, and maybe even defaulted. But not mandatory. I
think
How do you plan to address issues in plugins whose maintainers are largely
(or even completely) managed outside the repo-specific team, or with custom
teams that are largely maintained manually?
Since we grant repo admin permissions, it's easiest for maintainers to just
add new people as external
Hey,
i'm currently working on extending the Amazon ECS plugin a little bit to
add some information about the agent the job is run on the the builds log
in the UI.
For example the assumption was that the following line would create such a
log entry:
The default for a team is "secret" which means members are not visible to
anyone, the only other option available is "closed" which means the members
are visible only to members of the organization, not the general public. I
think since it is not exposed to the general public that this should be
Looks like the github-api library does not currently support setting the
`privacy` value for a team.
On Mon, Jan 13, 2020 at 5:58 AM Tim Jacomb wrote:
> The list of maintainers is already public in the repository permissions
> list,
>
> +1 for changing this
>
> I assume the API call needs to be
But the teams are not, and that could expose individuals without their consent.
> On Jan 13, 2020, at 4:58 AM, Tim Jacomb wrote:
>
>
> The list of maintainers is already public in the repository permissions list,
>
> +1 for changing this
>
> I assume the API call needs to be updated
The list of maintainers is already public in the repository permissions
list,
+1 for changing this
I assume the API call needs to be updated slightly in the IRC bot
Thanks
Tim
On Mon, 13 Jan 2020 at 12:46, Marky Jackson
wrote:
> Oleg,
> I feel that need some form of consent from maintainers.
I think this proposal sounds good. The groups are created automatically by
the bot, so its not like its a thing we are trying to hide anyway. Is there
anything we need to do in the bot to make sure these groups are public
going forward as new plugins are hosted?
On Mon, Jan 13, 2020 at 5:32 AM
Quite happy for that in the case of the plugins I maintain. My details are
in the POMs anyway.
On Mon, Jan 13, 2020 at 12:46 PM Marky Jackson
wrote:
> Oleg,
> I feel that need some form of consent from maintainers.
>
> On Jan 13, 2020, at 4:32 AM, Oleg Nenashev wrote:
>
>
> One thing here
Oleg,
I feel that need some form of consent from maintainers.
> On Jan 13, 2020, at 4:32 AM, Oleg Nenashev wrote:
>
>
> One thing here is that the most of the pluginId-developers teams are secret
> at the moment, and the teams must be public to operate properly with
> CODEOWNERS.
> I
One thing here is that the most of the *pluginId-developers* teams are
secret at the moment, and the teams must be public to operate properly with
CODEOWNERS.
I suggest to make all of them public, IMHO there is no value in hiding
teams in the open-source project (apart form unintended mention
17 matches
Mail list logo
