ognus

ognus

[Simon Josefsson]

Did anything happen after the last should-we-launch-ognus discussion?

What do you think about me tagging cvs HEAD as v5-8-8 and commiting my
S/MIME and PGP/MIME work to HEAD, marking the start of OGnus?

Lars, are you there?

(It doesn't necessarily mean current CVS must be Gnus 5.8.8, you can
move the tag before releasing Gnus 5.8.8 if required.)

Re: ognus

[ShengHuo ZHU]

Simon Josefsson <sj@extundo.com> writes:

> Did anything happen after the last should-we-launch-ognus discussion?
> 
> What do you think about me tagging cvs HEAD as v5-8-8 and commiting my
> S/MIME and PGP/MIME work to HEAD, marking the start of OGnus?
> 
> Lars, are you there?

I've sent Lars a message in early this month. No response yet.

> (It doesn't necessarily mean current CVS must be Gnus 5.8.8, you can
> move the tag before releasing Gnus 5.8.8 if required.)

I tagged it (pre-ognus-point instead), moved those files, truncated
ChangeLog, set revision to 6.0, added the wish list (todo file).  This
means beyond the point the codes are UNSTABLE.  I didn't fork a branch
because there is a stable branch emacs21-branch (though some XEmacs
files are not in it.)

ShengHuo

Re: ognus

[Simon Josefsson]

ShengHuo ZHU <zsh@cs.rochester.edu> writes:

> I tagged it (pre-ognus-point instead), moved those files, truncated
> ChangeLog, set revision to 6.0, added the wish list (todo file).

Cool!

I've commited sign/encrypt keybindings/menu for MML, and mml-sec.el to
implement S/MIME and PGP/MIME (using your mml2015).  The S/MIME stuff
probably make Gnus the world's first MUA that fetches certificates
from DNS.  (Altough you'll probably find that noone but me publish
their S/MIME certificate in DNS yet. :-))

As MML doesn't seem to be documented from a user perspective at all
(or is it?  All I could find was emacs-mime.texi) I'll start working
on a "composing articles" section in the Gnus manual, with info about
S/MIME and PGP/MIME.

Re: ognus

[Kai Großjohann]

On 28 Oct 2000, sj@extundo.com wrote:

> As MML doesn't seem to be documented from a user perspective at all
> (or is it?  All I could find was emacs-mime.texi) I'll start working
> on a "composing articles" section in the Gnus manual, with info
> about S/MIME and PGP/MIME.

Is gnus.texi the right place for this?

message.texi might be right because it's about composing messages.

emacs-mime.texi might be right because it's about MML.

kai
-- 
I like BOTH kinds of music.

Re: ognus

[Simon Josefsson]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> > As MML doesn't seem to be documented from a user perspective at all
> > (or is it?  All I could find was emacs-mime.texi) I'll start working
> > on a "composing articles" section in the Gnus manual, with info
> > about S/MIME and PGP/MIME.
> 
> Is gnus.texi the right place for this?
> 
> message.texi might be right because it's about composing messages.
> 
> emacs-mime.texi might be right because it's about MML.

Right, message.texi point to emacs-mime for MML.  Hm.  By the comment
in emacs-mime (it's intended for developers and not users) perhaps
message.texi is better?  The "step-for-step S/MIME setup" I'm working
on is probably best suited for message.texi.

emacs21-branch (Re: ognus)

[Karl Eichwalder]

ShengHuo ZHU <zsh@cs.rochester.edu> writes:

> I tagged it (pre-ognus-point instead), moved those files, truncated
> ChangeLog, set revision to 6.0, added the wish list (todo file).

Thanks!

> I didn't fork a branch because there is a stable branch emacs21-branch
> (though some XEmacs files are not in it.)

Yes, and the autoconf files are missing.  Any chance to add these files
to the STABLE branch, too?

-- 
work : ke@suse.de                          |                   ,__o
     : http://www.suse.de/~ke/             |                 _-\_<,
home : keichwa@gmx.net                     |                (*)/'(*)

Re: ognus

[Dave Love]

>>>>> "ZSH" == ShengHuo ZHU <zsh@cs.rochester.edu> writes:

 ZSH> I tagged it (pre-ognus-point instead), moved those files,
 ZSH> truncated ChangeLog, set revision to 6.0, added the wish list
 ZSH> (todo file).  This means beyond the point the codes are
 ZSH> UNSTABLE.

This is unfortunate.  Now people (like me) used to doing updates
against the CVS head or, I guess, picking up snapshots, get something
unstable that they're not expecting and they can't pick up bug fixes
to Gnus 5.8.  It also screws me merging stuff for Emacs 21.

Gnus 5.8 should have been stabilized and a proper release made before
this.  (I know that probably requires Lars to start doing maintenance
again unless someone else gets control at the distribution machine or
we can arrange to move things and advertise the fact.)  Development
hacking could have happened on a branch.

Changing RCS version numbers in the repository is just the wrong thing
to do.

 ZSH> I didn't fork a branch because there is a stable branch
 ZSH> emacs21-branch (though some XEmacs files are not in it.)

That is not a stable branch.  It's for my convenience importing into
Emacs, and the code may not even work, particularly outside Emacs 21.
It should not have XEmacs-specific files on it, or anything for which
we don't have assignments.  Apart from the fact that it needs more
merging, which I'll have to abandon for the moment, it's already
somewhat forked and will get worse soon unless we get assignments for
stuff installed without them.

Re: ognus

[Dave Love]

>>>>> "KG" == Kai Großjohann <.> writes:

 KG> message.texi might be right because it's about composing messages.

Yes.

 KG> emacs-mime.texi might be right because it's about MML.

Although it should be documented, users shouldn't actually see that
stuff.  It would be useful to provide a widget-based user interface to
it, but that should still be documented in message.texi.

We could use user-oriented doc in message.texi about composing MIME as
things stand for Gnus 5.8.

Re: emacs21-branch (Re: ognus)

[Dave Love]

>>>>> "KE" == Karl Eichwalder <keichwa@gmx.net> writes:

 KE> Yes, and the autoconf files are missing.  Any chance to add these
 KE> files to the STABLE branch, too?

_Please_ keep off the emacs21 branch.

Re: emacs21-branch (Re: ognus)

[Karl Eichwalder]

Karl Eichwalder <keichwa@gmx.net> writes:

> ShengHuo ZHU <zsh@cs.rochester.edu> writes:
> 
> > I tagged it (pre-ognus-point instead), moved those files, truncated
> > ChangeLog, set revision to 6.0, added the wish list (todo file).

Dave Love <d.love@dl.ac.uk> writes:

>  KE> Yes, and the autoconf files are missing.  Any chance to add these
>  KE> files to the STABLE branch, too?
> 
> _Please_ keep off the emacs21 branch.

Okay, I see your point.  The only solution I can see for the moment is
to create another branch based on the `pre-ognus-point' tag.  Right?

-- 
work : ke@suse.de                          |                   ,__o
     : http://www.suse.de/~ke/             |                 _-\_<,
home : keichwa@gmx.net                     |                (*)/'(*)

Re: emacs21-branch (Re: ognus)

[Kai Großjohann]

On Sun, 29 Oct 2000, keichwa@gmx.net wrote:

> Okay, I see your point.  The only solution I can see for the moment
> is to create another branch based on the `pre-ognus-point' tag.
> Right?

Sounds good to me.  What should it be called?  v_5_8?  STABLE?

I'm proposing several tags:

* for each Gnus release, let there be a tag RELEASE_5_8_7 or similar,
  which names a version (not a branch)
* for each Gnus version, let there be a tag V_5_8 or similar, which
  names a branch and `slides' along as patches are added
* let there be a STABLE tag which is the current stable branch (ie, at
  the moment it would be an alias for V_5_8, but when Oort Gnus has
  come of age, it will be an alias for V_5_10)
* let there be a HEAD tag (need not be created, is implicitly there
  anyway) which corresponds to the current development sources.

Thoughts?

Maybe we should put a chapter on the CVS organization into the manual.

kai
-- 
I like BOTH kinds of music.

Re: emacs21-branch (Re: ognus)

[Florian Weimer]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> * for each Gnus release, let there be a tag RELEASE_5_8_7 or similar,
>   which names a version (not a branch)
> * for each Gnus version, let there be a tag V_5_8 or similar, which
>   names a branch and `slides' along as patches are added
> * let there be a STABLE tag which is the current stable branch (ie, at
>   the moment it would be an alias for V_5_8, but when Oort Gnus has
>   come of age, it will be an alias for V_5_10)
> * let there be a HEAD tag (need not be created, is implicitly there
>   anyway) which corresponds to the current development sources.
> 
> Thoughts?

AFAIK, you need to mark the point of the last merge as well, to make
subsequent merging not too difficult.

> Maybe we should put a chapter on the CVS organization into the manual.

Definitely.

Re: emacs21-branch (Re: ognus)

[ShengHuo ZHU]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> On Sun, 29 Oct 2000, keichwa@gmx.net wrote:
> 
> > Okay, I see your point.  The only solution I can see for the moment
> > is to create another branch based on the `pre-ognus-point' tag.
> > Right?
> 
> Sounds good to me.  What should it be called?  v_5_8?  STABLE?
> 
> I'm proposing several tags:
> 
> * for each Gnus release, let there be a tag RELEASE_5_8_7 or similar,
>   which names a version (not a branch)

There are such tags, e.g. p0-99, v5-8-7.

> * for each Gnus version, let there be a tag V_5_8 or similar, which
>   names a branch and `slides' along as patches are added
> * let there be a STABLE tag which is the current stable branch (ie, at
>   the moment it would be an alias for V_5_8, but when Oort Gnus has
>   come of age, it will be an alias for V_5_10)

It is V5-8.

> * let there be a HEAD tag (need not be created, is implicitly there
>   anyway) which corresponds to the current development sources.

It is.

ShengHuo

Re: ognus

[Per Abrahamsen]

Dave Love <d.love@dl.ac.uk> writes:

> This is unfortunate.  Now people (like me) used to doing updates
> against the CVS head or, I guess, picking up snapshots, get something
> unstable that they're not expecting and they can't pick up bug fixes
> to Gnus 5.8.  It also screws me merging stuff for Emacs 21.

All other CVS based projects I know of either have HEAD as the front
of the development branch, or are planning to do so in the future
because having HEAD be the stable branch causes too many problems.

There are no excuse for picking up software with CVS and expecting
stable code.

> Gnus 5.8 should have been stabilized and a proper release made before
> this.  

Aren't all the 5.8.7 point releases stable?

> It should not have XEmacs-specific files on it, or anything for which
> we don't have assignments.

I thought Lars always required assignments for Gnus code.

Re: ognus

[Kai Großjohann]

On 30 Oct 2000, abraham@dina.kvl.dk wrote:

> I thought Lars always required assignments for Gnus code.

He included nndb.el before I signed anything.  (I didn't even know
about signing, back then.)

Now, I have signed, but nndb.el is useless :-)  (Or are there any nndb
users out there?)

