mainSavannah Administration - Support: sr #106531, Bazaar commit notification emails...

 
 

sr #106531: Bazaar commit notification emails omit large diffs

Submitter:  Bastiaan Jacques <bjacques>
Submitted:  Thu 23 Oct 2008 03:01:10 PM UTC
   
 
Category:  Savannah mail server Priority:  5 - Normal
Severity:  3 - Normal Status:  None
Privacy:  Public Assigned to:  None
Operating System:  None Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 02 Dec 2009 04:27:23 AM UTC, comment #18: 
Karl Fogel <kfogel>
Sun 06 Sep 2009 08:01:29 AM UTC, comment #17: 

Yavor: it depends whether this limit is global or can be defined for each project independently.

Sylvain Beucler <Beuc>
Sat 05 Sep 2009 02:42:31 PM UTC, comment #16: 

That makes some sense, especially given that the concern for recipients is the size of the overall mail, not the size of the diff specifically (it just happens that the diff is the element whose size varies the most).

In any case, we don't have to make this decision now.  I just wanted to make sure that our tools gave us all the options we might need.

Karl Fogel <kfogel>
Sat 05 Sep 2009 10:01:16 AM UTC, comment #15: 

There is no limit for the diff size for CVS repositories, so I don't see why there should be for Bzr.  Restrictions for the size should be implemented further in the chain -- MTA, mailing list setup, etc.

For Emacs specifically, it has always been the practice to send the full diff, including cases with giant merges such as unicode-2, multi-tty and the NS port.

Anyway, this is just my personal opinion.

Yavor Doganov <yavor>
Fri 04 Sep 2009 10:54:20 PM UTC, comment #14: 

Can you expand on that?

There is the question of whether we should place any limit or not; that is a separate issue.  But if we decide we do want to place a limit, then I think this hook (assuming we're using it) would be the right place.  Do you have some other place in mind?

Best,
-Karl

Karl Fogel <kfogel>
Fri 04 Sep 2009 08:48:20 PM UTC, comment #13: 

IMVHO this is the wrong place to put any limitations wrt size.

Yavor Doganov <yavor>
Fri 04 Sep 2009 08:24:49 PM UTC, comment #12: 

I have submitted a patch adding a '--byte-limit' option to bzr-hookless-email upstream:

https://code.edge.launchpad.net/~kfogel/bzr-hookless-email/byte-limit/+merge/11233

No action requested right now.  If the patch is accepted, we may request that Emacs's bzr trunk branch be configured to use the new bzr-hookless-email with some particular --byte-limit value.

Karl Fogel <kfogel>
Wed 29 Jul 2009 09:01:50 PM UTC, comment #11: 

No misunderstanding -- I will take a look at the script and see about getting a patch into it upstream, if still needed.

Karl Fogel <kfogel>
Sat 24 Jan 2009 12:14:06 PM UTC, comment #10: 

Thanks for the suggestions, but there's a misunderstanding: we don't develop this script, so it's better to direct them to the script author.

Sylvain Beucler <Beuc>
Fri 23 Jan 2009 05:40:38 PM UTC, comment #9: 

Well, for some people even receiving a mail that big is troublesome (download time, for example).  Ideally, this would be user-configurable, but I guess in practice that's hard, since the mails are going to mailing lists...

...though one could have two lists, one which gets all diffs, and one with size-controlled diffs.  That may be more trouble than it's worth.

Thanks for the loggerhead information; that's going to be important for sr #106612.

Karl Fogel <kfogel>
Fri 23 Jan 2009 05:26:39 PM UTC, comment #8: 


> almost no one wants to receive those


The problem is that "almost no one" != "absolutely no one".  AFAIK commit notifications is the only way some people (rms for example) track development, and others simply hate anything web-related.

TTBOMK rms considers the truncation of notifications a serious bug (and I can only agree with that -- if the diff is too large or not interesting, just skip the message).

> Always include the URL to the web-viewable change.


Not possible for the time being -- there is no Loggerhead installation at Savannah.

Yavor Doganov <yavor>
Fri 23 Jan 2009 04:43:19 PM UTC, comment #7: 

When the diff is large, just omit it and include a URL to a web-viewable version of the diff (via LoggerHead for example).  I mean, there's no point mailing out 1MB diffs -- almost no one wants to receive those, even if when mailing list software lets it through, which it usually won't anyway.

Tentative full solution for commit emails:

   * Always include the URL to the web-viewable change.
   * When the diff is less than (say) 100kb, include it too.
   * When the diff is omitted, replace it with a message
     explaining why.
   * The diff (or the replacement message) should come after
     the URL, so that the URL is always in a predictable
     location near the top of the mail.

Karl Fogel <kfogel>
Tue 04 Nov 2008 07:14:43 PM UTC, comment #6: 

Well short of other suggestions I'll just make a wild guess and put -l 10000

Sylvain Beucler <Beuc>
Sat 25 Oct 2008 11:28:01 AM UTC, comment #5: 

From my perspective, as close as you can get to "unlimited" would be great.

Bastiaan Jacques <bjacques>
Sat 25 Oct 2008 07:10:06 AM UTC, comment #4: 

After checking the configuration again I found 2 issues:

- the limit of 1000 lines is actually a default limit in the bzr script

- the script only allow a lines limit rather than a size limit


So apparently the best way to fix the situation is to send a patch in this regard to http://launchpad.net/bzr-hookless-email/

Meanwhile I can set a different value for "-l", what do you wanna try?

Sylvain Beucler <Beuc>
Sat 25 Oct 2008 07:05:52 AM UTC, comment #3: 

(please keep the discussion on the tracker)

Sylvain Beucler <Beuc>
Fri 24 Oct 2008 07:08:49 PM UTC, comment #2: 

I think so, because I can send the whole diff to the commit mailing list if I compose another email myself. And I think a 1000 line diff does not necessarily correspond to 40kB.

Bastiaan Jacques <bjacques>
Fri 24 Oct 2008 05:32:57 PM UTC, comment #1: 


> Also, in my opinion, the mailing system should be in charge of
> deciding when a message is too large.


And this is already the case! When that happens lists.gnu.org, well, drops the mail, which we want even less. This is no specific to bzr.

Recently the FSF sysadmins have introduced a 40kB size limit for messages after a few abuses (a few MB attachment send to hundreds members), which made such configuration necessary.

Still a bug? :)

Sylvain Beucler <Beuc>
Thu 23 Oct 2008 03:01:10 PM UTC, original submission:  

See for example: http://lists.gnu.org/archive/html/gnash-commit/2008-10/msg00292.html

The commit email reads: "Diff too large for email (9266 lines, the limit is 1000)." The diff is then simply omitted.

This is a problem for Bazaar workflows, because Bazaar encourages the use of branches. When branches are then merged, the diffs that are generated are often quite large. So these commit notifications should include large diffs.

Also, in my opinion, the mailing system should be in charge of deciding when a message is too large.

Bastiaan Jacques <bjacques>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by yavor (Posted a comment)
  • -email is unavailable- added by kfogel (Posted a comment)
  • -email is unavailable- added by Beuc
  • -email is unavailable- added by Beuc
  • -email is unavailable- added by Beuc (Posted a comment)
  • -email is unavailable- added by bjacques (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2008-10-25 Beuc Carbon-Copy- Added -email is unavailable-
    2008-10-25 Beuc Carbon-Copy- Added -email is unavailable-

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code