DEVELOPERS to CONTRIBUTORS (STAKEHOLDERS) :)

News, happenings
Message
Author
User avatar
ttuuxxx
Posts: 11171
Joined: Sat 05 May 2007, 10:00
Location: Ontario Canada,Sydney Australia
Contact:

Re: 4.2

#31 Post by ttuuxxx »

NathanO wrote:Ttuuxxx,

Did my e-mail get to you, been having problems with outgoing e-mail.

If it did not I will post here or PM as you wish.

NathanO
Sorry Nathan Yes I did, thanks for that, I'll contact you back shortly.
ttuuxxx
http://audio.online-convert.com/ <-- excellent site
http://samples.mplayerhq.hu/A-codecs/ <-- Codec Test Files
http://html5games.com/ <-- excellent HTML5 games :)

big_bass
Posts: 1740
Joined: Mon 13 Aug 2007, 12:21

#32 Post by big_bass »

you can finish the CE you started

that would be a good first step


big_bass


*edited to remove a url link
Last edited by big_bass on Thu 09 Oct 2008, 16:28, edited 1 time in total.

User avatar
HairyWill
Posts: 2928
Joined: Fri 26 May 2006, 23:29
Location: Southampton, UK

#33 Post by HairyWill »

I think it is great that we are talking about this.
This thread title needs to be changed from DEVELOPERS to CONTRIBUTORS (STAKEHOLDERS).

Who gets a say?
What do you want?
What what you like to contribute?

