Tinkering with "pages" as bug tracker


Recommended Posts

Donate and support the project!

I split the topic at this point since I just wanted to showcase a bit what the software is capable of doing with a bit of playing. As stated and mentioned we already have multiple places for issues  (which is an issue by itself but needs to be discussed in a/the other topic) and could at max replace the bug tracker  forums here to get slightly more organized.

But even that won't happen since the necessary license costs money and it is I think not worth atm if we dont consider do more with it like integrate the whole homepage as well as the docs into it which will most likely not happen either.

Link to post
Share on other sites

My main objection would not be the price at all but rather further dependence on proprietary tools and ecosystems.

 

My objections are on philosophical as well as practical grounds.

 

In the first case, as a F/LOSS project, I already think we rely on too many proprietary tools, and I think we should not only make effort to slow that trend but also to try to actually reverse it.  Especially if the name of our project echoes with Debian.  I understand the OS (software) is based on Debian.  However to many people (including myself) the name Debian stands for much more than a collection of software.  It stands for a certain set of philosophies: stability, etc...  But also chief among them a strong commitment towards Free Software (while still allowing you to do what you need to do; i.e., not outright preventing you from doing things like some of the more stringent Free Software distros, e.g. those on the (relatively short) GNU list of fully Free and FSF endorsed distributions).

 

In the second case, relying on these sort of things because they are "easy" or readily available, IMO is not the most important metric.  I think instead we should think about the long term costs, the potential (eventual) pain of extracting the project out of such ecosystems.  I think we need to think more in terms of long term support, flexibility, etc, and what is best for the project in regard to these concerns, instead of what might be "easier" "right now" or even what particular tools that any of us might personally prefer.  These are very practical concerns, with real (and long lasting) consequences, and completely separate therefore from the above philosophical ones.

 

A bit off the topic in OP, but in support of one of my main points (and because I fully expect someone to bring it up), I will state that I am very well aware of the hardware blob requirements in many cases on many of these boards.  I do not think it follows logically that because things may be difficult (or even impossible, in many cases) that we should not strive toward some ideal of software freedom (and again, especially if we call ourselves Armbian).  It does not have to be an all or nothing proposition, and I don't think we should "throw the baby out with the bath water" so to speak (i.e., completely give up on ideals, just because they may seem impractical at the moment).

Link to post
Share on other sites