Mailing List Archive

patch handling (was: Python 1.6 timing)
On Wed, 2 Feb 2000 bwarsaw@CNRI.Reston.VA.US wrote:
> >>>>> "Guido" == Guido van Rossum <guido@CNRI.Reston.VA.US> writes:
>...
> Guido> On the other hand, perhaps it would be better to deal with
> Guido> patches the same way as with bug reports -- the Jitterbug
> Guido> database isn't perfect, but it makes it possible to check
> Guido> regularly whether something has been dealt with or not,
> Guido> much better than a simple mailing list. (There are already
> Guido> lieutenants scanning the bugs traffic, so that part doesn't
> Guido> change.)
>
> Maybe then just use Jitterbug to collate patches. That's what a lot
> of my JPython users do.

Personally, I'm more comfortable knowing that I can email a patch (rather
than dropping it into a bug db), and that will get handled by a human. The
patch handlers could certainly use Jitterbug as arbitration, but I would
think the list itself would make that reasonably clear.

Note that "patches@python.org" could become THE place to submit patches.
Sure, Guido would get some patches still, but some of the load will drop
from his direct Inbox (yet he'd still get the patch as a subscriber). When
the patch handlers had a "final" patch, it would get sent straight to
Guido (with some "final" marker on it).

etc etc. I'm sure there is a lot discussion that can take place on the
exact mechanics. Until people will *volunteer*, I think the discussion of
mechanics can be postponed. No need for a peanut gallery here :-)

Cheers,
-g

--
Greg Stein, http://www.lyra.org/
Re: patch handling (was: Python 1.6 timing) [ In reply to ]
On Wed, 2 Feb 2000, Greg Stein wrote:

> > Maybe then just use Jitterbug to collate patches. That's what a lot
> > of my JPython users do.

<prefers e-mail to web-based>
> Note that "patches@python.org" could become THE place to submit patches.
<snip>

OK, I want to know one thing: is everyone comfortable with my suggestion
of a seperate list, with a reply-to: python-dev? Barry said he'd be
willing to hack it in, and everyone who talked seemed like this idea is
similar to what they have in mind. The sooner a consensus is reached, the
less patches Guido will have to deal with.

--
Moshe Zadka <mzadka@geocities.com>.
INTERNET: Learn what you know.
Share what you don't.
Re: patch handling (was: Python 1.6 timing) [ In reply to ]
On Thu, 3 Feb 2000, Moshe Zadka wrote:
>...
> OK, I want to know one thing: is everyone comfortable with my suggestion
> of a seperate list, with a reply-to: python-dev? Barry said he'd be

I don't advocate the reply-to (see my other email).

> willing to hack it in, and everyone who talked seemed like this idea is
> similar to what they have in mind. The sooner a consensus is reached, the
> less patches Guido will have to deal with.

It won't reduce his load unless we have actual volunteers that will truly
do some handling of the patches.

I'm assuming the current volunteer list is:

- Guido (he volunteers whether he wants to or not :-)
- Moshe (??)
- Greg in April

Others?

Cheers,
-g

--
Greg Stein, http://www.lyra.org/
Re: patch handling (was: Python 1.6 timing) [ In reply to ]
On Wed, 2 Feb 2000, Greg Stein wrote:

> I'm assuming the current volunteer list is:
>
> - Guido (he volunteers whether he wants to or not :-)
> - Moshe (??)

Part time -- I'll take responsibility for the patches that interest me.
There will likely be a few, and I *love* installing patches off the net,
just to test my security measures <0.3 wink>

> Others?

I assume you'll get a similar response from many people: hopefully,
for each patch it will either get booed automatically (hey! I just added
braces instead of indentation to the parser) or will interest someone.

--
Moshe Zadka <mzadka@geocities.com>.
INTERNET: Learn what you know.
Share what you don't.
Re: patch handling (was: Python 1.6 timing) [ In reply to ]
> OK, I want to know one thing: is everyone comfortable with my suggestion
> of a seperate list, with a reply-to: python-dev? Barry said he'd be
> willing to hack it in, and everyone who talked seemed like this idea is
> similar to what they have in mind. The sooner a consensus is reached, the
> less patches Guido will have to deal with.

