From 67695c97b837e3f803a17ecbcc2a27a4470d8d60 Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Tue, 16 Sep 2025 23:50:55 +0200 Subject: [PATCH] clean-up: drop superseded or obsoleted RfCs See added comments for the reason --- doc/devel/rfc/AllPluginInterfacesAreC.txt | 10 +-- doc/devel/rfc/ApplicationStructure.txt | 2 +- doc/devel/rfc/CCodingStyleGuide.txt | 29 ++++++- doc/devel/rfc/GitCommitMessageFormat.txt | 51 +++++++++++- doc/devel/rfc/RefactorLiblumieraOut.txt | 19 ++++- doc/devel/rfc/SemanticTags.txt | 38 ++++++--- doc/devel/rfc/TodoLists.txt | 78 +++++++++++++------ .../CCodingStyleGuide.txt | 0 .../GitCommitMessageFormat.txt | 0 .../RefactorLiblumieraOut.txt | 0 .../SemanticTags.txt | 0 .../{rfc_parked => rfc_dropped}/TodoLists.txt | 0 12 files changed, 181 insertions(+), 46 deletions(-) rename doc/devel/{rfc_final => rfc_dropped}/CCodingStyleGuide.txt (100%) rename doc/devel/{rfc_final => rfc_dropped}/GitCommitMessageFormat.txt (100%) rename doc/devel/{rfc_pending => rfc_dropped}/RefactorLiblumieraOut.txt (100%) rename doc/devel/{rfc_pending => rfc_dropped}/SemanticTags.txt (100%) rename doc/devel/{rfc_parked => rfc_dropped}/TodoLists.txt (100%) diff --git a/doc/devel/rfc/AllPluginInterfacesAreC.txt b/doc/devel/rfc/AllPluginInterfacesAreC.txt index 33683523b..74c155b1c 100644 --- a/doc/devel/rfc/AllPluginInterfacesAreC.txt +++ b/doc/devel/rfc/AllPluginInterfacesAreC.txt @@ -173,8 +173,8 @@ documented in the repository (tiddlywiki/source) ct:: '2007-07-11 13:10:07' - -Development took another direction over course of the years; +.State -> Dropped +Development took another direction over the course of the years; Lumiera is not based on a _generic plug-in Architecture_ and the topic of interfaces for _dedicated plugins_ still needs to be worked out @@ -190,12 +190,12 @@ Architecture. Experience with high-profile projects based on such a concept seem to show both tremendous possibilities, especially regarding user involvement, but at the same time also indicate serious problems with long-term sustainability. -The practical development -- mostly driven ahead by _Ichthyo_ -- thus never really -embraced that idea; rather structuring by internal interfaces and contracts was +The practical development -- after some point mostly driven ahead by _Ichthyo_ -- never +really embraced that idea; rather structuring by internal interfaces and contracts was preferred. The basic system for loading of Plug-ins, as indicated by this proposal, is still used though to load some dedicated plug-ins, most notably the GUI. -To draw an conclusion: this proposal is now considered as *rejected*. +To draw a conclusion: this proposal is now considered as *rejected*. Instead, Ticket https://issues.lumiera.org/ticket/1212[#1212 »Extension Concept«] was added to the list of relevant https://issues.lumiera.org/report/17[»Focus Topics«] for further development. diff --git a/doc/devel/rfc/ApplicationStructure.txt b/doc/devel/rfc/ApplicationStructure.txt index f8a01bfdf..71f4a6d34 100644 --- a/doc/devel/rfc/ApplicationStructure.txt +++ b/doc/devel/rfc/ApplicationStructure.txt @@ -62,7 +62,7 @@ Then our application structure looks somewhat like (please refine): - ... Furthermore the interface and plugin system is flexible enough to provide things -independently of their origin (if it is build in or a plugin/dynamic library). +independently of their origin (if it is either built-in or a plugin/dynamic library). So deployment (where to link these things) is secondary. `"lumiera"` will then be the executable the user starts up, diff --git a/doc/devel/rfc/CCodingStyleGuide.txt b/doc/devel/rfc/CCodingStyleGuide.txt index 917ad31f4..55da055a7 100644 --- a/doc/devel/rfc/CCodingStyleGuide.txt +++ b/doc/devel/rfc/CCodingStyleGuide.txt @@ -3,7 +3,7 @@ Design Process : C Coding Style Guide [options="autowidth"] |==================================== -|*State* | _Final_ +|*State* | _Dropped_ |*Date* | _2007-07-03_ |*Proposed by* | ct |==================================== @@ -212,5 +212,32 @@ point'', i.e. every point in the system, that can be extended by plugins. Ichthyostega:: '2007-07-10T17:23:33Z' + +.State -> Dropped +During the last years, I have read this RfC several times, and I am still +not sure what this proposal wanted to achieve, and what was the intention of +proposing it this way. + +A ``C coding style'', a ``naming system'' meant to be very verbose, +but not intended to be about design, yet ``technically not needed when +using the plugin system'' -- which all together touches at +questions of design for sure. + +In the early stages of the project, there was a debate revolving around the +idea of bootstrapping the application from a tiny core, with pretty much +any functionality assembled from plugins, and internal functions being +callable directly from Lua code. Combined with a low-ceremony, distributed, +collaborative working style, such a setup was linked to the promise of +fluid evolution of ideas in order to try out unconventional solutions +and see what works best. + +Personally, this premise made me feel queasy, because I had a clear vision +in my head, which required to build some rather advanced and challenging +structures. Mastering complexity means to segregate and settle parts of a +problem in order to avoid excess interdependencies. I'd rather attempt +to deflect and redirect flexibility and differentiation towards the +periphery and establish stable yet generic structures in the core. + +Ichthyostega:: '2025-09-16' + '''' Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/GitCommitMessageFormat.txt b/doc/devel/rfc/GitCommitMessageFormat.txt index 9da865ffd..ce27b6692 100644 --- a/doc/devel/rfc/GitCommitMessageFormat.txt +++ b/doc/devel/rfc/GitCommitMessageFormat.txt @@ -5,7 +5,7 @@ Git Commit Message Format [options="autowidth"] |==================================== -|*State* | _Final_ +|*State* | _Dropped_ |*Date* | _Fr 31 Aug 2012 03:54:14 CEST_ |*Proposed by* | Christian Thaeter |==================================== @@ -20,8 +20,8 @@ Description ----------- //description: add a detailed description: -Git commit messages are almost free form text, the only exception is that git -threats the first line in a commit message specially to form the header one +Git commit messages are almost free form text, the only exception is that Git +treats the first line in a commit message specially to form the header one sees in various outputs. Since we aim to automate some processing we refine the format for commit @@ -174,6 +174,51 @@ We decided on the sept. 2012 devel meeting to finlize this RFC. Christian Thaeter:: 'Do 13 Sep 2012 03:57:23 CEST' ~~ +NOTE: This RfC is now superseded by using the _Git-flow branching scheme._ + +.State -> Dropped + +With the recent move to link:{ldoc}/technical/code/GitBranching.html[Git-flow] +we acknowledge now -- by employing a branch model -- that the project history +is _built_ and _conducted_ consciously, _by us._ In the current stage, +it is not the goal of this project to churn out a stream of commits, +using an automated production line to push some metrics high. + +Since any automation comes at a cost and incurs burdens and limitations, +it should be employed to solve actual problems, but should not +be introduced prematurely: + +- we spend most of our time with finding suitable solutions, not with + coding them up. When a part is completed, some time can be spent + to document it and to consolidate the history. Thus, leaving + formalised WIP and STASH marks is besides the point. + +- releases and even bugfixes require forethought, analysis, verification + and reflection. The extra time required to set a git tag manually, or + even to perform a merge, is negligible in comparison, and does not + justify the weight of automation. + +- documentation is written in the context of solving actual problems; + it is pointless to spot ``documentation commits'' by some markers, + because their relevance is already obvious from a meaningful context. + +- Git bisect is an essential tool when working with a code base which you + do not understand. With a well-crafted yet ambitious system the situation + is quite distinct: in such a system, the change which caused the breakage + is obvious and easy to spot -- while the actual challenge is to + understand _why_ difficulties arose -- not to mention the amount + of work required to develop a path of escape from a real dilemma. + +This RfC highlights some general considerations however, which remain +valid anyway: to provide a short commit summary in the first line, +and then, after an empty line, to provide a description for +anything that is non-obvious, possibly with cross-references to +tickets, URLs pointing to external sources and anything that might +provide meaningful context for someone looking at this change +years later. And, commit messages should be line-wrapped. + +Ichthyostega:: '2025-09-16' + //endof_comments: '''' diff --git a/doc/devel/rfc/RefactorLiblumieraOut.txt b/doc/devel/rfc/RefactorLiblumieraOut.txt index 31ad2c586..3b4eea822 100644 --- a/doc/devel/rfc/RefactorLiblumieraOut.txt +++ b/doc/devel/rfc/RefactorLiblumieraOut.txt @@ -5,7 +5,7 @@ Refactor Liblumiera Out [options="autowidth"] |==================================== -|*State* | _Idea_ +|*State* | _Dropped_ |*Date* | _Fr 22 Apr 2011 10:46:50 CEST_ |*Proposed by* | Christian Thaeter |==================================== @@ -226,8 +226,25 @@ Comments -------- //comments: append below +.State -> Dropped +Ongoing development over the following years (after 2011) helped to clarify the situation +regarding the support library in Lumiera. The improved language standards, most notably C++14, +obsoleted most of the ad-hoc solutions in our library, since many aspects of system +integration are now handled by language and STL facilities in a satisfactory way. +On the other hand, by using the heightened capabilities of the language, some solution +patterns very specific to Lumiera could be established, gradually turning the support +library into some kind of an application framework. + +It is quite common in the field of software development to put great hopes into code +reuse -- yet it is this very tendency towards a framework which prevents that ideal +from playing out as anticipated, in practice. What seems to work best is to look +at some well-made piece of software, understand how it works, and then to copy +and extract parts in order to transform it into _your own solution._ + +Ichthyostega:: '2025-09-16' //endof_comments: + '''' Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc/SemanticTags.txt b/doc/devel/rfc/SemanticTags.txt index bb40d5621..875f1d66b 100644 --- a/doc/devel/rfc/SemanticTags.txt +++ b/doc/devel/rfc/SemanticTags.txt @@ -5,7 +5,7 @@ Semantic tags [options="autowidth"] |==================================== -|*State* | _Idea_ +|*State* | _Dropped_ |*Date* | _Do 30 Aug 2012 21:06:54 CEST_ |*Proposed by* | Christian Thaeter |==================================== @@ -13,7 +13,7 @@ Semantic tags ******************************************************************************** .Abstract We have a lot documentation which needs to be cross referenced. Adding well the -known 'tags' concept and extend it slightly with some semantics will aid future +known `tags' concept and extend it slightly with some semantics will aid future automatic processing. ******************************************************************************** @@ -21,15 +21,15 @@ Description ----------- //description: add a detailed description: -Every document (including sourcecode) could extended with some metadata, aka tags -which are then used to build automatic crossreferences. +Every document (including sourcecode) could be extended with some metadata, +aka. ``tags'', which are then used to build automatic crossreferences. -Commonly tags are just 'words' which are picked up and crossreferenceds. I propose +Commonly tags are _just words_ which are picked up and cross referenced. I propose to extend this scheme slightly. Overall this scheme must be very natual and easy to use. A user should not need to -know about the underlying machinery and a tag as in a single lowercase 'word' should -be sufficient in almost all cases. Moreover Tags should be optional. +know about the underlying machinery and a tag as in a single lowercase `"word"` +should be sufficient in almost all cases. Moreover Tags should be optional. .Ontology @@ -127,10 +127,13 @@ It is very urgent and important that we make our content much easier accessible. -//Conclusion -//---------- +Conclusion +---------- //conclusion: When approved (this proposal becomes a Final) // write some conclusions about its process: +⛔ This proposal was never expanded upon. +While containing some interesting ideas, in its current form +it is not deemed helpful for the project. @@ -141,7 +144,7 @@ Comments //edit comment You may recall this proposal created some heated debate at the last developer meeting. -After thinking it over some time, I can see now more clearly what irritated me. +After thinking it over some time, I can _see now more clearly what irritated me._ . for me, the proposal seems somewhat to lack focus. Right now we have some shortcomings at rather basic operations when *authoring content* at the website. This proposal tends to be more @@ -192,6 +195,21 @@ reader will somehow ``get it''. Ichthyostega:: 'Mi 10 Okt 2012 05:36:35 CEST' ~~ +.State -> Dropped +It is now _many years later,_ and no further discussion happened, nor did +anyone care to address the urgent practical needs related to stable cross-links +when authoring the website content. + +- -> link:{rfc}/WebsiteSupportMarkup.html[Cross-links and Website support markup] +- -> link:{rfc}/WebsiteNavigation.html[Website Navigation Menu] + +This proposal contains some intriguing ideas -- yet these ideas require more +dedicated work to transform them into a closed specification, which can be +judged for practicability. I would rather propose to start from the much +more concrete issue with the cross-links and develop a matching algorithm +which is sufficient to generate a ``linkfarm'' entry + +Ichthyostega:: '2025-09-17' //endof_comments: diff --git a/doc/devel/rfc/TodoLists.txt b/doc/devel/rfc/TodoLists.txt index 9bc303a12..e83eab89f 100644 --- a/doc/devel/rfc/TodoLists.txt +++ b/doc/devel/rfc/TodoLists.txt @@ -1,6 +1,9 @@ +How to organize work? +===================== + [options="autowidth"] |==================================== -|*State* | _Parked_ +|*State* | _Dropped_ |*Date* | _2008-03-05_ |*Proposed by* | ct |==================================== @@ -12,30 +15,12 @@ We need some way to organize tasks to be done (tiddlywiki, testsuite, ...?) Description ~~~~~~~~~~~ +Cehteh:: +``I want something which doesn’t need much human care and I want one big `milestones' thing +and a small `mini-task' thing'' - -Tasks -^^^^^ - - -Pros -^^^^ - - - -Cons -^^^^ - - - -Alternatives -^^^^^^^^^^^^ - - - -Rationale -^^^^^^^^^ - +Ichthyo:: +could be refined as as `Roadmap' and `Near time task list' @@ -43,8 +28,51 @@ Rationale Comments -------- -We decided to use a Tiddlywiki for now until this is further worked out +Discussed in the link:{ldoc}/devel/meeting_summary/2008-03-06.html#_idea_todo_lists[March.2008 developer meeting]. + +We decided to use a TiddlyWiki for now until this is further worked out ct:: '2008-03-08T03:38:50Z' +.... +​ +​ +​ +​ +​ +.... + +.looking back at another era... +What shall I say, just Whew! 😖 + +For context, I can recall that _Cehteh_ had a very pronounced aversion against bugtrackers +(and especially Bugzilla), because they are just plain confusing, filled with obsolete +information and last but not least, they create spurious work without being helpful +for the developer. Wouldn't it be much better to put everything into the code or +close to the code (as markup in comments)? Git would propagate this information +to the community of other contributors, which would decide about what is viable, +just simply by merging or not merging -- and some clever tool could watch the +resulting commit stream and extract the minimum necessary accounting to +supply the developers with that amount of information + they need to be actually productive.... + +.State -> Dropped +Lumiera is quite another kind of project today. There _is_ a https://issues.lumiera.org/[Bugtracker], +and I need all kinds of meta-tickets, tags, overview lists, the content in documentation pages plus +my own personal notes in several mindmaps just to cope with the sheer amount of information and not +to forget about matters already decided and settled. + +_All this meta-work takes a considerable amount of effort,_ for sure. + +Yet the question remains, how can I ``keep track'' without keeping track? +How can I judge and decide, without actually performing the judgement to arrive at a decision? +Would it make any difference to this dilemma, if ``someone else'' were to perform that work?? + +Can this kind of immaterial mental work be conditioned and commodified into an industrial process, +so that the individual person might side-step the effort, yet sill remain a sovereign? + +[purple]#I do not know the answer to this question.# + +Ichthyostega:: '2025-09-18' + + +'''' Back to link:/x/DesignProcess.html[Lumiera Design Process overview] diff --git a/doc/devel/rfc_final/CCodingStyleGuide.txt b/doc/devel/rfc_dropped/CCodingStyleGuide.txt similarity index 100% rename from doc/devel/rfc_final/CCodingStyleGuide.txt rename to doc/devel/rfc_dropped/CCodingStyleGuide.txt diff --git a/doc/devel/rfc_final/GitCommitMessageFormat.txt b/doc/devel/rfc_dropped/GitCommitMessageFormat.txt similarity index 100% rename from doc/devel/rfc_final/GitCommitMessageFormat.txt rename to doc/devel/rfc_dropped/GitCommitMessageFormat.txt diff --git a/doc/devel/rfc_pending/RefactorLiblumieraOut.txt b/doc/devel/rfc_dropped/RefactorLiblumieraOut.txt similarity index 100% rename from doc/devel/rfc_pending/RefactorLiblumieraOut.txt rename to doc/devel/rfc_dropped/RefactorLiblumieraOut.txt diff --git a/doc/devel/rfc_pending/SemanticTags.txt b/doc/devel/rfc_dropped/SemanticTags.txt similarity index 100% rename from doc/devel/rfc_pending/SemanticTags.txt rename to doc/devel/rfc_dropped/SemanticTags.txt diff --git a/doc/devel/rfc_parked/TodoLists.txt b/doc/devel/rfc_dropped/TodoLists.txt similarity index 100% rename from doc/devel/rfc_parked/TodoLists.txt rename to doc/devel/rfc_dropped/TodoLists.txt