From: Junio C Hamano <gitster@pobox.com>
To: git@vger.kernel.org
Subject: Maintaining "needswork" section of "What's (not) cooking"
Date: Sat, 23 Aug 2008 21:00:47 -0700 [thread overview]
Message-ID: <7vej4frrio.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <7v1w0ft750.fsf@gitster.siamese.dyndns.org> (Junio C. Hamano's message of "Sat, 23 Aug 2008 20:38:03 -0700")
Junio C Hamano <gitster@pobox.com> writes:
> Here is a list of issues/topics we saw on the mailing list but haven't
> resulted in anything queuable in 'pu' yet. They need further work by
> interested parties:
> ...
> [Stalled -- Needs Action to Proceed (or to be dropped)]
> ...
I am still experimenting with my own workflow with these parts.
With more people on the list sending patches recently, I still have enough
mental bandwidth to reject the initial rounds with comments/suggestions
for improvements, but I do not think it is realistic to expect me to keep
track of all of their progress on re-submission of improvements anymore (I
used to prod people privately asking how much they are making progress
after not hearing from people who received review comments).
It is a large loss for all of us when people do not come back with updated
patches after receiving review comments. Lost are their good idea based
on the real world needs. Time other people have volunteered to review
their initial submissions are also wasted when that happens.
I however do not intend to lower the patch acceptance standards. It is
not a workable approach to accept many new features implemented in a
substandard way or designed incoherently, expecting they will eventually
be cleaned up in-tree. Nobody will clean anything up after it is merged,
and when we give something to the end users, it becomes harder to change
its behaviour.
If a few people can volunteer to maintain a list that looks like the above
(not-quite) quoted ones, we may be able to give people more incentive to
keep polishing their patches in response to the reviews they received.
Other people can also offer help in topics they are interested in, and we
may see more topics through their completion as the result.
Thoughts?
.
next prev parent reply other threads:[~2008-08-24 4:03 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-24 3:38 What's cooking in git.git (Aug 2008, #07; Sat, 23) Junio C Hamano
2008-08-24 4:00 ` Junio C Hamano [this message]
2008-08-24 18:12 ` Johannes Schindelin
2008-08-24 19:16 ` Junio C Hamano
2008-08-24 20:24 ` Junio C Hamano
2008-08-24 20:27 ` [PATCH 1/3] daemon.c: minor style fixup Junio C Hamano
2008-08-24 20:27 ` [PATCH 2/3] daemon.c: simplify add_child() and kill_some_child() logic Junio C Hamano
2008-08-24 20:33 ` [PATCH 3/3] daemon.c: make sure kill_some_child() really kills somebody Junio C Hamano
2008-08-25 16:32 ` What's cooking in git.git (Aug 2008, #07; Sat, 23) Stephen R. van den Berg
2008-08-25 20:19 ` Junio C Hamano
2008-08-25 21:27 ` Stephen R. van den Berg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vej4frrio.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).