Early stabilisation
 

Dear ebuild maintainers,


thirty days is the norm for the minimal period between an ebuilds last
non-keywording change while in the tree and the usual call for
stabilisation. If you cannot find a pressing reason to push
stabilisation forward, then don't ask. In the last few days I have seen
several early calls for stabilisation (bugs #217148, #217845, #217841
and #217839 for instance) where no adequate reason was given, in my
opinion.

A good reason might be an important fix of a severe bug, a fix for a
build problem that couldn't be applied to a stable version but had to
go into an ebuild revision, or a version/revision that fixes a security
problem.

On the other hand, maybe these early stabilisation bug reports are a
sign of the times and we need to shorten the normal thirty day period,
become even more of a cutting edge distro - or at least discuss the
options.


Kind regards,
JeR
--
gentoo-dev@lists.gentoo.org mailing list

Early stabilisation
 

Jeroen Roovers wrote:

Dear ebuild maintainers,


thirty days is the norm for the minimal period between an ebuilds last
non-keywording change while in the tree and the usual call for
stabilisation. If you cannot find a pressing reason to push
stabilisation forward, then don't ask. In the last few days I have seen
several early calls for stabilisation (bugs #217148, #217845, #217841
and #217839 for instance) where no adequate reason was given, in my
opinion.


Given that 3 of the 4 are from one person, I wouldn't draw broad
conclusion from this.



A good reason might be an important fix of a severe bug, a fix for a
build problem that couldn't be applied to a stable version but had to
go into an ebuild revision, or a version/revision that fixes a security
problem.

On the other hand, maybe these early stabilisation bug reports are a
sign of the times and we need to shorten the normal thirty day period,
become even more of a cutting edge distro - or at least discuss the
options.


I'd say leave the current norm and smack the misbehaving maintainers :)

Caster
--
gentoo-dev@lists.gentoo.org mailing list

Early stabilisation
 

Vlastimil Babka wrote:

Jeroen Roovers wrote:

On the other hand, maybe these early stabilisation bug reports are a
sign of the times and we need to shorten the normal thirty day period,
become even more of a cutting edge distro - or at least discuss the
options.


I'd say leave the current norm and smack the misbehaving maintainers :)


++

The whole point of stable is that it ISN'T completely cutting edge, and
30 days is hardly super-stale. If there is a pressing need to
accelerate we should do so, but otherwise I'd stick to the general
policy. Anybody who wants cutting edge can use ACCEPT_KEYWORDS as desired.

--
gentoo-dev@lists.gentoo.org mailing list

Early stabilisation
 

On Wed, 2008-04-16 at 11:49 +0200, Vlastimil Babka wrote:
> > thirty days is the norm for the minimal period between an ebuilds last

It is the norm. It is not a requirement. In fact, it is specifically a
"guideline" rather than a hard rule. It is up to the maintainer's
discretion when to ask for stabilization, just like it is up to the arch
team's discretion when to actually *do* the stabilization. If you don't
think that it's ready on your arch, say so, but be prepared to defend
why you think so when the package maintainer, who should be much more
familiar with the package, thinks that it is ready.

> > On the other hand, maybe these early stabilisation bug reports are a
> > sign of the times and we need to shorten the normal thirty day period,
> > become even more of a cutting edge distro - or at least discuss the
> > options.
>
> I'd say leave the current norm and smack the misbehaving maintainers :)

Who says that they're misbehaving? Again, the maintainers probably know
their packages better than anyone else, so why are we not trusting their
judgement again?

--
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer
--
gentoo-dev@lists.gentoo.org mailing list

Early stabilisation
 

Wed, 16 Apr 2008 12:09:24 -0700
Chris Gianelloni <wolf31o2@gentoo.org> kirjoitti:

> On Wed, 2008-04-16 at 11:49 +0200, Vlastimil Babka wrote:
> > > thirty days is the norm for the minimal period between an ebuilds
> > > last
>
> It is the norm. It is not a requirement. In fact, it is
> specifically a "guideline" rather than a hard rule. It is up to the
> maintainer's discretion when to ask for stabilization, just like it
> is up to the arch team's discretion when to actually *do* the
> stabilization. If you don't think that it's ready on your arch, say
> so, but be prepared to defend why you think so when the package
> maintainer, who should be much more familiar with the package, thinks
> that it is ready.
>
> > > On the other hand, maybe these early stabilisation bug reports
> > > are a sign of the times and we need to shorten the normal thirty
> > > day period, become even more of a cutting edge distro - or at
> > > least discuss the options.
> >
> > I'd say leave the current norm and smack the misbehaving
> > maintainers :)
>
> Who says that they're misbehaving? Again, the maintainers probably
> know their packages better than anyone else, so why are we not
> trusting their judgement again?
>

Thanks for this, I was going to reply in similar fashion but didn't
want to (accidentally) start flaming..

- drac
--
gentoo-dev@lists.gentoo.org mailing list

Early stabilisation
 

Samuli Suominen wrote:

Wed, 16 Apr 2008 12:09:24 -0700
Chris Gianelloni <wolf31o2@gentoo.org> kirjoitti:


On Wed, 2008-04-16 at 11:49 +0200, Vlastimil Babka wrote:

thirty days is the norm for the minimal period between an ebuilds
last

It is the norm. It is not a requirement. In fact, it is
specifically a "guideline" rather than a hard rule. It is up to the
maintainer's discretion when to ask for stabilization, just like it
is up to the arch team's discretion when to actually *do* the
stabilization. If you don't think that it's ready on your arch, say
so, but be prepared to defend why you think so when the package
maintainer, who should be much more familiar with the package, thinks
that it is ready.


Okay. So we can just agree it's better if the maintainer tells his
reasons when opening the bug, to spare the later clarifications?



On the other hand, maybe these early stabilisation bug reports
are a sign of the times and we need to shorten the normal thirty
day period, become even more of a cutting edge distro - or at
least discuss the options.

I'd say leave the current norm and smack the misbehaving
maintainers :)

