Addshore added a comment.
Just going to poke this to see what people consider the state of this?
Personally I think out composer usage is rather streamlined right now (except in core we have super strict version dependencies)TASK DETAILhttps://phabricator.wikimedia.org/T105638EMAIL
daniel added a comment.
Lack of commitment, lack of resources. I still think it would be a good idea to do it, but i'm not sure that counts as "interest".
We should get rid of mediawiki/vendor at some point...TASK DETAILhttps://phabricator.wikimedia.org/T105638EMAIL
Tgr added a comment.
Is this blocked on something specific or just lack of interest? As I understood the original blocker was proper HTTPS support in Composer and that was fixed upstream some months ago.TASK DETAILhttps://phabricator.wikimedia.org/T105638EMAIL
Aklapper added a comment.
Wikimedia Developer Summit 2016 ended two weeks ago. This task is still open.
**If the session in this task took place**, please make sure 1) that the
session Etherpad notes are linked from this task, 2) that followup tasks for
any actions identified have been created
JanZerebecki added a comment.
Copy of the etherpad:
(missing start of talk, a minute or so)
Step 4: CI job that automatically triggers after changes to core or ext
* run composer update and push changes
Step 5: Update BC from steps 3-4
Are these sufficient examples? Can people
JanZerebecki added a comment.
Steps mentioned at the beginning of the session are
https://www.mediawiki.org/wiki/Requests_for_comment/Streamlining_Composer_usage#Workflow_example
.
TASK DETAIL
https://phabricator.wikimedia.org/T105638
EMAIL PREFERENCES
dduvall added a subscriber: dduvall.
dduvall added a comment.
Etherpad: https://etherpad.wikimedia.org/p/MWDS2016-composer
TASK DETAIL
https://phabricator.wikimedia.org/T105638
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: JanZerebecki, dduvall
Tgr added a subscriber: Tgr.
Tgr added a comment.
The librarization project is somewhat blocked on this (or rather on the
Composer security problems outlined here), see comments in
https://gerrit.wikimedia.org/r/#/c/248661/
TASK DETAIL
https://phabricator.wikimedia.org/T105638
EMAIL
mmodell added a comment.
@gwicke: very interesting suggestion. I like it, though I think I need to think
it over a bit more before I can say for sure that it would work for mediawiki
deployments.
TASK DETAIL
https://phabricator.wikimedia.org/T105638
EMAIL PREFERENCES
JanZerebecki added a comment.
TODO: See if something better than plain gpg1/2 verify exists and if git verify
can be enhanced to verify if the key that made the signature is trusted, e.g.
to have less of the implementation in composer and make it possible to share
this with other package
GWicke added a subscriber: GWicke.
GWicke added a comment.
Here is an idea for a workflow-based solution that would work for nodejs as
well:
1. Each code project has a corresponding deploy repository. For nodejs, current
practice is to have the code as a submodule of the deploy repository (in
JanZerebecki added a comment.
TODO perhaps add to link to:
https://phabricator.wikimedia.org/diffusion/TEXD/browse/master/nightly.py;8bd6c73cfbcd3ed484cb425ad35256d3ff6377ae$179
TASK DETAIL
https://phabricator.wikimedia.org/T105638
EMAIL PREFERENCES
JanZerebecki added a comment.
@Qgil I haven't seen any response from you, so I took the liberty to change the
column on the work board.
TASK DETAIL
https://phabricator.wikimedia.org/T105638
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To:
Qgil added a comment.
Congratulations! This is one of the 52 proposals that made it through the first
deadline of the
https://phabricator.wikimedia.org/tag/wikimedia-developer-summit-2016/
selection process
JanZerebecki added a comment.
@Qgil as far as I see it is complete, except that I need to update the RFC
document.
> definition of the problem
See RFC.
> expected outcome at the Summit
Progress on the RFC. It would be nice if the WMF would make it a goal, but that
is not strictly an
Qgil added a comment.
Does it make sense to discuss this RfC in the context of the
https://phabricator.wikimedia.org/tag/wikimedia-developer-summit-2016/? See
https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit_2016#Call_for_participation
TASK DETAIL
JanZerebecki added a comment.
My preferred way forward here is adding signature support to composer and
packagist.org, that would if the signature implementation is not broken and the
persons trusted with signing are not compromised prevent all from
JanZerebecki added a comment.
It might, if I have time to write up a sketch/plan how to implement this in
composer upstream and if the right people are interested and there.
The right people would be the people doing the branch cut before deployment,
doing the deployment, creating composer
Qgil added a comment.
Thank you for proposing a session for the Wikimedia Developer Summit. Please
complete your description -- see "Expected fields" at
https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit_2016#Call_for_participation
TASK DETAIL
JanZerebecki added a comment.
Currently I don't have enough time to catch up to the existing input. So I
think we should wait with discussing this RFC again.
TASK DETAIL
https://phabricator.wikimedia.org/T105638
EMAIL PREFERENCES
csteipp added a comment.
1 2 are probably related, so I'll add some comment here. Happy to move to
another forum if needed.
The threats I've seen laid out, and my (very rough) evaluation of their risk.
Happy to be corrected if it seems like I have assumptions that are wrong, or
you disagree
Aklapper added a comment.
What is the status of this task, now that Wikimania 2015 is over? Did this
meeting take place? If yes: Please provide an update and potentially summarize
findings / potentially provide a link to anything relevant. If no: Please edit
this task by removing the
JanZerebecki added a comment.
In https://phabricator.wikimedia.org/T105638#1472626, @Spage wrote:
@JanZerebecki, is this ready to discuss in the August 5 MediaWiki RFCs office
hour?
Yes.
TASK DETAIL
https://phabricator.wikimedia.org/T105638
EMAIL PREFERENCES
mmodell added a comment.
what came of this meeting?
TASK DETAIL
https://phabricator.wikimedia.org/T105638
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: JanZerebecki, mmodell
Cc: greg, tstarling, aude, hoo, daniel, zeljkofilipin, thcipriani,
JanZerebecki added a comment.
Only 2 people were there who I already discussed this before, thus only minor
edits to the RFC resulted.
TASK DETAIL
https://phabricator.wikimedia.org/T105638
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To:
JanZerebecki added a comment.
Moved it an hour later to Wednesday (day 1) at 17:00 in room Hackathon
Workplace 2 - Don Genaro.
TASK DETAIL
https://phabricator.wikimedia.org/T105638
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: JanZerebecki
Cc:
JanZerebecki added a comment.
The background and problem statement are now in a consumable state. Although it
might need to take more reference to older RFCs linked at the bottom.
TASK DETAIL
https://phabricator.wikimedia.org/T105638
EMAIL PREFERENCES
27 matches
Mail list logo
