On Mon, Mar 16, 2015 at 3:45 AM, John Found <johnfo...@asm32.info> wrote: > > The first step towards such achievement is to allow all Fossil users to > exists in > one common username space. > OpenID authentication could help to make this without big effort. >
OpenID support would be a nice addition. But, even in an enterprise environment where all users log in through a central service like Kerberos or MS AD, access to individual projects is still the domain of each project admin (where I work, the Project Managers). > Another step is to provide some notification mechanism from the cloned > repositories > to the parent repository - for example, when the user make commit to the > cloned > repository, Fossil sends notification message to the parent repository. > These automatic > notifications are not so useful but may serve as a statistics mechanism > and as > a indicator of the project development. Of course, if the project leader > has informations > about the changes, he can choose to pull some/all of these changes without > waiting > the pull request. > At least where I work, the Project Managers and Lead Developers subscribed/unsubscribe to the Fossil RSS feeds of the developers they are responsible for. I am aware of the difficulties people without enterprise resources can face - such as originating RSS feeds from a PC in one's residence. Even a service like GitHub can only partly mitigate these problems as the service only knows about changes that have been pushed to repos hosted by the service. RSS forwarding is possible. I don't know of any such service. (by RSS forwarding, I meant the originator pushes the new items to the forwarding service. Readers would then subscribe to the forwarded version of the feed.) Of course, for this to work, either the new TH1 hooks would need to be used to push to the forwarding service, or a local feed forwarder would read the feed from Fossil and push it > Even more useful is if the parent repository, notifies the clones about > new commits, > because the cloned repository might want to merge these changes. But if > the cloned > repository is not hosted on a web server this can be not easy task. In > this case > the notification can be made by request from the cloned repository. > Again, where I work, we subscribe to the Fossil RSS feeds of the repos we need to monitor > The ticket system can be used as a distributed messaging engine between > developers. True, but I think that would needlessly clutter the repository and its clones. FWIW, our IT department has set up some kind of email forwarder that "remembers" the subscriber list of the latest notification message for each issue. Any time someone wants/needs to email all subscribers of a given issue just addresses the message to "n...@issues.company.com" (where nnnn is the issue ID) and the message is forwarded to the remembered subscribers. Similar to Bugzilla, we treat issue subscription changes as ticket changes. The forwarder is able to reliably recognize and filter out subscription-change-only notifications so users don't get spammed. (Unfortunately, our IT people are not allowed to shared the details with people outside the company so I can't share those either.)
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
