Page MenuHomePhabricator

Increase release notes range
Closed, ResolvedPublic

Description

Right now using the release notes generator is hardcoded at a range of 5000 revs max.

Would be nice to increase this, especially since the commit rate has gone up significantly and a release is much more than 5000 revs these days :)

Obvious dependency added.


Version: unspecified
Severity: enhancement

Details

Reference
bz25437

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:13 PM
bzimport set Reference to bz25437.
bzimport added a subscriber: Unknown Object (MLST).
		if ( $this->mStartRev < ( $lastRev - 10000 ) ) {
			global $wgOut;
			$wgOut->addHtml( wfMsgHtml( 'code-release-badrange' ) );
			return;
		}

Seems this one is 10k now ;)

I bumped it to 10k and committed to trunk. Was this merged to deployment?

mysql> DESCRIBE SELECT cr_message,cr_author,cr_id,ct_tag AS rnotes FROM mw_code_rev LEFT JOIN mw_code_tags ON ((ct_repo_id = cr_repo_id AND ct_rev_id = cr_id AND ct_tag = "release-notes")) WHERE cr_repo_id = '3' AND (cr_status NOT IN('reverted','deferred','fixme')) AND (cr_message != '') AND (cr_id BETWEEN 77000 AND 78000 AND (cr_path LIKE '/trunk/phase3/%' OR cr_path = '/trunk/phase3')) ORDER BY cr_id DESC ;
+----+-------------+--------------+--------+-----------------------------------------+---------+---------+--------------------------------------------------------------+------+-------------+

idselect_typetabletypepossible_keyskeykey_lenrefrowsExtra

+----+-------------+--------------+--------+-----------------------------------------+---------+---------+--------------------------------------------------------------+------+-------------+

1SIMPLEmw_code_revrangePRIMARY,cr_repo_id,cr_repo_author,cr_idPRIMARY8NULL2370Using where
1SIMPLEmw_code_tagseq_refPRIMARY,ct_repo_idPRIMARY265wikidb.mw_code_rev.cr_repo_id,wikidb.mw_code_rev.cr_id,const1Using index

+----+-------------+--------------+--------+-----------------------------------------+---------+---------+--------------------------------------------------------------+------+-------------+
2 rows in set (0.00 sec)

That query looks fine :|

Doing that query... With SQL_NO_CACHE

327 rows in set (0.00 sec)

I'm thinking this isn't too bad. I'm gonna remove the technical restrictions later on today and close this bug :)

Linking to 23720, as this has a similar path based bug

r79395, r79400

And the stuff to improve the way all the paths were saved beforehand

ayg wrote:

When pasting these things in the future, use \G instead of ; as statement terminator, so that the result is more legible. E.g.,

DESCRIBE SELECT cr_message,cr_author,cr_id,ct_tag AS rnotes FROM
mw_code_rev LEFT JOIN mw_code_tags ON ((ct_repo_id = cr_repo_id AND
ct_rev_id = cr_id AND ct_tag = "release-notes")) WHERE cr_repo_id = '3' AND
(cr_status NOT IN('reverted','deferred','fixme')) AND (cr_message != '') AND
(cr_id BETWEEN 77000 AND 78000 AND (cr_path LIKE '/trunk/phase3/%' OR cr_path

'/trunk/phase3')) ORDER BY cr_id DESC \G

The ";" format tends to break horribly when you paste long rows into Bugzilla, which inserts line breaks.