Re: [Wikitech-l] Fwd: [Foundation-l] Single login - decision 2004

[Stryn]

Awesome, good job guys!

*Stryn*

2015-04-22 9:37 GMT+03:00 Keegan Peterzell :

>
>
> This is now complete [2]. That wasn't too bad.
>
> 2.
> https://lists.wikimedia.org/pipermail/wikimedia-l/2015-April/077576.html
>
> --
> Keegan Peterzell
> Community Liaison, Product
> Wikimedia Foundation
>
>
>
> --
> Keegan Peterzell
> Community Liaison, Product
> Wikimedia Foundation
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] RFC meeting this week

[Tim Starling]

In the next RFC meeting, we will discuss the following RFC:

* Business Layer Architecture on budget


The meeting will be on the IRC channel #wikimedia-office on
chat.freenode.net at the following time:

* UTC: Wednesday 21:00
* US PDT: Wednesday 14:00
* Europe CEST: Wednesday 23:00
* Australia AEST: Thursday 07:00

-- Tim Starling

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Last chance to reboot precise installs in Labs

[Marc A. Pelletier]

Hello Labs project maintainers,

Today is your last chance to reboot any instances you may be running
that have Ubuntu Precise and have not been rebooted since my
notification last week!

All instances how have a /usr/local/sbin/reboot-if-idmap script
installed which, if run by root or with sudo, will reboot any instance
iff it still needs to be rebooted.  (Specifically, it does the exact
feature test and does nothing if it passes).

== What happens if you don't reboot ==

At some point tomorrow (Apr 23, around 14h UTC) idmap[1] will be turned
off on the labs storage servers.  Instances that are still trying to use
idmap will loose the ability to access files in /home and /data/project
that are not globally readable (or writable, as the case may be).  This
may impact processes running on those instances in various ways.

Again, only instances that are running Ubuntu Precise and that have not
been rebooted (for any reason) since Apr 13, 2015 12h UTC are affected.
 If in doubt, you can safely run the reboot-if-idmap script - it will
have no effect on instances that do not neet reboot or have already been
rebooted.

Thank you,

-- Marc

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] "For the Sake of Simplicity"

[Ori Livneh]

From http://www.artima.com/weblogs/viewpost.jsp?thread=362327 :

That software systems are getting bigger and more pervasive is testament
that we can at times muster the wherewithal to manage the inherent
complexity of constructing large systems. At other times, however, it
simply supports the view that creating complexity is far easier than
hiding it — the creeping featurism, physical size, and bugginess of
certain operating systems and wordprocessing packages is tantamount to a
public admission of software engineering failure. To paraphrase Blaise
Pascal, "The software to solve your problem is larger and more complex
than necessary, because we did not have the ability or resources to make
it smaller and simpler."

[...]

In other words, leaving or taking things out by constantly examining the
difference between inherent and actual complexity, questioning and
reducing the number of features, and questioning and reducing the amount
of code. For benighted management that still measures productivity in
terms of KLOCs, this is scary: it appears to represent negative
productivity. But... less code, fewer bugs... fewer features, greater ease
of use... and so on.

This leads to an interesting marketing possibility, and one that I have
seen in action only a few times: the idea that a subsequent release of a
product might be smaller or have fewer features than the previous version,
and that this property should be considered a selling point. Perhaps the
market is not mature enough to accept it yet, but it remains a promising
and classic ideal — less is more.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] "For the Sake of Simplicity"

[Chad]

On Wed, Apr 22, 2015 at 10:45 AM Ori Livneh  wrote:

> This leads to an interesting marketing possibility, and one that I have
> seen in action only a few times: the idea that a subsequent release of a
> product might be smaller or have fewer features than the previous version,
> and that this property should be considered a selling point. Perhaps the
> market is not mature enough to accept it yet, but it remains a promising
> and classic ideal — less is more.
>
>
I remove features from MediaWiki all the time. I think the number of
new additions outpaces my removals though :p

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] "For the Sake of Simplicity"

[Stas Malyshev]

Hi!

> This leads to an interesting marketing possibility, and one that I have
> seen in action only a few times: the idea that a subsequent release of a
> product might be smaller or have fewer features than the previous version,
> and that this property should be considered a selling point. Perhaps the
> market is not mature enough to accept it yet, but it remains a promising
> and classic ideal — less is more.

Apple is doing it from time to time, and is not shy about it. I'm not
sure I personally am a big fan, but it works for many people.

Another interesting take on the same topic from ESR:
http://esr.ibiblio.org/?p=6737

-- 
Stas Malyshev
smalys...@wikimedia.org

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] "For the Sake of Simplicity"

[Trevor Parscal]

I'm a fan of removing features when the feature is not currently done well
and we aren't going to do it well anytime soon, if ever. Products with
fewer high quality features are superior in many ways to products with many
low quality features.

- Trevor

On Wednesday, April 22, 2015, Stas Malyshev  wrote:

> Hi!
>
> > This leads to an interesting marketing possibility, and one that I have
> > seen in action only a few times: the idea that a subsequent release of a
> > product might be smaller or have fewer features than the previous
> version,
> > and that this property should be considered a selling point. Perhaps the
> > market is not mature enough to accept it yet, but it remains a promising
> > and classic ideal — less is more.
>
> Apple is doing it from time to time, and is not shy about it. I'm not
> sure I personally am a big fan, but it works for many people.
>
> Another interesting take on the same topic from ESR:
> http://esr.ibiblio.org/?p=6737
>
> --
> Stas Malyshev
> smalys...@wikimedia.org 
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org 
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] "For the Sake of Simplicity"

[George Herbert]

Merely removing features is not deep enough.  This is fundamentally at its
origins an architecture challenge, and a development management challenge.
Removing features is rearguard action, not properly conceived engagement
with the problem.

Complexity can be neutral; code size by itself is not horrible in an era of
TB drives.  But code size hides bugs, and security flaws, and exponentially
more complicated development challenges the more components and parts that
one must consider interacting with each other.

ESR was wrong; he's asserting that simplicity is too hard and we should
give up.  We can't give up; software projects and distros / OS versions
that get too complex become unsustainable and fail in the market (public
opinion, or just financially).  He does not seem to understand the harm of
complexity, and does not here appear to understand the role that singular
architects and dev leaders and style guides and code standards can have.  A
very few people, or one, can point a project in a direction that both
allows lots of participation AND remains focused and architecturally clean.

PHK wasn't entirely right; he's gotten down in the weeds on a much larger
problem, and the weeds distracted everyone.  But he has a point.


On Wed, Apr 22, 2015 at 1:26 PM, Trevor Parscal 
wrote:

> I'm a fan of removing features when the feature is not currently done well
> and we aren't going to do it well anytime soon, if ever. Products with
> fewer high quality features are superior in many ways to products with many
> low quality features.
>
> - Trevor
>
> On Wednesday, April 22, 2015, Stas Malyshev 
> wrote:
>
> > Hi!
> >
> > > This leads to an interesting marketing possibility, and one that I have
> > > seen in action only a few times: the idea that a subsequent release of
> a
> > > product might be smaller or have fewer features than the previous
> > version,
> > > and that this property should be considered a selling point. Perhaps
> the
> > > market is not mature enough to accept it yet, but it remains a
> promising
> > > and classic ideal — less is more.
> >
> > Apple is doing it from time to time, and is not shy about it. I'm not
> > sure I personally am a big fan, but it works for many people.
> >
> > Another interesting take on the same topic from ESR:
> > http://esr.ibiblio.org/?p=6737
> >
> > --
> > Stas Malyshev
> > smalys...@wikimedia.org 
> >
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org 
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



-- 
-george william herbert
george.herb...@gmail.com
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] "For the Sake of Simplicity"

[Marc A. Pelletier]

On 15-04-22 05:06 PM, George Herbert wrote:
> He does not seem to understand the harm of
> complexity, and does not here appear to understand the role that singular
> architects and dev leaders and style guides and code standards can have.

I'm pretty sure I disagree with this.  Any system will begin to show
emergent complexity past a certain size or scope, and no amount of
precise architecture can prevent it.

A good architecture team, style guides and code standard are all
beneficial in that they push what 'certain size' is further, and helps
mitigate the effects of increasing complexity so that it remains more
managable - but they do not prevent either.

