Shouldn't we be *selling* woof-CE?

[user1234]

Don't worry... selling here means promoting.

---

I found a useful page for tips on attracting collaborators to an open-source project:
https://opensource.stackexchange.com/qu ... rogrammers

---

There are several answers, the ones I liked the most are as follows:
https://opensource.stackexchange.com/a/78/28986
https://opensource.stackexchange.com/a/107/28986

There was someone also writing about what to include in the docs:
https://opensource.stackexchange.com/a/1966/28986

---

With woof-CE becoming almost stale, I believe we should start to try to attract more developers for the project; and the above are, IMO, some great tips for it .

---

Discuss and share your ideas using replies

[rockedge]

One of the bigger hurdles to getting new developers to contribute to woof-CE is the complexity of the interwoven components that make it up,

Write good, well-structured code

Messy code might deter programmers away from contributing. They can probably understand most of it pretty quickly, but actually adding to and improving it is a lot harder.

Though @dimkr cleaned up and streamlined a lot of the code up to this point.

[dimkr]

Though @dimkr cleaned up and streamlined a lot of the code up to this point.

I haven't, people still use woof-CE to build very 'traditional' Puppy releases with X.Org, GTK+ 2 and other kinds of abandonware, plus things like PPM, which they refuse to maintain but also refuse to delete or replace.

I do have a super cleaned up fork at https://github.com/vanilla-dpup/woof-CE, and that's what I want to use to build Vanilla Dpup 11.0.x. I left the woof-CE organization and forked to have this freedom to clean up things, without having to worry about breaking things for others.

[rockedge]

I haven't

Interesting. I thought you did some. My mistake...the English language must have escaped me and I lost track of time how long you were involved with the project.

people still use woof-CE to build very 'traditional' Puppy releases with X.Org, GTK+ 2 and other kinds of abandonware, plus things like PPM, which they refuse to maintain but also refuse to delete or replace.

People still use Windows.

I suppose we could go into it to start via converting all those useful utilities and tools that depend on gtk2 and convert those to gtk3 syntax or straight to gtk4. And if there are some programs/scripts that matches up to said utilities, use those instead.

KLV is already using gtk4, so it has gtk2, gtk3 and gtk4 on board. Just for fun and that we like some of those gtk2 Puppy GUI's without converting any syntax to have super light very reliable tools.

[dimkr]

From what I see, it's not that easy. Somebody needs to port gtkdialog to GTK+ 4 and some widgets are gone. Some are moved to libadwaita but it's a moving target.

I introduced the concept of building packages from source within woof-CE, then ported dpup to GTK+ 3 everywhere minus ROX-Filer (which needs to be ported too but it's unmaintained for years, btw). This was necessary because GTK+3 supports Wayland (but without fractional scaling, and GTK +3 won't live forever), so somebody else will need to port everything to GTK+ 4 one day.

[wiak]

Which all makes it sound like the writing is on the wall. Reality check?

From the above, if no developers really tackling what sounds like the far too onerous job of fixing woof-CE, nearest to an alive and being maintained Puppy build system would seem to be that of dimkr Vanilla Dpup fork? Time to drop the idea that official Puppy can only be built from official woof-CE then, or what use is it building from something that isn't going to work well any more?

That would be the face reality situation - ignoring reality, whatever that reality really is, won't help those who want traditional Pups in the future. But traditional Pups rely on PPM and if no one maintaining that then PPM is effectively dead.

The topic post suggests attracting new devs to official woof-CE; maybe desperate times then, and if no-one applies? And with such problems is it worth it for any new dev; would they even stay? I suspect dimkr could answer all that best since he was the last to try, and what he wanted to do was resisted and hence his fork I suppose. So you would need to attract devs that remain happy with old code and who believe such old ideas as PPM are worthwhile and likely to be reliable and useful today.

Porting gtkdialog to GTK+4 is a different problem, but not a small one, so with its own issues to be addressed. Maybe more worthwhile though.

Aside from Puppy and Vanilla Dpup, the nearest to traditional Puppy look and feel is definitely FatDog (though under-the-hood it is a powerful wee beast compared to Pups), but FatDog doesn't use PPM (any more) and isn't called "Puppy" and isn't built with official Puppy woof-CE (though derived a bit from it I gather). If FatDog became the new Puppy, that would seem to me like a positive thing, but then the marketing on this forum is definitely all wrong... The FatDog team already have a name of their own choice for their distro.

Note also, at least as far as I understand them, neither FatDog build system nor that of Vanilla are designed (at present I suppose) to build more than one underlying distro type, meaning: FatDog uses own packages (but based on Slackware format for packages??), and Vanilla builds debian-based distro. Puppy woof-CE was intended to build several varieties of upstream types. However, I don't see that as important; the original pre-woof-CE pups were one upstream-repo type only per release or indeed (originally) used their own packages built from source (e.g. T2), so much like FatDog in that way.

