Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [hudson-dev] [Hudson-Dev] Re: Specifying the sections where your plugin should appear in the update center

On 1/5/12 12:57 PM, Henrik Lynggaard Hansen wrote:
2012/1/4 Winston Prakash<winston.prakash@xxxxxxxxx>:

One thing that is not documented is the values which can be used in that

Yes, we should document it. Unfortunately no solid list was ever
Let us work on that.
sure, let me start by making the initial suggestion

- scm: for all scm plugins (as today)
- scm-related: for scm helper plugins (as today except git,label column)
- trigger: for buils triggers (as today)
- builder/buildstep: for plugins that extend Builder. As today except
a few to clean out like project health, build pipeline, post build
task and the such
- slave: anything related to managing slaves (as today except system load avg)
- notification: for plugins that notify after (as today except copy to
slave, hudsontracker?)
- report: build reports
- publish/upload: any artifact uploader/publisher
- security: for security and user management
- fun: for none serious plugins such as cigame etc.

I know I am missing some categories, but since many of them are

changes from the current topic list
- suggest slaves and cloud plugins are one category
- drop the maven category
- add a library category for things like static-analysis-core, token-macro etc.
- drop the misc category and just use uncategorised

Sounds like a good list. Could you start a wiki page to list the Plugin Categories, so that others can chime in.

Maybe we should build an alternative topic page while we figure this out ?


also should we specify the tier in the pom ?

I'm not sure if it should be part of the POM. The tier is decided based on
popularity of the plugin (number of downloads etc)
Speaking of which, did we ever get the download/install stats for
plugins fixed,
If you mean fixing the Public/private key issue to unscramble the collected data, if so I fixed it in 2.2.0.
It has a unique server key, so the collected data will be more accurate/

The download data prior to 2.2.0 could be interpreted in terms of unique IP. But may not be accurate.
and is the data publically available ?
The data is collected as part of apache log rotation. I have to parse and create the statistics

What I think for the long run is to build an application that receives the download request which saves the stat directly in a database. The advantage of this approach would be; direct display of download stats by that application on demand.

- Winston

Best regards
hudson-dev mailing list

Back to the top