On 2 November 2010 08:23, Brett Porter <br...@apache.org> wrote: > > On 01/11/2010, at 10:26 PM, Brian Fox wrote: > >>> The barrier to collaboration is high here. >> >> That's all I'm saying. The tools make that partially true but it's not >> stopping other projects so it's clearly not the only issue. Maybe no >> one really cares about these plugins, and for the ones raised so far, >> that's probably the case. > > > The problem here is the way in which we abuse JIRA (by necessity). A change > of source control would make little difference, other than if it were to > route around issue tracking which isn't particularly helpful. Some people > watch patches on specific subprojects, other subprojects get neglected > (perhaps picked up in bursts). Not all such subprojects are retirable. > > No other project I know of tracks small components in such a way, and we > regularly lose sight or timeliness of patches. IMO, we should reconsider our > approach, or look again at aggregation, or some way of keeping track of > patches across projects. > > The limiting factor is in time, communicating and testing, not in applying or > releasing them. Those parts are about 10% at the start and end. The rest is > in the middle, and perhaps the pressure to fix more things while you are > there. >
+1 to all of the above. If we have plugins and there are people willing to work on them and who have demonstrated merit by submitting patches, let's grow the community in Apache by bringing them in... saying that things here are crap so let's not bring more people in is just like holing the big ship Apache below the water line. Yes, we abuse JIRA to a large extent by having so many sub-projects... perhaps we should consider migrating from codehaus JIRA into apache JIRA and do a tidy-up of our JIRA process We have no process for reviewing big impact changes... let's start a process using the reviewboard server We have plugins which do not have (committer) maintainers... let's see if we can find maintainers (from the pool of people submitting patches) and bring them into the community... that's the spirit of the Apache way IMHO We have plugins which are no longer relevant due to being: a hack that is no longer needed; superceeded by technology developments; etc... then let's deprecate them (release final version marked deprecated - oh and make sure the plugin site EXPLAINS WHY the plugin is deprectaed) and then remove them. OK, so github is faster for development... but a faster process is not necessarily better... it just means that the damage when you crash is bigger. [And don't get me wrong, I like github] A project being at Apache means it has a certain expectation in terms of quality, that is good... being a mojo gives an expectation of quality too, but IMHO it's a lesser expectation... As a plugin consumer, I see three tiers of plugins in terms of quality and adherence to "the maven way": Tier 1: Apache Maven hosted plugins Tier 2: Codehaus Mojo and other Apache (non-Maven) hosted plugins Tier 3: All other plugins Pushing plugins from tier 1 (maven) to tier 3 (github) does not reward users IMHO -Stephen --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
