On 27 February 2017 at 21:54, Peter Hutterer <[email protected]> wrote: > On Mon, Feb 27, 2017 at 12:09:38PM +0000, Emil Velikov wrote: >> 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 > > 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 ;-) >> - 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. >> - 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 ;-) >> - 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. >> >> "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 :-( -Emil _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