Who would you like to work with?
How should future collaboration be organised?
Many of the best inovations in puppy have been when one or two people work on their own. We DO NOT have successful experiece of large scale collaboration.
Is the future a series of forks?
Would these forks divege or could they run parallel? I believe that a large number of minor architectural decisions will cause them to diverge unless steps are taken to counteract this.
I have been posting here for 2.5 years and still only have a loose grasp on who is an expert at what.
Those with the loudest voices are probably ill equiped to speak (including me). Now is the time for everyone to stand up and answer my first three questions.
Will
contribute: [url=http://www.puppylinux.org]community website[/url], [url=http://tinyurl.com/6c3nm6]screenshots[/url], [url=http://tinyurl.com/6j2gbz]puplets[/url], [url=http://tinyurl.com/57gykn]wiki[/url], [url=http://tinyurl.com/5dgr83]rss[/url]

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

Notes on Compatibility

#34 Post by amigo »

I thought it might be helpful to clear up a few misconceptions about compatibility of any future version with other versions/distros.

Compatibility is not one thing -there are 4-5 different aspects to consider.

Being 'fully compatible' with a Big Brother distro would basically entail creating a spin-off much like Knoppix, sidux or DSL which in theory can mostly be built using the official debian depositories. I think it highly unlikely that this is really what anyone wants for Puppy. That level of compatibility is bound to cramp the Puppy style.

There are 5 kinds of compatibility to consider:
1. Binary compatibility
Contrary to what many people think, binary compatibility has little to do with the kernel version or the compiler version. Binary compatibility means that a program or library compiled on one OS will still run on another OS version -like compiling a program on a redhat system and then running it on Debian. This compatibility is nearly 100% dependent on the *glibc* version which was used while compiling the program or library. The glibc version is at the heart of the system. Often, when glibc is upgraded by a minor version number, compatibility is not maintained for programs which were compiled using another version of glibc. As an example, Slackware-8.1 used glibc-2.2.x (which used to be called libc5). Later versions (up till 12.0) used glibc-2.3.x. Programs which were compiled on Slackware-8.1 with glibc-2.2.x will not run under Slackware-9.1 and later versions.
The compiler version used to create the glibc for a distro is important, but not limiting. You can still use other compilers to create binaries using the new version of glibc. The kernel version is also pretty much non-critical -except that using glibc>=2.4 will require a 2.6 kernel. What is more important is the version of kernel-headers used to compile glibc with. When you start a new distro, the fresh glibc must be compiled using some headers which come from the kernel. But, the version of the headers does not have to be the same as the kernel version!

The first critical choices to make involve choosing versions of glibc, compiler, binutils and kernel headers which work together well. Simply choosing the latest version has never, ever worked. Here is where a little study of self-build projects and/or current major distributions pays off handily. You should always start with versions of these which have been proved to co-operate well. But, when compiled, the glibc version, its' options and the kernel-headers version used is what determines whether programs you compile will be binary-compatible with another distro -or vice-versa.
While it is possible to use another version of gcc to later compile programs with your new glibc, the choice of main compiler and its' location in the filesystem are essential to compatibility with libstdc++ -that's the libs used for programs which are written in C++. This is where binary-compatibility gets really sticky, because C++ programs are much more closely tied to the libstdc++ libs produced when compiling glibc. These libraries are compiler-dependent. The ld-linux program produced along with glibc, will try to link programs to be run to the glibc version and to the location of the compiler libs(libstdc++) -although these can simply be placed in the normal library search path.

In summary, the glibc version is the one thing that really 'defines' a major release of an OS. Changing the glibc version always entails re-compiling quite a few of the standard programs. Changing the kernel version is pretty much independent. The binutils and compiler version are chosen to accomodate them with the glibc version.

The trinity of compiler-binutils-glibc versions is what is known as a tool chain. For a fresh distro, these three items should all have been comoiled using each other. This can only be done with multiple passes. After that, all the programs for the new distro are built using the same toolchain and using the same kernel-headers which wre used for compiling glibc itself.

2. init script compatibility
There are basically three types of init system in common use. Debian uses an LSB-compatible system. SysVinit is used by redhat and most other distros. Slackware and its' derivatives mostly use what gets called BSD-style init. It really is a SysVinit, but the scripts are much simpler and easier to work with, similar to the those used by BSD.
Since init processes are controlled using shell scripts, differences between the various systems can nearly always be worked out, but this must usually be done manually. Programs which use the redhat-style SysVinit system have to be modified to run under debian-based systems.
Puppy, being a LiveCD has a basic init style which is very different from any standard distro, but what I am referring to is more about accessory programs than the basic functioning of the init process. Programs which are usually called 'services', like servers and other such, which must be started during bootup, use scripts in /etc/rc.d under Puppy. The Puppy style use of /etc/rc.d is most similar to the Slackware-style -but Slackware includes compatibility with redhat SysVinit-style init scripts. And, in fact, LSB-compatibility can also be included. It is possible to use all three types on one system, but that would make a pretty confusing system. Most users don't have to worry about this -only dvelopers and maintainers of the common services programs would need to have a good understanding of all this.

3. Directory layout compatibiblity
The situation here is better than it ever has been. Most distros are using mostly the same locations for important files. There used to be a lot of diferences with KDE being installed under /opt on some systems, with GNOME being installed under /opt on some and under /usr on others. The main remaining diferences these days, invlove the placement of shared data, doc, man-pages and info pages. Again, debian follows the LSB stabdards and places docs, ifo and ma-pages under /usr/share/(doc,info,man). Slackware uses /usr/doc,info,man and the redhat distros vary between the two. the placement of all these files is usually non-critical -that is at runtime, compiled programs
or libs don't know or care where these files are located. there are exceptions where programs make direct acces to documents(like help files), but these locations are alway configurable at compile-time. And converting most packages to another directoiry layout is usually no problem -except for the shared-data location and the prefix. The shared-data and prefix are often hard-coded into programs and libs at compile time, but these are also configurable (or can easily be changed with a simple patch)

4. package format compatibility
You can use rpm as a package format without the packages being compatible with other rpm systems. The same for using dpkg -using it doesn't necessarily mean your packages will be comopatible with debian-based systems. But, if you hope to have your new distro have binary or full compatibility with any other distro, you will almost surely want to use the same packaging format as that distro. Yoh may use alternate tools to create packages of the same format. the alien program does a pretty good job of converting packages between formats -it does so by using the same tools as the donor and target distro.
Package format is still a great weakness in Puppy. The two formats of pet and pup are both faulty. pets are weak on install-time options and pup's have maybe too many install-time options. It is ridiculous to have to create 5-7 files and archives to go with your finished program, like with pups. pets, on the other hand, have little facility for performing actions at install-time which are needed with lost of programs. The debian system is rich with such features without being tooo burdensome. Slackware packages offer the chance to include a doinst.sh script which can perform extra actions when insatlling a package(just after unpacking the script is run.) Debian offers even more chances, because packages are first unpacked in a temporary directory before being moved/copied to their final destination. this allows for a chance to backup files which we bill overwritten by the new package. Debian also also allows for two separate scripts which can be run when removing a package -one before and one after removing the package. rpm packages also offer similar options.

Choosing or creating a package format and package management system are extremely important. The lack of an easy-to-use, but feature rich installation method has always been a big fault in Puppy. And ease-of-use must also translate into easy-to-create. developers should have acces to an easy way of packaging their programs.
Most are aware that Slackware package management involves no resolution of dependencies, although third-party tools can add this capability. rpm distros have the bad fame of causing dependency-hell. Debian has the good fame of having nearly faultless package management which lets you dependably upgrade or even downgrade at will.
Designing and maintaining a true package management system which resolves dependencies is a nightmare and invloves a tremendous amount of work and testing. Maintaining a single database (like swaret) is one of doing it. But then each system must have the up-to-date database installed in order to use it. rpm and debian systems use in-package information to provide dependency resolution. doing it this way means that every person who creates or mainatins a package has to know how to correctly provide that info and keep it up to date.
A central database is somewhat easier to manage and can be done by less people, but it may be harder to keep it truly up to date.

I've just thrown this together to tickle your thinking a little. I may add to it or edit it later if their are questions, addtitional points to make or inconsistencies.

You can choose between any or all of the above aspects independently of the build environment. In other words, you can build a complete slackware-compatible system using a T2 build environment. Ot any other combination you choose. If you do the thing properly, the new toolchain is built first and everything that follows gets built using that toolchain -no matter which system is hosting the build. Once you new system is up and running at a level where it can reproduce itself, ther is no more need to run the original host system.

User avatar
ttuuxxx
Posts: 11171
Joined: Sat 05 May 2007, 10:00
Location: Ontario Canada,Sydney Australia
Contact:

#35 Post by ttuuxxx »

I have to agree with you Amigo, Oh so many times I've gotten incompatibilities with Glibc, Thats where it sits with big brother distro's. also I think that puppy only has 2 people who could pull off a successful base in a timely manner, Nathan O or cb88. Nathan also has local linux support group who could help him out. I'm not sure if they would want to take on something like that? In the past I've mentioned on numerous occasions Maybe Ubuntu Intrepid, as the big brother and then Barry even mentioned that his future project might use that as a Big brother distro.
I personally think if both parties keep to the same platform and move in the same or separate directions after that it could be very helpful for both of parties. I've always liked the ubuntu repo. Its well laid out. Probably the best linux one. I don't like how broken down each package is. They even break down single applications. http://packages.ubuntu.com/intrepid/ How do others feel about it,? When it comes to debian, http://packages.debian.org/stable/

Something else I was thinking about, It would be nice if Puppy kind of stuck with one series for maybe at least 12months maybe be more. It would give it time to mature better. If we kept our resources focussed on one model with patch releases, wouldn't that give us a better working Os, we went from 2.17 to 3.0,3.0.1,4.0 in about a year or a bit less. Its too bad the 3 series was so short lived, I've read numerous times how people really enjoyed it being slackware compatible actually never read a complaint against it!. Sure Slackware doesn't have a large repo that Ubuntu or Debian have but. Slackware binaries have less dependents after the first initial extra libs, Plus the main packages that most people want, Slackware usually has them. Puppy will always be independent of other distro's I feel because of all the extra programs we have from our excellent developers and trouble shooters, like Pfind, Pburn, Puppy package manager, Plus wireless fixes and nonstandard screen resoutions etc these unique packages
combined with colourful community is whats makes Puppy so great and unique. So when it boils down to it, If puppy was to have another big brother distro, Debian, Ubuntu, Slackware its all good :)
As for puppy 4.2 or 5.0 being the next model number should we continue with what Barry has started, or should be go with a new model compatible with a big brother distro? Start fresh ? for 5.0 but we could actually move closer towards Ubuntu Gutsy if we stick with 4.0 series since it uses the same Gilbc as puppy 4.0 and is already mostly compatible. http://packages.ubuntu.com/gutsy/
These are just ideas I'm tossing out, Something to think about.
ttuuxxx
http://audio.online-convert.com/ <-- excellent site
http://samples.mplayerhq.hu/A-codecs/ <-- Codec Test Files
http://html5games.com/ <-- excellent HTML5 games :)

User avatar
ttuuxxx
Posts: 11171
Joined: Sat 05 May 2007, 10:00
Location: Ontario Canada,Sydney Australia
Contact:

#36 Post by ttuuxxx »

HairyWill wrote:I think it is great that we are talking about this.
This thread title needs to be changed from DEVELOPERS to CONTRIBUTORS (STAKEHOLDERS). Done

Who gets a say? I think we all should
What do you want? a big brother distro for extra support/files, why reinvent the wheel??
What what you like to contribute? Lots of time, Packages, Graphics, Help to new users, Maybe a small amount of new programs, I'm still learning on the actual programming side. As much as I can do, about 50hrs a week or so.

Who would you like to work with? This is a hard one to answer, most people like to bash me around,LOL
How should future collaboration be organised? Simple Vote via locked forum where only a select list of trusted individuals have a vote. Developers can develop applications but they aren't graphic artist. etc
Many of the best innovations in puppy have been when one or two people work on their own. We DO NOT have successful experiece of large scale collaboration. Doesn't mean we couldn't with proper voting safe guards, less emotions and more productive production will happen.
Is the future a series of forks?
Would these forks divege or could they run parallel? I believe that a large number of minor architectural decisions will cause them to diverge unless steps are taken to counteract this.
I have been posting here for 2.5 years and still only have a loose grasp on who is an expert at what.
Those with the loudest voices are probably ill equiped to speak (including me). Now is the time for everyone to stand up and answer my first three questions.
http://audio.online-convert.com/ <-- excellent site
http://samples.mplayerhq.hu/A-codecs/ <-- Codec Test Files
http://html5games.com/ <-- excellent HTML5 games :)

