On Wed, Dec 19, 2018 at 12:50 PM Jason Ekstrand <ja...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
