On Fri, Dec 11, 1998 at 05:31:16PM +0100, Martin Schulze wrote:
> > That still leaves in the dependency on the physical maintainer. It also
> > makes the information in the Packages file authoritative for the
> > maintainer information. This is Bad for several reasons, only one of them
> > being
On Fri, Dec 11, 1998 at 05:02:17PM +0100, [EMAIL PROTECTED] wrote:
> Hi,
Hi!
First of all: I think your idea is excellent!
> > Could we extend this one more step and state that any package depending
> > on foo has their maintainer subscribed to foo's mailing list. That was
> > when foo change
Hi,
On Fri, 11 Dec 1998, Darren Benham wrote:
> OOps... took out the wrong addresses in the CC field...
>
> When maintainer's change, who's going to change the subscription list?
In case The Maintainer of a package changes identity, the "maintainers
maintainer" would. With a single change, a
On Fri, Dec 11, 1998 at 04:49:57PM +0100, Martin Schulze wrote:
> > I know Brian will be thankful for having an Imlib mailing list.
> See my last mail re this issue.
Erm? I must admit I don't read every message that goes thru -devel, would
take up far too much time...is there an archive of -devel o
On Fri, Dec 11, 1998 at 10:33:02AM -0500, Shaleh wrote:
> I know Brian will be thankful for having an Imlib mailing list.
Ugh. Fortunately Imlib is, for the most part, a well-behaved package.
Even if the bug reports I get for it do give me chest pains sometimes...;)
> Could we extend this one mor
OOps... took out the wrong addresses in the CC field...
When maintainer's change, who's going to change the subscription list? The
physical maintainer's via a "(un)subscribe" message? That would still leave
things in the hands of a physical maintainer... Automaticly from a package
upload would s
[EMAIL PROTECTED] wrote:
> > a) Use [EMAIL PROTECTED] or [EMAIL PROTECTED] in the maintainer field
> > of package foo.
>
> That still leaves in the dependency on the physical maintainer. It also
> makes the information in the Packages file authoritative for the
> maintainer information. Thi
Hi,
On Fri, 11 Dec 1998, Martin Schulze wrote:
> some issues of your proposel are already working. Every package can have
> a mailing list referenced through [EMAIL PROTECTED] This is already
> working for over a year.
Yes, I know. But part of my point was that the way it works now is a bit
o
Hi,
On Fri, 11 Dec 1998, Shaleh wrote:
> Nifty idea. Kinda like it. My only beef is that the "user" must know to mail
> [EMAIL PROTECTED] rather than [EMAIL PROTECTED] or
> [EMAIL PROTECTED]
True. But I don't think that using [EMAIL PROTECTED] or [EMAIL PROTECTED] as an
alias for exactly these
Shaleh wrote:
> Nifty idea. Kinda like it. My only beef is that the "user" must know to mail
> [EMAIL PROTECTED] rather than [EMAIL PROTECTED] or
> [EMAIL PROTECTED]
There is a cute mechanism that [EMAIL PROTECTED] and [EMAIL PROTECTED] both
work, so for regular libraries this issue is resolved.
Howdy Joost,
some issues of your proposel are already working. Every package can have
a mailing list referenced through [EMAIL PROTECTED] This is already
working for over a year.
Requirements:
a) Use [EMAIL PROTECTED] or [EMAIL PROTECTED] in the maintainer field
of package foo.
b) Creat
Nifty idea. Kinda like it. My only beef is that the "user" must know to mail
[EMAIL PROTECTED] rather than [EMAIL PROTECTED] or
[EMAIL PROTECTED]
Not a big issue I know. But you get my meaning.
I know Brian will be thankful for having an Imlib mailing list.
Could we extend this one more step a
Hi,
On Thu, 10 Dec 1998, Martin Schulze wrote:
> [EMAIL PROTECTED] should be a valid address. Would
> that be sufficient for you?
"[EMAIL PROTECTED]" ?
**dazzle**
With an email address like that, there must be a great idea behind it :-)
Seriously, [EMAIL PROTECTED], [EMAIL PROTECTED] and
13 matches
Mail list logo
