public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: "William L. Thomson Jr." <wlt-ml@o-sinc.com>
To: Michael Orlitzky <mjo@gentoo.org>
Cc: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Revisions for USE flag changes
Date: Mon, 14 Aug 2017 12:29:25 -0400	[thread overview]
Message-ID: <assp.0399b0fd74.20170814122925.35ceae16@o-sinc.com> (raw)
In-Reply-To: <dcd0a224-f00e-9e5e-53ef-30ed46ee2280@gentoo.org>

[-- Attachment #1: Type: text/plain, Size: 2096 bytes --]

On Sun, 13 Aug 2017 12:12:39 -0400
Michael Orlitzky <mjo@gentoo.org> wrote:

> On 08/13/2017 12:06 PM, William Hubbs wrote:
> > 
> > There is a down side you didn't talk about -- more work for the arch
> > teams and for us in terms of stabilizations.
> > 
> > When we revbump, a new revision automatically gets ~ keywords on
> > all arches unless we make an exception. If a revision changes iuse
> > but could still be built with the stable tree, I would want to be
> > able to commit this type of revision  directly to stable.
> >   
> 
> I don't think you should be adding features and code to stable ebuilds
> in the first place, but if you're going to do it, then I wouldn't let
> a little -r1 on the end of the filename stop you =P

I agree stable ebuilds should not be modified. What William Hubbs is
talking about is the work it creates on others. Which I am not sure can
be avoided as things are now with stablization process and policies.

Change IUSE of stable package. It becomes ~arch. Then it has to wait
~30 days to go stable. Which means it requires a arch tester, and then
someone to clean the old version before the IUSE change. That is the
extra work.

I think the difference is the package maybe using a stable tree, but
the change may cause the package itself to be unstable. Therefore
should go through the normal stabilization process. Despite being
stable before revbump. Not so much the env but the package itself.

P.S.
For my own reasons in my overlay I will skip a revbump at times when
making changes to an ebuild. But that is me doing stuff in my own repo
and with few users of my overlay. I know it is not the proper work flow.
Just cutting corners to save time.

My main reason to avoid is not lazyiness, as it is issues with my
ebuild-bumper. It does not handle -r*. If I am bumping a series of
packages with version A, to version B, if one has -r1 it requires
special attention. This is a personal thing in a personal overlay
outside of Gentoo. It would not be proper within Gentoo repos.

-- 
William L. Thomson Jr.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

  reply	other threads:[~2017-08-14 16:29 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-11 23:50 [gentoo-dev] Revisions for USE flag changes Michael Orlitzky
2017-08-12  0:45 ` Brian Evans
2017-08-12  0:59   ` Michael Orlitzky
2017-08-12  1:04     ` Michael Orlitzky
2017-08-12  1:11     ` Brian Evans
2017-08-12  8:39       ` Paweł Hajdan, Jr.
2017-08-12  9:58         ` Michael Orlitzky
2017-08-13  2:52           ` [gentoo-dev] " Duncan
2017-08-13 10:11             ` Michael Orlitzky
2017-08-13 10:18               ` M. J. Everitt
2017-08-14  1:34                 ` Duncan
2017-08-16 20:12               ` Daniel Campbell
2017-08-18 14:50             ` Duncan
2017-08-13  5:01           ` [gentoo-dev] " Hans de Graaff
2017-08-13 10:38             ` Michael Orlitzky
     [not found]               ` <CAJ0EP42EaW8=dm0c26Gaij9gEAmTVHxiyp5+Hc_CYGzEypudsA@mail.gmail.com>
     [not found]                 ` <CAJ0EP40yVVpLqHL5qVixxgvMmJc7ezRsn42qLoe621wS0KF-VA@mail.gmail.com>
     [not found]                   ` <CAJ0EP43YbX-vA5cWcFm_Etin4H31Nq2s_xYsrTwuOK6LVyW+9A@mail.gmail.com>
     [not found]                     ` <CAJ0EP42HkoYEkL1vt=Lyt-Dw-1XkdAXed8DrBp4oYB9j01+PKQ@mail.gmail.com>
2017-08-13 17:28                       ` Mike Gilbert
2017-08-12  4:22 ` [gentoo-dev] " Michael Palimaka
2017-08-12 10:16   ` Michael Orlitzky
2017-08-12 10:58     ` Michael Palimaka
2017-08-12 10:32   ` Rich Freeman
2017-08-12  5:02 ` [gentoo-dev] " Hans de Graaff
2017-08-12  7:03 ` Michał Górny
2017-08-12  9:57   ` Michael Orlitzky
2017-08-12 10:04     ` Toralf Förster
2017-08-12 10:29     ` Rich Freeman
2017-08-12 11:05       ` [gentoo-dev] " Michael Palimaka
2017-08-12 11:18         ` Rich Freeman
2017-08-14 12:01         ` Jason Zaman
2017-08-16  3:22           ` Michael Orlitzky
2017-08-16 15:56             ` Duncan
2017-08-16 16:09               ` Rich Freeman
2017-08-17  4:27             ` Jason Zaman
2017-08-12 14:14       ` [gentoo-dev] " Michael Orlitzky
2017-08-13  2:32         ` [gentoo-dev] " Duncan
2017-08-13 10:08           ` Michael Orlitzky
2017-08-13 16:06 ` [gentoo-dev] " William Hubbs
2017-08-13 16:12   ` Michael Orlitzky
2017-08-14 16:29     ` William L. Thomson Jr. [this message]
2017-08-14 16:21 ` William L. Thomson Jr.

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=assp.0399b0fd74.20170814122925.35ceae16@o-sinc.com \
    --to=wlt-ml@o-sinc.com \
    --cc=gentoo-dev@lists.gentoo.org \
    --cc=mjo@gentoo.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox