You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Rodent of Unusual Size <Ke...@Golux.Com> on 1998/01/11 17:07:21 UTC
[POLL] apachen/patches directory
I'm calling the question on the putting-patches-into-a-directory
issue. The specific details (such as where it should be, what it
should be called, whether "Subject: [PATCH]" messages should
be auto-committed there, and whether CVS messages about commits
to that directory should be burnt-before-sent, among others) can be
worked out later.
For now, let's just decide, as a group, if we're going to try the
experiment, as a group.
So.. the question is, shall a directory be created somewhere in
the source tree so patches can be made available through cvs update
rather than requiring separate mail to new-httpd? Votes, please.
#ken P-)}
Re: [POLL] apachen/patches directory
Posted by Martin Kraemer <Ma...@mch.sni.de>.
On Sun, Jan 11, 1998 at 05:48:19PM -0500, Jim Jagielski wrote:
>
> Yes... with c-t-r, this becomes a good backup plan.
Yes it has the advantage that patches won't get lost (lost in a huge
number of discussion mails! 400+ mails over the last few days! ;-)
I understand it then that a submitter
with CVS privs without CVS privs
============== =================
1) submits a [PATCH] to new-httpd submits a [PATCH] to new-httpd
* file is filtered by "[PATCH]" pattern
* file is stored in directory
* file is committed (cvs add / cvs ci)
??? (with cvs mail suppressed)
??? * file is forwarded to new-httpd or new patches list
(otherwise how could the discussion take place?)
2) (waits for no vetos?) asks a core member to commit it
3) commits core member commits
and updates STATUS / CHANGES
* commited files are sent to apache-cvs
* file is removed (cvs rm / cvs ci)
??? (with cvs mail suppressed)
What happens at the "???" markes places?
Martin
--
| S I E M E N S | <Ma...@mch.sni.de> | Siemens Nixdorf
| ------------- | Voice: +49-89-636-46021 | Informationssysteme AG
| N I X D O R F | FAX: +49-89-636-44994 | 81730 Munich, Germany
~~~~~~~~~~~~~~~~My opinions only, of course; pgp key available on request
Re: [POLL] apachen/patches directory
Posted by Dean Gaudet <dg...@arctic.org>.
I'm 0 on it as well, I'm not going to veto it.
Dean
On Sun, 11 Jan 1998, Randy Terbush wrote:
> On Sun, Jan 11, 1998 at 02:27:57PM -0500, Rodent of Unusual Size wrote:
> > Randy Terbush wrote:
> > >
> > > On Sun, Jan 11, 1998 at 01:23:13PM -0500, Rodent of Unusual Size wrote:
> > > >
> > > > Is this any clearer?
> > >
> > > Yes. More clear. Seems unnecessary if we are going to commit-then-review.
> > > Your plan above might be an alternative to revert to if we find that
> > > the commit-then-review method is not working?
> >
> > Sure, but even under those conditions it has a place. You know, the
> > controversial or "please double-check me" submissions, and submissions
> > from people who don't have CVS access.
> >
> > So.. does this mean you're +1 on it, then?
>
> Ken, I'm 0 on this issue. Seems like misplaced energy given the state
> of a few other items in dev.apache.org but don't let that discourage you.
> I'm kind of set in my ways if you get my drift. :-)
>
>
Re: [POLL] apachen/patches directory
Posted by Randy Terbush <ra...@covalent.net>.
On Sun, Jan 11, 1998 at 02:27:57PM -0500, Rodent of Unusual Size wrote:
> Randy Terbush wrote:
> >
> > On Sun, Jan 11, 1998 at 01:23:13PM -0500, Rodent of Unusual Size wrote:
> > >
> > > Is this any clearer?
> >
> > Yes. More clear. Seems unnecessary if we are going to commit-then-review.
> > Your plan above might be an alternative to revert to if we find that
> > the commit-then-review method is not working?
>
> Sure, but even under those conditions it has a place. You know, the
> controversial or "please double-check me" submissions, and submissions
> from people who don't have CVS access.
>
> So.. does this mean you're +1 on it, then?
Ken, I'm 0 on this issue. Seems like misplaced energy given the state
of a few other items in dev.apache.org but don't let that discourage you.
I'm kind of set in my ways if you get my drift. :-)
Re: [POLL] apachen/patches directory
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Randy Terbush wrote:
>
> On Sun, Jan 11, 1998 at 01:23:13PM -0500, Rodent of Unusual Size wrote:
> >
> > Is this any clearer?
>
> Yes. More clear. Seems unnecessary if we are going to commit-then-review.
> Your plan above might be an alternative to revert to if we find that
> the commit-then-review method is not working?
Sure, but even under those conditions it has a place. You know, the
controversial or "please double-check me" submissions, and submissions
from people who don't have CVS access.
So.. does this mean you're +1 on it, then?
#ken P-)}
Re: [POLL] apachen/patches directory
Posted by Randy Terbush <ra...@covalent.net>.
On Sun, Jan 11, 1998 at 01:23:13PM -0500, Rodent of Unusual Size wrote:
> Randy Terbush wrote:
> >
> > > > * This setup should not even consider auto commiting.
> > >
> > > Not arguing, but why not? Just curious.
> >
> > Mainly because it opens up these very fragile repositories to potential
> > abuse. Since we have the ability to commit directly to the repository,
> > why add another step that would require us to create a patch, mail it
> > to an auto committer, and hope that something doesn't go amiss and lock
> > up the repository until someone gets around to fixing it.
>
> No, no - that auto-committing step is so people who *don't* have CVS
> access can send mail to new-httpd with "Subject: [PATCH]" and have
> the message committed to the *patches* directory. No auto-committing
> of patches against the source.
>
> > Perhaps I don't completely understand what you want to implement.
> > Seems that the commit messages currently provide much of what you
> > describe. I'm understanding that you are wanting to commit these
> > commit messages to yet another CVS repository.
>
> No, not committing the commit messages. Rather than generating a patch
> and mailing it to new-httpd, and requiring people to extract it, you
> instead generate the patch, put it in apachen/needsvoting, and commit
> it *there* with cvs add. Then the commit message serves as the "here's
> a patch" message instead of a separate manual one sent to new-httpd.
> Rather than having to extract the patch from mail, people can just
> cvs update and then "patch <apachen/needsvoting/001-deans_latest.patch".
> The patches under consideration are kept in the repository so you
> get them along with any other updated stuff. The CVS message from
> the commitment to the patch directory (not to the source) becomes
> informational rather than integral.
>
> > Simply filtering cvs-commits with procmail to a local mailbox. The
> > mailbox is indexed with glimpse to allow me to search it when I
> > wish.
>
> In that case the only change would be that you'd see a minimum of
> three CVS messages: the commitment of the patch to the patches
> directory, the application of it to the sources (if approved; what
> we have now), and the cvs rm of the patch from the patch directory
> after it has been applied. Since the changes are the first and
> last messages (plus any that modified the patch in the patch
> directory before it was applied to the source), all would mention
> the patch directory in the subject line, which should make tailoring
> simple.
>
> Is this any clearer?
Yes. More clear. Seems unnecessary if we are going to commit-then-review.
Your plan above might be an alternative to revert to if we find that
the commit-then-review method is not working?
Re: [POLL] apachen/patches directory
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Randy Terbush wrote:
>
> > > * This setup should not even consider auto commiting.
> >
> > Not arguing, but why not? Just curious.
>
> Mainly because it opens up these very fragile repositories to potential
> abuse. Since we have the ability to commit directly to the repository,
> why add another step that would require us to create a patch, mail it
> to an auto committer, and hope that something doesn't go amiss and lock
> up the repository until someone gets around to fixing it.
No, no - that auto-committing step is so people who *don't* have CVS
access can send mail to new-httpd with "Subject: [PATCH]" and have
the message committed to the *patches* directory. No auto-committing
of patches against the source.
> Perhaps I don't completely understand what you want to implement.
> Seems that the commit messages currently provide much of what you
> describe. I'm understanding that you are wanting to commit these
> commit messages to yet another CVS repository.
No, not committing the commit messages. Rather than generating a patch
and mailing it to new-httpd, and requiring people to extract it, you
instead generate the patch, put it in apachen/needsvoting, and commit
it *there* with cvs add. Then the commit message serves as the "here's
a patch" message instead of a separate manual one sent to new-httpd.
Rather than having to extract the patch from mail, people can just
cvs update and then "patch <apachen/needsvoting/001-deans_latest.patch".
The patches under consideration are kept in the repository so you
get them along with any other updated stuff. The CVS message from
the commitment to the patch directory (not to the source) becomes
informational rather than integral.
> Simply filtering cvs-commits with procmail to a local mailbox. The
> mailbox is indexed with glimpse to allow me to search it when I
> wish.
In that case the only change would be that you'd see a minimum of
three CVS messages: the commitment of the patch to the patches
directory, the application of it to the sources (if approved; what
we have now), and the cvs rm of the patch from the patch directory
after it has been applied. Since the changes are the first and
last messages (plus any that modified the patch in the patch
directory before it was applied to the source), all would mention
the patch directory in the subject line, which should make tailoring
simple.
Is this any clearer?
#ken P-)}
Re: [POLL] apachen/patches directory
Posted by Randy Terbush <ra...@covalent.net>.
On Sun, Jan 11, 1998 at 12:08:45PM -0500, Rodent of Unusual Size wrote:
> Randy Terbush wrote:
> >
> > On Sun, Jan 11, 1998 at 11:07:21AM -0500, Rodent of Unusual Size wrote:
> > >
> > > So.. the question is, shall a directory be created somewhere in
> > > the source tree so patches can be made available through cvs update
> > > rather than requiring separate mail to new-httpd? Votes, please.
> >
> > I support doing anything as a group that will help us meet our goals.
>
> It's unclear whether this will meet that metric; I think we can't tell
> until we try it.
>
> > * This setup should not even consider auto commiting.
>
> Not arguing, but why not? Just curious.
Mainly because it opens up these very fragile repositories to potential
abuse. Since we have the ability to commit directly to the repository,
why add another step that would require us to create a patch, mail it
to an auto committer, and hope that something doesn't go amiss and lock
up the repository until someone gets around to fixing it.
> > * I'm not sure I understand the usefulness of CVS in this scenario.
>
> My belief is that it will simplify things for some people, such as
> Dean and myself. It may make things more complicated for others -
> I don't know. By having it in CVS, the patch gets downloaded to
> the working area automatically by an update - without having to futz
> with extracting mail and moving the extracted file around. Also
> by having it in CVS, the currently-manual "here's a patch" message to
> the group is replaced by the automatic notification generated when
> the patch is committed to CVS. And as Jim pointed out, a commentary
> can be added above the "Index" line, since patch with ignore it.
> Self-documenting!
Perhaps I don't completely understand what you want to implement.
Seems that the commit messages currently provide much of what you
describe. I'm understanding that you are wanting to commit these
commit messages to yet another CVS repository.
> That's my opinion of how it will benefit *some* of us. There may well
> be disadvantages I haven't spotted yet. ;->
>
> > * As long as this system does not require me to ditch the Email
> > filtering method that is working for me, go for it.
>
> Without knowing what your filtering mechanism is I obviously
> can't comment on that. It makes sense that a change shouldn't
> drastically affect this, though, since other people probably
> filter in a similar (if not identical) manner. So.. what *is*
> your filtering method so we can make sure this change (if voted)
> doesn't negatively affect you?
Simply filtering cvs-commits with procmail to a local mailbox. The
mailbox is indexed with glimpse to allow me to search it when I
wish.
Re: [POLL] apachen/patches directory
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Randy Terbush wrote:
>
> On Sun, Jan 11, 1998 at 11:07:21AM -0500, Rodent of Unusual Size wrote:
> >
> > So.. the question is, shall a directory be created somewhere in
> > the source tree so patches can be made available through cvs update
> > rather than requiring separate mail to new-httpd? Votes, please.
>
> I support doing anything as a group that will help us meet our goals.
It's unclear whether this will meet that metric; I think we can't tell
until we try it.
> * This setup should not even consider auto commiting.
Not arguing, but why not? Just curious.
> * I'm not sure I understand the usefulness of CVS in this scenario.
My belief is that it will simplify things for some people, such as
Dean and myself. It may make things more complicated for others -
I don't know. By having it in CVS, the patch gets downloaded to
the working area automatically by an update - without having to futz
with extracting mail and moving the extracted file around. Also
by having it in CVS, the currently-manual "here's a patch" message to
the group is replaced by the automatic notification generated when
the patch is committed to CVS. And as Jim pointed out, a commentary
can be added above the "Index" line, since patch with ignore it.
Self-documenting!
That's my opinion of how it will benefit *some* of us. There may well
be disadvantages I haven't spotted yet. ;->
> * As long as this system does not require me to ditch the Email
> filtering method that is working for me, go for it.
Without knowing what your filtering mechanism is I obviously
can't comment on that. It makes sense that a change shouldn't
drastically affect this, though, since other people probably
filter in a similar (if not identical) manner. So.. what *is*
your filtering method so we can make sure this change (if voted)
doesn't negatively affect you?
#ken P-)}
Re: [POLL] apachen/patches directory
Posted by Randy Terbush <ra...@covalent.net>.
On Sun, Jan 11, 1998 at 11:07:21AM -0500, Rodent of Unusual Size wrote:
> I'm calling the question on the putting-patches-into-a-directory
> issue. The specific details (such as where it should be, what it
> should be called, whether "Subject: [PATCH]" messages should
> be auto-committed there, and whether CVS messages about commits
> to that directory should be burnt-before-sent, among others) can be
> worked out later.
>
> For now, let's just decide, as a group, if we're going to try the
> experiment, as a group.
>
> So.. the question is, shall a directory be created somewhere in
> the source tree so patches can be made available through cvs update
> rather than requiring separate mail to new-httpd? Votes, please.
I support doing anything as a group that will help us meet our goals.
* This setup should not even consider auto commiting.
* I'm not sure I understand the usefulness of CVS in this scenario.
* As long as this system does not require me to ditch the Email
filtering method that is working for me, go for it.
Re: [POLL] apachen/patches directory
Posted by Paul Sutton <pa...@eu.c2.net>.
On Sun, 11 Jan 1998, Rodent of Unusual Size wrote:
> I'm calling the question on the putting-patches-into-a-directory
> issue. The specific details (such as where it should be, what it
> should be called, whether "Subject: [PATCH]" messages should
> be auto-committed there, and whether CVS messages about commits
> to that directory should be burnt-before-sent, among others) can be
> worked out later.
What's "burnt-before-sent" mean? Commit messages to the patches directory
are surely vital so that the committed can explain the purpose and need
for their patch? If not how do we match up the patch against the
discussion on new-httpd, unless the patcher manually sends their patch to
the list as well, with the description?
> So.. the question is, shall a directory be created somewhere in
> the source tree so patches can be made available through cvs update
> rather than requiring separate mail to new-httpd? Votes, please.
0. I'm not convinced that this is necessary. But provided that the commit
message is used to contain the full description of the patch and why it is
necessary, and that the commits go to new-httpd, then I'm not against it
either. I like the optionality of the question above -- presumably people
can still mail thie patches to new-httpd just like now?
//pcs