DEVELOPERS to CONTRIBUTORS (STAKEHOLDERS) :)

News, happenings
Message
Author
User avatar
cb88
Posts: 1165
Joined: Mon 29 Jan 2007, 03:12
Location: USA
Contact:

#21 Post by cb88 »

well .... regardless of above and past arguments we do have an svn

you can get acces from me by PMing your sourceforge unix account name

all you need to do is figure out how to use it SVN that is i haven't the time between a datastructures in java and engineering statisics

I do however have time to do what very little management is needed with the sourceforge page which up till now is just adding a few people to access it

i have compiled T2 with 686 optimisations and the binaries that i tried out in slackware seem very fast compared to plain slackware so multiple builds will be of interest

a T2 profile to generate a livecd would be very welcome and probably imperative to compete with the likes of the debian livecd remasters which will likely be very fast and have a huge applicaton base

most people are behind either T2 or gnomeslack... IMO T2 doesn't really hurt us since slackware has a pretty pittiful package selection anyway due to the fact that most of its users compile thier own apps on the other hand with T2 we can easily tweak out entire kernel to what ever we want VERY easily and rebuild time is not *that* bad ...like 3.5 days on a dual PII for the piglett base running slackware

FINALLY! what do we need to have on SVN?
3 things at least for now
-piglett T2 profile (will need updating to T2 8.0 when it is released currently we are using T2 8.0 trunk as of late 2007)
-archive of all puppy apps/scripts
-unleashed scripts (might be replaceable by T2 itself) ... plan integration by 5.0?

what do we need other than T2? a source snapshot !!!
it would be much appreciated if someone would download and host a .bz2 or .lzm of the full T2 source not just the basics BEWARE it might get HUGE multi GB of source the puppy base it self is a tar over 1gb!

it might be prudent to wait for the 8.0 release to do this snapshot...

as always these are sugesstions so what do you think?

on a side note slitaz it VERY interesting it claims to boot with only 5 scripts and a config file.... are the boots scripts that tiny in puppy? in anycase we absolutely need better documentation on how barry scripts and how linux boots in general
Taking Puppy Linux to the limit of perfection. meanwhile try "puppy pfix=duct_tape" kernel parem eater.
X86: Sager NP6110 3630QM 16GB ram, Tyan Thunder 2 2x 300Mhz
Sun: SS2 , LX , SS5 , SS10 , SS20 ,Ultra 1, Ultra 10 , T2000
Mac: Platinum Plus, SE/30

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

#22 Post by Pizzasgood »

My beef isn't about who is in charge or what structure we'll have. It's that we need to actually make known when we're making a decision, and then give people a chance to provide their input.
Ttuuxxx has kindly offered to put his considerable energy and diplomatic skills (in development) into 4.2

No one else has shown any inclination
It is very difficult to vote without candidates. Do we have any?
Not that I'm aware, but how long had it been? Three days or so? Besides which, I wasn't even aware that we were making this decision now! I thought we were still trying to pin down how things would work so that we'd be able to make an intelligent decision afterward. Maybe we don't even want to do a coordinator approach. Maybe something completely different would work better. But did we get a chance to discuss it? Maybe for a day or two. Woopdeedoo.

I have a lot of respect for you Lobster, but sometimes you rush things too much. There's a limit to how fast we can go and still keep everybody in the loop. And this is coming from a guy who's favorite fictional character is Sonic the Hedgehog...



well .... regardless of above and past arguments we do have an svn

you can get acces from me by PMing your sourceforge unix account name

all you need to do is figure out how to use it SVN that is i haven't the time between a datastructures in java and engineering statisics
Yes we do, I didn't forget that. It will be useful too. But I'm referring to something that can hold the entire Unleashed Tree, which I'm nearly certain is beyond what SourceForge will let us do. I could be wrong of course.

As far as I'm aware, the only reasonably efficient way to have multiple people working on this, while avoiding collisions, maintaining an accurate record of exactly what has changed and who changed it, and making it easy for anybody to follow along, is to put the whole unleashed tree into SVN or GIT. Technically it would probably be most efficient to split the packages directory from the unleashed directory and have them side-by-side on SVN, so that people can checkout the unleashed directory itself without grabbing the data for all 500 packages. Like I said on the thread you started before, the SourceForge SVN would then be used for all the stuff that doesn't fit inside unleashed along with the unique-to-Puppy applications. Things like T2, the P* applications, maybe Pebble 2.0 if I ever get around to that, etc. The Unleashed SVN would include the binaries of those, along with any tweaks needed (different default preferences, etc.) Actual development of the apps would go on at SourceForge, and the binaries could be imported when ready. The misc. scripts in Puppy would only be in the Unleashed tree of course. Just the full-blown applications would be on SF. Things that could actually stand on their own without Puppy, more or less. Especially ones that are using a compiled language, since the Unleashed SVN would not involve source, just as Unleashed doesn't. T2 and the SF repo would take care of that, for now.

