[gentoo-dev] RFC: modifications to GLEP42

[gentoo-dev] RFC: modifications to GLEP42

[Mike Doty]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

All-

After some discussion on #-dev there are some improvements that we can
make on glep 42.

1.  Priority levels for news items:  If we did this users could decide
what levels of importance to filter out.

2.  Standards for news items:  Based on the paludis news item thread,
it's clear we need some standards for what we release as news.  If
combined with #1 we can set different standards and give the users some
more choice on what they accept and what we publish.

Discuss.
- --
=======================================================
Mike Doty                      kingtaco -at- gentoo.org
Gentoo Council
Gentoo Infrastructure
Gentoo/AMD64 Strategic Lead
GPG: E1A5 1C9C 93FE F430 C1D6  F2AF 806B A2E4 19F4 AE05
=======================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.3 (GNU/Linux)

iQCVAwUBRjz2l4BrouQZ9K4FAQKDUAQA4FKbVvnunf1ePgpRGD5lKRFNgm8eG1KO
CXOT4uCFeWFR3Oz02ncVXBdpOxG4/1VhgfRi3ZoMf0r1TVo0T99t+543J6POUU6v
ncu5w7U+6k/HsfyVGJAUEygGGdr2b1c8DT+8ong4H0MgwUc2AhmjfU/rUx96ZWRN
wNlY1bpMAfU=
=5Elf
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: modifications to GLEP42

[Ciaran McCreesh]

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

On Sat, 05 May 2007 14:26:48 -0700
Mike Doty <kingtaco@gentoo.org> wrote:
> After some discussion on #-dev there are some improvements that we can
> make on glep 42.

Well, if you're going about improving it, start by adding in the
Display-If-Upgrading-From-To: header. It'll be a nuisance to implement,
but it'll be far more useful than any of the rest of this.

> 1.  Priority levels for news items:  If we did this users could decide
> what levels of importance to filter out.

That'll just increase the amount of disagreement about news items
because it'll give people more pointless wording to argue over.

> 2.  Standards for news items:  Based on the paludis news item thread,
> it's clear we need some standards for what we release as news.  If
> combined with #1 we can set different standards and give the users
> some more choice on what they accept and what we publish.

It's quite simple. If releasing a news item improves the user
experience of affected users more than not releasing it, the news item
should be released.

-- 
Ciaran McCreesh


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] RFC: modifications to GLEP42

[Mike Doty]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ciaran McCreesh wrote:
> On Sat, 05 May 2007 14:26:48 -0700
> Mike Doty <kingtaco@gentoo.org> wrote:
>> After some discussion on #-dev there are some improvements that we can
>> make on glep 42.
> 
> Well, if you're going about improving it, start by adding in the
> Display-If-Upgrading-From-To: header. It'll be a nuisance to implement,
> but it'll be far more useful than any of the rest of this.
Your word doesn't inspire most of us.  If you think this is a good idea,
you need to explain why.

>> 1.  Priority levels for news items:  If we did this users could decide
>> what levels of importance to filter out.
> 
> That'll just increase the amount of disagreement about news items
> because it'll give people more pointless wording to argue over.
Item #2 covers that.

>> 2.  Standards for news items:  Based on the paludis news item thread,
>> it's clear we need some standards for what we release as news.  If
>> combined with #1 we can set different standards and give the users
>> some more choice on what they accept and what we publish.
> 
> It's quite simple. If releasing a news item improves the user
> experience of affected users more than not releasing it, the news item
> should be released.
It clearly isn't that simple.


- --
=======================================================
Mike Doty                      kingtaco -at- gentoo.org
Gentoo Council
Gentoo Infrastructure
Gentoo/AMD64 Strategic Lead
GPG: E1A5 1C9C 93FE F430 C1D6  F2AF 806B A2E4 19F4 AE05
=======================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.3 (GNU/Linux)

iQCVAwUBRjz60IBrouQZ9K4FAQLGlAP/cnsW1nE+VUbyDiHjZ+kXaRd18gs3mjCp
zbQZ23DTHNc/Jr0UnqVXuY/RzsLnrFyRD5kzDgoh4wVMAIgyYHM76BuLLTpE/Tyi
yaARIKke8LsK04FO0MgVAapBSQmh2jo42n3KrJsghOXuX7Q9O0RpIkmMJf+Sq2Z/
Cg2G2Fo+qgk=
=iTKs
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: modifications to GLEP42

[Ciaran McCreesh]

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

On Sat, 05 May 2007 14:44:49 -0700
Mike Doty <kingtaco@gentoo.org> wrote:
> > Well, if you're going about improving it, start by adding in the
> > Display-If-Upgrading-From-To: header. It'll be a nuisance to
> > implement, but it'll be far more useful than any of the rest of
> > this.
>
> Your word doesn't inspire most of us.  If you think this is a good
> idea, you need to explain why.

There's no way to mark a news item as "to be read" when a user upgrades
from, say, <foo/bar-1.2 to >=foo/bar-1.2 . Ideally there would be. It
wasn't in the first GLEP because it's trickier from a package manager
implementation perspective.

> >> 2.  Standards for news items:  Based on the paludis news item
> >> thread, it's clear we need some standards for what we release as
> >> news.  If combined with #1 we can set different standards and give
> >> the users some more choice on what they accept and what we publish.
> > 
> > It's quite simple. If releasing a news item improves the user
> > experience of affected users more than not releasing it, the news
> > item should be released.
>
> It clearly isn't that simple.

Well, it is in theory. In practice determining into which category a
particular news item falls isn't so easy. Perhaps this should be left
alone until after we have experience delivering, say, a few dozen news
items to a wider audience. Currently the only evidence we have as to
the level of news items expected by users is fairly limited.

-- 
Ciaran McCreesh


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] RFC: modifications to GLEP42

[expose]

Ciaran McCreesh wrote:
> That'll just increase the amount of disagreement about news items
> because it'll give people more pointless wording to argue over.
After all, something I agree with.

> It's quite simple. If releasing a news item improves the user
> experience of affected users more than not releasing it, the news item
> should be released.
What exactly in "Critical News Reporting" is unclear here?
As everyone still talks about "News Reporting" it has to be the "Critical".
Let's try to define it:
"News items must only be for important changes that may cause serious upgrade 
or compatibility problems." (Source is GLEP 42)
Let's get the next thing straight:
Paludis will still work, after the upgrade, but it will produce warnings.
So there are no problems at all, it still works just fine.

Plus, a message saying
"You still use the old config file format. Please replace * with */*"
can hardly be misunderstood, in contrast to what you claimed when saying
> Experience has shown that without a news item, many users will ask for
> clarification or confirmation before making any changes, and with a
> news item users will be reassured that they're doing the right thing
> and that this is a deliberate change.
(Ciaran McCreesh today on 23:06:31)

If users dont trust the warning the code produces, why should they believe in 
a news item?

It just aint a critical issue, unless Paludis will stop working unless the 
config is fixed, and deliberatly breaking it now, to get that news item 
anyway, is
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: modifications to GLEP42

[Ciaran McCreesh]

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

On Sun, 6 May 2007 00:00:11 +0200
expose@luftgetrock.net wrote:
> Paludis will still work, after the upgrade, but it will produce
> warnings. So there are no problems at all, it still works just fine.

Paludis producing a warning (as opposed to a lower level notice --
Paludis has different levels for log notices, of which 'warning' is
the highest) is something that is considered critical enough that the
user should fix it before continuing. Were it not critical, a different
log level would be used.

This thread is not, however, about Paludis. Please keep future moaning
about Paludis in the appropriate thread.

-- 
Ciaran McCreesh


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] RFC: modifications to GLEP42

[expose]

Ciaran McCreesh wrote:
> Paludis producing a warning (as opposed to a lower level notice --
> Paludis has different levels for log notices, of which 'warning' is
> the highest) is something that is considered critical enough that the
> user should fix it before continuing. Were it not critical, a different
> log level would be used.
Paludis log levels are irrelevant.
The recent change in the cups.conf is no more or less critical that the one in 
Paludis: something changed without causing things to breaks --> it is not 
critical, as it wont be more or less work to fix it before or after running 
the application again, although doing so beforehand is perferred.
You say it yourself: "the user should fix it before continuing"
"should" not "has to"
It is critical if your filesystem might be damaged, if there are security 
issues of any kind, or if something stops working.

