maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hervé BOUTEMY <>
Subject Re: Improving Jenkins
Date Tue, 20 Dec 2016 07:29:15 GMT
Le mardi 20 décembre 2016, 03:45:47 CET Christian Schulte a écrit :
> Am 12/19/16 um 08:32 schrieb Hervé BOUTEMY:
> > Le lundi 19 décembre 2016, 00:44:48 CET Christian Schulte a écrit :
> >> Am 12/18/16 um 10:19 schrieb Hervé BOUTEMY:
> >> Thats what the resolver does when requested to collect dependencies for
> >> a POM or for a dependency. I just made two selector implementations
> >> behave the same.
> > 
> > that's the risky job: changing key Maven core feature => require a lot of
> > explanation for everybody before changing it on master
> > And a choice on when to include such breaking change
> I consider master "bleeding edge". This is where everyone is working on
> and what is used by the developers themselves. Main point of
> collaboration. Not questioning your points. We are talking about those
> things solely because I pushed them to master. That's the intention and
> that has lead to a state I would not mind to release. That's a different
> story, I know.
we are in a stabilization phase, to make a long awaited release which has 
already numerous questions attached for end users migration: that's not the 
time to add more breaking changes

> > "I'm not the author": wrong conclusion
> > right conclusion is: "change with extreme care, because even if your
> > intentions are the best, such change will bite a lot of users"
> I try to be that careful. The resolver codebase is quite special. What
> appears to be common sense patterns applied turns out to be tweaked like
> mad under the hood applying some custom only the original author knows
> what's going on patterns everywhere sometimes in conflict with what is
> common sense. I may be totally wrong with this. That's my impression
> having read large parts of that codebase. Continously re-reading may
> yield different results.
yes: that's why working on changing it requires unusual strategies

> >> What is broken?
> > 
> > remember we have thousands or millions of users: the change will make a
> > lot of builds fail
> All ITs are passing. I really do not expect that much of breakage.
All ITs are passing: that's a first minimal step = "it can fly"
the next step is to estimate how much efforts it will require for users to 
upgrade (for which benefit): do you have a list of plugins versions that are 
failing with the new plugins resolution algorithm? Putting it on a Wiki page 
would be useful for change management.

and there is even eventually another step: can a pom be configured to work both 
with the old algorithm and the new one?

> > As a conclusion: you're working on changing dependencies and plugin
> > management, which is the most difficult and risky part of Maven changes,
> > that has a lot of impact on every user (Maven developers being only the
> > first level of users)
> > Then this require extreme caution that you missed at the moment
> All ITs are passing. It took a weekend of work to reach that. Ok. In
> between master was in an unusable state from time to time but never for
> more than 2 hours. It maybe is a matter of workflow. I fetch only before
> I want to push something but I am pushing often. So this may not work
> when not fetching for weeks.
one week on a feature branch is the way to go for such key changes.
This is true in general, and even more when we're trying to do a release

> > I want to be supportive of such changes, but that will require other
> > working methods for the whole Maven team to be able to explain to ouor
> > end users why *we* changed something that breaks existing builds
> It is not breaking existing builds. Really. I haven't changed things
> that dramatically. Hopefully.
still has to be proven and documented: I want to help on the wiki page, please 
give some initial list and I'll work with you on it

> It may break broken builds working before. Different story.
that one is what makes me mad: you're playing like a purist kid, against 
normal users
If it was working, it was not broken: it may have worked by "chance", yes, and 
we must work on removing this risky "chance" part. But you can't start by 
telling users their build was broken: no, it worked

> > On the short term, I think that everything can't go into Maven 3.4.0 but
> > will have to be explained,documented and included in a future version:
> > perhaps Robert's idea on rewinding to a past state to rework what goes
> > into Maven 3.4.0 and what will go in a future version will be the best
> > solution to help us work back on a shared vision and clean codebase
> Maybe create a 3.4.0 branch forking from somewhere you feel comfortable
> with. The same for the resolver. Time for release branches then.
time for exceptional release branch, because this is exceptional change

> Means
> instead of everyone creating theire own branches, let everyone
> collaborate on master and have a release branch kept in a state one can
> cut a release from whenever needed/wanted. Maybe some release manager
> decides what is merged from master and what not. It's possible to cut
> releases in between whenever needed/wanted/requested/required that way.
> Collaboration is important. It has helped a lot getting those changes
> sorted out. In fact, we are still sorting things out now. That's
> something very positive.
yes, collaboration is positive: but you're still avoiding the fact that you 
just postponed the 3.4.0 release for I don't know how much time. It seems 
you're missing empathy for the rest of the team and for users: that one is a 
lot less positive :(
I hope this is the last time you're working on master for such risky key 
changes: please confirm


> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message