clean-up: drop superseded or obsoleted RfCs
See added comments for the reason
This commit is contained in:
parent
b556d2b770
commit
67695c97b8
12 changed files with 181 additions and 46 deletions
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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,
|
||||
|
|
|
|||
|
|
@ -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]
|
||||
|
|
|
|||
|
|
@ -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 <ct@pipapo.org>
|
||||
|====================================
|
||||
|
|
@ -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' ~<ct@pipapo.org>~
|
||||
|
||||
|
||||
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:
|
||||
|
||||
''''
|
||||
|
|
|
|||
|
|
@ -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 <ct@pipapo.org>
|
||||
|====================================
|
||||
|
|
@ -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]
|
||||
|
|
|
|||
|
|
@ -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 <ct@pipapo.org>
|
||||
|====================================
|
||||
|
|
@ -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' ~<prg@ichthyostega.de>~
|
||||
|
||||
|
||||
.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:
|
||||
|
||||
|
|
|
|||
|
|
@ -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]
|
||||
|
|
|
|||
Loading…
Reference in a new issue