If we used GIT, we'd probably want to structure things a little differently. The main advantage I see with GIT is the private branching, which would make it much easier to test stuff without messing with the trunk. That has the drawback of needing somebody to maintain the trunk and handle merging things into it from the various testing branches. That makes me think of the whole Coordinator thing, but this would have stronger technical requirements as he'd need to be able to read through the segments of code and figure out what the two people were doing and how best to combine them... Probably not a big issue with the small number of people that will be involved though.

An aside to Lobster: AFAIK the choices are CVS, SVN and GIT. SVN is basically the next version of CVS. GIT is more distributed than SVN, which has advantages and disadvantages. Might be overkill for Puppy, as I don't think we'll have enough people involved for that to help more than it will hurt. If we did have a lot, I'd vote for it. At the moment I'm leaning more towards SVN since it's simpler to understand and will probably take less work to use. That would also keep things consistent with the SourceForge repo. If you dig up the thread where cb88 announced the SF account for Puppy, I posted more on how I thought this could work.


Back to cb88: And you bring up a good point about combining T2 and Unleashed. I think that integrating T2 into Unleashed is definitely a long term goal we should work towards, assuming with stick with using T2. It would be nice to download something and be able to type make and have it build the default Puppy, fully populate Unleashed, and assemble a new ISO. Having it correct any scripts that need correcting for various kernel configurations would probably be going too far, so things would still need some manual intervention for some customizations, but in general it would be great.
[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]

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

#23 Post by ttuuxxx »

I'm all for T2, I played around with it and it worked nicely, Git on the other hand I only used it once on puppy 4.0, to compile VLC 9.1 After many downloads and tons of time compiling, VLC didn't work.
I have a good feeling its puppy's default compiler. But VLC isn't everything. ttuuxxx

PS It would be nice if we went back to Slackware, I was thinking Ubuntu, but the thing about that, Ubuntu breaks their packages into smaller package sections and they use more dependencies. Thats why slackware, Plus Gslapt is easy to get going on puppy. maybe based on the 12.1?
Just an idea, tossing around
http://audio.online-convert.com/ <-- excellent site
http://samples.mplayerhq.hu/A-codecs/ <-- Codec Test Files
http://html5games.com/ <-- excellent HTML5 games :)

User avatar
cb88
Posts: 1165
Joined: Mon 29 Jan 2007, 03:12
Location: USA
Contact:

#24 Post by cb88 »

so what you really saying is that you are lazy and don't really care if you make the best product you can?

you obviously completely ignored my post... slackware is old hat and there really aren't many packages at all for it puppylinux itself seems more active in that area if it weren't for the duplication of efforts (due to non automated package generation due to lack of T2 integration etc...) we would probably far outclass slackware for official packages

with T2 building packages automatically i may be as simple as updating a source link md5 hash and rebuilding the package

@pisszasgood unleashed is pretty much just a set of scripts to create teh packages list and squash the root filesystem and put it on the ISO among a few other things correct? The base core and kernel are usually in unleashed i know but that would be handed off to T2 to generate or we could build default/release versions of unleashed that are just like what we have now

@also at pizzasgood :-) i never intended for binaries to go on sourceforge that would be pretty silly since the whole idea is to get a system going where we can build LOTS of different versions of binaries different optimisations that people can host as thier own truely custom versions of puppy on thier own server space if they want

I guess all the official packages will remain on sourceforge and will be build by someone trustworthy from the default T2 profile then uploaded

also i believe that barry has hinted pretty strongly that an automated build from T2 was kindof in his goals anyway

@ttuuxxx using Slackware as a base may be easy but you have to think of the trade offs... Slackware packages are not easy to get working I know because I use Slackware as my every day system and if there is a lib missing from a package it is a pain in the butt to find and get the right version etc........ so by choosing Slackware you get an easy job of building puppy in you opinion anyway and offload the work onto the extra packagers and the users. I am really skeptical of your *project management* skill since you didn't think that through and you really do lack diplomacy sorry to give you heat here but I just don't agree with you.
Taking Puppy Linux to the limit of perfection. meanwhile try "puppy pfix=duct_tape" kernel parem eater.
X86: Sager NP6110 3630QM 16GB ram, Tyan Thunder 2 2x 300Mhz
Sun: SS2 , LX , SS5 , SS10 , SS20 ,Ultra 1, Ultra 10 , T2000
Mac: Platinum Plus, SE/30

User avatar
MU
Posts: 13649
Joined: Wed 24 Aug 2005, 16:52
Location: Karlsruhe, Germany
Contact:

