> On 27. Aug 2018, at 21:50, Craig Rodrigues <[email protected]> wrote:
>
> My submission is now Draft JEP-11:
>
> https://github.com/jenkinsci/jep/tree/master/jep/11
Reading through the current JEP, it doesn't seem robust enough in the face of
some of our historical infra baggage, and potentially introduces an additional
component to the takeover that may not actually be involved otherwise.
Not all plugins use Jira. Not all plugins have components in Jira. Not all
maintainers are default assignees. The first is mostly maintainers prioritizing
their own tool preferences over project convention (or having inherited
something like that), the others are mostly due to badly maintained old Jira
components. Since there's no syncing/automated cleanup of components (Tyler
refused to let me continually spam the Jira API), it will likely remain that
way for a while.
There's simply too much that can go wrong with these assumptions (being able to
rely on them would be nice, but we simply can't). Additionally, it seems weird
that the adoption request would be filed in the JENKINS project, when it's more
an INFRA kind of issue.
I agree with Devin and Oleg that a PR to
jenkins-infra/repository-permissions-updater should be the entry point and
reference for any plugin ownership takeover. Without a change there, no
ownership transfer can actually be complete, so making that the reference, and
things like default assignee changes and adding commit access secondary, would
be preferable. It satisfies all the conditions laid out in the motivation with
fewer of the previously mentioned pitfalls (although a dev list email CC
maintainers would still be useful to announce the intended change, and increase
visibility of the request). Even in the case of badly set up Git user names,
https://jenkins.io/doc/developer/publishing/source-code-hosting/ tells us what
GitHub users have commit access, which is usually good enough to identify
maintainer GitHub accounts to ping them. The history of an individual
permission file already tells the maintainership history of plugins since we
started with this.
Further feedback:
- The reasoning seems to ignore that maintainers are to be copied in any emails
to the dev list. They would receive emails directly. This is far more reliable
than Jira notifications could ever hope to be, so seems a step backwards.
- We give repo admin access (unless dealing with historical baggage), not just
write access.
- Batch reassigning issues is something anyone can trivially do in Jira,
doesn't need to be part of the process (presumably to be done by infra admins).
- Wiki pages don't typically list maintainers, so nothing needs updating there
(except for the last release's pom.xml metadata via update-center.json, which
cannot be changed).
- We should just ignore the pom.xml maintainer metadata for being mostly
useless.
- This process allows bad actors to take control of popular, but badly
maintained plugins (no more than today, but still). The JEP does not
acknowledge this issue in the security section.
- Tags exist in Jira as soon as they're entered once, so this probably doesn't
make the threshold for an infra requirement.
I think this has the potential to be an exemplary process JEP, solving an
important and currently underspecified problem, but I don't think it's quite
there yet.
I only read the finished JEP and earlier messages in this thread, so may have
missed further out of band communication.
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/E36E213F-7038-41A9-991A-01C65C0BD4F0%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.