Who says that they're misbehaving? Again, the maintainers probably
know their packages better than anyone else, so why are we not
trusting their judgement again?



Thanks for this, I was going to reply in similar fashion but didn't
want to (accidentally) start flaming..


Sorry I used a harsh word myself, didn't want to flame neither.

Caster
--
gentoo-dev@lists.gentoo.org mailing list

Early stabilisation
 

Thu, 17 Apr 2008 09:43:59 +0200
Vlastimil Babka <caster@gentoo.org> kirjoitti:

> Okay. So we can just agree it's better if the maintainer tells his
> reasons when opening the bug, to spare the later clarifications?

"It works. Do it."

- drac
--
gentoo-dev@lists.gentoo.org mailing list

Early stabilisation
 

On Thu, 17 Apr 2008 15:33:17 +0300
Samuli Suominen <drac@gentoo.org> wrote:

> Thu, 17 Apr 2008 09:43:59 +0200
> Vlastimil Babka <caster@gentoo.org> kirjoitti:
>
> > Okay. So we can just agree it's better if the maintainer tells his
> > reasons when opening the bug, to spare the later clarifications?
>
> "It works. Do it."

Then it will work just as well after a few more weeks. :)


Kind regards,
JeR
--
gentoo-dev@lists.gentoo.org mailing list


