On 27 February 2017 at 02:10, Peter Hutterer <[email protected]> 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 >> <[email protected]> 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 - we can automatically redirect moved repos (git clone `cat MOVED`) - we can do a sanity check (that configure bails out) for deprecated repos - 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
> 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 >> "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. -Emil _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
