I know I am somewhat new around here, but here is my opinion for whatever it is 
worth.

I can definitely see value in being able to determine whether or not a plugin 
is maintained, especially for when somebody is asking to be able to commit to 
it. I do not think the model proposed would provide a sufficiently accurate 
representation of that state. To me it would make more sense to evaluate the 
activity of the maintainer for a given plugin versus the activity on the plugin 
itself. It might also be worth evaluating other datapoints for the plugin 
itself such as average life span of pull requests, average number of pull 
requests in queue, etc.

I am not familiar with the GitHub APIs, so I do not know how difficult that 
would be to implement. It might also be more accurate to correlate GitHub data 
with data extracted from Jira or other sources.

I see little if any value in an "attic" for plugins. I have been using Jenkins 
for quite some time, and many of the plugins I use and have used have gone for 
extended periods without updates. In my opinion, this does not have any bearing 
on the suitability of a plugin for the performance of a given task. The idea 
that a plugin that still has utility is not plainly available within the UC 
seems like it would cause a great deal of frustration to Jenkins 
users/administrators.

I think the idea of making certain plugin metadata available in the UC has 
merit. I think the usefulness of metadata would be enhanced by the ability to 
filter plugins based on various criteria.

I think a possible reprecussion of a secondary "Attic" UC is the proliferation 
of non-official UCs. I can see myself (and others) creating my own with 
everything in it versus having to switch to an alternate to install certain 
plugins. I cannot imagine that this has long-term benefit to the Jenkins 
project, or it's users.


John Tatum
[email protected]
http://scientifichooliganism.net

Although this e-mail and any attachments are believed to be free of any virus 
or other defect that might affect any computer system into which it is received 
and/or upon which it is opened, it is the responsibility of the recipient(s) to 
ensure that it is virus and/or defect free and John Tatum bears no 
responsibility for any loss and/or damage arising in any way from its use.      
                                 

-- 
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/BLU179-W560C64F73D83ECB4D0481FF7BD0%40phx.gbl.
For more options, visit https://groups.google.com/d/optout.

Reply via email to