[meta] Drupal.org (websites/infra) blockers to a Drupal 8 RC1 [#2267715] | Drupal.org

[meta] Drupal.org (websites/infra) blockers to a Drupal 8 RC1 [#2267715] | Drupal.org
Skip to search
Can we use first and third party cookies and web beacons to
understand our audience, and to tailor promotions you see
[meta] Drupal.org (websites/infra) blockers to a Drupal 8 RC1
Closed (fixed)
Project:
Drupal core
Version:
8.0.x-dev
Component:
other
Priority:
Major
Category:
Task
Assigned:
gábor hojtsy
Issue tags:
affects drupal.org
Needs issue summary update
about tags
Needs issue summary update
Issue summaries save everyone time if they are kept up-to-date. See
Update issue summary task instructions
Reporter:
webchick
Created:
14 May 2014 at 21:29 UTC
Updated:
23 Sep 2015 at 22:04 UTC
Jump to comment:
Most recent
This is a placeholder issue for all Drupal.org (websites/infra) issues that block release of Drupal 8.
See
infrastructure blocker for Drupal 8.0.0 (issues tagged in issue queues outside of the core queue)
(and the related issues in the sidebar). Only use that tag on issues NOT in the d8 core queue. Issues in the d8 core queue blocking d8 release are Critical and dont need a tag.
It's possible we actually
could
release Drupal 8 without these things being fixed, but it'd definitely suck.
This issue is postponed on the relevant drupal.org issues.
8.0.0 release candidate blockers
#2467925: [plan] Remove blockers to the "minimum viable" state of DrupalCI to ship Drupal 8 RC1
#2113957: Build server side version fallback system for translations
(unless we want to keep manually updating fallback versions for core in core's PHP)
8.0.0 release blockers
See
#2559711: [meta] Drupal.org (websites/infra) blockers to Drupal 8.0.0, 8.1.0, etc.
To allow Drupal to play nicely with the rest of the PHP community and Packagist we should use SemVer, current consensus is CORE.MAJOR.MINOR.PATCH.
#1612910: [policy, no patch] Switch to Semantic Versioning for Drupal contrib extensions (modules, themes, etc)
We need to understand how to push modules to Packagist under the drupal namespace. This is currently locked down to a select few people.
#2537818: Can't add to the Drupal namespace on Packagist
Not yet categorized
[none in here yet]
Fixed
#2229641: D8 usage statistics not shown on d.o
#2285063: Support for Drupal 8 logger API
#1963092: Convert .info file rewriting in packaging plugins to deal with D8 .info.yml files
#2163683: PIFT/PIFT communication broken by D9 requeued patch
#2283379: Update for complex tokens in Twig
#951114: Support all screen sizes
#2170443: [meta] Create a plan for implementing semantic versioning for core
#1867192: Testbots need to run on 5.4, 5.5, 5.6 and 7
#697220: Run tests on all supported database servers
#1424984: Port localize.drupal.org to Drupal 7
Comments
Comment
#1
webchick
she/they
Vancouver 🇨🇦
commented
14 May 2014 at 21:37
Parent issue:
#1963092: Convert .info file rewriting in packaging plugins to deal with D8 .info.yml files
Related issues:
#2267719: Drupal.org cannot support semantic versioning
or
to post comments
Comment
#2
hass
commented
15 May 2014 at 05:52
Status:
Postponed
» Closed (duplicate)
Duplicate of
#2229641: D8 usage statistics not shown on d.o
or
to post comments
Comment
#3
ianthomas_uk
he/him
Brighton, UK
commented
15 May 2014 at 10:08
Issue summary:
View changes
Status:
Closed (duplicate)
» Postponed
Duplicate isn't really appropriate, since that's in a separate project. Also, that's been marked duplicate of
#1963092: Convert .info file rewriting in packaging plugins to deal with D8 .info.yml files
or
to post comments
Comment
#4
longwave
he/him
UK
commented
15 May 2014 at 11:59
Duplicate of
#2179741: Drupal 8 usage statistics not being recorded?
but this has more info
or
to post comments
Comment
#5
catch
he/him
commented
15 May 2014 at 12:21
Category:
Bug report
» Task
Not a functional bug in core. I think we might want a single core meta issue to track Drupal.org 8.0.0 release blockers, but moving to task for now.
or
to post comments
Comment
#6
webchick
she/they
Vancouver 🇨🇦
commented
15 May 2014 at 14:13
Title:
Drupal.org cannot track Drupal 8 usage statistics
» Drupal.org blockers to a Drupal 8 release
Parent issue:
#1963092: Convert .info file rewriting in packaging plugins to deal with D8 .info.yml files
Related issues:
#2267715: [meta] Drupal.org (websites/infra) blockers to a Drupal 8 RC1
Oh, sure. Let's do that.
or
to post comments
Comment
#7
webchick
she/they
Vancouver 🇨🇦
commented
15 May 2014 at 14:15
Component:
update.module
» other
Related issues:
#2267719: Drupal.org cannot support semantic versioning
#2170443: [meta] Create a plan for implementing semantic versioning for core
or
to post comments
Comment
#8
webchick
she/they
Vancouver 🇨🇦
commented
15 May 2014 at 14:29
Issue tags:
affects drupal.org
Related issues:
#2267715: [meta] Drupal.org (websites/infra) blockers to a Drupal 8 RC1
#1963092: Convert .info file rewriting in packaging plugins to deal with D8 .info.yml files
Sorry, one more meta comment then I'll leave your poor inboxes alone. Wrong related issue, tagging for the D.o tech team.
or
to post comments
Comment
#9
webchick
she/they
Vancouver 🇨🇦
commented
15 May 2014 at 14:32
Issue summary:
View changes
I lied. :( Updating issue summary.
or
to post comments
Comment
#10
hass
commented
15 May 2014 at 15:04
I moved my case
#2229641: D8 usage statistics not shown on d.o
between
several
queues without getting any feedback for about nearly 2 months, before I identified the root cause myself and committed
Try to see if we get some statistics done until the packaging script will be fixed
. After more than 2 weeks I can say, this does not fix the reporting. There are still no D8 installations counted in GA module and I ran cron several times.
Thanks.
or
to post comments
Comment
#11
catch
he/him
commented
15 May 2014 at 15:37
Adding
#2268449: Run contrib module branch tests against both dev and latest stable core branches
. That's not a hard blocker to 8.0.0, but I'd be very wary about opening 8.1.x without it in place.
or
to post comments
Comment
#12
catch
he/him
commented
15 May 2014 at 15:37
Related issues:
#2268449: Run contrib module branch tests against both dev and latest stable core branches
or
to post comments
Comment
#13
webchick
she/they
Vancouver 🇨🇦
commented
16 May 2014 at 15:57
Related issues:
#2163683: PIFT/PIFT communication broken by D9 requeued patch
Another one.
or
to post comments
Comment
#14
rjacobs
commented
19 May 2014 at 23:32
Title:
Drupal.org blockers to a Drupal 8 release
» Drupal.org (websites/infra) blockers to a Drupal 8 release
Issue summary:
View changes
Maybe I scan titles too fast, but it took me a few moments to wrap my head around the fact that this issue is exclusively related to Drupal.org
website instances/infra
, and has nothing to do with any D8 core codebase issues. The ".org" part of the title just didn't register for some reason. Given that the title appears as a link anchor in lots of places (I got here via a related issue dup link) I figured it could not hurt to make this slightly more unmistakable.
or
to post comments
Comment
#15
catch
he/him
commented
23 May 2014 at 17:32
Related issues:
#697220: Run tests on all supported database servers
or
to post comments
Comment
#16
xjm
she/her
commented
26 May 2014 at 03:41
Related issues:
#2273481: Contrib PSR-4 PHPUnit tests are not picked up by PIFR
or
to post comments
Comment
#17
catch
he/him
commented
28 May 2014 at 16:12
Related issues:
#1867192: Testbots need to run on 5.4, 5.5, 5.6 and 7
or
to post comments
Comment
#18
gábor hojtsy
he/him
Hungarian
Hungary
commented
13 June 2014 at 16:24
Related issues:
#2285063: Support for Drupal 8 logger API
, +
#1933988: Support for Drupal 8 shipped configuration translatables with external dependencies (in effect contrib)
, +
#2283379: Update for complex tokens in Twig
Adding l.d.o Drupal 8 support issues as suggested by @catch, although one could say these should not only block release but even RCs as soon as we want to go out and say translators should go and translate Drupal 8. So these should be done even sooner.
or
to post comments
Comment
#19
catch
he/him
commented
13 June 2014 at 16:54
I've been assuming that everything linked from here blocks a release candidate.
We might find issues that don't but can sort that out a lot closer to the time.
or
to post comments
Comment
#20
gábor hojtsy
he/him
Hungarian
Hungary
commented
17 June 2014 at 12:06
Related issues:
#2113957: Build server side version fallback system for translations
Adding
#2113957: Build server side version fallback system for translations
based on catch's suggestion also.
or
to post comments
Comment
#21
webchick
she/they
Vancouver 🇨🇦
commented
18 June 2014 at 17:03
Related issues:
#1424984: Port localize.drupal.org to Drupal 7
Talked to Neil about this issue on the DSWG call today, he pointed out that porting localize.d.o to D7 is also a blocker for the other localize blockers.
or
to post comments
Comment
#22
gábor hojtsy
he/him
Hungarian
Hungary
commented
18 June 2014 at 17:05
I don't think its a blocker for any of the other blockers, we still keep building D8 supporting code on D6 now. I'm happy though its considered a release blocker, that drupal.org does not want to run an unsupported version of our own system. That's great.
or
to post comments
Comment
#23
hass
commented
20 June 2014 at 12:25
Related issues:
#2229641: D8 usage statistics not shown on d.o
If
#1963092: Convert .info file rewriting in packaging plugins to deal with D8 .info.yml files
has been fixed project statistics will still be broken.
or
to post comments
Comment
#24
webchick
she/they
Vancouver 🇨🇦
commented
5 August 2014 at 14:59
Related issues:
#1475510: Remove external dependencies from the core repo and let Composer manage the dependencies instead
Not sure if this will end up being a release blocker or not yet, but cataloguing here for now, since it'll require packaging changes.
or
to post comments
Comment
#25
webchick
she/they
Vancouver 🇨🇦
commented
6 August 2014 at 18:42
Related issues:
#951114: Support all screen sizes
Another one. Not a hard release blocker, just a "terribly embarrassing if D8 goes out without this fixed" type of deal.
or
to post comments
Comment
#26
catch
he/him
commented
22 September 2014 at 13:05
Not a blocker, but it'd be good to have api.drupal.org use 8.x as the default by 8.0.1 or so.
or
to post comments
Comment
#27
catch
he/him
commented
12 November 2014 at 20:27
Issue tags:
-revisit before release candidate
Already critical, removing tag.
or
to post comments
Comment
#28
xjm
she/her
commented
27 November 2014 at 18:41
Issue tags:
Triaged D8 critical
or
to post comments
Comment
#29
yesct
commented
4 December 2014 at 02:25
Issue summary:
View changes
Added a note in the summary about the
infrastructure blocker for Drupal 8.0.0
tag.
Should give us a nicer way to view the issues, and see what queues they are in.
(we can also add "related" issues here without that needing to indicate they are blocking release. just the ones with the tag will block.)
or
to post comments
Comment
#30
catch
he/him
commented
28 January 2015 at 14:12
Title:
Drupal.org (websites/infra) blockers to a Drupal 8 release
» [meta] Drupal.org (websites/infra) blockers to a Drupal 8 release
or
to post comments
Comment
#31
webchick
she/they
Vancouver 🇨🇦
commented
4 February 2015 at 18:05
Issue tags:
Needs issue summary update
Related issues:
#2352091: Create (and maintain) a subtree split of Drupal core
Adding another one that's not a hard blocker but is related, per drumm.
Also tagging as needing an issue summary update, as it's unclear to the DA currently which of these are "must-have" to ship D8 and which are "really would be nice" and which are "meh."
or
to post comments
Comment
#32
catch
he/him
commented
5 February 2015 at 13:09
Issue summary:
View changes
Made a start on categorizing the issues.
or
to post comments
Comment
#33
catch
he/him
commented
5 February 2015 at 13:14
Issue summary:
View changes
or
to post comments
Comment
#34
gábor hojtsy
he/him
Hungarian
Hungary
commented
5 February 2015 at 15:34
Issue summary:
View changes
or
to post comments
Comment
#35
yesct
commented
26 February 2015 at 21:29
Issue summary:
View changes
formatting.
or
to post comments
Comment
#36
webchick
she/they
Vancouver 🇨🇦
commented
22 April 2015 at 22:35
Just for visibility, here's the proposal on the "MVP" in terms of DrupalCI for PHP/database versions to bring Drupal 8 to a shippable state:
#2467925: [plan] Remove blockers to the "minimum viable" state of DrupalCI to ship Drupal 8 RC1
or
to post comments
Comment
#37
webchick
she/they
Vancouver 🇨🇦
commented
24 April 2015 at 22:44
Issue summary:
View changes
Related issues:
#2349443: [META] Problems found during click testing localize-7 in Amsterdam
Updating issue summary with a reference to
#2349443: [META] Problems found during click testing localize-7 in Amsterdam
, which is holding up
#1424984: Port localize.drupal.org to Drupal 7
or
to post comments
Comment
#38
webchick
she/they
Vancouver 🇨🇦
commented
24 April 2015 at 22:46
Issue summary:
View changes
Er, thought I did anyway.
or
to post comments
Comment
#39
webchick
she/they
Vancouver 🇨🇦
commented
11 May 2015 at 10:10
Priority:
Critical
» Major
Downgrading, since this is now captured in the release checklist, per
#2485119-7: [meta] The Drupal 8.0.0-rc1 Release Checklist
or
to post comments
Comment
#40
mgifford
he/him
commented
29 June 2015 at 20:21
Status:
Postponed
» Active
Think this can be moved to active as
#1963092: Convert .info file rewriting in packaging plugins to deal with D8 .info.yml files
is fixed.
or
to post comments
Comment
#41
mbrett5062
commented
5 July 2015 at 17:07
Issue tags:
Triaged D8 critical
Removing "Triaged D8 critical" tag, as this is no longer critical re:
#39
or
to post comments
Comment
#42
David_Rothstein
commented
11 July 2015 at 16:06
8.0.0 release candidate blockers
.....
#1867192: Testbots need to run on php 5.3.10, 5.4, 5.5, 5.6 and 7
#697220: Run tests on all supported database servers/engines (unless we drop core support for both postgres and sqlite)
Although these are really great features, I'm not sure why they'd be release blockers... Their absence has never blocked releases before.
In any case, they look to me to have been mostly implemented already for Drupal 8, so can they be removed from the list either way? :)
or
to post comments
Comment
#43
japerry
KOMK
commented
19 July 2015 at 19:55
Localize is super close to a launch, just have 2 or so issues that need to be closed.
or
to post comments
Comment
#44
webchick
she/they
Vancouver 🇨🇦
commented
22 July 2015 at 19:00
Since we are within sight of
10 D8 release blockers
(if we don't find any more, this could potentially happen this week!) wanted to revisit this list.
Done!
Semver.
#2170443: [meta] Create a plan for implementing semantic versioning for core
Testbots on various environments:
#1867192: Testbots need to run on 5.4, 5.5, 5.6 and 7
#697220: Run tests on all supported database servers
has:
PHP 5.5 & MySQL 5.5
PHP 5.6 & MySQL 5.5
PHP 7 & MySQL 5.5
PHP 5.5 & SQLite 3.8
PHP 5.5 & PostgreSQL 9.1
Partially done.
#1424984: Port localize.drupal.org to Drupal 7
- According to japerry this is really close. This is not actually the blocker to D8, though, those are...
Not started.
While good progress has been made on the D7 port of localize, nothing has yet been done on the two big Localization-related blockers for D8:
Blocks D8 sites getting translations any later than 8.0.0-beta1:
#1933988: Support for Drupal 8 shipped configuration translatables with external dependencies (in effect contrib)
Blocks D8 translations in contrib:
#2113957: Build server side version fallback system for translations
Needs research.
#2273481: Contrib PSR-4 PHPUnit tests are not picked up by PIFR
This is still RTBC for PIFR, needs checking to see if it applies to DrupalCI.
I'll update the issue summary with this once I get confirmation from a couple of other committers that this is accurate.
Note that there are other issues also tracked above (Composer, contrib support for DrupalCI, etc.) that are not in this list, because AFAIK they do not directly block a Drupal 8.0.0 release.
or
to post comments
Comment
#45
yesct
commented
22 July 2015 at 19:05
Under needs research,
there was something mentioned in
about
#2273481: Contrib PSR-4 PHPUnit tests are not picked up by PIFR
"Contrib testing for Drupal8 is very nearly ready for deployment."
or
to post comments
Comment
#46
catch
he/him
commented
22 July 2015 at 19:12
Although these are really great features, I'm not sure why they'd be release blockers... Their absence has never blocked releases before.
They never blocked release before, but we've never had a release with working sqlite or postgresql support before either. So the idea was to release either with those working, or without them altogether, but not to keep pretending we support postgres and sqlite when we don't. This is all working now though which is fantastic, and sqlite/postgres should be 100% pass.
or
to post comments
Comment
#47
David_Rothstein
commented
22 July 2015 at 20:13
Supposedly both PostgreSQL and SQLite work OK on Drupal 7 (no
critical issues filed
, at any rate) - not sure if that was the case when Drupal 7 was released. But yes, it's really nice to be able to have the testbot run on those.
or
to post comments
Comment
#48
gábor hojtsy
he/him
Hungarian
Hungary
commented
28 July 2015 at 16:10
@webchick, you mixed up the issues:
While good progress has been made on the D7 port of localize, nothing has yet been done on the two big Localization-related blockers for D8:
Blocks D8 sites getting translations any later than 8.0.0-beta1:
#1933988: Support for Drupal 8 shipped configuration translatables with external dependencies (in effect contrib)
Blocks D8 translations in contrib:
#2113957: Build server side version fallback system for translations
Should be the other way around:
Blocks D8 sites getting translations any later than 8.0.0-beta1:
#2113957: Build server side version fallback system for translations
Blocks D8 translations in contrib:
#1933988: Support for Drupal 8 shipped configuration translatables with external dependencies (in effect contrib)
Also we can work around
#2113957: Build server side version fallback system for translations
at least for core (not for distros) with manual release instructions. @catch wanted to avoid that and revisit
#2113957: Build server side version fallback system for translations
later in the cycle "if that was the only one left".
or
to post comments
Comment
#49
catch
he/him
commented
28 July 2015 at 17:00
I'm a bit confused on what the issue with core translations is.
I thought we'd improved it with
#1914070: Improve version fallback for install language.
and that should work now we update the VERSION constant in core and do release nodes?
The impression I had was that it was only an issue for 8.0.x-dev snapshots or git checkouts, which feels like it should be solved by either git_deploy or l.d.o - I don't think the right translation fallback for dev snapshots is release blocking (and also don't think an extra release step is worth it as a workaround either).
If we have an issue for tagged releases then that obviously is release blocking but could use a reminder of the exact bug and what the core workaround would be.
or
to post comments
Comment
#50
gábor hojtsy
he/him
Hungarian
Hungary
commented
29 July 2015 at 07:45
@catch: It is true that beta releases started coming out with a version constant fitting the release with beta10 and later. This makes install_get_localization_release() kick in adding 8.0.0-beta12, 8.0.0-alpha1 and 7.0 as a candidates for the upcoming beta13 for example. So if there was a beta12 translation, it will be downloaded fine. This may be unpredictable if two releases come out in quick succession, as we have seen with some betas before and may see with minor releases later on. Then the fallback is to a much earlier version because we don't have info on what was the latest earlier version (the server side fallback would know). So if beta14 comes out within say a day or beta13 for whatever reason, l.d.o is not yet caught up with all the .po files, so translation downloads will then fall back to alpha1 until beta13 and beta14 translations become available. (Beta12 is not checked in this case because the list of fallbacks was designed to get to a somewhat useful file at least sooner than later to not slow down the installer with too many HTTP requests).
The same effect is going to be even stronger right when Drupal 8.0.0 is released, because until translation files become available, it will attempt to first do an HTTP request for 8.0.0's translation, not find it then the next fallback 8.0.0-rc1 will be looked for (even if RC1 was months earlier and if there were possibly multiple string changes due to critical bugs).
I am fine if we know about these problems and we don't consider them release blocking.
I understood that both the multiple HTTP requests required in the installer (slowing it down) and that old translations will be used due to unknown prior versions were the reason
#2113957: Build server side version fallback system for translations
was made a blocker. We can remove it from the blockers if these two are not release blocking problems.
or
to post comments
Comment
#51
timmillwood
🏴󠁧󠁢󠁷󠁬󠁳󠁿 Wales, UK
commented
4 August 2015 at 15:50
Issue summary:
View changes
Moved
#1475510: Remove external dependencies from the core repo and let Composer manage the dependencies instead
and
#2352091: Create (and maintain) a subtree split of Drupal core
to nice to have. These should not block any 8.x release, but really really nice, nice to haves as they make life a lot easier for those building Drupal sites using composer.
or
to post comments
Comment
#52
timmillwood
🏴󠁧󠁢󠁷󠁬󠁳󠁿 Wales, UK
commented
4 August 2015 at 15:57
Issue summary:
View changes
Added
#1612910: [policy, no patch] Switch to Semantic Versioning for Drupal contrib extensions (modules, themes, etc)
and
#2537818: Can't add to the Drupal namespace on Packagist
as nice to haves.
or
to post comments
Comment
#53
catch
he/him
commented
4 August 2015 at 16:45
@Gabor so from #50 I'm still not sure what the workaround in core is - that we'd manually add 8.0.0-rc3 as a fallback for 8.0.0? Where does that go if so? Or are you saying the current state of core fallback is as good as it gets now, and it's a question of whether the l.d.o work should block release or not?
So if beta14 comes out within say a day or beta13 for whatever reason, l.d.o is not yet caught up with all the .po files
What's the reason for the lag? Is it literally a 24 hour cron job or something else?
or
to post comments
Comment
#54
webchick
she/they
Vancouver 🇨🇦
commented
12 August 2015 at 22:29
Localize is now on D7. :) view-source:
or
to post comments
Comment
#55
gábor hojtsy
he/him
Hungarian
Hungary
commented
13 August 2015 at 06:57
@catch: the reason for the lag is the three step process:
l.d.o first needs to get to know about the release, that is parsed in from a dump from d.o
then l.d.o needs to grab the tar.gz and extract/parse it for all the source strings
then l.d.o needs to export the .po files for the strings found
All three need to happen in succession. The cronjob for the first two is the same and runs every 5 minutes. *However* the export for the first one is only refreshed daily or so on drupal.org. (I've only found the release history XML job in jenkins, which may be tied to the tsv we use for (1), but indirectly based on when l.d.o's jobs find new projects, it looks like daily). Then (3) also runs every 5 minutes. It gives precedence to projects based on usage (well, at least an outdated copy of usage from a year or so ago), so it will generate core stuff first and foremost if all goes well. So unless there are issues on l.d.o, the bottleneck looks more like d.o giving out new project info only daily.
As for knowing the last release on a lower level, that either needs to be hardcoded when release levels are bumped (alpha to beta, beta to rc, rc to release, 8.0.x to 8.1.x, 8.max.x to 9.0, etc) or a server side fallback needs to be provided. The good thing about the fallback at least is it only needs to be provided manually when a release level is jumped over, if we choose to handle it manually and not automate it.
or
to post comments
Comment
#56
webchick
she/they
Vancouver 🇨🇦
commented
14 August 2015 at 06:46
Issue summary:
View changes
We had a pow-wow today with most of the core committers (@xjm, @alexbronstein, @alexpott, @catch) as well as most of the DA tech team (@drumm, @basic, @isntall, @joshuami, @Mixologic, @hestenet, @japerry... hope I didn't forget anyone!) to go through this list.
Localize
#1424984: Port localize.drupal.org to Drupal 7
is done now. Yay!
#2113957: Build server side version fallback system for translations
is what Jakob is working on now. He and Neil think the plan outlined by Gábor in
#2113957-18: Build server side version fallback system for translations
should work, and should be doable before D8's release.
#1933988: Support for Drupal 8 shipped configuration translatables with external dependencies (in effect contrib)
has not really been looked at yet, but herom is working on a patch.
DrupalCI
We now have the environments we need, so closed out
#1867192: Testbots need to run on 5.4, 5.5, 5.6 and 7
and
#697220: Run tests on all supported database servers
However, there are still quite a few D8 blockers from the DrupalCI side, which are enumerated at
#2467925-80: [plan] Remove blockers to the "minimum viable" state of DrupalCI to ship Drupal 8 RC1
. SQLite/PostgreSQL aren't passing, only a handful of tests are being run on PostgreSQL, a workaround for lack of MariaDB testing, and regularly updated (and transparent) PHP 7 testbots.
There's another class of blockers at
#2534132: Disable Legacy Testbots and use drupalCI as our testing infrastructure
, but these block the shutting off of PIFT, not Drupal 8 specifically.
Updated issue summary to reflect what I believe is the current status. If I missed anything, please feel free to adjust.
or
to post comments
Comment
#57
catch
he/him
commented
14 August 2015 at 09:09
I just opened
#2551309: Increase opcache.max_accelerated_files
to have an explicit issue for the PIFR blocker to
#2495411: Make simpletest fail a test when it detects pages that need more than 64MB
That's not a hard blocker for release, mainly for that patch, but it would allow us to take memory checks off the performance checklist item, since we'd have memory constraints enforced in core.
Could be solved either by fixing the PIFR opcache configuration or switching it off.
or
to post comments
Comment
#58
timmillwood
🏴󠁧󠁢󠁷󠁬󠁳󠁿 Wales, UK
commented
14 August 2015 at 09:17
Can we add
#2315537: Install composer dependencies before running tests
to any DrupalCI discussions?
or
to post comments
Comment
#59
webchick
she/they
Vancouver 🇨🇦
commented
14 August 2015 at 14:32
Not in this issue, since it's a feature request and it doesn't block D8.
or
to post comments
Comment
#60
webchick
she/they
Vancouver 🇨🇦
commented
26 August 2015 at 21:56
As an update...
#2467925: [plan] Remove blockers to the "minimum viable" state of DrupalCI to ship Drupal 8 RC1
looks close. Might even be done (marked it RTBC just now). Needs confirmation from a PostgreSQL hero.
#2113957: Build server side version fallback system for translations
is RTBC. Gábor is back "in the office" tomorrow and should hopefully be able to confirm.
Either
#2273481: Contrib PSR-4 PHPUnit tests are not picked up by PIFR
or
#2538462: Contrib Testing Test discovery not working for d6/d7
is an 8.0.0 blocker, but wouldn't necessarily need to block RC. But one way or another, contrib needs to be able to run unit tests before 8.0.0 ships (and the sooner, the better, for module porting acceleration).
* By the same logic, we could shift the deadline of
#1933988: Support for Drupal 8 shipped configuration translatables with external dependencies (in effect contrib)
to an 8.0.0 blocker instead, since it likewise only screws contrib, not core.
So we
may
be able to remove this from the RC1 checklist soon-ish if those RTBC things end up actually RTBC.
or
to post comments
Comment
#61
webchick
she/they
Vancouver 🇨🇦
commented
28 August 2015 at 14:58
Title:
[meta] Drupal.org (websites/infra) blockers to a Drupal 8 release
» [meta] Drupal.org (websites/infra) blockers to a Drupal 8 RC1
Assigned:
Unassigned
gábor hojtsy
Status:
Active
» Reviewed & tested by the community
Talked with most of the core committers yesterday—@xjm, @catch, @alexpott, @effulgentsia—and we agreed that we could split this up into two phases:
a) Things that block core == RC1 blocker.
b) Things that block contrib == 8.0.0 blocker.
In light of that, since
#2467925: [plan] Remove blockers to the "minimum viable" state of DrupalCI to ship Drupal 8 RC1
was just marked Fixed, I
believe
that we might actually be done here. (We can re-purpose this issue from RC1 => 8.0.0 and move it to critical once RC1 is shipped.)
It would be good for Gábor to chime in here with his thoughts on whether or not that's true, but I believe:
1) Either
#2273481: Contrib PSR-4 PHPUnit tests are not picked up by PIFR
or
#2538462: Contrib Testing Test discovery not working for d6/d7
are a blocker for 8.0.0 (I know the DA plans to turn off PIFT as soon as possible, so hopefully the second one).
2) Translations are inherently contrib, so
#2113957: Build server side version fallback system for translations
(which is RTBC anyway) and
#1933988: Support for Drupal 8 shipped configuration translatables with external dependencies (in effect contrib)
would block 8.0.0, not RC1.
Marking RTBC + assigning to Gábor to get some visibility on this question.
or
to post comments
Comment
#62
gábor hojtsy
he/him
Hungarian
Hungary
commented
28 August 2015 at 15:24
Seeing
#2113957: Build server side version fallback system for translations
done looks good, however it does not help until
#2113955: Rely on proper server side version fallback for translations
is also done (or Drupal core is manually updated with last version numbers). While it does not block RC1, it would be sad to get it done as late as 8.0.0 if we want to get translators test with the latest translations using Drupal dev versions and not require them to use concrete tagged betas/RCs. If we are fine requiring translators to use tagged releases at all times to test their translations and/or manually keep updating last versions in core PHP files, then this does not block any release whatsoever.
#1933988: Support for Drupal 8 shipped configuration translatables with external dependencies (in effect contrib)
only affects contrib as the title shows :)
or
to post comments
Comment
#63
gábor hojtsy
he/him
Hungarian
Hungary
commented
28 August 2015 at 15:24
Assigned:
gábor hojtsy
» Unassigned
or
to post comments
Comment
#64
webchick
she/they
Vancouver 🇨🇦
commented
28 August 2015 at 17:14
My layman's, not-a-translator opinion is that testing against latest dev will become important as Drupal 8.0.0 gets closer and closer to release, but that for the first little while during RC there'll be more than enough new/changed strings in D8 to keep translators busy, so tagged releases only is fine for the first few.
Happy to be told I'm wrong about that, though.
or
to post comments
Comment
#65
catch
he/him
commented
28 August 2015 at 23:24
Title:
[meta] Drupal.org (websites/infra) blockers to a Drupal 8 RC1
» [meta] Drupal.org (websites/infra) blockers to a Drupal 8 RC1/8.0.0
Just updating the title since the issue summary has information relevant to post-RC i.e.
#2559575: [meta] The Drupal 8.0.0 Release Checklist
or
to post comments
Comment
#66
catch
he/him
commented
28 August 2015 at 23:28
Issue summary:
View changes
or
to post comments
Comment
#67
catch
he/him
commented
29 August 2015 at 09:36
Title:
[meta] Drupal.org (websites/infra) blockers to a Drupal 8 RC1/8.0.0
» [meta] Drupal.org (websites/infra) blockers to a Drupal 8 RC1
Issue summary:
View changes
I've moved 8.0.0 (and after) blockers to
#2559711: [meta] Drupal.org (websites/infra) blockers to Drupal 8.0.0, 8.1.0, etc.
or
to post comments
Comment
#68
webchick
she/they
Vancouver 🇨🇦
commented
31 August 2015 at 21:01
Status:
Reviewed & tested by the community
» Fixed
Ok, no disagreements so I think we can call this good to go for RC1. YAY!
or
to post comments
Comment
#69
webchick
she/they
Vancouver 🇨🇦
commented
31 August 2015 at 21:14
Assigned:
Unassigned
gábor hojtsy
Status:
Fixed
» Needs review
Ah, hold on, I was a bit hasty there.
I think we still need Gábor to respond to #64, because I notice
#2113957: Build server side version fallback system for translations
got bumped back from RTBC. My read of #63 is that we either need both
#1933988: Support for Drupal 8 shipped configuration translatables with external dependencies (in effect contrib)
and
#2113955: Rely on proper server side version fallback for translations
in before RC1, or both of them kicked out of the RC1 checklist and moved to 8.0.0 blockers in
#2559711: [meta] Drupal.org (websites/infra) blockers to Drupal 8.0.0, 8.1.0, etc.
instead.
There was also some concern from @catch that without one/both? of those fixes, translators would get beta1 for the first 24 hours of rc1's release? Any way to mitigate that, such as manually returning "8.0.0-rc1" from api.drupal.org/api/function/install_get_localization_release/8 in the tagged release?
Basically, I think the bottom line: what of this
must
block RC1 (which I believe means: prevents translators from starting their D8 translations) vs. what of this can wait until after RC1 but
must
be done before 8.0.0 (which I believe means: prevents translators from finishing their D8 translations)?
or
to post comments
Comment
#70
hass
commented
1 September 2015 at 15:59
@webchick: What is the roadmap/deadline for fixing translatable strings? Do we have a tag?
or
to post comments
Comment
#71
gábor hojtsy
he/him
Hungarian
Hungary
commented
1 September 2015 at 16:07
@webchick: yes, we can either manually hardcode the fallback list (add the last (or last two) beta release numbers so they are used as fallback for RC1) or do
#2113955: Rely on proper server side version fallback for translations
if the server side fallback is working well now. That should help core translatability.
#1933988: Support for Drupal 8 shipped configuration translatables with external dependencies (in effect contrib)
was already moved to
#2559711: [meta] Drupal.org (websites/infra) blockers to Drupal 8.0.0, 8.1.0, etc.
or
to post comments
Comment
#72
webchick
she/they
Vancouver 🇨🇦
commented
4 September 2015 at 17:49
I was still confused from that comment, so asked Gábor to tell me in very small words what is still needed here. :)
Basically:
- All of this revolves around the "little function that could,"
function install_get_localization_release()
. This is the function that returns which Drupal version's translations to pull in when downloading translations during installation.
- For tagged releases (beta15, rc1, etc.) this function does what it's intended to do. There is a problem where .po files on localize.drupal.org lag about ~48 hours behind the creation of the release on Drupal.org. However, this is an existing problem, doesn't block RC1. (It could use some investigation by DA staff, however; summary: d.o generates a dump of their new releases every day. l.d.o tries to in fact parse it every fine minutes (LOL) but its only updated once daily on d.o.)
- For dev releases, this function will attempt to make a guess. Until
both
#2113957: Build server side version fallback system for translations
and
#2113955: Rely on proper server side version fallback for translations
are done, it will have no choice but to try and do this in an extremely silly way, which is falling back to the
first
release of a given type (alpha1, beta1, rc1). See
There are, however, at least two workarounds:
#1: Until those two d.o issues are fixed, as part of the checklist before tagging a release, manually hack the following lines in install_get_localization_release:
$alternatives[] = $info['major'] . '.' . $info['minor'] . '.0-rc1';
$alternatives[] = $info['major'] . '.' . $info['minor'] . '.0-beta1';
to instead be the current release
and the one previous
(to account for the 48 hour lag). So hypothetically in beta15 right now it would read:
$alternatives[] = $info['major'] . '.' . $info['minor'] . '.0-rc1';
$alternatives[] = $info['major'] . '.' . $info['minor'] . '.0-beta15';
$alternatives[] = $info['major'] . '.' . $info['minor'] . '.0-beta14';
then in RC1 (assuming we don't have a beta16) it would be:
$alternatives[] = $info['major'] . '.' . $info['minor'] . '.0-rc1';
$alternatives[] = $info['major'] . '.' . $info['minor'] . '.0-beta15';
then in RC2 it would be:
$alternatives[] = $info['major'] . '.' . $info['minor'] . '.0-rc2';
$alternatives[] = $info['major'] . '.' . $info['minor'] . '.0-rc1';
...and so on. Which feels messy and error-prone to me, but hey, it's a workaround.
The second is putting some kind of disclaimer in a drupal_set_message() or whatever on localize.drupal.org that's like:
"Attention Drupal 8 translators: Note that you should only be translating against tagged releases of Drupal 8 (e.g. beta15, rc1), not dev releases, until
these
issues
are fixed."
And then move those issues to 8.0.0 blockers vs. RC1 blockers.
That seems like a 30 second solution, but not sure if it's sufficient.
or
to post comments
Comment
#73
webchick
she/they
Vancouver 🇨🇦
commented
9 September 2015 at 21:51
Status:
Needs review
» Fixed
Ok!
#2113957: Build server side version fallback system for translations
is officially DONE! I tested and committed the core patch to remove the silly non-serverside language fallback system here:
#2113955: Rely on proper server side version fallback for translations
I believe. We. Are. FINISHED! Thank you so much, DA!!!
or
to post comments
Comment
#74
webchick
she/they
Vancouver 🇨🇦
commented
9 September 2015 at 21:56
Oh, and see you at
#2559711: [meta] Drupal.org (websites/infra) blockers to Drupal 8.0.0, 8.1.0, etc.
. ;)
or
to post comments
Comment
#75
23 September 2015 at 22:04
Status:
Fixed
» Closed (fixed)
Automatically closed - issue fixed for 2 weeks with no activity.
or
to post comments
Contribution record
Child issues
#2467925: [plan] Remove blockers to the "minimum viable" state of DrupalCI to ship Drupal 8 RC1
#2559711: [meta] Drupal.org (websites/infra) blockers to Drupal 8.0.0, 8.1.0, etc.
Add child issue
clone issue
Related issues
Referenced by
#2318191: [meta] Database tests fail on SQLite
Infrastructure management for Drupal.org provided by
Need a Drupal 7 extended support partner? Consider Tag1.
News items
News
Planet Drupal
Social media
Sign up for Drupal news
Security advisories
Jobs
Our community
Community
Services
Training
Hosting
Contributor guide
Groups & meetups
DrupalCon
Code of conduct
Documentation
Documentation
Drupal Guide
Drupal User Guide
Developer docs
API.Drupal.org
Drupal code base
Download & Extend
Drupal core
Modules
Themes
Distributions
Governance of community
About
Web accessibility
Drupal Association
About Drupal.org
Drupal is a
registered trademark
of
Dries Buytaert