Re: [Issue 3096] Default perl script for notifying commits by email should be improved

[Erik Huelsmann <eh...@gmail.com>]

On Sat, Jun 7, 2008 at 1:42 PM,  <ma...@tigris.org> wrote:
> http://subversion.tigris.org/issues/show_bug.cgi?id=3096
>
>
>
> User maxb changed the following:
>
>                What    |Old value                 |New value
> ================================================================================
>        Target milestone|---                       |nonblocking
> --------------------------------------------------------------------------------

Or should we -instead- endorse mailer.py? I'm not at all that happy
with maintaining duplicate functionality. Within the Subversion core
we don't have much choice (as things stand), but do we need to do so
when the alternative is obviously so much more advanced?

Bye,

Erik.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: [Issue 3096] Default perl script for notifying commits by email should be improved

[Blair Zajac <bl...@orcaware.com>]

C. Michael Pilato wrote:
> Blair Zajac wrote:
>> Max Bowsher wrote:
>>> Karl Fogel wrote:
>>>> Blair Zajac <bl...@orcaware.com> writes:
>>>>>> Yes, I would totally be happy with binning commit-email.pl and 
>>>>>> shipping
>>>>>> a single endorsed solution for commit emails.
>>>>> +1 on using mailer.py and deprecating commit-email.pl.
>>>> I'm late to the party, but: +1 here too.
>>>
>>> The outstanding question then, is what timeline do we choose to follow
>>> for deprecation/removal.
>>>
>>> Given that it does _not_ use the bindings, just svnlook, the coupling to
>>>  a specific Subversion version is very loose indeed. Therefore, users of
>>> the script will not be prevented from upgrading, if we abruptly stop
>>> maintaining it. Therefore I'm inclined to slip a deprecation notice into
>>> 1.5.0, and plan on removing it before 1.6.
>>
>> I'm not suggesting we remove the script since somebody may want it, 
>> just we won't put any effort into it and we should put a large message 
>> in it saying, please improve mailer.py instead.
> 
> Move it to contrib/ ?
> 

+1.  r31755

Blair


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: [Issue 3096] Default perl script for notifying commits by email should be improved

["C. Michael Pilato" <cm...@collab.net>]

Blair Zajac wrote:
> Max Bowsher wrote:
>> Karl Fogel wrote:
>>> Blair Zajac <bl...@orcaware.com> writes:
>>>>> Yes, I would totally be happy with binning commit-email.pl and 
>>>>> shipping
>>>>> a single endorsed solution for commit emails.
>>>> +1 on using mailer.py and deprecating commit-email.pl.
>>> I'm late to the party, but: +1 here too.
>>
>> The outstanding question then, is what timeline do we choose to follow
>> for deprecation/removal.
>>
>> Given that it does _not_ use the bindings, just svnlook, the coupling to
>>  a specific Subversion version is very loose indeed. Therefore, users of
>> the script will not be prevented from upgrading, if we abruptly stop
>> maintaining it. Therefore I'm inclined to slip a deprecation notice into
>> 1.5.0, and plan on removing it before 1.6.
> 
> I'm not suggesting we remove the script since somebody may want it, just 
> we won't put any effort into it and we should put a large message in it 
> saying, please improve mailer.py instead.

Move it to contrib/ ?

-- 
C. Michael Pilato <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Re: [Issue 3096] Default perl script for notifying commits by email should be improved

[Blair Zajac <bl...@orcaware.com>]

Max Bowsher wrote:
> Karl Fogel wrote:
>> Blair Zajac <bl...@orcaware.com> writes:
>>>> Yes, I would totally be happy with binning commit-email.pl and shipping
>>>> a single endorsed solution for commit emails.
>>> +1 on using mailer.py and deprecating commit-email.pl.
>> I'm late to the party, but: +1 here too.
> 
> The outstanding question then, is what timeline do we choose to follow
> for deprecation/removal.
> 
> Given that it does _not_ use the bindings, just svnlook, the coupling to
>  a specific Subversion version is very loose indeed. Therefore, users of
> the script will not be prevented from upgrading, if we abruptly stop
> maintaining it. Therefore I'm inclined to slip a deprecation notice into
> 1.5.0, and plan on removing it before 1.6.

I'm not suggesting we remove the script since somebody may want it, just we 
won't put any effort into it and we should put a large message in it saying, 
please improve mailer.py instead.

> And, I've just noticed we have a commit-email.rb as well!
> That one *does* use the swig bindings. I'm not sure what to suggest there.

I don't see the bindings matter, given we work hard to maintain binary 
compatibility between 1.x releases and the bindings should do the same.

