Starwman. I happen to have discussed the situation and the approach with
the main people behind Composer in person, as well as gone over details
with contributors on IRC. They did not seem to share your opinion.
Since we’re throwing out logical fallacies: argumentum ab auctoritate.
Like I’ve
On Wed, Jun 4, 2014 at 9:53 AM, Tyler Romeo tylerro...@gmail.com wrote:
Here is the solution: rather than using Composer as a package management
system when, in reality, it is a dependency management system, we use
Composer to properly maintain core, and then do one of the following: 1)
As a temporary workaround, maybe we could create
extensions/composer-example.json which could be used for extension
registration by running composer in that directory?
Yes. That would work. All we would need to do is add the following into
Setup.php:
include “$IP/extensions/vendor/autoload.php”;
Hey,
As for the accusation that the current approach favors the WMF, it's almost
not worth responding to.
It seems like what James is getting at is the core community, not the WMF.
The problem being that several people seem to thing that the concerns
raised are not relevant and not worth
On Fri, May 30, 2014 at 3:56 PM, Bryan Davis bd...@wikimedia.org wrote:
There is still some ongoing internal discussion about the best way to
verify that included libraries are needed and that security patches
are watched for and applied from upstream. Chris Steipp is awesome,
but it would be
2014-05-30 0:57 GMT+03:00 Bryan Davis bd...@wikimedia.org:
I think bug 65188 [0] is the solution suggested by Ori that you are
referring to. Would this alone be enough to fix the problems for
translatewiki.net? More directly, is translatewiki.net using the top
level composer.json file to
To make things worse, I noticed on my development environment that our
own scap-equivalent will just go on to run composer update even if the
file conflicted. This causes it to remove the extensions and libraries
we currently install via composer, also breaking the site.
I hope for the sake
Hey,
To make things worse, I noticed on my development environment that our
own scap-equivalent will just go on to run composer update even if the
file conflicted. This causes it to remove the extensions and libraries
we currently install via composer, also breaking the site.
I hope for
I would also like to express my disappointment at third party users being
thrown under the bus once again. Several people have been putting a lot of
effort into supporting third party users, so it really saddens me that this
is dismissed as an irrelevance by some so easily.
Third party users were
That is just the unfortunate truth. We are
not going to misuse libraries and hack together MediaWiki just so extension
installation can be *slightly* easier.
This sort of behaviour towards non-WMF extension developers is
interesting and if your objective is to alienate (as with the attitude
This sort of behaviour towards non-WMF extension developers is
interesting and if your objective is to alienate (as with the attitude
above) volunteer developers then your on the right path.
Some people forget that users not always choose MW because of its
software but because it provides some
On Mon, Jun 2, 2014 at 6:37 PM, James HK jamesin.hongkon...@gmail.com
wrote:
That is just the unfortunate truth. We are
not going to misuse libraries and hack together MediaWiki just so
extension
installation can be *slightly* easier.
This sort of behaviour towards non-WMF extension
On Thu, May 29, 2014 at 11:27 AM, Bryan Davis bd...@wikimedia.org wrote:
My logging changes [0][1][2][3] are getting closer to being mergeable
(the first has already been merged). Tony Thomas' Swift Mailer change
[4] is also progressing. Both sets of changes introduce the concept of
specifying
My logging changes [0][1][2][3] are getting closer to being mergeable
(the first has already been merged). Tony Thomas' Swift Mailer change
[4] is also progressing. Both sets of changes introduce the concept of
specifying external library dependencies, both required and suggested,
to
2014-05-29 20:27 GMT+03:00 Bryan Davis bd...@wikimedia.org:
What use cases did I miss? What other concerns do we have for this process?
The email subject does not cover third party users, so apologies if
this is not the correct place for this.
Currently updating translatewiki.net codebase is
On Thu, May 29, 2014 at 2:38 PM, Niklas Laxström
niklas.laxst...@gmail.com wrote:
2014-05-29 20:27 GMT+03:00 Bryan Davis bd...@wikimedia.org:
What use cases did I miss? What other concerns do we have for this process?
The email subject does not cover third party users, so apologies if
this is
16 matches
Mail list logo
