Announcement List for Technical Reports

Posted 4 Dec 2000 at 10:35 UTC by bgough Share This

In the Advogato discussion "Quality vs Quantity" (Article #157) mettw suggested the idea of a journal where free software developers could submit articles about their projects in a scientific fashion. As a first step towards this I've created a "free software tech-reports" announcement list (info-tech-reports@gnu.org) for posting announcements of technical reports, papers and other types of formal publication about free software projects.

This will work in a similar way to the "preprint servers" used in the scientific community: authors post the title and abstract of their work to the list in a standard format, and subscribers receive an email digest of new announcements. The full text of each paper is accessible in postscript or pdf via a url in the message.

The list is going to cover any software under GPL-compatible licenses -- a very wide scope. The aim is to have something which will alert people to articles they might not otherwise have found, and give everyone an overview of the major developments in other projects. I will moderate the list to keep up a professional standard and generally try to make it unobtrusive.

To subscribe to the announcement list, send email to info-tech-reports-request@gnu.org with "subscribe" in the subject or body.

If you've written an article recently, or in the past, please go ahead and submit an announcement. Articles need to be freely redistributable, either under a "copying permitted provided this notice is preserved"-type license or a free documentation license such as the GNU FDL. This is so that people can distribute the articles along with the associated software. If you have any questions about the procedure there is a tech-reports-discuss@gnu.org mailing list for general queries. I will hold the first postings in the moderation queue until a sufficient number of subscribers have had a chance to sign up.

For more details see the info-tech-reports@gnu.org page at mail.gnu.org.


check out eprints, posted 4 Dec 2000 at 19:34 UTC by dchud » (Journeyer)

Fyi, it looks like eprints has finally hit 1.0. You might want to use it to set up an OAI-compatible print server. It has author self-archiving and email-alerts built in...

re: eprints (oops), posted 4 Dec 2000 at 19:41 UTC by dchud » (Journeyer)

he-heh, now i see that you worked on xxx.lanl.gov. sorry for pointing out the obvious without checking first... :(

one thing I forgot to mention, posted 4 Dec 2000 at 20:12 UTC by bgough » (Journeyer)

one thing I forgot to mention is that there is a template for the announcements (fill in the various fields and then post it). It can be found on the mailing list web page, url given above.

Republishing tech reports in peer-reviewed form?, posted 5 Dec 2000 at 22:27 UTC by jch » (Master)

You require the tech reports to be freely redistribuable. I assume that this includes commercial publication without permission from the authors and copyright holders, right?

Doesn't this cause problems for people who'd like to submit a tech report that they might later want to publish in the traditional (peer-reviewed) press? In particular, how does that work with copyright assignments to journals?

Re: Republishing tech reports in peer-reviewed form?, posted 6 Dec 2000 at 10:36 UTC by bgough » (Journeyer)

Yes, when journals require a transfer of copyright they usually want to prevent distribution of the article by anyone else, including the authors. Their economic model has evolved in the pre-digital age --- they own and control access to information, rather than providing a service of redistributing it. This is the same situation as proprietary software companies vs free software redistributors. Technological change means that these journals now restrict the flow of information, compared with what is possible.

The solution to the problem is to use journals which don't restrict redistribution. For example, in AI there is the Journal of Artificial Intelligence (JAIR). If there isn't a suitable free journal then one can be created by people in the field. Ultimately this is the only way that their work can be made available to everyone. I have suggested this on the list's page -- I think it would be good to have a freely redistributable journal like "Software Practice and Experience" but for free software. There is a tech-reports-discuss@gnu.org list for further ideas.

Organized Linux QA Proposal - linuxquality.org soon, posted 6 Dec 2000 at 13:09 UTC by goingware » (Master)

Last May I decided to test the 2.4.0-test1 kernel on my slackware laptop and soon found a bug in which my Adaptec APA-1480 Cardbus SCSI Host Bus Adapter wouldn't work.

I looked in the kernel sources and found instructions about what to do when one had this kind of bug - report it to the linux-kernel mailing list.

Well, that's what I did and although linux-kernel accepts messages from unsubscribed users (so they get lots of headhunter spam), I wanted to follow up to be sure the bug got fixed so I subscribed for a while. And boy, didn't I get a lot of email.

Further, it took some work to get the bug fixed. People would post patches, and I'd reply with notifications that the patches worked, or maybe that there were additional problems, but it took some effort to see that the bug fixes stuck.

I was OK with this being a mailing list junkie and a developer, but I felt that this wouldn't really work for the user at large, and probably in reality wasn't all that great for the kernel developers either.

So I made a suggestion entitled Organized Linux QA? in which I suggested:

There are a lot more people who are capable and willing to simply try out configuring and building a new kernel and to report the results than there are who can track down the cause of the bugs, but a lot more hours are needed just to try out that huge permutations of configurations needed to find that a bug exists.

What I was thinking would be useful would be to have a database where people who wanted to volunteer to do QA could register themselves, and then enter the configurations of machines that they have available to them - brand of machine, CPU time, PCI and ISA cards, and so on. They could have URLs for pages with further descriptions of the machine.

Each user would give a name to a preset configuration and then when reporting bugs would indicate what preset they'd used (I'd longed for this at companies I'd worked at).

There would be a contact method there. Either the user could log in and check their messages, or indicate that messages meant for them should be dropped in their email.

Then a kernel developer (and it could be expanded to include any free software) could send a message to anyone who had a PhooTek PCI WhizzoMaster Card and say "I've got a new driver available, please try it out", and then everyone would try it out and be able to file not just bugs, but successful tests.

Testers could log relevant information such as the .config files they'd used for particular tests and so on.

Further, you could do boolean searches such as "show me all the test results with machines that have a 3C-905 ethernet card and an adaptec 29160 SCSI host bus adapter with CONFIG_HAPPYMEAL set in their kernel build".

As a step towards making this easy for people to find, I registered the domains "linuxquality.org" and .com. A number of folks offered to host the site, my feeling for the best choice was a certain server facility that enthusiastically supports open source and that has a fat net connection.

I got a generally positive response to this suggestion, although it was suggested that folks like Linus and Alan Cox would need to support this.

One thing that's important to understand is that the Linux kernel development is so distributed that not everyone who contributes is actually connected to the Internet. Some folks mail their patches in via gateways and even on floppy disk (or so I've heard) and so a web database would cut these folks off if that was the only way they could get their bugs. One solution would be to allow developers to request that summaries be emailed to them, or even hardcopies sent regularly via postal mail.

Unfortunately, my consulting business got real busy with the need to ship a product and I was also married in July. So I never got time to even start on this. I'm not out of the woods yet but there is hope that I will have a normal life again soon, and I'd like to pursue this. I just sent an email to the folks who'd offerred to host it asking if they're still interested.

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

X
Share this page