public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Tobias Klausmann <klausman@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] New ebuild metadata to mark how robust the package is?
Date: Sat, 17 Oct 2009 11:27:18 +0200	[thread overview]
Message-ID: <20091017092718.GA13018@eric.schwarzvogel.de> (raw)
In-Reply-To: <4AD9571A.8010602@gentoo.org>

Hi! 

On Sat, 17 Oct 2009, Rémi Cardona wrote:
> Now we (gentoo devs) are finally starting to add news items for
> bigger updates (gnome, X, java, etc) and that's a good thing.
> But we definitely cannot and should not use news items for
> minor upgrades.
> 
> elog is much better suited for such upgrade notices.
> 
> However, since elog was put in portage, ebuilds have been using
> elog/ewarn/einfo _way_ too much. We're now at a point where the
> elog output at the end of an emerge phase is just _useless_
> because of all the noise.

One problem with this is that there is no way to "Acknowledge"
such ewarns/einfos. For example, I really, honestly know that
vanilla-sources isn't supported; I don't need the reminder every
time I upgrade it. Neither does the message from gentoo-sources
help me in any way anymore.

Come to think of it, how about an ewarn/einfo that is only
triggered on fresh installs, but not on upgrades? You can still
warn that foobard needs an etc-update and a restart, but I don't
need to be reminded where the examples are every time.

Ideally, one would be an einfo and one an ewarn, but in my
experience, many messages are ewarns "to be safe" (or so I
suspect).

> And with your metadata proposal, I'm worried the same thing
> will happen. Devs will enable the "troublesome" flag for a
> release, forget to remove it for the next bump and a few months
> later, half the packages in portage are labeled as such.
> 
> I really don't want to sound like I want to kill your idea but
> I'm somewhat doubtful it'll really work given our track record
> with other such infrastructure.

As usual with such things, it should as simple as possible to
use, especially when only bumping a package (hence my idea of
separate "one-shot" message functions).


Regards,
Tobias
-- 
printk ("Barf\n");
        linux-2.6.6/arch/v850/kernel/module.c



  reply	other threads:[~2009-10-17  9:27 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1255733421-30950-mlmmj-4f4db363@lists.gentoo.org>
2009-10-16 23:29 ` [gentoo-dev] New ebuild metadata to mark how robust the package is? Daniel Bradshaw
2009-10-16 23:48   ` Jeremy Olexa
2009-10-17  0:50   ` [gentoo-dev] " Ryan Hill
2009-10-17  5:33   ` [gentoo-dev] " Rémi Cardona
2009-10-17  9:27     ` Tobias Klausmann [this message]
2009-10-17  9:47       ` Petteri Räty
2009-10-17  7:53   ` Patrick Lauer
2009-10-18  0:10     ` [gentoo-dev] " Duncan
2009-10-21 12:45       ` Ladislav Laska
2009-10-21 15:21         ` Ladislav Laska
2009-10-21 16:30           ` William Hubbs
2009-10-26 12:55             ` Ladislav Laska
2009-10-26 21:49               ` Duncan

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=20091017092718.GA13018@eric.schwarzvogel.de \
    --to=klausman@gentoo.org \
    --cc=gentoo-dev@lists.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