No matter how well designed, any system will exponentially diverge from
expectations and show emergent behaviour as the number of interacting
component grows.  That is an inevitable reality, no matter how
insightful the project lead or how stringent the process.

-- Marc


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] "For the Sake of Simplicity"

[George Herbert]

At those sizes, insisting on APIs between component levels/layers/areas
helps keep sanity and order.

Every system's complexity reflects both actual functional requirements, at
whatever level of simplicity was realistic to impose, and evolution of the
required features as the uses were expanded and understood better.  If you
planned for orderly solutions and approaches at a higher level of
complexity than you had to implement to start with, expecting that growth,
then the evolving product can maintain a reasonable organized approach.

The question is, what was the forseen growth, the margins for that, and the
eventual growth level.  With many internet things, forseen growth was 10x
and the eventual growth seems to be bimodal into a lot of items at around
2x and a very few very successful ones at 100x.

It *is* a perfectly valid question as to whether enough time and
architectural experience is available to pre-plan a new internet tool for
the potential 100x growth...

(This does argue for complete rearchitect/recode projects every so often
for very large successful tools...).


On Wed, Apr 22, 2015 at 3:17 PM, Marc A. Pelletier  wrote:

> On 15-04-22 05:06 PM, George Herbert wrote:
> > He does not seem to understand the harm of
> > complexity, and does not here appear to understand the role that singular
> > architects and dev leaders and style guides and code standards can have.
>
> I'm pretty sure I disagree with this.  Any system will begin to show
> emergent complexity past a certain size or scope, and no amount of
> precise architecture can prevent it.
>
> A good architecture team, style guides and code standard are all
> beneficial in that they push what 'certain size' is further, and helps
> mitigate the effects of increasing complexity so that it remains more
> managable - but they do not prevent either.
>
> No matter how well designed, any system will exponentially diverge from
> expectations and show emergent behaviour as the number of interacting
> component grows.  That is an inevitable reality, no matter how
> insightful the project lead or how stringent the process.
>
> -- Marc
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



-- 
-george william herbert
george.herb...@gmail.com
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] "For the Sake of Simplicity"

[Matthew Flaschen]

On 04/22/2015 01:44 PM, Ori Livneh wrote:


That software systems are getting bigger and more pervasive is testament
that we can at times muster the wherewithal to manage the inherent
complexity of constructing large systems. At other times, however, it
simply supports the view that creating complexity is far easier than
hiding it — the creeping featurism, physical size, and bugginess of
certain operating systems and wordprocessing packages is tantamount to a
public admission of software engineering failure. To paraphrase Blaise
Pascal, "The software to solve your problem is larger and more complex
than necessary, because we did not have the ability or resources to make
it smaller and simpler."


+1.  Related concept: 
https://blog.intercom.io/product-strategy-means-saying-no/ .


Obviously, it's really about knowing when to say Yes, and when to say 
No, but both are very important.


Matt Flaschen

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] RFC meeting this week

[Matthew Flaschen]

On 04/22/2015 04:41 AM, Tim Starling wrote:

In the next RFC meeting, we will discuss the following RFC:

* Business Layer Architecture on budget



Minutes: 
https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-04-22-21.01.html


Log: 
https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-04-22-21.01.log.html


Summary of the discussion:

There was a fair amount of discussion about how the request/response 
model of the MW API ("API" here meaning api.php modules) should map to 
the proposed wfApi (or replacement).  Tim was concerned that done wrong 
it will not reflect the stateless nature of the API.


People generally agreed that not all code should do SQL.

There was consensus to rewrite the RFC (particularly the assumptions). 
There was not consensus on the underlying RFC, though there was some 
support for making FauxRequest better.


I, and others, expressed some concern about the lack of type checking 
possible in this approach (since every API request is essentially 
{action: 'thank', parameters: {}}, rather than 
$$thankServiceInstance->thank( $revision ) or whatever).


A counter-argument to this is that we don't fully take advantage of the 
type-checking available.  However, there are type checkers for PHP which 
some people use, and it's likely that even if we don't move to Hack, 
more type-checking features will move into the PHP ecosystem.


Also, we do have basic type-checking at run-time already (type hints, is 
it a real method?), though not quite the same thing.


Matt Flaschen


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l