Can Open Github Pull Requests be resolved?

[peebee]

@mistfire
@user1234
@dimkr
@gyrog

Can any of the 34 open Github Woof-CE Pull Requests be RESOLVED? Some go back quite a long time and we seem to have been "surviving" without them - so are they still needed?

34 open pull requests 2024-Feb-04

Update geany to version 2.0
#4219 opened last week by lakshayrohila
11

Update fontmanager: Some improvements
#4214 opened last month by rizalmart

Loopback - generate an enhaned grub2 loopback.cfg file
#4199 opened on Nov 29, 2023 by gyrog

Update filemnt: Some improvements and additional support
#4193 opened on Nov 26, 2023 by rizalmart

Update init: use binded mountpoint instead of direct path for save folder
#4192 opened on Nov 26, 2023 by rizalmart
1

rc.shutdown: Improve shutdown process
#4191 opened on Nov 26, 2023 by rizalmart

hacks-postinstall2.sh: added workaround for browsers, CEF-based, and electron-based application
#4155 opened on Oct 2, 2023 by rizalmart

Update autologin: make it configurable
#4106 opened on Jul 5, 2023 by rizalmart

Update DISTRO_PKGS_SPECS-debian-sid: Added libacl1
#4079 opened on Jun 12, 2023 by rizalmart

Update DISTRO_PKGS_SPECS-debian-sid: added zlib1g and libgcc-s1
#4078 opened on Jun 12, 2023 by rizalmart
3

The Documentation Update (again)
#4056 opened on May 20, 2023 by lakshayrohila
11

profile: Added debian library path
#3996 opened on Apr 5, 2023 by rizalmart

Update python_FIXUPHACK
#3983 opened on Mar 22, 2023 by rizalmart

perl_FIXUPHACK: Move perl docs and dev files
#3982 opened on Mar 21, 2023 by rizalmart

Create fix-duplicates script
#3981 opened on Mar 21, 2023 by rizalmart

Increase pfind dialog box size to show correctly
#3953 opened on Feb 26, 2023 by Overdrive5
12

Add ntfs3 support to initrd, simpler version of #3929
#3948 opened on Feb 25, 2023 by dimkr

Mount a tmpfs on /run, like other distros do
#3940 opened on Feb 24, 2023 by dimkr
4

mount-pup: Use NTFS3 support first
#3930 opened on Feb 20, 2023 by rizalmart

this will fix the puppyinstaller to work with bdrv
#3881 opened on Jan 30, 2023 by Linux-is-king
13

sending another pull request
#3879 opened on Jan 30, 2023 by Linux-is-king
2

Make 83a4bf5 work
#3824 opened on Jan 11, 2023 by dimkr

0setup: change from /root/.packages to /var/packages
#3779 opened on Dec 26, 2022 by rizalmart

Enhance runqemu_woof.sh
#3778 opened on Dec 26, 2022 by lakshayrohila
• Draft
12

Reapply the wmonitors.sh configuration when a monitor is connected
#3764 opened on Dec 21, 2022 by dimkr

installpkg.sh: Adaptive category fixing
#3742 opened on Dec 14, 2022 by rizalmart

.xinitrc: Properly set XDG Desktop variables
#3735 opened on Dec 13, 2022 by rizalmart
2

Avoid excessive use of FTP
#3577 opened on Nov 5, 2022 by ChrysoliteAzalea
18

Offer ext4 without a journal, not ext3, as an alternative to ext4
#3445 opened on Oct 1, 2022 by dimkr

snapmergepuppy: Avoid opened files 2.0
#3361 opened on Sep 1, 2022 by rizalmart
12

mscw2: Added pipewire support
#2993 opened on Mar 28, 2022 by rizalmart

mscw: Added pipewire support
#2992 opened on Mar 28, 2022 by rizalmart
1

10alsa: Added pipewire support
#2991 opened on Mar 28, 2022 by rizalmart
1

load_ext_file: some tweaks
#2681 opened on Dec 14, 2021 by rizalmart

[dimkr]

Why is it so important to close them? Some fix real problems, and you'll need them to fix bigger problems and improve the project's health.

