All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Olaf Hering <olaf@aepfle.de>
Cc: Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [PATCH for-xen-4.5] tools/mkrpm: improve version.release handling
Date: Fri, 7 Nov 2014 09:52:01 -0500	[thread overview]
Message-ID: <20141107145201.GE13259@laptop.dumpdata.com> (raw)
In-Reply-To: <20141107133058.GA11146@aepfle.de>

On Fri, Nov 07, 2014 at 02:30:58PM +0100, Olaf Hering wrote:
> So how should we proceed here?!

George, any input on this since Ian just nominated you to
be the maintainer-pro-temp?

Thanks.
> 
> Olaf
> 
> On Tue, Nov 04, Ian Campbell wrote:
> 
> > On Tue, 2014-11-04 at 11:00 +0000, George Dunlap wrote:
> > > On Tue, Nov 4, 2014 at 10:46 AM, Olaf Hering <olaf@aepfle.de> wrote:
> > > > On Tue, Nov 04, George Dunlap wrote:
> > > >
> > > >> A number based on the time you happened to create the RPM, not based
> > > >> on something intrinsic about the content of the RPM; that just seems
> > > >> kind of hacky to me.  It happens to work well for your common
> > > >> workflow, but you can certainly imagine other workflows or other
> > > >> situations where you'd have to more manually override things anyway
> > > >> (for instance, doing bisections, or comparing functionality in
> > > >> different releases).  It seems like rather than having to remember
> > > >> when you can skip the manual override bits, and when you can't, it
> > > >> would be better to just use them all the time.
> > > >
> > > > George, the release number is and was never meant to describe the
> > > > content of a package. It just means "its different". And it will even
> > > > work for bisect because the package is always "newer", even if the
> > > > content is different.
> > > 
> > > Not if you end up going to a previously built package for some reason.
> > > 
> > > I can see how this makes more sense if you do have an independent
> > > package installed for every branch; but most people are not going to
> > > do that.
> > > 
> > > Anyway, if I were a maintainer, I might decide to accept it, even
> > > though I didn't like it, on the grounds that it doesn't do much harm
> > > and somebody finds it useful.
> > > 
> > > Since I'm not a maintainer, I'm free to be opinionated. :-)
> > 
> > I don't think any of the formal maintainers of this code use RPM[0], and
> > you are the original author of the tool... So I'm afraid I think you
> > might have a more relevant opinion than you might like.
> > 
> > Ian.
> > 
> > [0] At least half happen to be Debian Maintainers...
> > 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

      reply	other threads:[~2014-11-07 14:52 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-07 15:01 [PATCH for-xen-4.5] tools/mkrpm: improve version.release handling Olaf Hering
2014-10-07 15:03 ` Olaf Hering
2014-10-29  8:17 ` Olaf Hering
2014-11-03 11:00   ` George Dunlap
2014-11-03 14:16 ` George Dunlap
2014-11-03 14:19   ` George Dunlap
2014-11-03 14:24   ` Olaf Hering
2014-11-03 14:29     ` Ian Campbell
2014-11-03 14:47       ` Olaf Hering
2014-11-04 10:11         ` Ian Campbell
2014-11-04 10:16           ` Olaf Hering
2014-11-03 14:32     ` George Dunlap
2014-11-03 14:48       ` Olaf Hering
2014-11-04 10:37         ` George Dunlap
2014-11-04 10:46           ` Olaf Hering
2014-11-04 11:00             ` George Dunlap
2014-11-04 11:03               ` Ian Campbell
2014-11-07 13:30                 ` Olaf Hering
2014-11-07 14:52                   ` Konrad Rzeszutek Wilk [this message]

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=20141107145201.GE13259@laptop.dumpdata.com \
    --to=konrad.wilk@oracle.com \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=olaf@aepfle.de \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xen.org \
    /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.