Hi everyone,
This morning, I have inadvertently updated gnustep-base on my Debian
machine, which remained at version 1.19 since april this year
To my surprise, I have found at least two unannounced changes:
- the property list format is now serialized directly in XML, which is
somehow use
Hi,
This morning, I have inadvertently updated gnustep-base on my Debian
machine, which remained at version 1.19 since april this year
To my surprise, I have found at least two unannounced changes:
- the property list format is now serialized directly in XML, which is
somehow useful
On 25 Nov 2009, at 20:21, Wolfgang Sourdeau wrote:
> Hi everyone,
>
>
> This morning, I have inadvertently updated gnustep-base on my Debian machine,
> which remained at version 1.19 since april this year
> To my surprise, I have found at least two unannounced changes:
> - the property lis
On 25 Nov 2009, at 22:39, Richard Frith-Macdonald wrote:
>
> On 25 Nov 2009, at 20:21, Wolfgang Sourdeau wrote:
>
>> Hi everyone,
>>
>>
>> This morning, I have inadvertently updated gnustep-base on my Debian
>> machine, which remained at version 1.19 since april this year
>> To my surpri
Hi,
Hi everyone,
This morning, I have inadvertently updated gnustep-base on my Debian machine,
which remained at version 1.19 since april this year
To my surprise, I have found at least two unannounced changes:
- the property list format is now serialized directly in XML, which is someh
On 25 Nov 2009, at 22:39, Richard Frith-Macdonald wrote:
There are actually three levels of change information ...
NEWS ... just the headlines
ReleaseNotes ... some more detail
ChangeLog ... everything
Maybe you are right and we shouldn't bother with NEWS? I'd be
interested to know what oth
I'd be in favour of ditching NEWS and ChangeLog.
ChangeLog has less information, in a less useful format, than the
svn logs and is a hold-over from CVS not storing repository-wide
change information sensibly. With svn log, you can get a log of
change messages at any granularity that you li
On 26 Nov 2009, at 00:50, Nicola Pero wrote:
I'd be in favour of ditching NEWS and ChangeLog.
ChangeLog has less information, in a less useful format, than the
svn logs and is a hold-over from CVS not storing repository-wide
change information sensibly. With svn log, you can get a log of
I still haven't seen a convincing argument for it. Any of the information
that people write in the ChangeLog file they could also write in the commit
log. It is impossible to make a commit without writing a log message, it is
easy to make a commit without editing the ChangeLog (you could add
On 25 Nov 2009, at 23:23, Riccardo Mottola wrote:
> Hi,
>>
>>> Hi everyone,
>>>
>>>
>>> This morning, I have inadvertently updated gnustep-base on my Debian
>>> machine, which remained at version 1.19 since april this year
>>> To my surprise, I have found at least two unannounced changes
On 26 Nov 2009, at 01:10, David Chisnall wrote:
> On 26 Nov 2009, at 00:50, Nicola Pero wrote:
>
>>> I'd be in favour of ditching NEWS and ChangeLog.
>>>
>>> ChangeLog has less information, in a less useful format, than the svn logs
>>> and is a hold-over from CVS not storing repository-wide c
ChangeLog has less information, in a less useful format, than the
svn logs and is a hold-over from CVS not storing repository-wide
change information sensibly. With svn log, you can get a log of
change messages at any granularity that you like.
I agree there is an overlap, but there are
It would be good to consider exactly how much (if any) information
we want to present in NEWS/ReleaseNotes ... my preference would be
for minimal information there, and a pointer to a generated
ChangeLog for details.
This would require a policy that svn log entries should be suitable
f
So I guess the solution to that would be instead to require
ChangeLog entries to be committed to svn log.
By the way, presumably we'd still include the author of the change in
the subversion commit message ?
Ie, we write a full ChangeLog entry including the author at the
beginning ?
The r
On 26 Nov 2009, at 11:03, Nicola Pero wrote:
>
>> It would be good to consider exactly how much (if any) information we want
>> to present in NEWS/ReleaseNotes ... my preference would be for minimal
>> information there, and a pointer to a generated ChangeLog for details.
>> This would requir
On 26 Nov 2009, at 11:08, Nicola Pero wrote:
>> So I guess the solution to that would be instead to require ChangeLog
>> entries to be committed to svn log.
>
> By the way, presumably we'd still include the author of the change in the
> subversion commit message ?
> Ie, we write a full ChangeL
On 26 Nov 2009, at 11:08, Nicola Pero wrote:
By the way, presumably we'd still include the author of the change
in the subversion commit message ?
Ie, we write a full ChangeLog entry including the author at the
beginning ?
Yes. If you look in the LLVM svn log, for example, you will see a f
It's not a strict requirement.
On Wednesday, November 25, 2009, wrote:
>
>
>
> I still haven't seen a convincing argument for it. Any of the information
> that people write in the ChangeLog file they could also write in the commit
> log. It is impossible to make a commit without writing a log
On Thu, Nov 26, 2009, Nicola Pero wrote:
> I also occasionally work on gnustep-make offline, and the subversion
> logs are not available offline, while ChangeLogs are.
Dare I say it, but the obvious answer to that is a DVCS,
of which hg and git spring to mind.
On Thu, Nov 26, 2009 at 11:08:01AM
David Chisnall wrote:
On 25 Nov 2009, at 22:39, Richard Frith-Macdonald wrote:
There are actually three levels of change information ...
NEWS ... just the headlines
ReleaseNotes ... some more detail
ChangeLog ... everything
Maybe you are right and we shouldn't bother with NEWS? I'd be
inter
Hi,
I agree with Nicola here ... it's very, very far from being a waste of space
... people do need to be able to see the changes made to the code.
So your suggestion of having a script make a ChangeLog automatically from the
svn logs makes a *lot* of sense.
WasteOfSpace? I think that is
On Thu, Nov 26, 2009 at 10:15 PM, Riccardo Mottola wrote:
> David Chisnall wrote:
>>
>> On 25 Nov 2009, at 22:39, Richard Frith-Macdonald wrote:
>>
>>> There are actually three levels of change information ...
>>> NEWS ... just the headlines
>>> ReleaseNotes ... some more detail
>>> ChangeLog ...
Hi,
By the way, presumably we'd still include the author of the change in
the subversion commit message ?
Ie, we write a full ChangeLog entry including the author at the
beginning ?
The reason is that when we receive patches, the committer is often
*not* the author of the patch, only the revi
On 26 Nov 2009, at 22:15, Riccardo Mottola wrote:
Not only in a ChangeLog I can write more than in a commit and I can
group files and comment on sigle pieces of them, but it is an easy
file I can check.
Are you using a different svn to me? When I do a commit, it pops up
$EDITOR (vim in
Also, A ChangeLog is easy to search. When something breaks I grep
in the changelog. Old habits.
Why is:
cat ChangeLog | grep
easier than:
svn log | grep
Because using a ChangeLog doesn't require internet access, and it is
*much* faster. :-)
And for people who get a source tarball, they
I know that I am rather late to jump into this discussion, but I was
away for a few weeks and only read through it now.
I strongly agree with Nicola's points here. I don't just write but also
read the ChangeLog a lot. Before every substantial change I try to find
the ChangeLog entry for the origin
Richard Frith-Macdonald wrote:
I think directly ~/GNUstep/Defaults/.GNUstepDefaults ?
That's XML for me now and it wasn't.
Oh, that's a hidden file for private use by the base library ...
kind of surprising that anyone would notice, and certainly not
something which should appear in news/r
On 26 Nov 2009, at 17:35, Wolfgang Lux wrote:
> Richard Frith-Macdonald wrote:
>
>>> I think directly ~/GNUstep/Defaults/.GNUstepDefaults ?
>>> That's XML for me now and it wasn't.
>>
>> Oh, that's a hidden file for private use by the base library ... kind of
>> surprising that anyone would no
On 27 Nov 2009, at 08:39, Richard Frith-Macdonald wrote:
The question is, do we want to write illegal XML in property lists?
At the moment the code can write legal XML or illegal (OSX
compatible) XML depending on the OSX compatibility defaults
setting. If we assume that 'XML' property lis
Am 27.11.2009 um 09:39 schrieb Richard Frith-Macdonald:
On 26 Nov 2009, at 17:35, Wolfgang Lux wrote:
Richard Frith-Macdonald wrote:
I think directly ~/GNUstep/Defaults/.GNUstepDefaults ?
That's XML for me now and it wasn't.
Oh, that's a hidden file for private use by the base library ..
On 27 Nov 2009, at 18:28, Lars Sonchocky-Helldorf wrote:
>
> Am 27.11.2009 um 09:39 schrieb Richard Frith-Macdonald:
>
>>
>> On 26 Nov 2009, at 17:35, Wolfgang Lux wrote:
>>
>>> Richard Frith-Macdonald wrote:
>>>
> I think directly ~/GNUstep/Defaults/.GNUstepDefaults ?
> That's XML f
Am 27.11.2009 um 20:36 schrieb Richard Frith-Macdonald:
On 27 Nov 2009, at 18:28, Lars Sonchocky-Helldorf wrote:
Am 27.11.2009 um 09:39 schrieb Richard Frith-Macdonald:
On 26 Nov 2009, at 17:35, Wolfgang Lux wrote:
Richard Frith-Macdonald wrote:
I think directly ~/GNUstep/Defaults/.G
On 27 Nov 2009, at 20:05, Lars Sonchocky-Helldorf wrote:
>
> Maybe we should file a bug with OS X on that by explaining them that they're
> writing invalid XML 1.0.
I did that some years ago. Possibly they fixed it.
> A fix would be simple for Apple, I think there's nothing to stop them from
33 matches
Mail list logo
