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. > > 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. > This makes it much less likely to accidentally send files with local > modifications or add/remove files without meaning to. > > 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. But there's a bunch of compile-time tests in libdrm, run by ninja test and make check, those should keep working imo, at least for now. -Daniel > Emil, would that be enough, or was your concern something else? -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
