On Tue, 19 Feb 2019 at 15:36, Dylan Baker <dy...@pnwbakers.com> wrote: > > Quoting Daniel Vetter (2019-02-19 07:20:12) > > On Tue, Feb 19, 2019 at 3:02 PM Eric Engestrom <eric.engest...@intel.com> > > wrote: > > > > > > On Tuesday, 2019-02-19 13:53:25 +0100, Daniel Vetter wrote: > > > > On Tue, Feb 19, 2019 at 12:57 PM Emil Velikov > > > > <emil.l.veli...@gmail.com> wrote: > > > > > > > > > > On Mon, 18 Feb 2019 at 17:42, Eric Engestrom > > > > > <eric.engest...@intel.com> wrote: > > > > > > > > > > > > On Thursday, 2018-12-20 11:53:11 -0800, Dylan Baker wrote: > > > > > > > Quoting Eric Engestrom (2018-12-19 08:23:40) > > > > > > > > Signed-off-by: Eric Engestrom <eric.engest...@intel.com> > > > > > > > > --- > > > > > > > > RELEASING | 27 ++++++++------------------- > > > > > > > > 1 file changed, 8 insertions(+), 19 deletions(-) > > > > > > > > > > > > > > > > diff --git a/RELEASING b/RELEASING > > > > > > > > index 7e03e3b9acb1cbfb261a..d1ad8e3b4ad16d4ca14f 100644 > > > > > > > > --- a/RELEASING > > > > > > > > +++ b/RELEASING > > > > > > > > @@ -9,25 +9,14 @@ However, this is up to whoever is driving the > > > > > > > > feature in question. > > > > > > > > > > > > > > > > Follow these steps to release a new version of libdrm: > > > > > > > > > > > > > > > > - 1) Bump the version number in configure.ac and meson.build. > > > > > > > > We seem > > > > > > > > - to have settled for 2.4.x as the versioning scheme for > > > > > > > > libdrm, so > > > > > > > > - just bump the micro version. > > > > > > > > - > > > > > > > > - 2) Run autoconf and then re-run ./configure so the build > > > > > > > > system > > > > > > > > - picks up the new version number. > > > > > > > > - > > > > > > > > - 3) Verify that the code passes "make distcheck". Running > > > > > > > > "make > > > > > > > > - distcheck" should result in no warnings or errors and end > > > > > > > > with a > > > > > > > > - message of the form: > > > > > > > > - > > > > > > > > - ============================================= > > > > > > > > - libdrm-X.Y.Z archives ready for distribution: > > > > > > > > - libdrm-X.Y.Z.tar.gz > > > > > > > > - libdrm-X.Y.Z.tar.bz2 > > > > > > > > - ============================================= > > > > > > > > - > > > > > > > > - Make sure that the version number reported by distcheck > > > > > > > > and in > > > > > > > > - the tarball names matches the number you bumped to in > > > > > > > > configure.ac. > > > > > > > > + 1) Bump the version number in meson.build. We seem to have > > > > > > > > settled for > > > > > > > > + 2.4.x as the versioning scheme for libdrm, so just bump > > > > > > > > the micro > > > > > > > > + version. > > > > > > > > + > > > > > > > > + 2) Run `ninja -C builddir/ dist` to generate the tarballs. > > > > > > > > + Make sure that the version number of the tarball name in > > > > > > > > + builddir/meson-dist/ matches the number you bumped to. > > > > > > > > Move that > > > > > > > > + tarball to the libdrm repo root for the release script to > > > > > > > > pick up. > > > > > > > > > > > > > > > > 4) Push the updated master branch with the bumped version > > > > > > > > number: > > > > > > > > > > > > Just noticed I forgot to decrement item 4 & 5 :] > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Cheers, > > > > > > > > Eric > > > > > > > > > > > > > > > > > > > > > > Acked-by: Dylan Baker <dy...@pnwbakers.com> > > > > > > > > > > > > > > But you should probably get someone other than just me to look at > > > > > > > this. > > > > > > > > > > > > There is no "libdrm maintainer", which makes everyone a libdrm > > > > > > maintainer :] > > > > > > > > > > > > If nobody object, I'll push this in a few weeks (there's really no > > > > > > rush, > > > > > > but I want to make that move at some point, we have no reason to > > > > > > stay > > > > > > dependant on autotools now that we have better tools). > > > > > > > > > > Must admit I'm not the biggest fan. I can see this being cool for the > > > > > maintainer, if autotools was was present on their system. > > > > > The unfortunate reality is - it's there for the foreseeable future. > > > > > If anything it makes it more annoying for those using autotools/make - > > > > > regardless if they like doing so or not. > > > > > > > > > > So that's a nack from me :-\ > > > > > > > > Not really following what's the downside is of using meson to cut the > > > > release tarball? Resulting tarball should still be able to build fine > > > > with automake. If the concern is that automake will bitrot, then I > > > > think a much better solution is to add a few automake targets to the > > > > gitlab ci autobuilder stuff. That's what we've done for igt at least, > > > > works neatly. > > > meson dist is effectively a git tarball. Hence one cannot simply "./configure && make" it
> > > Agreed, and to me using meson has a huge upside: it packages what's in > > > git, > > > unlike autotools which packages whatever was on your machine at the time. If meson doesn't use any of the extra files that is fine. I'm not saying it should :-) > > > This makes it much less likely to accidentally send files with local > > > modifications or add/remove files without meaning to. > > > The release tooling handles that amongst other things. > > > Like I said though, there's no rush, so let's make sure issues are > > > addressed first. > > > > > > I'll add a CI job to run `make distcheck` on releases (libdrm-* tags). > > > > I'd go with make check only. make distcheck needs all the manual > > fiddling in makefile templates (EXTRA_DIST and friends) since automake > > doesn't do the right thing by default like meson. If we go with meson > > for making release tarballs, I don't think it makes sense to keep the > > automake stuff alive. > > I agree with this. Getting a tarball with an autogen.sh and not a configure > script (i.e., unbootstrapped) is unexpected with autotools. When we move to > using meson to build the dist tarball we should drop autotools at the same > time > or shortly after. > If it doesn't get in one's way what's the point of killing it? Practically all the issues I've seen so far are people not running make check/ninja test :-( While I'm a fan of meson for the speed, there are no concerns from having a more established alternative around. -Emil _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel