| Summary: | cvs commit notification | ||
|---|---|---|---|
| Product: | Community | Reporter: | Alexandre Vasseur <avasseur> |
| Component: | CVS | Assignee: | Eclipse Webmaster <webmaster> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | gunnar, pete |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Windows 2000 | ||
| Whiteboard: | |||
|
Description
Alexandre Vasseur
I don't want to see CVS commit information on the dev mailing lists. These lists are very active as it is and with a large code base this will create an enormous amount of traffic. All this extra traffic will affect the Eclipse infrastructure as well. Apache and SourceForge (I'm not familiar with CodeHaus) in general seem to have smaller projects each with their own mailing list. Implementing this on a project such as WTP has the potential to add hundreds of messages to the mailing list per day. Also, with a larger project like WTP I'd guess most developers will not be interested in the majority of commits taking place. (In reply to comment #1) I agree with don't do this. The traffic will be far too large. The way we know there are changes is when we synchronize we see what was changed. It gives the same info as the diff in a more easily readable form and we can ignore project/package/files that we are not interested in. Usually, you don't send it to a developer discussion list. Instead there are lists ending with "-cvs" where the diffs are sent to. I agree that such notifications could be useful. I also agree that you see all the changes when synchronizing your projects. However, with a notification system change information are sent out immediately. In the synchronizing scenario you'll only see them if you perform a synchronize. The first option allows to track changes immediately. In some cases this is really useful and necessary. For example, when preparing releases for integration builds, cross checking commits, etc. Also, notification systems are typically "opt-in" systems. It must be explicitly enabled for a project. However, I wouldn't go with Fisheye. They say it's free for open source projects but you'll never know (see the BitKeeper/Linux kernel story). Also, Eclipse.org is already using ViewCVS, which provides colorized diffs as well. http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.core.runtime/about.html.diff?r1=1.18&r2=1.19 Maybe just plain text mails with links to ViewCVS would be suitable? http://sourceforge.net/docman/display_doc.php?docid=772&group_id=1#scriptsyncmail Thanks all for commenting. Please note: Yes the intent is not to spam a -dev list but have a new dedicated mailing list. In the case of Fisheye, this is completely different from notification. There is no mail at all but sort of a portal of the cvs diff where you have to go to see what is happening in the cvs. There is a MAJOR difference with viewCVS diff: Fisheye gather those by each commit ie it is very easy for anyone to see each commit as a whole (and not clicking around file by file) thus tracking the project history on a per commit basis and not a useless file by file basis. This is especially usefull in "big" projects. I also support this proposal. I've always used a *-cvs mailing list for CVS commit notification and was surprised that Eclipse doesn't. I was about to ask if such a facility existed when you created this bug. EMF team supports the proposal of CVS notifications (to -cvs lists). Personally, when working on Apache projects, I found it very useful to have – cvs lists, since they provide instantaneous notification and more importantly allow easy search for specific commit information in email archives. Ideally, we would like to be able to subscribe and unsubscribe from -cvs list. Hope this is going to be one of the options. Denis, I would really appreciate an update on that. As a sum-up: - no email has to be send on -dev list. No one wants that, and I did not proposed that. If we go for a mail push system, we'll need a new email alias like -scm or -commit (not archived by the way, would be useless to archive that). - I have seen a very little feedback on this issue (no need to say that it's kinda weird for me to push for it and spam folks so that they vote on it). It sounds that a per project set up will be a must have, and that a simple system to begin with will fit. I would thus advocate for cvsspam system insted of Fisheye for now. Can you get back to me with a proposal ? Else please explain me with who should I discuss further to have that service. Alexandre, We accept the feature request and we'll get some kind of CVS commit notification going. I'm not quite sure how fast we can act, but we'll look into it. Sujay if you have free cycles can you look into this? D. We have a solution in place that can notify you of individual commits, do let me know if you want to try it out. The solution we have put in place is a simple python script called syncmail - http://sourceforge.net/projects/cvs-syncmail Great ! Subscribe my "avasseur AT gmail DOT com" email for the AspectJ commits. I'll act as the alpha user. we have created mailing lists for cvs email notifications. The two lists created for the following modules are aspectj-cvs-commit@eclipse.org ajdt-cvs-commit@eclipse.org you should be able to subscribe to those mailing lists at www.eclipse.org enjoy :) More can be created on request per module. Sujay we have implemented a solution using syncmail. This solution is activated on a per module basis, and the commit notifications sent to a created mailing list which can be subscribed to. (reopen) did subscribed list seems ok since I can post to it did some commit 30 min ago but did not got any notifications I could just see your commit. I tried one as well and here is what I could spot. Sounds like a right issue. Checking in modules/weaver/features.txt; /home/technology/org.aspectj/modules/weaver/features.txt,v <-- features.txt new revision: 1.2; previous revision: 1.1 done sh: line 1: /home/admin/syncmail: Permission denied there was a permission problem while running the syncmail script as reported by Alexandre Vasseur. I have tested, and seems to work well now. works fine I will perhaps open new issues if new needs occur but that already sounds great. I let you guys announce it widely whenever you feel ready for it. for reference since it does not appear on the Eclipse list of mailing lists https://dev.eclipse.org/mailman/listinfo/aspectj-cvs-commit Webmaster: the commit list is archived. This is not needed. Can you turn that off ? (reopening) Archiving has been disabled, and future cvs lists won't be archived either. Susan has a list of the new lists, and she will be creating a specific page for them (otherwise the list of lists will be too long). D. Please add the username of the commiter to the message. as i have noted in previous comments, this cannot be done becuase we do not support cvs history. (In reply to comment #20) > as i have noted in previous comments, this cannot be done becuase we do not > support cvs history. I've whacked together some fix for this. The Eclipse userid is prepended to the e-mail subject line. This should work for you. D. I'm from Cenqua (the makers of FishEye) and I just stumbled across this thread. Reading through the comments, FishEye's RSS feeds are a perfect solution to this problem. Anyone can create a custom feed at any node in the repository (and even restrict it to braches, tags, or authors) that is pretty close to realtime (even without use of cvshistory). It also does a bunch of other stuff (search, tarballs, pretty chanesets, etc) that might be useful to the eclipse community. We'd be more than happy to support eclipse with a free license and assist wherever we can with setup, support and even hosting (we already mirror about 100 sourceforge, apache, and java.net project's CVS repositories on fisheye.cenqua.com). Feel free to contact me direct (pete _at_ cenqua.com) if you are interested and I'll hook you up. Cheers, Pete (In reply to comment #22) > We'd be more than happy to support eclipse with a free license and assist wherever we can with setup, > support and even hosting (we already mirror about 100 sourceforge, apache, and java.net project's CVS > repositories on fisheye.cenqua.com). FYI, I've opend bug 114883 to track this. |