php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #55197 required validation
Submitted: 2011-07-13 01:14 UTC Modified: 2020-02-02 19:27 UTC
From: philip@php.net Assigned:
Status: Not a bug Package: Online Doc Editor problem
PHP Version: Irrelevant OS: Irrelevant
Private report: No CVE-ID: None
View Developer Edit
 [2011-07-13 01:14 UTC] philip@php.net 
Description:
------------
Problem:

People are creating invalid patches, which are patches that break the build. 
Then, people commit them without first running configure.php

Solution (concept):

Be sure people validate patches before making the commit

Solution (ideas):

Require configure.php to be ran before _any_ commit is made. Either do this 
immediately before commit, OR, allow it to be done while creating the patch and 
track it. Example "Patch FOO (last validated on 1/1/11)" or similar. That gets 
complicated as it requires tracking edits, so doing it before commit may be 
best.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2011-07-14 05:45 UTC] rquadling@php.net 
Just to add a little weight to this, and specifically for translators, of the 10 
translations, currently 5 have failed to pass configure.php. So no new Windows 
CHMs this week.

Would a "continuous integration" mechanism be suitable.

As I understand things, all of the PhD outputs can be built on Windows, and as 
Windows is required for the CHM and EnhancedCHM builds, it would seem suitable 
to do it all on one machine.

Would constantly building, or at least daily building, with emailed reports for 
failures only (though no news is assumed to be good news - so maybe report every 
build) be a viable solution?

I was thinking something along the lines of 
http://windows.php.net/downloads/snaps/php-trunk/ but for phpdoc.
 [2011-07-14 05:46 UTC] rquadling@php.net 
http://oti1.php.net/logs and http://oti1.php.net/logs/build.chms.log shows the 
current log files.
 [2011-07-16 09:34 UTC] philip@php.net 
I don't think we need another machine doing that. The edit.php.net machine checks builds for each 
translation and sends emails daily when a build is broken, but there appears to be a bug that is 
preventing or interfering with that now.

However, the intent of this bug report (feature request?) is to prevent the broken build in the first 
place.
 [2017-09-21 15:27 UTC] cmb@php.net 
> People are creating invalid patches, which are patches that break the build. 
> Then, people commit them without first running configure.php

In my opinion, a failing build is less severe than anybody committing nonsense
(e.g. wrong information, gibberish) which successfully builds. And if a build
fails, it might be sufficient to point the committer to
<http://doc.php.net/tutorial/editing.php>, particularly the section "Validating
your changes".
 [2017-09-21 15:29 UTC] cmb@php.net 
Ah, well, this is about PhDOE. I'm always running configure after having
committed several patches, and updated my SVN checkout, and I suggest others do
so as well.
 [2020-02-02 19:27 UTC] yannick@php.net
-Status: Open +Status: Not a bug
 [2020-02-02 19:27 UTC] yannick@php.net 
Thank you for taking the time to report a problem with PHP.
Unfortunately you are not using a current version of PHP --
the problem might already be fixed. Please download a new
PHP version from http://www.php.net/downloads.php

If you are able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to "Open".
Again, thank you for your continued support of PHP.

Too old ;)

Best,

Yannick
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Thu Dec 26 16:01:31 2024 UTC