For example, if you close https://github.com/puppylinux-woof-CE/woof-CE/pull/3824, you can also revert 83a4bf5, which doesn't work.

If you merge https://github.com/puppylinux-woof-CE/woof-CE/pull/3948, you can proceed to drop all uses of ntfs-3g in Puppy and migrate to ntfs3.

If you close https://github.com/puppylinux-woof-CE/woof-CE/pull/3940 without merging it, Puppy remains pretty much the only distro with a persistent /run, causing extra disk writes and surprising consequences after reboot.

[peebee]

Why is it so important to close them?

Changed closed to resolved.......... what needs to be done for 3824, 3940 & 3948 to resolve?

[user1234]

@peebee, I'll also want to talk about the PRs I opened:

• Update geany to version 2.0: I am not sure if this is needed, but have left it to you to take any action (if you think it is required please merge; otherwise kindly inform me and I'll close the PR ).

• The Documentation Update (again): This one's quite big and old, but I think this is required for woof-CE. This one follows directly from https://forum.puppylinux.com/viewtopic.php?t=7273, and includes update of almost all the documentation files (except those which I have listed here). I think this one is needed, and I suppose this update has also been included in F96-CE (I'll like @bigpup to inform us more about what happened with these docs, as I have been away from Puppy for quite a lot time).

I'll again like to remind that I do not have any write permissions to the woof-CE, so can't merge the PRs. In case you require me to close any of them, I'll be happy to do so .

[gyrog]

I have noticed the large number of outstanding PR's, some of them from 2022.
I hope to look at them and maybe merge some, if I understand their significance, and they seem to "improve" Puppy.

Unfortunately there are many parts of woof, and even Puppy, that I have never had any need to even look at.
So don't hang by your thumbs.

But surely @user1234 's documentation work has got to be an improvement, right?

[wiak]

Don't you feel it would be a good idea to re-establish a woof-CE development and maintenance team in some organised fashion that encourages individual changes but works as a team to accept or reject new ideas pushed?

Whilst dimkr , who was close to single-handedly operating that ship, has indicated that he has flown to his own version/part-fork, surely he should be encouraged back, but in a more organised mjlti-person team role? Puppy needs someone with sufficiently deep system-level understanding, and someone capable of understanding modern Linux newer innovations and challenges and able and ready to re-write large chunks of woof-CE when inevitably necessary. At the same time getting away from the single-person control model of more recent woof-CE seems essential since if the sole-person captain is lost so is the ship.

And even more essential for the longterm development of Puppy and its build system seems to me to be to tie its build system development more closely to its forum of users in such a way that more pertinent dev discussions held on the forum are not ignored. If Puppy is a community distribution then its development process and structure really needs to reflect that. The forum is really 'where the community of users are at' and woof-CE is just the underlying technical tool that builds what users on the forum want.

Puppy will certainly need an alternative(s) to sufficiently system- oriented dimkr if he has stepped down, but previous organisation of woof-CE has effectively been to divorce Puppy build system participation to the git-familiar few and effectively disregard the more important, at the end of the day, core users who actually spend their discussion time on the forum.

In other words, as a start, I suggest appointing various regular core forum members, who have a major interest in Puppy, to become the forum puppy dev team on volunteer/proposed/limited-period with forum as centre of dev organisation and tech leaders do not end as captains but simply alternative key personnel for their particular tech-oriented role

[dimkr]

As somebody who often has to step in and "manage" technical decisions, architect solutions with a clear roadmap or oversee development processes at work, I see it as a question of vision. If your vision is to change as little as possible, close all these PRs instead of merging them. But this vision must be grounded in technical understanding, otherwise you're leading Puppy to its death - for example, if you don't want ntfs3 support, you're stuck with ntfs-3g forever and need to maintain the static executable in initrd-progs (for example, update it from time to time, especially if data loss bugs get fixed), or have a backup plan (in the form of a PR that replaces it with ntfs3 or something else) if development of ntfs-3g stops. In other cases of long-time dependencies of Puppy, like X.Org or aufs, the risk to Puppy is known (bad project health, public declaration of inability or lack of desire to maintain the project) and super high. If your vision goes beyond the number of open PRs, you need to find the skills and/or people to accomplish this vision: do some "training" and "hiring" (i.e. find somebody to maintain aufs). And somebody needs to take a "product manager" role and develop understanding of what users value in Puppy, what needs to be improved (+ priority) and what can be removed entirely to make Puppy's codebase smaller and easier to maintain in the long term.

