Did I not just say something about "Who died and made you king" arguments? Yep, over here.I guess I'm the first coordinator for the next puppy Release.
Not to say you aren't qualified or that I wouldn't like you being coordinator. That isn't the point. The point is that I don't recall voting for you, or even saying any kind of opinion about it. For that matter, I only recall a handful of people saying anything.
Before we start choosing coordinators and such, we all need to get together and decide on some sort of structure. There's still the old Foundation (now Community?) that we can fall back on. Have we actually done this already? Again, I don't recall a decision actually being made. I may have missed it, I've been busy this summer.
BTW, why is it that all these references to the Community are on Lobster's wiki? Don't we have our own wiki? Temporary solution until we get organized?
I'm sorry to sound like Mr. We-Need-Rules-And-Regulations. I generally hate them. But we need them with this. Without a structure we will fall apart. This isn't a couple people teaming up here, this is a long term community driven project. I may not have a degree in anything yet, but I have enough common sense to know that nothing will get done without a structure that everybody involved has agreed on.
The first thing we need to do is get everybody together, and discuss whether we want to use the old Foundation structure, or create something new. It needs to give enough time for the people who only visit once a week or so to be involved (that group often includes me, though I try for thrice a week).
Then, we need to hash out how we're going to do this. Not sure if you're aware of the SVN/GIT discussion that went on earlier? We need to decide what we're going to use and how we'll use it. I'll tell you now that if it winds up being a "send your code to Mr. Coordinator and he'll assemble it all" type deal, like all the community editions we've done, then I will not be involved. We need some kind of SVN type system. Barry seems to agree.
As for email, only if anyone off the street can subscribe through an automatic process that doesn't need human involvement. I haven't really used mailing lists so I don't know if there can be permissions so that they can read without sending. We don't need to have a bunch of random fluff going through the development lists, but the development lists are also the most important to make transparent so people can see what's going on. Also there must be an online log of it (not sure if this is implied, just making sure).
May be easier to just use a development forum. Probably would be good to be a separate forum from this one, for traffic considerations. Not private! In fact allow anybody to sign up. But strongly discourage any fluff. Off topic and generic requests for help belong over here and should be ignored, other than maybe telling them that they're in the wrong place and providing a link to here. ttuuxxx, please don't run off and create one overnight. I know you're chomping at the bit, but hold your horses. This isn't a race; there's no need to rush. People might want to propose recommendations about what forum software to use, etc.
I might run my own personal projects with a fly by the seat of my pants mentality, but there's a big difference between a one-man effort and a long term group project that is intended to be used by many hundreds of people! This needs Planning.
Somewhat back on topic, we do need to find out who is interested in actually doing development stuff. I am. I won't support a half-baked scheme, but given proper planning I will do what I can to help out. The first item on my radar is fixing the bug where Xorgwizard only halfway configures xorg.conf for a dual-monitor setup. It should either go all the way, or not make an attempt. Either one would result in a WORKING xorg.conf file. But the halfway approach results in a broken file that I must correct by hand every time I boot with pfix=ram or a fresh install.
This may also be an issue for people who have only one monitor, but both an onboard graphics chip and a separate graphics card.
Otherwise I haven't used 4.xx enough to know what the current issues are. Until halfway through this summer I was still using a derivative of 2.14 for daily use. One thing is that ever since we dropped Xtmix (I think it was Xtmix - the one with the retro look) I've been wholly unsatisfied with Puppy's volume controls. Just haven't gotten around to writing my own, as Alsamixer gets the job done right the first time. But it would be nice to have a proper mixer in the tray. That's something I could do. I've shied away from learning to use GTK with C/C++ for too long anyways. Need to get it over with, as that would open up many new projects to me.
I could also tweak the PetGet manager to have the functionality of Pet-Be-Gone built in. Barry had actually intended something similar from the beginning but never got around to it.
The unleashed createpuppy script needs some work too. I have a crudely hacked local copy that can read the configuration from a config file and then do the build automatically, as opposed to asking a million questions every time, which always annoyed the carp out of me (don't know how the carp got into me though - I hardly ever eat fish...). Mine is crude, I basically just hardcoded it to read from the file and not ask questions. A proper solution would ask if it should ask questions or read a file, and have a default file but accept others. This way one can build Puppy more reproducibly, because you don't have to worry about accidentally putting in a different choice during each build.