To begin with, we have a lot more plugins than we have people to work on them.

Then, we have some critical functionality that is very fragile.
Perhaps this is because the problem is fundamentally hard. Perhaps it
is because the abstraction is fundamentally wrong.

In the case of git, where I think that I'm (one of) the perp(s) being
referred to, I tried to satisfy a set of very unhappy users. The
difficulty is that Maven SCM does not interact with git through a
clean abstraction. So my attempt to fix a problem that afflicted a set
of users (admittedly including myself) with one version of git in one
usage pattern, caused problems with other users with other versions of
git. All the tests we had passed with the environment available to me
and the CI system we have. So we're about at the point where it's
nearly impossible to change anything interesting.

To avoid complete constipation here, I can imagine:

1: there is a new git SCM artifact (or branch) for each materially
different version of git, so that a person with access to and interest
in version X can fix things without being prepared to set up and test
versions Y, Z, etc.

2: there is a testing apparatus that we maintain that can regress all
this against a wide spectrum. This might not be good enough -- if the
requirement to commit a patch to the code was to succeed in fighting
through all the problems that manifest in all the versions, I might
never have enough time to do anything.

3: analysis would lead to a different way to think about the
abstraction of working with git so that we could have a less fragile
result.

4: cooperation with someone on the git / egit side of the house would
lead to an API we could talk to that would avoid some of this trouble.

Some of this is amplified by the problem that there isn't enough
information in the POM data model to handle the requirements of the
SCM's very well, and we've ground to a halt in advancing to a next POM
data model.




On Sat, Jun 27, 2015 at 7:10 AM, Tibor Digana <[email protected]> wrote:
>>> And the team should be big  enough to cover them all. Otherwise we should
> just look for them.
>
> Agree. So why not to introduce more committers.
> This still sounds to me like we do not have environment to cover the fix in
> tests on all SCM we support.
>
>
>
> --
> View this message in context: 
> http://maven.40175.n5.nabble.com/number-of-bugs-in-maven-release-plugin-tp5838696p5838743.html
> Sent from the Maven Developers mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to