kai
-- 
I like BOTH kinds of music.

Re: emacs21-branch (Re: ognus)

[Dave Love]

>>>>> "KG" == Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> writes:

 KG> Maybe we should put a chapter on the CVS organization into the manual.

That has no place in a user manual.

Re: emacs21-branch (Re: ognus)

[Denys Duchier]

Dave Love <d.love@dl.ac.uk> writes:

> >>>>> "KG" == Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> writes:
> 
>  KG> Maybe we should put a chapter on the CVS organization into the manual.
> 
> That has no place in a user manual.

I beg to disagree: when you buy a physical device, you expect the
manual to contain instructions about maintenance.  Same here, only
more so.

Things can be complicated enough as they are.  Let's not make them
harder by withholding crucial information.  Thank you.

-- 
Dr. Denys Duchier			Denys.Duchier@ps.uni-sb.de
Forschungsbereich Programmiersysteme	(Programming Systems Lab)
Universitaet des Saarlandes, Geb. 45	http://www.ps.uni-sb.de/~duchier
Postfach 15 11 50			Phone: +49 681 302 5618
66041 Saarbruecken, Germany		Fax:   +49 681 302 5615

Re: ognus

[Dave Love]

>>>>> "PA" == Per Abrahamsen <abraham@dina.kvl.dk> writes:

 PA> All other CVS based projects I know of either have HEAD as the front
 PA> of the development branch, or are planning to do so in the future
 PA> because having HEAD be the stable branch causes too many problems.

I doubt many of them have absentee maintainers, a lack of management
and not even the ability to make a release or update a web site.

