All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Engestrom <eric.engestrom@intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Emil Velikov <emil.l.velikov@gmail.com>,
	ML dri-devel <dri-devel@lists.freedesktop.org>,
	Dylan Baker <dylan@pnwbakers.com>
Subject: Re: [PATCH libdrm] RELEASING: update instructions to use meson instead of autotools
Date: Tue, 19 Feb 2019 14:02:02 +0000	[thread overview]
Message-ID: <20190219140202.atrakudq6jv5zbey@intel.com> (raw)
In-Reply-To: <CAKMK7uFeOtBnRNc+J2VRZ0=YM29p-d9oeNx484Hi75JcRUcz9g@mail.gmail.com>

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.velikov@gmail.com> wrote:
> >
> > On Mon, 18 Feb 2019 at 17:42, Eric Engestrom <eric.engestrom@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.engestrom@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 <dylan@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).

Emil, would that be enough, or was your concern something else?
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2019-02-19 14:02 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-19 16:23 [PATCH libdrm] RELEASING: update instructions to use meson instead of autotools Eric Engestrom
2018-12-20 19:53 ` Dylan Baker
2019-02-18 17:42   ` Eric Engestrom
2019-02-18 20:36     ` Daniel Vetter
2019-02-19 11:52     ` Emil Velikov
2019-02-19 12:53       ` Daniel Vetter
2019-02-19 14:02         ` Eric Engestrom [this message]
2019-02-19 15:20           ` Daniel Vetter
2019-02-19 15:34             ` Dylan Baker
2019-02-19 16:51               ` Emil Velikov
2019-02-19 22:33                 ` Dylan Baker
2019-02-21  9:42                   ` Daniel Vetter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190219140202.atrakudq6jv5zbey@intel.com \
    --to=eric.engestrom@intel.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=dylan@pnwbakers.com \
    --cc=emil.l.velikov@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.