[dimkr]

I suspect dimkr could answer all that best since he was the last to try, and what he wanted to do was resisted and hence his fork I suppose.

https://github.com/puppylinux-woof-CE/w ... sions/4209

What pushed me over the edge is
1. Low standards - people pushing random untested changes with "update x" as the commit message and eventually break stuff or just add code that doesn't work, or even push binary files (big no-no with git) - most Puppy development these days is copy-paste driven (copy Puppy x, make changes, publish as y) and this is sad
2. People who keep using woof-CE to build their stuff but with local modifications and even manual build steps - these things never reach woof-CE and other Puppy builds, creating fragmentation and confusion (you don't know what to expect as a user - if you move from Puppy x to Puppy y, you don't know if y has bug A and the fix for bug B, or bug B and the fix for A, ...)
3. People who insist on building Puppy with aufs, X.Org, ROX-Filer, GTK+ 2, PPM and other unmaintained things (I'm fine with that), but refuse any change to woof-CE that allows woof-CE to build a Puppy without these things even if this change is 100% optional and hidden behind a feature flag that defaults to the "legacy" behavior (so it shouldn't affect their work in any way)

My fork at https://github.com/vanilla-dpup/woof-CE has two purposes:
1. Isolate Vanilla Dpup 9.3.x and 10.0.x from bad changes in woof-CE - both are stable and built from a branch, I cherry pick only tested changes that don't break anything
2. Allow me to make big changes in woof-CE so 11.0.x can be built from a very minimal woof-CE without rotten, unmaintained bits and with big architecture changes (like ability to safely apt upgrade, much faster boot, different implementation of "copying to RAM", ...)

If anyone wants to cherry-pick changes from my fork, rebase upstream woof-CE on top of my fork or even sell my fork's build output - I have no problem with that as long as the license is obeyed.

[Grey]

Reality check?

doesn't use PPM (any more) and isn't called "Puppy" and isn't built with official Puppy woof-CE (though derived a bit from it I gather).

Note also, at least as far as I understand them,

I also hope that in the future there will be some kind of orderly standard. So far, I've put myself in the observer category.
Romance is also important to dilute everyday reality and being. The main thing here is to guess the dosage.

2. People who keep using woof-CE to build their stuff but with local modifications and even manual build steps

I am engaged in the first part of this phrase, I have such a sin, yes. About the second part with modifications... In general, for a long time I was sure that this should not be done according to some unspoken rules (for the purity of the Puppy breed). Then it turned out that you (it's not you specifically here, but anyone in general) can do ANYTHING, turning anarchy into Universal Chaos.

[dimkr]

some unspoken rules (for the purity of the Puppy breed).

woof-CE is GPL-licensed and the meaning of the GPL license is well understood

But it's not about "purity of breed", it's about the health of Puppy as a software project. I publish Puppy A with feature w and fix for bug x, you publish B with feature y and fix for bug z, ... eventually users realize that every Puppy has its a unique set of features and problems, then move on to a well-maintained distro where version n+1 has the features version n had, all the fixes applied n had, plus more features and fixes on top. In addition, the private 'mods' various Puppy developers make during their use of woof-CE make the Puppy they build unreproducible by others - if you disappear after you published version n of your Puppy, nobody can pick up the project and publish version n+1 (so Puppy's "bus factor" is forever stuck at 1).

[bigpup]

As I see it.

There must be something about Woof-CE that works or no one would use it.

The problem with Woof-CE is no one is in overall control of it.

Any control that is there, is very loosely done.

That was one of the jobs 01micko had, but last I saw any info from him was, I am not working on Puppy anymore.
I am no longer involved in any control of Puppy Linux.

So who is?

dimkr was one of the only people, that did anything on Woof-CE, that seemed to really try to improve it, and keep it updated.

It is just like Puppy in general.

No one does anything with Puppy unless they just want to do it.
They stop when they want to.

Just like this post by me!

[rockedge]

So who is?

peebee has administration rights to merge commits as do a couple of others to the woof-CE GitHub repo

[bigpup]

Here is something in Woof-CE many people could get involved in.

Updating the software that is in the Woof-CE/noarch repository.
https://github.com/puppylinux-woof-CE/w ... ges-noarch

If any of these have newer versions they need to be in this repository.

Look at the last time most have been placed in it.

Sure some are as far as they will ever go for updating. They just work as they now are.

But I am sure others need to be added.

Some have been updated, but not gotten updated here.

[peebee]

So who is?

peebee has administration rights to merge commits as do a couple of others to the woof-CE GitHub repo

and is very worried that this is the current unhealthy state of affairs!

[user1234]

With this thread, I meant to suggest adding contribution guidelines and sort of better docs to woof-CE.

But due to my lack of foreseeing, I did not see that the major step would not be the above, but rather getting the rotten bits out of woof-CE, of which there exists a ton. Maybe woof-CE has finally almost reached its end-of-life .

[mikewalsh]

Here is something in Woof-CE many people could get involved in.

Updating the software that is in the Woof-CE/noarch repository.
https://github.com/puppylinux-woof-CE/w ... ges-noarch

If any of these have newer versions they need to be in this repository.

Look at the last time most have been placed in it.

Sure some are as far as they will ever go for updating. They just work as they now are.

But I am sure others need to be added.

Some have been updated, but not gotten updated here.

I can see one straightaway. UExtract. Currently at v4.12, the Woof-CE version is still at 3.32.....the current version is easier to use, has a better interface, and covers a lot more formats. It's always one of the first things I update.

Mike.

[ozsouth]

I think we're wanting an ideal situation, where some folk, out of the goodness of their hearts, maintain woof-ce, as has happened in the past. Seems to me it's a massive job, with insufficient skilled or willing folk to do it. The fact folk have left underlines the enormity.
I think that leaves us with some tough choices:

1. Incentivise folk to do it (i.e. pay)
2. Use forks made where there are willing maintainers
3. Accept that it will never be perfect & simply mitigate issues
4. Minimise it, requiring less updating, & providing bare-bones for folk to add to (big job)
5. Write long diatribes which go nowhere, hoping someone sympathetic will bail us out
6. Give up & use old puppies till they hopelessly break
7. Use something else

I get the feeling that we will eventually run out of willing devs if nothing changes.

As for me, things I make often have many intermediate versions, due to simple errors I make in what is mostly customisations.
You wouldn't want to let me loose on woof-ce - I'm frankly not up to it.
Writing this from my Chromebook, as I mostly only run Puppy when I get a project idea, or am trying to help someone.

[dimkr]

I think that leaves us with some tough choices:

Puppy started as a do-ocracy but became a wait-ocracy, a project where everybody is waiting for some legendary developer to return, waiting for a new version that will never come because nobody is working on it, or waiting for somebody to fix a problem with an ancient, unmaintained thing they use.

I suggest that everyone who cares about a component of woof-CE starts maintaining it by writing patches and submitting pull requests. If they're not merged, just fork the project and became the new "lead".

Until every piece of woof-CE has a skilled and motivated maintainer (probably won't happen), those who build a Puppy should warn users when they use something that's old and unmaintained, especially if it makes big changes to their system and may lead to data loss (like PPM). At the same time, those in charge of the woof-CE project should start reducing the scope of the woof-CE project to something narrower they can and want to maintain properly. For example, if nobody maintains ROX-Filer for years, maybe it's time to drop it and the huge amounts of code written specifically to deal with its limitations, then switch to something else. And if people prefer apt or vpm to PPM, maybe PPM itself can be eliminated and woof-CE can be simplified to bootstrap the build using debootstrap or xbps-install.

[amethyst]

Use something else

[rockedge]

And if people prefer apt or vpm to PPM, maybe PPM itself can be eliminated and woof-CE can be simplified to bootstrap the build using debootstrap or xbps-install.

There is talk of plans to dig in and radically change the way Puppy Linux is built and what from. How this is going to look exactly is not know at this time.

I think the experience from DebianDog and FirstRib/Kennel Linux assembly and how those are built are a good foundation.

[amethyst]

Is it really necessary to always have everything up to date as in up until April 2024? I mean some of us are still using Bionic, Xenial, etc. I like the way Fossa9.6CE works. Fossa was updated more than a year ago and it seems a new release is now planned. That's perfectly fine for me personally if something is updated once a year (whatever changes are decided on then). Keeping things up to date on a day to day basis will result in a lot of work. Personally I think as far as Puppy goes, we should concentrate on a specific path which will make things easier, ie. like bringing out Debian based releases only. I'm just a user though....

[ozsouth]

@amethyst wrote: -

like bringing out Debian based releases only

Dimkr is doing that now with Vanilla Dpup & maintaining the fork that produces it. If folk want to go that way, that is a real option. As far as I know, he is the lone dev there.
Others have made forks they maintain to some degree. BarryK has some real options, & also peebee regularly produces slackware based pups which are a real option - less popular for sure, but stable & customisable. Imagine if a dozen or so folk occasionally made s15pup or Lxpup packages, where there are no Slackware equivalents. As for PPM, I use it to uninstall .pets only.

[amethyst]

The package manager is not an issue for me either, hardly ever use it.

[BologneChe]

Is it really necessary to always have everything up to date as in up until April 2024? I mean some of us are still using Bionic, Xenial, etc. I like the way Fossa9.6CE works. Fossa was updated more than a year ago and it seems a new release is now planned. That's perfectly fine for me personally if something is updated once a year (whatever changes are decided on then). Keeping things up to date on a day to day basis will result in a lot of work. Personally I think as far as Puppy goes, we should concentrate on a specific path which will make things easier, ie. like bringing out Debian based releases only. I'm just a user though....

If I follow the conversation correctly, it's about "we" and not "I"