RE: New application proposal - git-core SCM

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

RE: New application proposal - git-core SCM

Gary R. Van Sickle
> From: Tim O'Callaghan
[snip]

> > I don't know about the others but I don't think we want to have two
> > competing versions of mutt in the distribution.  I don't
> see mutt-ng
> > in any linux distro either so it would need to be voted on anyway.
> >
>
> This is the kind of information that should possibly be added
> to the setup.html? While i do not see that multiple tools
> doing the same job is a bad thing, i can see why it might not
> right for cygwin. Same is true of the pre-requisite of having
> it in a Linux distro.
>

The "pre-requisite" is only a sort of "fast track" for new package approval
- if it's in Debian the app gets a free pass as far whether it gets to be
included or not.

Otherwise, it needs an up or down vote from maintainers.  There's like
primaries and gerrymandering and such, it gets pretty messy, there's a page
somewhere with the details I'm sure. ;-)

> With regards to mutt, I emailed g.r.vansickle about 3 weeks
> ago asking about the possibility of moving from mutt 1.4.1 to
> 1.5.10 or to create a 1.5.10 test release. I did not get any
> response, so i grabbed and compiled the latest mutt and later
> found mutt-ng.

Oh, yeah, sorry.  For future reference, private emails are generally
discouraged in favor of posts to the lists.  Somebody asked me this on-list
not long ago; My current plans are to only support the "Stable" 1.4.x
upstream release.

As far as doing 1.5.x as a "test" release, it seems to me that would be a
bit of a misuse of the test category.  The way I see it, "test" is purgatory
for "curr"-wannabes.  There's a lot of upstream mutt development going on
right now, and there's no indication that 1.5.10 will ever be stamped
"Stable" (in fact I'd be pretty surprised if it was).

>  I do not want to step on any toes or usurp
> anyones maintainership. I just thought a wider audience might
> like easy access to mutt-ng, as i use it with the other tools
> i mentioned.
>
> The advantages of mutt-ng is that it can handle getting
> messages via POP, IMAP and NNTP without need for an external
> tool. It also has a thunder-bird style sidebar in which you
> can display the status of your mail and news folders.
>

I frankly don't know much about mutt-ng other than what you said there and
that it's a fork of the mutt codebase.  Rumor on the mutt lists is that it
isn't very active, and I got the impression it was a fork that had "flamed
out".

I personally don't care one way or the other if you wanted to package it,
unless it would interfere with mutt or its mailbox(es).  Is mutt-ng still
using mbox and/or Maildir?

--
Gary R. Van Sickle
 


Reply | Threaded
Open this post in threaded view
|

Re: New application proposal - git-core SCM

Tim O'Callaghan
On Tue, Nov 01, 2005 at 07:49:57PM +0100, Reini Urban wrote:
> $ cpan String::ShellQuote
> works out of the box.
> $ pmq String::ShellQuote
> 1.03    /usr/lib/perl5/site_perl/5.8/String/ShellQuote.pm
>
> cygwin doesn't package each and every perl package.
>

Fair enough. I'll add this to the the git post-install script.

Tim.
"However beautiful the strategy, you should occasionally look at the results."
-- Winston Churchill
Reply | Threaded
Open this post in threaded view
|

Re: New application proposal - git-core SCM

Tim O'Callaghan
In reply to this post by Gary R. Van Sickle
On Tue, Nov 01, 2005 at 11:05:42PM -0600, Gary R. Van Sickle wrote:

> > From: Tim O'Callaghan
> >
> > With regards to mutt, I emailed g.r.vansickle about 3 weeks
> > ago asking about the possibility of moving from mutt 1.4.1 to
> > 1.5.10 or to create a 1.5.10 test release. I did not get any
> > response, so i grabbed and compiled the latest mutt and later
> > found mutt-ng.
>
> Oh, yeah, sorry.  For future reference, private emails are generally
> discouraged in favor of posts to the lists.  Somebody asked me this on-list
> not long ago; My current plans are to only support the "Stable" 1.4.x
> upstream release.
>
> As far as doing 1.5.x as a "test" release, it seems to me that would be a
> bit of a misuse of the test category.  The way I see it, "test" is purgatory
> for "curr"-wannabes.  There's a lot of upstream mutt development going on
> right now, and there's no indication that 1.5.10 will ever be stamped
> "Stable" (in fact I'd be pretty surprised if it was).
>

Maybe got the wrong idea, but i assumed Test generated the
'Experimental' list in the setup app. Which to me implied non 'stable'
ports. I was going to release muttng in that category because of this
assumption.

> >  I do not want to step on any toes or usurp
> > anyones maintainership. I just thought a wider audience might
> > like easy access to mutt-ng, as i use it with the other tools
> > i mentioned.
> >
> > The advantages of mutt-ng is that it can handle getting
> > messages via POP, IMAP and NNTP without need for an external
> > tool. It also has a thunder-bird style sidebar in which you
> > can display the status of your mail and news folders.
> >
>
> I frankly don't know much about mutt-ng other than what you said there and
> that it's a fork of the mutt codebase.  Rumor on the mutt lists is that it
> isn't very active, and I got the impression it was a fork that had "flamed
> out".
>

AFAIU its a version of mutt with some patches that have not been
accepted into the main mutt tree, such as sidebar and NNTP. There is
still development being done on the source, not much on the traffic
lists. AFAIK it is also tracking the mutt base as well.

my compiled version of muttng -v reports:

--
/cygdrive/c/home/tim>muttng -v
Mutt-ng devel-r561 (based on Mutt 1.5.11/2005-09-15)
Copyright (C) 1996-2002 Michael R. Elkins and others.
Mutt-ng comes with ABSOLUTELY NO WARRANTY; for details type `muttng -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `muttng -vv' for details.

System:
  CYGWIN_NT-5.0 1.5.18(0.132/4/2) (i686)
External Libraries:
  ncurses 5.4
  libiconv 1.9
  gdbm GDBM version 1.8.3. 10/15/2002 (built Aug 10 2003 22:11:57)
  gnutls 1.0.25
Compile Options:
  -DEBUG
  +HOMESPOOL  -USE_SETGID  +USE_DOTLOCK  -DL_STANDALONE
  +USE_FCNTL  -USE_FLOCK   -USE_INODESORT   +USE_HCACHE
  +USE_POP  +USE_NNTP  +USE_IMAP  -USE_GSS  -USE_SSL  +USE_GNUTLS  -USE_SASL  -USE_LIBESMTP
  -HAVE_REGCOMP  +USE_GNU_REGEX  +COMPRESSED
  +HAVE_COLOR  +HAVE_START_COLOR  +HAVE_TYPEAHEAD  +HAVE_BKGDSET
  +HAVE_CURS_SET  +HAVE_META  +HAVE_RESIZETERM
  +CRYPT_BACKEND_CLASSIC_PGP  +CRYPT_BACKEND_CLASSIC_SMIME  -CRYPT_BACKEND_GPGME  +BUFFY_SIZE -SUN_ATTACHMENT
  +ENABLE_NLS  -LOCALES_HACK  +HAVE_WC_FUNCS  +HAVE_LANGINFO_CODESET  +HAVE_LANGINFO_YESEXPR
  +HAVE_ICONV  -ICONV_NONTRANS  -HAVE_LIBIDN  +HAVE_GETSID  -HAVE_GETADDRINFO
Built-In Defaults:
  -DOMAIN
  +ISPELL="/cygdrive/r/texlive/bin/win32/ispell"
  +SENDMAIL="/usr/sbin/sendmail"
  +MAILPATH="mail/localinbox"
  +PKGDATADIR="/usr/local/share/muttng"
  +PKGDOCDIR="NONE/doc/muttng"
  +SYSCONFDIR="/usr/local/etc"
  +EXECSHELL="/bin/sh"
  -MIXMASTER

To contact the developers, please mail to <[hidden email]>.
To visit the Mutt-ng homepage go to http://www.muttng.org.
To report a bug, please use the fleang(1) utility.

Mutt-ng is based on the following patches written for mutt:

patch-1.5.6.cb.current_shortcut.2
patch-1.5.6.tt.assumed_charset.1
patch-1.5.6.tg.hcache.12
patch-1.5.5.1.pdmef.short_mbox_name.1
rr.compressed
patch-1.5.4.fw.maildir_inode_sort
patch-1.4.admcd.gnutls.59d
patch-1.5.6i.sidebar.20041122
patch-1.5.4.aw.listreply.1
vvv.initials
patch-1.5.5.1.cd.purge_message.3.4
patch-1.5.5.1.cd.trash_folder.3.4
patch-1.5.5.1.cd.edit_threads.9.5
patch-1.5.4.cd.ifdef.1
patch-1.5.4.cd.source_multiple.2
vvv.quote
vvv.nntp

> I personally don't care one way or the other if you wanted to package it,
> unless it would interfere with mutt or its mailbox(es).  Is mutt-ng still
> using mbox and/or Maildir?
>

The mailbox handling should be exactly the same as mutt, so should
cause no problems.  It would not interfere with existing mutt
configurations either, as the rc files are:
/usr/local/etc/Muttngrc, ~/.muttngrc, ~/.muttng/muttngrc

I will hold off for a month or so before formally submitting muttng,
but i would like to submit it at some point. Then we can let the
gerrymandering begin in earnest ;)

Tim.
"However beautiful the strategy, you should occasionally look at the results."
-- Winston Churchill
Reply | Threaded
Open this post in threaded view
|

Re: New application proposal - git-core SCM

Yitzchak Scott-Thoennes
In reply to this post by Gary R. Van Sickle
On Tue, Nov 01, 2005 at 11:03:07AM -0500, Christopher Faylor wrote:
> I don't know about the others but I don't think we want to have two
> competing versions of mutt in the distribution.  I don't see mutt-ng in
> any linux distro either so it would need to be voted on anyway.

I disagree; a very brief google on mutt-ng tells me it would reasonable
to offer it as an alternative to vanilla mutt.

Oh, and:

http://packages.debian.org/experimental/mail/mutt-ng
Reply | Threaded
Open this post in threaded view
|

Re: New application proposal - git-core SCM

Yitzchak Scott-Thoennes
In reply to this post by Tim O'Callaghan
On Wed, Nov 02, 2005 at 09:38:56AM +0100, Tim O'Callaghan wrote:

> On Tue, Nov 01, 2005 at 07:49:57PM +0100, Reini Urban wrote:
> > $ cpan String::ShellQuote
> > works out of the box.
> > $ pmq String::ShellQuote
> > 1.03    /usr/lib/perl5/site_perl/5.8/String/ShellQuote.pm
> >
> > cygwin doesn't package each and every perl package.
> >
>
> Fair enough. I'll add this to the the git post-install script.

Not sure that's a good idea, since "cpan String::ShellQuote" will
fetch files from the internet (are there other post-installs that do
this?).  Also, if cpan has never been used before, it will go into
a lengthy configuration dialog to set up CPAN::Config.

It would be better to include with your package a git-core-config
script and document that it needs to be run before using git-core.
Reply | Threaded
Open this post in threaded view
|

Re: New application proposal - git-core SCM - Include Perl Module

Tim O'Callaghan
On Wed, Nov 02, 2005 at 02:31:47AM -0800, Yitzchak Scott-Thoennes wrote:

> On Wed, Nov 02, 2005 at 09:38:56AM +0100, Tim O'Callaghan wrote:
> > On Tue, Nov 01, 2005 at 07:49:57PM +0100, Reini Urban wrote:
> > > $ cpan String::ShellQuote
> > > works out of the box.
> > > $ pmq String::ShellQuote
> > > 1.03    /usr/lib/perl5/site_perl/5.8/String/ShellQuote.pm
> > >
> > > cygwin doesn't package each and every perl package.
> > >
> >
> > Fair enough. I'll add this to the the git post-install script.
>
> Not sure that's a good idea, since "cpan String::ShellQuote" will
> fetch files from the internet (are there other post-installs that do
> this?).  Also, if cpan has never been used before, it will go into
> a lengthy configuration dialog to set up CPAN::Config.
>
> It would be better to include with your package a git-core-config
> script and document that it needs to be run before using git-core.

Ok, I'll look into local install and uninstall with the git setup
scripts.

Tim.
"However beautiful the strategy, you should occasionally look at the results."
-- Winston Churchill
Reply | Threaded
Open this post in threaded view
|

Re: New application proposal - git-core SCM - Include Perl Module

Igor Peshansky
On Wed, 2 Nov 2005, Tim O'Callaghan wrote:

> On Wed, Nov 02, 2005 at 02:31:47AM -0800, Yitzchak Scott-Thoennes wrote:
> > On Wed, Nov 02, 2005 at 09:38:56AM +0100, Tim O'Callaghan wrote:
> > > On Tue, Nov 01, 2005 at 07:49:57PM +0100, Reini Urban wrote:
> > > > $ cpan String::ShellQuote
> > > > works out of the box.
> > > > $ pmq String::ShellQuote
> > > > 1.03    /usr/lib/perl5/site_perl/5.8/String/ShellQuote.pm
> > > >
> > > > cygwin doesn't package each and every perl package.
> > > >
> > >
> > > Fair enough. I'll add this to the the git post-install script.
> >
> > Not sure that's a good idea, since "cpan String::ShellQuote" will
> > fetch files from the internet (are there other post-installs that do
> > this?).  Also, if cpan has never been used before, it will go into
> > a lengthy configuration dialog to set up CPAN::Config.
> >
> > It would be better to include with your package a git-core-config
> > script and document that it needs to be run before using git-core.
>
> Ok, I'll look into local install and uninstall with the git setup
> scripts.

Or you could package the necessary modules in a separate package that
follow the installation structure of the Cygwin perl package (like
perl-libwin32 did), and then make the git package depend on that.  We've
done this with some of our prerequisites for an internal project -- works
quite well (incidentally, we needed String::Escape, among other things).
Debian uses this model too, IIRC.
HTH,
        Igor
--
                                http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_ [hidden email]
ZZZzz /,`.-'`'    -.  ;-;;,_ [hidden email]
     |,4-  ) )-,_. ,\ (  `'-' Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DA
Reply | Threaded
Open this post in threaded view
|

Re: New application proposal - git-core SCM

Brian Dessent
In reply to this post by Yitzchak Scott-Thoennes
Yitzchak Scott-Thoennes wrote:

> > Fair enough. I'll add this to the the git post-install script.
>
> Not sure that's a good idea, since "cpan String::ShellQuote" will
> fetch files from the internet (are there other post-installs that do
> this?).  Also, if cpan has never been used before, it will go into
> a lengthy configuration dialog to set up CPAN::Config.

Yes, this is a definite no-no as postinstall scripts cannot be
interactive.  I believe in times past they had a console allocated, but
now they don't even have that so a user cannot read any output nor
provide input to a running postinstall, and running CPAN the first time
requires answering a slew of questions.  Plus, it's not safe to assume
that the computer is connected to the internet when running a
postinstall, since many people do the package download step on one
machine and then install that on a different machine that's not
connected to the net, or connected through a slow connection.

I think it would be sufficient to say in the package README that certain
perl modules are required.  If this is a package meant for developers
then I don't think it's too much to ask them to read the docs and run a
cpan command if they don't have a module.

Brian