7 Want to know what the status of this package is? Read
8 /usr/share/doc/sourceforge/TODO.Debian or (even better)
9 <http://savannah.gnu.org/support/?group_id=259>. If you miss a
10 feature, or find a bug, or want to help, don't hesitate to contact me
11 (Roland Mas <lolando@debian.org>) . Plenty of features are missing,
12 I'm working on some, but if you don't tell me which ones you miss the
13 most I might process them in the wrong order for you.
15 Please read the bug reports on the Debian bug-tracking system (at
16 <URL:http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=sourceforge>)
17 before submitting new ones. Be warned that bug reports describing a
18 problem precisely and/or offering a solution will probably be
24 Sourceforge is a big piece of software. It's far-reaching. It
25 fiddles with many different parts of the system. As automated as I
26 have tried to make its installation, there are still things that need
27 to be done by hand, maybe even by a system administrator.
29 First, you'll need a hostname. Get the sourceforge.<your-domain>
30 DNS name to be created, pointing on the IP address of the host you're
31 installing Sourceforge on. The "sourceforge" part isn't required, you
32 can call it however you like. However, I'll assume you chose
33 "sourceforge" from now on; substitute as needed.
35 If you want to use the Apache virtual hosting service, you'll even
36 need a delegation of a subdomain. Get your system administrator to
37 delegate you the SOA for the sourceforge.<your-domain> subdomain.
38 This will allow Sourceforge to create new hostnames for projects when
39 needed (foo.sourceforge.<your-domain>, for instance), as well as some
40 hostnames needed by the system (for mailing-lists or CVS, for
41 instance). This is if you choose web_only to be false when
42 configuring Sourceforge.
44 The LDAP server is hosted on the same host and automatically
45 managed, therefore you should not have to worry too much about it.
46 You might be able to access it from another host, but I'm not sure
47 you'll be able to modify the entries in it. I would advise not to in
48 any case, since it would make the data contained in the LDAP directory
49 inconsistent with the real data stored in the PostgreSQL database.
51 You'll need a configured MTA for Sourceforge. Depending on whether
52 the Sourceforge users are local or remote, you might need to set up a
53 smarthost or something else. Sourceforge depends on a working mail
54 system, and you won't be able to create user accounts without it. I'm
55 not sure yet what advanced tricks need to be done with the MTA. There
56 might be some stuff to do with virtual domains for mailing-lists or
57 user email forwarding... I haven't fully investigated it yet. Your
58 contribution will be most welcome.
60 Depending on the targeted audience, you might want to get a real
61 SSL/TLS certificate from some certification authority, whether it be a
62 professional one or your personal one (or the one in your company).
63 Otherwise, just use mod-ssl-makecert as advised during the
64 configuration phase, and get your own custom certificate.
66 Do *not* delete the /etc/sourceforge/*.template files. They are
67 needed. Do not alter them either unless you *know* what you're doing.
72 This section sketches a roadmap of the steps that needed to be taken
73 before any official release of Sourceforge in Debian was possible.
75 It is completely outdated, and wrong. I once followed this roadmap,
76 but it turned out that some things came before others and some came
77 after, I switched to SF 2.5, that sort of stuff. The latest scheme
78 was 2.5-0+x (up to 2.5-0+15) before upload, 2.5-1 being the first
79 upload to Debian unstable. Current scheme is a classical "2.5-x" for
80 released packages (the ones I upload to Debian). Inter-release
81 versioning scheme, for the packages I use internally before uploading,
82 uses `+' (the current development package is 2.5-9+5).
84 I keep the original roadmap only for reference, and it might just
85 get deleted altogether in the near future. Here it comes:
88 | I'll use a pre-release numbering scheme similar to Branden Robinson's,
89 | except I'll use more phases.
91 | Phase 1 (package revisions 2.0-0phase1v1 to 2.0-0phase1v<$BIGNUM>)
92 | ------------------------------------------------------------------
93 | This phase will concentrate on the web services that only involve PHP
94 | and the database. This includes account and project creation and
95 | management, the bug-tracking system, the task manager, the forums, the
96 | support manager, the user's page and the software map. Probably also
97 | the patch manager and the news system, maybe the doc manager.
99 | These packages will probably break everything everytime you'll
100 | install them, so I won't even try to provide smooth upgrades. Yet
101 | I'll provide an apt-get'able directory for the brave.
103 | Phase 2 (2.0-0phase2v*)
104 | -----------------------
105 | This phase will get into the system a bit more and end by proposing
106 | features that require access to real files and services on the system:
107 | the end of phase2 will offer all the items marked "maybe" in phase1,
108 | plus the FTP and file releases services, as well as integration with
111 | At this stage I'll try and stabilize the package a bit, so that from
112 | phase3 Sourceforge can be cleanly upgraded with a reasonably low risk
115 | Phase 3 (2.0-0phase3*)
116 | ----------------------
117 | This phase will take care of the services that require modifications
118 | to existing software (in particular, CVS and CVS-Web will have to be
119 | patched) or deep meddling with the system (DNS and web virtual
120 | hosting, Unix account creation with libnss-probably-mysql). Mailing
121 | lists should be operational by the end of phase3 if not earlier.
123 | Phase 4 (2.0-0phase4*)
124 | ----------------------
125 | That one should wrap it up before the big show, completing all the
126 | tidbits that were previously overlooked: the software foundries, the
127 | search engine, and basically everything I can think of that I forgot
130 | Face it, I've got to get it out sometime
131 | ----------------------------------------
132 | By that time, I should (hopefully) be a full-fledged Debian
133 | developer and I'll upload to unstable. If I'm not yet, I'll call for
134 | some thick-skinned volunteer to sponsor me and upload it for me. That
135 | could be called -0phase5, but it'll be high time to call it
136 | sourceforge-2.0-1. And -2.0-2 and -2.0-3 and so on, 'cause I suspect
137 | there will be bugs.
139 | I'm not yet sure if the BTS can be used to track bugs on a package
140 | that's not in Debian yet, but if it can I will probably encourage its
141 | use even for very early packages, and take into consideration all the
142 | reports I find there. The only exception will be for bug-reports
143 | telling me that the upstream codebase I'm packaging is out-of-date,
144 | see next paragraph. These ones will get closed immediately (well, as
145 | soon as I see them anyway), with minimal comment, or merged with the
146 | first one that happened.
148 | I choose to package the Sourceforge released code (labeled 2.0 by
149 | the SF crew). I know that the development version has since the 2.0
150 | release been made accessible by anonymous CVS. I know that tremendous
151 | enhancements have been committed into this CVS, not the least of which
152 | are internationalisation and localisation. I know that bugs have been
153 | fixed. Yet I don't feel like packaging a big piece of intrusive
154 | software like Sourceforge while running after the backlog and tracking
155 | its evolution at the same time. Don't be alarmed, I will eventually
156 | follow the upstream evolution, but only after the sourceforge-2.0-*
157 | has stabilised a bit and the bugs in the BTS are only (or mostly) bugs
158 | that have already been fixed upstream instead of problems coming from
161 | Of course, I'll be interested in feedback from users. I just love
162 | receiving email... There are, however, some items of feedback I'd
163 | *NOT* be grateful for:
165 | - aesthetic comments: except for the top banner that I did, the look
166 | and design of the site have been made by the SF crew upstream. If it
167 | doesn't please you, there are several (currently two) themes. If
168 | these themes do not please you, propose your own upstream. If it
169 | makes it into upstream, it'll make it into the package.
171 | - "not up-to-date" reminders. See three paragraphs above.
173 | - "speed up, you're late" comments. You'll notice I deliberately did
174 | not state any date in this roadmap. I have no clue how long it will
175 | take, what with the NM queue and real-life and stuff, and any date
176 | you'd get out of my mouth would be heavily smelling of alcohol (thus
177 | being void). If you feel I'm late, help me.
179 | On the contrary, here are some examples of interaction and help I'd
180 | *very much* be interested in:
182 | - security advice, with explanations (and patches if possible). I am
183 | absolutely no security guru, and I suspect that there are many ways SF
184 | could be exploited.
186 | - help with the BTS: I haven't focused really on all the evolutions of
187 | SF since the 2.0 release. I expect many people will file reports for
188 | bugs that have already been fixed upstream. Keeping the two BTS as
189 | synchronous as possible would be a big help.
191 | -- Roland Mas <99.roland.mas@aist.enst.fr>, 2000-12-04
197 Apart from the Sourceforge crew at VA Linux, who did (and still do)
198 a great job with SF, I'd like to send my thanks to Guillaume Morin,
199 who wrote a very thorough Sourceforge installation guide. That guide
200 gives step-by-step instructions for the installation procedure, and a
201 big part of the packaging task was to turn these instructions into
204 Thanks also to all who tested packages and helped correct many
207 And mega-thanks to Christian Bayle. That guy single-handedly
208 adapted and fixed all the scripts related to CVS, DNS, SSH accounts,