From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [PATCH for-xen-4.5] tools/mkrpm: improve version.release handling Date: Fri, 7 Nov 2014 09:52:01 -0500 Message-ID: <20141107145201.GE13259@laptop.dumpdata.com> References: <1412694063-29616-1-git-send-email-olaf@aepfle.de> <20141103142436.GA23458@aepfle.de> <545791F6.2080809@eu.citrix.com> <20141103144848.GB28870@aepfle.de> <20141104104649.GA8479@aepfle.de> <1415099037.11486.25.camel@citrix.com> <20141107133058.GA11146@aepfle.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20141107133058.GA11146@aepfle.de> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Olaf Hering Cc: Wei Liu , Ian Campbell , Stefano Stabellini , George Dunlap , Ian Jackson , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org 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 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