Nekochan Net

One of the nicest things about nekoware has been the quality of the applications. It used to be that you were never afraid to install a nekoware application. Even /beta was 99.9% likely to be fine.

Then we sort of had a lapse Now we've got stuff in there that's a year old and a bunch of stuff that breaks things and ... it's no longer so wonderful

Seems to me that Mr Nekonoko already spends plenty of his time keeping nekochan running, so asking him to keep up with that would be rude. But leaving /beta to stagnate is not a very good thing, either. If we don't do something, it's gonna be just another brick in the wall ...

Idears ?

I am up helping out. My O2 is primed for action.

I suggest we pick up each package in beta, check it against the current source and push it to prod.
Might be an idea to take a look at http://mxcl.github.com/homebrew .

I guess my biggest hurdle is the compiler options for the various Abis, a refresher on what the base level of support necessary and some experience on Linux assumption in some these packages. Some of it is documented on this twiki somewhere. Is my sgi compiler fully functional without a license, or do I have to use gcc? I know historically gcc has been not so good on MIPS. I'm sure many here would never dream of using it.

Anybody interested in helping who isn't familiar with the process should start by reading this guide to packaging software for Nekoware . And I say that as somebody who needs to read it...

My first goal is simply to get /beta cleaned up, so we can start from a known position ... any interest in a thorough winnowing operation ? A semi-automated system, like three votes plus, goes into /current, one vote bad, goes into /problems, two or three votes bad goes into /circular_file ? A sticky thread just for voting, so nekonoko doesn't have to spend all his spare time keeping track ?

Or something like that ?

If we don't work from a dependable base, we're just going to create more troubles for ourselves

I'm wondering more what the testing guidelines are going to be. Does each tester have to fire up every other app in Nekoware to make sure there's no interference?

Edit: I've been drinking, so don't be surprised if I'm missing the obvious...

I wouldn't think so .... even if that were a good idea (in theory, it probably is a good idea !) we don't have the manpower. But we could use some upgrades in the maintenance department ... I would propose something as simple as "three positives in the 'testing' sticky thread and any moderator could move the app to /current" ... with maybe some structure for moving tardists that proved troublesome to /problems ...

Or something like that ? Nekoware is a very valuable resource to anyone running an SGI computer. I'd love to see it get more current, without having to make nekonoko spend hours and hours keeping track.


Good idea. Maybe I should go get a drink as well

I'd be up for helping test and vet beta packages. I just got my Indigo2 running again, and would be happy to put it to good use.

I'm not sure what would be the best way to track votes. I'd be afraid that a thread could get pretty big and spread the data out too much to easily figure out the tally.

I think you're right. On the other hand, the situation isn't going to get better by itself .... got any idears ?

btw, Indigo2's are waycool. Want to trade for an O2 ?

How about a thread for each beta app. Have the thread include the full name of the app to be tested, something like Beta Test: neko_newapp-0.1.13.tardist

I'd suggest that the person who packaged/submitted the app should start the thread - that initial post could include basic details on the app like dependencies or anything else noteworthy.

That naming-convention/single-thread methodology would make it fairly easy to find the thread, and see if anyone had tested the app, if any issues had been discovered, how many yea or nay votes had been cast. And the thread would remain, so if a year down the road someone has just gotten around to loading the app (even if it's been moved to /current), they can see what, if any, issues others might have had - something that might be helpful in tracking down potential problems or as yet unforeseen dependency issues.

That sounds pretty good - except for the part about the person who creeated the tardist creating the thread. I think most of them are dead

OK - fair enough. Until beta is cleaned up, if anyone who decides to test an app without an existing Beta Test thread would create the test thread (so that'd be any app that doesn't already have an originator-created thread).

It probably wouldn't be a bad idea if the person who created the test thread amended/edited the thread title once the testing had received enough votes. Something like Beta Test: neko_newapp-0.1.13.tardist - COMPLETED (or YEA or NAY or whatever). It would leave the thread open if further or future discussion was needed, but would serve as an easy visual clue that the initial testing had been completed.

Might it be worth setting up a separate forum, i.e. Board Index >> Miscellaneous >> Nekoware, if there will be more than a couple of betas?

I'd be happy to chip in with testing.

We used to have a system where submitters would post in the 'Nekoware-current' sticky thread and testers would leave feedback there, but everyone abandoned it. Heck, I can't get folks to notify me when things are uploaded - most of what is in /beta right now is random mystery meat uploaded to /incoming.

That's what I was thinking too, but actually, recondas has a point. With 160 tardists in /beta, this could be something of a problem

I'll go first, there's a few programs I've been using for quite a while that seem to be fine ... maybe we can cut /beta down to size ...

Pymble is going to love this, but a little entry in the wiki about each app might be handy ? I know he doesn't have enough to do, this will keep him off the streets for a while

At one time joerg had a script that would automatically pull the release notes from a tardist and create a wiki entry based on it (he used it on his own wiki). I'm not sure if he still has it anymore; he's pretty much moved on.

The thread-per-package might give you a nice place for people to come back and log problems later. Like if it turns out it does have a bad interaction with another package, or combination thereof, or ...

I've moved one package to /current after three positive votes, but based on the low response to the threads so far we may have to go with just two positive votes.

Don't have any IRIX machines powered up at the moment but if I get time tomorrow I'll have a run at it.

Pretty much the same situation here. I have my Onyx2 half set up, but still have some work to do yet.

I'd love to help but I don't even have an analog monitor to run the little beastie with right now...