Hello all,
*TL;DR*: Reminder to please bike-shed at [[mw:Phabricator/Diffusion/Callsign_naming_conventions]] https://www.mediawiki.org/wiki/Phabricator/Diffusion/Callsign_naming_conventions before December.
Just when you thought it was safe, there's the next stage in our migration of developer tools over to Phabricator: moving all our code into the Diffusion module https://www.mediawiki.org/wiki/Phabricator/Diffusion.
This is *not* about doing code review in Phabricator; that task will be left for another time. However, it does establish some immutable URLs and so there's a lot of scope for discussion and verification about how exactly we want to do things.
We currently use gitblit to provide our service at git.wikimedia.org ; it's a down-stream, read-only, HTTPS service for browsing all our git repos. We'd like to replace this service with the single platform of Phabricator because (a) we need to make these decisions anyway for the code review workstream, (b) fewer tools makes for a simpler learning environment for newbies, and (c) more integrated tools makes for fewer hacky bots and "work arounds" for everyone.
To explore what Diffusion looks like, compare:
- GitBlit: http://git.wikimedia.org/summary/VisualEditor%2FVisualEditor.git - GitHub: https://github.com/wikimedia/visualeditor - Diffusion: https://phabricator.wikimedia.org/diffusion/VE/
We need to agree how we are going to name our repos, and much more importantly because it can't change, what their "callsign" is. These will be at the heart of e-mails, IRC notifications and git logs for a long time, so it's important to get this right rather than regret it after the fact.
A handful of repos are so important and high-profile that we can use an acronym without too much worry, like "MW" for MediaWiki or "VE" for VisualEditor. For the rest, we need to make sure we've got a good enough name that won't cause inconveniences or confusion, and doesn't repeat the mistakes we've identified over time. We've learnt since the SVN to git migration a few years ago that calling your repository "/core" is a bad plan, for instance.
*Action request*
The proposed naming conventions https://www.mediawiki.org/wiki/Phabricator/Diffusion/Callsign_naming_conventions and in particular the plan for what we'll call the existing repos https://www.mediawiki.org/wiki/Phabricator/Diffusion/Callsign_naming_conventions/Existing_repositories when we duplicate them would benefit from more people looking at them, if only to say that you don't care. :-) We've had these under discussion since October so you may well have seen these before.
We plan to declare the current list as "agreed" in a week's time (that is, by the end of 1 December) unless there's significant on-going discussion.
Yours,
James Forrester wrote:
We need to agree how we are going to name our repos, and much more importantly because it can't change, what their "callsign" is. These will be at the heart of e-mails, IRC notifications and git logs for a long time, so it's important to get this right rather than regret it after the fact.
A handful of repos are so important and high-profile that we can use an acronym without too much worry, like "MW" for MediaWiki or "VE" for VisualEditor. For the rest, we need to make sure we've got a good enough name that won't cause inconveniences or confusion, and doesn't repeat the mistakes we've identified over time. We've learnt since the SVN to git migration a few years ago that calling your repository "/core" is a bad plan, for instance.
Could we not?
JIRA does this prefixing with tickets and I don't really understand its purpose. We already have Git hashes and positive integers. Is another scheme really needed? And what was wrong with the repository names again?
I was pleased that Maniphest simply uses T as a prefix. I'm kind of bummed out that Diffusion is introducing shouting obscure immutable abbreviations.
MZMcBride
No we can't not.
-Chad
On Tue, Nov 25, 2014, 9:11 PM MZMcBride z@mzmcbride.com wrote:
James Forrester wrote:
We need to agree how we are going to name our repos, and much more importantly because it can't change, what their "callsign" is. These will be at the heart of e-mails, IRC notifications and git logs for a long time, so it's important to get this right rather than regret it after the fact.
A handful of repos are so important and high-profile that we can use an acronym without too much worry, like "MW" for MediaWiki or "VE" for VisualEditor. For the rest, we need to make sure we've got a good enough name that won't cause inconveniences or confusion, and doesn't repeat the mistakes we've identified over time. We've learnt since the SVN to git migration a few years ago that calling your repository "/core" is a bad plan, for instance.
Could we not?
JIRA does this prefixing with tickets and I don't really understand its purpose. We already have Git hashes and positive integers. Is another scheme really needed? And what was wrong with the repository names again?
I was pleased that Maniphest simply uses T as a prefix. I'm kind of bummed out that Diffusion is introducing shouting obscure immutable abbreviations.
MZMcBride
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I think that is a bit sad. Not tearing of cloths or gnashing of teeth sad. Maybe stare whistfully into the sunset and think of what could have been bad.
I'd prefer not to have them but I ultimately don't care that much. It does provide a fun bikeshedding opportunity I guess.
Nik On Nov 26, 2014 12:52 AM, "Chad" innocentkiller@gmail.com wrote:
No we can't not.
-Chad
On Tue, Nov 25, 2014, 9:11 PM MZMcBride z@mzmcbride.com wrote:
James Forrester wrote:
We need to agree how we are going to name our repos, and much more importantly because it can't change, what their "callsign" is. These
will
be at the heart of e-mails, IRC notifications and git logs for a long time, so it's important to get this right rather than regret it after
the
fact.
A handful of repos are so important and high-profile that we can use an acronym without too much worry, like "MW" for MediaWiki or "VE" for VisualEditor. For the rest, we need to make sure we've got a good enough name that won't cause inconveniences or confusion, and doesn't repeat
the
mistakes we've identified over time. We've learnt since the SVN to git migration a few years ago that calling your repository "/core" is a bad plan, for instance.
Could we not?
JIRA does this prefixing with tickets and I don't really understand its purpose. We already have Git hashes and positive integers. Is another scheme really needed? And what was wrong with the repository names again?
I was pleased that Maniphest simply uses T as a prefix. I'm kind of
bummed
out that Diffusion is introducing shouting obscure immutable
abbreviations.
MZMcBride
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
Le 26/11/2014 03:45, James Forrester a écrit :
A handful of repos are so important and high-profile that we can use an acronym without too much worry, like "MW" for MediaWiki or "VE" for VisualEditor.
What is the point of opening a discussion if some people already rushed/enforced their decisions ?
For the rest, we need to make sure we've got a good enough name that won't cause inconveniences or confusion, and doesn't repeat the mistakes we've identified over time. We've learnt since the SVN to git migration a few years ago that calling your repository "/core" is a bad plan, for instance.
{in your opinion}, I think `/core` is just fine.
[[mw:Phabricator/Diffusion/Callsign_naming_conventions]] https://www.mediawiki.org/wiki/Phabricator/Diffusion/Callsign_naming_conventions
Can we take sometime to clean up the repositories, there are a lot of obsolete/abandoned ones that I would love to see disappear or archived somewhere else.
For the Gerrit hierarchy 'integration/*', please have who ever is leading the project to fill a task for the #contint project. Some repos need to be renamed / changed.
Is there a length limit to call signs? I imagine that the answer is yes, at least in terms of how hashes are displayed on that page, I would imagine that anything above 11 characters would make the shortened display of hashes unusable.
I'm personally not a fan of abbreviations like "VE" to begin with, although I do unfortunately use them sometimes in public content like commit messages. They're alienating to casual code contributors who should be dealing with unified naming for a given component and shouldn't need to learn our insider jargon. If the extension is called VisualEditor, so should the rest. For example in the diffusion page you've linked to, the fact that the URL is /VE/ is a bad idea, imho. I understand the challenge for hash display, but there's no reason to make the URL shorter. Are the two tied together in Phabricator? I.e. does the callsign define the diffusion URL?
On Wed, Nov 26, 2014 at 9:10 AM, Antoine Musso hashar+wmf@free.fr wrote:
Le 26/11/2014 03:45, James Forrester a écrit :
A handful of repos are so important and high-profile that we can use an acronym without too much worry, like "MW" for MediaWiki or "VE" for VisualEditor.
What is the point of opening a discussion if some people already rushed/enforced their decisions ?
For the rest, we need to make sure we've got a good enough name that won't cause inconveniences or confusion, and doesn't repeat the mistakes we've identified over time. We've learnt since the SVN to git migration a few years ago that calling your repository "/core" is a bad plan, for instance.
{in your opinion}, I think `/core` is just fine.
[[mw:Phabricator/Diffusion/Callsign_naming_conventions]] <
https://www.mediawiki.org/wiki/Phabricator/Diffusion/Callsign_naming_convent...
Can we take sometime to clean up the repositories, there are a lot of obsolete/abandoned ones that I would love to see disappear or archived somewhere else.
For the Gerrit hierarchy 'integration/*', please have who ever is leading the project to fill a task for the #contint project. Some repos need to be renamed / changed.
-- Antoine "hashar" Musso
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Yes they are tied together.
There are some really good explanations about the reasons and history of phab callsigns in https://secure.phabricator.com/T4245 I'm not a big fan of them either....
DJ
On Wed, Nov 26, 2014 at 10:51 AM, Gilles Dubuc gilles@wikimedia.org wrote:
Is there a length limit to call signs? I imagine that the answer is yes, at least in terms of how hashes are displayed on that page, I would imagine that anything above 11 characters would make the shortened display of hashes unusable.
I'm personally not a fan of abbreviations like "VE" to begin with, although I do unfortunately use them sometimes in public content like commit messages. They're alienating to casual code contributors who should be dealing with unified naming for a given component and shouldn't need to learn our insider jargon. If the extension is called VisualEditor, so should the rest. For example in the diffusion page you've linked to, the fact that the URL is /VE/ is a bad idea, imho. I understand the challenge for hash display, but there's no reason to make the URL shorter. Are the two tied together in Phabricator? I.e. does the callsign define the diffusion URL?
On Wed, Nov 26, 2014 at 9:10 AM, Antoine Musso hashar+wmf@free.fr wrote:
Le 26/11/2014 03:45, James Forrester a écrit :
A handful of repos are so important and high-profile that we can use an acronym without too much worry, like "MW" for MediaWiki or "VE" for VisualEditor.
What is the point of opening a discussion if some people already rushed/enforced their decisions ?
For the rest, we need to make sure we've got a good enough name that won't cause inconveniences or confusion, and doesn't repeat
the
mistakes we've identified over time. We've learnt since the SVN to git migration a few years ago that calling your repository "/core" is a bad plan, for instance.
{in your opinion}, I think `/core` is just fine.
[[mw:Phabricator/Diffusion/Callsign_naming_conventions]] <
https://www.mediawiki.org/wiki/Phabricator/Diffusion/Callsign_naming_convent...
Can we take sometime to clean up the repositories, there are a lot of obsolete/abandoned ones that I would love to see disappear or archived somewhere else.
For the Gerrit hierarchy 'integration/*', please have who ever is leading the project to fill a task for the #contint project. Some repos need to be renamed / changed.
-- Antoine "hashar" Musso
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
BTW, I gather from examples on the page like "wikimedia-roadmap-updater" that we're doing away with subpaths in the git clone url ?
I just want to make sure that people are aware that using the "Clone/Checkout As" option allows you to specify whatever you want, including paths (I use this myself).
So, both of these are possible: git clone ssh:// git@phabricator.wikimedia.org/diffusion/CALLSIGN/wikimedia-roadmap-updater.git git clone ssh:// git@phabricator.wikimedia.org/diffusion/CALLSIGN/wikimedia/roadmap-updater.git
Respectively resulting in the directories: wikimedia-roadmap-updater.git roadmap-updater.git
I just wanted to make sure that people were aware of that, it's an interesting way to namespace on url, but not on checkout directory.
DJ
On Wed, Nov 26, 2014 at 12:07 PM, Derk-Jan Hartman < d.j.hartman+wmf_ml@gmail.com> wrote:
Yes they are tied together.
There are some really good explanations about the reasons and history of phab callsigns in https://secure.phabricator.com/T4245 I'm not a big fan of them either....
DJ
On Wed, Nov 26, 2014 at 10:51 AM, Gilles Dubuc gilles@wikimedia.org wrote:
Is there a length limit to call signs? I imagine that the answer is yes, at least in terms of how hashes are displayed on that page, I would imagine that anything above 11 characters would make the shortened display of hashes unusable.
I'm personally not a fan of abbreviations like "VE" to begin with, although I do unfortunately use them sometimes in public content like commit messages. They're alienating to casual code contributors who should be dealing with unified naming for a given component and shouldn't need to learn our insider jargon. If the extension is called VisualEditor, so should the rest. For example in the diffusion page you've linked to, the fact that the URL is /VE/ is a bad idea, imho. I understand the challenge for hash display, but there's no reason to make the URL shorter. Are the two tied together in Phabricator? I.e. does the callsign define the diffusion URL?
On Wed, Nov 26, 2014 at 9:10 AM, Antoine Musso hashar+wmf@free.fr wrote:
Le 26/11/2014 03:45, James Forrester a écrit :
A handful of repos are so important and high-profile that we can use
an
acronym without too much worry, like "MW" for MediaWiki or "VE" for VisualEditor.
What is the point of opening a discussion if some people already rushed/enforced their decisions ?
For the rest, we need to make sure we've got a good enough name that won't cause inconveniences or confusion, and doesn't repeat
the
mistakes we've identified over time. We've learnt since the SVN to git migration a few years ago that calling your repository "/core" is a
bad
plan, for instance.
{in your opinion}, I think `/core` is just fine.
[[mw:Phabricator/Diffusion/Callsign_naming_conventions]] <
https://www.mediawiki.org/wiki/Phabricator/Diffusion/Callsign_naming_convent...
Can we take sometime to clean up the repositories, there are a lot of obsolete/abandoned ones that I would love to see disappear or archived somewhere else.
For the Gerrit hierarchy 'integration/*', please have who ever is leading the project to fill a task for the #contint project. Some repos need to be renamed / changed.
-- Antoine "hashar" Musso
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
On Tue, Nov 25, 2014 at 9:45 PM, James Forrester jforrester@wikimedia.org wrote:
and in particular the plan for what we'll call the existing repos < https://www.mediawiki.org/wiki/Phabricator/Diffusion/Callsign_naming_convent...
I can't find documentation anywhere for what's valid in callsigns besides "uppercase", but seeing feature requests for stuff like "Allow digits in callsigns" and "allow hyphens in callsigns" I'm suspecting the character set is literally [A-Z]. Which means a lot of the callsigns you have on that page aren't even valid.
Is the "repo name" column there supposed to be meaning "rename 'mediawiki/extensions/AbuseFilter' to just 'AbuseFilter'"? If that's the case, then IMO the proposed naming is simply awful. We have so many repositories that namespacing them is essential to make any sense out of things without already knowing what is what. For example, what's "Donate"? An extension for donations would be my guess. It's much clearer when it's called "mediawiki/skins/Donate", then you know it's actually a skin. And your own naming conventions page says that "Example" is a bad name, and yet you're proposing renaming "mediawiki/skins/Example" to "Example" and "mediawiki/extensions/Examples" to "Examples"!
From the link to https://secure.phabricator.com/T4245 that was posted
elsewhere in this thread, it looks like this whole idea of "callsigns" is a response to someone having a problem with resolving svn revision numbers on the level of single-digit numbers of repositories. It doesn't seem to me that it will scale AT ALL to the hundreds of repositories that we have, and we're extremely likely to be running into problems that are far more serious than the claimed problems from calling a repository "/core".
If we can't -2 the whole idea of required callsigns, it seems to me we'd be better served by just treating them as random base-26 integers with no inherent meaning.
On Wed Nov 26 2014 at 7:27:20 AM Brad Jorsch (Anomie) bjorsch@wikimedia.org wrote:
On Tue, Nov 25, 2014 at 9:45 PM, James Forrester <jforrester@wikimedia.org
wrote:
and in particular the plan for what we'll call the existing repos < https://www.mediawiki.org/wiki/Phabricator/Diffusion/
Callsign_naming_conventions/Existing_repositories
I can't find documentation anywhere for what's valid in callsigns besides "uppercase", but seeing feature requests for stuff like "Allow digits in callsigns" and "allow hyphens in callsigns" I'm suspecting the character set is literally [A-Z]. Which means a lot of the callsigns you have on that page aren't even valid.
Gah, how did that slip through? I could've sworn...whatever, moving on.
Is the "repo name" column there supposed to be meaning "rename 'mediawiki/extensions/AbuseFilter' to just 'AbuseFilter'"? If that's the case, then IMO the proposed naming is simply awful. We have so many repositories that namespacing them is essential to make any sense out of things without already knowing what is what. For example, what's "Donate"? An extension for donations would be my guess. It's much clearer when it's called "mediawiki/skins/Donate", then you know it's actually a skin. And your own naming conventions page says that "Example" is a bad name, and yet you're proposing renaming "mediawiki/skins/Example" to "Example" and "mediawiki/extensions/Examples" to "Examples"!
Those are bad examples and should have better names. But repo names are just descriptive in Phabricator, they don't really matter beyond display (hence the callsigns for linking). They can have spaces too :)
They also don't affect cloning paths which is outside the scope of what we're discussing here.
I think forcing every repo to be called Foo/Bar/Baz is ugly and redundant for things that don't conflict. For things that do, just describe them better. Call it "Example Extension" or somesuch.
From the link to https://secure.phabricator.com/T4245 that was posted elsewhere in this thread, it looks like this whole idea of "callsigns" is a response to someone having a problem with resolving svn revision numbers on the level of single-digit numbers of repositories. It doesn't seem to me that it will scale AT ALL to the hundreds of repositories that we have, and we're extremely likely to be running into problems that are far more serious than the claimed problems from calling a repository "/core".
/core is a red herring and irrelevant to this discussion. Let's drop it.
If we can't -2 the whole idea of required callsigns, it seems to me we'd be better served by just treating them as random base-26 integers with no inherent meaning.
I'm not opposed to that. It would make my life so much easier.
-Chad
On Wed Nov 26 2014 at 1:22:59 PM svetlana svetlana@fastmail.com.au wrote:
Hi,
On Thu, 27 Nov 2014, at 02:26, Brad Jorsch (Anomie) wrote:
[...] If we can't -2 the whole idea of required callsigns,
Why can't we?
Because Phabricator requires them for all repositories as a unique identifier.
They're used primarily in URLs and in the database which is why they can't change.
Repo names, on the other hand, can be changed every Friday if we wanted and are only used for display purposes.
-Chad
Chad wrote:
On Wed Nov 26 2014 at 1:22:59 PM svetlana svetlana@fastmail.com.au wrote:
On Thu, 27 Nov 2014, at 02:26, Brad Jorsch (Anomie) wrote:
[...] If we can't -2 the whole idea of required callsigns,
Why can't we?
Because Phabricator requires them for all repositories as a unique identifier.
They're used primarily in URLs and in the database which is why they can't change.
Repo names, on the other hand, can be changed every Friday if we wanted and are only used for display purposes.
I don't think the database is carved in stone or anything. Many other parts of the database are editable, after all. :-)
The real question here is whether having non-optional callsigns is a blocker to using Diffusion. Probably not.
If we're stuck with using callsigns, the idea of using the shortest possible strings (a four-character hash?) appeals to me. It seems vastly preferable to bikeshedding over options that include "ANALYTICS-GLOBAL-DEV-DASHBOARD-DATA" and "CENTRALNOTICE-BANNERPROXY" and similar eyesores. 16*16*16*16 (A-F and 0-9) gives us 65,536 options. If particular repos want specific available hashes (AAAA, FFFF), I'm fine with allocating on a first-come, first-served basis.
It'd also be helpful to nail down whether "-" or any other delimiter is allowed in callsigns... for example, "OPSDEBSCXAPERTIUMBRFR" instead of "OPS-DEBS-CX-APERTIUM-BR-FR" is going to bring only pain and regret.
MZMcBride
Sadly this is carved from the fires of Mt Doom.
-Chad
On Wed, Nov 26, 2014, 2:30 PM MZMcBride z@mzmcbride.com wrote:
Chad wrote:
On Wed Nov 26 2014 at 1:22:59 PM svetlana svetlana@fastmail.com.au wrote:
On Thu, 27 Nov 2014, at 02:26, Brad Jorsch (Anomie) wrote:
[...] If we can't -2 the whole idea of required callsigns,
Why can't we?
Because Phabricator requires them for all repositories as a unique identifier.
They're used primarily in URLs and in the database which is why they can't change.
Repo names, on the other hand, can be changed every Friday if we wanted and are only used for display purposes.
I don't think the database is carved in stone or anything. Many other parts of the database are editable, after all. :-)
The real question here is whether having non-optional callsigns is a blocker to using Diffusion. Probably not.
If we're stuck with using callsigns, the idea of using the shortest possible strings (a four-character hash?) appeals to me. It seems vastly preferable to bikeshedding over options that include "ANALYTICS-GLOBAL-DEV-DASHBOARD-DATA" and "CENTRALNOTICE-BANNERPROXY" and similar eyesores. 16*16*16*16 (A-F and 0-9) gives us 65,536 options. If particular repos want specific available hashes (AAAA, FFFF), I'm fine with allocating on a first-come, first-served basis.
It'd also be helpful to nail down whether "-" or any other delimiter is allowed in callsigns... for example, "OPSDEBSCXAPERTIUMBRFR" instead of "OPS-DEBS-CX-APERTIUM-BR-FR" is going to bring only pain and regret.
MZMcBride
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 26 November 2014 at 23:29, MZMcBride z@mzmcbride.com wrote:
If we're stuck with using callsigns, the idea of using the shortest possible strings (a four-character hash?) appeals to me. If particular repos want specific available hashes (AAAA, FFFF), I'm fine with allocating on a first-come, first-served basis.
I've fiddled a bit with this in the style of tail numbers / actual radio call signa: first letter is a category (country in a call sign), the rest is assigned as a number, unless someone wants a specific one.
Categories: M - mediawiki/*, except for extensions and skins E - extensions S - skins
W - wikimedia AN - analytics AP - apps CI - integration O - operations
L - labs LT - labs/tools
PH - phabricator PW - pywikibot
G - general
For most of those categories, I used a callsign derived from the repository name (eg Extension:Flow -> EFLW), except for - operations/debs, which are ODAA-ODDF - wikimedia/fundraising/*crm, which are WFCA-WFCM
There were some conflicts in extensions, but those were easy enough to solve with a bit of fiddling. Using five-character callsigns would probably solve most of those.
List: https://www.mediawiki.org/wiki/Phabricator/Diffusion/Callsign_naming_convent...
Merlijn
On Thu, 27 Nov 2014 21:02:39 +0100, Merlijn van Deen valhallasw@arctus.nl wrote:
I've fiddled a bit with this in the style of tail numbers / actual radio call signa: first letter is a category (country in a call sign), the rest is assigned as a number, unless someone wants a specific one.
https://www.mediawiki.org/wiki/Phabricator/Diffusion/Callsign_naming_convent...
I definitely like this proposal a lot more than the current one.
On Fri Nov 28 2014 at 2:41:00 PM Bartosz Dziewoński matma.rex@gmail.com wrote:
On Thu, 27 Nov 2014 21:02:39 +0100, Merlijn van Deen valhallasw@arctus.nl wrote:
I've fiddled a bit with this in the style of tail numbers / actual radio call signa: first letter is a category (country in a call sign), the rest is assigned as a number, unless someone wants a specific one.
Callsign_naming_conventions/Existing_repositories_valhallasw
I definitely like this proposal a lot more than the current one.
+1. Big improvement for callsigns :)
-Chad
Chad wrote:
On Fri Nov 28 2014 at 2:41:00 PM Bartosz Dziewoński matma.rex@gmail.com wrote:
On Thu, 27 Nov 2014 21:02:39 +0100, Merlijn van Deen valhallasw@arctus.nl wrote (roughly):
I definitely like this proposal a lot more than the current one.
+1. Big improvement for callsigns :)
Yes, this is great, valhallasw. Thank you!
So instead of "DATAVALUEIMPLEMENTATIONS" we'd have "EDVM" and instead of "FUNDRAISINGTRANSLATEWORKFLOW" we'd have "EFTW". I'm sold.
Does anyone hate or object to this four-character scheme?
MZMcBride
On Fri Nov 28 2014 at 6:15:44 PM MZMcBride z@mzmcbride.com wrote:
Chad wrote:
On Fri Nov 28 2014 at 2:41:00 PM Bartosz Dziewoński matma.rex@gmail.com wrote:
On Thu, 27 Nov 2014 21:02:39 +0100, Merlijn van Deen valhallasw@arctus.nl wrote (roughly):
I definitely like this proposal a lot more than the current one.
+1. Big improvement for callsigns :)
Yes, this is great, valhallasw. Thank you!
So instead of "DATAVALUEIMPLEMENTATIONS" we'd have "EDVM" and instead of "FUNDRAISINGTRANSLATEWORKFLOW" we'd have "EFTW". I'm sold.
Does anyone hate or object to this four-character scheme?
The only exception I'd make is MediaWiki. Under this scheme the callsign is MWMW. MediaWiki should be just plain MW.
-Chad
On Sat, 29 Nov 2014 17:51:11 +0100, Chad innocentkiller@gmail.com wrote:
The only exception I'd make is MediaWiki. Under this scheme the callsign is MWMW. MediaWiki should be just plain MW.
Feels slippery. Next thing you know, someone will want VE and SMW. :)
On 29 November 2014 at 09:13, Bartosz Dziewoński matma.rex@gmail.com wrote:
On Sat, 29 Nov 2014 17:51:11 +0100, Chad innocentkiller@gmail.com wrote:
The only exception I'd make is MediaWiki. Under this
scheme the callsign is MWMW. MediaWiki should be just plain MW.
Feels slippery. Next thing you know, someone will want VE and SMW. :)
I think MW and MWV would be reasonable for the two main mediawiki/* repos, but I don't really care.
I think "GVED" is ugly as hell , and though EVED is fine for the MediaWiki extension shell around VisualEditor ; VE and VEMW would make more sense in general, but they break the naming system , and I don't really care here either. :-)
When we have VE-WordPress and VE-Drupal and VE-Joomla and whatever, we'll put them as… GVEW, GVED, GVEJ *etc.* and just hope we never have a first character clash on integrations?
J.
James Forrester wrote:
I think MW and MWV would be reasonable for the two main mediawiki/* repos, but I don't really care.
I think "GVED" is ugly as hell, and though EVED is fine for the MediaWiki extension shell around VisualEditor; VE and VEMW would make more sense in general, but they break the naming system [...]
When we have VE-WordPress and VE-Drupal and VE-Joomla and whatever, we'll put them as… GVEW, GVED, GVEJ *etc.* and just hope we never have a first character clash on integrations?
VisualEditor/VisualEditor would most naturally be VEVE. I'm not sure if that's better or worse than GVED. It would mean that VE-Drupal would be VEDP, VE-WordPress would be VEWP, etc. Just a thought.
mediawiki/core could be WIKI, but people might object. MWMW is rough, yes.
Anyway, a foolish consistency and all that. :-) Maybe we can just specify a maximum character length? I think constraining ourselves a bit here is a good idea to ensure that the callsigns aren't crazy long, but I'm not sure a fixed length is absolutely necessary (though I do think it looks nicer).
MZMcBride
On the talk page I suggested dropping the "G" prefix for top-level repos, and just giving them an unprefixed callsign. I think that would fix the ugliness of some of the frequently used names.
On Sat, 29 Nov 2014 17:51:11 +0100, Chad innocentkiller@gmail.com wrote:
The only exception I'd make is MediaWiki. Under this
scheme the callsign is MWMW. MediaWiki should be just plain MW.
If we rename "mediawiki/core" to just "mediawiki" it becomes a top-level repo and can just be "MW".
On 29 November 2014 at 09:13, Bartosz Dziewoński matma.rex@gmail.com wrote:
Feels slippery. Next thing you know, someone will want VE and SMW. :)
If the "VisualEditor/VisualEditor" repo becomes "VisualEditor" I don't see anything against naming it "VE".
On 11/29/14 9:26 AM, James Forrester wrote:
When we have VE-WordPress and VE-Drupal and VE-Joomla and whatever, we'll put them as… GVEW, GVED, GVEJ *etc.* and just hope we never have a first character clash on integrations?
I think we would set up VE as a prefix rather than dumping them under general, so: VEWP, VEDP, VEJM (or whatever).
-- Legoktm
On Nov 29, 2014 1:58 PM, "Legoktm" legoktm.wikipedia@gmail.com wrote:
On the talk page I suggested dropping the "G" prefix for top-level repos, and just giving them an unprefixed callsign. I think that would fix the ugliness of some of the frequently used names.
On Sat, 29 Nov 2014 17:51:11 +0100, Chad innocentkiller@gmail.com
wrote:
The only exception I'd make is MediaWiki. Under this
scheme the callsign is MWMW. MediaWiki should be just plain MW.
If we rename "mediawiki/core" to just "mediawiki" it becomes a top-level repo and can just be "MW".
On 29 November 2014 at 09:13, Bartosz Dziewoński matma.rex@gmail.com wrote:
Feels slippery. Next thing you know, someone will want VE and SMW. :)
If the "VisualEditor/VisualEditor" repo becomes "VisualEditor" I don't see anything against naming it "VE".
On 11/29/14 9:26 AM, James Forrester wrote:
When we have VE-WordPress and VE-Drupal and VE-Joomla and whatever,
we'll
put them as… GVEW, GVED, GVEJ *etc.* and just hope we never have a first character clash on integrations?
I think we would set up VE as a prefix rather than dumping them under general, so: VEWP, VEDP, VEJM (or whatever).
-- Legoktm
+1
Three short notes:
- The G-prefix has on major advantage: it keeps the 'root namespace' (i.e. the first letter) clean: at the moment only A C E G L M O P S W are in use, so adding another prefix 'B' is easy. If we already have repositories that start with a B, it's more confusing.
- Being a bit more flexible with the length seems OK to me, but I would not do this for large namespaces (e.g. G and E). For 'the most important repository in a namespace', using a shorter callsign makes sense. So yes to MW, no to GVE and EVE. If it's important enough to be shorter, it's important enough to have it's own prefix.
- A seperate prefix for VE is sensible if a larger set of repositories are expected. GVED vs VEMW will be a bit confusing, though, so I'd suggest VEMW rather than EVED in that case.
Merlijn
On 29 November 2014 at 20:33, Nikolas Everett neverett@wikimedia.org wrote:
On Nov 29, 2014 1:58 PM, "Legoktm" legoktm.wikipedia@gmail.com wrote:
On the talk page I suggested dropping the "G" prefix for top-level repos, and just giving them an unprefixed callsign. I think that would fix the ugliness of some of the frequently used names.
On Sat, 29 Nov 2014 17:51:11 +0100, Chad innocentkiller@gmail.com
wrote:
The only exception I'd make is MediaWiki. Under this
scheme the callsign is MWMW. MediaWiki should be just plain MW.
If we rename "mediawiki/core" to just "mediawiki" it becomes a top-level repo and can just be "MW".
On 29 November 2014 at 09:13, Bartosz Dziewoński matma.rex@gmail.com wrote:
Feels slippery. Next thing you know, someone will want VE and SMW. :)
If the "VisualEditor/VisualEditor" repo becomes "VisualEditor" I don't see anything against naming it "VE".
On 11/29/14 9:26 AM, James Forrester wrote:
When we have VE-WordPress and VE-Drupal and VE-Joomla and whatever,
we'll
put them as… GVEW, GVED, GVEJ *etc.* and just hope we never have a first character clash on integrations?
I think we would set up VE as a prefix rather than dumping them under general, so: VEWP, VEDP, VEJM (or whatever).
-- Legoktm
+1 _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Sat, Nov 29, 2014 at 6:26 PM, Merlijn van Deen valhallasw@arctus.nl wrote:
- The G-prefix has on major advantage: it keeps the 'root namespace'
(i.e. the first letter) clean: at the moment only A C E G L M O P S W are in use, so adding another prefix 'B' is easy. If we already have repositories that start with a B, it's more confusing.
+1
On Fri, Nov 28, 2014 at 6:15 PM, MZMcBride z@mzmcbride.com wrote:
Chad wrote:
On Fri Nov 28 2014 at 2:41:00 PM Bartosz Dziewoński matma.rex@gmail.com wrote:
On Thu, 27 Nov 2014 21:02:39 +0100, Merlijn van Deen valhallasw@arctus.nl wrote (roughly):
I definitely like this proposal a lot more than the current one.
+1. Big improvement for callsigns :)
Yes, this is great, valhallasw. Thank you!
So instead of "DATAVALUEIMPLEMENTATIONS" we'd have "EDVM" and instead of "FUNDRAISINGTRANSLATEWORKFLOW" we'd have "EFTW". I'm sold.
Does anyone hate or object to this four-character scheme?
I have my own mapping of four-letter words to repositories, but this one works too.
On Thu, Nov 27, 2014 at 3:02 PM, Merlijn van Deen valhallasw@arctus.nl wrote:
I've fiddled a bit with this in the style of tail numbers / actual radio call signa: first letter is a category (country in a call sign), the rest is assigned as a number, unless someone wants a specific one.
The other day some of us were discussing something along these lines on IRC;[1] unfortunately that doesn't seem to have made it to the mailing list. We wound up liking something very similar to this, except we skipped the "unless someone wants a specific one" part. Always randomly assigning the number for everyone means no worry over conflicts.
[1]: http://bots.wmflabs.org/~wm-bot/logs/%23mediawiki-core/20141126.txt starting around 15:27
Categories: AN - analytics AP - apps CI - integration LT - labs/tools PH - phabricator PW - pywikibot
IMO it would be nice if the categories could all be the same length instead of some being one character and some being two.
On 27 Nov 2014, at 20:02, Merlijn van Deen valhallasw@arctus.nl wrote:
On 26 November 2014 at 23:29, MZMcBride z@mzmcbride.com wrote:
If we're stuck with using callsigns, the idea of using the shortest possible strings (a four-character hash?) appeals to me. If particular repos want specific available hashes (AAAA, FFFF), I'm fine with allocating on a first-come, first-served basis.
I've fiddled a bit with this in the style of tail numbers / actual radio call signa: first letter is a category (country in a call sign), the rest is assigned as a number, unless someone wants a specific one.
(..)
https://www.mediawiki.org/wiki/Phabricator/Diffusion/Callsign_naming_convent...
+1 as well. Like the restricted length. Not sure 4 is enough, but we can always grow later on.
Most license plate systems do the same. Though I'm not sure that was for the best.
-- Krinkle
On Mon Dec 01 2014 at 8:28:50 PM Krinkle krinklemail@gmail.com wrote:
On 27 Nov 2014, at 20:02, Merlijn van Deen valhallasw@arctus.nl wrote:
On 26 November 2014 at 23:29, MZMcBride z@mzmcbride.com wrote:
If we're stuck with using callsigns, the idea of using the shortest possible strings (a four-character hash?) appeals to me. If particular repos want specific available hashes (AAAA, FFFF), I'm fine with allocating on a first-come, first-served basis.
I've fiddled a bit with this in the style of tail numbers / actual radio call signa: first letter is a category (country in a call sign), the rest is assigned as a number, unless someone wants a specific one.
(..)
Callsign_naming_conventions/Existing_repositories_valhallasw
+1 as well. Like the restricted length. Not sure 4 is enough, but we can always grow later on.
/[A-Z]{4}/ produces 456976 possibilities. I don't think we'll run out anytime soon :)
-Chad
On Mon Dec 01 2014 at 9:09:18 PM Chad innocentkiller@gmail.com wrote:
On Mon Dec 01 2014 at 8:28:50 PM Krinkle krinklemail@gmail.com wrote:
On 27 Nov 2014, at 20:02, Merlijn van Deen valhallasw@arctus.nl wrote:
On 26 November 2014 at 23:29, MZMcBride z@mzmcbride.com wrote:
If we're stuck with using callsigns, the idea of using the shortest possible strings (a four-character hash?) appeals to me. If particular repos want specific available hashes (AAAA, FFFF), I'm fine with allocating on a first-come, first-served basis.
I've fiddled a bit with this in the style of tail numbers / actual radio call signa: first letter is a category (country in a call sign), the rest is assigned as a number, unless someone wants a specific one.
(..)
https://www.mediawiki.org/wiki/Phabricator/Diffusion/Callsig
n_naming_conventions/Existing_repositories_valhallasw
+1 as well. Like the restricted length. Not sure 4 is enough, but we can always grow later on.
/[A-Z]{4}/ produces 456976 possibilities. I don't think we'll run out anytime soon :)
So I'm thinking people are liking where we've ended up on callsigns...at least I haven't seen any major objections in the last day or so.
Do we have a rough consensus? If so, could we move Merlijn's table over the messy original one and update the guidelines to match the new plan? Once that's done I'd be glad to close out T1314 and we can start importing repositories.
-Chad
On 2 December 2014 at 13:51, Chad innocentkiller@gmail.com wrote:
So I'm thinking people are liking where we've ended up on callsigns...at least I haven't seen any major objections in the last day or so.
Do we have a rough consensus? If so, could we move Merlijn's table over the messy original one and update the guidelines to match the new plan? Once that's done I'd be glad to close out T1314 and we can start importing repositories.
Let's do it.
J.
On Tue Dec 02 2014 at 2:23:49 PM James Forrester jforrester@wikimedia.org wrote:
On 2 December 2014 at 13:51, Chad innocentkiller@gmail.com wrote:
So I'm thinking people are liking where we've ended up on callsigns...at least I haven't seen any major objections in the last day or so.
Do we have a rough consensus? If so, could we move Merlijn's table over the messy original one and update the guidelines to match the new plan? Once that's done I'd be glad to close out T1314 and we can start importing repositories.
Let's do it.
Pages are updated, T1314 has been closed. Thank you everyone for participating in this discussion on list, on IRC and on mw.org.
tl;dr: Callsigns are going to be /[A-Z]{2,4}/ with a preference towards {4}.
I think James and I are going to whip up a script to do this en masse rather than by hand but otherwise I think we're set :)
-Chad
Le 02/12/2014 22:51, Chad a écrit :
Do we have a rough consensus? If so, could we move Merlijn's table over the messy original one and update the guidelines to match the new plan? Once that's done I'd be glad to close out T1314 and we can start importing repositories.
I have a last minute concern: do the repository also have a path / explicit name such as mediawiki/extensions/VisualEditor ?
In Zuul we use the Gerrit repository name to attach Jenkins jobs to a project which makes it easy to understand :
project: mediawiki/core gate-and-submit: - mediawiki-core-do-stuff
In Jenkins Job Builder we have a list of all extensions basename which is iterated to forge jobs ex:
extension-names: - MobileFrontend - VisualEditor
jobs: - '{extension-names}-testextension'
Which yields the jobs:
MobileFrontend-testextension VisualEditor-testextension
I am not sure how Zuul/JJB will work out with call signs. Might end up being very messy.
On Tue Dec 02 2014 at 2:25:20 PM Antoine Musso hashar+wmf@free.fr wrote:
Le 02/12/2014 22:51, Chad a écrit :
Do we have a rough consensus? If so, could we move Merlijn's table over the messy original one and update the guidelines to match the new plan? Once that's done I'd be glad to close out T1314 and we can start importing repositories.
I have a last minute concern: do the repository also have a path / explicit name such as mediawiki/extensions/VisualEditor ?
Yes, the repo will also have a path for cloning (at a later time) and a name (which is arbitrary and can be changed by repo owners whenever they want).
I am not sure how Zuul/JJB will work out with call signs. Might end up being very messy.
I'm not sure either yet, but I don't imagine it'll be insurmountable. I think when we get to the repo paths for cloning/pushing/etc we'll keep something rather Gerrit-esque as otherwise we'd go insane :)
But that's still a ways off yet I think :)
-Chad
Le 02/12/2014 23:55, Chad a écrit :
Yes, the repo will also have a path for cloning (at a later time) and a name (which is arbitrary and can be changed by repo owners whenever they want).
Great, that works for me so :-]
Brad Jorsch (Anomie) wrote:
I can't find documentation anywhere for what's valid in callsigns besides "uppercase", but seeing feature requests for stuff like "Allow digits in callsigns" and "allow hyphens in callsigns" I'm suspecting the character set is literally [A-Z]. Which means a lot of the callsigns you have on that page aren't even valid.
Just to quickly follow up on this, Phabricator callsigns are indeed [A-Z]+. I've now noted this on mediawiki.org: https://www.mediawiki.org/w/index.php?diff=1297212&oldid=1281352.
MZMcBride
wikitech-l@lists.wikimedia.org