Great! I'll see if I can run this on a few more and see how it fares.
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> There is a point when there are enough changes (or it's sufficiently
> unclear
On 01/12/18 4:36 AM, Alfred M. Szmidt wrote:
Emacs:
~/emacs/src $ python3 ~/gen-changed-entities.py
f1ea2b9e6b63593f5919f60a68a9e19026756ac4
0e484c66fd63877230c3dfa97f2ce9dda71ad88b
[...]
[_REGEX_RE_COMP ||
_LIBC][_LIBC][_LIBC][RE_ENABLE_I18N][RE_ENABLE_I18N][RE_ENABLE_I18N][!
_LIBC]
On 12/4/18 7:33 PM, Richard Stallman wrote:
> Please accept my decision: the GNU Project welcomes the use of git,
> but also respects contributors that don't want to use git.
I accept that decision, it is a good position overall.
--
Cheers,
Carlos.
On Wed, 5 Dec 2018, Richard Stallman wrote:
> More precisely, how far we can _reduce_ what we require a user to know,
> to do those things?
For example, we have the rules on comments that mean in many cases the
required information should be in a comment and it shouldn't be necessary
to refer t
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> The last time I checked (some years ago) there was an attempt to use git
> in
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> > Git still isn't a requirement to be able to contribute to glibc or the
> > re
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> I think some version control system is crucial for large-scale software
> deve
On Tue, 4 Dec 2018, Richard Stallman wrote:
> It is no great problem for a human looking at ONE diff. But when it comes
> to trying to look thru many diffs to find what changed a given entity,
> it is a total screw.
There is a point when there are enough changes (or it's sufficiently
unclear wh
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> In these discussions, we have been discussing two problems that are
> inverses
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> > If there is no way to name these entities, then what do hand-written
> > GCC
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> Alfred wrote "We don't require git for anything in the GNU project",
> and the
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
I very much appreciate your work on this script.
--
Dr Richard Stallman
President,
On Tue, 4 Dec 2018, Siddhesh Poyarekar wrote:
> The last time I checked (some years ago) there was an attempt to use git in
> bash but with patch blobs going into the git tree with little or no
> information in the git log.
That was what I had in mind when I wrote point 3 on my list of criteria
> Chet has maintained Bash for a very long time successfully, the setup
> works for him. As such, it cannot be the bottom worst but rather the
> opposite. In some ways I can think that maybe even the lack of VCS
> might be a good thing here.
I started writing a long ran
On 04/12/18 1:20 AM, Alfred M. Szmidt wrote:
Chet has maintained Bash for a very long time successfully, the setup
works for him. As such, it cannot be the bottom worst but rather the
opposite. In some ways I can think that maybe even the lack of VCS
might be a good thing here.
I started writ
> anything. E.g. GNU bash isn't even using VCS to this date (AFAIK)...
FWIW, bash is a well known example of key software that's maintained in
the worst possible way, with emails for bug reporting and tracking and
some manual labour that depends on one person for release management.
On 03/12/18 11:34 PM, Alfred M. Szmidt wrote:
anything. E.g. GNU bash isn't even using VCS to this date (AFAIK)...
FWIW, bash is a well known example of key software that's maintained in
the worst possible way, with emails for bug reporting and tracking and
some manual labour that depends o
On Mon, 3 Dec 2018, Alfred M. Szmidt wrote:
>I think that we should respect the experience of non-GNU free software
>developers managing very large non-GNU projects (e.g. the Linux kernel)
>with the above tools, but not using ChangeLog format, as a proof by
>example that ChangeL
On Mon, 3 Dec 2018, Alfred M. Szmidt wrote:
> Git still isn't a requirement to be able to contribute to glibc or the
> rest of the GNU project, you can pull the e.g. tarball, make a patch,
> and send it to libc-alpha. The change might be applicable to master,
> it might not, but that is the same
Alfred wrote "We don't require git for anything in the GNU project",
and the obvious proof by contradiction is that we do require it for
glibc development work on master. The answer "Tarball?" is not a
supportable one because you're quickly so far away from master that
you can't gen
Thank you!
On Sat, 1 Dec 2018, Richard Stallman wrote:
> > You need to know some C to contribute to a package written in C.
> > Similarly, I think it's reasonable to expect knowledge of some git to
> > explore the history of a package using git.
>
> Those two issues look similar
On 12/3/18 1:48 AM, Siddhesh Poyarekar wrote:
> I suppose I also need to push the patch up to atleast a private
> branch in glibc so that people can check out and play with the latest
> version with fixes. I'll do that tonight.
Thank you! That would be great.
--
Cheers,
Carlos.
On Sun, 2 Dec 2018, Richard Stallman wrote:
> What matters here is that that method doesn't give reliable data for
> the job we need to do.
The job ultimately is a *subjective and contextual* one. It's not "what
entities changed in this commit?", it's not even "what commits changed
this entity
On Sat, 1 Dec 2018, Richard Stallman wrote:
> > You need to know some C to contribute to a package written in C.
> > Similarly, I think it's reasonable to expect knowledge of some git to
> > explore the history of a package using git.
>
> Those two issues look similar at a superficial gl
On 01/12/18 4:36 AM, Alfred M. Szmidt wrote:
Tried playing with this just a bit, and please don't get the wrong
idea with all the "it doesn't work complaints". I think this is an
amazing attempt at automating ChangeLogs.
Thanks, I'm looking for "it doesn't work" kind of feedback because that
On 12/1/18 6:42 PM, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider]]]
> [[[ whether defending the US Constitution against all enemies, ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> > > We don't require git f
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> I htink that the hack made by Siddhesh is a good compromise, it gets
> us to th
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> I think it is a misrepresentation to say that they "fail".
They fail in the sens
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> But I'm a bit confundled, I tried this on one change in the glibc tree
> (see b
On Sat, Dec 01, 2018 at 06:42:18PM -0500, Richard Stallman wrote:
In any case, remember that the problem with git is that its commands
to study the history predictably fail in certain cases.
The program I want people to write would work around that failure.
I think it is
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> You need to know some C to contribute to a package written in C.
> Similarly,
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> > We don't require git for anything in the GNU project, let alone being
>
Actually, commit
aca7a3d201 ("Merge ChangeLog.unicode files into ChangeLogs")
changed the date of that ChangeLog entry from 2007-10-26 to 2008-02-02
while moving the content, for some reason. The info that git blame gave
you is accurate.
Thank you for correcting me! And what
Tried playing with this just a bit, and please don't get the wrong
idea with all the "it doesn't work complaints". I think this is an
amazing attempt at automating ChangeLogs.
But I'm a bit confundled, I tried this on one change in the glibc tree
(see below). While it is true that _itoa.h was in
On 2018-11-30 17:58, Simon Marchi wrote:
On 2018-11-30 16:08, Alfred M. Szmidt wrote:
I think this is not really what one (or at least, I) is after. Here
is one typical excursion, picking a random file and function in Emacs:
pr-menu-set-txt-title in lisp/printing.el.
I was unable to follow the
On 2018-11-30 16:08, Alfred M. Szmidt wrote:
I think this is not really what one (or at least, I) is after. Here
is one typical excursion, picking a random file and function in Emacs:
pr-menu-set-txt-title in lisp/printing.el.
I was unable to follow the history of pr-menu-set-txt-title using gi
On Fri, 30 Nov 2018, Alfred M. Szmidt wrote:
>I think it's a feature for git blame not to show changes when a function
>was moved without its contents being changed, not a bug.
>
> I certainly do not, it can mean the difference between working code
> and non-working code, and it can chan
>It is not an unreasonable expectation to expect experience with git.
>
> We don't require git for anything in the GNU project, let alone being
> able to use it to contribute a change. You can get away happily
> without learning any git commands and still be able to contribute
> We don't require git for anything in the GNU project, let alone being
> able to use it to contribute a change. You can get away happily
> without learning any git commands and still be able to contribute to
> the GNU project. Just like being fluent in English is not an
> requirem
On Fri, 30 Nov 2018, Alfred M. Szmidt wrote:
> I was unable to follow the history of pr-menu-set-txt-title using git
> log, git blame, or any other such command. Infact, I get the wrong
> information from git blame, mainly because of things getting wrapped
> with a eval-when:
On Fri, 30 Nov 2018, Alfred M. Szmidt wrote:
> I was unable to follow the history of pr-menu-set-txt-title using git
> log, git blame, or any other such command. Infact, I get the wrong
> information from git blame, mainly because of things getting wrapped
> with a eval-when:
>
> ebe4c71027c (Vi
On 11/30/18 4:08 PM, Alfred M. Szmidt wrote:
> We don't require git for anything in the GNU project, let alone being
> able to use it to contribute a change. You can get away happily
> without learning any git commands and still be able to contribute to
> the GNU project. Just like being fluent i
On Fri, 30 Nov 2018, Alfred M. Szmidt wrote:
>It is not an unreasonable expectation to expect experience with git.
>
> We don't require git for anything in the GNU project, let alone being
> able to use it to contribute a change. You can get away happily
> without learning any git commands a
On 11/30/18 8:42 AM, Joseph Myers wrote:
> If someone changes something in glibc and find the result fails to build
> or fails to pass the glibc testsuite, they then need to debug the problem.
> Debugging a problem like that is much more complicated, and much less
> susceptible to having a sing
On Fri, 2018-11-30 at 13:57 -0500, Alfred M. Szmidt wrote:
> I don't see how "git blame" (which is useful, and available via
> vc-mode) replaces what what a ChangeLog style format provides, it
> won't tell me anything about how functions have moved, been renamed,
> etc. You'll nee
> If someone changes something in glibc and find the result fails
> to build or fails to pass the glibc testsuite, they then need to
> debug the problem. Debugging a problem like that is much more
> complicated, and much less susceptible to having a single set of
> instructions to f
On Fri, 30 Nov 2018, Alfred M. Szmidt wrote:
> I don't see how "git blame" (which is useful, and available via
> vc-mode) replaces what what a ChangeLog style format provides, it
In these discussions, we have been discussing two problems that are
inverses of each other.
(1) Mapping from a commi
On Fri, 2018-11-30 at 13:57 -0500, Alfred M. Szmidt wrote:
> I don't see how "git blame" (which is useful, and available via
> vc-mode) replaces what what a ChangeLog style format provides, it
> won't tell me anything about how functions have moved, been renamed,
> etc. You'll need go back and for
> harder by requiring a complicated, hard to understand tool like git to
> just be able to poke around in history.
As with other things, people become more familiar with it over time.
I dunno, I've used git since just about when it was created. I still
struggle with it, and still figh
On Fri, 30 Nov 2018, Alfred M. Szmidt wrote:
> I disagree on that, you don't have to have any familiarity with that
> at all to make useful contributions to glibc, nor should we make it
If you're trying to add a new (public) function - which is quite a common
thing for new contributors to try to
People need to use a range of tools to find their way around a source tree
with tens of thousands of files and work out which ones are relevant to
edit to address their issue. For many things in glibc, people need to be
familiar with many advanced GNU make features, with properties
On Fri, 30 Nov 2018, Alfred M. Szmidt wrote:
>On Fri, 30 Nov 2018, Richard Stallman wrote:
>
>> We have already established that "git blame" and "git log -L" fail to
>> do this job reliably.
>
>No, we haven't established that. We've established that the names in
>*diff hunk
On Fri, 30 Nov 2018, Richard Stallman wrote:
> We have already established that "git blame" and "git log -L" fail to
> do this job reliably.
No, we haven't established that. We've established that the names in
*diff hunk headers* from "git diff" or "git show" aren't sufficientl
On Fri, 30 Nov 2018, Richard Stallman wrote:
> We have already established that "git blame" and "git log -L" fail to
> do this job reliably.
No, we haven't established that. We've established that the names in
*diff hunk headers* from "git diff" or "git show" aren't sufficiently
reliable - whi
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> And so tools such as "git blame" and "git log -L", where
> you examine the c
On Thu, 29 Nov 2018, Richard Stallman wrote:
> The issue that remains is that it is sometimes necessary to find which
> commits changed some specific entity in the code. The current format
> of change logging gives a way to do that. The issue is how to arrange
> to do that if we no longer itemiz
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> I think you're arguing about a non-issue.
> Remember what this featur
On Tue, Nov 27, 2018 at 05:57:38PM -0500, Richard Stallman wrote:
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
On Tue, 27 Nov 2018, Richard Stallman wrote:
> > Furthermore, you have unnamed entities - for example, in GCC machine
> > descriptions, unnamed define_split constructs.
>
> If there is no way to name these entities, then what do hand-written
> GCC change log entries say about them? Can the
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> And when the actual change is a rearrangement of the contents of the file,
> o
On Mon, 26 Nov 2018, Richard Stallman wrote:
> > I think "in all cases" is not realistic; there are cases of structural
> > changes where any description in terms of named entities will be a mess,
>
> I doubt that. Whatever the changes were, it is possible to list
> the entities that were
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> > If it is acceptable to them _and_ it gives correct output in all cases
> > th
On Sat, 24 Nov 2018, Richard Stallman wrote:
> If it is acceptable to them _and_ it gives correct output in all cases
> that can appear in glibc, then I say yes.
I think "in all cases" is not realistic; there are cases of structural
changes where any description in terms of named entities will b
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> Thanks, should I take this as approval for glibc on the condition that
> it's
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> We also need some sort of update to the standards - possibly based on Paul
> E
On 23/11/18 4:48 AM, Richard Stallman wrote:
It looks like you're making good progress.
Thanks, should I take this as approval for glibc on the condition that
it's acceptable to the glibc community? We still have a couple of
months and the standards could be amended by then, alongside the s
On 22/11/18 10:33 PM, Joseph Myers wrote:
We also need some sort of update to the standards - possibly based on Paul
Eggert's patches - to discuss the case where entity-level descriptions of
changes are not maintained but there is some kind of automation to
identify the changed entities, which is
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
It looks like you're making good progress.
--
Dr Richard Stallman
President, Free S
On Thu, 22 Nov 2018, Siddhesh Poyarekar wrote:
> If you think this is a good start, I'd like to install this in glibc so that
> we don't have to maintain a ChangeLog file after the 2.29 release in February.
We also need some sort of update to the standards - possibly based on Paul
Eggert's patch
On 22/11/18 5:56 AM, Richard Stallman wrote:
That is very sophisticated, and perhaps that means it will not be
fooled by simple things that fool the git commands for finding
differences.
However, it might get totally messed up by macros that syntactically
don't parse like valid code. Have you t
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
I am glad to see someone is working on this.
> There is a general consensus among
On 21/11/18 7:36 PM, Jose E. Marchesi wrote:
I get this error;
dc4f75757320d8d82cd4f4be29b156ca1e790479: Unknown line format T
when processing the commit:
jemarch@termi:~/gnu/hacks/poke$ git show --date=short --raw
dc4f75757320d8d82cd4f4be29b156ca1e790479
commit dc4f75757320d8d82cd4f4be29b156
On Wed, 21 Nov 2018, Per Bothner wrote:
> text from commit-messages. A list of functions that were removed,
> added, or modified has limited use - what does it get you that
> 'git diff' doesn't? It's slightly more convenient, that's all.
I'd be fine without having a way to generate that list, b
On 11/21/18 4:10 AM, Siddhesh Poyarekar wrote:
There is a general consensus among the glibc community to stop maintaining a
ChangeLog file and we were told that the requirement for doing that was to have
a script that provided a representation of the git log that looks similar to a
ChangeLog.
Hey Siddhesh!
There is a general consensus among the glibc community to stop
maintaining a ChangeLog file and we were told that the requirement for
doing that was to have a script that provided a representation of the
git log that looks similar to a ChangeLog.
I have
77 matches
Mail list logo