Blair

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: [Issue 3096] Default perl script for notifying commits by email should be improved

[Max Bowsher <ma...@ukf.net>]

Karl Fogel wrote:
> Blair Zajac <bl...@orcaware.com> writes:
>>> Yes, I would totally be happy with binning commit-email.pl and shipping
>>> a single endorsed solution for commit emails.
>> +1 on using mailer.py and deprecating commit-email.pl.
> 
> I'm late to the party, but: +1 here too.

The outstanding question then, is what timeline do we choose to follow
for deprecation/removal.

Given that it does _not_ use the bindings, just svnlook, the coupling to
 a specific Subversion version is very loose indeed. Therefore, users of
the script will not be prevented from upgrading, if we abruptly stop
maintaining it. Therefore I'm inclined to slip a deprecation notice into
1.5.0, and plan on removing it before 1.6.



And, I've just noticed we have a commit-email.rb as well!
That one *does* use the swig bindings. I'm not sure what to suggest there.


Max.

Re: [Issue 3096] Default perl script for notifying commits by email should be improved

[Karl Fogel <kf...@red-bean.com>]

Blair Zajac <bl...@orcaware.com> writes:
>> Yes, I would totally be happy with binning commit-email.pl and shipping
>> a single endorsed solution for commit emails.
>
> +1 on using mailer.py and deprecating commit-email.pl.

I'm late to the party, but: +1 here too.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: [Issue 3096] Default perl script for notifying commits by email should be improved

[Blair Zajac <bl...@orcaware.com>]

Max Bowsher wrote:
> John Peacock wrote:
>> Erik Huelsmann wrote:
>>> Or should we -instead- endorse mailer.py? I'm not at all that happy
>>> with maintaining duplicate functionality. Within the Subversion core
>>> we don't have much choice (as things stand), but do we need to do so
>>> when the alternative is obviously so much more advanced?
>> I agree - why does Subversion need to provide and maintain more than one
>> sample post-commit mailer?  It's nice to have *something* included in
>> the core package, but when I tried to improve commit-email.pl.in, I
>> found to be not very easily rewritten (no jokes about all Perl code
>> being that way). ;-)
>>
>> We could also just mention SVN::Notify for the Perl-inclined, which is
>> at least as advanced and flexible as mailer.py (plus I have some
>> proprietary interest in that one, since I have several subclasses of it
>> that I have written/maintain).
> 
> Well, I'm a Python person anyway, so I'm a bit biased, but...
> 
> Yes, I would totally be happy with binning commit-email.pl and shipping
> a single endorsed solution for commit emails.

+1 on using mailer.py and deprecating commit-email.pl.

Blair


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: [Issue 3096] Default perl script for notifying commits by email should be improved

[Max Bowsher <ma...@ukf.net>]

John Peacock wrote:
> Erik Huelsmann wrote:
>> Or should we -instead- endorse mailer.py? I'm not at all that happy
>> with maintaining duplicate functionality. Within the Subversion core
>> we don't have much choice (as things stand), but do we need to do so
>> when the alternative is obviously so much more advanced?
> 
> I agree - why does Subversion need to provide and maintain more than one
> sample post-commit mailer?  It's nice to have *something* included in
> the core package, but when I tried to improve commit-email.pl.in, I
> found to be not very easily rewritten (no jokes about all Perl code
> being that way). ;-)
> 
> We could also just mention SVN::Notify for the Perl-inclined, which is
> at least as advanced and flexible as mailer.py (plus I have some
> proprietary interest in that one, since I have several subclasses of it
> that I have written/maintain).

Well, I'm a Python person anyway, so I'm a bit biased, but...

Yes, I would totally be happy with binning commit-email.pl and shipping
a single endorsed solution for commit emails.

Max.

Re: [Issue 3096] Default perl script for notifying commits by email should be improved

[John Peacock <jp...@tigris.org>]

Erik Huelsmann wrote:
> Or should we -instead- endorse mailer.py? I'm not at all that happy
> with maintaining duplicate functionality. Within the Subversion core
> we don't have much choice (as things stand), but do we need to do so
> when the alternative is obviously so much more advanced?

I agree - why does Subversion need to provide and maintain more than one 
sample post-commit mailer?  It's nice to have *something* included in 
the core package, but when I tried to improve commit-email.pl.in, I 
found to be not very easily rewritten (no jokes about all Perl code 
being that way). ;-)

We could also just mention SVN::Notify for the Perl-inclined, which is 
at least as advanced and flexible as mailer.py (plus I have some 
proprietary interest in that one, since I have several subclasses of it 
that I have written/maintain).

John

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org