User avatar
notned
Posts: 51
Joined: Wed 04 Apr 2007, 22:30
Location: California

#37 Post by notned »

Newbie, so I'm hesitant to input, but... Today we got my step-daughter's driving permit. I feel like she pulled a fast one she said that her drivers ed class would expire when she turned 16. I may have a talk with her about that one.

Here's the point. We all know not to believe bad people when they say gotta do it now. I don't think we have to believe good people either.

What exactly is the rush?

User avatar
ttuuxxx
Posts: 11171
Joined: Sat 05 May 2007, 10:00
Location: Ontario Canada,Sydney Australia
Contact:

#38 Post by ttuuxxx »

notned wrote:Newbie, so I'm hesitant to input, but... Today we got my step-daughter's driving permit. I feel like she pulled a fast one she said that her drivers ed class would expire when she turned 16. I may have a talk with her about that one.

Here's the point. We all know not to believe bad people when they say gotta do it now. I don't think we have to believe good people either.

What exactly is the rush?
Well we aren't rushing, Barry K. Puppy's founder is retiring from Puppy which is new to us all and were just trying to sort some ground work out, Building a distro is a difficult task hands down, So we are trying to form some sort unity and direction to move forward in the up and coming months. We have no layout, model and if we don't act somewhat in a timely fashion and iron out the preliminary issues, then who knows the fate for puppy.
It would be nice to go on as usual, but not this time around. Nothing is being built yet, We are merely trying to figure out.
- Is future puppy's going to have a large or small community voice.
- Will it have a big brother or stand alone
- Are the Developers going to be the new dictators, without community input? And if so, shouldn't it be Just 1 developer calling all the shots, ? Probably the main base builder maintainer. If not where do we call the line for developers inputs in what? Or do we just put every issue into a vote? I think we need a new "Puppy Linux Foundation" If people are part of something then its the ties that bring us closer.
ttuuxxx
http://audio.online-convert.com/ <-- excellent site
http://samples.mplayerhq.hu/A-codecs/ <-- Codec Test Files
http://html5games.com/ <-- excellent HTML5 games :)

User avatar
ttuuxxx
Posts: 11171
Joined: Sat 05 May 2007, 10:00
Location: Ontario Canada,Sydney Australia
Contact:

#39 Post by ttuuxxx »

big_bass wrote:http://www.phrases.org.uk/bulletin_boar ... s/737.html

you can finish the CE you started

that would be a good first step


big_bass
Tronkel builds it, I just contribute to packages, and bug squashing, troubleshooting, So when tronkel has time to release a new candidate then we move forward, He has released a lot of them, and each one gets closer to final. Hes done a great job and looking forward to future releases.
ttuuxxx
http://audio.online-convert.com/ <-- excellent site
http://samples.mplayerhq.hu/A-codecs/ <-- Codec Test Files
http://html5games.com/ <-- excellent HTML5 games :)

raffy
Posts: 4798
Joined: Wed 25 May 2005, 12:20
Location: Manila

kernel development

#40 Post by raffy »

ttuuxxx
I guess I'm the first coordinator for the next puppy Release. Smile
Well I have to start somewhere
It looks like PlatonicP, alcy and others are already into development for the next Puppy core:
http://murga-linux.com/puppy/viewtopic.php?t=33461
Compiling the new 2.6.26 Kernel for puppy
Puppy user since Oct 2004. Want FreeOffice? [url=http://puppylinux.info/topic/freeoffice-2012-sfs]Get the sfs (English only)[/url].

User avatar
ttuuxxx
Posts: 11171
Joined: Sat 05 May 2007, 10:00
Location: Ontario Canada,Sydney Australia
Contact:

Re: kernel development

#41 Post by ttuuxxx »

raffy wrote:ttuuxxx
I guess I'm the first coordinator for the next puppy Release. Smile
Well I have to start somewhere
It looks like PlatonicP, alcy and others are already into development for the next Puppy core:
http://murga-linux.com/puppy/viewtopic.php?t=33461
Compiling the new 2.6.26 Kernel for puppy
well He only has 34 post and never compiled before, thats a very large task to compile a kernel even from the most experienced developer.
But I do applaud him for trying. But really what has that to do with Coordinating developers?
What I'm trying to do is organise the developers on task they want to do to and try to keeep to some sort of time frame for releases schedules, I was never going to try to compile a kernel for a main puppy release, plus we haven't figured out if we were going with t2 yet and if so Platonic kernel efforts wouldn't be needed because thats a part of T2. But if he is keen he could help out other ways.
ttuuxxx
http://audio.online-convert.com/ <-- excellent site
http://samples.mplayerhq.hu/A-codecs/ <-- Codec Test Files
http://html5games.com/ <-- excellent HTML5 games :)

User avatar
Pizzasgood
Posts: 6183
Joined: Wed 04 May 2005, 20:28
Location: Knoxville, TN, USA

#42 Post by Pizzasgood »

I'm not trying to argue here, just want to point something out. I say this because I feel like maybe I've been argumentative lately. Last night I was on a roller coaster for the first time in a year and it made me realize just how down I've been lately. Even though the coaster seems to have stolen my cell phone, it was a very good ride and I'm happy again. :)
if so Platonic kernel efforts wouldn't be needed because thats a part of T2.
T2 helps automate compilation. AFAIK, it doesn't magically know which modules we do and do not need. In my experience with Gentoo, configuring the kernel is the tricky part. I had to recompile my kernel 10+ times before everything worked properly. I haven't messed with Puppy's kernel yet, but I know it needs a couple patches. That's another part that can become tricky, and T2 probably doesn't help much there either.

So IMHO, he could be a valuable resource to tap if he gets it working.

Who gets a say?
What do you want?
What what you like to contribute?

Who would you like to work with?
How should future collaboration be organised?
*I think anybody and everybody should be able to make suggestions, but a committee/council/group thing should vote on the direction Puppy should take. But how to decide who is in that group? I think that once the group is created, it would handle inducting new members on its own, based on merit. That leaves us with initializing the group. We could just do a "who wants to be in the group" question, and if nobody has a problem with the end result, call it the group. If there is a problem, maybe defer to Barry to get the initial group selected. Then, the group could induct any people it feels should have been allowed in.

*I want for Puppy to continue being a sub-100mb distro, to continue using a clean self-contained format like it does now with the filesystem images, and to maintain a lack of overall internal systems. Clarification on the last bit: In Puppy, if I want to change something I just change it. I don't have to worry if it will mess up the package manager, or goof up the tool that you're supposed to use to alter the boot process, or throw my desktop environment out of whack. If I want to replace a particular application, chances are no other things are set up to use it so I won't bork the whole system. Everything is mostly independent.

*I like the idea of Puppy loading into ram, along with the pfix=ram option and the .sfs file concepts. There are a lot of limitations though, particularly concerning what is and isn't loaded into ram, read-only .sfs files, getting to choose if things are saved, etc. So I want to play around with improving this stuff. That's more of a longer term goal though. In the nearer term I'd like to work on the stuff I mentioned earlier in this thread and on any other misc stuff I bump into. There have also been some repository and package-management related things that have come up over the years which it may be time to start considering in the not-quite-near future.

*I've generally just done my own thing. I don't have any preferences.

*I suggested a "task pool" earlier, where people would check a list of things that need doing along with priorities and decide what to work on from there (if they come up with something else needing doing they could either add it to the list or just do it themselves, unless it's some big thing that would need approval first). Another option would be to assign people general areas and have them maintain that portion, fixing all bugs they find and taking care of things that need doing. That way you could make sure no area gets ignored, but you'd also be constraining people to limited areas where they can contribute. Maybe allow trades and occasionally do a rotation to shake things up and bring fresh eyes into the areas.

Maybe a hybrid approach, where people have a region of Puppy that they give extra priority to, but can still take on jobs in other areas of Puppy if they don't have much else to do and there are a bunch of more important things elsewhere.
[size=75]Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib[/size]
[img]http://www.browserloadofcoolness.com/sig.png[/img]

Mic67

#43 Post by Mic67 »

I recall this quote from a sailing forum:

"The earth was not created by a committee"

Nor was puppy.

mic67

User avatar
alienjeff
Posts: 2265
Joined: Sat 08 Jul 2006, 20:19
Location: Winsted, CT - USA

#44 Post by alienjeff »

ttuuxxx wrote:
HairyWill wrote: Who gets a say? I think we all should

<snip>

How should future collaboration be organised? Simple Vote via locked forum where only a select list of trusted individuals have a vote.
So everyone gets a "say," but "only" a "select" list of "trusted" individuals get to vote?

How arrogantly clever, ttuuxxx!
[size=84][i]hangout:[/i] ##b0rked on irc.freenode.net
[i]diversion:[/i] [url]http://alienjeff.net[/url] - visit The Fringe
[i]quote:[/i] "The foundation of authority is based upon the consent of the people." - Thomas Hooker[/size]

Trobin
Posts: 968
Joined: Fri 19 Aug 2005, 03:16
Location: BC Canada

#45 Post by Trobin »

alienjeff wrote:
ttuuxxx wrote:
HairyWill wrote: Who gets a say? I think we all should

<snip>

How should future collaboration be organised? Simple Vote via locked forum where only a select list of trusted individuals have a vote.
So everyone gets a "say," but "only" a "select" list of "trusted" individuals get to vote?

How arrogantly clever, ttuuxxx!
Well AJ, how would you do it?
[url]http://speakpup.blogspot.com[/url]

John Doe
Posts: 1681
Joined: Mon 01 Aug 2005, 04:46
Location: Michigan, US

#46 Post by John Doe »

alienjeff wrote:
ttuuxxx wrote:
HairyWill wrote: Who gets a say? I think we all should

<snip>

How should future collaboration be organised? Simple Vote via locked forum where only a select list of trusted individuals have a vote.
So everyone gets a "say," but "only" a "select" list of "trusted" individuals get to vote?

How arrogantly clever, ttuuxxx!
almost like watching a benign dictatorship mold into a democratically labeled communist organization, isn't it.

User avatar
Lobster
Official Crustacean
Posts: 15522
Joined: Wed 04 May 2005, 06:06
Location: Paradox Realm
Contact:

#47 Post by Lobster »

At the moment, Puppy is developer led.

That is where it can stay if we have a developer willing to put 4.2 together. This will mean most of the work will be with the Developer (Barry has been given a LOT more coding help from others lately).

The 4.2 developer will have to understand coding and how to put together an ISO base but does not necessarily have to do much coding themselves. It is still a lot of work, just updating packages etc.

By using a release ISO often model (if possible), we can test and only would lose a weeks work if say the ISO was uploaded regularly and a need to change developers occurred (unlikely but possible) . . .

This is the preferred model that Barry used and was used in the successful community editions that came to fruition as 'official' Puppy releases.. An extreme example of this was Puppy Linux 2.03. Hacao did ALL the coding, added Open Office, released one test version and then the final Official Puppy version.

I keep getting this impression that some people want to 'change everything',
in fact small incremental changes can be added as they become available on the forum. So all that is needed for 4.2 is someone prepared to put together what IS available..

People I know are capable of this from past experience are BarryK, MU, Pizzasgood, John Murgha, Warren, Nathan, Hacao, Raffy, Tronkel and some of the Puplet creators who want to 'step up a notch'

So it is up to one of those to step forward and say yes I will have a go.

Maybe BarryK will surprise us with a plan - he often does ;)
Puppy Raspup 8.2Final 8)
Puppy Links Page http://www.smokey01.com/bruceb/puppy.html :D