The fact that this exchange is happening is indicative.  I shouldn't
be doing the work I am and I certainly shouldn't find things change
under me like this without warning.  (I'm not a beginner.)

 PA> There are no excuse for picking up software with CVS and
 PA> expecting stable code.

So people wouldn't advise users to do that?  How should things be
stabilized and users provided with useful fixed versions?  (I know
stabilization prior to Gnus releases isn't traditional.)

 PA> Aren't all the 5.8.7 point releases stable?

I don't know what that means.

Certainly things after 5.8.7 don't look too stable and 5.8.7 was
apparently released with mail-source-delete-incoming turned off, for
instance, even if there's notthing else seriously wrong with it.

Something that particularly looks as though it needs sorting out in a
5.8 release is coding conversion stuff; I'd like to see Handa's advice
followed.

 PA> I thought Lars always required assignments for Gnus code.

You might think or hope that.  You might hope that everybody with CVS
write access would have an assignment on file and that no-one else
checked in anything dubious.  If you were Gerd or me, you'd be
disappointed and waste a lot of time on the issue.

rms was right to worry about the situation more than I did previously.

Re: ognus

[Dave Love]

>>>>> "KG" == Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> writes:

 KG> Now, I have signed, but nndb.el is useless :-)  

Having a single contributor sign (thanks) isn't sufficient anyhow, of
course.

Re: emacs21-branch (Re: ognus)

[Laura Conrad]

>>>>> "Denys" == Denys Duchier <Denys.Duchier@ps.uni-sb.de> writes:
    Denys> Dave Love <d.love@dl.ac.uk> writes:
    >> >>>>> "KG" == Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> writes:
    >> 
    KG> Maybe we should put a chapter on the CVS organization into the manual.
    >> 
    >> That has no place in a user manual.

    Denys> I beg to disagree: when you buy a physical device, you expect the
    Denys> manual to contain instructions about maintenance.  Same here, only
    Denys> more so.

    Denys> Things can be complicated enough as they are.  Let's not make them
    Denys> harder by withholding crucial information.  Thank you.

I doubt that Dave was saying anyone should withhold anything.

I think the gnus user manual is daunting enough to a new user without
having an implication that you have to understand CVS as well as 6
kinds of buffer, umpteen backends, 3 kinds of score files...

It might make sense to have a "developer manual", which might contain
such things as guidelines, explainations about things like Incoming*
files, instructions about how to use CVS, and anything else that a
user of the development version should know that isn't relevant to a
user of a released version.  

-- 
Laura (mailto:lconrad@laymusic.org , http://www.laymusic.org/ )
(617) 661-8097	fax: (801) 365-6574 
233 Broadway, Cambridge, MA 02139

Re: emacs21-branch (Re: ognus)

[Steven E. Harris]

Dave Love <d.love@dl.ac.uk> writes:

> That has no place in a user manual.

Agreed. The problem is that we can only refer to "*the* manual."
Perhaps there needs to be a manual directed at developers as
contributors.

-- 
Steven E. Harris        :: steven.harris@tenzing.com
Tenzing                 :: http://www.tenzing.com

Re: ognus

[Russ Allbery]

Dave Love <d.love@dl.ac.uk> writes:

> Certainly things after 5.8.7 don't look too stable and 5.8.7 was
> apparently released with mail-source-delete-incoming turned off, for
> instance, even if there's notthing else seriously wrong with it.

5.8.7 has multiple outstanding bugs, some of which are just annoying
(random failures to decode format=flowed that go away when I peer at them
funny, the random inclusion of NNTP responses in the article headers, some
weird slowness when only a few newsgroups have additional articles when
you press 'g') and some of which seem more serious (complete inability to
encode some corrupted types of messages with non-ASCII characters that I
run into when forwarding spam ranging from a whole sequence of odd
"message has unknown characters" questions to aborting errors about
functions being called with the wrong numbers of arguments).

I've reported some of these to this list.  I tried using the bug-reporting
command and discovered that it included in the e-mail message tons of
information that I consider private, such as my entire split ruleset, so
that was a bit of a non-starter.  Some of the rest I can't reproduce well
enough to generate a bug report for, although I'll give it another try
when I run into a good test case.

> You might think or hope that.  You might hope that everybody with CVS
> write access would have an assignment on file and that no-one else
> checked in anything dubious.  If you were Gerd or me, you'd be
> disappointed and waste a lot of time on the issue.

> rms was right to worry about the situation more than I did previously.

It's staggeringly difficult to run a successful free software project with
many contributors and the GNU copyright submission rules.  I'm very
impressed by those people who manage it; I know from trying to manage INN
development that it would be a complete non-starter for us.  This isn't a
complaint; I know why they exist.  But it's really bloody hard.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

Re: emacs21-branch (Re: ognus)

[Denys Duchier]

Laura Conrad <lconrad@laymusic.org> writes:

> I doubt that Dave was saying anyone should withhold anything.

Perhaps not, but I find the opacity and the secrecy surrounding so
many GNU projects rather frustrating. Gnus is an exception and I'd
like it to stay this way.

> I think the gnus user manual is daunting enough to a new user without
> having an implication that you have to understand CVS as well as 6
> kinds of buffer, umpteen backends, 3 kinds of score files...

"I doubt that Denys was saying that anyone should read an implication
that you have to understand CVS..." :-)

Ah hem... There is nothing wrong about having a part titled
"Maintenance, Development, Or Living On The Bleeding Edge"... but I
don't think we really disagree:

> It might make sense to have a "developer manual"

So, you bind the "bleeding edge" part separately and the user gets two
manuals.  That's fine with me :-)

Cheers,

-- 
Dr. Denys Duchier			Denys.Duchier@ps.uni-sb.de
Forschungsbereich Programmiersysteme	(Programming Systems Lab)
Universitaet des Saarlandes, Geb. 45	http://www.ps.uni-sb.de/~duchier
Postfach 15 11 50			Phone: +49 681 302 5618
66041 Saarbruecken, Germany		Fax:   +49 681 302 5615

Re: emacs21-branch (Re: ognus)

[Kai Großjohann]

On Mon, 30 Oct 2000, d.love@dl.ac.uk wrote:
>>>>>> "KG" == Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE>
>>>>>> writes:
> 
>  KG> Maybe we should put a chapter on the CVS organization into the
>  KG> manual.
> 
> That has no place in a user manual.

The Gnus manual already contains a `for programmers' chapter -- how
about putting it there?

Maybe the `for programmers' stuff should be factored out into a
separate manual, but that can be done later.

kai
-- 
I like BOTH kinds of music.

Re: ognus

[Kai Großjohann]

On Mon, 30 Oct 2000, d.love@dl.ac.uk wrote:
>>>>>> "KG" == Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE>
>>>>>> writes:
> 
>  KG> Now, I have signed, but nndb.el is useless :-)  
> 
> Having a single contributor sign (thanks) isn't sufficient anyhow,
> of course.

Of course.  I was only trying to warn that Lars apparently did not
require assignments, so the work of worrying about assignments isn't
done, yet.

Maybe I should just have said "No, Per"...

kai
-- 
I like BOTH kinds of music.

Re: ognus

[Karl Kleinpaste]

Russ Allbery <rra@stanford.edu> writes:
> I tried using the bug-reporting
> command and discovered that it included in the e-mail message tons of
> information that I consider private, such as my entire split ruleset, so
> that was a bit of a non-starter.

These days, the inclusion of one's customizations is carried out as an
#mml thing, and I routinely just delete those few lines entirely from
the *message* buffer when sending reports, unless there's data in
there that's particularly relevant.

Re: ognus

[Per Abrahamsen]

Dave Love <d.love@dl.ac.uk> writes:

> >>>>> "PA" == Per Abrahamsen <abraham@dina.kvl.dk> writes:
> 
>  PA> All other CVS based projects I know of either have HEAD as the front
>  PA> of the development branch, or are planning to do so in the future
>  PA> because having HEAD be the stable branch causes too many problems.
> 
> I doubt many of them have absentee maintainers, a lack of management
> and not even the ability to make a release or update a web site.

Nor are they writing newsreaders in Emacs Lisp.  Of course the
management situation needs to be cleared, but that doesn't mean we
have to start making decisions that have proven bad in their projects.

> The fact that this exchange is happening is indicative.  I shouldn't
> be doing the work I am and I certainly shouldn't find things change
> under me like this without warning.  (I'm not a beginner.)

I don't know why you are doing that work.  None of the earlier Emacs
bundles have been trying to track Gnus development, they have just
integrated a specific version.  I don't see the XEmacs people having a
specific Gnus branch either.

>  PA> There are no excuse for picking up software with CVS and
>  PA> expecting stable code.
> 
> So people wouldn't advise users to do that?

People advise others to take illegal drugs and engage in unsafe sex
with strangers.  "People" will always give stupid advice, given how
most cvs based projects works, "users" have no excuse for following
that advice.  CVS access is meant for developers, most of whom are
working on the development branch, not end-users[1].

> How should things be
> stabilized and users provided with useful fixed versions?  (I know
> stabilization prior to Gnus releases isn't traditional.)

Gnus _is_ released, and like all the other released versions I find it
pretty good (and stable).  

>  PA> Aren't all the 5.8.7 point releases stable?
> 
> I don't know what that means.

I meant `5.8.x'.

>  PA> I thought Lars always required assignments for Gnus code.
> 
> You might think or hope that.  You might hope that everybody with CVS
> write access would have an assignment on file and that no-one else
> checked in anything dubious.  If you were Gerd or me, you'd be
> disappointed and waste a lot of time on the issue.

Well, he used to avoid e.g. Kyle Jones code (which is both relevant
and very high quality, but unassigned).

Footnotes: 
[1]  Someone pointed out that using CVS to retrieve a specific tagged
release make sense, also for end-users.

Re: ognus

[Sean Doran]

Dave Love <d.love@dl.ac.uk> writes:

> I doubt many of them have absentee maintainers, a lack of management
> and not even the ability to make a release or update a web site.

Hm, I think it would be as easy as one of the usual
suspects making a candidate release tag and fixing up
things in that tagged branch until it seems "good enough"
for a release, tagging the release, putting tarballs up on
ftp.gnus.org, and doing the normal announcement.  If he's
around, some of all of this could be done by Lars, but I
don't think his being buried stalls most of the hard work
(i.e., everything up to the posting of the announcement &
the installation of the tarball on the ftp site).

The question is then what to do about pulling-up bugfixes
into the release; obviously fingers should get broken for
pulling-up anything incompatible into a release tag, and
to avoid unnecessary broken-fingers, someone should play
"releng", maintaining purity, making tarballs of patches
against the released tarball, and so forth.  Various
software projects do this somewhat differently; pull-ups
against the release tag and pull-ups against a second
release_bugfix tag or equivalent seem to work reasonably well.

As to the website and ftp archive, one of the usual
suspects probably could convince him to cough over write
access to his playpens, if they can do a reasonable
imitation of his whimsicalness. :-)

> The fact that this exchange is happening is indicative.  I shouldn't
> be doing the work I am and I certainly shouldn't find things change
> under me like this without warning.  (I'm not a beginner.)

Right, beginners go to the ftp archive and observe
"gnus.tar.gz", or they end up at
http://www.gnus.org/distribution.html where they see
useful information starting with, "Gnus is distributed as
a compressed tar file of Emacs Lisp files".

Perhaps the "development sources" further down the page is
insufficiently scary to people who aren't familiar with
how CVS tends to work in large multi-person projects?

> So people wouldn't advise users to do that?  

No, users should not run development sources, unless they
are prepared to deal with unexpected bugs.

> How should things be stabilized and users provided with
> useful fixed versions?  (I know stabilization prior to
> Gnus releases isn't traditional.)

"Gnus is distributed as a compressed tar file of Emacs
Lisp files".

Unfortunately, the "An archive of patches is also available"
is bit-rotting, but this would be a good place to put
pull-up fixes against the compressed tar files.

Gnus used to be released with such frequency, that
inter-release pull-ups were mostly pointless.  Releasing
with that frequency again is another option, and cuts down
on the releng activity.

>  PA> Aren't all the 5.8.7 point releases stable?
> I don't know what that means.

He means, the "gnus.tar.gz" files found in the primary and
mirror archives are stable.   The current gnus.tar.gz
contains sources to version "Gnus v5.8.7".

> Certainly things after 5.8.7 don't look too stable and 5.8.7 was
> apparently released with mail-source-delete-incoming turned off, for
> instance, even if there's notthing else seriously wrong with it.

After 5.8.7 is "Gnus development sources".

mail-source-delete-incoming -> nil is a safety feature for
new users who have never set up Gnus before, and is a
smart idea.   Anyone who has been using gnus for a while
(e.g., 5.8.6, 5.8.5, ...) may well have (setq mail-source-delete-incoming t)
in her or his .gnus.el

        Sean.

Re: ognus

[Sean Doran]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> Footnotes: 
> [1]  Someone pointed out that using CVS to retrieve a specific tagged
> release make sense, also for end-users.

Yes, iff it's an operation identical to one of:

        1. grab compressed tar file from ftp/www archive
           extract it
           
or

        1. grab compressed tar file from ftp/www archive
           extract it
        2. grab patches relevant to this tar file 
           from ftp/www archive
           extract and apply them
        
Both are done fairly commonly, and in CVS land one could
have various mechanisms for supporting both
simultaneously.  For example:

(for the first option)  cvs co -P -rgnus-5.8.7_release
(for the second option) cvs co -P -rgnus-5.8.7_patched

with a "DO NOT EVER TOUCH" understanding about the first tag above.

"cvs co -P" with no tag at all should always result in the
latest development sources, and may catch fire, explode,
leak battery acid, eat your mail, send spam, or whatnot.
You have been warned.

When there is consensus among the people actually
supporting CVS Gnus about the way to go, someone should kindly
figure out how to make this clear on http://www.gnus.org/distribution/

        Sean.

Re: ognus

[Sean Doran]

Russ Allbery <rra@stanford.edu> writes:

> 5.8.7 has multiple outstanding bugs

In the old days, this would result in a rapid "fixed in zgnus-0.2"
or somesuch if on the developer list (now it's "fixed committed");
if asked somewhere else (e.g. USENET), "will be fixed in gnus-5.8.8".

We do not have Lars (or anyone) doing releasing this
quickly any more, so there are three options, relevant to
other projects which release slowly:

        1. "will be fixed in next Gnus release, don't know when that will be"

        2. "fix pulled up to gnus-5.8.7, grab it by:
           "    a/ applying patches found at <URL>
           "    b/ cvs -d :pserver:gnus@cvs.gnus.org:/usr/local/cvsroot \
           "       checkout gnus -rgnus-5.8.7_patched
           " or if you've done (b) before
           "    c/ cd <path-to-gnus-5.8.7_patched>
           "       cvs update -dP"

        3. "if you're very brave, you can track CVS Gnus"

We seem to be stuck on option three, which is probably the
worst choice for the volunteers who currently do all the
CVS committing and answering questions in various big
venues (e.g. USENET).

There are trade-offs between the first two; one requires
frequent releasing, the other requires policing pull-ups
to the appropriate tag, and storing (in the ftp/www archive)
the pull-ups as patches.

        Sean.

Re: ognus

[Kai Großjohann]

On 31 Oct 2000, smd@ebone.net wrote:

>         2. "fix pulled up to gnus-5.8.7, grab it by:
>            "    a/ applying patches found at <URL>
>            "    b/ cvs -d :pserver:gnus@cvs.gnus.org:/usr/local/cvsroot \
>            "       checkout gnus -rgnus-5.8.7_patched
>            " or if you've done (b) before
>            "    c/ cd <path-to-gnus-5.8.7_patched>
>            "       cvs update -dP"

2b sounds good.  If I'm not mistaken, there's a tag for this.  V-5-8,
maybe?

kai
-- 
I like BOTH kinds of music.

S/MIME and PGP/MIME (Was: Re: ognus)

[Bjørn Mork]

Simon Josefsson <sj@extundo.com> writes:

> I've commited sign/encrypt keybindings/menu for MML, and mml-sec.el to
> implement S/MIME and PGP/MIME (using your mml2015). 

Great! But why are signed parts qp-encoded even when they shouldn't be
according to gnus-group-posting-charset-alist? 


Bjørn

Re: S/MIME and PGP/MIME (Was: Re: ognus)

[ShengHuo ZHU]

"Bjørn Mork" <bmork@dod.no> writes:

> Simon Josefsson <sj@extundo.com> writes:
> 
> > I've commited sign/encrypt keybindings/menu for MML, and mml-sec.el to
> > implement S/MIME and PGP/MIME (using your mml2015). 
> 
> Great! But why are signed parts qp-encoded even when they shouldn't be
> according to gnus-group-posting-charset-alist? 

It is called ultra-safe encoding.  Otherwise, MTAs or MUAs may munge
the signed part.

ShengHuo

Re: S/MIME and PGP/MIME (Was: Re: ognus)

[Bjørn Mork]

ShengHuo ZHU <zsh@cs.rochester.edu> writes:
> "Bjørn Mork" <bmork@dod.no> writes:
> > Simon Josefsson <sj@extundo.com> writes:
> > 
> > > I've commited sign/encrypt keybindings/menu for MML, and mml-sec.el to
> > > implement S/MIME and PGP/MIME (using your mml2015). 
> > 
> > Great! But why are signed parts qp-encoded even when they shouldn't be
> > according to gnus-group-posting-charset-alist? 
> 
> It is called ultra-safe encoding.  Otherwise, MTAs or MUAs may munge
> the signed part.

OK. That makes sense.


Bjørn

Re: ognus

[Dave Love]

>>>>> "SD" == Sean Doran <smd@ebone.net> writes:

 SD> Hm, I think it would be as easy as 

... if it's deemed necessary, appointing a new maintainer (responsible
to the GNU project) and getting access to Lars's machine to make
changes, if only to point people elsewhere.

 SD> No, users should not run development sources, unless they
 SD> are prepared to deal with unexpected bugs.

Doubtless, but I don't see any essential difference between a typical
Gnus release and the head of the development tree at some arbitrary
time.  Which is not to say there shouldn't be one.

There does appear to me to be encouragement, sometimes necessity, for
users to run unstabilized development sources.

Re: emacs21-branch (Re: ognus)

[Dave Love]

>>>>> "DD" == Denys Duchier <Denys.Duchier@ps.uni-sb.de> writes:

 DD> when you buy a physical device, you expect the manual to contain
 DD> instructions about maintenance.

Then you must get disappointed.

 DD> Same here, only more so.

It's probably pointless to enumerate why putting details of the CVS
repository in a user manual is a bad idea, but I'll go further and say
they shouldn't be in any manual in the distribution.  Consider
alternatives.

 DD> Things can be complicated enough as they are.  

Yes, like I often can't figure out how I'm supposed to do something in
Gnus without reading the code, and it's often hard even then.

 DD> Let's not make them harder by withholding crucial information.

Let's not set up straw men.  How about contributing to the
documentation so that it is less complicated for people?  Try to
follow rms's exacting standards for user and programmer docs.

-- 
People have told me the [Emacs] manual is very good.  -- rms

Re: emacs21-branch (Re: ognus)

[Dave Love]

>>>>> "DD" == Denys Duchier <Denys.Duchier@ps.uni-sb.de> writes:

 DD> Perhaps not, but I find the opacity and the secrecy surrounding
 DD> so many GNU projects rather frustrating.

What do you need to know to help you contribute that you think is
being kept secret?

Re: emacs21-branch (Re: ognus)

[Gunnar Evermann]

Dave Love <d.love@dl.ac.uk> writes:

> >>>>> "DD" == Denys Duchier <Denys.Duchier@ps.uni-sb.de> writes:
> 
>  DD> Perhaps not, but I find the opacity and the secrecy surrounding
>  DD> so many GNU projects rather frustrating.
> 
> What do you need to know to help you contribute that you think is
> being kept secret?

FSF emacs pre-releases?

 Gunnar

Re: ognus

[Dave Love]

>>>>> "PA" == Per Abrahamsen <abraham@dina.kvl.dk> writes:

[I'm not going to get into a slanging match over the rest of this, but
I'd prefer not to be treated like someone with no experience talking
through his hat.]

 PA> Well, he used to avoid e.g. Kyle Jones code (which is both
 PA> relevant and very high quality, but unassigned).

Please stop giving a false impression of this issue.  Here's an
indication of serious management problems -- no `but's -- particularly
if the statement about Emacs just integrating a specific version from
the general release were true:

$ grep 'Copyright (C)' base64.el md5.el gpg*el starttls.el gnus-ml.el
base64.el:;;; Copyright (C) 1997 Kyle E. Jones
md5.el:;; Copyright (C) 1995 by Gareth Rees
md5.el:;; Copyright (C) 1990, RSA Data Security, Inc. All rights reserved.
gpg-ring.el:;; Copyright (C) 2000 RUS-CERT, University Of Stuttgart
gpg.el:;; Copyright (C) 2000 RUS-CERT, University Of Stuttgart
starttls.el:;; Copyright (C) 1999 Daiki Ueno
gnus-ml.el:;; Copyright (C) 2000 by Julien Gilles 

[Obviously an FSF copyright notice doesn't mean the contents of a file
are actually properly assigned and I know Lars didn't check in all the
problematic stuff.]

Now I will fork off and do my best at the job I agreed with the Emacs
maintainer and the Gnus maintainer.

-- 
CVS is not a substitute for management.  -- the manual

Re: ognus

[ShengHuo ZHU]

Dave Love <d.love@dl.ac.uk> writes:

> $ grep 'Copyright (C)' base64.el md5.el gpg*el starttls.el gnus-ml.el
> base64.el:;;; Copyright (C) 1997 Kyle E. Jones
> md5.el:;; Copyright (C) 1995 by Gareth Rees
> md5.el:;; Copyright (C) 1990, RSA Data Security, Inc. All rights reserved.
> gpg-ring.el:;; Copyright (C) 2000 RUS-CERT, University Of Stuttgart
> gpg.el:;; Copyright (C) 2000 RUS-CERT, University Of Stuttgart
> starttls.el:;; Copyright (C) 1999 Daiki Ueno
> gnus-ml.el:;; Copyright (C) 2000 by Julien Gilles 

All of them are optional.  Gnus won't break without them.

ShengHuo

Re: ognus

[Per Abrahamsen]

Dave Love <d.love@dl.ac.uk> writes:

> >>>>> "PA" == Per Abrahamsen <abraham@dina.kvl.dk> writes:
> 
>  PA> Well, he used to avoid e.g. Kyle Jones code (which is both
>  PA> relevant and very high quality, but unassigned).
> 
> Please stop giving a false impression of this issue. 

Dave, you are being insulting.  Generally in your latest messages, and
specifically here.  I'm *not* trying to make any "impressions", false
or true.  And I don't care about whatever game you think we are
playing, where "impressions" matter.

> Here's an indication of serious management problems
> [ list of non-FSF copyrights in Gnus]

It is *not* in itself a sign of management problems.  It is only a
sign of management problems, if the project goal includes being
bundled with Emacs.  It *used to*[1] to be a project goal, a factoid
that is relevant when trying to establish what the presents goals are.

That the manager is absent so we can't ask him *is* an obvious
management problem.   

I care about Gnus, and I want Gnus to be part of Emacs (more than half
of all Gnus messages are posted from the version bundled with Emacs,
to bundling probably does more to get Gnus used than any work on
beginner friendliness).  Now, there is a big difference between "Lars
have abandoned the goal of bundling Gnus with Emacs", and "the goal is
unchanged, but the current commiteres haven't been teached properly".
In the first case, there is nothing you can do (except forking Gnus).
In the second case, trying to create a consensus on the list that
non-assigned code can be included is a viable goal.  Whining doesn't
help, carefully phrased non-insulting arguments does.

> CVS is not a substitute for management.  -- the manual

CVS with multiple writers probably require more format management than
the previous "send patch to Lars, wait for next snapshot" situation.
I did ask Lars to write some commit guidelines and he did, but they
should have been more detailed.

Footnotes: 
[1]  Past tense!

uunassigned code (was: Re: ognus)

[Per Abrahamsen]

ShengHuo ZHU <zsh@cs.rochester.edu> writes:

> Dave Love <d.love@dl.ac.uk> writes:
> 
> > $ grep 'Copyright (C)' base64.el md5.el gpg*el starttls.el gnus-ml.el
> > base64.el:;;; Copyright (C) 1997 Kyle E. Jones
> > md5.el:;; Copyright (C) 1995 by Gareth Rees
> > md5.el:;; Copyright (C) 1990, RSA Data Security, Inc. All rights reserved.
> > gpg-ring.el:;; Copyright (C) 2000 RUS-CERT, University Of Stuttgart
> > gpg.el:;; Copyright (C) 2000 RUS-CERT, University Of Stuttgart
> > starttls.el:;; Copyright (C) 1999 Daiki Ueno
> > gnus-ml.el:;; Copyright (C) 2000 by Julien Gilles 
> 
> All of them are optional.  Gnus won't break without them.

Base64 support is hardly optional, but since it is build into modern
Emacsen, providing it in an unassigned file for backward compatibility
seems reasonable enough.

In general, I think unassigned code should be put in a contrib
directory, and not enabled by default.

Re: emacs21-branch (Re: ognus)

[Denys Duchier]

Dave Love <d.love@dl.ac.uk> writes:

> >>>>> "DD" == Denys Duchier <Denys.Duchier@ps.uni-sb.de> writes:
> 
>  DD> Perhaps not, but I find the opacity and the secrecy surrounding
>  DD> so many GNU projects rather frustrating.
> 
> What do you need to know to help you contribute that you think is
> being kept secret?

I think your reply is very symptomatic of what I find frustrating
about GNU projects: namely that one must petition the high priests in
order to obtain the slightest tidbits of information :-) Case in
point: Emacs.  Why does the general public have no information and no
access to the current developments?  Why should I have to be an
`accredited' contributor in order to have access to this information?

My remarks about CVS info for Gnus were motivated by the same
concerns.  Publishing a bit of information can make the on-going
development accessible to a much wider audience.  When I read the user
manual for a piece of software, I usually look for urls that would let
me know where it is currently maintained and developed.  I think the
Gnus user manual should of course contain this information.  Whether
details about the organization and assumptions of the CVS archive
should be in the "USER" manual or elsewhere is really not the issue,
as long as the information is sufficiently openly available as to
permit non-initiates to look in, possibly share the thrills of the
bleeding edge, and maybe eventually contribute, oooh... :-)

Cheers,

-- 
Dr. Denys Duchier			Denys.Duchier@ps.uni-sb.de
Forschungsbereich Programmiersysteme	(Programming Systems Lab)
Universitaet des Saarlandes, Geb. 45	http://www.ps.uni-sb.de/~duchier
Postfach 15 11 50			Phone: +49 681 302 5618
66041 Saarbruecken, Germany		Fax:   +49 681 302 5615

Re: emacs21-branch (Re: ognus)

[Kai Großjohann]

On 02 Nov 2000, Denys Duchier wrote:

> I think your reply is very symptomatic of what I find frustrating
> about GNU projects: namely that one must petition the high priests
> in order to obtain the slightest tidbits of information :-) Case in
> point: Emacs.  Why does the general public have no information and
> no access to the current developments?  Why should I have to be an
> `accredited' contributor in order to have access to this
> information?

(Off-topic alert.)
I'm also interested in this.  Obviously, the Emacs development model
has worked quite well for a long time.  But I don't know why is it the
way it is.  That would be interesting to know.

(Back on topic.)
I also think that the CVS server organization should be documented.  I
don't care whether it's in gnus.texi or gnus-devel.texi or in the
INSTALL or README file.

kai
-- 
The arms should be held in a natural and unaffected way and never
be conspicuous. -- Revised Technique of Latin American Dancing

Re: ognus

[Kai Großjohann]

On 02 Nov 2000, Per Abrahamsen wrote:

> CVS with multiple writers probably require more format management
> than the previous "send patch to Lars, wait for next snapshot"
> situation.  I did ask Lars to write some commit guidelines and he
> did, but they should have been more detailed.

There are CVS commit guidelines?  I grepped -i in gnus/texi/*.tex* for
`cvs' as well as `commit' but didn't find anything.  I also looked on
www.gnus.org under `Distribution'.  It explains how to log in to the
server, no more.

kai
-- 
The arms should be held in a natural and unaffected way and never
be conspicuous. -- Revised Technique of Latin American Dancing

Re: ognus

[Per Abrahamsen]

[-- Attachment #1: Type: text/plain, Size: 104 bytes --]


Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> There are CVS commit guidelines? 


[-- Attachment #2.1: Type: text/plain, Size: 101 bytes --]

Subject: Topics

Topics:
   CVS write access policy & nntp gateway & bug reports & stuff
   Re: CVS


[-- Attachment #2.2: Type: text/plain, Size: 1649 bytes --]

Date: 27 Sep 1999 18:40:44 +0200
From: Lars Magne Ingebrigtsen <larsi@gnus.org>
To: ding@gnus.org
Subject: CVS write access policy & nntp gateway & bug reports & stuff
Message-ID: <m34sgg8fzn.fsf_-_@quimbies.gnus.org>
References: <37EF95D0.26891872@orgtek.com> <rxn1u8uy9y.fsf@tick.thecity.home> <m3d7v48ghw.fsf@quimbies.gnus.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> (And we're still testing the news-to-mail thing.)

Hey!  It worked!

Anybody can now access the quimby.gnus.org news server.  Gatewaying
back and forth seems to work ok, so anyone who want to use it -- feel
free.

CVS read policy:  Anyone who wants to check things out of the CVS
thing -- go ahead.

CVS write policy:  People who have write access can check things into
the repository whenever they feel like it.  Before doing a release, I
will be going over the diff and chucking out anything I don't like,
but if nobody puts in things I don't like, that will make things
easier for me.  :-)  But you have my confidence.  Oh, but pleeeze --
please update the ChangeLog when you do any changes.

Perhaps a pgnus-current.tar.gz package should be created once a day -- 
just a CVS checkout, and then tarred and gzipped?

All bug reports go to the gnus-bug newsgroup.  Perhaps this group
shouldn't be open for reading for the entire world, since there might
be sensitive information there?  How about password-protecting that
group, but with a "public" password that people on this list knows
about? 

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen



[-- Attachment #2.3: Type: text/plain, Size: 1338 bytes --]

Date: 07 Nov 1999 07:27:11 +0100
From: Lars Magne Ingebrigtsen <larsi@gnus.org>
To: ding@gnus.org
Subject: Re: CVS
Message-ID: <m3hfiyvmtc.fsf@quimbies.gnus.org>
References: <rjemeo7tz3.fsf@feller.dina.kvl.dk> <874sfklpbc.fsf@pc-hrvoje.srce.hr> <m3ln8bcl7b.fsf@quimbies.gnus.org> <vaf7ljvuo36.fsf@lucy.cs.uni-dortmund.de> <m3so2jugdo.fsf@quimbies.gnus.org> <rjvh7f2aom.fsf_-_@feller.dina.kvl.dk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> I'd feel safer if there were some rules for cvs writes.  
> 
> For auctex, I use:
> 
> 1. People can update the files they "own", but should post to the list
>    when they do.
> 
> 2. Updates to shared files requeres an ok from me.  Not for the
>    specific code, just for the idea.

Ok, these are the rules:

1. You have full responsibility for the files you "own"

2. Fix any bugs you want.  (Especially you, Shenghuo.  :-)

3. New features or major stuff should either have an OK from me before
   they are checked in, or they should be discussed here, and people here
   should think it's a good idea.  (If I really hate it, I'll back it out
   again, anyway)

4. If you're unsure, ask me or ask here before checking in

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: emacs21-branch (Re: ognus)

[Per Abrahamsen]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> (Off-topic alert.)
> I'm also interested in this.  Obviously, the Emacs development model
> has worked quite well for a long time.  But I don't know why is it the
> way it is.  That would be interesting to know.

Historical reasons.  The first many years the normal way to get Emacs
was to bye or borrow a tape, and the normal way to contribute was to
send patches with email via. uucp over a slow modem.  This requires a
very centralized, batch oriented development process. It was first in
the 90'ties that Internet access became common, and more interactive
development models became feasible.  Since the model works for Emacs,
why change it?

The reason it works is that RMS is extremely responsive.  He also does
a huge job teaching people to contribute.  The model doesn't
necessarilly work for other people, when Kenner took over GCC
maintenance from RMS, the process became sufficiently slow that a fork
became necessary.  I hope Gert manages better with Emacs.

> (Back on topic.)
> I also think that the CVS server organization should be documented.  I
> don't care whether it's in gnus.texi or gnus-devel.texi or in the
> INSTALL or README file.

Me2.  Including things like policies and project goals, which wasn't
as necessary back when Lars was present all the time.

Re: emacs21-branch (Re: ognus)

[luis fernandes]

    abraham> necessary.  I hope Gert manages better with Emacs.

Hmmm...doesn't look promising so far. He's taking forever to reply
about the new Emacs logo proposals I sent him...

(I just couldn't resist that tease... :)

Re: ognus

[Simon Josefsson]

Dave Love <d.love@dl.ac.uk> writes:

> starttls.el:;; Copyright (C) 1999 Daiki Ueno

My bad.   I installed the file after asking that papers was sent to FSF
but never updated the copyright statement. Sorry, I'll take care of it.

Re: ognus

[Dave Love]

>>>>> "ZSH" == ShengHuo ZHU <zsh@cs.rochester.edu> writes:

 ZSH> All of them are optional.  Gnus won't break without them.

If you thought my previous request not to include unassigned code was
wrong, i.e. you disagree with rms, and were going to change how he
understood Gnus is maintained, I wish you'd said so before.

Re: ognus

[Dave Love]

You can explain all this about maintenance changes to rms and gerd.  I
can no longer reassure them, but I am the one actually working to
prevent Gnus 5.9 being pulled from the Emacs 21 sources.

Re: emacs21-branch (Re: ognus)

[Dave Love]

>>>>> "GE" == Gunnar Evermann <ge204@eng.cam.ac.uk> writes:

 >> What do you need to know to help you contribute that you think is
 >> being kept secret?

 GE> FSF emacs pre-releases?

Then you would be wrong.  Of course, you can't contribute much without
an assignment and XEmacs maintainers probably have to demonstrate a
particular spirit of cooperation, but as far as I know they will get
what access they need to help.

Re: emacs21-branch (Re: ognus)

[Dave Love]

>>>>> "DD" == Denys Duchier <Denys.Duchier@ps.uni-sb.de> writes:

 DD> Why does the general public have no information and no access to
 DD> the current developments?  Why should I have to be an
 DD> `accredited' contributor in order to have access to this
 DD> information?

I'm not aware of an accreditation scheme.

Why should maintainers expend the effort to do that if it's better
devoted to improving the software?  If you are volunteering to provide
that effort, and can you show competence to do it, great, contact the
maintainer and perhaps you can change things.  (If you're competent,
you know what's involved and may think twice.)

I don't think the general public has any particular right to demand
that I, say, do this.  GNU is about cooperation and volunteers make
things happen.

 DD> When I read the user manual for a piece of software, I usually
 DD> look for urls that would let me know where it is currently
 DD> maintained and developed.  I think the Gnus user manual should of
 DD> course contain this information.

Yes.  If it doesn't you might contribute a fix.  It _is_ listed in the
released Emacs along with a bunch of other URLs which I've failed to
keep secret.  URLs are also scattered in Lisp library files'
commentary and a number have been added to defgroups, particularly in
the development sources.  They are often already out-of-date in the
released version, of course.

Re: emacs21-branch (Re: ognus)

[Denys Duchier]

Dave Love <d.love@dl.ac.uk> writes:

> I'm not aware of an accreditation scheme.
> 
> If you are volunteering to provide that effort, and can you show
> competence to do it, great, contact the maintainer and perhaps you
> can change things.

Exactly what I was saying: you need to be specially accredited by the
powers that be simply in order to access information.

> Why should maintainers expend the effort to do that if it's better
> devoted to improving the software?

No effort need be expended.  These days, we all use CVS to develop
software.  You simply need to give anonymous read access, just like we
have it for Gnus.

> GNU is about cooperation and volunteers make things happen.

You'd be more likely to get volunteers if they could observe the
on-going developments and decide whether there is something they can
contribute to.

But really, all I am suggesting is that the on-going development be
made transparent rather than opaque.  No effort is involved.  The
general public benefits by being better informed, and as a result can
also better decide whether, what and how to contribute back to the
project.  The project itself doesn't have to change its policy about
accepting contributors.  Everybody wins.  The only thing that we loose
is the veil of mystery.

Cheers,

-- 
Dr. Denys Duchier			Denys.Duchier@ps.uni-sb.de
Forschungsbereich Programmiersysteme	(Programming Systems Lab)
Universitaet des Saarlandes, Geb. 45	http://www.ps.uni-sb.de/~duchier
Postfach 15 11 50			Phone: +49 681 302 5618
66041 Saarbruecken, Germany		Fax:   +49 681 302 5615

Re: emacs21-branch (Re: ognus)

[Gunnar Evermann]

Dave Love <d.love@dl.ac.uk> writes:

> >>>>> "GE" == Gunnar Evermann <ge204@eng.cam.ac.uk> writes:
> 
>  >> What do you need to know to help you contribute that you think is
>  >> being kept secret?
> 
>  GE> FSF emacs pre-releases?
> 
> Then you would be wrong.  Of course, you can't contribute much without
> an assignment and XEmacs maintainers probably have to demonstrate a
> particular spirit of cooperation, but as far as I know they will get
> what access they need to help.

That's what I thought, but RMS apparently disagrees. At least he did
when I asked for access to help contribute the bug fixes that we make
to XEmacs to FSF emacs. I found that very frustrating and to be honest
lost interest in helping FSF emacs at that point.

I hardly find time to work on XEmacs these days anyway.

 Gunnar

Re: emacs21-branch (Re: ognus)

[Kai Großjohann]

On 03 Nov 2000, Denys Duchier wrote:

> No effort need be expended.  These days, we all use CVS to develop
> software.  You simply need to give anonymous read access, just like
> we have it for Gnus.

AFAIK, that's Gerd's plan.  After Emacs 21.1, though.

kai
-- 
The arms should be held in a natural and unaffected way and never
be conspicuous. -- Revised Technique of Latin American Dancing

Re: emacs21-branch (Re: ognus)

[Russ Allbery]

Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> writes:

> (Back on topic.)
> I also think that the CVS server organization should be documented.  I
> don't care whether it's in gnus.texi or gnus-devel.texi or in the
> INSTALL or README file.

For INN, we have a separate HACKING file in the source distribution that
gives coding standards, CVSup server information, information about
programs used to generate documentation, and other similar sorts of
things.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

Re: emacs21-branch (Re: ognus)

[Steinar Bang]

>>>>> Per Abrahamsen <abraham@dina.kvl.dk>:

> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

>> (Back on topic.)
>> I also think that the CVS server organization should be documented.
>> I don't care whether it's in gnus.texi or gnus-devel.texi or in the
>> INSTALL or README file.

> Me2.  Including things like policies and project goals, which wasn't
> as necessary back when Lars was present all the time.

Where is Lars these days, anyways?  Has anyone heard _anything_ in a
while?

Re: ognus

[Steinar Bang]

>>>>> Per Abrahamsen <abraham@dina.kvl.dk>:

> Dave Love <d.love@dl.ac.uk> writes:
>> This is unfortunate.  Now people (like me) used to doing updates
>> against the CVS head or, I guess, picking up snapshots, get
>> something unstable that they're not expecting and they can't pick
>> up bug fixes to Gnus 5.8.  It also screws me merging stuff for
>> Emacs 21.

> All other CVS based projects I know of either have HEAD as the front
> of the development branch,

Yes.

> or are planning to do so in the future because having HEAD be the
> stable branch causes too many problems.

Yes.

Re: ognus

[Steinar Bang]

>>>>> Dave Love <d.love@dl.ac.uk>:

>>>>> "PA" == Per Abrahamsen <abraham@dina.kvl.dk> writes:
PA> All other CVS based projects I know of either have HEAD as the front
PA> of the development branch, or are planning to do so in the future
PA> because having HEAD be the stable branch causes too many problems.

> I doubt many of them have absentee maintainers, a lack of management
> and not even the ability to make a release or update a web site.

Whether the manager is absent or not, doesn't really affect the way
CVS behaves.

Listen to Per.  In fact, just listen.

You should try that some time.

Re: emacs21-branch (Re: ognus)

[Per Abrahamsen]

Denys Duchier <Denys.Duchier@ps.uni-sb.de> writes:

> But really, all I am suggesting is that the on-going development be
> made transparent rather than opaque.  No effort is involved.  

Actually, quite a lot of effort is required to make the development
process "feel" open/transparent to outsiders.  At least, that is the
impression I get from the people who have changed existing software
projects (Mozilla, GCC, GDB) to make them appear more open.  They also
claim the effort is well spend, in terms of recruiting developers.

Re: ognus

[Per Abrahamsen]

Dave Love <d.love@dl.ac.uk> writes:

> You can explain all this about maintenance changes to rms and gerd. 

Why?  It is totally irrelevant to them.  It is the Gnus developers who
decide the project goal, and they are on this list.

Re: emacs21-branch (Re: ognus)

[Denys Duchier]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> Denys Duchier <Denys.Duchier@ps.uni-sb.de> writes:
> 
> > But really, all I am suggesting is that the on-going development be
> > made transparent rather than opaque.  No effort is involved.  
> 
> Actually, quite a lot of effort is required to make the development
> process "feel" open/transparent to outsiders.

Since my suggestion was essentially to give the general public
anonymous CVS access, I can guarantee you that this is a no-brainer
that requires 5mn to set up.  Anything additional would be gravy and
of course welcome, but not essential and can, if desired, be put in
place later.  You might even get volunteers to do it :-)

Cheers,

-- 
Dr. Denys Duchier			Denys.Duchier@ps.uni-sb.de
Forschungsbereich Programmiersysteme	(Programming Systems Lab)
Universitaet des Saarlandes, Geb. 45	http://www.ps.uni-sb.de/~duchier
Postfach 15 11 50			Phone: +49 681 302 5618
66041 Saarbruecken, Germany		Fax:   +49 681 302 5615

Re: ognus

[Lars Magne Ingebrigtsen]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Of course.  I was only trying to warn that Lars apparently did not
> require assignments, so the work of worrying about assignments isn't
> done, yet.

Well, I do require assignments, but, er, I've never been good at,
like, remembering who I've already got assignments from.  I assumed
that I must have gotten an assignment from you, since, well, like,
you're Kai Großjohann.  :-)

I've also slipped up a couple of other times during the years...  Gerd
did a copyright audit of Gnus and unearthed the areas where there was
missing assignments in Gnus.

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: ognus

[Lars Magne Ingebrigtsen]

Dave Love <d.love@dl.ac.uk> writes:

> Please stop giving a false impression of this issue.  Here's an
> indication of serious management problems -- no `but's -- particularly
> if the statement about Emacs just integrating a specific version from
> the general release were true:
> 
> $ grep 'Copyright (C)' base64.el md5.el gpg*el starttls.el gnus-ml.el
> base64.el:;;; Copyright (C) 1997 Kyle E. Jones
> md5.el:;; Copyright (C) 1995 by Gareth Rees
> md5.el:;; Copyright (C) 1990, RSA Data Security, Inc. All rights reserved.

No, that's not a management problem.  I've always deleted these two
files (along with the bundle of XEmacs-dependent files) before
installing into Emacs.  

> gpg-ring.el:;; Copyright (C) 2000 RUS-CERT, University Of Stuttgart
> gpg.el:;; Copyright (C) 2000 RUS-CERT, University Of Stuttgart
> starttls.el:;; Copyright (C) 1999 Daiki Ueno

I don't know what these three are, but I'm assuming Zhenghuo included
these with the same idea as above.

> gnus-ml.el:;; Copyright (C) 2000 by Julien Gilles 

And this one is waiting for copyright assignment papers.

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: ognus

[Kai Großjohann]

On 04 Nov 2000, Lars Magne Ingebrigtsen wrote:

Welcome back, Lars!

> Well, I do require assignments, but, er, I've never been good at,
> like, remembering who I've already got assignments from.  I assumed
> that I must have gotten an assignment from you, since, well, like,
> you're Kai Großjohann.  :-)

:-) Well, no worries.  Like I said, there is one now.  (But I think
Gnus 5.5 and 5.7 are missing nndb.el because of that assignment
thingy.)

I take it that you're still interested in Gnus being included in
Emacs.  So I guess we must all be careful not to include anything in
Gnus which is lacking the copyright assignment.  But ShengHuo has
moved the relevant files to contrib already, if I'm not mistaken.

kai
-- 
The arms should be held in a natural and unaffected way and never
be conspicuous. -- Revised Technique of Latin American Dancing

Re: ognus

[Lars Magne Ingebrigtsen]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> I take it that you're still interested in Gnus being included in
> Emacs.

Yup.

> So I guess we must all be careful not to include anything in
> Gnus which is lacking the copyright assignment.

Indeed.

> But ShengHuo has moved the relevant files to contrib already, if I'm
> not mistaken.

Cool.

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: emacs21-branch (Re: ognus)

[Andreas Fuchs]

Today, Denys Duchier <Denys.Duchier@ps.uni-sb.de> wrote:
>> Actually, quite a lot of effort is required to make the development
>> process "feel" open/transparent to outsiders.
> Since my suggestion was essentially to give the general public
> anonymous CVS access, I can guarantee you that this is a no-brainer
> that requires 5mn to set up.  Anything additional would be gravy and
> of course welcome, but not essential and can, if desired, be put in
> place later.  You might even get volunteers to do it :-)

That is not completely correct. With the open cvs archive come new (and
not quite new)-user questions who could check out the software but do
not understand enough of it to make it work. Thus, expect a flood of
"emacs21 don't work" postings in the gnu.emacs.*.

Nevertheless, the gain is worth the effort. New developers are a _good_
thing in open software projects, and users can be educated.

regards,
-- 
Andreas Fuchs, <asf@acm.org>, <d96001@htlwrn.ac.at>, antifuchs

Re: emacs21-branch (Re: ognus)

[Russ Allbery]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> Actually, quite a lot of effort is required to make the development
> process "feel" open/transparent to outsiders.  At least, that is the
> impression I get from the people who have changed existing software
> projects (Mozilla, GCC, GDB) to make them appear more open.  They also
> claim the effort is well spend, in terms of recruiting developers.

It's a lot of effort to set up.  There is a bunch of automation that you
can do initially that makes it not too bad to maintain, though, apart from
the increasing number of questions about unstable sources.

Setting up read-only CVS access and setting up some loginfo scripts so
that all CVS commit messages result in an e-mail message (and ideally
point to CVSweb diffs) really does wonders towards letting people feel
like they know what's happening behind the scenes.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>