On Thursday 20 March 2008 17:41, David Sowder wrote: > Obey Arthur Liu wrote: > > References=20080319015601.GH3506 at freenetproject.org > > In-Reply-To=20080319015601.GH3506 at freenetproject.org > > > > [Sorry if I broke a mailing-list reference chain, I wasn't subscribed, > > so can't just reply and keep the References: fields, Thunderbird won't > > take Lurker's extended mailto: tags and handcrafting a SMTP request > > might just be overkill... ]
Reply To All. :) > > > > I didn't know about this mail until after my discussion with Nextgen, > > but I'll reply to it anyway. We've discussed various problems arising > > from the packaging and solutions to them. > > > >> * arthur@??? <arthur@???> [2008-03-19 00:15:58]: > >> / > >> > >>> Hi, > >>> > >>> I'm a french student of computer science at ENSIMAG[1]. I am looking > >>> > >> for > >> > >>> your feeling > >>> on my proposal for working in your organization as part of the Google > >>> Summer of Code. Hi, I'm one of the mentors and admins. > >>> > >>> I have been using the Freenet software for various reasons for a > >>> > >> long time > >> > >>> and I find > >>> it to be a very interesting endeavour, although not easy to setup./ Past experience with Freenet is good and is obvious from your comment about refs (although obviously refs aren't a problem any more). > >> > > Making it work correctly in a multi-user system is not straightforward > > for exemple. You have to run it manually so there's no deamon > > monitoring.. That kind of stuff. Freenet itself is fine. It's just that > > installing binaries /opt style to ~/ is not really a perfect solution. There are issues on several levels when running on a multi-user system. Proper packaging would go a long way to solving some of them. > >> /> and redistribute under Linux, especially with > >> > >>> distributions which enforce high levels of good practice and standard > >>> conformance like > >>> the Debian-based distributions./ > >>> > >> Agreed, we will need to provide packages at some point. > >> > >>> I am very interested by your project idea to overhaul the installation > >>> packages. > >> > >>> would be a very interesting > >>> task to me. It would also greatly lower the barrier of entry for less > >>> technically > >>> minded users as the Tor project achieved in its distinct field. > >>> > >>> I am a long time Linux user and sysadmin and now have a fairly good > >>> experience with > >>> Linux packaging. I have made packages for private deployment of custom > >>> software on > >>> Linux servers. I am also currently working on a large multiple > >>> distributions packaging > >>> project for Oberthur Card Systems as part of work done through my > >>> > >> school's > >> > >>> Junior > >>> Enterprise[2]. I have access to a large range of architectures and > >>> operating systems > >>> with my schools computer labs. > >>> I have experience with navigating around fairly large C/C++ codebases, > >>> including as > >>> part of packaging work. > >>> > >> Freenet is written in java and that's part of why it's hard to package > >> properly. Do you have any experience with java packaging? > >> > > Sorry about the faux-pas, I don't really know why I still wrote that > > after doing research on java apps .deb packaging. Never packaged > > primarily java apps to be honest, but I dug up a lot of useful > > documentation and interesting tools to bridge cdbs to ant. I am > > confident that something is workable to automate the .deb building > > process in extension of the current building tools. Well, it's a lot easier than it used to be; there are lots of java-based packages in debian now. You would need to develop good packages for a range of architectures: not only debian, but preferably fedora, ubuntu, etc etc. Whether you advise the user to visit the setup wizard, or whether you actually move the key settings into debconf, is up to you. It would also be good if the default install scripts would add an init.d script if possible (or even an @startup cron job, if root access isn't available). It may be worth adding a dedicated user for Freenet. And so on. On OS/X, if you have access to it, we've had a number of reports that the startup script we add doesn't work; it would be good to fix this. > > > >>> For peculiar reasons, I have not done a lot of packaging work for free > >>> software and > >>> I'd gladly reuse my experience for public interest./ > >>> > >> I am not sure I would have mentioned that if I were you. Open-source > >> contribution is more a matter of faith than a way of making money. If > >> your main reason to take part into GSoC is money, you are likely to be > >> disappointed. > >> > > Seems like there was a misunderstanding. My point was that I did a lot > > of things with and around free software but could not so far > > redistribute it, either because of software being only of private > > usefulness or because it happened to be with closed source software. I'd > > gladly rather do something that could benefit free software even if it > > didn't involve monetary retribution. So it's really more of a matter of > > faith. I realize that the Google SoC involves a 'stipend' (what an > > interesting choice of wording) but I do it really more for the > > "internship"-like experience and with the plan to stay inside the > > project and and the whole free software movement. > > I hope I dissipated any misunderstanding. > > > >>> I'm looking forward to any advice about this proposal and am > >> available for > >>> more > >>> details, including schedule. > >>> > >> I suggest you state more clearly what the deliverables of your work > >> will be. How far are you planning to go? Which distributions are you > >> planning to build packages for? Deb. based ones only or are you > >> considering RPM based ones as well? Will you write the server-side > >> scripts needed to maintain mirrors? > >> > > Considering the discussion on IRC a little earlier with Nextgen, I'd > > deliver the whole chain from .deb packages to server-side scripts > > altough it would depend on the solution we would ultimately select. > > I haven't reviewed in detail the release workflow of freenet (didn't > > find it on svn, is it done manually ?) but I'm confident I can work out > > something that can integrate with the current workflow. The jar files are produced automatically on our server. A few things are updated manually, but it should be fully automated if possible so we can have daily snapshots. > > > > The packaging of Freenet is challenging as far as packages go but > > challenges are what keep curious minds going. How do you propose to handle updating? If you enable the auto-updater, your package needs to be tolerant of it; if you don't, you need to turn it off in the config. > > > > I will discuss it further with Nextgen or otherwise as best appropriate. Hopefully nextgens will be available as a mentor this year... > > > > Regards to the whole team. > > > > Obey Arthur Liu. > > > > PS.: You kept me awake shuffling through your code until 6am :p -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080320/1e5ef0a6/attachment.pgp>