A simply warning because a deprecated config format is used, just aint 
critical.
If I am wrong here, I bet the majority of Gentoo developers would jump in and 
start correcting me. If they wont, I would suggest you just accept this, and 
use einfo or whatever you like to.
By doing so you alone would be able do save each and everyone of us reading 
this list time and/or bandwidth.

> This thread is not, however, about Paludis. Please keep future moaning
> about Paludis in the appropriate thread.
Perfectly correct, it is about this news item being critical or not.
I were not the one who started to talk about log levels, which is off-topic.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: modifications to GLEP42

[expose]

I wrote:
> Ciaran McCreesh wrote:
> > This thread is not, however, about Paludis. Please keep future moaning
> > about Paludis in the appropriate thread.
>
> Perfectly correct, it is about this news item being critical or not.
> I were not the one who started to talk about log levels, which is
> off-topic.
Confuse the issue.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: modifications to GLEP42

[Ciaran McCreesh]

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

On Sun, 6 May 2007 00:25:20 +0200
expose@luftgetrock.net wrote:
> It is critical if your filesystem might be damaged, if there are
> security issues of any kind, or if something stops working.

It is critical if it requires manual action by many or the majority of
targetted users.

-- 
Ciaran McCreesh


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] RFC: modifications to GLEP42

[Richard Freeman]

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ciaran McCreesh wrote:
> On Sun, 6 May 2007 00:25:20 +0200
> expose@luftgetrock.net wrote:
>> It is critical if your filesystem might be damaged, if there are
>> security issues of any kind, or if something stops working.
> 
> It is critical if it requires manual action by many or the majority of
> targetted users.
> 

I might offer a primarily-end-user perspective.

First - the ELOG feature added a few months back (allowing emailing of
notices/etc) is GREAT!  Now I can track read/unread using my email
software, which is clearly suited to such purposes.

I think that this mechanism is ideal for most notices.  However, maybe I
can suggest a few categories that need advance warning:

1.  Cases where upgrading a major dependency requires revdep-rebuild.
For example, if my glibc upgrade borks half the system until I recompile
3/4ths of it I'd like to know about that BEFORE installing it.

2.  Updates to server-oriented software (sendmail/ postfix/ apache/
mysql/ postgres/ mythtv/ etc) that require significant manual tweaks.
People running this kind of software generally don't want unexpected
downtime, even in situations that don't demand test environments.

3.  Updates of any kind that could prevent booting or network access if
mishandled.  You don't want users leaving their systems in an unbootable
state for more than a few minutes, or in a state where it is hard to get
to online info.

4.  Anything security-related that requires advance warning.  Honestly,
I couldn't think of an example of this.  If a package leaves the system
insecure by default that would qualify, but I doubt anybody would design
such a package in the first place.

I think that what is really needed are guidelines.  No user is going to
complain about getting 14 news items when they should have gotten 13.
On the other hand, if they get 100 instead of 5 that would be an issue.
 As long as we don't go hog-wild I'd think that any issues would be
easily addressed with time.  Right now I think users would appreciate
advance notice about some things that have caused major headaches in the
past (ABI breaks/etc).

I think the priority setting idea was a good one - even if people argue
over whether something is a 3 or a 4 on the 1-5 scale, at least we know
the difference between a 1 and a 5.  And I'd like to think that devs
have better things to do than nitpick each other's ebuilds over things
like that...  :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGPS0BG4/rWKZmVWkRAm+cAJ9pmr17brezGsdw3v7LIq9ARveinwCfUB3d
Oo3vanOr3cewFgc8DDjfzVo=
=tRk/
-----END PGP SIGNATURE-----

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3875 bytes --]

Re: [gentoo-dev] RFC: modifications to GLEP42

[Dan Meltzer]