#25 Post by MU »

search files:
http://packages.slackware.it/

Enter the name of a lib, check "file name", and you should find it.
Slackware has huge repositories, what is not listed in the official repository, can be found on other sites.
browse:
http://ftp.ntua.gr/pub/linux/slackware/ ... slackware/
ftp://ftp.slackware.org.uk/gsb/gsb-curr ... /packages/
visit:
http://linuxpackages.net/

And if something is not available, just compile it from source.
In Puppy I often had trouble to compile stuff, this has become much easier, since I replaced almost everything with slackware packages.

Mark
[url=http://murga-linux.com/puppy/viewtopic.php?p=173456#173456]my recommended links[/url]

User avatar
cb88
Posts: 1165
Joined: Mon 29 Jan 2007, 03:12
Location: USA
Contact:

#26 Post by cb88 »

@Mu i am well aware of those and slackware is still lacking :?

I have often browsed linuxpackages and many other repos for libs...COMPLETE waste of time

think of it this way Debian = {all packages have deps automatically resolved.... 0 wasted time for the user slight overhead on the developer to make sure the deps are available big deal}

slackware = {I have the libs here is a package i made hope it works! then 3 or four dependancies are missing and you are up a creek compiling stuff.... the user has to be able to compile just to use it]

IMO using slackware is just spinning your wheels if you need more than the defaults (which i don't... right now)
Taking Puppy Linux to the limit of perfection. meanwhile try "puppy pfix=duct_tape" kernel parem eater.
X86: Sager NP6110 3630QM 16GB ram, Tyan Thunder 2 2x 300Mhz
Sun: SS2 , LX , SS5 , SS10 , SS20 ,Ultra 1, Ultra 10 , T2000
Mac: Platinum Plus, SE/30

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

#27 Post by Pizzasgood »

Unleashed itself is a small jumble of scripts that takes all the packages making up Puppy, combines them into one directory, and builds a squashfs file from that. But the Unleashed Tree is a clean organized way to edit the packages that will be merged to create Puppy. You don't just run T2 and then it builds a Puppy, yet. A lot of manual work goes on between T2 and running Unleashed's createpuppy script. This is the stage I'm talking about putting inside of an SVN or GIT repository.

Eventually, I do hope we have T2 set up such that it will make that middle stage unnecessary. At that point all we'd need is the SVN/GIT repo holding the Puppy-specific T2 stuff. That, I believe, would be fine to do with SourceForge.

But I'm under the impression that that's still a good ways in the future, if it's even a practical thing to do. I may be wrong. I still haven't had a chance to play with T2. Too much real-life stuff at the moment. It's on my near-term todo list, but could still take a month before I get to it. Hopefully more like two weeks.
i never intended for binaries to go on sourceforge that would be pretty silly
Exactly. We'd develop the Puppy specific applications there, and we'd put their binaries into the Unleashed tree which would be hosted elsewhere. In the future we'd grab and compile them through T2, making a separate SVN/GIT repo unnecessary.


Assuming we stick with T2. I won't have a real opinion either way until I've used it. But being able to recompile everything, say for a 64-bit architecture or for PowerPC, would be pretty handy I think.
[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]

User avatar
cb88
Posts: 1165
Joined: Mon 29 Jan 2007, 03:12
Location: USA
Contact:

#28 Post by cb88 »

yeah I haven't gotten much past compiling (which is pretty easy with T2)

I wanted to try barrys scripts to build packages but just don't have the resources (time at home or a laptop... not that even haveing a laptop i would still lack time LOL)
Taking Puppy Linux to the limit of perfection. meanwhile try "puppy pfix=duct_tape" kernel parem eater.
X86: Sager NP6110 3630QM 16GB ram, Tyan Thunder 2 2x 300Mhz
Sun: SS2 , LX , SS5 , SS10 , SS20 ,Ultra 1, Ultra 10 , T2000
Mac: Platinum Plus, SE/30

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

#29 Post by Lobster »

Lob:
It is very difficult to vote without candidates. Do we have any?

Pizzasgood:
Not that I'm aware, but how long had it been? Three days or so?

Over two and a half years since Barry announced his retirement.
During that time a developer with the time and inclination has not yet emerged organically . . .

Just as the numerous attempts for an SVN system have been tried (even implemented - I have tried about 5) but never adopted.

It is why I suggested tick
http://www.murga-linux.com/puppy/viewto ... 033#221033

Any news on that from Prithish?
Puppy Raspup 8.2Final 8)
Puppy Links Page http://www.smokey01.com/bruceb/puppy.html :D

NathanO
Posts: 210
Joined: Fri 23 Feb 2007, 00:03
Location: San Antonio, TX

4.2

#30 Post by NathanO »

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

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].

Post Reply