Re: The General Public Licence (GPL) as the basic governance tool
> From: Ludovic Courtès > Cc: Mark Wielaard , gnu-misc-discuss@gnu.org > Date: Sat, 22 Feb 2020 22:04:36 +0100 > > > I always thought that maintaining a GNU project according to the > > guidelines I was communicated when I was appointed _is_ upholding GNU > > values, that it's all there is in upholding them, as applied to my job > > as the maintainer. But you seem to be saying there's something else > > there? What is that? > > Quoth RMS¹: > > GNU package maintainers have committed to do work to maintain and add > to the GNU system, but not anything beyond that. We have never > pressed contributors to endorse the GNU Project philosophy, or any > other philosophical views, because people are welcome to contribute to > GNU regardless of their views. That's just the tip of a very large iceberg. I know it, you know it, and every GNU maintainer knows it. When we get appointed, we receive a 1000-word message from RMS with some quite non-trivial instructions, including, but not limited to, a pointer to maintain.texi as the place to find specific policies and guidelines that are mandatory to follow. That is what I alluded to when I said "maintaining a GNU project according to the guidelines". I don't know how things are on your plate, but for me following those guidelines takes most of my free time, and requires some non-trivial efforts. > The GNU Social Contract is about changing that. How can you change that if the document is voluntary? That's exactly the essence of my questions, and I don't see any answers in what you wrote. > > The fact is that those same people who wrote the document > > The document was drafted on this list, with a call for an additional > feedback period. You could have been one of those people, and you can > become one for a future version. The goal has always been to have as > many maintainers as possible on board. > > > and promote it are those who are promoting the ideas of changing the > > leadership and the governance model. You cannot work around of that. > > It is IMO better to present these issues honestly and a objectively as > > possible than to try to sweep them under the carpet. It might make > > the discussions more open and the sides more trustworthy towards one > > another. > > That some of us want to change the governance of GNU is not a mystery. > Our first message to maintainers¹ and the endorsement page² read: > > Additionally, we think it can be a first step towards formalizing a > transparent and collective governance of the GNU Project. I think you are missing the point. You are asking people to endorse a document, but it's unclear whether the document is a goal in itself or a step in some direction, and if the latter, then what exactly is that direction. "We think it can be a first step" doesn't cut it: is it the first step or isn't it? If it is, then I at least would like to know where you are aiming, and I'd like to see it written clearly and unequivocally on your site, including any controversy that might exist about those goals (so people could consider them and make up their minds). You see, I'm somewhat picky in choosing documents which I sign, and would like to understand better what kind of movement I'm joining by doing so. I expect that at least some of us here think the same. Moreover, being involved in a campaign to diminish and unseat the current leadership for reasons that are controversial at best puts you at a disadvantage, because there could be a reasonable assumption that this document is part of that campaign, and if that is so, then people might decide they don't want any part in that. If the document is not part of that campaign, then onus is on you to convince us that it isn't, and the best way of doing that is honestly and clearly mention the issues and controversies on your site. Keeping silence about that just makes people wonder and ask questions, and is unfair towards your audience, since it might trick some of them to make decisions they will later regret. > Now, I do think there is value in having maintainers endorse the Social > Contract, regardless of the governance model one is aiming for: it can > improve cohesion and allow for more delegation of responsibilities. Details, please: what cohesion are we talking about, how it will depend on whether I did or didn't endorse the document, and which responsibilities you expect to be able to delegate to those who endorse it.
Re: The General Public Licence (GPL) as the basic governance tool
> From: Ludovic Courtès > Cc: m...@klomp.org, gnu-misc-discuss@gnu.org > Date: Sun, 23 Feb 2020 22:34:32 +0100 > > > That's just the tip of a very large iceberg. I know it, you know it, > > and every GNU maintainer knows it. When we get appointed, we receive > > a 1000-word message from RMS with some quite non-trivial instructions, > > including, but not limited to, a pointer to maintain.texi as the place > > to find specific policies and guidelines that are mandatory to follow. > > That is what I alluded to when I said "maintaining a GNU project > > according to the guidelines". I don't know how things are on your > > plate, but for me following those guidelines takes most of my free > > time, and requires some non-trivial efforts. > > Of course, but these are mostly technicalities. Richard’s point here is > that we’re expected to do nothing beyond following those policies, and > even the guidelines can be sidestepped. Those "technicalities" and policies is what makes the GNU Project what it is: a Free OS advanced by a Free Software movement. Without those "technicalities", there would be nothing to make us different from any other "open-source" project. > >> The GNU Social Contract is about changing that. > > > > How can you change that if the document is voluntary? > > Endorsers will know what to expect from each other and people who work > with them will have a clearer picture, too. Expect from them and have a clearer picture in what areas? Are we talking about developing GNU software, or are we talking about something else? IOW, are you trying to make the GNU Project change its goals to include more than just developing a Free OS? And if you do, then what are those additional goals which you would ideally want GNU to pursue? > Over the last decade I have, again, not been silent about a desire to > work towards a collectively-run GNU. But I’ve also done a lot for GNU > in that time, and I don’t think it’s useful to view every single action > of mine as “part of that campaign”. I was only talking about that single action, not about everything you did and continue doing as part of developing and maintaining GNU software. > If you and I both state our commitment to upholding that set of values, > then we have something in common that we can build on. We know we’re on > the same page. > > A project like GNU is the people who make it. If the ties among those > people are stronger, the whole project benefits. The Social Contract > can be one of these things that allows us to emphasize what we share. I think being involved in the same GNU software project is already evidence that we have a lot in common, and goes a long way towards making our ties quite strong. I don't see how a declarative document can do anything to make that any stronger. Especially since not everyone will endorse it. I hope it doesn't mean you will talk kinder to those who did, or treat them more favorably in any other sense.
Re: The General Public Licence (GPL) as the basic governance tool
> From: Mark Wielaard > Cc: gnu-misc-discuss@gnu.org > Date: Thu, 27 Feb 2020 14:48:58 +0100 > > those mostly describe the what, not the why. The GNU Social Contract > describes the core goals, the why we do GNU. "Core goals" and "why we do it" are not the same. The latter might be personal and different from one maintainer to another. > They can be seen as a summary of the GNU mission. What is GNU and what is its mission is described here: https://www.gnu.org/ I see no reason to add anything else, as any addition will most probably reiterate what is already there (or, worse, contradict it). > Now that we have a GNU Social Contract, that describes the core mission > of GNU, we can more easily reason about all these policies and > recommendations and how some of them might indeed be mandatory and > which are just suggestions that might or might not apply in the > technical context of your package and developer community. That again doesn't answer my questions and doesn't resolve the concerns around this strange document. You seem to be saying that it is an attempt to produce a concise summary of what is already written elsewhere, but the stuff presented on the GNU site is quite structured and easy to read and understand. So this document seems to be redundant, and calling it a "Contract", and a non-mandatory one at that (a contradiction of terms in my book), makes the purpose even less clear. But if that's all the document is: an attempt to summarize the purpose of the GNU project, then why all the fuss around it? why is it so important to have it? I've never seen any confusion among maintainers of GNU packages related to the goal of GNU as a whole, and it's quite clear why: that goal is pretty much in your face right from the first phrases of https://www.gnu.org/. We know what we are doing, and we know that for a long time.
Re: The General Public Licence (GPL) as the basic governance tool
> From: Ludovic Courtès > Cc: "Alfred M. Szmidt" , gnu-misc-discuss@gnu.org, > christo...@poncy.fr > Date: Fri, 21 Feb 2020 09:02:34 +0100 > > > I don't see the opposing viewpoints reflected in your documentation > > anywhere. You have formed a subgroup, discussed your views in private, > > and are now soliciting positive feedback within the project, while > > largely ignoring negative one. > > This is wrong. See the timeline at: > > https://wiki.gnu.tools/gnu:gsc-feedback If, as that page says, the proposed "contract" is entirely voluntary, then what is its significance? IOW, what would those who endorse it have or be entitled to that the others won't? And why are you going to such lengths trying to advance and promote a document which is not mandatory for endorsement by GNU developers and maintainers? Those promotion efforts imply that the document is somehow very central to your ideas of governance and the call for changes in the GNU leadership, whereas dismissing its importance by saying the endorsement is entirely optional seems to fly in the face of those efforts. This apparent contradiction needs to be clarified, IMO, because its existence makes your intention unclear and even somewhat mysterious. More generally, I don't think that page answers Dmitry's concerns. The disputes we witness here and elsewhere about your initiative involve much more than just that single short declarative document, they are about several more specific ideas of yours, such as that GNU maintainers and developers should have more say in the GNU political decision-making, and that RMS should be removed from his current role because you think he is unfit for leading GNU and even causes harm to GNU. There's nothing in your Wiki about dissent over these and other related ideas, AFICT.
Re: The General Public Licence (GPL) as the basic governance tool
> From: Mark Wielaard > Cc: gnu-misc-discuss@gnu.org > Date: Fri, 21 Feb 2020 22:40:00 +0100 > > To work on the GNU project you do not need to endorse it. But > those who do are promising to uphold its values while working on GNU. I don't understand the practical implications of the last sentence. What does it mean in practice "to uphold the values while working on GNU", and how might that differ from what we the maintainers do today while working on GNU, for a maintainer who doesn't necessarily endorse the document? I always thought that maintaining a GNU project according to the guidelines I was communicated when I was appointed _is_ upholding GNU values, that it's all there is in upholding them, as applied to my job as the maintainer. But you seem to be saying there's something else there? What is that? > It isn't directly related to governance issues. But discussing > governance issues (or any policy issues) will be easier if we at least > have a set of core principles we all value. Promoting those values is > what is important. How will governance be easier if some of the governed don't endorse some of the principles in the document? > > More generally, I don't think that page answers Dmitry's concerns. > > The disputes we witness here and elsewhere about your initiative > > involve much more than just that single short declarative document, > > they are about several more specific ideas of yours, such as that GNU > > maintainers and developers should have more say in the GNU political > > decision-making, and that RMS should be removed from his current role > > because you think he is unfit for leading GNU and even causes harm to > > GNU. There's nothing in your Wiki about dissent over these and other > > related ideas, AFICT. > > You are right that some months ago there was discussion on this > mailinglist about some of those issues. Yes, there are GNU participants > who have strong opinions about those issues. But they are often > expressed in the negative. That the dissenting opinions are expressed in the negative doesn't mean they are invalid or should be dismissed. Surely, there's a way of describing those opinions in civilized ways so they are worthy to be mentioned as serious objections. Moreover, some of the dissenting opinions were indeed expressed in such civilized form, so the label "negative" is not really appropriate to them. > I don't believe there is consensus on some of those ideas yet. The lack of the consensus is precisely why they should be mentioned there, including the fact that there's no consensus as of yet. > Without first having a clear definition of what GNU is and what the > core values of the GNU project are that we all agree on, it is > unproductive to tackle more controversial topics. That is why the > GNU Social Contract is so narrow, focused and concentrates on the > positives. The fact is that those same people who wrote the document and promote it are those who are promoting the ideas of changing the leadership and the governance model. You cannot work around of that. It is IMO better to present these issues honestly and a objectively as possible than to try to sweep them under the carpet. It might make the discussions more open and the sides more trustworthy towards one another. IOW, focusing on the positive sides is, at least IME, not a good strategy when dealing with such divisive topics.
Re: [Hangout - NYLXS] State of the GNUnion 2020
> Date: Fri, 21 Feb 2020 21:09:47 +0100 > From: Andreas Enge > Cc: gnu-misc-discuss@gnu.org > > Well, you are of course entitled to that opinion, but I am naturally of the > opposite one. Why "naturally"? Can you be convinced that your opinion is wrong? (If not, this seems to be a kind of religious argument, where no agreements or compromises can ever be reached.) If you can be convinced otherwise, what would it take for you to change your opinion?
Re: State of the GNUnion 2020
> From: DJ Delorie > Cc: gnu-misc-discuss@gnu.org > Date: Thu, 20 Feb 2020 13:10:49 -0500 > > a...@gnu.org (Alfred M. Szmidt) writes: > > That speaks more to the fact that the GNU project leadership has no > > impact on project adaptation, or contributor activity. But rather it > > is a individual effort by each project maintainer. > > One could argue that this indicates that what you term "GNU leadership" > is not providing leadership to the projects, and that the maintainers > must provide that leadership themselves. What is the point of > leadership that has no impact? No one, not even the above quote, said they have "no impact" in general. The guiding principles of what it takes to be a maintainer of a GNU project are communicated to each one of us when he or she is appointed. Those principles have very important impact on what we do, day in and day out, as part of our job as maintainers. But whether to accept this or that changeset, in what direction to develop the project, which new features are more important then others, how to attract more contributors, etc. etc. -- here the leadership has almost no impact. They will if we ask them for advice or help, but we rarely if ever do, because we generally know how to that stuff ourselves, and because besides general advice an outsider cannot really help in these matters. So the actual health and longevity of each project is almost completely dependent on the project maintainers, and the leadership has almost no influence there -- until and unless there's a crisis, of which we had a few: the Emacs/XEmacs fork, the EGCS split, the glibc incident, etc. Those are the few and far-in-between exceptions that IMO squarely tell us what the rule is. > Perhaps this view does not align with your view, but we must also > consider how the general public (or at least the general > free-software-involved public) views us from the outside. If they are > more likely to be influenced by the maintainers than by RMS, from > *their* point of view, the maintainers *are* the GNU leadership. We > should not be blind to how we are perceived by others. Are you really saying that the general public cares about our day-to-day decisions, or about how frequently we make releases, or our commit rate? IME, they only care when there's some potentially scandalous issue, or one that seems to be brewing. If you disagree, please show a few examples of such interest, where deeper involvement of the leadership in routine management of a project did or could have mattered as far as general public is concerned. I could think of none, but maybe my memory is biased. > And don't fall into the trap of thinking leadership can only come from > one person. RMS may be "the leader" but he's not the only one providing > leadership to others. "Can provide" or "does provide"? Are you saying that leadership _can_ be from more than one person, or are you saying that it already is? If the latter, who specifically did you have in mind that is providing leadership to others at this time, or did in the past? And what kind of leadership is/was that?
Re: State of the GNUnion 2020
> From: DJ Delorie > Cc: a...@gnu.org, gnu-misc-discuss@gnu.org > Date: Sat, 22 Feb 2020 10:34:31 -0500 > > > The guiding principles of what it takes to be a maintainer of a GNU > > project are communicated to each one of us when he or she is > > appointed. Those principles have very important impact on what we do, > > day in and day out, as part of our job as maintainers. > > But being a leader in a project for a community of developers is so much > more than just doing the GNU maintainership duties. One of the side > effects of being a good leader is that you have a stronger community, > more developers, more *effective* contributors, etc. A leader can grow > a community, not just accept patches from it. This is what the > "outsiders" can see when they choose which project to contribute to. I think we are losing the context. See below. > > If you disagree, please show a few examples of such interest, where > > deeper involvement of the leadership in routine management of a > > project did or could have mattered as far as general public is > > concerned. I could think of none, but maybe my memory is biased. > > Can you not remember all those years of djgpp development? All the > users who came for help, and stayed to help? You were as responsible > for the success of that community as I was. Sure, but neither of us was "GNU leadership". Which is exactly my point in this sub-thread: the project developers and maintainers have a much more significant effect on the project than "GNU leadership". And neither do I remember how any of what happened in DJGPP was of any interest of the general public. > > "Can provide" or "does provide"? Are you saying that leadership _can_ > > be from more than one person, or are you saying that it already is? > > Both. Looking at the tools (gcc, glibc, binutils, gdb) I see a strong > guiding hand from the project leads (stewards, maintainers, whatever) > that very much says "leaders". These are people who not only accept > patches but organize conventions, plan future work, arrange for tutors, > and even in some cases handle sponsorships. I would say these projects > are thriving under their own leadership *despite* the lack of leadership > from above. You say "despite", and by that postulate that leadership from above is lacking, and moreover, if it were available, it could do a lot better than the project maintainers do. But this still has to be proven, and my personal opinion and experience is that any outside influence cannot help on any significant level. Attracting new developers is mainly about the technical details of the package, and then about the communication and educational skills, but most significantly it is about intimate day-to-day communications. How can any outsiders help me in this matter, when they generally lack any detailed knowledge about the particular software and its development trends, don't routinely speak on our forums, and don't even know who are the veterans and who are newcomers? > But still, a growing concern in these projects is - why do people choose > to work for other projects and not GNU? How do we convince, for > example, younger developers to participate? Having someone who can > accept patches is insufficient to solve this. The context of this was the question I asked whether "GNU leadership" has any effect on the metrics that Andy presented, which looks at the frequency of releases. We can talk about other and broader aspects, but then we'd lose context and wander to other pastures. Going back to the original context, I still don't see how any of the aspects you mentioned are relevant to the metrics which was proposed as a measure of the leadership's fitness for the job and/or the health of GNU in general.
Re: State of the GNUnion 2020
> From: Andy Wingo > Cc: gnu-misc-discuss@gnu.org > Date: Mon, 17 Feb 2020 21:37:55 +0100 > > I agree also! This sort of activity is natural in a project that > engages in self-reflection. If a project has leadership, then naturally > leadership would be conducting the exercise. Do you actually know whether the leadership does/did such analysis? I don't, but if you do, please share the details. I do agree that leadership of any project should track and analyze the long-term tendencies in the project's life cycle. However, the methods and tools for such an analysis are not necessarily the ones you've chosen, and in any case what tools to choose is up to the leadership. > > _before_ showing us a bunch of naïve graphs and drawing conclusions > > from them (which unsurprisingly coincide with the opinions the author > > expressed long before showing those graphs). > > I know that we may disagree on interpretation of the data, and that > neither you nor I can avoid starting this kind of investigation with > preconceptions, but please believe that I did the analysis in good > faith. I didn't say and didn't mean that you did what you did in bad faith. I said the tools and methods chosen were naïve, which is something very different. The tendency to interpret complex data in naïve ways is a frequent human error, I see it every day on my daytime job. That we all tend to interpret the data in ways that are consistent with our prior beliefs is also a common cause of incorrect and biased conclusions, not at all a sign of foul play. I think your conclusions are naïve because they take all of the hundreds of GNU projects and apply simple statistics to all of them together, as if they were a homogeneous population. My point is that they aren't homogeneous, and any serious attempt to analyze the data you used to reflect on the health of the GNU Project as a whole must subdivide the projects into several groups and deal with each group separately, according to that group's traits. We all do this kind of selective analysis in each of our specific projects: we distinguish between major and minor aspects of our projects, between problems that affect the main functionalities and those which affect marginal ones, or happen on platforms about which we care less or not at all. We then consider only the important parts when assessing the health of our projects, or at least assign very low weight to the unimportant parts. Giving everything the same weight will more often than not produce absurd or nonsensical results. > or fork the repo and do your own analysis... seriously. Sorry, no. Criticism of the methodology and tools is (or at least should be) a legitimate response to a published analysis; saying "do it yourself or forever hold your peace" is not a valid counter-argument. If you are serious about your research, you should hear the criticism, refine your methodology, improve your tools, and publish corrected results. Or you can say "sorry, feel free to disregard my conclusions, they are not necessarily valid". > I have my conclusions which I stand by but which are certainly not > set in stone. I'm saying, quite simply, that the data and its analysis you provided don't support your conclusions. First and foremost, the criteria you've chosen as "health indicators" must be analyzed and validated, _before_ they are used to draw such conclusions. I've seen no such validation in your presentation. You seem to have accepted their validity as an axiom. > > Why wasn't such (or similar) analysis done before coming up with this > > "state of GNUnion"? I think such anecdotal studies can speak volumes > > more than those graphs. > > This could be! Please do go out and ask. Again, that was a suggestion to _you_ to try and validate your criteria. Don't turn the table and make it _my_ problem, because doing so doesn't make your conclusions any more valid than they were originally. The analysis you did was _your_ itch to scratch, not mine. If you want to convince me that your conclusions are valid, you will have to go the extra mile. > > And then we have Guile, whose development pace leaves a lot to be > > desired, if we really want it to become the GNU standard extension > > languages. Strangely, the Guile developers, including Andy Wingo, > > don't seem to do anything about that. There are no discussions about > > making the project more active, none at all. Does that mean the Guile > > level of activity is OK with Andy? If so, how does that live in peace > > with the seemingly grave outlook for the rest of GNU? > > Honestly this argument is beneath you. You do not believe my > conclusions about GNU -- which is fine -- but instead you try to shift > the focus to the project I maintain, claiming that it is in poor health > -- something that which would not invalidate the argument -- but, with > no data or analysis to back it up, which is the aspect that you > criticise about my conclusion. WTF.
Re: State of the GNUnion 2020
> From: DJ Delorie > Cc: gnu-misc-discuss@gnu.org > Date: Tue, 11 Feb 2020 12:00:51 -0500 > > a...@gnu.org (Alfred M. Szmidt) writes: > > You make the incorrect assumption that the health of the GNU project > > should be measured in how many new projects are adopted or released -- > > instead of what our goal is to provide a free operating system. > > Are we DONE producing that operating system? No? If not, why not? > Aren't all those developers who finished their packages working on > other, new packages? Why aren't the package counts continuing to > increase, if the developers are otherwise unoccupied? Those are very important questions, and they should have been investigated, analyzed, and answered _before_ showing us a bunch of naïve graphs and drawing conclusions from them (which unsurprisingly coincide with the opinions the author expressed long before showing those graphs). So: _are_ we done developing that OS? How do you tell? Do other OSes constantly increase their package counts? If so, by how much and with what rate? How come we attempt to answer the former question without studying the latter ones? Is that an attempt at a serious analysis, or is this an attempt to "prove" what we think we already know? > I think, package activity *is* a valid metric if the goal is "all > packages in the OS are free." Yes, but _what_ package activity is that? Who says that package activity is measured by the number of new packages? Isn't it reasonable to see the number of packages level out at some point, and the activity then switches to making new releases? And for packages that have a limited set of features, isn't it reasonable that they at some point slow down development and even stop making new releases? Take Sed, for example, or 'ed', or even GNU Hello -- how many new features can you stuff into that? Or take GNU Make -- is it really unreasonable that it is in maintenance mode? I don't think so. And then there are packages which simply no longer have the demand that would justify new releases. DJGPP comes to mind. If someone wants to try answering this question: > If a set of developers finish a package, and don't start on a new one, I > think that says something interesting about the health of GNU and its > community. then they could try tracking down the DJGPP developers of yore and see what happened to them, and try through that deduce what does that say about the health of GNU and its community. Why wasn't such (or similar) analysis done before coming up with this "state of GNUnion"? I think such anecdotal studies can speak volumes more than those graphs. I could also offer a different measure of the health of GNU: look at the projects that are at the base of any OS: GCC, glibc, Binutils, GDB, etc. These are thriving by any measure, putting out new releases every few months. Even Emacs, which was always, and still is, blamed for notoriously slow release cycle, keeps delivering a major release every 3 years -- for the last 25 years. And then we have Guile, whose development pace leaves a lot to be desired, if we really want it to become the GNU standard extension languages. Strangely, the Guile developers, including Andy Wingo, don't seem to do anything about that. There are no discussions about making the project more active, none at all. Does that mean the Guile level of activity is OK with Andy? If so, how does that live in peace with the seemingly grave outlook for the rest of GNU? Last, but not least: I'm not at all sure that statistics of the kind we were presented, which is based on various measures of package activity, tells anything about "the health of GNU", because GNU, at least as I understand that term, has almost nothing to do with development activity of GNU packages. The development activity is determined solely by the project's development team and its abilities to draw contributions and find worthy development goals. GNU as an organization doesn't have any impact on that, because they almost never interfere into these matters (unless there's some sort of scandal, which happens only very rarely).
Re: A summary of some open discussions
> From: Siddhesh Poyarekar > Date: Tue, 14 Jan 2020 12:38:13 +0530 > > On 14/01/20 6:50 am, nylxs wrote: > > So you guys should get together an create your own organization > > > > The last time a major fork happened in the GNU world was with egcs. A > little reading will give an indication of how that ended. OTOH, there was also the XEmacs fork, which started almost in the same time frame, and which ended very differently. If someone is going to read on the egcs affair, I suggest reading on XEmacs as well. My take from this is twofold: . forks are a terrible waste of our scarce resources . people should try harder to work with those with whom they disagree, and should emphasize the common instead of the disagreements
Re: A summary of some open discussions
> From: Brandon Invergo
> Date: Wed, 08 Jan 2020 21:28:02 +
>
> > Linus gives a lot of delegation. In the end he is the last merge point,
> > but he completely trusts direct subtree maintainers, who can work the
> > way they wish.
>
> As does Richard. He largely only retains responsibility for
> project-wide decisions while the rest is delegated. In the overwhelming
> majority of cases he lets the maintainers, webmasters, etc. do their
> jobs independently. Many of the email exchanges I have with him end up
> with "DTRT" ("do the right thing", meaning, use my judgment). He very,
> very rarely intervenes in the development of individual packages (other
> than Emacs, of course).
Not even in Emacs, as a matter of fact. He posts quite rarely to
emacs-devel, mostly to express his opinions regarding some issue that
comes up in the discussions, but almost never says anything that would
sound as intervention or enforcing his views.
