Grokbase › Groups › PHP › php-internals › October 2013
FAQ
Just to be sure everybody has a chance to read and comment:
On 9 October 2013 09:07, Michael Wallner wrote:
Thanks for your feedback! I fixed NEWS for the upcoming releases.
Please let us have an eye on it in the future!
Okay -- looking at NEWS.GIT-RULES it actually says the opposite:

2. All news updates intended for public viewing, such as new features,
bug fixes, improvements, etc., should go into the NEWS file of the
*first* to be released version with the given change. In other words
any NEWS file change only needs to done in one branch.

How about changing it to:

2. All news updates intended for public viewing, such as new features,
bug fixes, improvements, etc., should go into the NEWS file of *any
stable release* version with the given change. In other words,
news about a bug fix which went into PHP-5.4, PHP-5.5 and master
should be noted in both PHP-5.4/NEWS and PHP-5.5/NEWS but
not master, which is not a public released version yet.

PS: I post that for other people that had not time to notice this
discussion and I will most probably give a week or so for others to
speek up before changing any settled rules. Could well be there are
people who do not want to write two NEWS entries :)


--
Regards,
Mike

Search Discussions

  • Nikita Popov at Oct 16, 2013 at 12:26 pm ⇧

    On Tue, Oct 15, 2013 at 2:54 PM, Michael Wallner wrote:

    Just to be sure everybody has a chance to read and comment:
    On 9 October 2013 09:07, Michael Wallner wrote:
    Thanks for your feedback! I fixed NEWS for the upcoming releases.
    Please let us have an eye on it in the future!
    Okay -- looking at NEWS.GIT-RULES it actually says the opposite:

    2. All news updates intended for public viewing, such as new features,
    bug fixes, improvements, etc., should go into the NEWS file of the
    *first* to be released version with the given change. In other words
    any NEWS file change only needs to done in one branch.

    How about changing it to:

    2. All news updates intended for public viewing, such as new features,
    bug fixes, improvements, etc., should go into the NEWS file of *any
    stable release* version with the given change. In other words,
    news about a bug fix which went into PHP-5.4, PHP-5.5 and master
    should be noted in both PHP-5.4/NEWS and PHP-5.5/NEWS but
    not master, which is not a public released version yet.

    PS: I post that for other people that had not time to notice this
    discussion and I will most probably give a week or so for others to
    speek up before changing any settled rules. Could well be there are
    people who do not want to write two NEWS entries :)
    Doing it like this seems more cumbersome. Currently merges use an "ours"
    merge driver for NEWS etc, so NEWS changes are not merged upwards. You'd
    have to manually copy them in. I think it's okay like it is right now,
    assuming that the RMs copy the items from the 5.4 changelog into the one
    for 5.5 when releasing (which iirc they do).

    Nikita
  • Michael Wallner at Oct 16, 2013 at 12:43 pm ⇧

    On Wed, 16 Oct 2013 14:26:28 +0200, Nikita Popov wrote:

    Doing it like this seems more cumbersome. Currently merges use an "ours"
    merge driver for NEWS etc, so NEWS changes are not merged upwards. You'd
    They are not automatically mergable, no.
    have to manually copy them in. I think it's okay like it is right now,
    assuming that the RMs copy the items from the 5.4 changelog into the one
    for 5.5 when releasing (which iirc they do).
    Well, fact is, they don't. Besides, it's even way easier to add a NEWS
    entry oneself than for the RM fiddling around with that (from
    a branch he/she probably isn't even RM).

    --
    Regards,
    Mike
  • Johannes Schlüter at Oct 16, 2013 at 1:23 pm ⇧

    On Wed, 2013-10-16 at 08:43 -0400, Michael Wallner wrote:
    On Wed, 16 Oct 2013 14:26:28 +0200, Nikita Popov wrote:

    Doing it like this seems more cumbersome. Currently merges use an "ours"
    merge driver for NEWS etc, so NEWS changes are not merged upwards. You'd
    They are not automatically mergable, no.
    have to manually copy them in. I think it's okay like it is right now,
    assuming that the RMs copy the items from the 5.4 changelog into the one
    for 5.5 when releasing (which iirc they do).
    Well, fact is, they don't. Besides, it's even way easier to add a NEWS
    entry oneself than for the RM fiddling around with that (from
    a branch he/she probably isn't even RM).
    It's also requires quite some review - not all changes on lower branches
    go to higher. For instance for removed features.

    The developer should know where they push.

    Ideal would be a tool where an RM can invoke a script which parses
    commit messages and builds NEWS from there. This requires some stricter
    rules on commit message formats, though. (the idea is as old as the git
    migration but there wasn't a good idea, yet)

    johannes
  • Pierre Joye at Oct 16, 2013 at 4:02 pm ⇧

    On Wed, Oct 16, 2013 at 3:23 PM, Johannes Schlüter wrote:

    Ideal would be a tool where an RM can invoke a script which parses
    commit messages and builds NEWS from there. This requires some stricter
    rules on commit message formats, though. (the idea is as old as the git
    migration but there wasn't a good idea, yet)
    Yes, that's the idea behind the new commit message format:

    https://wiki.php.net/vcs/gitworkflow#new_commit_message_format

    But somehow even harder to enforce.

    Cheers,
    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Nikita Popov at Oct 16, 2013 at 4:08 pm ⇧

    On Wed, Oct 16, 2013 at 6:02 PM, Pierre Joye wrote:

    On Wed, Oct 16, 2013 at 3:23 PM, Johannes Schlüter
    wrote:
    Ideal would be a tool where an RM can invoke a script which parses
    commit messages and builds NEWS from there. This requires some stricter
    rules on commit message formats, though. (the idea is as old as the git
    migration but there wasn't a good idea, yet)
    Yes, that's the idea behind the new commit message format:

    https://wiki.php.net/vcs/gitworkflow#new_commit_message_format

    But somehow even harder to enforce.
    I think it's pretty hard to get this information from the commit messages
    (not all commits are NEWSworthy, some changes have multiple commits). Maybe
    it's better to integrate this with bugs.php.net? After all NEWS only has
    changes with assigned bug IDs (minus rather rare exceptions), so that seems
    like a good place to do it. I.e. don't just "Closed" the bugs, but make
    them "Fixed in PHP 5.4.20, PHP 5.5.5" or something.

    Just a thought, not sure if it makes sense.
    Nikita
  • Johannes Schlüter at Oct 16, 2013 at 4:18 pm ⇧

    On Wed, 2013-10-16 at 18:08 +0200, Nikita Popov wrote:


    I think it's pretty hard to get this information from the commit
    messages (not all commits are NEWSworthy, some changes have multiple
    commits). Maybe it's better to integrate this with bugs.php.net? After
    all NEWS only has changes with assigned bug IDs (minus rather rare
    exceptions), so that seems like a good place to do it. I.e. don't just
    "Closed" the bugs, but make them "Fixed in PHP 5.4.20, PHP 5.5.5" or
    something.
    It's not completely rare - there are feature additions which aren't
    traced in the bug tracker. We might make that a stronger requirement,
    though. But mind that only the tree (currently) has the primary
    knowledge about where it was merged in (also mind release branches) and
    kicked out again.

    johannes
  • Johannes Schlüter at Oct 16, 2013 at 4:15 pm ⇧

    On Wed, 2013-10-16 at 18:02 +0200, Pierre Joye wrote:
    On Wed, Oct 16, 2013 at 3:23 PM, Johannes Schlüter
    wrote:
    Ideal would be a tool where an RM can invoke a script which parses
    commit messages and builds NEWS from there. This requires some stricter
    rules on commit message formats, though. (the idea is as old as the git
    migration but there wasn't a good idea, yet)
    Yes, that's the idea behind the new commit message format:

    https://wiki.php.net/vcs/gitworkflow#new_commit_message_format

    But somehow even harder to enforce.
    That format is not enough for that purpose. It is i.e. missing a
    specification for the NEWS categories ("Core" or extension name etc.) I
    believe if we have a good(!) format for that RMs can hit developers not
    following it so they remember.

    Requirement from top of my head for a good format:
      - Easy to remember and type (developers are lazy, the more complicated
        the harder it is to get "proper" pull requests etc.)
      - Easy to parse
      - Provides category
      - provides a way to mark null-merges (i.e. 5.4-only fix merged up)
      - additional authors (primary author should be in commit itself)

    Anybody is welcome to pickup this challenge and define a format and
    writing a NEWS-file generator based on it (... and html changelog
    generator and release announcement generator and ...) :)

    johannes

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedOct 15, '13 at 12:54p
activeOct 16, '13 at 4:18p
posts8
users4
websitephp.net

4 users in discussion

Johannes Schlüter: 3 posts Nikita Popov: 2 posts Michael Wallner: 2 posts Pierre Joye: 1 post

Content

People

Support

Translate

site design / logo © 2022 Grokbase