[gentoo-dev] Re: News item: Upgrading Apache from 2.2 to 2.4

2016-01-14 Thread Duncan
Dirkjan Ochtman posted on Wed, 13 Jan 2016 18:13:41 +0100 as excerpted:

> Display-If-Installed: www-servers/apache

Can't that be made 

Re: [gentoo-dev] RFD: News item format 2.0

2016-01-14 Thread Rich Freeman
On Tue, Jan 12, 2016 at 1:13 PM, Ulrich Mueller  wrote:
>
> Therefore, we could use the opportunity to add some other features.
> So far, this includes:
>

I don't have a solution for this in mind, but I do see a problem that
could use a solution with our current approach to news in our stable
and unstable branches.

Using the current criteria we have for displaying news items it is
very hard to prepare a news item that is displayed at an appropriate
time for both stable and unstable users of a package.  Either the
unstable users don't get the news item at all, or everybody gets it at
the same time.  Then stable users end up getting confused and
eventually forgetting about the notice, only to be hit with the update
after a significant time lag (it could be a year or more in some
cases) without any advance news.

One way to do this (and I'm certainly open to others) is a
Display-If-Installable header which takes a keyword string and an atom
(typically a specific PV).  The package manager would determine if a
package with that keyword string and PV would be accepted or not based
on the user's configuration, and if so display the news.  So, if the
string "~amd64 ~x86", =www-client/apache-2.4.19 were passed, users
running ~arch would generally get the message, as would a user running
stable but with 

[gentoo-dev] New project: Vim

2016-01-14 Thread Michael Palimaka
I am announcing the Vim project[1], to replace the old herd in
preparation for the implementation of GLEP 67.

1: https://wiki.gentoo.org/wiki/Project:Vim






Re: [gentoo-dev] RFD: News item format 2.0

2016-01-14 Thread Rich Freeman
On Thu, Jan 14, 2016 at 4:30 PM, Michał Górny  wrote:
> For example, for foo-1.0 to -2.0 upgrade notes, we'd do:
>
>   Display-if-installed:Display-if-visible: >=foo-2.0
>
> which would basically mean that all people having old foo installed
> would get the item as soon as they foo-2.0 becomes visible to them.
> But people installing straight 2.0 without previous versions don't get
> the item.

This works, but does require 2.0 to be in the tree already.  It is
obviously simpler as a result.

I think it still makes sense - users just need to check news before
they update.  We couldn't put out the news items a few days in advance
this way.

So, ++ from me.

-- 
Rich



Re: [gentoo-dev] RFD: News item format 2.0

2016-01-14 Thread Ulrich Mueller
> On Thu, 14 Jan 2016, Michał Górny wrote:

> On Thu, 14 Jan 2016 07:28:43 -0500
> Rich Freeman  wrote:

>> One way to do this (and I'm certainly open to others) is a
>> Display-If-Installable header which takes a keyword string and an
>> atom (typically a specific PV).  The package manager would
>> determine if a package with that keyword string and PV would be
>> accepted or not based on the user's configuration, and if so
>> display the news.

> Based on your idea, this is how I'd do it:

> 1. 'Display-If-Visible' that enables news items if given atom is
> visible for PM (i.e. in repo, with right keywords and not masked).
> I would avoid using 'Installable' as that could get confusing wrt
> conflicts and so on.

I had omitted the Display-If-Visible header (which has been discussed
since 2007 at least) deliberately, because we want to get format 2.0
done in a timely manner.

The problem with any visibility filtering is that visibility depends
on user configuration [1], and I don't know what changes in the
package manager would be necessary to make this work correctly and
efficiently. For example, how does portage's --autounmask-write option
interact with it?

Ulrich

[1] https://bugs.gentoo.org/show_bug.cgi?id=290038#c9


pgpFIzoHHeYcY.pgp
Description: PGP signature


[gentoo-dev] Last rites: dev-java/gjdoc

2016-01-14 Thread James Le Cuirot
# James Le Cuirot  (14 Jan 2016)
# Superseded by gnu-classpath. Removal in 30 days.
dev-java/gjdoc

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpPhzrbhs11f.pgp
Description: OpenPGP digital signature


[gentoo-dev] New project: Cron

2016-01-14 Thread Michael Palimaka
I am announcing the Cron project[1], to replace the old herd in
preparation for the implementation of GLEP 67.

1: https://wiki.gentoo.org/wiki/Project:Cron






[gentoo-dev] New project: SuperH

2016-01-14 Thread Michael Palimaka
I am announcing the SuperH project[1], to replace the old herd in
preparation for the implementation of GLEP 67.

1: https://wiki.gentoo.org/wiki/Project:SuperH






Re: [gentoo-dev] RFD: News item format 2.0

2016-01-14 Thread Michał Górny
On Thu, 14 Jan 2016 07:28:43 -0500
Rich Freeman  wrote:

> On Tue, Jan 12, 2016 at 1:13 PM, Ulrich Mueller  wrote:
> >
> > Therefore, we could use the opportunity to add some other features.
> > So far, this includes:
> >  
> 
> I don't have a solution for this in mind, but I do see a problem that
> could use a solution with our current approach to news in our stable
> and unstable branches.
> 
> Using the current criteria we have for displaying news items it is
> very hard to prepare a news item that is displayed at an appropriate
> time for both stable and unstable users of a package.  Either the
> unstable users don't get the news item at all, or everybody gets it at
> the same time.  Then stable users end up getting confused and
> eventually forgetting about the notice, only to be hit with the update
> after a significant time lag (it could be a year or more in some
> cases) without any advance news.

I was going to speak about this, and you beat me up to it...

> One way to do this (and I'm certainly open to others) is a
> Display-If-Installable header which takes a keyword string and an atom
> (typically a specific PV).  The package manager would determine if a
> package with that keyword string and PV would be accepted or not based
> on the user's configuration, and if so display the news.  So, if the
> string "~amd64 ~x86", =www-client/apache-2.4.19 were passed, users
> running ~arch would generally get the message, as would a user running
> stable but with  not a user running stable with  package.keywords.  If a user already was running
> www-client/apache-2.4.21 the news would not display since the package
> manager wouldn't attempt to install 2.4.19 if it showed up in the tree
> (I'm open to argument as to whether it should show up if 2.4.19 is
> already installed as there are pros and cons here).  Note that this is
> all hypothetical and the news should be triggered even if 2.4.19 isn't
> in the tree yet, or if it is in the tree with a different set of
> keywords.
> 
> Now, this would still potentially require putting the same news item
> into the tree multiple times to trigger it for the unstable/stable
> users, but the key would be that the right users get the message when
> this happens.  Since the details of the news and what PV it applies to
> might change between unstable/stable this is probably appropriate
> anyway.  Likewise if three archs are going stable now and two more a
> year from now the news could be re-triggered just for those archs.
> 
> The main downside to this I see is complexity - you can't just set up
> one news item and have it do the right thing.  The main advantage I
> see to this is correctness - it handles both the case where keywords
> are set in make.conf and package.keywords, because it provides enough
> of a hint to the package manager about what is about to be introduced
> into the tree.
> 
> There could easily be a better solution for this.  However, I think it
> is a problem worth solving.

...and I think you've found a pretty good solution to the problem.
However, I get lost in your wall of text and I don't really see
the problems you see.

Based on your idea, this is how I'd do it:

1. 'Display-If-Visible' that enables news items if given atom is
visible for PM (i.e. in repo, with right keywords and not masked).
I would avoid using 'Installable' as that could get confusing wrt
conflicts and so on.

2. Combine that with 'Display-If-Installed' -- and we should be able to
get somewhat sane behavior.

For example, for foo-1.0 to -2.0 upgrade notes, we'd do:

  Display-if-installed: =foo-2.0

which would basically mean that all people having old foo installed
would get the item as soon as they foo-2.0 becomes visible to them.
But people installing straight 2.0 without previous versions don't get
the item.

We could also do:

  Display-if-installed: foo
  Display-if-visible: >=foo-2.0

which would cause the item to be displayed to both people who have old
foo installed and can upgrade, or installed 2.0 directly.

-- 
Best regards,
Michał Górny



pgpHvRxx4n_iB.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: News item: Upgrading Apache from 2.2 to 2.4

2016-01-14 Thread Dirkjan Ochtman
On Thu, Jan 14, 2016 at 10:53 AM, Duncan <1i5t5.dun...@cox.net> wrote:
>> Display-If-Installed: www-servers/apache
>
> Can't that be made  2.4 need a news item about something they've already taken care of?

This makes sense to me, though I imagine it could be annoying if
people (stupidly, but whatever) postpone reading their news items
until after the upgrade. Is this a canonical approach? Would like some
feedback from the experts, here!

Cheers,

Dirkjan



Re: [gentoo-dev] News item: Upgrading Apache from 2.2 to 2.4

2016-01-14 Thread Marc Schiffbauer
* Dirkjan Ochtman schrieb am 14.01.16 um 22:41 Uhr:
> On Thu, Jan 14, 2016 at 10:53 AM, Duncan <1i5t5.dun...@cox.net> wrote:
> >> Display-If-Installed: www-servers/apache
> >
> > Can't that be made  > 2.4 need a news item about something they've already taken care of?
> 
> This makes sense to me, though I imagine it could be annoying if
> people (stupidly, but whatever) postpone reading their news items
> until after the upgrade. Is this a canonical approach? Would like some
> feedback from the experts, here!


Personally I'd not like it, when the news item will disappear right 
after the upgrade. So I'd prefer to not change it.

-Marc

> 
> Cheers,
> 
> Dirkjan
> 

-- 
0x35A64134 - 8AAC 5F46 83B4 DB70 8317
 3723 296C 6CCA 35A6 4134


signature.asc
Description: Digital signature