Thu Apr 17 21:30:01 2008
Return-path: <fedora-packaging-bounces@redhat.com>
Envelope-to: tom@linux-archive.org
Delivery-date: Thu, 17 Apr 2008 20:37:22 +0300
Received: from hormel1.redhat.com ([209.132.177.33] helo=hormel.redhat.com)
by s2.java-tips.org with esmtp (Exim 4.68)
(envelope-from <fedora-packaging-bounces@redhat.com>)
id 1JmY30-0002wk-2E
for tom@linux-archive.org; Thu, 17 Apr 2008 20:37:22 +0300
Received: from listman.util.phx.redhat.com (listman.util.phx.redhat.com [10.8.4.110])
by hormel.redhat.com (Postfix) with ESMTP id D7756618A32;
Thu, 17 Apr 2008 13:37:26 -0400 (EDT)
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com
[172.16.52.254])
by listman.util.phx.redhat.com (8.13.1/8.13.1) with ESMTP id
m3HHbOUw011644 for <fedora-packaging@listman.util.phx.redhat.com>;
Thu, 17 Apr 2008 13:37:24 -0400
Received: from mx3.redhat.com (mx3.redhat.com [172.16.48.32])
by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m3HHbNr3024691
for <fedora-packaging@redhat.com>; Thu, 17 Apr 2008 13:37:23 -0400
Received: from igw3.br.ibm.com (igw3.br.ibm.com [32.104.18.26])
by mx3.redhat.com (8.13.8/8.13.8) with ESMTP id m3HHbAsS008815
for <fedora-packaging@redhat.com>; Thu, 17 Apr 2008 13:37:11 -0400
Received: from mailhub3.br.ibm.com (unknown [9.18.232.110])
by igw3.br.ibm.com (Postfix) with ESMTP id 99CF4390110
for <fedora-packaging@redhat.com>;
Thu, 17 Apr 2008 14:23:52 -0300 (BRST)
Received: from d24av01.br.ibm.com (d24av01.br.ibm.com [9.18.232.46])
by mailhub3.br.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id
m3HHb5YE4182150
for <fedora-packaging@redhat.com>; Thu, 17 Apr 2008 14:37:05 -0300
Received: from d24av01.br.ibm.com (loopback [127.0.0.1])
by d24av01.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id
m3HHb4rK015302
for <fedora-packaging@redhat.com>; Thu, 17 Apr 2008 14:37:04 -0300
Received: from [9.18.238.24] (dyn531757.br.ibm.com [9.18.238.24])
by d24av01.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id
m3HHb4Mt015299
for <fedora-packaging@redhat.com>; Thu, 17 Apr 2008 14:37:04 -0300
From: =?ISO-8859-1?Q?S=E9rgio?= Durigan =?ISO-8859-1?Q?J=FAnior?=
<sergiodj@linux.vnet.ibm.com>
To: fedora-packaging@redhat.com
Content-Type: text/plain; charset=ISO-8859-1
Organization: LTC - IBM
Date: Thu, 17 Apr 2008 14:37:19 -0300
Message-Id: <1208453839.7258.13.camel@miki>
Mime-Version: 1.0
X-Mailer: Evolution 2.12.2
X-RedHat-Spam-Score: -2
X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254
X-Scanned-By: MIMEDefang 2.63 on 172.16.48.32
X-loop: fedora-packaging@redhat.com
Subject: [Fedora-packaging] 32- and 64-bit softwares living together
X-BeenThere: fedora-packaging@redhat.com
X-Mailman-Version: 2.1.5
Precedence: junk
Reply-To: Discussion of RPM packaging standards and practices for Fedora
<fedora-packaging@redhat.com>
List-Id: Discussion of RPM packaging standards and practices for Fedora
<fedora-packaging.redhat.com>
List-Unsubscribe: <https://www.redhat.com/mailman/listinfo/fedora-packaging>,
<mailto:fedora-packaging-request@redhat.com?subject=unsubscribe>
List-Archive: <https://www.redhat.com/archives/fedora-packaging>
List-Post: <mailto:fedora-packaging@redhat.com>
List-Help: <mailto:fedora-packaging-request@redhat.com?subject=help>
List-Subscribe: <https://www.redhat.com/mailman/listinfo/fedora-packaging>,
<mailto:fedora-packaging-request@redhat.com?subject=subscribe>
Sender: fedora-packaging-bounces@redhat.com
Errors-To: fedora-packaging-bounces@redhat.com
Content-Transfer-Encoding: quoted-printable

Hello folks,

I would like to know if there are any efforts to make both 32- and
64-bit versions of the same package "live" together in a system. I've
been finding some packages that unfortunately break when you install
both versions from the RPM (one example is Perl). Basically, what
usually happens is:

- The executable files for both 32- and 64-bit versions have the same
names (e.g., "perl", "python")

- The libraries for both versions are installed under /usr/lib

- Some other arch-dependent (therefore, bitness-dependent) files are
installed at the same place for both versions

Those 3 situations make the last installed version to override things
from the previous one.

So, do you intend to solve this problem in future versions of Fedora?

Thanks in advance,

--=20
S=E9rgio Durigan J=FAnior
Linux on Power Toolchain - Software Engineer
Linux Technology Center - LTC
IBM Brazil

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

Early stabilisation
 

On Thu, 17 Apr 2008 15:33:17 +0300
Samuli Suominen <drac@gentoo.org> wrote:

> "It works. Do it."

Oh by the way. This isn't directed toward you personally, but I
personally detest this "do it" attitude. You wouldn't say that to my
face, would you? (Trust me, you would regret it.) :)


JeR
--
gentoo-dev@lists.gentoo.org mailing list

Early stabilisation
 

On Thu, 2008-04-17 at 19:38 +0200, Jeroen Roovers wrote:
> On Thu, 17 Apr 2008 15:33:17 +0300
> Samuli Suominen <drac@gentoo.org> wrote:
>
> > "It works. Do it."
>
> Oh by the way. This isn't directed toward you personally, but I
> personally detest this "do it" attitude. You wouldn't say that to my
> face, would you? (Trust me, you would regret it.) :)

What attitude do you prefer? How about the prevailing "let's talk about
it forever and do nothing" attitude, instead?

Seriously, we should be "doing it" much more than we should be sitting
around patting each other on the backs. We're not here to stroke each
other's egos. We're here to write software. Any chance we can get
ourselves back to getting things *done* and getting them done in a
decent time-frame? It's very simple. If you don't have time to do
something, don't do it. However, the common courtesy in such cases
would be to inform the requester of said time constraint, so he can
either adjust his expectations, or find someone else to do the work.

--
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer
--
gentoo-dev@lists.gentoo.org mailing list