Yes, let's do it. I actually think the reply-to is unnecessary to
start (it's just a nicety).

--Guido van Rossum (home page: http://www.python.org/~guido/)
Re: patch handling (was: Python 1.6 timing) [ In reply to ]
> I assume you'll get a similar response from many people: hopefully,
> for each patch it will either get booed automatically (hey! I just added
> braces instead of indentation to the parser) or will interest someone.

The thing here that makes me slightly uncomfortable is how to keep
track of patches that nobody picks up. a Jitterbug database would
nicely do this, but I agree that it's inconvenient and overkill for
other reasons. Perhaps we could use the "Linus Torvalds' inbox
algorithm"? (When it overflows he deletes everything; "if it was
important they'll send it again.")

--Guido van Rossum (home page: http://www.python.org/~guido/)
Re: patch handling (was: Python 1.6 timing) [ In reply to ]
On Wed, 2 Feb 2000, Guido van Rossum wrote:

> > I assume you'll get a similar response from many people: hopefully,
> > for each patch it will either get booed automatically (hey! I just added
> > braces instead of indentation to the parser) or will interest someone.
>
> The thing here that makes me slightly uncomfortable is how to keep
> track of patches that nobody picks up. a Jitterbug database would
> nicely do this, but I agree that it's inconvenient and overkill for
> other reasons. Perhaps we could use the "Linus Torvalds' inbox
> algorithm"? (When it overflows he deletes everything; "if it was
> important they'll send it again.")

1. This discussion is in the (as you put it) niceties are. You are
unlikely to get that many patches that it is an *immediate* problem.

2. mailman (what fun to me! I'm dumping work on Barry) could be hacked
(or hooked) into doing that: it can keep a list of all patches which never
got a reply in whatever list is being "replied to:" (that would
neccessitate developers to CC the list, at least on the first post, but
that's probably a good idea to do anyway) and send a mail message after a
week to a patch-submitter who hasn't gotten a reply with a notice to the
effect that nobody seems interested in it so he should make a bit more
noise.

3. Like in the CP4E BOF we're getting all geeky again (which is fine,
since we're all geeks). Just get something out of the door! Even a mailing
list with no policy at all to who sends to it is infinitely better then
Guido's mailbox, as much as we all respect that mailbox. We'll argue the
fine points of exactly how to score automatically irrelevant patches (and
I've got just the algorithm <0.9 wink>) later.


--
Moshe Zadka <mzadka@geocities.com>.
INTERNET: Learn what you know.
Share what you don't.
RE: patch handling (was: Python 1.6 timing) [ In reply to ]
[Greg Stein asks ...]
> ...
> It won't reduce his load unless we have actual volunteers that will truly
> do some handling of the patches.
>
> I'm assuming the current volunteer list is:
>
> - Guido (he volunteers whether he wants to or not :-)
> - Moshe (??)
> - Greg in April
>
> Others?

Sure -- but can't make a concrete time commitment. The time I've been able
to make so far amounted to changing three letters in a FAQ <wink/sigh>.

I hope the Jitterbug idea is adopted: clunky as it is, it's public,
searchable, has categories (so supports *some* rudimentary notion of
workflow), and doesn't tie up my 28.8 modem <wink>.
Re: patch handling (was: Python 1.6 timing) [ In reply to ]
From: "Guido van Rossum" <guido@CNRI.Reston.VA.US>
To: <python-dev@python.org>
Sent: Wednesday, February 02, 2000 4:50 PM
Subject: Re: [Python-Dev] patch handling (was: Python 1.6 timing)


> > I assume you'll get a similar response from many people: hopefully,
> > for each patch it will either get booed automatically (hey! I just added
> > braces instead of indentation to the parser) or will interest someone.
>
> The thing here that makes me slightly uncomfortable is how to keep
> track of patches that nobody picks up.

Sourceforge has a nice patch manager which allows a GUI'ish view of patches
in context, discarding/deferring/etc. The code is available and open
source.

--david
Re: patch handling (was: Python 1.6 timing) [ In reply to ]
On Wed, 2 Feb 2000, David Ascher wrote:

> Sourceforge has a nice patch manager which allows a GUI'ish view of patches
> in context, discarding/deferring/etc. The code is available and open
> source.

However, I think I'd still like to be able to
1. send patches by e-mail (I don't always want to fire up a browser)
2. receive patches by e-mail (think of it as select() instead of a busy
wait ;-)

If the patch manager allows that/can do that with a simple addition, I'm
for it.

--
Moshe Zadka <mzadka@geocities.com>.
INTERNET: Learn what you know.
Share what you don't.
Re: patch handling (was: Python 1.6 timing) [ In reply to ]
Another idea is to steal Ping's very cool idea of a 'nosy list'. If you
missed his short talk at IPC8, he has a system which is a frontend to their
bug database (but I think it would work well with patches). As far as I
understood, folks submit bugs via an email message. Each email message has
an _implicit_ mailing list, which is made up of all the people who either
'register' interest in the bug/patch, or who reply to the submission. That
way there is an automatic broadcasting of the discussion to those parties
interested in the topic at hand, and only those.

Maybe Ping can explain in more detail how it works. It seemed like a
brilliant idea to me.

--david
Re: patch handling (was: Python 1.6 timing) [ In reply to ]
> Another idea is to steal Ping's very cool idea of a 'nosy list'.

I missed it. Sounds an interesting long-term solution. I've heard
about a similar concept elsewhere: you never unsubscribe to a list,
each subject has its own list, and subjects just die.

--Guido van Rossum (home page: http://www.python.org/~guido/)
Re: patch handling (was: Python 1.6 timing) [ In reply to ]
On Wed, 2 Feb 2000, Guido van Rossum wrote:
> > Another idea is to steal Ping's very cool idea of a 'nosy list'.
>
> I missed it. Sounds an interesting long-term solution. I've heard
> about a similar concept elsewhere: you never unsubscribe to a list,
> each subject has its own list, and subjects just die.

Yup, that's the general approach. The short paper is at
http://www.lfw.org/ping/roundup.html; here is an excerpt
describing the mechanism:


a. New issues are always submitted by sending an e-mail message.
This message is saved in a mail spool attached to the
newly-created issue record, and copied to the relatively large
user community of the application so everyone knows the issue
has been raised.

b. All e-mail messages sent by Roundup have their "Reply-To" field
set to send mail back to Roundup, and have the issue's ID number
in the Subject field. So, any replies to the initial announcement
and subsequent threads are all received by Roundup and appended
to the spool.

c. Each issue has a "nosy list" of people interested in the issue.
Any mail tagged with the issue's ID number is copied to this list
of people, and any users found in the From:, To:, or Cc: fields
of e-mail about the issue are automatically added to the nosy
list. Whenever a user edits an item in the Web interface, they
are also added to the list.

The result is that no one ever has to worry about subscribing to
anything. Indicating interest in an issue is sufficient, and if you
want to bring someone new into the conversation, all you need to do
is Cc: a message to them. It turns out that no one ever has to worry
about unsubscribing, either: the nosy lists are so specific in scope
that the conversation tends to die down by itself when the issue is
resolved or people no longer find it sufficiently important. The
transparent capture of the mail spool attached to each issue also
yields a nice searchable knowledge repository over time.


In practice, this has worked fairly well for developers at ILM, and
no one has complained about missing mail they wanted or getting mail
they didn't want -- which, given the apathetic nature of programmers,
i suppose one could interpret as a positive empirical result.



-- ?!ng

"There's no point in being grown up if you can't be childish sometimes."
-- Dr. Who
Re: patch handling (was: Python 1.6 timing) [ In reply to ]
Moshe Zadka writes:
> OK, I want to know one thing: is everyone comfortable with my suggestion
> of a seperate list, with a reply-to: python-dev? Barry said he'd be
> willing to hack it in, and everyone who talked seemed like this idea is

I think this is the right approach.


-Fred

--
Fred L. Drake, Jr. <fdrake at acm.org>
Corporation for National Research Initiatives
Re: patch handling (was: Python 1.6 timing) [ In reply to ]
Greg Stein writes:
> - Guido (he volunteers whether he wants to or not :-)
> - Moshe (??)
> - Greg in April

I can certainly help out a bit, at least for small patches and
anything related to the documentation (including additions of
docstrings to module sources and the like).


-Fred

--
Fred L. Drake, Jr. <fdrake at acm.org>
Corporation for National Research Initiatives
Re: patch handling (was: Python 1.6 timing) [ In reply to ]
>>>>> "MZ" == Moshe Zadka <moshez@math.huji.ac.il> writes:

MZ> 2. mailman (what fun to me! I'm dumping work on Barry) could
MZ> be hacked (or hooked) into doing that:

Not a good strategy right now :)

Here's my proposal, from short term/easy to long term:

1. Create patches@python.org which will be the official advertised
address to send patches. This will be a Mailman mailing list to
which anybody can post, but to which subscriptions are closed.
Amount of work: trivial.

2. Create patches-discuss@python.org which will be the address to
discuss patches@python.org postings. We make Reply-To: for
patches@ be patches-discuss@
Amount of work: relatively small (for me to hack Mailman)

3. If someone will write a Python function to scan a string, returning
true or false as to whether it contains a patch, I will integrate
this into Mailman so that if a patch is found, it will be forwarded
to the Jitterbug database address. Ideally this filter would check
to be sure that the disclaimer text is included, but that's not
necessary. Guido (or someone) is still going to have to decide
whether the small text or a wet signature is necessary.
Amount of work: Fairly non-trivial for someone other than Barry
Not too bad for Barry to hack this into Mailman

4. When !?ng frees Roundup we look at adopting it. From everything
that I heard about it, it's OHS (official hot shit). I want, I
want! :)
Amount of work: none now, except for !?ng :)
Later, some for one of us CNRI'ers

5. Move the whole kit-and-kaboodle to SourceForge (or
server51.freshmeat.net which looks to provide many of the same
services). We cannot be the only project facing these same issues,
so let's leverage off of what others have done.
Amount of work: unknown, but I'm looking into it for Mailman

-Barry
Re: patch handling (was: Python 1.6 timing) [ In reply to ]
> 1. Create patches@python.org which will be the official advertised
> address to send patches. This will be a Mailman mailing list to
> which anybody can post, but to which subscriptions are closed.
> Amount of work: trivial.
>
> 2. Create patches-discuss@python.org which will be the address to
> discuss patches@python.org postings. We make Reply-To: for
> patches@ be patches-discuss@
> Amount of work: relatively small (for me to hack Mailman)

Why do we need two lists? For my own email processing I don't see how
it will make a difference. A reply-bot could check whether there's a
"Re:" in the subject or not to decide whether to send an
acknowledgement.

--Guido van Rossum (home page: http://www.python.org/~guido/)
Re: patch handling (was: Python 1.6 timing) [ In reply to ]
>>>>> "GvR" == Guido van Rossum <guido@python.org> writes:

GvR> Why do we need two lists? For my own email processing I
GvR> don't see how it will make a difference. A reply-bot could
GvR> check whether there's a "Re:" in the subject or not to decide
GvR> whether to send an acknowledgement.

Okay, fine with me.
RE: patch handling (was: Python 1.6 timing) [ In reply to ]
Barry:

> 5. Move the whole kit-and-kaboodle to SourceForge (or
> server51.freshmeat.net which looks to provide many of the same
> services). We cannot be the only project facing these same issues,
> so let's leverage off of what others have done.
> Amount of work: unknown, but I'm looking into it for Mailman

Given that VA Linux is buying Andover.net (parent of freshmeat.net), I doubt
the two will remain as competing solutions. =)

http://www.businesswire.com/cgi-bin/f_headline.cgi?day0/200340020&ticker=lnu
x|andn

--david
RE: patch handling (was: Python 1.6 timing) [ In reply to ]
>>>>> "DA" == David Ascher <dascher@mindspring.com> writes:

DA> Given that VA Linux is buying Andover.net (parent of
DA> freshmeat.net), I doubt the two will remain as competing
DA> solutions. =)

Indeed!
Re: patch handling (was: Python 1.6 timing) [ In reply to ]
Let me just note the whole thing sounds great! I'm for it.

On Thu, 3 Feb 2000, Barry A. Warsaw wrote:

> ... We cannot be the only project facing these same issues,
> so let's leverage off of what others have done.

As a point to think about, linux-kernel have a very non-high-tech solution
that works, but for some reason causes everyone shivers: high volume
mailing list, with patches and discussion of patches, and Linus's mailbox,
in which patches from known hackers are more streamlined. That's the
ultimate in flexibility ;-)

I don't know how many people here ever subscribed to linux-kernel, but as
someone who compiled a new kernel every week for a few months, I just want
to say that it works <0.6 wink>
--
Moshe Zadka <mzadka@geocities.com>.
INTERNET: Learn what you know.
Share what you don't.