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

Tue Feb 28 00:58:07 UTC 2017

On Mon, Feb 27, 2017 at 11:40:55PM +0000, Emil Velikov wrote:
> On 27 February 2017 at 21:54, Peter Hutterer <peter.hutterer at who-t.net> wrote:
> > 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.
> >
> Saying this made me look at the build.sh additions and first official
> release of the respective projects:
>  - xf86-video-amdgpu, added to build.sh 01/2017, v1.0.0 - 11/2015
>  - libinput - 08/2016, v1.0.0 08/2015
>  - xf86-input-libinput - 08/2016, v0.1.0 06/2014
> 
> This brings two things to mind:
>  a) people may not know/remember to update build.sh
>  b) why bother remembering when one can do it [semi] automatically, in
> the first place ;-)

hmm, good point. For the libinput case it's simply that build.sh
is good for getting the initial bit up and running but then day-to-day stuff
works on a per-repository basis. And when you start a new project, it's not
part of the whole setup yet, and then you forget...

> >>  - 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 :)
> >
> Parsing through configure.ac/README.txt might be a bit iffy, but sure
> it can work.
> I'm leaning towards the latter - nuke everything but a simple README.

If the project really moved, then this is the best approach. For dead
project it could still be interesting to leave the code in place so it's
easily accessible through cgit, etc.

> >>  - 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.
> >
> If they've been unchanged for years then there will be little-to-no
> maintenance effort, right ?
> On the other hand:
>  - if/when(?) that changes, say someone snuck behind your back and
> starts maintaining xf86-input-digitaledge, it will be flagged
>  - there's multiple semi-broken packages which would appreciate the
> configure.ac AC_MSG_ERROR 'fix'.
> Having a complete list in build.sh will point them out ;-)

I suspect the maintenance effort may come more from those running build.sh
and ending up with repositories that don't build. Not all are officially
discontinued, iirc. And then start filling bug, thus us having to spend time
on it. This is really the main issue I have with cloning a repository that
is known to be useless.

> >>  - 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 :)
> >
> True - cross-referencing stuff should make it easier to find. In
> theory at least.
> 
> >> > 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.
> >
> Ack, fair enough - was just an idea.
> 
> Generally it would be nice to have a reference to the maintainer
> within the repo. The easy way to sync any reference(s) [be that with
> xorg-docs or other] to that person is a big plus IMHO.

Would be easy to add to the README of each project. Though that tends to get
stale too, so we kinda rely on the "do a git log and figure it out".

> >> >> "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.
> >
> These are some ideas of how to make the whole thing [build.sh/modular]
> actually useful. I'm not saying that you/others have to do any of it.
> If one is not willing to let build.sh/modular (and others) die, might
> as well beat them into shape ?
> 
> Guess I'm just naive (hence the NOMAKE patch) and shouldn't bother :-(

the NOMAKE patch is a good example for something that works though, but it
had a direct immediate impact and usecase (and one I've faced in the past,
so I'm biased here). I'm just a lot more hesitant on anything that requires
more long-term maintenance effort because historically we've been pretty
terrible at it.

And I don't even know how many people use build.sh, even more so since the
tinderboxes have gone dodo.

Cheers,
   Peter