[PATCH util-modular 5/9] build.sh: add the remaining xorg lib(s)

[Peter Hutterer]

On Mon, Feb 27, 2017 at 12:09:38PM +0000, Emil Velikov wrote:
> On 27 February 2017 at 02:10, Peter Hutterer <peter.hutterer at who-t.net> wrote:
> > On Tue, Feb 14, 2017 at 10:11:09PM +0000, Emil Velikov wrote:
> >> Thanks for having a look Alan.
> >>
> >> On 14 February 2017 at 16:31, Alan Coopersmith
> >> <alan.coopersmith at oracle.com> wrote:
> >> > This one seems useful/important:
> >> >> +    build lib libXpresent
> >> >
> >> > Are you using the github version for this since it moved off fd.o?
> >> >> +    build lib libxkbcommon
> >> >
> >> > I don't know what this is:
> >> >> +    build lib libXrandrUtils
> >> >
> >> > This was a student project that I don't know if it ever got finished or
> >> > adopted:
> >> >> +    build lib libxcwm
> >> >
> >> > The rest are deprecated/obsolete/unused:
> >>
> >> Rather than scattering, I'll try to sum it up here:
> >>
> >> Patches 4-9 are sort of RFC, at least for the time being.
> >> IMHO it makes sense to have all the repos listed since amongst others
> >> it makes it easy to track/sync the list via the diff command provided.
> >>
> >> Now to the moved/foo/bar repos. One idea boils down to having a checked-in file.
> >>  - moved - "moved-to" -> git clone ... `cat $ROOT/$MODULE/moved-to`
> >> and act accordingly
> >>  - no longer maintained - "unmaintained" can be used to
> >> a) track if configure.ac has been updated (returns unique error code)
> >> b) warn early when explicitly requesting to configure/build the module, other
> >>  - odd repos - xorg/xserver-test anyone, xproto, other - nuke them ;-)
> >
> > What's the end goal of this though? Having configure nuke out seems like the
> > most sensible solution for any repository that has surpassed its useful
> > life. And *not* having it in the build.sh script is likely better to avoid
> > erroneous clones than having an external file that tracks this.
> >
> Having the extra checkout is negligible comparing to:
>  - we can diff (see the command in patch 4) the existing tree against
> the current contents

what do we need this for? I'm working on the assumption here that if we have
a new and well-maintained repository, then things like build.sh updates
should be handled by the maintainers anyway, so the diff would only provide
us with information about dead repositories.

>  - we can automatically redirect moved repos (git clone `cat MOVED`)

that is a feature i can see to be useful, but the same can be achieved in
configure.ac, or, if you want to go to more of an extreme: git rm everything
in the repo and only leave a README.txt with the moved project url. That's
sure to get everyone's attention :)

>  - we can do a sanity check (that configure bails out) for deprecated repos

from my experience, out-of-band checks like this just increase the
maintenance effort with very little benefit. for example, most of the input
drivers have been deprecated for years, checking that they still bail out
seems superfluous.

>  - the above two can be synced with a third party file (MAINTAINERS?)
>  - but in general relying solely on MAINTAINERS (or anything that's
> outside of the respective repo) will lead end up horrilbly out of date

I'm going to argue that the same is true here, given the number of issues
you already found with build.sh because it's barely maintained :)

> > We do have a MAINTAINERS file somewhere, in theory that could already be
> > used to list deprecated repositories.
> >
> The MAINTAINERS is one such example.
> 
> Actually skimming through the file we can even feed/cross reference
> the information between it and the git config of the repos.
> Something like -> git config  --get sendemail.cc $MAINTAINER

on the subject of people being on my lawn, I like the current convention
where I'm not CC'd on every patch automatically. once that would just
increase my filtering needs and likely lead to more patches being missed
than now. but that's my personal view here.
 
> >> "Fixing" things roughly like above will take some time, but I wouldn't
> >> mind helping out every now and then.
> >
> > This is something where I think we'd have to have everything in place in one
> > go. Because if we merge the patches 4-9 but then not update the rest for
> > another year, we'll have a year's worth of people checking out repositories
> > that they don't need. Or worse, repositories, that break the build.sh run.
> >
> Fully agree - we cannot merge 4-9 as-is. I'm mostly looking for a
> confirmation that I'm not completely loosing it and the (above) plan
> sounds reasonable.

tbh, to me it sounds like "there's all these cool things we want to do" but
I'm not quite convinced yet on *why* we want to do these and what the
benefits are. I live in my own bubble of only few repositories I have to
deal with, so if you tell me that this is more of an issue when working on
mesa/drivers/whatever then I'll take that as argument.

Cheers,
   Peter