[Citadel Development] Re: New Developer Questions
Oh! Ok, that's why I didn't see a merge request. Cool, that's exactly how it should be. :) In other news, I finally figured out why the server kept crashing (on this site). Someone put a match string in their inbox rules that doesn't compile to a regular expression. regcomp() fails, and then when we do the match, the library throws a segfault. I modified the code to only do a match if the regex compiles successfully, and we've been running clean ever since. Unfortunately the server crashed in such a way that my user record got corrupted! That's why that "undocumented recovery mode" got added to the tree. :)
[Citadel Development] Re: New Developer Questions
That is not the branch that was merged. It is the new one to actually add support for all the flags. I ran into some issues testing so I am working on it locally. Should be updating the branch and submitting soon. Adding the flags is a big change (hopefully for the better), but touches a lot of files.
[Citadel Development] Re: New Developer Questions
I also see that the `Support_IMAP_Flagged_Deleted_Draft_Recent_flags` branch is still there. I thought it was going to get deleted in the merge. Mind if I delete it? I also have to make sure I'm not "squashing" multiple commits so they all get their own commit log messages. Thanks for bearing with me on this. The code is what's important, but if we make it easier to work on it, more people will want to.
[Citadel Development] Re: New Developer Questions
I am completely new to Git and commits, so I did not realize there was a standard :-P Thanks for the feedback and access. I'll now shut up and code :-)
[Citadel Development] Re: New Developer Questions
I'm assuming you're familiar with the industry-wide standard for how to write a commit message (summary line of 50 characters or less, then if you need to type more, skip a line and then make the longer description lines of 72 characters or less). If you're doing that in the commit message, then when you create a merge request you can just copy the same data over (or it might actually do that automatically, I don't remember). That way you won't have to needlessly duplicate work. The whole GitLab thing is new for us, so as we get comfortable in it I'll probably have certain information get posted to this room automatically. I saw your last merge request because you told it to specifically go to me, but maybe we can have all such things get posted here automatically. Like I said, we'll figure out what's comfortable. As for issues and enhancements, we have a "Citadel Issue Tracker" wiki room that I totally forgot to add you to until now. From a quick scan of it, I think some of the open issues have been fixed and I need to close them. I'm not sure whether using the GitLab issue tracker would be better or not. In the distant past we had a Bugzilla and it got to be a huge mess with people logging poorly researched bugs and feature enhancements. Now shut up and code ;)
[Citadel Development] Re: New Developer Questions
Ok. I have gotten my feet wet, so now I have a couple more questions. I am trying not to be annoying, but I seem to be running into things that I am not sure how to handle. Just let me know if I should shut up and code :-) As you have seen, I have been creating rather long, detailed commit information. Do you want this type of detail in the commit or do you just want a smaller summary? I am writing like I am providing details for a code reviewer. If you don't want all the detail in the commit, I could add a message here with the details when I submit the merge request, or maybe there is something in GitLab we can use? Is there a list of issues or enhancements that we can review and maybe work on? I am willing to put in some effort to help with it. This might be something that we could use the Issues in GitLab for.
[Citadel Development] Re: New Developer Questions
libcitadel and webcit use the GNU Automake build system. That's why there's a bootstrap program; it sets up the build environment on your build machine so you can continue. citadel (server), textclient, and webcit-ng use a much simpler build system, one that doesn't rely on the GNU Autotools and therefore carries much less baggage. The idea is that everyone now has a modern build system and is running on either Linux or BSD, and we don't have to support 20 year old HP/UX or whatever. The length of the email addresses field in user records was set at 256 simply to save space.
[Citadel Development] Re: New Developer Questions
The bootstrap was the part I was missing. Thanks. For webcit, I am glad to hear that it is getting rewritten. At one point, I tried to fix the calendar so it would work as an internet calendar in Outlook, but after a bunch of work, it was not worth it. Got it talking to Outlook, but then I found there were bugs in the iCal library and just decided it was not worth spending any more time on it. I ended up using iCloud to share calendars. One thing I will submit a patch for is the recipient handling. Some of my users caused core dumps because of long addresses. It looks like the address length is limited to 256 and the total recipient line is limited to 900 characters. I think these were probably from the standard, but I have found that many mail servers violate the standard. Is there any reason to limit these in the server? For my implementation, I just bumped up both to handle SIZ (4096) throughout the code and have not seen any issues. Any reason I should not be allowing it? If there is, I can just add the code to avoid the core dump. Out of curiosity, why are the Makefiles built for libcitadel and webcit, but are checked in for citadel and textclient?
[Citadel Development] Re: New Developer Questions
The patch looks good, and I'll go ahead and see if it applies cleanly. The important thing is that it doesn't try to change too many things at the same time, and you've documented what it is intended to do. That's really really good. By the way -- in case you haven't figured it out yet, try not to change any of the because, as you've probably guessed, those get fed into a translator for international languages and if you change the string it throws away all of the translations. And you probably also noticed that WebCit is being completely rewritten, because it's based on 27 year old spaghetti code that's been so badly abused that it isn't worth trying to fix. The template engine in particular is super ugly -- it was meant to separate the code from the markup but it ended up being even harder to work with than it was before. When you get your development system up and running you'll be able to look at webcit-ng and see how it's coming together. As for how to build the development system -- you can take a look at the build script for either the Docker container or Easy Install to get an idea of how it comes together. [ https://easyinstall.citadel.org/install ] That's a good place to start. Ignore the bit about `ctdlvisor` since that's container specific. Basically, the order goes like this: 1. Install the development packages for all dependencies ... on a CentOS system that would be yum groupinstall "Development Tools" yum install \ zlib-devel \ openldap-devel \ openssl-devel \ libcurl-devel \ libical-devel \ expat-devel \ readline-devel 2. Install the Berkeley DB library -- download it from https://easyinstall.citadel.org/db-6.2.32.NC.tar.gz and unpack it, then cd db-6.2.32.NC/build_unix ../dist/configure --prefix=/usr/local --disable-static --disable-compat185 --disable-cxx --disable-debug --disable-dump185 --disable-java --disable-tcl --disable-test --without-rpm make make install 3. Clone the git repository git clone git://git.citadel.org/citadel 4. Build and install libcitadel cd citadel/libcitadel ./bootstrap ./configure make make install 5. Build the Citadel Server. I usually run it from the build directory, in the foreground, when I'm using it. cd citadel/citadel ./bootstrap ./configure make and then run it with: ./citserver -x9 -h`pwd` 6. In another window, build WebCit. I usually run this from its build directory as well. cd citadel/webcit ./bootstrap ./configure make and then run it with: ./webcit -p80 uds ~/citadel/citadel 7. If you want the text mode client, it's the same routine again, but in citadel/textclient That ought to be enough to get you started. Thanks for your interest in helping out with development!
[Citadel Development] Re: New Developer Questions
Submitting Code: What you said makes very good sense. To try out submitting code, I cloned down the citadel release, created a branch and made some updates to fix some WebCit page issues and cleaned up a little formatting. Seemed like a simple change to submit with low impact for a first try. I created a patch from the branch (attached). Is this what you were expecting for submitting changes? New Features: The Flagging and Aliasing were just examples. The Aliasing is a big help to my server, but I figured may not be considered a useful feature to others. It is a bit tricky to implement and as you noted, you have to be careful about user names. It is fun when you get to tell a company like Fidelity Investments that their email list has been stolen and you have the proof :-) The flagging is most likely useful. I added support for Draft, Flagged, Deleted and Recent. After reviewing the standards I noticed that Seen was not quite implemented properly so I fixed that while implementing the others. I’ll write up details on it and send it to you. Building Code: The main issue I ran into was trying to build the server from the citadel repository. I normally have just copied the build after an easy install and then made my changes on top of it so all I had to do is run Make. With the citadel repository, I tried to create the configure scripts and then run them to create the make files, but ran into some missing files and script errors. I am compiling on Rocky Linux. I assume that developers are not running autoconf, etc. from just a citadel repository clone or to build easy install. What is the proper process for building from the repository? 0001-WebCit-Fix-HTML-errors-and-clean-up-page-output.patch Description: Binary data
[Citadel Development] Re: New Developer Questions
Ok, let me see if I can answer these questions one at a time. git: at any given time, you'll want to be keeping up with the code in the git repo. If you are developing against a released version of the code you might have trouble integrating your changes. That having been said, no open source projects are going to give commit access to new developers right away. Initially you submit patches against the current tree, and the maintainer (in this case, me) will evaluate each patch, and if it is acceptable, apply those patches to integrate the new code. After a while, you would get commit access to the tree, and even then, you might maintain a separate branch and then make "pull requests" asking for changes in that branch to be pulled into the master branch. But let's not worry about that for now; just submit patch files. Test suite: unfortunately there is none. We hand-test everything. I suppose Uncensored could be considered the test site :) New features: if you have an idea, propose it right here. We can discuss it and talk about whether a particular new feature makes sense for the system as a whole, and if implemented, what would need to be done. Good ideas are always welcome, especially if you're willing to write the code yourself. I would only shy away from ideas that would compromise the system's usability for other users. Let's look at your two examples: 1. Flagging in IMAP Sure, that's a great idea. So you added to `struct visit` to do that, which makes perfect sense. Here's where I get to ask: did you look in all places where `struct visit` is used, to see if any additional code is necessary? For example, `serv_migrate.c` will have to be patched to add the `flagged` element to exports and imports. `serv_expire.c` is probably ok as-is, but check. 2. Aliasing This is a good example of where it needs to be re-thought, in this case only a little. Let's say you have a user "alice" with appended suffixes like "alicebank" and "alicespam". So far so good ... but then another Alice joins the organization, let's say her name is "Alice Bob" and you make her email "ali...@example.com". Now you get mail for "aliceb...@example.com" -- is it for "al...@example.com" with suffix "bank" or "ali...@example.com" with suffix "ank"? I would suggest we use a separator character. I think the plus sign "+" is often used for this. If you were to submit a patch to do suffixes, let's make the rule that when it comes to finding the user associated with an email address, we throw away the "+" and anything after it. We also reject new usernames or email addresses containing a "+" in them. Is that enough to get you started?
[Citadel Development] Re: New Developer Questions
Thanks. Looking forward to it.
[Citadel Development] Re: New Developer Questions
Great! I just want to answer quick and let you know I'll read through this soon -- I'm super busy at work this week but I wanted to let you know these questions *will* be answered. Give me a bit and I'll go through it. Thanks for being interested in contributing!
