Hi,
after the 5.3.3 release I was approached with the request to restructure
the NEWS file -- for instance by grouping entries by extension -- so
users can identify whether there are bug fixes relevant for them etc.
The list itself is rather long. Anybody opinions on this? Anybody who
wants to play with it to come up with a nice layout which is compact
while still helping these people? Maybe it is enough to do this only
online on the release web page?
Thanks,
johannes
19.11.2010 0:39, Johannes Schlüter kirjoitti:
Hi,
after the 5.3.3 release I was approached with the request to restructure
the NEWS file -- for instance by grouping entries by extension -- so
users can identify whether there are bug fixes relevant for them etc.
Something that I did in trunk NEWS perhaps? I'd like a better formatted
NEWS though. And get rid of those ancient Changelog* files as well. :)
Ideas / examples of better format accepted, I can always implement it if
time permits. It would also help if we can forget that 80 chars per line
limit as well. It's 2k already and people do have bigger terminals
nowadays.
--Jani
2010/11/19 Jani Taskinen jani.taskinen@iki.fi:
19.11.2010 0:39, Johannes Schlüter kirjoitti:
Hi,
after the 5.3.3 release I was approached with the request to restructure
the NEWS file -- for instance by grouping entries by extension -- sousers can identify whether there are bug fixes relevant for them etc.
Something that I did in trunk NEWS perhaps? I'd like a better formatted NEWS
though. And get rid of those ancient Changelog* files as well. :)Ideas / examples of better format accepted, I can always implement it if
time permits. It would also help if we can forget that 80 chars per line
limit as well. It's 2k already and people do have bigger terminals nowadays.
+1 on the 80 chars per line limit. I hope no one is still using a
"everyday" serial terminal :)
--Jani
2010/11/19 Jani Taskinen jani.taskinen@iki.fi:
19.11.2010 0:39, Johannes Schlüter kirjoitti:
after the 5.3.3 release I was approached with the request to
restructure
the NEWS file -- for instance by grouping entries by extension -- sousers can identify whether there are bug fixes relevant for them etc.
Something that I did in trunk NEWS perhaps? I'd like a better formatted
NEWS
though. And get rid of those ancient Changelog* files as well. :)Ideas / examples of better format accepted, I can always implement it if
time permits. It would also help if we can forget that 80 chars per line
limit as well. It's 2k already and people do have bigger terminals
nowadays.+1 on the 80 chars per line limit. I hope no one is still using a
"everyday" serial terminal :)
I'm not using a serial terminal, but I usually use a font so big that the
window only has 80-110 columns. I'm sure I'm not alone.
--
Gustavo Lopes
19.11.2010 0:39, Johannes Schlüter kirjoitti:
Hi,
after the 5.3.3 release I was approached with the request to restructure
the NEWS file -- for instance by grouping entries by extension -- so
users can identify whether there are bug fixes relevant for them etc.Something that I did in trunk NEWS perhaps? I'd like a better formatted
NEWS though.
I didn't see that change but yeah something like that. Aybody volunteers
to go through the 5.3 NEWS? :-)
And get rid of those ancient Changelog* files as well. :)
I proposed this in the past. Some people complained. Nobody fixed it (it
is not being updated since the switch to svn, before that only cvs HEAD
was updated, no branches...) and I didn't see anybody complaining this
tells me nobody really needs them. Using svn history features is more
effective anyways ...
Ideas / examples of better format accepted, I can always implement it if
time permits. It would also help if we can forget that 80 chars per line
limit as well. It's 2k already and people do have bigger terminals
nowadays.
I like having multiple 80 chars terminals next to each other :-)
But I think most editors can wrap or cut it off as one prefers. We
should avoid 300 char lines though.
johannes
And get rid of those ancient Changelog* files as well. :)
I proposed this in the past.
See internals@lists.php.net/msg46669.html" rel="nofollow" target="_blank">http://www.mail-archive.com/internals@lists.php.net/msg46669.html
If nobody creates a process for updating these files I will drop the
ChangeLog* files before packaging 5.3.4RC2 in two weeks. The current
state is useless.
johannes
And get rid of those ancient Changelog* files as well. :)
I proposed this in the past.
See internals@lists.php.net/msg46669.html" rel="nofollow" target="_blank">http://www.mail-archive.com/internals@lists.php.net/msg46669.html
If nobody creates a process for updating these files I will drop the
ChangeLog* files before packaging 5.3.4RC2 in two weeks. The current
state is useless.
Do it also in trunk.. :)
--Jani
Hi,
2010/11/19 Johannes Schlüter johannes@schlueters.de
19.11.2010 0:39, Johannes Schlüter kirjoitti:
Hi,
after the 5.3.3 release I was approached with the request to
restructure
the NEWS file -- for instance by grouping entries by extension -- so
users can identify whether there are bug fixes relevant for them etc.Something that I did in trunk NEWS perhaps? I'd like a better formatted
NEWS though.I didn't see that change but yeah something like that. Aybody volunteers
to go through the 5.3 NEWS? :-)
I groupped the the 5.3.4RC1 entries: http://dpaste.com/277482/plain/
Is it okay to commit? :)
--
Regards,
Felipe Pena
I groupped the the 5.3.4RC1 entries: http://dpaste.com/277482/plain/
Is it okay to commit? :)
Wouldn't it be better to group PHP-FPM changes in a single block rather than
two separate for additions and fixes?
/Simas
It would also help if we can forget that 80 chars per line limit as
well. It's 2k already and people do have bigger terminals nowadays.
No please, don't change that. Even though some screens are larger, the
defacto screen size when you login somewhere is 80x24. I hardly change
the size, but instead have 4 open that show at the same time.
regards,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug