Hi,
On 05.01.20 19:33, Benjamin Marwell wrote:
Hi,
thanks for sharing your idea. While I can see the benefits, I also do see
some drawbacks.
If only one part of the plugin has an invalid state, it will be impossible
to create a release.
Also, the Unix philosophy (make a tool which does one thing well) would be
broken.
Yes very good philosophy...
If voting is a drawback for small plugins, maybe change the voting system
for smaller plugins instead?
Than I would ask: What is a "small" plugin? Not really I just want to
note that...
As a new contributer, I found it easy to find a plugin I could contribute
to. That would not have been that easy if there was one repository with one
plugin that does a lot of things.
I'd stick to the current layout for this reason.
Maybe let's talk about voting instead?
The VOTEing has a very good background see
https://www.apache.org/foundation/voting.html but if we might need we
could change it..
> And maybe talk about more
automatisms for updating the poms and dependencies, maybe even use a github
bot?
Automated updates for dependencies is a very good idea..
I already have done a lot to more automate my tooling...
The final step is check which dependencies could be updated...and the
rest can be automated as I already did...
At the moment I only call my script "createdependencyupgradeissue.sh"
from the appropriate plugin/lib with supplemental explanation (This
could be automated)..This will create a branch for the change / JIRA
Issue etc.
I only need to manually change the version of the dependency...and wait
for the successful build and afterwards "gitmergeandclean.sh" which
merges the branch, fixes the JIRA issue etc.
So the interesting part is: Identify which dependency has to be updated?
Something like "versions:display-dependency-updates" which can deliver
the needed information....I think that might a way to go or maybe GitHub
DependendaBot...
On Sun, 5 Jan 2020, 17:31 Enrico Olivelli, <[email protected]> wrote:
Hi community,
I just want to share this idea, maybe it is silly but why not talk about
it.
We have tens of plugins, most of them are rarely updated and released.
So it happens that users contribute patches in order to fix real problems
but they have to wait an indefinite time before seeing the fix released,
because we are not doing a release just for one issue.
Another problem is that making a release is quite an heavyweight task:
- update parent pom, update dependencies....
This is independant of the release.
- stage a release....
That's not the real problem. The signing of the artifacts is the part
which is the issue cause the rest could be automated via
Jenkins/WhatEver...but the Problem is related to the private PGP key to
sign the artifacts.
- make the VOTE, wait, make at least 3 PMC vote..
Yes ...
- finalize...
Could be done via button ...(Need some work, but doable)...
Also creating the announcement mail etc.
What about creating some maven-ext-plugins git repository with a parent and
reactor pom and move all of those plugins that are really never released?
I am thinking to side plugins like jdeps, checkstyle, pmd, enforcer....not
compiler, assembly, surefire...
If we merge them into one single code base we can:
- have releases for all of them, even with some minimal (but blocker) fix
- save time and resources (one committer does the work once and PMC votes
only once, and we release 10 or more plugins...)
Which means one plugin could block all others. We have some plugins like
maven-compiler, maven-shade, maven-pmd which needed to be released with
each Java version ...other are not that problem..
We could even think to time based release schedule
How long could be the time between the releases? days, weeks, months?
I image the big work you did for splitting all of the 100 git repositories
from svn....but I think this move can give more vitality to the project
We would have to think about jira, websites....I know it won't be easy
Best regards
Enrico
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
