[sles-beta] php disappeared in beta6?

[Pieter Hollants]

That would exactly be the right solution to get the best of both: not complicating customers' install scenarios further AND satisfying other customer's demands for up-to-date PHP, Python, younameit. 
Otherwise, as suggested, SUSE should make sure to create a addon ISO as well. You can perfectly offer that ISO download subject to the same support lifecycle statements as the online repo. Maybe a SLEWEB addon as for HA.

We perfectly understand that SUSE doesn't want to raise assumptions that PHP etc. can be supported in the same way as, say, core-utils, and that's fine. But at the same time SUSE needs to understand customer requirements. And as long as your next German flight's security is guaranteed by months-taking software approval procedures, we need ISOs, not online repos.

-----Ursprüngliche Nachricht-----
Von: sles-beta-bounces at lists.suse.com [mailto:sles-beta-bounces at lists.suse.com] Im Auftrag von Joe Doupnik
Gesendet: Donnerstag, 15. Mai 2014 13:17
An: sles-beta at lists.suse.com
Betreff: Re: [sles-beta] php disappeared in beta6?

     If I might clarify procedures, it would go like this.
     Let us distinguish between tail and dog in this part of things. 
That means ship PHP and many other standard items as before, providing the long term base, and those are part of DVD1 when we build a server. 
No removed functionality at installation time. That's the pooch. 
Alternatives, which I am pleased to see, are options, "tail" items, which might require yet another set of channels or be on DVD1 in a useful manner. To be candid, the multiplicity of channels is getting out of hand, but I don't have a clever solution to cite here.
     The reason I chose those strong words is because they represent what we in the field would be faced with. One does not wish to think about what trade press articles would say, so we work out these things within our group.
     Thanks,
     Joe D.

On 15/05/2014 12:04, Olaf Kirch wrote:
> Hi Joe,
>
> On Thursday 15 May 2014 09:36:38 Joe Doupnik wrote:
>>       Without having heard Matthias' presentation on the topic, the 
>> appearance at present is this is hostage taking. As we all know,
>>   PHP is a central component of building production servers. Chasing
>>   down -devel RPMs is awkward enough, now core material is being
>>   placed behind locked doors. Might someone offer a brief
>>   explanation of why this approach is being taken?
> "Hostage taking" and "locked door" are somewhat strong words... and I 
> hope you'll come to a different conclusion once we're talking about 
> the facts behind these changes.
>
> In a nutshell, SLES faces a dilemma with fast moving technologies.
> SLES releases are in the market for a very long time. Customers using 
> SLES expect a high level of stability in everything, including APIs.
> Now, API stability is definitely not one of the focus areas of the 
> people creating Web development frameworks. This includes php, ruby on 
> rails, you name it.
>
> With SLES, we could definitely take the approach of companies selling
> pharmaceuticals: "Bayer Froozle fights migraine, except when you do 
> this or that or something else, and by the way if you're unlucky, it 
> might make your hair fall out, cause your ears to grown like balloons 
> and your nose to turn green, ..." Just like that, we could say "In 
> SLES, we keep all APIs stable, except for <insert longish list>, and 
> we provide full support for everything, except for <insert another
> list>."
>
> In some weird coordinate system, this might be considered customer 
> friendly, but in most it's not.
>
> In the past, we have had a very hard time to upgrade components such 
> as php. Not really for technical reasons, but because of such 
> expectations on the life cycle. So what we are going to do is to 
> create several modules (aka channels) which will be free of charge to 
> SLE customers. These modules will hold collections of related 
> packages, and communicate a clear life cycle and support statement for 
> each module.
>
> You discovered the drawback of the module concept. It's easy to miss.
> On the other hand, you receive a strong benefit - which is a regular 
> refresh of the code base for components such as php, which was not 
> possible before.
>
> One of these modules will be targeted at Web Development, and contain 
> PHP.
>
> Regards,
> Olaf

_______________________________________________
sles-beta mailing list
sles-beta at lists.suse.com
http://lists.suse.com/mailman/listinfo/sles-beta

DFS Deutsche Flugsicherung GmbH
Am DFS-Campus
D - 63225 Langen

Tel.: +49-(0)6103-707-0

Sitz der Gesellschaft: Langen/Hessen
Zuständiges Registergericht: AG Offenbach am Main, HRB 34977
Vorsitzender des Aufsichtsrates: Michael Odenwald
Geschäftsführer: Prof. Klaus-Dieter Scheurle (Vors.), Robert Schickling, Dr. Michael Hann

Internet: http://www.dfs.de
Public-Key der DFS: http://www.dfs.de/dfs/public_key.asc <http://www.dfs.de/dfs/public_key.asc>