<div dir="auto">FWIW, with all the feedback I've given, I think autotools is not better than meson. The issues that I reported won't make me switch back to autotools.<div dir="auto"><br></div><div dir="auto">Marek</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Dec 19, 2018, 12:45 PM Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Dec 19, 2018 at 10:32 AM Ilia Mirkin <<a href="mailto:imirkin@alum.mit.edu" target="_blank" rel="noreferrer">imirkin@alum.mit.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Dec 19, 2018 at 11:03 AM Jason Ekstrand <<a href="mailto:jason@jlekstrand.net" target="_blank" rel="noreferrer">jason@jlekstrand.net</a>> wrote:<br>
><br>
> On Wed, Dec 19, 2018 at 9:32 AM Ilia Mirkin <<a href="mailto:imirkin@alum.mit.edu" target="_blank" rel="noreferrer">imirkin@alum.mit.edu</a>> wrote:<br>
>><br>
>> On Wed, Dec 19, 2018 at 10:25 AM Matt Turner <<a href="mailto:mattst88@gmail.com" target="_blank" rel="noreferrer">mattst88@gmail.com</a>> wrote:<br>
>> ><br>
>> > On Wed, Dec 19, 2018 at 8:06 AM Ilia Mirkin <<a href="mailto:imirkin@alum.mit.edu" target="_blank" rel="noreferrer">imirkin@alum.mit.edu</a>> wrote:<br>
>> > ><br>
>> > > On Wed, Dec 19, 2018 at 1:01 AM Matt Turner <<a href="mailto:mattst88@gmail.com" target="_blank" rel="noreferrer">mattst88@gmail.com</a>> wrote:<br>
>> > > > WTF would you have us do?<br>
>> > ><br>
>> > > Same thing as for any change with an impact this wide --<br>
>> > ><br>
>> > > 1. Identify stakeholders. In this case, probably the sub-project<br>
>> > > maintainers, major contributors, and a smattering of distro<br>
>> > > maintainers.<br>
>> > > 2. Make them happy, or at least get them, as a group, to agree that<br>
>> > > it's "good enough".<br>
>> ><br>
>> > So we're trying to get better coverage than what you're suggesting.<br>
>> ><br>
>> > > 3. Apply.<br>
>> > ><br>
>> > > This is the point at which you can make autotools less visible. We're<br>
>> > > not at that point yet.<br>
>> ><br>
>> > Ilia, it's an extra flag. I think you'll survive.<br>
>><br>
>> It's an advertising strategy for meson (hello world, check this out,<br>
>> it's going to be the default soon). It can be done at the final stage.<br>
>> We're not at that stage.<br>
>><br>
>> We're at the stage of "hello community, we'd like to replace<br>
>> autotools", and the community coming back to you with feedback.<br>
><br>
><br>
> I disagree.  I think we were at that stage 6-8 months ago and a bunch of the community didn't come back with feedback until we sent a patch to delete autotools.  Identify stakeholders?  Done; the distros are all cool with it or have already switched.  Agree it's "good enough"?  We thought we'd done that and then people raised issues at the 11th hour.  Even with those issues, the ones that are real issues with meson are all in-progress to fix.  The others are just "make it look like autotools so I can pretend meson doesn't exist".  Please pardon my frustration but we thought we'd done our due diligence and it wasn't until we took a step very much like this one that we actually got feedback from certain people such as yourself.  To say that we're only now getting to the "hello community, we'd like to replace autotools" stage is a bit disingenuous.<br>
><br>
> That said, that doesn't mean I think this patch is the right way to go.  I think the referenced e-mail conversaion has flushed out enough of the remaining issues that we need to fix a couple of remaining things in meson and then just delete autotools.  Maybe this means that autotools stays around for one more release but then I think we should just can it without bothering with the extra deprecation step.<br>
<br>
First -- I want you (and Dylan, and others who are pushing this) to<br>
know that I understand your frustration. Making big changes is a giant<br>
pain. Not only is the change itself difficult (aka 80% of the work),<br>
but then you have to herd all the cats to make it all happen. And cats<br>
don't like to be herded (which is why 20% of the work takes 80% of the<br>
time).<br>
<br>
Second -- you're not just getting to "hello community" -- you've been<br>
there for a while. But it's not a signpost to move past (like an<br>
announcement might be), it's a stage to complete. The community has to<br>
be happy. You're saying the concerns are last-second, but I've been<br>
seeing these complaints going on for a while (stuff about saving env<br>
vars, inability to see how you configured something, etc). I was<br>
expecting these would all be addressed before I had to have another<br>
look. And then all of a sudden, "let's drop autotools!" and variants<br>
thereof.<br></blockquote><div><br></div><div>I thought I recalled some fairly big "meson is ready; please try it out and report issues" e-mails in the past but I'm having trouble finding them today.  I do recall you having some complaints early on but, to be honest, I don't remember what form those took or how/if they got dealt with.  I think one of the failings here is that we really need some sort of a check-list of things that need to happen prior to autotools deprecation which people can lobby to get things added to.  I think dylan has a checklist somewhere but it may not be sufficiently public/obvious such that some of your complaints never got logged there.</div><div><br></div><div>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?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
What you've been doing thus far is getting all the yaysayers to be<br>
happy (people who are enthusiastic about the change, such as yourself)<br>
-- making sure it all basically works, etc. Now you have to get the<br>
naysayers to be happy, like me, who are pretty happy with the status<br>
quo, and see limited/no benefit in the change. The way you do that is<br>
to make the new system no worse than the old one. Given that some<br>
people are interested, the naysayers aren't going to just shut it<br>
down, but their concerns should be addressed or ruled invalid.<br></blockquote><div><br></div><div>I responded to your e-mail and I agree that a couple of those are real problems that need to be sorted and another is something that while I personally don't care about, I agree that people find it useful and it'd be nice to have.  However, when you're talking about "no worse than the old one", what are we supposed to do about the things which aren't actually worse but are just different?</div><div><br></div><div>--Jason<br></div></div></div></div>
_______________________________________________<br>
mesa-dev mailing list<br>
<a href="mailto:mesa-dev@lists.freedesktop.org" target="_blank" rel="noreferrer">mesa-dev@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a><br>
</blockquote></div>