[peebee]

Please keep this thread focussed on practical steps for improvement rather than philosophical debate .... thanks.

[peebee]

• Update geany to version 2.0: I am not sure if this is needed, but have left it to you to take any action (if you think it is required please merge; otherwise kindly inform me and I'll close the PR ).

• The Documentation Update (again): This one's quite big and old, but I think this is required for woof-CE.

Both the above now merged............

The documentation update (if anybody can find the time to review) can be found (mainly) at:
https://github.com/puppylinux-woof-CE/w ... /share/doc

[dimkr]

Please keep this thread focussed on practical steps for improvement rather than philosophical debate .... thanks.

Define 'improvement', because updating Geany to 2.0 doesn't align with your tradition of shipping Puppy releases with mostly GTK+ 2 applications and resisting change in general. As the one with merge rights (which makes you a de-facto maintainer), you should make it clear what the vision/roadmap is, otherwise potential contributors don't know what changes are accepted and what changes can sit there in the list of open PRs, ignored for years.

[Jasper]

............bit confused here

Is there not a private section where Dev's and their discussions take place?

[Clarity]

Hi @Jasper

I think the 'private conversations, you refer, is via the PRs. Beyond that,,they interact here in the forum ;and probably via the PUPPY chat services.

[rockedge]

Is there not a private section where Dev's and their discussions take place?

Lots of the discussions happen in the GitHub puppylinux-woof-CE / woof-CE Pull Requests and Issues areas or as Clarity mentions, right here on the forum.

Puppy Linux development is transparent and input on direction, function and the future comes from the community. So the forum in it's semi-chaotic state, is a good place to have conversation and exchange of ideas.

You Jasper, would be a talented developer and have a chance to keep Puppy Linux on the front lines of usefulness to the computer world. Imagine being able to integrate all these packages you have made for Fossapup64, into woof-CE a production, woof-CE built Focal Fossa based Puppy Linux like what could be the next stage F96-CE_5.

@sonny produced a nice ISO that has F96-CE_4 with some key components upgraded to the latest greatest. The goal is to get all of this great innovation and compiling talent focused to be included in the scripting that makes up woof-CE.

Now it seems daunting but keep in mind, step by step and some practice to become familiar with basic Git operation will start to make the magic.

[user1234]

The documentation update (if anybody can find the time to review) can be found (mainly) at:
https://github.com/puppylinux-woof-CE/w ... /share/doc

Except that, I have also added SNS (Simple Network Setup) and connman-gtk docs. The SNS docs reside here, while the connman-gtk ones reside here.

[user1234]

what changes can sit there in the list of open PRs, ignored for years.

I agree, PRs should not be ignored - either "accept", or "reject", or in the third case guide the author of the PR if any modification is required. I think it is high time to add contribution guidelines in woof-CE. Those who currently have write access to the repo (I only know about @peebee) should come forward and take that responsibility.

---

I also feel that the current woof-CE does not has a proper documentation - not about using woof-CE, but about developing it. There is the Contributor-101, but it also goes through how to contribute, not what to contribute. What I think is required is something like @dimkr's this commit, which explains the working of woof-CE for new users (I mean, learning git is a very simple task - took me only a week; but going through thousands of lines of codes of woof-CE just to understand what it does is something different, to which most the people will respond with "TLDR Too Long, Didn't Read" - including me).

For example, we provide petbuilds, but do not document all the things happening with it. I do not say that we explain in the documentation each and every LOC we write, but at least we should guide the programmer to what related file they need to read. For example, I would require to read woof-code/support/petbuilds.sh to understand what mostly happens with petbuilds, but if I even don't know what specific file I have to go through, I'll just get confused when something unexpected happens and maybe even leave what I am developing.
By unexpected I mean, things like copying of some files and not the others - if by chance I named my file which I want to include as foo-bar.txt instead of something like foo_bar.txt, my file will not be included, and I will be left confused why it happens since the documentation in README.md (specifically this section) does not mention this sort of behaviour of woof. Here is a direct quote from README.md:

To build a package from source during 3builddistro and include it in the build:

1. If needed, add extra sources files that cannot be downloaded, like Puppy-specific patches.
2. If needed, add extra files and directories that will be included in the package, like configuration files.

It says "Puppy-specific patches", but not the aforementioned.

I do not say that this level of documentation is required, or if any other project has it. Personally, I have zero experience with any project before woof-CE; am a self-taught programmer - that too I do it casually. So I know I may be wrong about this point - maybe that is how all the projects in real life are, none have this level of docs. But, if someone would like to ask my opinion, this should be necessary, at least for big projects. This will surely slow down a bit of the pace of development, but it might be helpful to gain new contributors (again, this is my personal view which is based on no professional experience).

Again, a counter to this would be "But, how can you say that there surely will be new contributors for the project?" or something like "How can you say that the new documentation will not be a 'too-long-to-read' type of document?" - I do not have a counter to those facts .

Maybe, the reason for 'nothing making sense' about woof-CE for me for several months was my lack of professional experience, and not the documentation

---

EDIT:

Please keep this thread focussed on practical steps for improvement rather than philosophical debate .... thanks.

Oops...sorry! Read that after I wrote this message.

Took a long time to type, so not going to delete it .

Again sorry..

[dimkr]

Please keep this thread focussed on practical steps for improvement rather than philosophical debate .... thanks.

Oops...sorry! Read that after I wrote this message.

Took a long time to type, so not going to delete it .

Again sorry..

I think that the limited git skills of most people with woof-CE commit access, lack of documentation and unclear contribution guidelines are practical concerns. Puppy is a software project, it doesn't build and maintain itself.

[Jasper]

@rockedge

Thank you for the encouragement, but I am using decade old hardware. So FP95 has luckily for me has worked OOTB. The basic set of applications are all functional and I might miss not being able to use Bluetooth, but it's not a game changer.

My biggest problem is @ozsouth continued support for this . His work for the OS and kernel updates (@peebee too ) has been my personal downfall.

I have little if any feedback on anything I contribute here. I only post applications that I have compiled and tested myself to share with others.

As I said to @user1234 , if anything works and is useful, please incorporate it.

My compiled applications were really built only because I was unable to access the PPM successfully. In my case it was through necessity and not through choice.

The PPM, Synaptic and Apt contain 1000's of applications. Which should satisfy the majority of users.

I will look at GitHub and setting up an account...... but I am not sure what the cost (yes, will read the TOS) will be. I do use GitHub just to clone ATM.

[gyrog]

2 observations:

1. The existence of these Pull Request's suggests that we still have some folk who are willing to propose code changes to "improve" Puppy.

2. The currrent system for "resolving" PR's is not working.

We need to get a process working, or the limited folk that do produce PR's may stop.

Suggestion1:
Create a "woof-CE Pull Requests" subforum.
Each topic in this subforum will correspond to an open PR in woof-CE on github.
All discussion in a particular topic should be the "pros and cons" of the particular PR.
(Moderators would need to police this.)

This allows the Puppy community to be aware of what is changing in woof-CE,
and to accept some ownership as to what gets accepted and what is rejected, by participating in these topics.
This would provide the gatekeepers (folk who can merge PR's), some perspective.

Note: It would be reasonable to expect submitters of PR's to create the coresponding forum topic,
and outline their "pros" for the change.

Suggestion2:
We could go even further than that.
Create a "woof-CE patches" subforum.
Each topic would be about a proposed "patch" to a woof-CE file.
If the discussion suggests aceptence, then someone else might turn the "patch" into a PR.
(In this case, the resultant PR could be merged without further discussion.)

A "patch" is the output of a comand like:

Code: Select all

diff -u /path/to/copy/of/woof-ce/file /path/to/modified/file > patch.diff

Note: The whole idea is to provide mechanisms to encourage folk to be "code contributers".
(Even if they don't want to learn github.)

[user1234]

2 observations:

1. The existence of these Pull Request's suggests that we still have some folk who are willing to propose code changes to "improve" Puppy.

Not much, the open PRs are from years ago. That does not show that new folks are joining (though we got the first PR from a new person this week, except that only old contributors are there).

1. The currrent system for "resolving" PR's is not working.

@dimkr recently left the organization, stepping down from his maintainer role. That is one reason. Although, as aforementioned, lack of contribution guidelines is one cause.

Suggestion1:
Create a "woof-CE Pull Requests" subforum.
Each topic in this subforum will correspond to an open PR in woof-CE on github.
All discussion in a particular topic should be the "pros and cons" of the particular PR.
(Moderators would need to police this.)

This allows the Puppy community to be aware of what is changing in woof-CE,
and to accept some ownership as to what gets accepted and what is rejected, by participating in these topics.
This would provide the gatekeepers (folk who can merge PR's), some perspective.

Note: It would be reasonable to expect submitters of PR's to create the coresponding forum topic,
and outline their "pros" for the change.

Can work , since not many are wanting to learn GIT/GITHUB.

Suggestion2:
We could go even further than that.
Create a "woof-CE patches" subforum.
Each topic would be about a proposed "patch" to a woof-CE file.
If the discussion suggests aceptence, then someone else might turn the "patch" into a PR.
(In this case, the resultant PR could be merged without further discussion.)

A "patch" is the output of a comand like:

Code: Select all

diff -u /path/to/copy/of/woof-ce/file /path/to/modified/file > patch.diff

Note: The whole idea is to provide mechanisms to encourage folk to be "code contributers".
(Even if they don't want to learn github.)

Please see viewtopic.php?p=111419#p111419.

Although, since patches will only be for those who are reluctant to learning Github, it can be easy for them to do so (although it will be difficult for them in the long run); although the lives of reviewers would be much more difficult .

One more thing I noted: they will still require to learn diff command, and IMHO, diff and patch are as difficult as git

---

I have created viewtopic.php?p=111407#p111407, comparing git vs. manual handling of stuff. Tomorrow, I will do the same for GitHub as well, since GitHub is nothing but (almost) Facebook for sharing code. Who knows, someone might get inspired to learn ?

[dimkr]

Before you convince people to do a 10 minute git tutorial and learn how to use git for once and for all, you'll need to convince people to produce patches of the changes they make to woof-CE or at least make all their work publicly available and reproducible by others. For example, Bionicpup, Fossapup and many other Puppy releases were not built from woof-CE as-is but with changes lost to time: this woof-CE code is unavailable because the author of the changes never published them (a GPL violation, by the way). Even if you want to volunteer to upstream such changes to compensate for the author's reluctance to do this, you don't have this code.

Look at the git history of woof-CE, it's a pretty inactive project - the core problem is not lack of git skills (git add, git commit, git push is super easy to learn and doesn't require high IQ) but lack of activity: people don't fix bugs, don't add features, or just do these things in a private, local fork.

[peebee]

For example, Bionicpup, Fossapup and many other Puppy releases were not built from woof-CE as-is but with changes lost to time:

For example, Bionicpup64, Fossapup64

BionicPup32 & FocalPup32 are built on Github Woof-CE as is

[dimkr]

Ubuntu 18.04 is dead and Ubuntu will probably drop its limited i686 repo one day (by converting Steam and Wine into snaps), but getting Bookworm Pup64 fully upstreamed is important if you want it to have a successor and don't want newer Puppy releases to feel like a step backwards.

[peebee]

IF we are sticking with Ubuntu then we should be getting JammyPup64 uploaded in preparation for NoblePup64........ there is already a JammyPup64 build: https://github.com/puppylinux-woof-CE/w ... ammy64.yml

I personally think it would be better to get BookwormPup64 uploaded as the next official Pup (BookwormPup32 is already uploaded to Woof-CE and built on Github Woof-CE PeaBee fork)..... @radky any thoughts?

[Clarity]

As progress is made in Ububtu versions in WoofCE, I think progress should be made on package management for WoofCE Pups.

@BarryK has made some progress, albeit Void progress, in creating a mechanism for 'central' management of all things installed on his OS.

Can something akin to his PKGget management approach be beginning in Ubuntu versions in Puppyland?

I think this could be useful as the Linux World comprises SNAPs and FLATs, now, along with past package tools; and PETs packagers in this forum.

Just a thought.

[user1234]

IF we are sticking with Ubuntu then we should be getting JammyPup64 uploaded in preparation for NoblePup64........ there is already a JammyPup64 build: https://github.com/puppylinux-woof-CE/w ... ammy64.yml

I personally think it would be better to get BookwormPup64 uploaded as the next official Pup (BookwormPup32 is already uploaded to Woof-CE and built on Github Woof-CE PeaBee fork)..... @radky any thoughts?

Probably yes, Bookworm might be a better solution since Jammy might not be ready yet (IDK, but I am currently working on adding Conky to Jammy64; and maybe samba as well in the future). Also, I do not see notifications in Jammy using notify-send, even after installing it. I saw something related to notifications running, but running notify-send, I didn't see any notification.

---

As progress is made in Ububtu versions in WoofCE, I think progress should be made on package management for WoofCE Pups.

@BarryK has made some progress, albeit Void progress, in creating a mechanism for 'central' management of all things installed on his OS.

Can something akin to his PKGget management approach be beginning in Ubuntu versions in Puppyland?

I think this could be useful as the Linux World comprises SNAPs and FLATs, now, along with past package tools; and PETs packagers in this forum.

Just a thought.

Could you please elaborate? I think apt is sufficient, snaps might just work (although not sure); but flatpaks, I think @dimkr made some progress about those since they can't be run as root, though I am not sure.

[dimkr]

Probably yes, Bookworm might be a better solution since Jammy might not be ready yet (IDK, but I am currently working on adding Conky to Jammy64; and maybe samba as well in the future).

It will be "ready" if enough people find a way to collaborate on it (using development tools like GitHub, rather than discussion forums), then actually collaborate on it.

Also, I do not see notifications in Jammy using notify-send, even after installing it. I saw something related to notifications running, but running notify-send, I didn't see any notification.

Easy, remove notification-daemon-stub from PETBUILDS and add notification-daemon in DISTRO_PKGS_SPECS

I think @dimkr made some progress about those since they can't be run as root, though I am not sure.

Flatpak in Bookworm Pup64 should work well, but not perfectly.

Snap is out of question, it depends on systemd: Puppy doesn't have systemd and there's no way to fit systemd in Puppy's current architecture (rc.sysinit will need to go away, etc').

[mistfire]

The Pull Requests was reduced from 34, now down to 27 Pull Requests

[mistfire]

Probably yes, Bookworm might be a better solution since Jammy might not be ready yet (IDK, but I am currently working on adding Conky to Jammy64; and maybe samba as well in the future).

It will be "ready" if enough people find a way to collaborate on it (using development tools like GitHub, rather than discussion forums), then actually collaborate on it.

Also, I do not see notifications in Jammy using notify-send, even after installing it. I saw something related to notifications running, but running notify-send, I didn't see any notification.

Easy, remove notification-daemon-stub from PETBUILDS and add notification-daemon in DISTRO_PKGS_SPECS

I think @dimkr made some progress about those since they can't be run as root, though I am not sure.

Flatpak in Bookworm Pup64 should work well, but not perfectly.

Snap is out of question, it depends on systemd: Puppy doesn't have systemd and there's no way to fit systemd in Puppy's current architecture (rc.sysinit will need to go away, etc').

Speaking of systemd, I successfully run puppy on systemd, but still compatible with rc.sysinit. the only problem was its the shutdown phase. Its discriminately unmounts the mounted filesystems. I once put a PR on woof-ce about systemd, then widespread panic occured when they saw the PR