Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Wed 26 Nov 2014, 19:07
All times are UTC - 4
 Forum index » Taking the Puppy out for a walk » Announcements
DEVELOPERS to CONTRIBUTORS (STAKEHOLDERS) :)
Moderators: Flash, Ian, JohnMurga
Post_new_topic   Reply_to_topic View_previous_topic :: View_next_topic
Page 3 of 9 Posts_count   Goto page: Previous 1, 2, 3, 4, 5, 6, 7, 8, 9 Next
Author Message
ttuuxxx


Joined: 05 May 2007
Posts: 10843
Location: Ontario Canada,Sydney Australia

PostPosted: Fri 19 Sep 2008, 03:49    Post_subject: Re: 4.2  

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 Smile
Back to top
View user's profile Send_private_message Visit_website 
big_bass

Joined: 13 Aug 2007
Posts: 1747

PostPosted: Fri 19 Sep 2008, 10:58    Post_subject:  

you can finish the CE you started

that would be a good first step


big_bass


*edited to remove a url link

Edited_time_total
Back to top
View user's profile Send_private_message 
HairyWill


Joined: 26 May 2006
Posts: 2949
Location: Southampton, UK

PostPosted: Fri 19 Sep 2008, 11:23    Post_subject:  

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: community website, screenshots, puplets, wiki, rss
Back to top
View user's profile Send_private_message 
amigo

Joined: 02 Apr 2007
Posts: 2278

PostPosted: Fri 19 Sep 2008, 14:45    Post_subject: Notes on Compatibility
Sub_title: A few considerations regarding inter-distro compatibility
 

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.
Back to top
View user's profile Send_private_message 
ttuuxxx


Joined: 05 May 2007
Posts: 10843
Location: Ontario Canada,Sydney Australia

PostPosted: Fri 19 Sep 2008, 17:04    Post_subject:  

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 Smile
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 Smile
Back to top
View user's profile Send_private_message Visit_website 
ttuuxxx


Joined: 05 May 2007
Posts: 10843
Location: Ontario Canada,Sydney Australia

PostPosted: Fri 19 Sep 2008, 17:34    Post_subject:  

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 Smile
Back to top
View user's profile Send_private_message Visit_website 
notned


Joined: 04 Apr 2007
Posts: 51
Location: California

PostPosted: Fri 19 Sep 2008, 19:13    Post_subject:  

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?
Back to top
View user's profile Send_private_message 
ttuuxxx


Joined: 05 May 2007
Posts: 10843
Location: Ontario Canada,Sydney Australia

PostPosted: Fri 19 Sep 2008, 19:51    Post_subject:  

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 Smile
Back to top
View user's profile Send_private_message Visit_website 
ttuuxxx


Joined: 05 May 2007
Posts: 10843
Location: Ontario Canada,Sydney Australia

PostPosted: Fri 19 Sep 2008, 20:10    Post_subject:  

big_bass wrote:
http://www.phrases.org.uk/bulletin_board/8/messages/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 Smile
Back to top
View user's profile Send_private_message Visit_website 
raffy

Joined: 25 May 2005
Posts: 4796
Location: Manila

PostPosted: Sat 20 Sep 2008, 04:24    Post_subject: kernel development  

ttuuxxx
Quote:
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? Get the sfs (English only).
Back to top
View user's profile Send_private_message 
ttuuxxx


Joined: 05 May 2007
Posts: 10843
Location: Ontario Canada,Sydney Australia

PostPosted: Sat 20 Sep 2008, 04:57    Post_subject: Re: kernel development  

raffy wrote:
ttuuxxx
Quote:
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 Smile
Back to top
View user's profile Send_private_message Visit_website 
Pizzasgood


Joined: 04 May 2005
Posts: 6270
Location: Knoxville, TN, USA

PostPosted: Sat 20 Sep 2008, 17:51    Post_subject:  

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

Quote:
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.


Quote:
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.

_________________
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

Back to top
View user's profile Send_private_message Visit_website 
Mic67

Joined: 30 Oct 2006
Posts: 478

PostPosted: Sat 20 Sep 2008, 19:39    Post_subject:  

I recall this quote from a sailing forum:

"The earth was not created by a committee"

Nor was puppy.

mic67
Back to top
View user's profile Send_private_message 
alienjeff


Joined: 08 Jul 2006
Posts: 2291
Location: Winsted, CT - USA

PostPosted: Sat 20 Sep 2008, 23:46    Post_subject:  

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!

_________________
hangout: ##b0rked on irc.freenode.net
diversion: http://alienjeff.net - visit The Fringe
quote: "The foundation of authority is based upon the consent of the people." - Thomas Hooker

Back to top
View user's profile Send_private_message 
Trobin

Joined: 18 Aug 2005
Posts: 907
Location: BC Canada

PostPosted: Sun 21 Sep 2008, 00:43    Post_subject:  

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?

_________________
http://speakpup.blogspot.com
Back to top
View user's profile Send_private_message 
Display_posts:   Sort by:   
Page 3 of 9 Posts_count   Goto page: Previous 1, 2, 3, 4, 5, 6, 7, 8, 9 Next
Post_new_topic   Reply_to_topic View_previous_topic :: View_next_topic
 Forum index » Taking the Puppy out for a walk » Announcements
Jump to:  

Rules_post_cannot
Rules_reply_cannot
Rules_edit_cannot
Rules_delete_cannot
Rules_vote_cannot
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1529s ][ Queries: 13 (0.0054s) ][ GZIP on ]