http://wiki.geeklog.net/api.php?action=feedcontributions&user=Blaine&feedformat=atomGeeklogWiki - User contributions [en]2024-03-28T22:50:55ZUser contributionsMediaWiki 1.27.5http://wiki.geeklog.net/index.php?title=Using_Mercurial&diff=4758Using Mercurial2008-11-14T14:39:45Z<p>Blaine: /* Windows Users - Secret Sauce (if you have commit rights) */</p>
<hr />
<div>== Introduction ==<br />
<br />
[http://www.selenic.com/mercurial/ Mercurial] is a distributed version control system (DVCS). The differences to a "traditional" centralized VCS (like CVS or Subversion) include:<br />
<br />
* Users get a self-contained repository that they can commit changes to, even when being offline.<br />
* Changes can be pushed back to the parent repository or even to other repositories.<br />
<br />
Having used CVS since its inception, Geeklog switched to Mercurial after the release of Geeklog 1.5.1. This switch was preceded by an successful experiment using Mercurial during the 2008 [[Google Summer of Code]]. The distributed model did fit this scenario nicely, as each of our students was working on a separate feature. So they had a local repository to check in to (giving them all the benefits of a version control system). Once a feature or part of a feature was done, it could be pushed back to the parent repository. And in the meantime, it was easy to let other people, e.g. their mentor or interested members of the Geeklog community, pull the changes from the student's repository to show things off or get help on a problem.<br />
<br />
== Installing Mercurial ==<br />
<br />
Installation instructions are provided for [http://www.selenic.com/mercurial/wiki/index.cgi/WindowsInstall Windows], [http://www.selenic.com/mercurial/wiki/index.cgi/UnixInstall Mac OS X], and [http://www.selenic.com/mercurial/wiki/index.cgi/UnixInstall Linux]<br />
<br />
== Setup ==<br />
<br />
Geeklog's Mercurial repository is available from this URL:<br />
<br />
: http://project.geeklog.net/cgi-bin/hgwebdir.cgi/geeklog/<br />
<br />
This repository was converted from the CVS repository right after the release of [http://www.geeklog.net/article.php/geeklog-1.5.1 Geeklog 1.5.1].<br />
<br />
To create a copy of that repository, simply do<br />
<br />
<pre>hg clone http://project.geeklog.net/cgi-bin/hgwebdir.cgi/geeklog/ geeklog</pre><br />
<br />
Where the last "geeklog" is just a directory name for the local copy (and can be changed at will). This will give you a fully working local repository that you can commit changes to.<br />
<br />
'''Note:''' The same URL can also be used to browse the repository online. Simply visit that URL with your web browser.<br />
<br />
=== SSH Setup ===<br />
<br />
For ssh access, you need an account on the server. So this is only of interest for the core developers and SoC students.<br />
<br />
You can clone the repository via SSH like so:<br />
<br />
<pre>hg clone ssh://username@cvs.geeklog.net//cvsroot/hg/geeklog geeklog</pre><br />
<br />
Where "username" is your login name and the "geeklog" at the end of the command line is again simply a name for your local directory.<br />
<br />
Please note the slightly odd path syntax with the two slashes after <tt>cvs.geeklog.net</tt> - those are required.<br />
<br />
<br />
== Pushing back ==<br />
<br />
Being able to push changes back to the repository again requires an account on the server. You can either do<br />
<br />
<pre>hg push ssh://username@cvs.geeklog.net//cvsroot/hg/geeklog</pre><br />
<br />
or, to make your life easier, set the <tt>default-push</tt> repository in the <tt>.hg/hgrc</tt> file of your local repository like so:<br />
<br />
<pre>[paths]<br />
default-push = ssh://username@cvs.geeklog.net//cvsroot/hg/geeklog</pre><br />
<br />
(Again, in the ssh: URLs above, replace "username" with your login name)<br />
<br />
=== Trust and Notifications ===<br />
<br />
Changes pushed back into the central repository will trigger an email sent to the geeklog-cvs mailing list. However, that email will only be sent after the following additional steps:<br />
<br />
# log into your account on cvs.geeklog.net<br />
# in your home directory, create a file named <tt>.hgrc</tt><br />
# enter this as the file's content:<br />
<pre>[trusted]<br />
users = geeklog2<br />
groups = users</pre><br />
<br />
This will also get rid of warnings like<br />
: remote: Not trusting file (...) from untrusted user geeklog2, group users<br />
when pushing back changes.<br />
<br />
<br />
== GSoC Repository ==<br />
<br />
The repository used during the 2008 Google Summer of Code is still available from<br />
<br />
: http://project.geeklog.net/cgi-bin/hgwebdir.cgi/gsoc-2008/<br />
<br />
Note that both the URL and the repository name have changed (formerly <tt>Geeklog-SoC</tt>). You can still use your local copies of that repository - you only need to update the <tt>default-push</tt> setting to the new address and name.<br />
<br />
<br />
== Best practices ==<br />
<br />
Since we're all new to Mercurial, this is something we will have to establish as we go along. For starters, the [http://www.selenic.com/mercurial/wiki/ Mercurial Wiki] has a page on [http://www.selenic.com/mercurial/wiki/index.cgi/WorkingPractices Working Practices] that we may want to adopt.<br />
<br />
=== Use a clean incoming repository ===<br />
<br />
Pull changes to a local "incoming" repository but don't work on that repository. Cloning that repository locally is a cheap operation and allows you to easily create multiple copies if necessary, e.g. when working on different features in parallel.<br />
<br />
Push directly from your working repositories, then sync back by pulling the changes back down via your incoming repository.<br />
<br />
=== Merging ===<br />
<br />
If you attempt to push changes to the main repository and receive the error:<br />
pushing to ssh://username@cvs.geeklog.net//cvsroot/geeklog/Geeklog-SoC<br />
searching for changes<br />
abort: push creates new remote heads!<br />
(did you forget to merge? use push -f to force)<br />
Simply pull from the main repository, "hg heads" to see the revision numbers, "hg merge [rev number]" to merge your changes, then commit the changes, and push back to the main repository.<br />
<br />
Also: Don't try to push newly added files while you still have uncommited changes lying around (or you will end up with the above). In that case, it may make sense to make a fresh clone (fast + cheap if you use an "incoming" repository!), add the new files there, then push from the fresh copy.<br />
<br />
=== Username ===<br />
<br />
When committing a change, the username associated with that change will be your local username (login, etc.) - ''not'' the name of your account on the server.<br />
<br />
For a consistent username, add your preferred username to your local <tt>.hgrc</tt> file:<br />
<pre>username = John Doe <john@example.com></pre><br />
The email address is optional.<br />
<br />
''(More tips and tricks to be added here)''<br />
<br />
<br />
== Undoing Changes ==<br />
<br />
To undo changes you made, use one of the following, depending on circumstances:<br />
<br />
* <tt>hg revert</tt><br>to revert changes made before a commit. This will also undo <tt>hg add</tt> and <tt>hg remove</tt>.<br />
* <tt>hg rollback</tt><br>to revert changes that have been commited to the local repository but not been pushed to another repository yet. You can only rollback the last hg command.<br />
* <tt>hg backout</tt><br>to revert changes after they have been commited ''and'' pushed.<br />
<br />
Note that <tt>hg backout</tt> will actually add a new change to the current branch that reverts your previous change. I.e. your change will ''not'' be removed from the repository. Unless you've accidentally committed something super-secret, that's usually fine. Mistakes happen - no need to sweat it.<br />
<br />
<br />
== Documentation ==<br />
<br />
The [http://www.selenic.com/mercurial/wiki/ Mercurial Wiki] is a good place to search for information. For starters, however, [http://hgbook.red-bean.com/ Distributed revision control with Mercurial] aka "the hg book" is a much better place to start. This book is available for download under the Open Publication License.<br />
<br />
Here's the entirely subjective "The Impatient's Guide to the HG Book":<br />
<br />
* Chapter 1: Introduction<br>Skip if you already know about VCS and DVCS<br />
* Chapter 2: A tour of Mercurial: the basics<br>Everything from section 2.2 on is '''recommended reading'''. The essential things you need to know to use Mercurial.<br />
* Chapter 3: A tour of Mercurial: merging work<br>Title says it all - '''recommended reading'''<br />
* Chapter 4: Behind the scenes<br>Feel free to skip<br />
* Chapter 5: Mercurial in daily use<br>Despite the title, this chapter seems more confusing than helpful - skip<br />
* Chapter 6: Collaborating with other people<br>Section 6.2 is '''recommended reading''' once you've mastered the basics<br />
* Chapter 7: File names and pattern matching<br>Nothing surprising here - skip<br />
* Chapter 8: Managing releases and branchy development<br>Advanced topic but useful<br />
* Chapter 9: Finding and fixing your mistakes<br>Very useful (but skip sections 9.5 and 9.6)<br />
* You can effectively stop reading after Chapter 9.<br />
* Appendix A may be useful as a reference.<br />
<br />
<br />
[[Category:Development]]<br />
<br />
<br />
== Windows Users - Secret Sauce (if you have commit rights) ==<br />
<br />
I'm using command line Mercurial (I don't like the windows explorer performance hit of the tortoise system). But this works for me, after much messing around.<br />
<br />
# Clone the main Geeklog repository, as above. (geeklog-hg)<br />
# Clone your local copy of Geeklog to give yourself a clean working environment. (geeklog-hg-mine)<br />
# Clone your clean working environment ;-) (geeklog-hg-dev)<br />
# Update /path/to/geeklog-hg/.hg/hgrc to match bellow<br />
# Update /documents and settings/[your user]/mercurial.ini to match the other bellow<br />
<br />
And that works.<br />
<br />
For hgrc:<br />
<br />
<pre>[paths]<br />
default = ssh://[your username]@cvs.geeklog.net//cvsroot/hg/geeklog<br />
</pre><br />
<br />
For mercurial.ini:<br />
<br />
<pre>[ui]<br />
ssh = c:/path/to/putty/plink.exe -ssh -v -l [your username] -pw [your password]<br />
username = [your name] <[your email address]><br />
</pre><br />
<br />
* No quotes are used in defining the .ini paramaters<br />
* Path to plink.exe can not have any spaces in the actual directory names<br />
* Commit will just commit the change to your local repository<br />
* Use the synchronize (Tortoise client term) to push the local committed changes up to the remote repository<br />
* When doing the syncronize, in the pop-up dialog, the remote path is: ssh://username@cvs.geeklog.net//cvsroot/hg/geeklog<br />
<br />
So I develop in geeklog-hg-dev, then I winmerge my changes back into geeklog-hg-mine to make sure I never accidentally commit localsettings (paths etc) or hacks, debugs. Then I commit to geeklog-hg-mine, then back to geeklog-hg when that's ready, then push up to master. Complex hey? ;-)</div>Blainehttp://wiki.geeklog.net/index.php?title=Using_Mercurial&diff=4757Using Mercurial2008-11-14T14:39:17Z<p>Blaine: /* Windows Users - Secret Sauce (if you have commit rights) */</p>
<hr />
<div>== Introduction ==<br />
<br />
[http://www.selenic.com/mercurial/ Mercurial] is a distributed version control system (DVCS). The differences to a "traditional" centralized VCS (like CVS or Subversion) include:<br />
<br />
* Users get a self-contained repository that they can commit changes to, even when being offline.<br />
* Changes can be pushed back to the parent repository or even to other repositories.<br />
<br />
Having used CVS since its inception, Geeklog switched to Mercurial after the release of Geeklog 1.5.1. This switch was preceded by an successful experiment using Mercurial during the 2008 [[Google Summer of Code]]. The distributed model did fit this scenario nicely, as each of our students was working on a separate feature. So they had a local repository to check in to (giving them all the benefits of a version control system). Once a feature or part of a feature was done, it could be pushed back to the parent repository. And in the meantime, it was easy to let other people, e.g. their mentor or interested members of the Geeklog community, pull the changes from the student's repository to show things off or get help on a problem.<br />
<br />
== Installing Mercurial ==<br />
<br />
Installation instructions are provided for [http://www.selenic.com/mercurial/wiki/index.cgi/WindowsInstall Windows], [http://www.selenic.com/mercurial/wiki/index.cgi/UnixInstall Mac OS X], and [http://www.selenic.com/mercurial/wiki/index.cgi/UnixInstall Linux]<br />
<br />
== Setup ==<br />
<br />
Geeklog's Mercurial repository is available from this URL:<br />
<br />
: http://project.geeklog.net/cgi-bin/hgwebdir.cgi/geeklog/<br />
<br />
This repository was converted from the CVS repository right after the release of [http://www.geeklog.net/article.php/geeklog-1.5.1 Geeklog 1.5.1].<br />
<br />
To create a copy of that repository, simply do<br />
<br />
<pre>hg clone http://project.geeklog.net/cgi-bin/hgwebdir.cgi/geeklog/ geeklog</pre><br />
<br />
Where the last "geeklog" is just a directory name for the local copy (and can be changed at will). This will give you a fully working local repository that you can commit changes to.<br />
<br />
'''Note:''' The same URL can also be used to browse the repository online. Simply visit that URL with your web browser.<br />
<br />
=== SSH Setup ===<br />
<br />
For ssh access, you need an account on the server. So this is only of interest for the core developers and SoC students.<br />
<br />
You can clone the repository via SSH like so:<br />
<br />
<pre>hg clone ssh://username@cvs.geeklog.net//cvsroot/hg/geeklog geeklog</pre><br />
<br />
Where "username" is your login name and the "geeklog" at the end of the command line is again simply a name for your local directory.<br />
<br />
Please note the slightly odd path syntax with the two slashes after <tt>cvs.geeklog.net</tt> - those are required.<br />
<br />
<br />
== Pushing back ==<br />
<br />
Being able to push changes back to the repository again requires an account on the server. You can either do<br />
<br />
<pre>hg push ssh://username@cvs.geeklog.net//cvsroot/hg/geeklog</pre><br />
<br />
or, to make your life easier, set the <tt>default-push</tt> repository in the <tt>.hg/hgrc</tt> file of your local repository like so:<br />
<br />
<pre>[paths]<br />
default-push = ssh://username@cvs.geeklog.net//cvsroot/hg/geeklog</pre><br />
<br />
(Again, in the ssh: URLs above, replace "username" with your login name)<br />
<br />
=== Trust and Notifications ===<br />
<br />
Changes pushed back into the central repository will trigger an email sent to the geeklog-cvs mailing list. However, that email will only be sent after the following additional steps:<br />
<br />
# log into your account on cvs.geeklog.net<br />
# in your home directory, create a file named <tt>.hgrc</tt><br />
# enter this as the file's content:<br />
<pre>[trusted]<br />
users = geeklog2<br />
groups = users</pre><br />
<br />
This will also get rid of warnings like<br />
: remote: Not trusting file (...) from untrusted user geeklog2, group users<br />
when pushing back changes.<br />
<br />
<br />
== GSoC Repository ==<br />
<br />
The repository used during the 2008 Google Summer of Code is still available from<br />
<br />
: http://project.geeklog.net/cgi-bin/hgwebdir.cgi/gsoc-2008/<br />
<br />
Note that both the URL and the repository name have changed (formerly <tt>Geeklog-SoC</tt>). You can still use your local copies of that repository - you only need to update the <tt>default-push</tt> setting to the new address and name.<br />
<br />
<br />
== Best practices ==<br />
<br />
Since we're all new to Mercurial, this is something we will have to establish as we go along. For starters, the [http://www.selenic.com/mercurial/wiki/ Mercurial Wiki] has a page on [http://www.selenic.com/mercurial/wiki/index.cgi/WorkingPractices Working Practices] that we may want to adopt.<br />
<br />
=== Use a clean incoming repository ===<br />
<br />
Pull changes to a local "incoming" repository but don't work on that repository. Cloning that repository locally is a cheap operation and allows you to easily create multiple copies if necessary, e.g. when working on different features in parallel.<br />
<br />
Push directly from your working repositories, then sync back by pulling the changes back down via your incoming repository.<br />
<br />
=== Merging ===<br />
<br />
If you attempt to push changes to the main repository and receive the error:<br />
pushing to ssh://username@cvs.geeklog.net//cvsroot/geeklog/Geeklog-SoC<br />
searching for changes<br />
abort: push creates new remote heads!<br />
(did you forget to merge? use push -f to force)<br />
Simply pull from the main repository, "hg heads" to see the revision numbers, "hg merge [rev number]" to merge your changes, then commit the changes, and push back to the main repository.<br />
<br />
Also: Don't try to push newly added files while you still have uncommited changes lying around (or you will end up with the above). In that case, it may make sense to make a fresh clone (fast + cheap if you use an "incoming" repository!), add the new files there, then push from the fresh copy.<br />
<br />
=== Username ===<br />
<br />
When committing a change, the username associated with that change will be your local username (login, etc.) - ''not'' the name of your account on the server.<br />
<br />
For a consistent username, add your preferred username to your local <tt>.hgrc</tt> file:<br />
<pre>username = John Doe <john@example.com></pre><br />
The email address is optional.<br />
<br />
''(More tips and tricks to be added here)''<br />
<br />
<br />
== Undoing Changes ==<br />
<br />
To undo changes you made, use one of the following, depending on circumstances:<br />
<br />
* <tt>hg revert</tt><br>to revert changes made before a commit. This will also undo <tt>hg add</tt> and <tt>hg remove</tt>.<br />
* <tt>hg rollback</tt><br>to revert changes that have been commited to the local repository but not been pushed to another repository yet. You can only rollback the last hg command.<br />
* <tt>hg backout</tt><br>to revert changes after they have been commited ''and'' pushed.<br />
<br />
Note that <tt>hg backout</tt> will actually add a new change to the current branch that reverts your previous change. I.e. your change will ''not'' be removed from the repository. Unless you've accidentally committed something super-secret, that's usually fine. Mistakes happen - no need to sweat it.<br />
<br />
<br />
== Documentation ==<br />
<br />
The [http://www.selenic.com/mercurial/wiki/ Mercurial Wiki] is a good place to search for information. For starters, however, [http://hgbook.red-bean.com/ Distributed revision control with Mercurial] aka "the hg book" is a much better place to start. This book is available for download under the Open Publication License.<br />
<br />
Here's the entirely subjective "The Impatient's Guide to the HG Book":<br />
<br />
* Chapter 1: Introduction<br>Skip if you already know about VCS and DVCS<br />
* Chapter 2: A tour of Mercurial: the basics<br>Everything from section 2.2 on is '''recommended reading'''. The essential things you need to know to use Mercurial.<br />
* Chapter 3: A tour of Mercurial: merging work<br>Title says it all - '''recommended reading'''<br />
* Chapter 4: Behind the scenes<br>Feel free to skip<br />
* Chapter 5: Mercurial in daily use<br>Despite the title, this chapter seems more confusing than helpful - skip<br />
* Chapter 6: Collaborating with other people<br>Section 6.2 is '''recommended reading''' once you've mastered the basics<br />
* Chapter 7: File names and pattern matching<br>Nothing surprising here - skip<br />
* Chapter 8: Managing releases and branchy development<br>Advanced topic but useful<br />
* Chapter 9: Finding and fixing your mistakes<br>Very useful (but skip sections 9.5 and 9.6)<br />
* You can effectively stop reading after Chapter 9.<br />
* Appendix A may be useful as a reference.<br />
<br />
<br />
[[Category:Development]]<br />
<br />
<br />
== Windows Users - Secret Sauce (if you have commit rights) ==<br />
<br />
I'm using command line Mercurial (I don't like the windows explorer performance hit of the tortoise system). But this works for me, after much messing around.<br />
<br />
# Clone the main Geeklog repository, as above. (geeklog-hg)<br />
# Clone your local copy of Geeklog to give yourself a clean working environment. (geeklog-hg-mine)<br />
# Clone your clean working environment ;-) (geeklog-hg-dev)<br />
# Update /path/to/geeklog-hg/.hg/hgrc to match bellow<br />
# Update /documents and settings/[your user]/mercurial.ini to match the other bellow<br />
<br />
And that works.<br />
<br />
For hgrc:<br />
<br />
<pre>[paths]<br />
default = ssh://[your username]@cvs.geeklog.net//cvsroot/hg/geeklog<br />
</pre><br />
<br />
For mercurial.ini:<br />
<br />
<pre>[ui]<br />
ssh = c:/path/to/putty/plink.exe -ssh -v -l [your username] -pw [your password]<br />
username = [your name] <[your email address]><br />
</pre><br />
<br />
* No quotes are used in defining the .ini paramaters<br />
* Path to plink.exe can not have any spaces in the actual directory names<br />
* Commit will just commit the change to your local repository<br />
* Use the synchronize (Tortoise client term) to push the change up to the remote repository<br />
* When doing the syncronize, in the pop-up dialog, the remote path is: ssh://username@cvs.geeklog.net//cvsroot/hg/geeklog<br />
<br />
So I develop in geeklog-hg-dev, then I winmerge my changes back into geeklog-hg-mine to make sure I never accidentally commit localsettings (paths etc) or hacks, debugs. Then I commit to geeklog-hg-mine, then back to geeklog-hg when that's ready, then push up to master. Complex hey? ;-)</div>Blainehttp://wiki.geeklog.net/index.php?title=Using_Mercurial&diff=4756Using Mercurial2008-11-14T14:38:49Z<p>Blaine: /* Windows Users - Secret Sauce (if you have commit rights) */</p>
<hr />
<div>== Introduction ==<br />
<br />
[http://www.selenic.com/mercurial/ Mercurial] is a distributed version control system (DVCS). The differences to a "traditional" centralized VCS (like CVS or Subversion) include:<br />
<br />
* Users get a self-contained repository that they can commit changes to, even when being offline.<br />
* Changes can be pushed back to the parent repository or even to other repositories.<br />
<br />
Having used CVS since its inception, Geeklog switched to Mercurial after the release of Geeklog 1.5.1. This switch was preceded by an successful experiment using Mercurial during the 2008 [[Google Summer of Code]]. The distributed model did fit this scenario nicely, as each of our students was working on a separate feature. So they had a local repository to check in to (giving them all the benefits of a version control system). Once a feature or part of a feature was done, it could be pushed back to the parent repository. And in the meantime, it was easy to let other people, e.g. their mentor or interested members of the Geeklog community, pull the changes from the student's repository to show things off or get help on a problem.<br />
<br />
== Installing Mercurial ==<br />
<br />
Installation instructions are provided for [http://www.selenic.com/mercurial/wiki/index.cgi/WindowsInstall Windows], [http://www.selenic.com/mercurial/wiki/index.cgi/UnixInstall Mac OS X], and [http://www.selenic.com/mercurial/wiki/index.cgi/UnixInstall Linux]<br />
<br />
== Setup ==<br />
<br />
Geeklog's Mercurial repository is available from this URL:<br />
<br />
: http://project.geeklog.net/cgi-bin/hgwebdir.cgi/geeklog/<br />
<br />
This repository was converted from the CVS repository right after the release of [http://www.geeklog.net/article.php/geeklog-1.5.1 Geeklog 1.5.1].<br />
<br />
To create a copy of that repository, simply do<br />
<br />
<pre>hg clone http://project.geeklog.net/cgi-bin/hgwebdir.cgi/geeklog/ geeklog</pre><br />
<br />
Where the last "geeklog" is just a directory name for the local copy (and can be changed at will). This will give you a fully working local repository that you can commit changes to.<br />
<br />
'''Note:''' The same URL can also be used to browse the repository online. Simply visit that URL with your web browser.<br />
<br />
=== SSH Setup ===<br />
<br />
For ssh access, you need an account on the server. So this is only of interest for the core developers and SoC students.<br />
<br />
You can clone the repository via SSH like so:<br />
<br />
<pre>hg clone ssh://username@cvs.geeklog.net//cvsroot/hg/geeklog geeklog</pre><br />
<br />
Where "username" is your login name and the "geeklog" at the end of the command line is again simply a name for your local directory.<br />
<br />
Please note the slightly odd path syntax with the two slashes after <tt>cvs.geeklog.net</tt> - those are required.<br />
<br />
<br />
== Pushing back ==<br />
<br />
Being able to push changes back to the repository again requires an account on the server. You can either do<br />
<br />
<pre>hg push ssh://username@cvs.geeklog.net//cvsroot/hg/geeklog</pre><br />
<br />
or, to make your life easier, set the <tt>default-push</tt> repository in the <tt>.hg/hgrc</tt> file of your local repository like so:<br />
<br />
<pre>[paths]<br />
default-push = ssh://username@cvs.geeklog.net//cvsroot/hg/geeklog</pre><br />
<br />
(Again, in the ssh: URLs above, replace "username" with your login name)<br />
<br />
=== Trust and Notifications ===<br />
<br />
Changes pushed back into the central repository will trigger an email sent to the geeklog-cvs mailing list. However, that email will only be sent after the following additional steps:<br />
<br />
# log into your account on cvs.geeklog.net<br />
# in your home directory, create a file named <tt>.hgrc</tt><br />
# enter this as the file's content:<br />
<pre>[trusted]<br />
users = geeklog2<br />
groups = users</pre><br />
<br />
This will also get rid of warnings like<br />
: remote: Not trusting file (...) from untrusted user geeklog2, group users<br />
when pushing back changes.<br />
<br />
<br />
== GSoC Repository ==<br />
<br />
The repository used during the 2008 Google Summer of Code is still available from<br />
<br />
: http://project.geeklog.net/cgi-bin/hgwebdir.cgi/gsoc-2008/<br />
<br />
Note that both the URL and the repository name have changed (formerly <tt>Geeklog-SoC</tt>). You can still use your local copies of that repository - you only need to update the <tt>default-push</tt> setting to the new address and name.<br />
<br />
<br />
== Best practices ==<br />
<br />
Since we're all new to Mercurial, this is something we will have to establish as we go along. For starters, the [http://www.selenic.com/mercurial/wiki/ Mercurial Wiki] has a page on [http://www.selenic.com/mercurial/wiki/index.cgi/WorkingPractices Working Practices] that we may want to adopt.<br />
<br />
=== Use a clean incoming repository ===<br />
<br />
Pull changes to a local "incoming" repository but don't work on that repository. Cloning that repository locally is a cheap operation and allows you to easily create multiple copies if necessary, e.g. when working on different features in parallel.<br />
<br />
Push directly from your working repositories, then sync back by pulling the changes back down via your incoming repository.<br />
<br />
=== Merging ===<br />
<br />
If you attempt to push changes to the main repository and receive the error:<br />
pushing to ssh://username@cvs.geeklog.net//cvsroot/geeklog/Geeklog-SoC<br />
searching for changes<br />
abort: push creates new remote heads!<br />
(did you forget to merge? use push -f to force)<br />
Simply pull from the main repository, "hg heads" to see the revision numbers, "hg merge [rev number]" to merge your changes, then commit the changes, and push back to the main repository.<br />
<br />
Also: Don't try to push newly added files while you still have uncommited changes lying around (or you will end up with the above). In that case, it may make sense to make a fresh clone (fast + cheap if you use an "incoming" repository!), add the new files there, then push from the fresh copy.<br />
<br />
=== Username ===<br />
<br />
When committing a change, the username associated with that change will be your local username (login, etc.) - ''not'' the name of your account on the server.<br />
<br />
For a consistent username, add your preferred username to your local <tt>.hgrc</tt> file:<br />
<pre>username = John Doe <john@example.com></pre><br />
The email address is optional.<br />
<br />
''(More tips and tricks to be added here)''<br />
<br />
<br />
== Undoing Changes ==<br />
<br />
To undo changes you made, use one of the following, depending on circumstances:<br />
<br />
* <tt>hg revert</tt><br>to revert changes made before a commit. This will also undo <tt>hg add</tt> and <tt>hg remove</tt>.<br />
* <tt>hg rollback</tt><br>to revert changes that have been commited to the local repository but not been pushed to another repository yet. You can only rollback the last hg command.<br />
* <tt>hg backout</tt><br>to revert changes after they have been commited ''and'' pushed.<br />
<br />
Note that <tt>hg backout</tt> will actually add a new change to the current branch that reverts your previous change. I.e. your change will ''not'' be removed from the repository. Unless you've accidentally committed something super-secret, that's usually fine. Mistakes happen - no need to sweat it.<br />
<br />
<br />
== Documentation ==<br />
<br />
The [http://www.selenic.com/mercurial/wiki/ Mercurial Wiki] is a good place to search for information. For starters, however, [http://hgbook.red-bean.com/ Distributed revision control with Mercurial] aka "the hg book" is a much better place to start. This book is available for download under the Open Publication License.<br />
<br />
Here's the entirely subjective "The Impatient's Guide to the HG Book":<br />
<br />
* Chapter 1: Introduction<br>Skip if you already know about VCS and DVCS<br />
* Chapter 2: A tour of Mercurial: the basics<br>Everything from section 2.2 on is '''recommended reading'''. The essential things you need to know to use Mercurial.<br />
* Chapter 3: A tour of Mercurial: merging work<br>Title says it all - '''recommended reading'''<br />
* Chapter 4: Behind the scenes<br>Feel free to skip<br />
* Chapter 5: Mercurial in daily use<br>Despite the title, this chapter seems more confusing than helpful - skip<br />
* Chapter 6: Collaborating with other people<br>Section 6.2 is '''recommended reading''' once you've mastered the basics<br />
* Chapter 7: File names and pattern matching<br>Nothing surprising here - skip<br />
* Chapter 8: Managing releases and branchy development<br>Advanced topic but useful<br />
* Chapter 9: Finding and fixing your mistakes<br>Very useful (but skip sections 9.5 and 9.6)<br />
* You can effectively stop reading after Chapter 9.<br />
* Appendix A may be useful as a reference.<br />
<br />
<br />
[[Category:Development]]<br />
<br />
<br />
== Windows Users - Secret Sauce (if you have commit rights) ==<br />
<br />
I'm using command line Mercurial (I don't like the windows explorer performance hit of the tortoise system). But this works for me, after much messing around.<br />
<br />
# Clone the main Geeklog repository, as above. (geeklog-hg)<br />
# Clone your local copy of Geeklog to give yourself a clean working environment. (geeklog-hg-mine)<br />
# Clone your clean working environment ;-) (geeklog-hg-dev)<br />
# Update /path/to/geeklog-hg/.hg/hgrc to match bellow<br />
# Update /documents and settings/[your user]/mercurial.ini to match the other bellow<br />
<br />
And that works.<br />
<br />
For hgrc:<br />
<br />
<pre>[paths]<br />
default = ssh://[your username]@cvs.geeklog.net//cvsroot/hg/geeklog<br />
</pre><br />
<br />
For mercurial.ini:<br />
<br />
<pre>[ui]<br />
ssh = c:/path/to/putty/plink.exe -ssh -v -l [your username] -pw [your password]<br />
username = [your name] <[your email address]><br />
</pre><br />
<br />
* No quotes are used in defining the .ini paramaters<br />
* Path to plink.exe can not have any spaces in the actual directory names<br />
* Commit will just commit the change to your local repository, you need to use the synchronize (Tortoise client term) to push the change up to the remote repository<br />
* When doing the syncronize, in the pop-up dialog, the remote path is: ssh://username@cvs.geeklog.net//cvsroot/hg/geeklog<br />
<br />
So I develop in geeklog-hg-dev, then I winmerge my changes back into geeklog-hg-mine to make sure I never accidentally commit localsettings (paths etc) or hacks, debugs. Then I commit to geeklog-hg-mine, then back to geeklog-hg when that's ready, then push up to master. Complex hey? ;-)</div>Blainehttp://wiki.geeklog.net/index.php?title=Using_Mercurial&diff=4755Using Mercurial2008-11-14T14:30:27Z<p>Blaine: /* Windows Users - Secret Sauce (if you have commit rights) */</p>
<hr />
<div>== Introduction ==<br />
<br />
[http://www.selenic.com/mercurial/ Mercurial] is a distributed version control system (DVCS). The differences to a "traditional" centralized VCS (like CVS or Subversion) include:<br />
<br />
* Users get a self-contained repository that they can commit changes to, even when being offline.<br />
* Changes can be pushed back to the parent repository or even to other repositories.<br />
<br />
Having used CVS since its inception, Geeklog switched to Mercurial after the release of Geeklog 1.5.1. This switch was preceded by an successful experiment using Mercurial during the 2008 [[Google Summer of Code]]. The distributed model did fit this scenario nicely, as each of our students was working on a separate feature. So they had a local repository to check in to (giving them all the benefits of a version control system). Once a feature or part of a feature was done, it could be pushed back to the parent repository. And in the meantime, it was easy to let other people, e.g. their mentor or interested members of the Geeklog community, pull the changes from the student's repository to show things off or get help on a problem.<br />
<br />
== Installing Mercurial ==<br />
<br />
Installation instructions are provided for [http://www.selenic.com/mercurial/wiki/index.cgi/WindowsInstall Windows], [http://www.selenic.com/mercurial/wiki/index.cgi/UnixInstall Mac OS X], and [http://www.selenic.com/mercurial/wiki/index.cgi/UnixInstall Linux]<br />
<br />
== Setup ==<br />
<br />
Geeklog's Mercurial repository is available from this URL:<br />
<br />
: http://project.geeklog.net/cgi-bin/hgwebdir.cgi/geeklog/<br />
<br />
This repository was converted from the CVS repository right after the release of [http://www.geeklog.net/article.php/geeklog-1.5.1 Geeklog 1.5.1].<br />
<br />
To create a copy of that repository, simply do<br />
<br />
<pre>hg clone http://project.geeklog.net/cgi-bin/hgwebdir.cgi/geeklog/ geeklog</pre><br />
<br />
Where the last "geeklog" is just a directory name for the local copy (and can be changed at will). This will give you a fully working local repository that you can commit changes to.<br />
<br />
'''Note:''' The same URL can also be used to browse the repository online. Simply visit that URL with your web browser.<br />
<br />
=== SSH Setup ===<br />
<br />
For ssh access, you need an account on the server. So this is only of interest for the core developers and SoC students.<br />
<br />
You can clone the repository via SSH like so:<br />
<br />
<pre>hg clone ssh://username@cvs.geeklog.net//cvsroot/hg/geeklog geeklog</pre><br />
<br />
Where "username" is your login name and the "geeklog" at the end of the command line is again simply a name for your local directory.<br />
<br />
Please note the slightly odd path syntax with the two slashes after <tt>cvs.geeklog.net</tt> - those are required.<br />
<br />
<br />
== Pushing back ==<br />
<br />
Being able to push changes back to the repository again requires an account on the server. You can either do<br />
<br />
<pre>hg push ssh://username@cvs.geeklog.net//cvsroot/hg/geeklog</pre><br />
<br />
or, to make your life easier, set the <tt>default-push</tt> repository in the <tt>.hg/hgrc</tt> file of your local repository like so:<br />
<br />
<pre>[paths]<br />
default-push = ssh://username@cvs.geeklog.net//cvsroot/hg/geeklog</pre><br />
<br />
(Again, in the ssh: URLs above, replace "username" with your login name)<br />
<br />
=== Trust and Notifications ===<br />
<br />
Changes pushed back into the central repository will trigger an email sent to the geeklog-cvs mailing list. However, that email will only be sent after the following additional steps:<br />
<br />
# log into your account on cvs.geeklog.net<br />
# in your home directory, create a file named <tt>.hgrc</tt><br />
# enter this as the file's content:<br />
<pre>[trusted]<br />
users = geeklog2<br />
groups = users</pre><br />
<br />
This will also get rid of warnings like<br />
: remote: Not trusting file (...) from untrusted user geeklog2, group users<br />
when pushing back changes.<br />
<br />
<br />
== GSoC Repository ==<br />
<br />
The repository used during the 2008 Google Summer of Code is still available from<br />
<br />
: http://project.geeklog.net/cgi-bin/hgwebdir.cgi/gsoc-2008/<br />
<br />
Note that both the URL and the repository name have changed (formerly <tt>Geeklog-SoC</tt>). You can still use your local copies of that repository - you only need to update the <tt>default-push</tt> setting to the new address and name.<br />
<br />
<br />
== Best practices ==<br />
<br />
Since we're all new to Mercurial, this is something we will have to establish as we go along. For starters, the [http://www.selenic.com/mercurial/wiki/ Mercurial Wiki] has a page on [http://www.selenic.com/mercurial/wiki/index.cgi/WorkingPractices Working Practices] that we may want to adopt.<br />
<br />
=== Use a clean incoming repository ===<br />
<br />
Pull changes to a local "incoming" repository but don't work on that repository. Cloning that repository locally is a cheap operation and allows you to easily create multiple copies if necessary, e.g. when working on different features in parallel.<br />
<br />
Push directly from your working repositories, then sync back by pulling the changes back down via your incoming repository.<br />
<br />
=== Merging ===<br />
<br />
If you attempt to push changes to the main repository and receive the error:<br />
pushing to ssh://username@cvs.geeklog.net//cvsroot/geeklog/Geeklog-SoC<br />
searching for changes<br />
abort: push creates new remote heads!<br />
(did you forget to merge? use push -f to force)<br />
Simply pull from the main repository, "hg heads" to see the revision numbers, "hg merge [rev number]" to merge your changes, then commit the changes, and push back to the main repository.<br />
<br />
Also: Don't try to push newly added files while you still have uncommited changes lying around (or you will end up with the above). In that case, it may make sense to make a fresh clone (fast + cheap if you use an "incoming" repository!), add the new files there, then push from the fresh copy.<br />
<br />
=== Username ===<br />
<br />
When committing a change, the username associated with that change will be your local username (login, etc.) - ''not'' the name of your account on the server.<br />
<br />
For a consistent username, add your preferred username to your local <tt>.hgrc</tt> file:<br />
<pre>username = John Doe <john@example.com></pre><br />
The email address is optional.<br />
<br />
''(More tips and tricks to be added here)''<br />
<br />
<br />
== Undoing Changes ==<br />
<br />
To undo changes you made, use one of the following, depending on circumstances:<br />
<br />
* <tt>hg revert</tt><br>to revert changes made before a commit. This will also undo <tt>hg add</tt> and <tt>hg remove</tt>.<br />
* <tt>hg rollback</tt><br>to revert changes that have been commited to the local repository but not been pushed to another repository yet. You can only rollback the last hg command.<br />
* <tt>hg backout</tt><br>to revert changes after they have been commited ''and'' pushed.<br />
<br />
Note that <tt>hg backout</tt> will actually add a new change to the current branch that reverts your previous change. I.e. your change will ''not'' be removed from the repository. Unless you've accidentally committed something super-secret, that's usually fine. Mistakes happen - no need to sweat it.<br />
<br />
<br />
== Documentation ==<br />
<br />
The [http://www.selenic.com/mercurial/wiki/ Mercurial Wiki] is a good place to search for information. For starters, however, [http://hgbook.red-bean.com/ Distributed revision control with Mercurial] aka "the hg book" is a much better place to start. This book is available for download under the Open Publication License.<br />
<br />
Here's the entirely subjective "The Impatient's Guide to the HG Book":<br />
<br />
* Chapter 1: Introduction<br>Skip if you already know about VCS and DVCS<br />
* Chapter 2: A tour of Mercurial: the basics<br>Everything from section 2.2 on is '''recommended reading'''. The essential things you need to know to use Mercurial.<br />
* Chapter 3: A tour of Mercurial: merging work<br>Title says it all - '''recommended reading'''<br />
* Chapter 4: Behind the scenes<br>Feel free to skip<br />
* Chapter 5: Mercurial in daily use<br>Despite the title, this chapter seems more confusing than helpful - skip<br />
* Chapter 6: Collaborating with other people<br>Section 6.2 is '''recommended reading''' once you've mastered the basics<br />
* Chapter 7: File names and pattern matching<br>Nothing surprising here - skip<br />
* Chapter 8: Managing releases and branchy development<br>Advanced topic but useful<br />
* Chapter 9: Finding and fixing your mistakes<br>Very useful (but skip sections 9.5 and 9.6)<br />
* You can effectively stop reading after Chapter 9.<br />
* Appendix A may be useful as a reference.<br />
<br />
<br />
[[Category:Development]]<br />
<br />
<br />
== Windows Users - Secret Sauce (if you have commit rights) ==<br />
<br />
I'm using command line Mercurial (I don't like the windows explorer performance hit of the tortoise system). But this works for me, after much messing around.<br />
<br />
# Clone the main Geeklog repository, as above. (geeklog-hg)<br />
# Clone your local copy of Geeklog to give yourself a clean working environment. (geeklog-hg-mine)<br />
# Clone your clean working environment ;-) (geeklog-hg-dev)<br />
# Update /path/to/geeklog-hg/.hg/hgrc to match bellow<br />
# Update /documents and settings/[your user]/mercurial.ini to match the other bellow<br />
<br />
And that works.<br />
<br />
For hgrc:<br />
<br />
<pre>[paths]<br />
default = ssh://[your username]@cvs.geeklog.net//cvsroot/hg/geeklog<br />
</pre><br />
<br />
For mercurial.ini:<br />
<br />
<pre>[ui]<br />
ssh = c:/path/to/putty/plink.exe -ssh -v -l [your username] -pw [your password]<br />
username = [your name] <[your email address]><br />
</pre><br />
<br />
* No quotes are used in defining the .ini paramaters<br />
* Path to plink.exe can not have any spaces in the actual directory names<br />
* When doing the syncronize, in the pop-up dialog, the remote path is: ssh://username@cvs.geeklog.net//cvsroot/hg/geeklog<br />
<br />
So I develop in geeklog-hg-dev, then I winmerge my changes back into geeklog-hg-mine to make sure I never accidentally commit localsettings (paths etc) or hacks, debugs. Then I commit to geeklog-hg-mine, then back to geeklog-hg when that's ready, then push up to master. Complex hey? ;-)</div>Blainehttp://wiki.geeklog.net/index.php?title=Using_Mercurial&diff=4754Using Mercurial2008-11-14T14:28:49Z<p>Blaine: /* Windows Users - Secret Sauce (if you have commit rights) */</p>
<hr />
<div>== Introduction ==<br />
<br />
[http://www.selenic.com/mercurial/ Mercurial] is a distributed version control system (DVCS). The differences to a "traditional" centralized VCS (like CVS or Subversion) include:<br />
<br />
* Users get a self-contained repository that they can commit changes to, even when being offline.<br />
* Changes can be pushed back to the parent repository or even to other repositories.<br />
<br />
Having used CVS since its inception, Geeklog switched to Mercurial after the release of Geeklog 1.5.1. This switch was preceded by an successful experiment using Mercurial during the 2008 [[Google Summer of Code]]. The distributed model did fit this scenario nicely, as each of our students was working on a separate feature. So they had a local repository to check in to (giving them all the benefits of a version control system). Once a feature or part of a feature was done, it could be pushed back to the parent repository. And in the meantime, it was easy to let other people, e.g. their mentor or interested members of the Geeklog community, pull the changes from the student's repository to show things off or get help on a problem.<br />
<br />
== Installing Mercurial ==<br />
<br />
Installation instructions are provided for [http://www.selenic.com/mercurial/wiki/index.cgi/WindowsInstall Windows], [http://www.selenic.com/mercurial/wiki/index.cgi/UnixInstall Mac OS X], and [http://www.selenic.com/mercurial/wiki/index.cgi/UnixInstall Linux]<br />
<br />
== Setup ==<br />
<br />
Geeklog's Mercurial repository is available from this URL:<br />
<br />
: http://project.geeklog.net/cgi-bin/hgwebdir.cgi/geeklog/<br />
<br />
This repository was converted from the CVS repository right after the release of [http://www.geeklog.net/article.php/geeklog-1.5.1 Geeklog 1.5.1].<br />
<br />
To create a copy of that repository, simply do<br />
<br />
<pre>hg clone http://project.geeklog.net/cgi-bin/hgwebdir.cgi/geeklog/ geeklog</pre><br />
<br />
Where the last "geeklog" is just a directory name for the local copy (and can be changed at will). This will give you a fully working local repository that you can commit changes to.<br />
<br />
'''Note:''' The same URL can also be used to browse the repository online. Simply visit that URL with your web browser.<br />
<br />
=== SSH Setup ===<br />
<br />
For ssh access, you need an account on the server. So this is only of interest for the core developers and SoC students.<br />
<br />
You can clone the repository via SSH like so:<br />
<br />
<pre>hg clone ssh://username@cvs.geeklog.net//cvsroot/hg/geeklog geeklog</pre><br />
<br />
Where "username" is your login name and the "geeklog" at the end of the command line is again simply a name for your local directory.<br />
<br />
Please note the slightly odd path syntax with the two slashes after <tt>cvs.geeklog.net</tt> - those are required.<br />
<br />
<br />
== Pushing back ==<br />
<br />
Being able to push changes back to the repository again requires an account on the server. You can either do<br />
<br />
<pre>hg push ssh://username@cvs.geeklog.net//cvsroot/hg/geeklog</pre><br />
<br />
or, to make your life easier, set the <tt>default-push</tt> repository in the <tt>.hg/hgrc</tt> file of your local repository like so:<br />
<br />
<pre>[paths]<br />
default-push = ssh://username@cvs.geeklog.net//cvsroot/hg/geeklog</pre><br />
<br />
(Again, in the ssh: URLs above, replace "username" with your login name)<br />
<br />
=== Trust and Notifications ===<br />
<br />
Changes pushed back into the central repository will trigger an email sent to the geeklog-cvs mailing list. However, that email will only be sent after the following additional steps:<br />
<br />
# log into your account on cvs.geeklog.net<br />
# in your home directory, create a file named <tt>.hgrc</tt><br />
# enter this as the file's content:<br />
<pre>[trusted]<br />
users = geeklog2<br />
groups = users</pre><br />
<br />
This will also get rid of warnings like<br />
: remote: Not trusting file (...) from untrusted user geeklog2, group users<br />
when pushing back changes.<br />
<br />
<br />
== GSoC Repository ==<br />
<br />
The repository used during the 2008 Google Summer of Code is still available from<br />
<br />
: http://project.geeklog.net/cgi-bin/hgwebdir.cgi/gsoc-2008/<br />
<br />
Note that both the URL and the repository name have changed (formerly <tt>Geeklog-SoC</tt>). You can still use your local copies of that repository - you only need to update the <tt>default-push</tt> setting to the new address and name.<br />
<br />
<br />
== Best practices ==<br />
<br />
Since we're all new to Mercurial, this is something we will have to establish as we go along. For starters, the [http://www.selenic.com/mercurial/wiki/ Mercurial Wiki] has a page on [http://www.selenic.com/mercurial/wiki/index.cgi/WorkingPractices Working Practices] that we may want to adopt.<br />
<br />
=== Use a clean incoming repository ===<br />
<br />
Pull changes to a local "incoming" repository but don't work on that repository. Cloning that repository locally is a cheap operation and allows you to easily create multiple copies if necessary, e.g. when working on different features in parallel.<br />
<br />
Push directly from your working repositories, then sync back by pulling the changes back down via your incoming repository.<br />
<br />
=== Merging ===<br />
<br />
If you attempt to push changes to the main repository and receive the error:<br />
pushing to ssh://username@cvs.geeklog.net//cvsroot/geeklog/Geeklog-SoC<br />
searching for changes<br />
abort: push creates new remote heads!<br />
(did you forget to merge? use push -f to force)<br />
Simply pull from the main repository, "hg heads" to see the revision numbers, "hg merge [rev number]" to merge your changes, then commit the changes, and push back to the main repository.<br />
<br />
Also: Don't try to push newly added files while you still have uncommited changes lying around (or you will end up with the above). In that case, it may make sense to make a fresh clone (fast + cheap if you use an "incoming" repository!), add the new files there, then push from the fresh copy.<br />
<br />
=== Username ===<br />
<br />
When committing a change, the username associated with that change will be your local username (login, etc.) - ''not'' the name of your account on the server.<br />
<br />
For a consistent username, add your preferred username to your local <tt>.hgrc</tt> file:<br />
<pre>username = John Doe <john@example.com></pre><br />
The email address is optional.<br />
<br />
''(More tips and tricks to be added here)''<br />
<br />
<br />
== Undoing Changes ==<br />
<br />
To undo changes you made, use one of the following, depending on circumstances:<br />
<br />
* <tt>hg revert</tt><br>to revert changes made before a commit. This will also undo <tt>hg add</tt> and <tt>hg remove</tt>.<br />
* <tt>hg rollback</tt><br>to revert changes that have been commited to the local repository but not been pushed to another repository yet. You can only rollback the last hg command.<br />
* <tt>hg backout</tt><br>to revert changes after they have been commited ''and'' pushed.<br />
<br />
Note that <tt>hg backout</tt> will actually add a new change to the current branch that reverts your previous change. I.e. your change will ''not'' be removed from the repository. Unless you've accidentally committed something super-secret, that's usually fine. Mistakes happen - no need to sweat it.<br />
<br />
<br />
== Documentation ==<br />
<br />
The [http://www.selenic.com/mercurial/wiki/ Mercurial Wiki] is a good place to search for information. For starters, however, [http://hgbook.red-bean.com/ Distributed revision control with Mercurial] aka "the hg book" is a much better place to start. This book is available for download under the Open Publication License.<br />
<br />
Here's the entirely subjective "The Impatient's Guide to the HG Book":<br />
<br />
* Chapter 1: Introduction<br>Skip if you already know about VCS and DVCS<br />
* Chapter 2: A tour of Mercurial: the basics<br>Everything from section 2.2 on is '''recommended reading'''. The essential things you need to know to use Mercurial.<br />
* Chapter 3: A tour of Mercurial: merging work<br>Title says it all - '''recommended reading'''<br />
* Chapter 4: Behind the scenes<br>Feel free to skip<br />
* Chapter 5: Mercurial in daily use<br>Despite the title, this chapter seems more confusing than helpful - skip<br />
* Chapter 6: Collaborating with other people<br>Section 6.2 is '''recommended reading''' once you've mastered the basics<br />
* Chapter 7: File names and pattern matching<br>Nothing surprising here - skip<br />
* Chapter 8: Managing releases and branchy development<br>Advanced topic but useful<br />
* Chapter 9: Finding and fixing your mistakes<br>Very useful (but skip sections 9.5 and 9.6)<br />
* You can effectively stop reading after Chapter 9.<br />
* Appendix A may be useful as a reference.<br />
<br />
<br />
[[Category:Development]]<br />
<br />
<br />
== Windows Users - Secret Sauce (if you have commit rights) ==<br />
<br />
I'm using command line Mercurial (I don't like the windows explorer performance hit of the tortoise system). But this works for me, after much messing around.<br />
<br />
# Clone the main Geeklog repository, as above. (geeklog-hg)<br />
# Clone your local copy of Geeklog to give yourself a clean working environment. (geeklog-hg-mine)<br />
# Clone your clean working environment ;-) (geeklog-hg-dev)<br />
# Update /path/to/geeklog-hg/.hg/hgrc to match bellow<br />
# Update /documents and settings/[your user]/mercurial.ini to match the other bellow<br />
<br />
And that works.<br />
<br />
For hgrc:<br />
<br />
<pre>[paths]<br />
default = ssh://[your username]@cvs.geeklog.net//cvsroot/hg/geeklog<br />
</pre><br />
<br />
For mercurial.ini:<br />
<br />
<pre>[ui]<br />
ssh = c:/path/to/putty/plink.exe -ssh -v -l [your username] -pw [your password]<br />
username = [your name] <[your email address]><br />
</pre><br />
<br />
* No quotes are used in defining the .ini paramaters<br />
* Path to plink.exe can not have any spaces in the actual directory names<br />
* When doing the syncronize, in the pop-up dialog, the remote path is: ssh://loginname@cvs.geeklog.net//cvsroot/hg/geeklog<br />
<br />
So I develop in geeklog-hg-dev, then I winmerge my changes back into geeklog-hg-mine to make sure I never accidentally commit localsettings (paths etc) or hacks, debugs. Then I commit to geeklog-hg-mine, then back to geeklog-hg when that's ready, then push up to master. Complex hey? ;-)</div>Blainehttp://wiki.geeklog.net/index.php?title=SoC_content_translation_service&diff=4558SoC content translation service2008-03-22T13:06:32Z<p>Blaine: </p>
<hr />
<div><center>(Return to the main idea page for the [[Google Summer of Code]])</center><br />
<br />
== Overview ==<br />
Add support for Google's Translation API [http://googleajaxsearchapi.blogspot.com/2008/03/introducing-ajax-language-api-tools-for.html Google's Translation API]<br />
<br />
<br />
== Objective ==<br />
<br />
* Develop a set of core GL API's to support the registration of new notification services and user notification subscriptions.<br />
* Extend the GL Core Story/Blogging and Staticpage features to use the new services<br />
<br />
== Level of Difficulty ==<br />
<br />
''medium to high''<br />
<br />
This project will require someone to spend time understanding how the core GL plugin API works.</div>Blainehttp://wiki.geeklog.net/index.php?title=SoC_content_translation_service&diff=4557SoC content translation service2008-03-22T13:04:04Z<p>Blaine: </p>
<hr />
<div>Add support for Google's Translation API [http://googleajaxsearchapi.blogspot.com/2008/03/introducing-ajax-language-api-tools-for.html Google's Translation API]</div>Blainehttp://wiki.geeklog.net/index.php?title=Google_Summer_of_Code&diff=4556Google Summer of Code2008-03-22T13:02:40Z<p>Blaine: /* For Geeklog 1.x */</p>
<hr />
<div>== What is it? ==<br />
<br />
The [http://code.google.com/soc/ Google Summer of Code™] is a program sponsored by Google where they pay students to develop open source software. In its third incarnation in 2007, Geeklog [[Summer of Code 2007|took part]] in the program for the first time and we have been accepted for 2008 again.<br />
<br />
<br />
== Project Ideas ==<br />
<br />
This is a list of ideas for projects that we feel would add useful functionality to Geeklog. We are open for other ideas not listed here as long as they fit in with Geeklog's general ideas and concepts and can be done in the 3-months period of the Summer of Code program. <br />
<br />
Also, please read the [[Google_Summer_of_Code#Notes_for_Students|Notes for Students]] below.<br />
<br />
=== For Geeklog 1.x ===<br />
<br />
* [[SoC_improving comments_2008|Improving the comments]]<br />
* [[SoC_webservices_revisited|Webservices revisited]]<br />
* [[SoC_install_script_revisited|Install script: Plugins and Migration]]<br />
* [http://swot.fuckingbrit.com/ SWOT] ''(Spam: Web of Trust)''<br />
* [[SoC_mailman|Mailman Plugin]]<br />
* [[SoC_improved_search|Improved Search]]<br />
* [[SoC_socialnetworking|Add Social Networking Features]]<br />
* [[SoC_css_foundation_classes|Implement a theme based on the YUI CSS Foundation Libraries]]<br />
* [[SoC_cross_site_publication|Cross Site Alerting and Publication API]]<br />
* [[SoC_web_analytics_api|Implement Open Web Analytics]]<br />
* [[SoC_core_notification_support|Core Notification Service]]<br />
* [[Soc_content_translation_serice|Google Translation API]]<br />
<br />
There are also some [[SoC_more_ideas|leftover ideas]] from 2007.<br />
<br />
=== For Geeklog 2 ===<br />
<br />
* [[SoC_geeklog2_taxonomy_tagging_plugin| Taxonomy and Tagging Plugin]]<br />
* [[SoC_geeklog2_continuous_builds| Continuous Builds]]<br />
* [[SoC_geeklog2_workflow_plugin| Workflow Plugin]]<br />
* [[SoC_geeklog2_mapping_plugin| Mapping Plugin]]<br />
* [[SoC_geeklog2_syndication_api|Geeklog2 Syndication API]]<br />
* [[SoC_geeklog2_spam_solution|Geeklog2 Anti-Spam "Solution"]]<br />
* [[Soc_geeklog2_media_plugin| Media Plugin]]<br />
* [[Soc_geeklog2_social_plugin| Social Plugin using Google's OpenSocial]]<br />
<br />
<br />
== Notes for Students ==<br />
<br />
=== Required skills ===<br />
<br />
Students interested in any of the above projects should have reasonable experience with PHP and some basic SQL knowledge. Being able to set up your own LAMP server (Linux, Apache, MySQL, PHP) would probably help but isn't a prerequisite.<br />
<br />
=== Background information ===<br />
<br />
Please note that there are '''two''' versions of Geeklog currently under active development but that they share little other than the name and a few contributors.<br />
<br />
* '''Geeklog 1.x''' (currently 1.4.1, with 1.5.0 "almost done") is the software you may have seen running websites such as [http://www.groklaw.net/ Groklaw].<br />
* '''Geeklog 2''' is "the next generation" of Geeklog and has been rewritten from the ground up. There are no released versions of Geeklog 2 yet.<br />
<br />
Geeklog 1.x was started back in the year 2000 and its code is still mostly procedural and it uses its own (thin) database abstraction layer. Geeklog 2, on the other hand, is fully object oriented and uses technologies such as MVC and design patterns.<br />
<br />
So basically, you can choose between working on a system that is in wide use already or one that uses all the latest and greatest in technology but isn't ''quite'' ready for mainstream use yet. In either case, you would be helping the Geeklog community immensely.<br />
<br />
=== License ===<br />
<br />
Geeklog 1.x has been released under the GPLv2 (GNU General Public License, version 2). All code written for Geeklog 1.x projects should also be released under that same license.<br />
<br />
No final decision has been made on the license for Geeklog 2. However, it will most likely ''not'' be the GPL but another [http://www.opensource.org/licenses/ OSI approved] license in the spirit of the BSD license.<br />
<br />
<br />
== Contact ==<br />
<br />
For all questions regarding Geeklog and the Summer of Code, please email us at <tt>contact-us(AT)lists.geeklog.net</tt> or use [http://www.geeklog.net/profiles.php?uid=2&subject=Google%20Summer%20of%20Code%202008 this web form].<br />
<br />
You are also invited to join our [http://lists.geeklog.net/mailman/listinfo/geeklog-devel Development Mailing List] and say "Hi!"<br />
<br />
Or you can hop on our IRC channel: #geeklog at irc.freenode.net and talk to us directly (some patience required - not everyone may be online there all the time).<br />
<br />
<br />
[[Category:Summer of Code]] [[Category:Development]]</div>Blainehttp://wiki.geeklog.net/index.php?title=SoC_web_analytics_api&diff=4476SoC web analytics api2008-03-02T20:35:52Z<p>Blaine: /* Level of Difficulty */</p>
<hr />
<div><center>(Return to the main idea page for the [[Google Summer of Code]])</center><br />
<br />
== Overview ==<br />
<br />
Implement the website analytics API from http://www.openwebanalytics.com and develop a set of core API's so that both the CORE GL modules and plugins can generate metrics for usage and performance related stats.<br />
<br />
<br />
== Objective ==<br />
<br />
* Develop a set of core API services<br />
* Add support for plugins<br />
* Add calls so all core GL modules are instrumented<br />
* Develop the admin interface to control what level of detail and modules will have data collected.<br />
* Develop the reports that are needed. Need tabular and some graphical reporting with export to Excel. Investigate how other projects have implemented the same API and also explore the Google Analytics application for inspiration.<br />
<br />
== Level of Difficulty ==<br />
<br />
''medium''<br />
<br />
This project will require someone to spend time understanding how the core GL plugin API works. <br />
<br />
Students need some User Interface design experience and ability to create graphical and tabular reports. <br />
<br />
Student needs to spend time installing other popular plugins to get a good understanding of the types of data metrics to collect and how plugins will best use this new service.<br />
<br />
[[Category:Summer of Code]] [[Category:Development]]</div>Blainehttp://wiki.geeklog.net/index.php?title=SoC_web_analytics_api&diff=4475SoC web analytics api2008-03-02T20:35:28Z<p>Blaine: </p>
<hr />
<div><center>(Return to the main idea page for the [[Google Summer of Code]])</center><br />
<br />
== Overview ==<br />
<br />
Implement the website analytics API from http://www.openwebanalytics.com and develop a set of core API's so that both the CORE GL modules and plugins can generate metrics for usage and performance related stats.<br />
<br />
<br />
== Objective ==<br />
<br />
* Develop a set of core API services<br />
* Add support for plugins<br />
* Add calls so all core GL modules are instrumented<br />
* Develop the admin interface to control what level of detail and modules will have data collected.<br />
* Develop the reports that are needed. Need tabular and some graphical reporting with export to Excel. Investigate how other projects have implemented the same API and also explore the Google Analytics application for inspiration.<br />
<br />
== Level of Difficulty ==<br />
<br />
''medium''<br />
<br />
This project will require someone to spend time understanding how the core GL plugin API works. <br />
<br />
Students need some User Interface design experience and ability to create graphical and tabular reports. <br />
<br />
Student needs to spend time with installing other popular plugins to get a good understanding of the types of data metrics to collect and how plugins will best use this new service.<br />
<br />
[[Category:Summer of Code]] [[Category:Development]]</div>Blainehttp://wiki.geeklog.net/index.php?title=SoC_core_notification_support&diff=4474SoC core notification support2008-03-02T20:32:06Z<p>Blaine: /* Level of Difficulty */</p>
<hr />
<div><center>(Return to the main idea page for the [[Google Summer of Code]])</center><br />
<br />
== Overview ==<br />
<br />
There are a number of core GL features and plugins that send out email notifications and each plugin or module has to develop their own code. There is no central area for the site admin or members to moderate what they can receive notifications for or how they want them handled.<br />
<br />
There is also the need to add new levels of alerting or allow alerting of additional site events.<br />
<br />
Many plugins would require a more basic level of notification services and others like the forum allow a user to subscribe to a topic or complete forum. If they have subscribed to a complete forum, they can selectively un-subscribe to some topics. The same level of control may be needed for stories, where a user can subscribe to a complete site but then un-subscribe to certain topics or stories by a certain user.<br />
<br />
<br />
== Objective ==<br />
<br />
* Develop a set of core GL API's to support the registration of new notification services and user notification subscriptions.<br />
* Extend the plugin API's to use the new services<br />
* Extend the core GL modules to use the new services<br />
* Develop the notification admin / site admin screen<br />
* Develop the UI and program for the users to manage their notification subscription rules.<br />
<br />
Support for:<br />
* Alert Classification (admin, general, moderation, error ...)<br />
* Alert Type (core, plugin ...)<br />
* Alert Subtype (module specific)<br />
<br />
Only Root or plugin Admin's have access to the admin and error type notifications but this should be a configurable mapping option and controllable via the online notification service admin.<br />
<br />
Users should be able to determine how they want to receive their notifications.<br />
* Admin wants to be emailed on all admin and error notifications<br />
* Admin wants to receive daily digest of all other notifications<br />
* User wants daily digest of all notifications<br />
* Support for RSS Feed per user - using a random hash like URL<br />
* Daily digest format needs to use a template so the site admin can modify it<br />
<br />
<br />
== Use Cases ==<br />
* Site Admin wants to be notified of all new forum topics and MG albums created but not new replies and images uploaded<br />
* User wants daily digest of all MG updates for albums they have access to<br />
* User wants daily digest of all comments to content they have created or have replied to.<br />
* Admin wants daily digest of all items awaiting moderation<br />
* Admin wants to be notified via email of all site logins<br />
* Admin wants to be notified via email of all bad login attempts so they know if a user is now locked out<br />
* Admin wants to be notified of new user signups.<br />
<br />
The site Admin and user can have multiple notification rules setup and setup the email subject, email address so they can filter or redirect notifications.<br />
<br />
== Level of Difficulty ==<br />
<br />
''medium to high''<br />
<br />
This project will require someone to spend time understanding how the core GL plugin API works. Need to install a number of the more popular plugins use notification like features and develope a model of the new notification service API.<br />
<br />
Students should have OO experience and knowledge of say the Observer Design Pattern as that would be a good base for the design of this project.<br />
<br />
[[Category:Summer of Code]] [[Category:Development]]</div>Blainehttp://wiki.geeklog.net/index.php?title=SoC_core_notification_support&diff=4473SoC core notification support2008-03-02T20:30:53Z<p>Blaine: /* Level of Difficulty */</p>
<hr />
<div><center>(Return to the main idea page for the [[Google Summer of Code]])</center><br />
<br />
== Overview ==<br />
<br />
There are a number of core GL features and plugins that send out email notifications and each plugin or module has to develop their own code. There is no central area for the site admin or members to moderate what they can receive notifications for or how they want them handled.<br />
<br />
There is also the need to add new levels of alerting or allow alerting of additional site events.<br />
<br />
Many plugins would require a more basic level of notification services and others like the forum allow a user to subscribe to a topic or complete forum. If they have subscribed to a complete forum, they can selectively un-subscribe to some topics. The same level of control may be needed for stories, where a user can subscribe to a complete site but then un-subscribe to certain topics or stories by a certain user.<br />
<br />
<br />
== Objective ==<br />
<br />
* Develop a set of core GL API's to support the registration of new notification services and user notification subscriptions.<br />
* Extend the plugin API's to use the new services<br />
* Extend the core GL modules to use the new services<br />
* Develop the notification admin / site admin screen<br />
* Develop the UI and program for the users to manage their notification subscription rules.<br />
<br />
Support for:<br />
* Alert Classification (admin, general, moderation, error ...)<br />
* Alert Type (core, plugin ...)<br />
* Alert Subtype (module specific)<br />
<br />
Only Root or plugin Admin's have access to the admin and error type notifications but this should be a configurable mapping option and controllable via the online notification service admin.<br />
<br />
Users should be able to determine how they want to receive their notifications.<br />
* Admin wants to be emailed on all admin and error notifications<br />
* Admin wants to receive daily digest of all other notifications<br />
* User wants daily digest of all notifications<br />
* Support for RSS Feed per user - using a random hash like URL<br />
* Daily digest format needs to use a template so the site admin can modify it<br />
<br />
<br />
== Use Cases ==<br />
* Site Admin wants to be notified of all new forum topics and MG albums created but not new replies and images uploaded<br />
* User wants daily digest of all MG updates for albums they have access to<br />
* User wants daily digest of all comments to content they have created or have replied to.<br />
* Admin wants daily digest of all items awaiting moderation<br />
* Admin wants to be notified via email of all site logins<br />
* Admin wants to be notified via email of all bad login attempts so they know if a user is now locked out<br />
* Admin wants to be notified of new user signups.<br />
<br />
The site Admin and user can have multiple notification rules setup and setup the email subject, email address so they can filter or redirect notifications.<br />
<br />
== Level of Difficulty ==<br />
<br />
''medium''<br />
<br />
This project will require someone to spend time understanding how the core GL plugin API works. Need to install a number of the more popular plugins use notification like features and develope a model of the new notification service API.<br />
<br />
Students should have OO experience and knowledge of say the Observer Design Pattern as that would be a good base for the design of this project.<br />
<br />
[[Category:Summer of Code]] [[Category:Development]]</div>Blainehttp://wiki.geeklog.net/index.php?title=SoC_core_notification_support&diff=4472SoC core notification support2008-03-02T20:23:53Z<p>Blaine: </p>
<hr />
<div><center>(Return to the main idea page for the [[Google Summer of Code]])</center><br />
<br />
== Overview ==<br />
<br />
There are a number of core GL features and plugins that send out email notifications and each plugin or module has to develop their own code. There is no central area for the site admin or members to moderate what they can receive notifications for or how they want them handled.<br />
<br />
There is also the need to add new levels of alerting or allow alerting of additional site events.<br />
<br />
Many plugins would require a more basic level of notification services and others like the forum allow a user to subscribe to a topic or complete forum. If they have subscribed to a complete forum, they can selectively un-subscribe to some topics. The same level of control may be needed for stories, where a user can subscribe to a complete site but then un-subscribe to certain topics or stories by a certain user.<br />
<br />
<br />
== Objective ==<br />
<br />
* Develop a set of core GL API's to support the registration of new notification services and user notification subscriptions.<br />
* Extend the plugin API's to use the new services<br />
* Extend the core GL modules to use the new services<br />
* Develop the notification admin / site admin screen<br />
* Develop the UI and program for the users to manage their notification subscription rules.<br />
<br />
Support for:<br />
* Alert Classification (admin, general, moderation, error ...)<br />
* Alert Type (core, plugin ...)<br />
* Alert Subtype (module specific)<br />
<br />
Only Root or plugin Admin's have access to the admin and error type notifications but this should be a configurable mapping option and controllable via the online notification service admin.<br />
<br />
Users should be able to determine how they want to receive their notifications.<br />
* Admin wants to be emailed on all admin and error notifications<br />
* Admin wants to receive daily digest of all other notifications<br />
* User wants daily digest of all notifications<br />
* Support for RSS Feed per user - using a random hash like URL<br />
* Daily digest format needs to use a template so the site admin can modify it<br />
<br />
<br />
== Use Cases ==<br />
* Site Admin wants to be notified of all new forum topics and MG albums created but not new replies and images uploaded<br />
* User wants daily digest of all MG updates for albums they have access to<br />
* User wants daily digest of all comments to content they have created or have replied to.<br />
* Admin wants daily digest of all items awaiting moderation<br />
* Admin wants to be notified via email of all site logins<br />
* Admin wants to be notified via email of all bad login attempts so they know if a user is now locked out<br />
* Admin wants to be notified of new user signups.<br />
<br />
The site Admin and user can have multiple notification rules setup and setup the email subject, email address so they can filter or redirect notifications.<br />
<br />
== Level of Difficulty ==<br />
<br />
''medium''<br />
<br />
This project will require someone to spend time understanding<br />
<br />
[[Category:Summer of Code]] [[Category:Development]]</div>Blainehttp://wiki.geeklog.net/index.php?title=SoC_improved_search&diff=4471SoC improved search2008-03-02T20:22:28Z<p>Blaine: /* Initial Ideas */</p>
<hr />
<div><center>(Return to the main idea page for the [[Google Summer of Code]])</center><br />
<br />
== Incentive ==<br />
Many Geeklog sites have a lot of content spread across multiple plugins. Content can have different access rights so that needs to be respected when content search is made. <br />
There is a need to better display the search results and improve the search speed and ability for the user to refine their search and filter/sort the displayed search results.<br />
<br />
== Initial Ideas ==<br />
* Tags, Tag Cloud: Ability to define tags, admin tags and search/browse using tags<br />
* AJAX powered to improve the responsiveness of the UI and reduce the page refresh<br />
* Better Formatting or layout options<br />
* Sub Filtering of results<br />
* Search within results<br />
* Listing to have sortable headings and able to change view to see results for all or selected plugins<br />
* User able to change the number of records per page and set preference<br />
* Improved API - plugins need to be able to tie into the new search features<br />
* Option on content to be excluded from search. So some public staticpages are not to be returned in searches.<br />
<br />
== Level of Difficulty ==<br />
''medium to high''<br />
<br />
This project will require someone to spend time understanding out the existing Search feature works, how plugins tie into the search, how the search class works.<br />
<br />
Students will need to have experience to suggest how the ideas above would best be implemented and should likley do a proof of concept. Exploring how other tools provide search servics is a good approach to develop ideas.<br />
<br />
Experience with User Interface design will benefit so that search implementation improvements can be made.<br />
<br />
[[Category:Summer of Code]] [[Category:Development]]</div>Blainehttp://wiki.geeklog.net/index.php?title=SoC_improved_search&diff=4470SoC improved search2008-03-02T20:20:45Z<p>Blaine: /* Incentive */</p>
<hr />
<div><center>(Return to the main idea page for the [[Google Summer of Code]])</center><br />
<br />
== Incentive ==<br />
Many Geeklog sites have a lot of content spread across multiple plugins. Content can have different access rights so that needs to be respected when content search is made. <br />
There is a need to better display the search results and improve the search speed and ability for the user to refine their search and filter/sort the displayed search results.<br />
<br />
== Initial Ideas ==<br />
* Tags, Tag Cloud<br />
* AJAX powered<br />
* Better Formatting or layout options<br />
* Sub Filtering of results<br />
* Search within results<br />
* Listing to have sortable headings and able to change view to see results for all or selected plugins<br />
* User able to change the number of records per page and set preference<br />
* Improved API<br />
* Option on content to be excluded from search. So some public staticpages are not to be returned in searches.<br />
<br />
== Level of Difficulty ==<br />
''medium to high''<br />
<br />
This project will require someone to spend time understanding out the existing Search feature works, how plugins tie into the search, how the search class works.<br />
<br />
Students will need to have experience to suggest how the ideas above would best be implemented and should likley do a proof of concept. Exploring how other tools provide search servics is a good approach to develop ideas.<br />
<br />
Experience with User Interface design will benefit so that search implementation improvements can be made.<br />
<br />
[[Category:Summer of Code]] [[Category:Development]]</div>Blainehttp://wiki.geeklog.net/index.php?title=SoC_improved_search&diff=4469SoC improved search2008-03-02T20:20:25Z<p>Blaine: /* Incentive */</p>
<hr />
<div><center>(Return to the main idea page for the [[Google Summer of Code]])</center><br />
<br />
== Incentive ==<br />
Many Geeklog sites have a lot of content spread across multiple plugins. Content can have different access rights so that needs to be respected when content search is made. <br />
<br />
There is a need to better display the search results and improve the search speed and ability for the user to refine their search and filter/sort the displayed search results.<br />
<br />
== Initial Ideas ==<br />
* Tags, Tag Cloud<br />
* AJAX powered<br />
* Better Formatting or layout options<br />
* Sub Filtering of results<br />
* Search within results<br />
* Listing to have sortable headings and able to change view to see results for all or selected plugins<br />
* User able to change the number of records per page and set preference<br />
* Improved API<br />
* Option on content to be excluded from search. So some public staticpages are not to be returned in searches.<br />
<br />
== Level of Difficulty ==<br />
''medium to high''<br />
<br />
This project will require someone to spend time understanding out the existing Search feature works, how plugins tie into the search, how the search class works.<br />
<br />
Students will need to have experience to suggest how the ideas above would best be implemented and should likley do a proof of concept. Exploring how other tools provide search servics is a good approach to develop ideas.<br />
<br />
Experience with User Interface design will benefit so that search implementation improvements can be made.<br />
<br />
[[Category:Summer of Code]] [[Category:Development]]</div>Blainehttp://wiki.geeklog.net/index.php?title=SoC_improved_search&diff=4468SoC improved search2008-03-02T20:17:42Z<p>Blaine: /* Initial Ideas */</p>
<hr />
<div><center>(Return to the main idea page for the [[Google Summer of Code]])</center><br />
<br />
== Incentive ==<br />
<br />
The current Geeklog search service is in need of an update and this project is a placeholder to collect ideas on what that would include.<br />
<br />
<br />
== Initial Ideas ==<br />
* Tags, Tag Cloud<br />
* AJAX powered<br />
* Better Formatting or layout options<br />
* Sub Filtering of results<br />
* Search within results<br />
* Listing to have sortable headings and able to change view to see results for all or selected plugins<br />
* User able to change the number of records per page and set preference<br />
* Improved API<br />
* Option on content to be excluded from search. So some public staticpages are not to be returned in searches.<br />
<br />
== Level of Difficulty ==<br />
''medium to high''<br />
<br />
This project will require someone to spend time understanding out the existing Search feature works, how plugins tie into the search, how the search class works.<br />
<br />
Students will need to have experience to suggest how the ideas above would best be implemented and should likley do a proof of concept. Exploring how other tools provide search servics is a good approach to develop ideas.<br />
<br />
Experience with User Interface design will benefit so that search implementation improvements can be made.<br />
<br />
[[Category:Summer of Code]] [[Category:Development]]</div>Blainehttp://wiki.geeklog.net/index.php?title=SoC_cross_site_publication&diff=4467SoC cross site publication2008-03-02T20:12:00Z<p>Blaine: /* Level of Difficulty */</p>
<hr />
<div><center>(Return to the main idea page for the [[Google Summer of Code]])</center><br />
<br />
== Overview ==<br />
<br />
Develop an Alerting and Cross Site Publication API that can be used among trusted sites. There would be two modes which can both be enabled or not (i: Peer to Peer, ii: Hub based distribution)<br />
<br />
Sites would need to subscribe to remote sites (Peers) and be approved. They would have the ability to query the remote sites for the types of alerts or publishing services available. Source site would need to approve all requests unless alert service was setup as public.<br />
<br />
Each alert or publish event would have a number of rules once an update is available. The Rules need to be flexible or extendable but initially for alerts, it may be to publish the alert on the site in an alert area, or send an email to the site admin. Option to be published automatic or moderated per source. So I may want to publish alerts from Geeklog.net automatically but moderate them from other sites I have setup.<br />
<br />
Plugin should use the GL 1.5 Config Manager to provide the online configuration admin.<br />
<br />
== Use Cases ==<br />
<br />
* Geeklog.net setup as hub where security updates can be broadcasted to all subscribing sites.<br />
* Plugin Developers can use the service to send out update notices. The plugin Editor could pull developer sites and request the latest version<br />
* A ring of community sites may want to send out lost-pet alerts or crime alerts.<br />
* Service could be used to push spam site updates to a hub and then subscribers get updates automatically<br />
<br />
Flexible rules or options will make this a more valuable service. <br />
* Announcements on siteA are picked up by SiteB and published to Topic ABC.<br />
** The SiteB's story indicates that it was originally published on SiteA by John Hanover.<br />
* Announcements on SiteA are picked up by SiteC.<br />
** An email alert is sent to site Admin to approve before publishing.<br />
<br />
<br />
== More details or ideas ==<br />
<br />
Content could be pulled from remote site but cached with a configurable expiry age. Source site can at any time send out an update event which clears the cache.<br />
<br />
Content can also be setup to be published and saved locally on the remote site. The source site can still send out an update event but admin would need to approve update. This may be usefull for GL community sites to share announcements and have then published automatically on their local sites.<br />
<br />
== Level of Difficulty ==<br />
''medium''<br />
<br />
This project will require someone to spend time understanding how to develop a Geeklog plugin.<br />
[[Category:Summer of Code]] [[Category:Development]]</div>Blainehttp://wiki.geeklog.net/index.php?title=SoC_cross_site_publication&diff=4466SoC cross site publication2008-03-02T20:11:46Z<p>Blaine: </p>
<hr />
<div><center>(Return to the main idea page for the [[Google Summer of Code]])</center><br />
<br />
== Overview ==<br />
<br />
Develop an Alerting and Cross Site Publication API that can be used among trusted sites. There would be two modes which can both be enabled or not (i: Peer to Peer, ii: Hub based distribution)<br />
<br />
Sites would need to subscribe to remote sites (Peers) and be approved. They would have the ability to query the remote sites for the types of alerts or publishing services available. Source site would need to approve all requests unless alert service was setup as public.<br />
<br />
Each alert or publish event would have a number of rules once an update is available. The Rules need to be flexible or extendable but initially for alerts, it may be to publish the alert on the site in an alert area, or send an email to the site admin. Option to be published automatic or moderated per source. So I may want to publish alerts from Geeklog.net automatically but moderate them from other sites I have setup.<br />
<br />
Plugin should use the GL 1.5 Config Manager to provide the online configuration admin.<br />
<br />
== Use Cases ==<br />
<br />
* Geeklog.net setup as hub where security updates can be broadcasted to all subscribing sites.<br />
* Plugin Developers can use the service to send out update notices. The plugin Editor could pull developer sites and request the latest version<br />
* A ring of community sites may want to send out lost-pet alerts or crime alerts.<br />
* Service could be used to push spam site updates to a hub and then subscribers get updates automatically<br />
<br />
Flexible rules or options will make this a more valuable service. <br />
* Announcements on siteA are picked up by SiteB and published to Topic ABC.<br />
** The SiteB's story indicates that it was originally published on SiteA by John Hanover.<br />
* Announcements on SiteA are picked up by SiteC.<br />
** An email alert is sent to site Admin to approve before publishing.<br />
<br />
<br />
== More details or ideas ==<br />
<br />
Content could be pulled from remote site but cached with a configurable expiry age. Source site can at any time send out an update event which clears the cache.<br />
<br />
Content can also be setup to be published and saved locally on the remote site. The source site can still send out an update event but admin would need to approve update. This may be usefull for GL community sites to share announcements and have then published automatically on their local sites.<br />
<br />
== Level of Difficulty ==<br />
<br />
''medium''<br />
<br />
This project will require someone to spend time understanding how to develop a Geeklog plugin.<br />
[[Category:Summer of Code]] [[Category:Development]]</div>Blainehttp://wiki.geeklog.net/index.php?title=SoC_mailman&diff=4465SoC mailman2008-03-02T18:57:56Z<p>Blaine: </p>
<hr />
<div><center>(Return to the main idea page for the [[Google Summer of Code]])</center><br />
<br />
== Incentive ==<br />
<br />
The [http://www.list.org/ Mailman] program is one of the most commonly used programs for adminstrating mailing lists and is usually the only installed solution on a hosted service.<br />
<br />
Mailman is used to maintain list subscriptions where users can self register and un-register. The lists are then used for email either as a normal or moderated email list for automatic distribution. You can also have a closed use list that can only be used by moderators.<br />
<br />
Mailman is written in Python while Geeklog is written in PHP but there is presently a Mailman project to develope a set of [http://wiki.list.org/display/DEV/REST+Interface REST API's]<br />
<br />
In an email discussion with Bruce Warsaw of the Mailman project, he expressed that the Mailman REST API is an active project. Much of the needed API's are there now and and more work is being planned for both the 2.2 and 3.0 versions as a high priority. He is very interested in pursuing this as a SOC project.<br />
<br />
== Objective ==<br />
<br />
* Develop a set of Mailman wrappers for the REST API's<br />
* Develop a MailMan plugin<br />
* Integrate the subscriber list admin features (add/remove) into the GL member profile<br />
* Mailman password can be sync'ed with GL password<br />
* List Admin Features to manage lists<br />
** Add/Delete List (support for multiple lists)<br />
** List Types: Public, private (GL Groups) and moderated<br />
** Add/Remove Subscribers<br />
** Import in subscribers<br />
** Subscribers can be GL members and non-site members<br />
** Moderate Lists<br />
** Use list to send out newsetters, notifications (mailings)<br />
** Support for HTML and text mailings<br />
* Plugin will use the 1.5 Config Manager API's for online config admin<br />
<br />
<br />
== Options ==<br />
<br />
# Add support for as much control as possible over the pages the user would go to in order to subscribe and un-subscribe. It would be nice to always have site control over the look and feel for all the pages the user would be directed to.<br />
# Support for both automatic registration/un-registration based on email address and authenticated mode that requires an email confirmation.<br />
<br />
<br />
== Level of Difficulty ==<br />
<br />
''medium''<br />
<br />
This project will require someone to spend time understanding how Mailman works as well as how to develop a Geeklog plugin. The student will need to coordinate with the Mailman team or GSOC student assigned to work on the Mailman REST API's.<br />
<br />
[[Category:Summer of Code]] [[Category:Development]]</div>Blainehttp://wiki.geeklog.net/index.php?title=SoC_socialnetworking&diff=4464SoC socialnetworking2008-03-02T18:54:04Z<p>Blaine: /* Level of Difficulty */</p>
<hr />
<div><center>(Return to the main idea page for the [[Google Summer of Code]])</center><br />
<br />
== Incentive ==<br />
<br />
Geeklog does not have any current core features for individual members to develop their own trusted friends list so they for which they can share content with.<br />
<br />
== Goals ==<br />
<br />
Geeklog has the idea or Groups which the site Admin can setup but users can not define their own groups or list of friends. Users would need to accept the inviation to join another members group but once joined they could view each others private content as determined by the content owner.<br />
<br />
Sites like Facebook do this well and can be a model for what is needed. Users should be able to define multiple access control profiles so not all friends have to be give the same access to a users content.<br />
* Develop Trusted Members interface and control/access to trusted content<br />
* Add new GL API support for plugins to use new features<br />
* Extend Member profile page to have "Add to Friends" link if not a friend<br />
<br />
== Use Cases ==<br />
* Users features or blocks can be added so that I can easily monitor new updates to the site by my friends or watch list. <br />
* A user could create a private MediaGallery Album and then setup access to their friends list.<br />
* The forum could allow users to post new topics that are only seen by the author and their friends and only their friends can reply to.<br />
<br />
== Optional Ideas ==<br />
* Implement Google's [http://code.google.com/apis/opensocial/ OpenSocial API]<br />
* Support for [http://www.apml.org/ APML] (Attention Profile Markup Language)<br />
<br />
== Level of Difficulty ==<br />
<br />
''medium''<br />
<br />
This project will require someone to spend time understanding how Geeklog maintains permissions and it's permission related functions. This could be implemented as a plugin but I suspect changes to the CORE SEC functions may be needed to extend the new permission checks.<br />
<br />
As noted, new API's need to be created so other plugins can use the new features so this is not likely a plugin by itself but extensions to the core code.<br />
<br />
UI changes will be needed to integrate these new features so a user can manage their friends list and different access profiles.<br />
<br />
<br />
[[Category:Summer of Code]] [[Category:Development]]</div>Blainehttp://wiki.geeklog.net/index.php?title=SoC_socialnetworking&diff=4463SoC socialnetworking2008-03-02T18:53:50Z<p>Blaine: /* Level of Difficulty */</p>
<hr />
<div><center>(Return to the main idea page for the [[Google Summer of Code]])</center><br />
<br />
== Incentive ==<br />
<br />
Geeklog does not have any current core features for individual members to develop their own trusted friends list so they for which they can share content with.<br />
<br />
== Goals ==<br />
<br />
Geeklog has the idea or Groups which the site Admin can setup but users can not define their own groups or list of friends. Users would need to accept the inviation to join another members group but once joined they could view each others private content as determined by the content owner.<br />
<br />
Sites like Facebook do this well and can be a model for what is needed. Users should be able to define multiple access control profiles so not all friends have to be give the same access to a users content.<br />
* Develop Trusted Members interface and control/access to trusted content<br />
* Add new GL API support for plugins to use new features<br />
* Extend Member profile page to have "Add to Friends" link if not a friend<br />
<br />
== Use Cases ==<br />
* Users features or blocks can be added so that I can easily monitor new updates to the site by my friends or watch list. <br />
* A user could create a private MediaGallery Album and then setup access to their friends list.<br />
* The forum could allow users to post new topics that are only seen by the author and their friends and only their friends can reply to.<br />
<br />
== Optional Ideas ==<br />
* Implement Google's [http://code.google.com/apis/opensocial/ OpenSocial API]<br />
* Support for [http://www.apml.org/ APML] (Attention Profile Markup Language)<br />
<br />
== Level of Difficulty ==<br />
<br />
''medium''<br />
<br />
This project will require someone to spend time understanding how Geeklog maintains permissions and it's permission related functions. This could be implemented as a plugin but I suspect changes to the CORE SEC functions may be needed to extend the new permission checks.<br />
<br />
As noted, new API's need to be created so other plugins can use the new features so this is not likely a plugin by itself but extensions to the core code.<br />
<br />
UI changes will be needed to integrate these new features so a user can manager their friends list and different access profiles.<br />
<br />
<br />
[[Category:Summer of Code]] [[Category:Development]]</div>Blainehttp://wiki.geeklog.net/index.php?title=SoC_socialnetworking&diff=4462SoC socialnetworking2008-03-02T18:52:12Z<p>Blaine: /* Goals */</p>
<hr />
<div><center>(Return to the main idea page for the [[Google Summer of Code]])</center><br />
<br />
== Incentive ==<br />
<br />
Geeklog does not have any current core features for individual members to develop their own trusted friends list so they for which they can share content with.<br />
<br />
== Goals ==<br />
<br />
Geeklog has the idea or Groups which the site Admin can setup but users can not define their own groups or list of friends. Users would need to accept the inviation to join another members group but once joined they could view each others private content as determined by the content owner.<br />
<br />
Sites like Facebook do this well and can be a model for what is needed. Users should be able to define multiple access control profiles so not all friends have to be give the same access to a users content.<br />
* Develop Trusted Members interface and control/access to trusted content<br />
* Add new GL API support for plugins to use new features<br />
* Extend Member profile page to have "Add to Friends" link if not a friend<br />
<br />
== Use Cases ==<br />
* Users features or blocks can be added so that I can easily monitor new updates to the site by my friends or watch list. <br />
* A user could create a private MediaGallery Album and then setup access to their friends list.<br />
* The forum could allow users to post new topics that are only seen by the author and their friends and only their friends can reply to.<br />
<br />
== Optional Ideas ==<br />
* Implement Google's [http://code.google.com/apis/opensocial/ OpenSocial API]<br />
* Support for [http://www.apml.org/ APML] (Attention Profile Markup Language)<br />
<br />
== Level of Difficulty ==<br />
<br />
''medium''<br />
<br />
This project will require someone to spend time understanding how Geeklog maintains permissions and it's permission functions. This could be implemented as a plugin but I suspect changes to the CORE SEC functions may be needed to extend the new permission checks.<br />
<br />
UI changes will be needed to integrate these new features so a user can manager their friends list and different access profiles.<br />
<br />
<br />
[[Category:Summer of Code]] [[Category:Development]]</div>Blainehttp://wiki.geeklog.net/index.php?title=SoC_socialnetworking&diff=4461SoC socialnetworking2008-03-02T18:51:26Z<p>Blaine: </p>
<hr />
<div><center>(Return to the main idea page for the [[Google Summer of Code]])</center><br />
<br />
== Incentive ==<br />
<br />
Geeklog does not have any current core features for individual members to develop their own trusted friends list so they for which they can share content with.<br />
<br />
== Goals ==<br />
<br />
Geeklog has the idea or Groups which the site Admin can setup but users can not define their own groups or list of friends. Users would need to accept the inviation to join another members group but once joined they could view each others private content as determined by the content owner.<br />
<br />
Sites like Facebook do this well and can be a model for what is needed. Users should be able to define multiple access control profiles so not all friends have to be give the same access to a users content.<br />
<br />
<br />
* Develop Trusted Members interface and control/access to trusted content<br />
* Add new GL API support for plugins to use new features<br />
* Extend Member profile page to have "Add to Friends" link if not a friend<br />
<br />
== Use Cases ==<br />
* Users features or blocks can be added so that I can easily monitor new updates to the site by my friends or watch list. <br />
* A user could create a private MediaGallery Album and then setup access to their friends list.<br />
* The forum could allow users to post new topics that are only seen by the author and their friends and only their friends can reply to.<br />
<br />
== Optional Ideas ==<br />
* Implement Google's [http://code.google.com/apis/opensocial/ OpenSocial API]<br />
* Support for [http://www.apml.org/ APML] (Attention Profile Markup Language)<br />
<br />
== Level of Difficulty ==<br />
<br />
''medium''<br />
<br />
This project will require someone to spend time understanding how Geeklog maintains permissions and it's permission functions. This could be implemented as a plugin but I suspect changes to the CORE SEC functions may be needed to extend the new permission checks.<br />
<br />
UI changes will be needed to integrate these new features so a user can manager their friends list and different access profiles.<br />
<br />
<br />
[[Category:Summer of Code]] [[Category:Development]]</div>Blainehttp://wiki.geeklog.net/index.php?title=SoC_socialnetworking&diff=4460SoC socialnetworking2008-03-02T18:50:27Z<p>Blaine: /* Goals */</p>
<hr />
<div><center>(Return to the main idea page for the [[Google Summer of Code]])</center><br />
<br />
== Incentive ==<br />
<br />
Geeklog does not have any current core features for individual members to develop their own trusted friends list so they for which they can share content with.<br />
<br />
== Goals ==<br />
<br />
Geeklog has the idea or Groups which the site Admin can setup but users can not define their own groups or list of friends. Users would need to accept the inviation to join another members group but once joined they could view each others private content as determined by the content owner.<br />
<br />
Sites like Facebook do this well and can be a model for what is needed. Users should be able to define multiple access control profiles so not all friends have to be give the same access to a users content.<br />
<br />
<br />
* Develop Trusted Members interface and control/access to trusted content<br />
* Add new GL API support for plugins to use new features<br />
* Extend Member profile page to have "Add to Friends" link if not a friend<br />
<br />
== Use Cases ==<br />
Users features or blocks can be added so that I can easily monitor new updates to the site by my friends or watch list. <br />
<br />
A user could create a private MediaGallery Album and then setup access to their friends list.<br />
<br />
The forum could allow users to post new topics that are only seen by the author and their friends and only their friends can reply to.<br />
<br />
== Optional Ideas ==<br />
* Implement Google's [http://code.google.com/apis/opensocial/ OpenSocial API]<br />
* Support for [http://www.apml.org/ APML] (Attention Profile Markup Language)<br />
<br />
== Level of Difficulty ==<br />
<br />
''medium''<br />
<br />
This project will require someone to spend time understanding how Geeklog maintains permissions and it's permission functions. This could be implemented as a plugin but I suspect changes to the CORE SEC functions may be needed to extend the new permission checks.<br />
<br />
UI changes will be needed to integrate these new features so a user can manager their friends list and different access profiles.<br />
<br />
<br />
[[Category:Summer of Code]] [[Category:Development]]</div>Blainehttp://wiki.geeklog.net/index.php?title=SoC_socialnetworking&diff=4459SoC socialnetworking2008-03-02T18:42:32Z<p>Blaine: /* Ideas */</p>
<hr />
<div><center>(Return to the main idea page for the [[Google Summer of Code]])</center><br />
<br />
== Incentive ==<br />
<br />
Geeklog does not have any current core features for individual members to develop their own trusted friends list so they for which they can share content with.<br />
<br />
== Goals ==<br />
<br />
Geeklog has the idea or Groups which the site Admin can setup but users can not define their own groups or list of friends. Users would need to accept the inviation to join another members group but once joined they could view each others private content as determined by the content owner.<br />
<br />
Sites like Facebook do this well and can be a model for what is needed. Users should be able to define multiple access control profiles so not all friends have to be give the same access to a users content.<br />
<br />
* Develop Trusted Members interface and control/access to trusted content<br />
* Add new GL API support for plugins to use new features<br />
<br />
== Optional Ideas ==<br />
* Implement Google's [http://code.google.com/apis/opensocial/ OpenSocial API]<br />
* Support for [http://www.apml.org/ APML] (Attention Profile Markup Language)<br />
<br />
== Level of Difficulty ==<br />
<br />
''medium''<br />
<br />
This project will require someone to spend time understanding how Geeklog maintains permissions and it's permission functions. This could be implemented as a plugin but I suspect changes to the CORE SEC functions may be needed to extend the new permission checks.<br />
<br />
UI changes will be needed to integrate these new features so a user can manager their friends list and different access profiles.<br />
<br />
<br />
[[Category:Summer of Code]] [[Category:Development]]</div>Blainehttp://wiki.geeklog.net/index.php?title=SoC_socialnetworking&diff=4458SoC socialnetworking2008-03-02T18:42:09Z<p>Blaine: </p>
<hr />
<div><center>(Return to the main idea page for the [[Google Summer of Code]])</center><br />
<br />
== Incentive ==<br />
<br />
Geeklog does not have any current core features for individual members to develop their own trusted friends list so they for which they can share content with.<br />
<br />
== Ideas ==<br />
<br />
Geeklog has the idea or Groups which the site Admin can setup but users can not define their own groups or list of friends. Users would need to accept the inviation to join another members group but once joined they could view each others private content as determined by the content owner.<br />
<br />
Sites like Facebook do this well and can be a model for what is needed. Users should be able to define multiple access control profiles so not all friends have to be give the same access to a users content.<br />
<br />
* Develop Trusted Members interface and control/access to trusted content<br />
* Add new GL API support for plugins to use new features<br />
<br />
== Optional Ideas ==<br />
* Implement Google's [http://code.google.com/apis/opensocial/ OpenSocial API]<br />
* Support for [http://www.apml.org/ APML] (Attention Profile Markup Language)<br />
<br />
== Level of Difficulty ==<br />
<br />
''medium''<br />
<br />
This project will require someone to spend time understanding how Geeklog maintains permissions and it's permission functions. This could be implemented as a plugin but I suspect changes to the CORE SEC functions may be needed to extend the new permission checks.<br />
<br />
UI changes will be needed to integrate these new features so a user can manager their friends list and different access profiles.<br />
<br />
<br />
[[Category:Summer of Code]] [[Category:Development]]</div>Blainehttp://wiki.geeklog.net/index.php?title=Main_Page&diff=4449Main Page2008-02-24T16:19:58Z<p>Blaine: /* Geeklog Documentation */</p>
<hr />
<div>[[Image:Logo.gif]]<br />
<br />
== Geeklog Documentation ==<br />
<br />
This is the main entry for Documentation for the [http://www.geeklog.net Geeklog Portal System]. The current version is 1.4x. The next generation portal is also under development and documentation for it will be posted here as it becomes available.<br />
<br />
This documentation is a result of community action. Everyone is invited to sign up and participate. If you see an omission you can fill it in. If you see a mistake, correct it. If you see where things could be better organized, change it. If you have a note about a particular configuration, add it. In other words we need your help to make it better.<br />
<br />
Authors note that you can refer to yourself or sign your work by linking to User:Youruserid, the shorthand for this is three tildes. This points initially to nothing but a blank page on which you can enter whatever info you want about yourself. You can also reach this page by clicking on your userid at the top of the page when you are logged in.<br />
<br />
#[[Geeklog_1.3x_Documentation]]<br />
#[[Geeklog_1.4x_Documentation]]<br />
#[[Geeklog 2x Documentation]]<br />
#[[PEAR::Auth_Enterprise Documentation]]<br />
#[[Google_Summer_of_Code]]</div>Blainehttp://wiki.geeklog.net/index.php?title=SoC_mailman&diff=4448SoC mailman2008-02-24T16:17:18Z<p>Blaine: /* Objective */</p>
<hr />
<div><center>(Return to the main idea page for the [[Google Summer of Code]])</center><br />
<br />
== Incentive ==<br />
<br />
The [http://www.list.org/ Mailman] program is one of the most commonly used programs for adminstrating mailing lists and is usually the only installed solution on a hosted service.<br />
<br />
Mailman is used to maintain list subscriptions where users can self register and un-register. The lists are then used for email either as a normal or moderated email list for automatic distribution. You can also have a closed use list that can only be used by moderators.<br />
<br />
Mailman is written in Python while Geeklog is written in PHP but there is presently a Mailman project to develope a set of [http://wiki.list.org/display/DEV/REST+Interface REST API's]<br />
<br />
In an email discussion with Bruce Warsaw of the Mailman project, he expressed that the Mailman REST API is an active project. Much of the needed API's are there now and and more work is being planned for both the 2.2 and 3.0 versions as a high priority. He is very interested in pursuing this as a SOC project.<br />
<br />
== Objective ==<br />
<br />
* Develop a set of Mailman wrappers for the REST API's<br />
* Develop a MailMan plugin<br />
* Integrate the subscriber list admin features (add/remove) into the GL member profile<br />
* Mailman password can be sync'ed with GL password<br />
* List Admin Features to manage lists<br />
** Add/Delete List (support for multiple lists)<br />
** List Types: Public, private (GL Groups) and moderated<br />
** Add/Remove Subscribers<br />
** Import in subscribers<br />
** Subscribers can be GL members and non-site members<br />
** Moderate Lists<br />
** Use list to send out newsetters, notifications (mailings)<br />
** Support for HTML and text mailings<br />
<br />
== Options ==<br />
<br />
# Add support for as much control as possible over the pages the user would go to in order to subscribe and un-subscribe. It would be nice to always have site control over the look and feel for all the pages the user would be directed to.<br />
# Support for both automatic registration/un-registration based on email address and authenticated mode that requires an email confirmation.<br />
<br />
<br />
[[Category:Summer of Code]] [[Category:Development]]</div>Blainehttp://wiki.geeklog.net/index.php?title=SoC_mailman&diff=4447SoC mailman2008-02-24T16:16:26Z<p>Blaine: /* Incentive */</p>
<hr />
<div><center>(Return to the main idea page for the [[Google Summer of Code]])</center><br />
<br />
== Incentive ==<br />
<br />
The [http://www.list.org/ Mailman] program is one of the most commonly used programs for adminstrating mailing lists and is usually the only installed solution on a hosted service.<br />
<br />
Mailman is used to maintain list subscriptions where users can self register and un-register. The lists are then used for email either as a normal or moderated email list for automatic distribution. You can also have a closed use list that can only be used by moderators.<br />
<br />
Mailman is written in Python while Geeklog is written in PHP but there is presently a Mailman project to develope a set of [http://wiki.list.org/display/DEV/REST+Interface REST API's]<br />
<br />
In an email discussion with Bruce Warsaw of the Mailman project, he expressed that the Mailman REST API is an active project. Much of the needed API's are there now and and more work is being planned for both the 2.2 and 3.0 versions as a high priority. He is very interested in pursuing this as a SOC project.<br />
<br />
== Objective ==<br />
<br />
* Develop a set of MailMan wrappers for the REST API's<br />
* Develop a MailMan plugin<br />
* Integrate the subscriber list admin features (add/remove) into the GL member profile<br />
* MailMan password can be sync'ed with GL password<br />
* List Admin Features to manage lists<br />
** Add/Delete List (support for multiple lists)<br />
** List Types: Public, private (GL Groups) and moderated<br />
** Add/Remove Subscribers<br />
** Import in subscribers<br />
** Subscribers can be GL members and non-site members<br />
** Moderate Lists<br />
** Use list to send out newsetters, notifications (mailings)<br />
** Support for HTML and text mailings<br />
<br />
<br />
== Options ==<br />
<br />
# Add support for as much control as possible over the pages the user would go to in order to subscribe and un-subscribe. It would be nice to always have site control over the look and feel for all the pages the user would be directed to.<br />
# Support for both automatic registration/un-registration based on email address and authenticated mode that requires an email confirmation.<br />
<br />
<br />
[[Category:Summer of Code]] [[Category:Development]]</div>Blainehttp://wiki.geeklog.net/index.php?title=SoC_mailman&diff=4446SoC mailman2008-02-24T16:15:49Z<p>Blaine: /* Incentive */</p>
<hr />
<div><center>(Return to the main idea page for the [[Google Summer of Code]])</center><br />
<br />
== Incentive ==<br />
<br />
The [http://www.list.org/ Mailman] program is one of the most commonly used programs for adminstrating mailing lists and is usually the only installed solution on a hosted service.<br />
<br />
Mailman is used to maintain list subscriptions where users can self register and un-register. The lists are then used for email either as a normal or moderated email list for automatic distribution. You can also have a closed use list that can only be used by moderators.<br />
<br />
Mailman is written in Python while Geeklog is written in PHP but there is presently a Mailman project to develope a set of [http://wiki.list.org/display/DEV/REST+Interface REST API's]<br />
<br />
In an email discussion with Bruce Warsaw of the Mailman project, he expressed that the Mailman REST API is an active project. and work is being planned for both the 2.2 and 3.0 versions as a high priority. He is very interested in pursuing this as a SOC project.<br />
<br />
== Objective ==<br />
<br />
* Develop a set of MailMan wrappers for the REST API's<br />
* Develop a MailMan plugin<br />
* Integrate the subscriber list admin features (add/remove) into the GL member profile<br />
* MailMan password can be sync'ed with GL password<br />
* List Admin Features to manage lists<br />
** Add/Delete List (support for multiple lists)<br />
** List Types: Public, private (GL Groups) and moderated<br />
** Add/Remove Subscribers<br />
** Import in subscribers<br />
** Subscribers can be GL members and non-site members<br />
** Moderate Lists<br />
** Use list to send out newsetters, notifications (mailings)<br />
** Support for HTML and text mailings<br />
<br />
<br />
== Options ==<br />
<br />
# Add support for as much control as possible over the pages the user would go to in order to subscribe and un-subscribe. It would be nice to always have site control over the look and feel for all the pages the user would be directed to.<br />
# Support for both automatic registration/un-registration based on email address and authenticated mode that requires an email confirmation.<br />
<br />
<br />
[[Category:Summer of Code]] [[Category:Development]]</div>Blainehttp://wiki.geeklog.net/index.php?title=SoC_mailman&diff=4445SoC mailman2008-02-24T16:15:14Z<p>Blaine: /* Incentive */</p>
<hr />
<div><center>(Return to the main idea page for the [[Google Summer of Code]])</center><br />
<br />
== Incentive ==<br />
<br />
The [http://www.list.org/ Mailman] program is one of the most commonly used programs for adminstrating mailing lists and is usually the only installed solution on a hosted service.<br />
<br />
Mailman is used to maintain list subscriptions where users can self register and un-register. The lists are then used for email either as a normal or moderated email list for automatic distribution. You can also have a closed use list that can only be used by moderators.<br />
<br />
Mailman is written in Python while Geeklog is written in PHP but there is presently a Mailman project to develope a set of [http://wiki.list.org/display/DEV/REST+Interface REST API's]<br />
<br />
In an email discussion with Bruce Warsaw of the Mailman project, he expressed that the Mailman REST API is an active project and work is being planned for both the 2.2 and 3.0 versions as a high priority. He is very interested in pursuing this as a SOC project.<br />
<br />
== Objective ==<br />
<br />
* Develop a set of MailMan wrappers for the REST API's<br />
* Develop a MailMan plugin<br />
* Integrate the subscriber list admin features (add/remove) into the GL member profile<br />
* MailMan password can be sync'ed with GL password<br />
* List Admin Features to manage lists<br />
** Add/Delete List (support for multiple lists)<br />
** List Types: Public, private (GL Groups) and moderated<br />
** Add/Remove Subscribers<br />
** Import in subscribers<br />
** Subscribers can be GL members and non-site members<br />
** Moderate Lists<br />
** Use list to send out newsetters, notifications (mailings)<br />
** Support for HTML and text mailings<br />
<br />
<br />
== Options ==<br />
<br />
# Add support for as much control as possible over the pages the user would go to in order to subscribe and un-subscribe. It would be nice to always have site control over the look and feel for all the pages the user would be directed to.<br />
# Support for both automatic registration/un-registration based on email address and authenticated mode that requires an email confirmation.<br />
<br />
<br />
[[Category:Summer of Code]] [[Category:Development]]</div>Blainehttp://wiki.geeklog.net/index.php?title=SoC_mailman&diff=4444SoC mailman2008-02-24T16:14:55Z<p>Blaine: /* Incentive */</p>
<hr />
<div><center>(Return to the main idea page for the [[Google Summer of Code]])</center><br />
<br />
== Incentive ==<br />
<br />
The [http://www.list.org/ Mailman] program is one of the most commonly used programs for adminstrating mailing lists and is usually the only installed solution on a hosted service.<br />
<br />
Mailman is used to maintain list subscriptions where users can self register and un-register. The lists are then used for email either as a normal or moderated email list for automatic distribution. You can also have a closed use list that can only be used by moderators.<br />
<br />
Mailman is written in Python while Geeklog is written in PHP but there is presently a Mailman project to develope a set of [http://wiki.list.org/display/DEV/REST+Interface REST API's]<br />
<br />
In an email discussion with Bruce Warsaw of the Mailman project, he's expressed that the Mailman REST API is an active project and work is being planned for both the 2.2 and 3.0 versions as a high priority. He is very interested in pursuing this as a SOC project.<br />
<br />
== Objective ==<br />
<br />
* Develop a set of MailMan wrappers for the REST API's<br />
* Develop a MailMan plugin<br />
* Integrate the subscriber list admin features (add/remove) into the GL member profile<br />
* MailMan password can be sync'ed with GL password<br />
* List Admin Features to manage lists<br />
** Add/Delete List (support for multiple lists)<br />
** List Types: Public, private (GL Groups) and moderated<br />
** Add/Remove Subscribers<br />
** Import in subscribers<br />
** Subscribers can be GL members and non-site members<br />
** Moderate Lists<br />
** Use list to send out newsetters, notifications (mailings)<br />
** Support for HTML and text mailings<br />
<br />
<br />
== Options ==<br />
<br />
# Add support for as much control as possible over the pages the user would go to in order to subscribe and un-subscribe. It would be nice to always have site control over the look and feel for all the pages the user would be directed to.<br />
# Support for both automatic registration/un-registration based on email address and authenticated mode that requires an email confirmation.<br />
<br />
<br />
[[Category:Summer of Code]] [[Category:Development]]</div>Blainehttp://wiki.geeklog.net/index.php?title=SoC_mailman&diff=4443SoC mailman2008-02-24T16:12:26Z<p>Blaine: /* Incentive */</p>
<hr />
<div><center>(Return to the main idea page for the [[Google Summer of Code]])</center><br />
<br />
== Incentive ==<br />
<br />
The [http://www.list.org/ Mailman] program is one of the most commonly used programs for adminstrating mailing lists and is usually the only installed solution on a hosted service.<br />
<br />
Mailman is used to maintain list subscriptions where users can self register and un-register. The lists are then used for email either as a normal or moderated email list for automatic distribution. You can also have a closed use list that can only be used by moderators.<br />
<br />
Mailman is written in Python while Geeklog is written in PHP but there is presently a MailMan project to develope a set of [http://wiki.list.org/display/DEV/REST+Interface REST API's]<br />
<br />
Need to further investigate where the Mailman project is on this initiative and if they would like to do a joint SoC project.<br />
<br />
== Objective ==<br />
<br />
* Develop a set of MailMan wrappers for the REST API's<br />
* Develop a MailMan plugin<br />
* Integrate the subscriber list admin features (add/remove) into the GL member profile<br />
* MailMan password can be sync'ed with GL password<br />
* List Admin Features to manage lists<br />
** Add/Delete List (support for multiple lists)<br />
** List Types: Public, private (GL Groups) and moderated<br />
** Add/Remove Subscribers<br />
** Import in subscribers<br />
** Subscribers can be GL members and non-site members<br />
** Moderate Lists<br />
** Use list to send out newsetters, notifications (mailings)<br />
** Support for HTML and text mailings<br />
<br />
<br />
== Options ==<br />
<br />
# Add support for as much control as possible over the pages the user would go to in order to subscribe and un-subscribe. It would be nice to always have site control over the look and feel for all the pages the user would be directed to.<br />
# Support for both automatic registration/un-registration based on email address and authenticated mode that requires an email confirmation.<br />
<br />
<br />
[[Category:Summer of Code]] [[Category:Development]]</div>Blainehttp://wiki.geeklog.net/index.php?title=SoC_core_notification_support&diff=4439SoC core notification support2008-02-23T21:29:04Z<p>Blaine: /* Objective */</p>
<hr />
<div><center>(Return to the main idea page for the [[Google Summer of Code]])</center><br />
<br />
==== Overview ====<br />
<br />
There are a number of core GL features and plugins that send out email notifications and each plugin or module has to develop their own code. There is no central area for the site admin or members to moderate what they can receive notifications for or how they want them handled.<br />
<br />
There is also the need to add new levels of alerting or allow alerting of additional site events.<br />
<br />
Many plugins would require a more basic level of notification services and others like the forum allow a user to subscribe to a topic or complete forum. If they have subscribed to a complete forum, they can selectively un-subscribe to some topics. The same level of control may be needed for stories, where a user can subscribe to a complete site but then un-subscribe to certain topics or stories by a certain user.<br />
<br />
====Objective====<br />
* Develop a set of CORE GL API's to support the registration of new notification services and user notification subscriptions.<br />
* Extend the plugin API's to use the new services<br />
* Extend the core GL modules to use the new services<br />
* Develope the notification admin - site admin screen<br />
* Develop the UI and program for the users to manage their notification subscription rules.<br />
<br />
Support for:<br />
* Alert Classification (admin, general, moderation, error ...)<br />
* Alert Type (core, plugin ...)<br />
* Alert Subtype (module specific)<br />
<br />
Only Root or plugin Admin's have access to the admin and error type notifications but this should be a configurable mapping option and controllable via the online notification service admin.<br />
<br />
Users should be able to determine how they want to receive their notifications.<br />
* Admin wants to be emailed on all admin and error notifications<br />
* Admin wants to receive daily digest of all other notifications<br />
* User wants daily digest of all notifications<br />
* Support for RSS Feed per user - using a random hash like URL<br />
* Daily digest format needs to use a template so the site admin can modify it<br />
<br />
====Use Cases====<br />
* Site Admin wants to be notified of all new forum topics and MG albums created but not new replies and images uploaded<br />
* User wants daily digest of all MG updates for albums they have access to<br />
* User wants daily digest of all comments to content they have created or have replied to.<br />
* Admin wants daily digest of all items awaiting moderation<br />
* Admin wants to be notified via email of all site logins<br />
* Admin wants to be notified via email of all bad login attempts so they know if a user is now locked out<br />
* Admin wants to be notified of new user signups.<br />
<br />
The site Admin and user can have multiple notifiction rules setup and setup the email subject, email address so they can filter or redirect notifications<br />
<br />
[[Category:Summer of Code]] [[Category:Development]]</div>Blainehttp://wiki.geeklog.net/index.php?title=SoC_core_notification_support&diff=4438SoC core notification support2008-02-23T21:25:36Z<p>Blaine: /* Overview */</p>
<hr />
<div><center>(Return to the main idea page for the [[Google Summer of Code]])</center><br />
<br />
==== Overview ====<br />
<br />
There are a number of core GL features and plugins that send out email notifications and each plugin or module has to develop their own code. There is no central area for the site admin or members to moderate what they can receive notifications for or how they want them handled.<br />
<br />
There is also the need to add new levels of alerting or allow alerting of additional site events.<br />
<br />
Many plugins would require a more basic level of notification services and others like the forum allow a user to subscribe to a topic or complete forum. If they have subscribed to a complete forum, they can selectively un-subscribe to some topics. The same level of control may be needed for stories, where a user can subscribe to a complete site but then un-subscribe to certain topics or stories by a certain user.<br />
<br />
====Objective====<br />
<br />
Support for:<br />
* Alert Classification (admin, general, moderation, error ...)<br />
* Alert Type (core, plugin ...)<br />
* Alert Subtype (module specific)<br />
<br />
Only Root or plugin Admin's have access to the admin and error type notifications but this should be a configurable mapping option and controllable via the online notification service admin.<br />
<br />
Users should be able to determine how they want to receive their notifications.<br />
* Admin wants to be emailed on all admin and error notifications<br />
* Admin wants to receive daily digest of all other notifications<br />
* User wants daily digest of all notifications<br />
* Support for RSS Feed per user - using a random hash like URL<br />
* Daily digest format needs to use a template so the site admin can modify it<br />
<br />
====Use Cases====<br />
* Site Admin wants to be notified of all new forum topics and MG albums created but not new replies and images uploaded<br />
* User wants daily digest of all MG updates for albums they have access to<br />
* User wants daily digest of all comments to content they have created or have replied to.<br />
* Admin wants daily digest of all items awaiting moderation<br />
* Admin wants to be notified via email of all site logins<br />
* Admin wants to be notified via email of all bad login attempts so they know if a user is now locked out<br />
* Admin wants to be notified of new user signups.<br />
<br />
The site Admin and user can have multiple notifiction rules setup and setup the email subject, email address so they can filter or redirect notifications<br />
<br />
[[Category:Summer of Code]] [[Category:Development]]</div>Blainehttp://wiki.geeklog.net/index.php?title=SoC_core_notification_support&diff=4437SoC core notification support2008-02-23T21:23:17Z<p>Blaine: /* Use Cases */</p>
<hr />
<div><center>(Return to the main idea page for the [[Google Summer of Code]])</center><br />
<br />
== Overview ==<br />
<br />
There are a number of core GL features and plugins that send out email notifications and each plugin or module has to develop their own code. There is no central area for the site admin or members to moderate what they can receive notifications for or how they want them handled.<br />
<br />
There is also the need to add new levels of alerting or allow alerting of additional site events.<br />
<br />
Many plugins would require a more basic level of notification services and others like the forum allow a user to subscribe to a topic or complete forum. If they have subscribed to a complete forum, they can selectively un-subscribe to some topics. The same level of control may be needed for stories, where a user can subscribe to a complete site but then un-subscribe to certain topics or stories by a certain user.<br />
<br />
Support for:<br />
* Alert Classification (admin, general, moderation, error ...)<br />
* Alert Type (core, plugin ...)<br />
* Alert Subtype (module specific)<br />
<br />
Only Root or plugin Admin's have access to the admin and error type notifications but this should be a configurable mapping option and controllable via the online notification service admin.<br />
<br />
Users should be able to determine how they want to receive their notifications.<br />
* Admin wants to be emailed on all admin and error notifications<br />
* Admin wants to receive daily digest of all other notifications<br />
* User wants daily digest of all notifications<br />
* Support for RSS Feed per user - using a random hash like URL<br />
* Daily digest format needs to use a template so the site admin can modify it<br />
<br />
====Use Cases====<br />
* Site Admin wants to be notified of all new forum topics and MG albums created but not new replies and images uploaded<br />
* User wants daily digest of all MG updates for albums they have access to<br />
* User wants daily digest of all comments to content they have created or have replied to.<br />
* Admin wants daily digest of all items awaiting moderation<br />
* Admin wants to be notified via email of all site logins<br />
* Admin wants to be notified via email of all bad login attempts so they know if a user is now locked out<br />
* Admin wants to be notified of new user signups.<br />
<br />
The site Admin and user can have multiple notifiction rules setup and setup the email subject, email address so they can filter or redirect notifications<br />
<br />
[[Category:Summer of Code]] [[Category:Development]]</div>Blainehttp://wiki.geeklog.net/index.php?title=SoC_core_notification_support&diff=4436SoC core notification support2008-02-23T21:19:40Z<p>Blaine: /* Overview */</p>
<hr />
<div><center>(Return to the main idea page for the [[Google Summer of Code]])</center><br />
<br />
== Overview ==<br />
<br />
There are a number of core GL features and plugins that send out email notifications and each plugin or module has to develop their own code. There is no central area for the site admin or members to moderate what they can receive notifications for or how they want them handled.<br />
<br />
There is also the need to add new levels of alerting or allow alerting of additional site events.<br />
<br />
Many plugins would require a more basic level of notification services and others like the forum allow a user to subscribe to a topic or complete forum. If they have subscribed to a complete forum, they can selectively un-subscribe to some topics. The same level of control may be needed for stories, where a user can subscribe to a complete site but then un-subscribe to certain topics or stories by a certain user.<br />
<br />
Support for:<br />
* Alert Classification (admin, general, moderation, error ...)<br />
* Alert Type (core, plugin ...)<br />
* Alert Subtype (module specific)<br />
<br />
Only Root or plugin Admin's have access to the admin and error type notifications but this should be a configurable mapping option and controllable via the online notification service admin.<br />
<br />
Users should be able to determine how they want to receive their notifications.<br />
* Admin wants to be emailed on all admin and error notifications<br />
* Admin wants to receive daily digest of all other notifications<br />
* User wants daily digest of all notifications<br />
* Support for RSS Feed per user - using a random hash like URL<br />
* Daily digest format needs to use a template so the site admin can modify it<br />
<br />
====Use Cases====<br />
* Site Admin wants to be notified of all new forum topics and MG albums created but not new replies and images uploaded<br />
* User wants daily digest of all MG updates for albums they have access to<br />
* Admin wants daily digest of all items awaiting moderation<br />
<br />
[[Category:Summer of Code]] [[Category:Development]]</div>Blainehttp://wiki.geeklog.net/index.php?title=SoC_core_notification_support&diff=4435SoC core notification support2008-02-23T21:18:58Z<p>Blaine: /* Use Cases */</p>
<hr />
<div><center>(Return to the main idea page for the [[Google Summer of Code]])</center><br />
<br />
== Overview ==<br />
<br />
There are a number of core GL features and plugins that send out email notifications and each plugin or module has to develop their own code. There is no central area for the site admin or members to moderate what they can receive notifications for or how they want them handled.<br />
<br />
There is also the need to add new levels of alerting or allow alerting of additional site events.<br />
<br />
Many plugins would require a more basic level of notification services and others like the forum allow a user to subscribe to a topic or complete forum. If they have subscribed to a complete forum, they can selectively un-subscribe to some topics. The same level of control may be needed for stories, where a user can subscribe to a complete site but then un-subscribe to certain topics or stories by a certain user.<br />
<br />
Support for:<br />
* Alert Classification (admin, general, error ...)<br />
* Alert Type (core, plugin ...)<br />
* Alert Subtype (module specific)<br />
<br />
Only Root or plugin Admin's have access to the admin and error type notifications but this should be a configurable mapping option and controllable via the online notification service admin.<br />
<br />
Users should be able to determine how they want to receive their notifications.<br />
* Admin wants to be emailed on all admin and error notifications<br />
* Admin wants to receive daily digest of all other notifications<br />
* User wants daily digest of all notifications<br />
* Support for RSS Feed per user - using a random hash like URL<br />
<br />
====Use Cases====<br />
* Site Admin wants to be notified of all new forum topics and MG albums created but not new replies and images uploaded<br />
* User wants daily digest of all MG updates for albums they have access to<br />
* Admin wants daily digest of all items awaiting moderation<br />
<br />
[[Category:Summer of Code]] [[Category:Development]]</div>Blainehttp://wiki.geeklog.net/index.php?title=SoC_core_notification_support&diff=4434SoC core notification support2008-02-23T21:17:40Z<p>Blaine: </p>
<hr />
<div><center>(Return to the main idea page for the [[Google Summer of Code]])</center><br />
<br />
== Overview ==<br />
<br />
There are a number of core GL features and plugins that send out email notifications and each plugin or module has to develop their own code. There is no central area for the site admin or members to moderate what they can receive notifications for or how they want them handled.<br />
<br />
There is also the need to add new levels of alerting or allow alerting of additional site events.<br />
<br />
Many plugins would require a more basic level of notification services and others like the forum allow a user to subscribe to a topic or complete forum. If they have subscribed to a complete forum, they can selectively un-subscribe to some topics. The same level of control may be needed for stories, where a user can subscribe to a complete site but then un-subscribe to certain topics or stories by a certain user.<br />
<br />
Support for:<br />
* Alert Classification (admin, general, error ...)<br />
* Alert Type (core, plugin ...)<br />
* Alert Subtype (module specific)<br />
<br />
Only Root or plugin Admin's have access to the admin and error type notifications but this should be a configurable mapping option and controllable via the online notification service admin.<br />
<br />
Users should be able to determine how they want to receive their notifications.<br />
* Admin wants to be emailed on all admin and error notifications<br />
* Admin wants to receive daily digest of all other notifications<br />
* User wants daily digest of all notifications<br />
* Support for RSS Feed per user - using a random hash like URL<br />
<br />
====Use Cases====<br />
* Site Admin wants to be notified of all new forum topics and MG albums created but not new replies and images uploaded<br />
* User wants daily digest of all MG updates for albums they have access to<br />
<br />
[[Category:Summer of Code]] [[Category:Development]]</div>Blainehttp://wiki.geeklog.net/index.php?title=SoC_core_notification_support&diff=4428SoC core notification support2008-02-23T20:59:48Z<p>Blaine: </p>
<hr />
<div><center>(Return to the main idea page for the [[Google Summer of Code]])</center><br />
====Overview====<br />
There are a number of core GL features and plugins that send out email notifications and each plugin or module has to develop their own code. There is no central area for the site admin or members to moderate what they can receive notifications for our how they want them handled.<br />
<br />
There is also the need to add new levels of alerting or allow alerting of additional site events.<br />
<br />
Many plugins would require a more basic level of notification services and others like the forum allow a user to subscribe to a topic or complete forum. If they have subscribed to a complete forum, they can selectively un-subscribe to some topics. The same level of control may be needed for stories, where a user can subscribe to a complete site but then un-subscribe to certain topics or stories by a certain user.<br />
<br />
Support for:<br />
* Alert Classification (admin,general,error ...)<br />
* Alert Type (core, plugin ...)<br />
* Alert Subtype (module specific)<br />
<br />
Only Root or plugin Admin's have access to the admin and error type notifications but this should be a configurable mapping option and controllable via the online notification service admin.<br />
<br />
Users should be able to determine how they want to receive their notifications.<br />
* Admin wants to be emailed on all admin and error notifications<br />
* Admin wants to recieve daily digest of all other notifications<br />
* User wants daily digest of all notifications</div>Blainehttp://wiki.geeklog.net/index.php?title=SoC_core_notification_support&diff=4427SoC core notification support2008-02-23T20:59:40Z<p>Blaine: </p>
<hr />
<div><center>(Return to the main idea page for the [[Google Summer of Code]])</center><br />
====Overview====<br />
There are a number of core GL features and plugins that send out email notifications and each plugin or module has to develop their own code. There is no central area for the site admin or members to moderate what they can receive notifications for our how they want them handled.<br />
<br />
There is also the need to add new levels of alerting or allow alerting of additional site events.<br />
<br />
Many plugins would require a more basic level of notification services and others like the forum allow a user to subscribe to a topic or complete forum. If they have subscribed to a complete forum, they can selectively un-subscribe to some topics. The same level of control may be needed for stories, where a user can subscribe to a complete site but then un-subscribe to certain topics or stories by a certain user.<br />
<br />
Support for:* Alert Classification (admin,general,error ...)<br />
* Alert Type (core, plugin ...)<br />
* Alert Subtype (module specific)<br />
<br />
Only Root or plugin Admin's have access to the admin and error type notifications but this should be a configurable mapping option and controllable via the online notification service admin.<br />
<br />
Users should be able to determine how they want to receive their notifications.<br />
* Admin wants to be emailed on all admin and error notifications<br />
* Admin wants to recieve daily digest of all other notifications<br />
* User wants daily digest of all notifications</div>Blainehttp://wiki.geeklog.net/index.php?title=SoC_core_notification_support&diff=4426SoC core notification support2008-02-23T20:59:01Z<p>Blaine: </p>
<hr />
<div><center>(Return to the main idea page for the [[Google Summer of Code]])</center><br />
====Overview====<br />
There are a number of core GL features and plugins that send out email notifications and each plugin or module has to develop their own code. There is no central area for the site admin or members to moderate what they can receive notifications for our how they want them handled.<br />
<br />
There is also the need to add new levels of alerting or allow alerting of additional site events.<br />
<br />
Many plugins would require a more basic level of notification services and others like the forum allow a user to subscribe to a topic or complete forum. If they have subscribed to a complete forum, they can selectively un-subscribe to some topics. The same level of control may be needed for stories, where a user can subscribe to a complete site but then un-subscribe to certain topics or stories by a certain user.<br />
<br />
Support for:<br />
* Alert Classification (admin,general,error ...)<br />
* Alert Type (core, plugin ...)<br />
* Alert Subtype (module specific)<br />
<br />
Only Root or plugin Admin's have access to the admin and error type notifications but this should be a configurable mapping option and controllable via the online notification service admin.<br />
<br />
Users should be able to determine how they want to receive their notifications.<br />
* Admin wants to be emailed on all admin and error notifications<br />
* Admin wants to recieve daily digest of all other notifications<br />
* User wants daily digest of all notifications</div>Blainehttp://wiki.geeklog.net/index.php?title=SoC_web_analytics_api&diff=4418SoC web analytics api2008-02-23T20:33:35Z<p>Blaine: /* Overview */</p>
<hr />
<div><center>(Return to the main idea page for the [[Google Summer of Code]])</center><br />
====Overview====<br />
Implement the website analytics API from http://www.openwebanalytics.com and develope a set of core API's so that both the CORE GL modules and plugins can generate metrcs for usage and performance related stats.<br />
<br />
====Objective====<br />
* Develop a set of core API services<br />
* Add support for plugins<br />
* Add calls so all core GL modules are instrumented<br />
* Develop the admin interface to control what level of detail and modules will have data collected.<br />
* Develop the reports that are needed. Need tabular and some graphical reporting with export to Excel. Investigate how other projects have implemented the same API and also explore the Google Analytics application for inspiration.</div>Blainehttp://wiki.geeklog.net/index.php?title=SoC_web_analytics_api&diff=4417SoC web analytics api2008-02-23T20:32:23Z<p>Blaine: /* Overview */</p>
<hr />
<div><center>(Return to the main idea page for the [[Google Summer of Code]])</center><br />
====Overview====<br />
Implement the website analytics API from http://www.openwebanalytics.com and provide core plugin API calls so that plugins can also add metric related stats.<br />
<br />
====Objective====<br />
* Develop a set of core API services<br />
* Add support for plugins<br />
* Add calls so all core GL modules are instrumented<br />
* Develop the admin interface to control what level of detail and modules will have data collected.<br />
* Develop the reports that are needed. Need tabular and some graphical reporting with export to Excel. Investigate how other projects have implemented the same API and also explore the Google Analytics application for inspiration.</div>Blainehttp://wiki.geeklog.net/index.php?title=SoC_web_analytics_api&diff=4416SoC web analytics api2008-02-23T20:32:11Z<p>Blaine: </p>
<hr />
<div><center>(Return to the main idea page for the [[Google Summer of Code]])</center><br />
====Overview====<br />
Implement the website analytics API from http://www.openwebanalytics.com/ and provide core plugin API calls so that plugins can also add metric related stats.<br />
<br />
<br />
====Objective====<br />
* Develop a set of core API services<br />
* Add support for plugins<br />
* Add calls so all core GL modules are instrumented<br />
* Develop the admin interface to control what level of detail and modules will have data collected.<br />
* Develop the reports that are needed. Need tabular and some graphical reporting with export to Excel. Investigate how other projects have implemented the same API and also explore the Google Analytics application for inspiration.</div>Blainehttp://wiki.geeklog.net/index.php?title=SoC_web_analytics_api&diff=4415SoC web analytics api2008-02-23T20:29:40Z<p>Blaine: </p>
<hr />
<div><center>(Return to the main idea page for the [[Google Summer of Code]])</center><br />
====Overview====<br />
Implement the website analytics API from http://www.openwebanalytics.com/ and provide core plugin API calls so that plugins can also add metric related stats.<br />
<br />
<br />
====Objective====<br />
Develop a set of core API services<br />
Add calls so all core GL modules are instrumented<br />
<br />
Develop the admin interface to control what level of detail and modules will have data collected.<br />
<br />
Develop the reports that are needed. Need tabular and some graphical reporting with export to Excel. Investigate how other projects have implemented the same API and also explore the Google Analytics application for inspiration.</div>Blainehttp://wiki.geeklog.net/index.php?title=SoC_web_analytics_api&diff=4414SoC web analytics api2008-02-23T20:28:40Z<p>Blaine: </p>
<hr />
<div><center>(Return to the main idea page for the [[Google Summer of Code]])</center><br />
====Overview====<br />
Implement the website analytics API from http://www.openwebanalytics.com/ and provide core plugin API calls so that plugins can also add metric related stats.<br />
<br />
We can then instrument the core GL modules.<br />
<br />
Develop the admin interface to control what level of detail and modules will have data collected.<br />
<br />
Develop the reports that are needed. Need tabular and some graphical reporting with export to Excel. Investigate how other projects have implemented the same API and also explore the Google Analytics application for inspiration.</div>Blainehttp://wiki.geeklog.net/index.php?title=SoC_web_analytics_api&diff=4413SoC web analytics api2008-02-23T20:28:24Z<p>Blaine: </p>
<hr />
<div><center>(Return to the main idea page for the [[Google Summer of Code]])</center><br />
====Overview====<br />
Implement the website analytics API from http://www.openwebanalytics.com/ and provide core plugin API calls so that plugins can also add metric related stats.<br />
<br />
We can then instrument the core GL modules.<br />
<br />
Develop the admin interface to control what level of detail and modules will have data collected.<br />
<br />
Develop the reports that are needed. Need tabular and some graphical reporting with export to Excel. Investigate how other projects have implemented the same API also explore the Google Analytics application for inspiration.</div>Blainehttp://wiki.geeklog.net/index.php?title=SoC_cross_site_publication&diff=4412SoC cross site publication2008-02-23T20:18:42Z<p>Blaine: /* More details or ideas */</p>
<hr />
<div><center>(Return to the main idea page for the [[Google Summer of Code]])</center><br />
====Overview====<br />
Develop an Alerting and Cross Site Publication API that can be used among trusted sites. There would be two modes which can both be enabled or not (i: Peer to Peer, ii: Hub based distribution)<br />
<br />
Sites would need to subscribe to remote sites (Peers) and be approved. They would have the ability to query the remote sites for the types of alerts or publishing services available. Source site would need to approve all requests unless alert service was setup as public.<br />
<br />
Each alert or publish event would have a number of rules once an update is available. The Rules need to be flexible or extendable but initially for alerts, it may be to publish the alert on the site in an alert area, or send an email to the site admin. Option to be published automatic or moderated per source. So I may want to publish alerts from Geeklog.net automatically but moderate them from other sites I have setup.<br />
<br />
====Use Cases====<br />
- Geeklog.net setup as hub where security updates can be broadcasted to all subscribing sites.<br />
- Plugin Developers can use the service to send out update notices. The plugin Editor could pull developer sites and request the latest version<br />
- A ring of community sites may want to send out lost-pet alerts or crime alerts.<br />
- Service could be used to push spam site updates to a hub and then subscribers get updates automatically<br />
<br />
Flexible rules or options will make this a more valuable service. <br />
- Announcements on siteA are picked up by SiteB and published to Topic ABC.<br />
The SiteB's story indicates that it was originally published on SiteA by John Hanover.<br />
- Announcements on SiteA are picked up by SiteC.<br />
An email alert is sent to site Admin to approve before publishing.<br />
<br />
====More details or ideas====<br />
Content could be pulled from remote site but cached with a configurable expiry age. Source site can at any time send out an update event which clears the cache.<br />
<br />
Content can also be setup to be published and saved locally on the remote site. The source site can still send out an update event but admin would need to approve update. This may be usefull for GL community sites to share announcements and have then published automatically on their local sites.</div>Blaine