User avatar
tronkel
Posts: 1116
Joined: Fri 30 Sep 2005, 11:27
Location: Vienna Austria
Contact:

#48 Post by tronkel »

Lobster wrote:
So it is up to one of those to step forward and say yes I will have a go.
Problem is, people who really understand what it takes to "have a go" know exactly what is involved in trying to step into Barry's shoes.

Unquantifiable hours compiling, scripting, testing, bug tracing, repair and thinking out new innovations. Building an ISO takes about 10 mins on a medium speed machine using Unleashed. This is the easy bit - anyone can do it - you don't need to be much of a developer for that. On the other hand, building on OS from scratch is a job for heavyweight developers only.

We don't actually have anyone who can do what Barry has done though. The time factor alone would put most people off - even if they had the will and the expertise to get the job done.

With Barry retiring, the Puppy project is in "damage limitation mode". This means, that if the project is to survive into the future, difficult decisions will need to be taken and flexibility will also be required. We may have to consider options that were never necessary in the past, simply because Barry did everything necessary to produce the all-important base versions - without which there would be no Puplets CE's etc.

A project committee may well be the only temporary solution available, in order to ensure that the project doesn't keel over. In the meantime, we should be looking round to try to find a Chief Implementer-cum-Project Director who is worthy of the task. I don't believe there is anyone within the community at present, who has such a track record and who also has the time to devote to the task.
Last edited by tronkel on Sun 21 Sep 2008, 09:50, edited 4 times in total.

raffy
Posts: 4798
Joined: Wed 25 May 2005, 12:20
Location: Manila

The young ones

#49 Post by raffy »

I vote for the young ones to have important roles in the development of Puppy Linux. The really young ones here are students, like Pizzasgood, cb88, SirDuncan, {please add names that I missed}...

ttuuxxx is quite young, too, but that's compared to the old me. :) He will still be the most prolific puplet and package creator no matter who we choose as leader.

When youth is combined with merit (contributions to Puppy development), probably Pizzasgood will easily top the list, as he has been contributing to Puppy development since his high school days. FYI, his latest completed project is PCPuppyOS, a commercial-grade puplet.

Pizzasgood is already used to managing affairs in Puppy - note that he has high privileges in this forum, and is able to moderate difficult discussions. He can also easily shift gears to publishing a blog, as he keeps his own website.

Many regulars in this community know how to be selfless, and would easily get into the routine of supporting a leader, while also steering/influencing others into a favored direction of development. This will not be difficult as the Puppy ideals are clear: more computing power with less resources.

PG (ok, I shortened the name) is already used to scanning this forum for new developments, so all he has to do is write notes about the direction Puppy is taking, and to request help by volunteers in certain areas of development.

Meantime, the community will be happily chugging along in innovative work, and what it produces may or may not get into the official Puppy.

Development will not be about committees, but about innovations that are put together by a leader, to build one official version.
Puppy user since Oct 2004. Want FreeOffice? [url=http://puppylinux.info/topic/freeoffice-2012-sfs]Get the sfs (English only)[/url].

User avatar
Lobster
Official Crustacean
Posts: 15522
Joined: Wed 04 May 2005, 06:06
Location: Paradox Realm
Contact:

#50 Post by Lobster »

My general policy with developers is to keep out of their way and let them get on with their magic.

Pizzasgood has a great attitude and I would love him to do it . . . even if it takes him 6 months to a year I know he can deliver . . .

You can find an old interview with him here:
http://tmxxine.com/wik/wikka.php?wakka=PizzasGood

Pizzasgood has a proven record for diplomacy, skill, innovation and flexibility.

'There is another' [said in my best yoda voice]
However when I ask about CE versions - 'no time.'
No harm in asking again.
Pizzasgood are you up for it? :)

One of the strangest experiences was when I had Vector Linux on my HD (it was meant to be used for developers and I was role playing . . . :wink:

I managed to run and use Vector Linux programs from the Puppy CD
This has now been formalised in the 'underdog' system - that I know very little about. Is there any traction in this route?
Puppy Raspup 8.2Final 8)
Puppy Links Page http://www.smokey01.com/bruceb/puppy.html :D

Post Reply