On Saturday 05 May 2007 5:34:29 pm Ciaran McCreesh wrote:
> On Sat, 05 May 2007 14:26:48 -0700
>
> Mike Doty <kingtaco@gentoo.org> wrote:
> > After some discussion on #-dev there are some improvements that we can
> > make on glep 42.
>
> Well, if you're going about improving it, start by adding in the
> Display-If-Upgrading-From-To: header. It'll be a nuisance to implement,
> but it'll be far more useful than any of the rest of this.
>
> > 1.  Priority levels for news items:  If we did this users could decide
> > what levels of importance to filter out.
>
> That'll just increase the amount of disagreement about news items
> because it'll give people more pointless wording to argue over.
>
> > 2.  Standards for news items:  Based on the paludis news item thread,
> > it's clear we need some standards for what we release as news.  If
> > combined with #1 we can set different standards and give the users
> > some more choice on what they accept and what we publish.
>
> It's quite simple. If releasing a news item improves the user
> experience of affected users more than not releasing it, the news item
> should be released.

mmm, by this arguement news should be written for every version bump, 
explaining what has changed in the package that is user visible.  It would 
definatly improve the users experience if they knew what they were upgrading 
to, not just that they were upgrading.


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: modifications to GLEP42

[Petteri Räty]

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

Dan Meltzer kirjoitti:
> 
> mmm, by this arguement news should be written for every version bump, 
> explaining what has changed in the package that is user visible.  It would 
> definatly improve the users experience if they knew what they were upgrading 
> to, not just that they were upgrading.
> 

For the standard version bumps people should be documenting things like
this in ChangeLog. Too bad it's usually just "Version bump. Fixes bug
#XXXXXX."

Regards,
Petteri


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

Re: [gentoo-dev] RFC: modifications to GLEP42

[Jakub Moc]

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

Petteri Räty napsal(a):
> Dan Meltzer kirjoitti:
>> mmm, by this arguement news should be written for every version bump, 
>> explaining what has changed in the package that is user visible.  It would 
>> definatly improve the users experience if they knew what they were upgrading 
>> to, not just that they were upgrading.
>>
> 
> For the standard version bumps people should be documenting things like
> this in ChangeLog. Too bad it's usually just "Version bump. Fixes bug
> #XXXXXX."

Well, 'fixes bug #XXXXXX' is still way more useful entry than 'many
bugfixes' or nothing at all in ChangeLog - which is not so rare at all,
unfortunately :/


-- 
Best regards,

 Jakub Moc
 mailto:jakub@gentoo.org
 GPG signature:
 http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature   ;)


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

Re: [gentoo-dev] RFC: modifications to GLEP42

[Marius Mauch]

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

On Sat, 05 May 2007 14:26:48 -0700
Mike Doty <kingtaco@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> All-
> 
> After some discussion on #-dev there are some improvements that we can
> make on glep 42.
> 
> 1.  Priority levels for news items:  If we did this users could decide
> what levels of importance to filter out.
> 
> 2.  Standards for news items:  Based on the paludis news item thread,
> it's clear we need some standards for what we release as news.  If
> combined with #1 we can set different standards and give the users
> some more choice on what they accept and what we publish.

0.) Reevaluate/refine the goal that glep 42 is supposed to achieve. As
the previous discussion has shown there are different interpretations
about that.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] RFC: modifications to GLEP42

[Petteri Räty]

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

Jakub Moc kirjoitti:
> Petteri Räty napsal(a):
>> Dan Meltzer kirjoitti:
>>> mmm, by this arguement news should be written for every version bump, 
>>> explaining what has changed in the package that is user visible.  It would 
>>> definatly improve the users experience if they knew what they were upgrading 
>>> to, not just that they were upgrading.
>>>
>> For the standard version bumps people should be documenting things like
>> this in ChangeLog. Too bad it's usually just "Version bump. Fixes bug
>> #XXXXXX."
> 
> Well, 'fixes bug #XXXXXX' is still way more useful entry than 'many
> bugfixes' or nothing at all in ChangeLog - which is not so rare at all,
> unfortunately :/
> 

Repoman could be made to not commit stuff if new files are added without
a ChangeLog entry. This should be fairly easy to implement even with the
repoman code base.

https://bugs.gentoo.org/show_bug.cgi?id=177290

Regards,
Petteri


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