headers
David Harrington | 13 Sep 2010 20:10
Picon

wiki-trac

Hi,

Can we get some sort of SCCS lock capability on wiki-trac?
I just entered a BOF Request, which was rather slow and time-consuming
given the arcane formatting we use, and the difficulty of cutting and
pasting due to the way the cursor keeps repositioning the page while
you edit.
And somebody went in while I was previewing my changes, did an edit,
and I lost all my work.
I cannot tell when somebody else is editing, so I don't know when it
is safe to go back and do my edits again, so that I don't interrupt
their editing session.

David Harrington
Director, IETF Transport Area
ietfdbh <at> comcast.net (preferred for ietf)
dbharrington <at> huaweisymantec.com
+1 603 828 1401 (cell)
Permalink | Reply | 3 comments |
headers
David Harrington | 14 Sep 2010 20:19
Picon

email aliases

Hi,

any chance we can migrate the aliases <at> tools.ietf.org to
aliases <at> ietf.org, so I don't have to keep trying to remember which
aliases fall within which domain? 

I getting old, and my memory ain't what it is used to be. I'm getting
tired of bounced messages because we have two different domains to do
alias resolution.

David Harrington
Director, IETF Transport Area
ietfdbh <at> comcast.net (preferred for ietf)
dbharrington <at> huaweisymantec.com
+1 603 828 1401 (cell)
Permalink | Reply | 5 comments |
headers
Henrik Levkowetz | 16 Sep 2010 12:52

Re: wiki-trac

Hi David,

On 2010-09-13 20:10 David Harrington said:
> Hi,
> 
> Can we get some sort of SCCS lock capability on wiki-trac?
> I just entered a BOF Request, which was rather slow and time-consuming
> given the arcane formatting we use, and the difficulty of cutting and
> pasting due to the way the cursor keeps repositioning the page while
> you edit.
> And somebody went in while I was previewing my changes, did an edit,
> and I lost all my work.

Ouch.  But maybe not necessary, see below...

> I cannot tell when somebody else is editing, so I don't know when it
> is safe to go back and do my edits again, so that I don't interrupt
> their editing session.

The handling already implemented in Trac is to 1) keep the edited
text in a text box in the view which tells you that the page has
been modified by somebody else, so you can copy it out and then fix
things in a new edit, and 2) at the bottom of the page, provide
'Merge changes' button which you can use to merge in your changes to
the modified page.  I think this is a reasonable handling?

Best,

	Henrik
(Continue reading)

Permalink | Reply | 2 comments |
headers
Henrik Levkowetz | 16 Sep 2010 12:57

Re: email aliases

Hi David,

On 2010-09-14 20:19 David Harrington said:
> Hi,
> 
> any chance we can migrate the aliases <at> tools.ietf.org to
> aliases <at> ietf.org, so I don't have to keep trying to remember which
> aliases fall within which domain? 
> 
> I getting old, and my memory ain't what it is used to be. I'm getting
> tired of bounced messages because we have two different domains to do
> alias resolution.

I don't mind in the least, quite the other way around.  But somebody
has to do the work, I've got a backlog which is ploughing me under and
I'm trying to prioritise as best I can...

