[Mesa-dev] [PATCH] autotools: Deprecate the use of autotools

[Ilia Mirkin]

On Wed, Dec 19, 2018 at 12:50 PM Jason Ekstrand <jason at jlekstrand.net> wrote:
> What do you suggest to solve this communication issue?  If autotools survives another release, so be it.  However, I want to get us out of the vicious cycle of long e-mail threads and endless debates and on to a model where Dylan is working towards something and is able to actually close the gap.  The cynic in me says that if the last week's exchanges teach us anything, it's that we'll never make the naysayers happy and we're wasting our time trying.  I badly don't want that to be true.  However, for my internal cynic to be proven wrong, we need a more productive model for how we close that gap and agree that it's "good enough."  What do you suggest?

Well, there are a few considerations here. First of all, "who should
we ask". I'm thinking, whoever's had at least 25 changes this year
[not a scientific cut-off, could go higher or lower, but some
precedence for that number -- iirc Valve uses that as the cut-off for
giving the all-valve-games-package]:

git shortlog origin --since 2018-01-01 | grep '^\w' | awk -F"[()]"
'$(NF-1) > 25'

This works out to 49 people as of a few days ago. I'm thinking these
are all people who have built mesa over and over and over again, and
know the various pitfalls, as well as are remaining active
contributors and thus "part of the community". Ideally these people
would also be the ones who know the sorts of issues that end-users run
into through doing a bunch of support, but that's harder to screen
for. Separately go through each driver and state tracker, and ensure
that at least one significant contributor for each one is on that list
of people. Glancing over the above list, I believe that's already the
case, but a thorough check should be performed.

When the current crop of issues is fixed, you should request that each
of these people give the current checked-in meson setup a fair shake
or forever hold their peace re build systems. You should give about 2
weeks for people to do this -- I know many of the issues I ran into
weren't on day 1 but rather on day 10 of using meson.

Of these, I assume a bunch won't care and bow out. The remainder
should submit a list of asks for a replacement. Hopefully we're all
grown-ups and don't ask for the moon -- any outliers can be dealt with
separately. I think anything that's materially over and above what
autotools does now is just out. However you need to be prepared for
feedback that requires changes to meson.

Any feedback you [the "meson" group] believe is not worth addressing
(or would incur an unduly high amount of effort to resolve) should be
separated out [and collated], and we can, as a group decide if it's
really worth dealing with or not.

Rinse and repeat until the concerns of the group are either addressed
or deemed too esoteric.

I realize I've taken some shortcuts here ... who determines what's
esoteric and what's not, and how does the group come to a consensus on
it? I'm hoping we can all be reasonable, and not have to have it come
to that. If there's a situation that's not resolvable directly, we'll
have to figure it out then.

>
> what are we supposed to do about the things which aren't actually worse but are just different?

All these things are preferences, of course. Each complaint should be
triaged and decided whether it's important to fix or not. On top of
preference, practical considerations need to be taken into account --
difficulty, importance, etc. Different isn't necessarily bad, but it's
also not necessarily good. I believe it would be a laudable goal to
have a way to make this all entirely transparent to the average user
[who doesn't care to learn a fancy new system], and in my mind I've
sketched out a pretty trivial way to get to it. Perhaps there's a
giant gaping hole in my estimate which makes it go from "easy" to
"very hard", at which point I'd obviously reconsider the necessity.

Lastly, I suspect many of you who are eager to get the shiny new meson
build to be the default are considering me to be the bad guy here -- I
don't really mind. However realize that there are people out there who
*do* mind that sort of thing. Either due to personality, or due to job
security (for many of the frequent contributors, mesa is their day
job), or due to being on the same team and not wanting real-life
weirdness, people won't speak up. I don't think we're at the point
where feedback needs to be anonymous or anything, but it's something
to be mindful of as we make changes that affect everyone's workflows.

Cheers,

  -ilia