Because things are continually changing, the alias lists have to be
re-generated frequently (currently it's done hourly) and the main IETF
mail server doesn't have the infrastructure (files, directories, etc.)
which the current scripts expect.  This means that new scripts need to
be written to generate the alias lists from the database, rather than
from the flat text files which are used on the tools servers.

Best,

	Henrik
Permalink | Reply | 4 comments |
headers
David Harrington | 16 Sep 2010 16:49
Picon

Re: wiki-trac

Hi Henrik,

Well, I saw the merge button, and I am used to CVS merge handling.
But I have no experience with Trac merge handling, and bluntly I
didn't trust it because I lacked experience with it.
If I had done the merge it would have occurred while somebody else was
apparently actively editing the same page. Given that the merge is
calculated based on a snapshot of the page at the time of the merge,
if it is a moving target, I'm not sure how well the merge would work.

I did actually cut and paste my work into a file so I didn't lose it.
But I could not tell when somebody else was editing, so I could not
tell when it was safe for me to re-submit without causing a merge
problem. (and I think the edits being done did not overlap with mine,
which I think would have been fine with a CVS system).

A little indicator that somebody else was actively editing the page
would have been wonderful.

But, given the frequency that this problem occurs, it certainly is not
one of the higher priority items.

Thanks,
dbh

> -----Original Message-----
> From: Henrik Levkowetz [mailto:henrik <at> levkowetz.com] 
> Sent: Thursday, September 16, 2010 6:52 AM
> To: David Harrington
> Cc: tools-discuss <at> ietf.org
(Continue reading)

Permalink | Reply | 1 comment |
headers
Henrik Levkowetz | 16 Sep 2010 17:27

Re: wiki-trac

Hi David,

On 2010-09-16 16:49 David Harrington said:
> Hi Henrik,
> 
> Well, I saw the merge button, and I am used to CVS merge handling.
> But I have no experience with Trac merge handling, and bluntly I
> didn't trust it because I lacked experience with it.

Ah, well.  The only way to get experience is to try it.  Trac maintains
all back revisions, so it's easy enough to revert to an earlier version
if the merge proves catastrophic.

> If I had done the merge it would have occurred while somebody else was
> apparently actively editing the same page.

Not necessarily so; you received the conflict warning because someone
else had completed an edit meanwhile.  If you had done your merge, and
they had continued to work on another edit, they would have received
a conflict message and merge offer in turn, which should also have turned
out well if you hadn't been editing the same piece of text...

> Given that the merge is
> calculated based on a snapshot of the page at the time of the merge,
> if it is a moving target, I'm not sure how well the merge would work.

The merge is between the new version and the most recently committed
version; I think it should be just fine as long as the edits don't
overlap.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dan Wing | 18 Sep 2010 22:15
Picon
Favicon

Re: email aliases

> -----Original Message-----
> From: tools-discuss-bounces <at> ietf.org [mailto:tools-discuss-
> bounces <at> ietf.org] On Behalf Of Henrik Levkowetz
> Sent: Thursday, September 16, 2010 3:58 AM
> To: David Harrington
> Cc: tools-discuss <at> ietf.org
> Subject: Re: [Tools-discuss] email aliases
> 
> Hi David,
> 
> On 2010-09-14 20:19 David Harrington said:
> > Hi,
> >
> > any chance we can migrate the aliases <at> tools.ietf.org to
> > aliases <at> ietf.org, so I don't have to keep trying to remember which
> > aliases fall within which domain?
> >
> > I getting old, and my memory ain't what it is used to be. I'm getting
> > tired of bounced messages because we have two different domains to do
> > alias resolution.
> 
> I don't mind in the least, quite the other way around.  But somebody
> has to do the work, I've got a backlog which is ploughing me under and
> I'm trying to prioritise as best I can...
> 
> Because things are continually changing, the alias lists have to be
> re-generated frequently (currently it's done hourly) and the main IETF
> mail server doesn't have the infrastructure (files, directories, etc.)
> which the current scripts expect.  This means that new scripts need to
> be written to generate the alias lists from the database, rather than
(Continue reading)

Permalink | Reply | 3 comments |
headers
Henrik Levkowetz | 20 Sep 2010 11:02

Re: email aliases

Hi Dan,

Adding Cc: to Glen to this thread, for possible action.

On 2010-09-18 22:15 Dan Wing said:
...
>> Because things are continually changing, the alias lists have to be
>> re-generated frequently (currently it's done hourly) and the main IETF
>> mail server doesn't have the infrastructure (files, directories, etc.)
>> which the current scripts expect.  This means that new scripts need to
>> be written to generate the alias lists from the database, rather than
>> from the flat text files which are used on the tools servers.
> 
> Could the main ietf.org servers simply route messages to draft-*
> and *-wg (etc.) to tools.ietf.org?

Yes, this is possible, and it's actually already being done for the *-chairs <at> 
aliases.  But this has its own problems, which has become apparent for the
chairs aliases on several occasions.  But if people think it's better than
the current situation, I think it could be done.

> They appear to be running postfix 
> and a virtual alias map should do the trick, something like this,
> 
>   /^draft-(.*) <at> ietf.org$/   draft-${1} <at> tools.ietf.org
>   /^(.*)-chairs <at> ietf.org$/  ${1}-chairs <at> tools.ietf.org
> 
> and so on.  The tools server would get the messages and deliver them
> or bounce them, as necessary.  Only drawback seems to be NDN blow-
> back because ietf.org won't reject the messages for invalid
(Continue reading)

Permalink | Reply | 2 comments |
headers
Glen Barney | 20 Sep 2010 17:39

Re: email aliases

I'm good with whatever!  Of course, I look to Henrik to steer this
effort, but he knows he will have whatever support and work from me that
he desires!

Glen

On 9/20/2010 2:02 AM, Henrik Levkowetz wrote:
> Hi Dan,
> 
> Adding Cc: to Glen to this thread, for possible action.
> 
> On 2010-09-18 22:15 Dan Wing said:
> ...
>>> Because things are continually changing, the alias lists have to be
>>> re-generated frequently (currently it's done hourly) and the main IETF
>>> mail server doesn't have the infrastructure (files, directories, etc.)
>>> which the current scripts expect.  This means that new scripts need to
>>> be written to generate the alias lists from the database, rather than
>>> from the flat text files which are used on the tools servers.
>>
>> Could the main ietf.org servers simply route messages to draft-*
>> and *-wg (etc.) to tools.ietf.org?
> 
> Yes, this is possible, and it's actually already being done for the *-chairs <at> 
> aliases.  But this has its own problems, which has become apparent for the
> chairs aliases on several occasions.  But if people think it's better than
> the current situation, I think it could be done.
> 
>> They appear to be running postfix 
>> and a virtual alias map should do the trick, something like this,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dan Wing | 20 Sep 2010 19:43
Picon
Favicon

Re: email aliases

> -----Original Message-----
> From: Henrik Levkowetz [mailto:henrik <at> levkowetz.com]
> Sent: Monday, September 20, 2010 2:02 AM
> To: Dan Wing
> Cc: 'David Harrington'; tools-discuss <at> ietf.org; Glen
> Subject: Re: [Tools-discuss] email aliases
> 
> Hi Dan,
> 
> Adding Cc: to Glen to this thread, for possible action.
> 
> On 2010-09-18 22:15 Dan Wing said:
> ...
> >> Because things are continually changing, the alias lists have to be
> >> re-generated frequently (currently it's done hourly) and the main
> IETF
> >> mail server doesn't have the infrastructure (files, directories,
> etc.)
> >> which the current scripts expect.  This means that new scripts need
> to
> >> be written to generate the alias lists from the database, rather
> than
> >> from the flat text files which are used on the tools servers.
> >
> > Could the main ietf.org servers simply route messages to draft-*
> > and *-wg (etc.) to tools.ietf.org?
> 
> Yes, this is possible, and it's actually already being done for the *-
> chairs <at> 
> aliases.  But this has its own problems, which has become apparent for
(Continue reading)

Permalink | Reply | 0 comments |

Gmane