info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Tcl/Tk community on Github
307 views
Skip to first unread message
Оlе Ѕtrеісhеr
Jun 9, 2021, 2:49:18 AM6/9/21
to
Hi all,
(just subscribed here, please apologize if this was discussed recently)
I am the Debian maintainer for a number of Tcl/Tk packages. I do not
actively used Tcl/Tk myself (apart from using applications written in
Tcl), and my main motivation is to keen a few important astronomy
programs usable in Debian: SAOImageDS9, fv, skycat etc. So, my
experience with the language is rather low.
The maintainance of the Debian packages always requires an upstream, and
since Tcl lost popularity over the years, many packages remain orphaned
or are difficult to find. For those which are needed to keep the
astronomy packages running, I had no other chance than to adopt them
myself: tktable, tkhtml3, and recently tclxml.
This is however an unfortunate solution, since I can't do a really
useful maintainance with them, due to the lack of knowledge, but also
time. This is probably the case for many other Tcl/Tk packages, which
therefore have the chance to silently disappear -- maybe for good, but
maybe they are a real loss. For example, tkhtml3 has, despite of its
status, still many users as reported by our "popcon" service.
To keep these packages in a better shape, it may be useful to have them
maintained in a central place; which is nowadays Github. There is
already a tcltk organization on Github, however this looks more like an
"official" organization, right?
So, wouldn't it be useful to either create a Tcl/Tk community
organization in Github which is a central place for Tcl packages? Or is
the tcltk organization on Github already used for that? Whom could I ask
to get my packages there (and some maintainance rights on them...)?
Would others also move the packages they maintain there?
The advantages are:
* packages are easier to find if there is a one-stop place
* packages are easier to take over if they are orphaned; they are not
just lost
* the danger of forked development decreases a lot
Any thoughts?
Cheers
Ole
--
Github: https://github.com/olebole
Debian: ole...@debian.org
(just subscribed here, please apologize if this was discussed recently)
I am the Debian maintainer for a number of Tcl/Tk packages. I do not
actively used Tcl/Tk myself (apart from using applications written in
Tcl), and my main motivation is to keen a few important astronomy
programs usable in Debian: SAOImageDS9, fv, skycat etc. So, my
experience with the language is rather low.
The maintainance of the Debian packages always requires an upstream, and
since Tcl lost popularity over the years, many packages remain orphaned
or are difficult to find. For those which are needed to keep the
astronomy packages running, I had no other chance than to adopt them
myself: tktable, tkhtml3, and recently tclxml.
This is however an unfortunate solution, since I can't do a really
useful maintainance with them, due to the lack of knowledge, but also
time. This is probably the case for many other Tcl/Tk packages, which
therefore have the chance to silently disappear -- maybe for good, but
maybe they are a real loss. For example, tkhtml3 has, despite of its
status, still many users as reported by our "popcon" service.
To keep these packages in a better shape, it may be useful to have them
maintained in a central place; which is nowadays Github. There is
already a tcltk organization on Github, however this looks more like an
"official" organization, right?
So, wouldn't it be useful to either create a Tcl/Tk community
organization in Github which is a central place for Tcl packages? Or is
the tcltk organization on Github already used for that? Whom could I ask
to get my packages there (and some maintainance rights on them...)?
Would others also move the packages they maintain there?
The advantages are:
* packages are easier to find if there is a one-stop place
* packages are easier to take over if they are orphaned; they are not
just lost
* the danger of forked development decreases a lot
Any thoughts?
Cheers
Ole
--
Github: https://github.com/olebole
Debian: ole...@debian.org
Harald Oehlmann
Jun 9, 2021, 3:52:21 AM6/9/21
to
Am 09.06.2021 um 08:49 schrieb Оlе Ѕtrеісhеr:
> Hi all,
>
> (just subscribed here, please apologize if this was discussed recently)
>
> I am the Debian maintainer for a number of Tcl/Tk packages. I do not
> actively used Tcl/Tk myself (apart from using applications written in
> Tcl), and my main motivation is to keen a few important astronomy
> programs usable in Debian: SAOImageDS9, fv, skycat etc. So, my
> experience with the language is rather low.
first of all, welcome to the TCL community !
I appreciate your activity and support for Debian.
It would be great if you could subscribe to the tcl-core list. There are
also the maintainers for FreeBSD etc.
The TCL release manager Don Porter has just asked for tests on platform
for the upcoming TCL 8.7a5.
TCL 8.7 introduces an internal virtual zip file system, so script files
may go into zip-files and may be attached to .dll or .so files.
This implies a new level of abstractions where tests are welcome.
The original posting is below.
-------- Weitergeleitete Nachricht --------
Betreff: [TCLCORE] Release candidates for Tcl/Tk 8.7a5
Datum: Mon, 7 Jun 2021 18:33:42 +0000
Von: Porter, Don (Fed) via Tcl-Core <tcl-...@lists.sourceforge.net>
Antwort an: Porter, Don (Fed) <donald...@nist.gov>
An: Tcl Core List <tcl-...@lists.sourceforge.net>
...are now available at
https://sourceforge.net/projects/tcl/files/Tcl/8.7a5/
<https://sourceforge.net/projects/tcl/files/Tcl/8.7a5/>
I am most interested in discovering any build failures that make these
source distributions unsuitable for making libraries and binaries that
can be tested in the many ways people use Tcl and Tk. Failures of that
kind will prevent their release. If you think you have some other
reason, speak up.
DGP
---
Take care,
Harald
EL
Jun 9, 2021, 5:22:04 AM6/9/21
to
On 09.06.2021 08:49, Оlе Ѕtrеісhеr wrote:
> So, wouldn't it be useful to either create a Tcl/Tk community
> organization in Github which is a central place for Tcl packages?
Yes, yes, YESSSS please!
> So, wouldn't it be useful to either create a Tcl/Tk community
> organization in Github which is a central place for Tcl packages?
+1 from my side. I'd *really* love to have it that way!
It would make so many thing so much easier, not only for linux
distribution maintainers. Plus: Tcl would at least have a chance to
appear on the radar of developers again.
The current side way with a separate fossil server and the
source/distribution download splattering is a dead end road, IMHO.
--
EL
EL
Jun 9, 2021, 8:22:05 AM6/9/21
to
of the TCT. In the end its they who decide about development directions.
--
EL
Harald Oehlmann
Jun 9, 2021, 8:45:18 AM6/9/21
to
Am 09.06.2021 um 14:13 schrieb EL:
> It's probably worthwhile to write a TIP, to bring this to the attention
> of the TCT. In the end its they who decide about development directions.
EL,
> It's probably worthwhile to write a TIP, to bring this to the attention
> of the TCT. In the end its they who decide about development directions.
with all respect, the issue here is not an issue of willingness of "the"
TCT. Many individuals have tried that and a Batteries Included version
was always a dream. Many initiatives raised and dissappeared. The issue
is the lack of constant manpower. As ActiveState stepped away from the
TCL distribution business, there is no successor.
Anybody is welcome. It is not a question of "GIT" or "Fossil" nor money.
I payed volontary to ActiveState but it did not help. FlightAware has
many bonus points. It is a question of constant manpower. If someone
does it on GIT, it is welcome. But before you do that, please
investigate the current fossil infrastructure. Have you checked
androwish.org fossil? It is a BI of highest quality with many packages
requested by Ole.
Thank you,
Harald
EL
Jun 9, 2021, 11:02:04 AM6/9/21
to
On 09.06.2021 14:45, Harald Oehlmann wrote:
> with all respect, the issue here is not an issue of willingness of "the"
> TCT.
The issue is an issue of not-awareness, I think. Or has anyone already
> with all respect, the issue here is not an issue of willingness of "the"
> TCT.
proposed a TIP for moving all the Tcl, Tk and extension sources to
Github? Has it already been discussed?
> Many individuals have tried that and a Batteries Included version
> was always a dream. Many initiatives raised and dissappeared.
point here is to get the Tcl sources and Tcl package sources to a
mainstream infrastructure that almost every developer uses today, for
the following purposes:
- single point of entrance for everything around the sources, the
development, the issues, the binary releases, etc.
- low to zero learning curve for people who want to use Tcl / extensions
in terms of "how and where do I get stuff"
- low to zero learning curve for people who like to contribute. Fixes,
enhancements, TIPs and so on.
- modern infrastructure for *collaborating* on the sources. Especially
pull requests for code reviews about code changes.
- and especially: a *well known* infrastructure
Will that be enough to "make Tcl great again"? No, certainly not! And
that is far from what can be expected.
But it will at least throw in some points to "make Tcl *visible* again".
And it will certainly add many points to "make Tcl better usable" for a
variety of people who want to use it, contribute to it, distribute it,
write their own extensions etc.
And then let me come back to the "batteries included" distro discussion.
Every language has nowadays some kind of package manager. Pip for
python, cargo for rust, maven for java.... you name a language and
you'll find a package manager that can pull and manage development
dependencies. Tcl had such a thing, called teacup. It was part of
ActiveTcl, but it apparently has disappeared... anyway.
The point is, that such a package manager can be much more easily
implemented, when the sources and binary releases for packages are in
one place, in one standard format and the package manager knows where to
pull them. That's where the scattering and split brain situation, that
we have today, is really debilitating... It's almost impossible for
anyone to implement a package manager when the packages are too
scattered around the net.
> The issue
> is the lack of constant manpower.
always be a lack. But if you create the infrastructure for many men who
can *easily* contribute and spend as little manpower as they can, the
situation is different.
> It is not a question of "GIT" or "Fossil" nor money.
wrote elsewhere, fossil is good and nice, and it has it's niches. But
Git is well known to every developer, as is github. And that means that,
if we used git/github, new and old developers:
- have a single entry point to everything (which is github)
- have a low to zero learning curve in terms of "how and where do I get
stuff"
- have a low to zero learning curve for contributing
- have a modern infrastructure for collaborating on the sources.
- and especially: have a *well known* infrastructure
Using fossil instead does set Tcl always somewhat apart from the
mainstream and makes things harder. And therewith creates a higher entry
threshold for newcomers and some headaches for old users like me. That's
the sad truth.
Remarkably: Its not about "not use fossil because fossil is bad". Fossil
is very good. But it's not as popular as we need a VCS and collaboration
platform to be, imo.
> But before you do that, please
> investigate the current fossil infrastructure. Have you checked
> androwish.org fossil? It is a BI of highest quality with many packages
> requested by Ole.
But the problem is: I am one of the many. I work with git the whole day
and I am busy with other languages. I use Tcl mainly in my spare time.
And sometimes I want to contribute something, i.e. a small fix in some
tcllib code (happened recently). Not more. So all I want to do is:
- fork the project on the platform that I know and work with anyway
- make my fix
- create a PR for the maintainer of the project to review
- discuss that PR and hope it will be merged
That's all. All that should be necessary, and all for what I have time.
It works like that flawlessly, for many other projects.
And I certainly do not want to spend time to learn a completely
different ecosystem around a different VCS tool, creating accounts on
various different servers, etc. just to contribute a few lines of code
to a project.
If contributing a fix means that I have to go down that road, I'd rather
stay out. That in turn means, that my fix is _not_ contributed. And you
can imagine what it means if many such small fixes from many people like
me are _not_ contributed.
--
EL
Harald Oehlmann
Jun 9, 2021, 11:38:40 AM6/9/21
to
Dear EL,
thank you for your valuable contribution.
I basically don't want to answer your opinion. Go, and I will go with
you, no problem, the result counts.
My personal experience with GIT:
- I am forced to use it, as some decided to use it (not my decision)
- I maintain two GIT projects (zint-tcl, tksvg)
- For me, GIT is just a pain.
- Learning it, is so complicated. Anything is hidden - to find the
timeline took me years - I still read one hour tutorial to do a simple
step - but seeing all the nice people icons and statistics is a sort of
amusement...
- Pull requests are a big problem for me as maintainer. I tend to accept
points only by patches by E-Mail. Each time I get a pull request, I need
hours to find out, what it does. Then, I press "rejected" and then, I
manually modify the source by excusing the author and explaining, why it
is done like that and explaining manually in the source, where it came
from (referencing the pull request).
- You know perhaps the GIT windows client - no comment required ;-) -
you press the wrong button - error - command line fix - re-clone
repository - retry - fail again - re-clone. It takes hours of my time...
With admiration,
Harald
thank you for your valuable contribution.
I basically don't want to answer your opinion. Go, and I will go with
you, no problem, the result counts.
My personal experience with GIT:
- I am forced to use it, as some decided to use it (not my decision)
- I maintain two GIT projects (zint-tcl, tksvg)
- For me, GIT is just a pain.
- Learning it, is so complicated. Anything is hidden - to find the
timeline took me years - I still read one hour tutorial to do a simple
step - but seeing all the nice people icons and statistics is a sort of
amusement...
- Pull requests are a big problem for me as maintainer. I tend to accept
points only by patches by E-Mail. Each time I get a pull request, I need
hours to find out, what it does. Then, I press "rejected" and then, I
manually modify the source by excusing the author and explaining, why it
is done like that and explaining manually in the source, where it came
from (referencing the pull request).
- You know perhaps the GIT windows client - no comment required ;-) -
you press the wrong button - error - command line fix - re-clone
repository - retry - fail again - re-clone. It takes hours of my time...
With admiration,
Harald
Оlе Ѕtrеісhеr
Jun 9, 2021, 12:19:52 PM6/9/21
to
Hi Harald,
this is going to be "a bit offtopic"; however there is a valid point in
ELs argumentation: Github (and git as VCS) is very popular; I would
think that most projects are maintained with git, and Github is the
biggest Open Source repository at all.
Which means: there are many people which are somehow familar with how it
works, and who are potential contributors; the threshold is much lower
than on any other platform. So, if you care about reaching people,
Github is the best place. F.e. I wouldn't have found the tksvg stuff
when you would not have it pushed to Github.
Harald Oehlmann <wort...@yahoo.de> writes:
> My personal experience with GIT:
> - I am forced to use it, as some decided to use it (not my decision)
> - I maintain two GIT projects (zint-tcl, tksvg)
> - For me, GIT is just a pain.
> - Learning it, is so complicated. Anything is hidden - to find the
> timeline took me years - I still read one hour tutorial to do a
> simple step - but seeing all the nice people icons and statistics is
> a sort of amusement...
This IMO comes from your experience with Fossil- people who grew up with
Github (like me) have similar problems with Fossil. It is just
different.
The time line is the history, right? It is just hitting the "Commits"
link, or doing "git log" on the cmd line, or showing directly in gitk or
another graphicsl tool.
> - Pull requests are a big problem for me as maintainer. I tend to
> accept points only by patches by E-Mail. Each time I get a pull
> request, I need hours to find out, what it does. Then, I press
> "rejected" and then, I manually modify the source by excusing the
> author and explaining, why it is done like that and explaining
> manually in the source, where it came from (referencing the pull
> request).
Why? You just answer in the pull request what you dislike and ask the
author to change it to your needs. You can even comment directly the
code lines and ask for changes. Or change it yourself in the pull
request. The changes can be shown directly in the "Files changed" tab.
The idea is that you have a discussion in the pull request which
documents how thinks went, and finally just merge. And the Github
workflow is (once you are familar with it) quite effective.
> - You know perhaps the GIT windows client - no comment required ;-) -
> you press the wrong button - error - command line fix - re-clone
> repository - retry - fail again - re-clone. It takes hours of my
> time...
I am not familar with Windows at all; but the command line client should
be the same as for Linux. And with some experience you almost never need
to re-clone. As a tip: "git reflog" shows you the last steps you did,
and you can always get back to an earlier state.
When the pandemie is more over than now, we may meet for a Beer on my
way home and I can show it to you :-)
Cheers
Ole
this is going to be "a bit offtopic"; however there is a valid point in
ELs argumentation: Github (and git as VCS) is very popular; I would
think that most projects are maintained with git, and Github is the
biggest Open Source repository at all.
Which means: there are many people which are somehow familar with how it
works, and who are potential contributors; the threshold is much lower
than on any other platform. So, if you care about reaching people,
Github is the best place. F.e. I wouldn't have found the tksvg stuff
when you would not have it pushed to Github.
Harald Oehlmann <wort...@yahoo.de> writes:
> My personal experience with GIT:
> - I am forced to use it, as some decided to use it (not my decision)
> - I maintain two GIT projects (zint-tcl, tksvg)
> - For me, GIT is just a pain.
> - Learning it, is so complicated. Anything is hidden - to find the
> timeline took me years - I still read one hour tutorial to do a
> simple step - but seeing all the nice people icons and statistics is
> a sort of amusement...
Github (like me) have similar problems with Fossil. It is just
different.
The time line is the history, right? It is just hitting the "Commits"
link, or doing "git log" on the cmd line, or showing directly in gitk or
another graphicsl tool.
> - Pull requests are a big problem for me as maintainer. I tend to
> accept points only by patches by E-Mail. Each time I get a pull
> request, I need hours to find out, what it does. Then, I press
> "rejected" and then, I manually modify the source by excusing the
> author and explaining, why it is done like that and explaining
> manually in the source, where it came from (referencing the pull
> request).
author to change it to your needs. You can even comment directly the
code lines and ask for changes. Or change it yourself in the pull
request. The changes can be shown directly in the "Files changed" tab.
The idea is that you have a discussion in the pull request which
documents how thinks went, and finally just merge. And the Github
workflow is (once you are familar with it) quite effective.
> - You know perhaps the GIT windows client - no comment required ;-) -
> you press the wrong button - error - command line fix - re-clone
> repository - retry - fail again - re-clone. It takes hours of my
> time...
be the same as for Linux. And with some experience you almost never need
to re-clone. As a tip: "git reflog" shows you the last steps you did,
and you can always get back to an earlier state.
When the pandemie is more over than now, we may meet for a Beer on my
way home and I can show it to you :-)
Cheers
Ole
EL
Jun 9, 2021, 12:44:05 PM6/9/21
to
On 09.06.2021 17:38, Harald Oehlmann wrote:
> My personal experience with GIT:
> - I am forced to use it, as some decided to use it (not my decision)
> - I maintain two GIT projects (zint-tcl, tksvg)
> - For me, GIT is just a pain.
> - Learning it, is so complicated. Anything is hidden - to find the
> timeline took me years - I still read one hour tutorial to do a simple
> step - but seeing all the nice people icons and statistics is a sort of
> amusement...
Ok, well... I understand :).
> My personal experience with GIT:
> - I am forced to use it, as some decided to use it (not my decision)
> - I maintain two GIT projects (zint-tcl, tksvg)
> - For me, GIT is just a pain.
> - Learning it, is so complicated. Anything is hidden - to find the
> timeline took me years - I still read one hour tutorial to do a simple
> step - but seeing all the nice people icons and statistics is a sort of
> amusement...
It took me some time and constant practice too, but finally, after
getting used to the workflows, I must say I don't want to go back to the
dark ages of SVN or worse.
BTW, the timeline is just "git log".
I personally have an alias in my ~/.gitconfig on "git log --pretty ..."
that displays a compressed and nicely colored timeline like so:
eb29967 [ecky-l, 05.06.2021 12:08] (U F4B70B208E1AB48A) test verbosity
that is:
short-hash [name, date] (GPG key of signature) "first line of message"
But that's a matter of personal taste.
> - Pull requests are a big problem for me as maintainer. I tend to accept
> points only by patches by E-Mail. Each time I get a pull request, I need
> hours to find out, what it does. Then, I press "rejected" and then, I
> manually modify the source by excusing the author and explaining, why it
> is done like that and explaining manually in the source, where it came
> from (referencing the pull request).
comment on them, and finally click "merge" (or was it "accept"?) to get
it in the mainstream repo.
Fiddling around with patches by Email and applying them manually to the
source is a lot more complicated. I did that as well, but... that was
ages ago, today I would not want it anymore.
> - You know perhaps the GIT windows client - no comment required ;-) -
> you press the wrong button - error - command line fix - re-clone
> repository - retry - fail again - re-clone. It takes hours of my time...
every subcommand, in case you forgot the usage.
That's what I do. Sometimes I use the core UI tools like git-gui or gitk
(both written in Tcl/Tk, for that matter), but most of the time I use
purely the git bash on windows.
But that's also personal matter of taste. I am just so much used to the
command line in everything I do.
--
EL
Eric
Jun 9, 2021, 1:10:05 PM6/9/21
to
On 2021-06-09, EL <e...@noreply.spam> wrote:
> On 09.06.2021 14:45, Harald Oehlmann wrote:
8>< --------
> On 09.06.2021 14:45, Harald Oehlmann wrote:
> The point here is not a batteries included sort of distribution. The
> point here is to get the Tcl sources and Tcl package sources to a
> mainstream infrastructure that almost every developer uses today,
Really? I happen to use a Linux distro called voidlinux which happens to
> point here is to get the Tcl sources and Tcl package sources to a
> mainstream infrastructure that almost every developer uses today,
make it easy for me to count how many packages are built (by the distro
build infrastructure) from package source code obtained from github:
Packages built from github 2573
Packages not built from github 5211
Some of those "from github" are actually using a github mirror of the
package sources whose definitive copy is elsewhere.
So, "almost every"?
> for the following purposes:
>
> - single point of entrance
> - low to zero learning curve
(whatever it may be)
> - modern infrastructure
Whatever that means. Fossil is modern infrastructure.
> Especially pull requests
Pull requests fit into a particular style of package maintenance which
does not suit every project, and which many people actually disapprove
of.
8>< --------
> Every language has nowadays some kind of package manager.
Yes, Tcl would benefit from a new package manager - want to write it?
8>< --------
> It's almost impossible for anyone to implement a package manager when
> the packages are too scattered around the net.
No it isn't! That's essentially what most Linux distros do.
> the packages are too scattered around the net.
No more point-by-point answers (which would be repetitive anyway since
you do seem to have repeated yourself to some extent).
You seem to want everything to use github because it is the most popular -
it isn't (see above) and even if it was that would not be a good reason
to use it.
However,
* github is owned by Microsoft
* git itself allows the project history to be distorted after the event
* regardless of those, git may not be the best tool for every project
* moving Tcl to github would be solving the wrong problem, and would
also be a poor use of the available resources.
Eric
--
ms fnd in a lbry
Harald Oehlmann
Jun 9, 2021, 1:41:07 PM6/9/21
to
Dear Eric,
thank you for your contribution.
There is one point, which is a bit ironic in history:
Am 09.06.2021 um 19:00 schrieb Eric:
> On 2021-06-09, EL <e...@noreply.spam> wrote:
>> Every language has nowadays some kind of package manager.
>
> Yes, Tcl would benefit from a new package manager - want to write it?
currently on github ;-)
I had a licence for it and it did its job until ActiveState gave up.
Perhaps some additional personal words:
My personal use-case is an all integrated starkit.
Thus, I personally copy everything to a local svn. You know TortoiseSVN?
That is really comfortable! Icons in the file explorer with overlayd and
recursive status icons, right click and all relevant commands, light
speed. Never entered one line on the command line. I include all
libraries by externs including the documentation (auto assembled). The
maximum version number of my repository is automatically in the about
box of the application and in the documentation.
All comments up to now are: GIT it is simple - go to the command line -
type this - edit a config file. You may imagine, that those hints make
me a bit smile ;-). The perception of the word "simple" may be two-fold.
TkSVG was created by Christian on fossil. The other Christian has
probably modified it and has put it on GIT. Both are Wizards and my role
is to support them. So, I took tksvg and maintain it with my limmited
knowledge.
If others decide to go GIT - no problem - I will serve.
Thank you all, I appreciate !
Harald
EL
Jun 9, 2021, 2:44:04 PM6/9/21
to
On 09.06.2021 19:00, Eric wrote:
> Packages built from github 2573
> Packages not built from github 5211
You compare apples to pears here. I was not talking about linux
> Packages built from github 2573
> Packages not built from github 5211
distribution packages, where hundreds of diligent maintainers work on a
few packages each. I was talking about a programming language package
manager, where the requirements are quite different (package upgrades,
versioning, actuality etc.) and especially I was talking about a
repository for such a thing.
Nevertheless, a ratio of 2573 github to 5211 not github is still
impressive. It shows where the journey went in the past years.
> So, "almost every"?
The "almost every" I was talking about was regarding the developers. I
said: almost every developer knows github.
>
>> for the following purposes:
>>
>> - single point of entrance
>
> Fossil provides that for anything that uses it
>
>> - low to zero learning curve
>
> For those who already know the system used by the package maintainers
> (whatever it may be)
>
>> - modern infrastructure
>
> Whatever that means. Fossil is modern infrastructure.
pull requests (or merge request). What exactly has the fossil ecosystem
to offer in that direction?
> Pull requests fit into a particular style of package maintenance which
> does not suit every project, and which many people actually disapprove
> of.
where the package maintainer is the _only_ developer. Or where he hardly
tries to be the only developer.
Otherwise, when a larger team works on a code base, or external
contributions must be integrated, I cannot imagine a different style. At
least not one with similar efficiency. Really.
> Yes, Tcl would benefit from a new package manager - want to write it?
and they have semantic versioning, it shouldn't be a big problem ;).
Then it's not too hard to implement such a thing.
The hard thing is: how to get the packages to this central place, in a
unique format, and hopefully built automatically from VCS tags by a
CI/CD pipeline, for many platforms (if necessary)?
> No it isn't! That's essentially what most Linux distros do.
as it is @debian. With fulltime employees who do the same work for
money, as it is @redhat or @suse.
Sure, with much manpower behind it is easy to fill the repos also from
non-central places.
Anyway, its still comparing apples to pears. What we would need is more
like pip, maven, cargo etc.. Not like deb or rpm.
> You seem to want everything to use github because it is the most popular -
> it isn't (see above) and even if it was that would not be a good reason
> to use it.
for your linux distro come from github, whereas the rest is from
different other sources. Have you looked at the other sources,
quantity-wise?
But yes, there are alternatives to github. Gitlab for instance. Its even
very easy to host an own gitlab server, which provides the same
functionality as github... Pull requests are called "merge requests"
there, but in principal its the same. Its even for free in most
circumstances. I don't know how releases would be handled though, I have
never done that with gitlab. But maybe that is possible too. But a big
plus: Gitlab has its build in pipelines for CI/CD, which is very nice
and maybe even easier than that of github.
Then my points from the post before would also be fulfilled, mostly, or
even overfulfilled (CI/CD additionally). I don't want to repeat them
here ;).
--
EL
Оlе Ѕtrеісhеr
Jun 9, 2021, 2:48:03 PM6/9/21
to
Hi Eric,
Eric <er...@deptj.eu> writes:
> On 2021-06-09, EL <e...@noreply.spam> wrote:
>> On 09.06.2021 14:45, Harald Oehlmann wrote:
> 8>< --------
>> The point here is not a batteries included sort of distribution. The
>> point here is to get the Tcl sources and Tcl package sources to a
>> mainstream infrastructure that almost every developer uses today,
>
> Really? I happen to use a Linux distro called voidlinux which happens to
> make it easy for me to count how many packages are built (by the distro
> build infrastructure) from package source code obtained from github:
>
> Packages built from github 2573
> Packages not built from github 5211
>
> Some of those "from github" are actually using a github mirror of the
> package sources whose definitive copy is elsewhere.
>
> So, "almost every"?
Don't be nitpicky on words. I also know a lot of packages that are
developed elsewhere. To make a small, personal estimation from what I
maintain or sponsor as astronomy packages for Debian:
* 145 packages with an upstream repository
- 102 github.com
- 3 sourceforge.net
- 2 savannah.gnu.org
- 1 gitlab.com
- 1 bitbucket.org
- 35 on personal servers (6 of them are being migrated to github)
The "personal servers" are usually not (write-) accessible for the
public. Ofcourse, that statistics is subjective.
Not all there packages are "built from github", most Python packages are
f.e. taken from PyPI. However, the development happens on Github. This
may explain the difference between your and my findings.
>> for the following purposes:
>> - single point of entrance
>
> Fossil provides that for anything that uses it
It does not really. Handling >>100 packages, I am really happy about the
statistics above; this allows me to communicate patches and issues for
most packages with a single login, using a single user interface.
My threshold to contribute is therefor much lower for software that is
on Github than for any other platform. The whole issue here would not
have been brought up if I didn't find the tclxml packages on Github.
So, this "single point of entrance" really helps to increase the
visibility of the software. Something that is crucial for Tcl/Tk.
>> - low to zero learning curve
>
> For those who already know the system used by the package maintainers
> (whatever it may be)
... and for many potential contributors. There are probably many more
people out there knowing git than knowing fossil. From my experience in
the astronomy community: Many, especially younger, developers know Git
(and Github), some know Subversion, few know Mercury, and almost nobody
knows Fossil. And learning a different VCS just to volunteer some Tcl
maintainance? I am sure that most people have better things to do.
>> Especially pull requests
>
> Pull requests fit into a particular style of package maintenance which
> does not suit every project, and which many people actually disapprove
> of.
My personal feeling here is that you are not right. One reason is that
other git repository servers actually try to copy much of the Github
workflow: Bitbucket is quite similar, Gitlab just names the pull
requests "Merge Requests" etc (actually, that is a co-evolution, not
just a copy). They would not do it if the Github workflow would not be
that useful for most people.
> However,
>
> * github is owned by Microsoft
May be seen problematic; however the API allows one to export
everything. And there are many similar projects, for example Gitlab
(which is Open Source). So, in case Microsoft does something weird,
there is no real vendor-lockin, one can migrate.
> * git itself allows the project history to be distorted after the
> event
Not really. Every commit has an id, and this cannot be altered. As long
as the repository is intact and the commit id is know, you can always
recover. That is similar to Fossil (as far as I know).
> * regardless of those, git may not be the best tool for every project
That is -- as a general comment -- right, but obvious. There is never a
"one size fits all" solution.
> * moving Tcl to github would be solving the wrong problem, and would
> also be a poor use of the available resources.
That was not my proposal. My proposal was to create a community
organization on Github as a central place for module maintainance.
And I think that I brought some good arguments for it, which were still
not discussed.
Cheers
Ole
Eric <er...@deptj.eu> writes:
> On 2021-06-09, EL <e...@noreply.spam> wrote:
>> On 09.06.2021 14:45, Harald Oehlmann wrote:
> 8>< --------
>> The point here is not a batteries included sort of distribution. The
>> point here is to get the Tcl sources and Tcl package sources to a
>> mainstream infrastructure that almost every developer uses today,
>
> Really? I happen to use a Linux distro called voidlinux which happens to
> make it easy for me to count how many packages are built (by the distro
> build infrastructure) from package source code obtained from github:
>
> Packages built from github 2573
> Packages not built from github 5211
>
> Some of those "from github" are actually using a github mirror of the
> package sources whose definitive copy is elsewhere.
>
> So, "almost every"?
developed elsewhere. To make a small, personal estimation from what I
maintain or sponsor as astronomy packages for Debian:
* 145 packages with an upstream repository
- 102 github.com
- 3 sourceforge.net
- 2 savannah.gnu.org
- 1 gitlab.com
- 1 bitbucket.org
- 35 on personal servers (6 of them are being migrated to github)
The "personal servers" are usually not (write-) accessible for the
public. Ofcourse, that statistics is subjective.
Not all there packages are "built from github", most Python packages are
f.e. taken from PyPI. However, the development happens on Github. This
may explain the difference between your and my findings.
>> for the following purposes:
>> - single point of entrance
>
> Fossil provides that for anything that uses it
statistics above; this allows me to communicate patches and issues for
most packages with a single login, using a single user interface.
My threshold to contribute is therefor much lower for software that is
on Github than for any other platform. The whole issue here would not
have been brought up if I didn't find the tclxml packages on Github.
So, this "single point of entrance" really helps to increase the
visibility of the software. Something that is crucial for Tcl/Tk.
>> - low to zero learning curve
>
> For those who already know the system used by the package maintainers
> (whatever it may be)
people out there knowing git than knowing fossil. From my experience in
the astronomy community: Many, especially younger, developers know Git
(and Github), some know Subversion, few know Mercury, and almost nobody
knows Fossil. And learning a different VCS just to volunteer some Tcl
maintainance? I am sure that most people have better things to do.
>> Especially pull requests
>
> Pull requests fit into a particular style of package maintenance which
> does not suit every project, and which many people actually disapprove
> of.
other git repository servers actually try to copy much of the Github
workflow: Bitbucket is quite similar, Gitlab just names the pull
requests "Merge Requests" etc (actually, that is a co-evolution, not
just a copy). They would not do it if the Github workflow would not be
that useful for most people.
> However,
>
> * github is owned by Microsoft
everything. And there are many similar projects, for example Gitlab
(which is Open Source). So, in case Microsoft does something weird,
there is no real vendor-lockin, one can migrate.
> * git itself allows the project history to be distorted after the
> event
as the repository is intact and the commit id is know, you can always
recover. That is similar to Fossil (as far as I know).
> * regardless of those, git may not be the best tool for every project
"one size fits all" solution.
> * moving Tcl to github would be solving the wrong problem, and would
> also be a poor use of the available resources.
organization on Github as a central place for module maintainance.
And I think that I brought some good arguments for it, which were still
not discussed.
Cheers
Ole
Christian Gollwitzer
Jun 9, 2021, 4:03:21 PM6/9/21
to
Hi Ole,
Am 09.06.21 um 18:19 schrieb Оlе Ѕtrеісhеr:
such a thing exists - in fact, tksvg is on Github because I started it
there and later on Harald took over the maintenance.
The problem is: the most important Tcl developers, the TCT, worked with
CVS and then learned fossil and they have zero incentive to re-learn git
now. Fossil was chosen back then because Richard Hipp wrote it, a
valuable member of the Tcl community, who also wrote SQLite (sic!) as a
Tcl extension first.
I also think that, when maintaining an "obscure" language, one should at
least not use "obscure" tools, but you'll have to convince the core
developers of this switch. It's like left-handed traffic, bad idea, hard
to change. At least, there is a bridge from fossil to git such that
every commit gets also pushed to https://github.com/tcltk/
> When the pandemie is more over than now, we may meet for a Beer on my
> way home and I can show it to you :-)
I might also join, I'm in Schöneberg....
Christian
Am 09.06.21 um 18:19 schrieb Оlе Ѕtrеісhеr:
> Which means: there are many people which are somehow familar with how it
> works, and who are potential contributors; the threshold is much lower
> than on any other platform. So, if you care about reaching people,
> Github is the best place. F.e. I wouldn't have found the tksvg stuff
> when you would not have it pushed to Github.
I fully agree with you. I'm also a "git person" in this universe, if
> works, and who are potential contributors; the threshold is much lower
> than on any other platform. So, if you care about reaching people,
> Github is the best place. F.e. I wouldn't have found the tksvg stuff
> when you would not have it pushed to Github.
such a thing exists - in fact, tksvg is on Github because I started it
there and later on Harald took over the maintenance.
The problem is: the most important Tcl developers, the TCT, worked with
CVS and then learned fossil and they have zero incentive to re-learn git
now. Fossil was chosen back then because Richard Hipp wrote it, a
valuable member of the Tcl community, who also wrote SQLite (sic!) as a
Tcl extension first.
I also think that, when maintaining an "obscure" language, one should at
least not use "obscure" tools, but you'll have to convince the core
developers of this switch. It's like left-handed traffic, bad idea, hard
to change. At least, there is a bridge from fossil to git such that
every commit gets also pushed to https://github.com/tcltk/
> When the pandemie is more over than now, we may meet for a Beer on my
> way home and I can show it to you :-)
Christian
Eric
Jun 9, 2021, 4:10:05 PM6/9/21
to
On 2021-06-09, EL <e...@noreply.spam> wrote:
You have misunderstood most of the things I said. I suppose you will
choose to blame me for that, but it doesn't matter.
It seems to me that the style of your posts is a combination of
tunnel vision, perpetual denial and broken record.
Christian Gollwitzer
Jun 9, 2021, 4:12:00 PM6/9/21
to
Am 09.06.21 um 19:40 schrieb Harald Oehlmann:
G., and developed in the original repo auriocus/tksvg on github which
you have taken over. Christian W. found it useful and contributed big
patches. He stored his own copy on fossil as a part of androwish.
Finally, Rene Zaumseil voted for inclusion into the Tk core with TIP 507
which was accepted and now it lives on as a part of Tk 8.7, which again
YOU backport into the repo, now oehhar/tksvg
Christian G.
> TkSVG was created by Christian on fossil. The other Christian has
> probably modified it and has put it on GIT. Both are Wizards and my role
> is to support them. So, I took tksvg and maintain it with my limmited
> knowledge.
Please don't distort the history! tksvg was initiated by me, Christian
> probably modified it and has put it on GIT. Both are Wizards and my role
> is to support them. So, I took tksvg and maintain it with my limmited
> knowledge.
G., and developed in the original repo auriocus/tksvg on github which
you have taken over. Christian W. found it useful and contributed big
patches. He stored his own copy on fossil as a part of androwish.
Finally, Rene Zaumseil voted for inclusion into the Tk core with TIP 507
which was accepted and now it lives on as a part of Tk 8.7, which again
YOU backport into the repo, now oehhar/tksvg
Christian G.
Оlе Ѕtrеісhеr
Jun 9, 2021, 5:06:55 PM6/9/21
to
> I also think that, when maintaining an "obscure" language, one should
> at least not use "obscure" tools, but you'll have to convince the core
> developers of this switch. It's like left-handed traffic, bad idea,
> hard to change. At least, there is a bridge from fossil to git such
> that every commit gets also pushed to https://github.com/tcltk/
I don't want to convince the core people to switch. My proposal was that
> at least not use "obscure" tools, but you'll have to convince the core
> developers of this switch. It's like left-handed traffic, bad idea,
> hard to change. At least, there is a bridge from fossil to git such
> that every commit gets also pushed to https://github.com/tcltk/
"community development" (i.e. things that is not in the core) could
happen in a well-defined place on Github. This however only works if a
"critical mass" of maintainers would take part; it does not make sense
to have there just my 2-3 packages, and me as the only one, basically
incompetent, team member.
>> When the pandemie is more over than now, we may meet for a Beer on my
>> way home and I can show it to you :-)
>
> I might also join, I'm in Schöneberg....
Cheers
Ole
EL
Jun 9, 2021, 7:02:04 PM6/9/21
to
On 09.06.2021 21:41, Eric wrote:
> It seems to me that the style of your posts is a combination of
> tunnel vision, perpetual denial and broken record.
In that assumption you are clearly wrong.
> It seems to me that the style of your posts is a combination of
> tunnel vision, perpetual denial and broken record.
--
EL
Harald Oehlmann
Jun 10, 2021, 2:50:11 AM6/10/21
to
I thought, it was the other way around.
Sorry, you learn each day.
Thank you,
Harald
Оlе Ѕtrеісhеr
Jun 10, 2021, 3:38:07 AM6/10/21
to
Hi EL,
EL <elehm...@gmail.com> writes:
> fossil. The most important and valuable extensions are also on fossil
> servers elsewhere (or even still at sourceforge). They followed the
> decision of the TCT.
I think here we have the big difference in the development philosphy:
Grown up with Linux, and being a convinced git user and part of the
Debian developer community, I believe that the best way to create (most
of) Open Source is the "Bazaar" principle: low threshold to contribute,
many contributors, self-organization etc.
On the other side, Tcl seems to be developed in a "cathedral" style, not
by chance, but by decision (or tradition). This leads to a much more
closed development, where one can contribute from extern only via
mailed-in patches.
While both schemas somehow work with an active community, the
"cathedral" way has clear disadvantages when projects get old, loose
popularity etc. Then packages don't have anymore an active developer
team; people just disappear, packages are getting unmaintained and
nobody really turns up to take over in full. Instead, people like me pop
up and want to fix one single line, to keep it running in their
environment, but they don't want to take the burden of being responsible
for the whole package. So, with the "cathedral" style, they create a
local copy and fix it there, and we end up with what we finally see:
forks of Tcl modules, each with a few small local fixes or changes;
partially incomplete or with a questioned history. At the end we don't
have a structure anymore, but an unmaintainable mess.
Converting the development philosophy at some point into "bazaar" style
makes it easier to keep the development in a central place for aging
packages. The repository is then the natural place to discuss patches
("Pull Requests"), and the threshold to contribute from strawmen is
rather low, encouraging people to submit what they otherwise would have
kept locally. So, you still have an (although slow) further maintainance
and development and keep a structure for the software as long as there
is any interest in it.
E.S.Raymone, The Cathedran and the Bazaar:
http://www.catb.org/~esr/writings/cathedral-bazaar/
Fossil Versus Git, Development Organization:
https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki#devorg
I however think that it is impossible to convince people to change the
basic development style. It seems that there is not enough intrinsic
momentum in creating a Tcl community on Github; that makes the
realization of my proposal improble. If someone wants to continue
efforts for this: I am happe to hand over the few Tcl/Tk packages that I
maintain.
Cheers
Ole
EL <elehm...@gmail.com> writes:
> Оlе Ѕtrеісhеr <ole-use...@gmx.net> wrote:
>> I don't want to convince the core people to switch. My proposal was that
>> "community development" (i.e. things that is not in the core) could
>> happen in a well-defined place on Github. This however only works if a
>> "critical mass" of maintainers would take part;
>
> Yes. But the main part of the truly *active* Tcl community is working with
>> I don't want to convince the core people to switch. My proposal was that
>> "community development" (i.e. things that is not in the core) could
>> happen in a well-defined place on Github. This however only works if a
>> "critical mass" of maintainers would take part;
>
> fossil. The most important and valuable extensions are also on fossil
> servers elsewhere (or even still at sourceforge). They followed the
> decision of the TCT.
I think here we have the big difference in the development philosphy:
Grown up with Linux, and being a convinced git user and part of the
Debian developer community, I believe that the best way to create (most
of) Open Source is the "Bazaar" principle: low threshold to contribute,
many contributors, self-organization etc.
On the other side, Tcl seems to be developed in a "cathedral" style, not
by chance, but by decision (or tradition). This leads to a much more
closed development, where one can contribute from extern only via
mailed-in patches.
While both schemas somehow work with an active community, the
"cathedral" way has clear disadvantages when projects get old, loose
popularity etc. Then packages don't have anymore an active developer
team; people just disappear, packages are getting unmaintained and
nobody really turns up to take over in full. Instead, people like me pop
up and want to fix one single line, to keep it running in their
environment, but they don't want to take the burden of being responsible
for the whole package. So, with the "cathedral" style, they create a
local copy and fix it there, and we end up with what we finally see:
forks of Tcl modules, each with a few small local fixes or changes;
partially incomplete or with a questioned history. At the end we don't
have a structure anymore, but an unmaintainable mess.
Converting the development philosophy at some point into "bazaar" style
makes it easier to keep the development in a central place for aging
packages. The repository is then the natural place to discuss patches
("Pull Requests"), and the threshold to contribute from strawmen is
rather low, encouraging people to submit what they otherwise would have
kept locally. So, you still have an (although slow) further maintainance
and development and keep a structure for the software as long as there
is any interest in it.
E.S.Raymone, The Cathedran and the Bazaar:
http://www.catb.org/~esr/writings/cathedral-bazaar/
Fossil Versus Git, Development Organization:
https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki#devorg
I however think that it is impossible to convince people to change the
basic development style. It seems that there is not enough intrinsic
momentum in creating a Tcl community on Github; that makes the
realization of my proposal improble. If someone wants to continue
efforts for this: I am happe to hand over the few Tcl/Tk packages that I
maintain.
Cheers
Ole
Harald Oehlmann
Jun 10, 2021, 4:52:28 AM6/10/21
to
Dear Ole, dear EL,
thank you for your contributions.
I personally don't like to speak about "the TCT". This set of people are
individuals with merit in TCL/Tk. For my perception, your words about
them to blame them for all that is personally blessing, sorry.
I would invite you to some respect. There is no "the TCT". There is a
procedure (TIP) and the TCT members voting on them.
What I can say on the Cathedral:
- the GIT one got just copied to another GIT repository. That is totally
ok, no problem. It is aparently the way on GIT to solve issues. I did
not get one ticket. It is just copied. That is ok, no problem.
- on the fossil ones, nobody copied it. I get tickets.
I am a very low level programmer. My last contribution to tk (image
metadata) took 2 full years of programming and understanding time.
Nevertheless, I always got support to implement it. But I must accept
the rules. They are difficult for me.
I can understand that all the wizards do not follow that. They do that
in one day. And writing TIPs or doing administrative steps which take
months are just not in the time frame. That is why I try to support the
wizards.
I am also always amazed about the quality of TCL/Tk. Bugs are taken
serious and are hunted until found. That may take 10 years (like "open
com1:" in Tk). I like the conservative way, as quality is one of the
priorities.
Of cause, I would love to have more fancy features: gesture support, for
example, modern Windows skin, Browser integration, more speed, get all
the indexed colour support out of Tk (image). I work slowly on all that.
One day, it will come or not. Csaba has recently implemented a lot of my
dreams with scrollutil.
Yesterday, the other Christian posted a success story at the end of this
wiki page:
https://wiki.tcl-lang.org/page/LUCK
Try it, it is just amazing. 1 minuite to a running application for
Windows, Mac, Linux, Android. This wizard is rejecting to directly
contribute to fossil - takes to much time - administrative burden - no
way. I understand and try to build the bridge manually.
People come and go. The designer of Ttk is gone, coroutines designer
died. That is life. I am thankful to them. It is always disruptive.
Despite of all of that, TCL is alive and at good health.
Again, I am not against a git community. Go ! I am sure, "the TCT" will
not stop you.
Best regards,
Harald
Оlе Ѕtrеісhеr
Jun 10, 2021, 5:39:39 AM6/10/21
to
Dear Harald,
Harald Oehlmann <wort...@yahoo.de> writes:
> Dear Ole, dear EL,
>
> thank you for your contributions.
>
> I personally don't like to speak about "the TCT". This set of people
> are individuals with merit in TCL/Tk. For my perception, your words
> about them to blame them for all that is personally blessing, sorry.
I do not blame anyone here. I tried to point out the differences in the
development philosophy and how this -- in my opinion -- affects the
future development.
I also don't speak about core development. My point here are some
packages which are part the Tcl/Tk universe, which are usually not
maintained by the core maintainers.
> Again, I am not against a git community. Go ! I am sure, "the TCT"
> will not stop you.
That was never my question. I would rather formulate the other way: who
would join such an initiative? And the response to this is not really
overwhelming, which makes my proposal unlikely to happen.
Cheers
Ole
Harald Oehlmann <wort...@yahoo.de> writes:
> Dear Ole, dear EL,
>
> thank you for your contributions.
>
> I personally don't like to speak about "the TCT". This set of people
> are individuals with merit in TCL/Tk. For my perception, your words
> about them to blame them for all that is personally blessing, sorry.
development philosophy and how this -- in my opinion -- affects the
future development.
I also don't speak about core development. My point here are some
packages which are part the Tcl/Tk universe, which are usually not
maintained by the core maintainers.
> Again, I am not against a git community. Go ! I am sure, "the TCT"
> will not stop you.
would join such an initiative? And the response to this is not really
overwhelming, which makes my proposal unlikely to happen.
Cheers
Ole
EL
Jun 10, 2021, 6:02:04 AM6/10/21
to
On 10.06.2021 10:52, Harald Oehlmann wrote:
> I personally don't like to speak about "the TCT". This set of people are
> individuals with merit in TCL/Tk. For my perception, your words about
> them to blame them for all that is personally blessing, sorry.
> I would invite you to some respect. There is no "the TCT". There is a
> procedure (TIP) and the TCT members voting on them.
I haven't blamed anybody. If you think so, you should maybe rethink your
> I personally don't like to speak about "the TCT". This set of people are
> individuals with merit in TCL/Tk. For my perception, your words about
> them to blame them for all that is personally blessing, sorry.
> I would invite you to some respect. There is no "the TCT". There is a
> procedure (TIP) and the TCT members voting on them.
perception.
I have just stated the things as they are. Tcl development *is* driven
by the TCT and they decide about the directions. That has always been
so... And no, I do not think this goes entirely bad or must be
fundamentally changed.
What I initially proposed was, that the development could take place in
git and github, so that a larger developer base could more easily
contribute. That would not mean a total shift of style, since the TCT
would still decide which patches (= PRs) go in and which ones not. Just
that it would be easier for them also, to review these patches. It would
just mean a change in tooling, not a change in style or directions.
Well, what could maybe change is, that fixes and enhancements come in
faster by more people, which is generally a good thing (at least as far
as I consider). But it would still not be out of control of the TCT.
But well... I understand that this is not going to happen. So let's
leave things in peace and go back to work ;)
--
EL
Harald Oehlmann
Jun 10, 2021, 6:05:10 AM6/10/21
to
Am 10.06.2021 um 11:39 schrieb Оlе Ѕtrеісhеr:
> That was never my question. I would rather formulate the other way: who
> would join such an initiative? And the response to this is not really
> overwhelming, which makes my proposal unlikely to happen.
>
> Cheers
>
> Ole
>
As this discussions sows up again and again, I think people are fearing
harsh mails like from EL. Even positive people are fearing of bashing in
the modern style of internet (like the EL style).
Most people are very shy nerds and we are all doing this volontarily.
In addition, I suppose, this is more discussed on the TkChat. That is
why you don't read anything here.
Take care,
Harald
EL
Jun 10, 2021, 8:02:05 AM6/10/21
to
On 10.06.2021 09:38, Оlе Ѕtrеісhеr wrote:
> I think here we have the big difference in the development philosphy:
> Grown up with Linux, and being a convinced git user and part of the
> Debian developer community, I believe that the best way to create (most
> of) Open Source is the "Bazaar" principle: low threshold to contribute,
> many contributors, self-organization etc.
>
> On the other side, Tcl seems to be developed in a "cathedral" style, not
> by chance, but by decision (or tradition). This leads to a much more
> closed development, where one can contribute from extern only via
> mailed-in patches.
You are right. I haven't seen it from this perspective before, but yes,
> I think here we have the big difference in the development philosphy:
> Grown up with Linux, and being a convinced git user and part of the
> Debian developer community, I believe that the best way to create (most
> of) Open Source is the "Bazaar" principle: low threshold to contribute,
> many contributors, self-organization etc.
>
> On the other side, Tcl seems to be developed in a "cathedral" style, not
> by chance, but by decision (or tradition). This leads to a much more
> closed development, where one can contribute from extern only via
> mailed-in patches.
that describes it very well.
> While both schemas somehow work with an active community, the
> "cathedral" way has clear disadvantages when projects get old, loose
> popularity etc. Then packages don't have anymore an active developer
> team; people just disappear, packages are getting unmaintained and
> nobody really turns up to take over in full. Instead, people like me pop
> up and want to fix one single line, to keep it running in their
> environment, but they don't want to take the burden of being responsible
> for the whole package. So, with the "cathedral" style, they create a
> local copy and fix it there, and we end up with what we finally see:
> forks of Tcl modules, each with a few small local fixes or changes;
> partially incomplete or with a questioned history. At the end we don't
> have a structure anymore, but an unmaintainable mess.
honest. But I know that it is applied a lot... so there may be
advantages over the bazaar model.
> Converting the development philosophy at some point into "bazaar" style
> makes it easier to keep the development in a central place for aging
> packages. The repository is then the natural place to discuss patches
> ("Pull Requests"), and the threshold to contribute from strawmen is
> rather low, encouraging people to submit what they otherwise would have
> kept locally. So, you still have an (although slow) further maintainance
> and development and keep a structure for the software as long as there
> is any interest in it.
abandoned or are for whatever reasons poorly maintained. They could go
to github as "the central repo" and switch to the bazaar style. Maybe
this is even already...
> I however think that it is impossible to convince people to change the
> basic development style.
maintainers who favor it. And for the Tcl core, this is still the case.
But as you mentioned, the situation is different when the maintainers go
away and nobody feels responsible anymore for the software, or the
maintainers have not much time for it anymore, etc. This is the case for
various extensions, and then the bazaar style would work better for them.
> It seems that there is not enough intrinsic
> momentum in creating a Tcl community on Github; that makes the
> realization of my proposal improble.
the closest, thematically. But its apparently just mirrors... Maybe it
can be discussed with the maintainers of various extensions on fossil,
which are poorly maintained on fossil at the moment, whether they want
to switch to github as primary repos?
--
EL
rene
Jun 10, 2021, 8:09:16 AM6/10/21
to
Hello Ole,
don't give up so easy.
Оlе Ѕtrеісhеr schrieb am Donnerstag, 10. Juni 2021 um 11:39:39 UTC+2:
> I also don't speak about core development. My point here are some
> packages which are part the Tcl/Tk universe, which are usually not
> maintained by the core maintainers.
> > Again, I am not against a git community. Go ! I am sure, "the TCT"
> > will not stop you.
> That was never my question. I would rather formulate the other way: who
> would join such an initiative? And the response to this is not really
> overwhelming, which makes my proposal unlikely to happen.
This is IMHO a really good question. I already have done some work in BI creation.
The main problem was always finding the correct source.
Do you know the gutter at https://core.tcl-lang.org/jenglish/gutter/
Just another attempt to get a central point to get the sources.
Then there is androwish.org. Have a look on it.
I personally have my repos under fossil at chiselapp.com.
And I'm seldom use git. But I'm not against it.
So you have to give some more details.
- How will we identify packages on github
- Who will be maintainer
- Can we get existing packages with history to github (fossil2git, svn2git,..)
- Should we use github as mirror to the outside and use the code from elsewhere
- Can we build and provide binaries for different platforms
...
May be set up a page on wiki.tcl.tk and discuss there.
Regards
René
don't give up so easy.
Оlе Ѕtrеісhеr schrieb am Donnerstag, 10. Juni 2021 um 11:39:39 UTC+2:
> I also don't speak about core development. My point here are some
> packages which are part the Tcl/Tk universe, which are usually not
> maintained by the core maintainers.
> > Again, I am not against a git community. Go ! I am sure, "the TCT"
> > will not stop you.
> That was never my question. I would rather formulate the other way: who
> would join such an initiative? And the response to this is not really
> overwhelming, which makes my proposal unlikely to happen.
The main problem was always finding the correct source.
Do you know the gutter at https://core.tcl-lang.org/jenglish/gutter/
Just another attempt to get a central point to get the sources.
Then there is androwish.org. Have a look on it.
I personally have my repos under fossil at chiselapp.com.
And I'm seldom use git. But I'm not against it.
So you have to give some more details.
- How will we identify packages on github
- Who will be maintainer
- Can we get existing packages with history to github (fossil2git, svn2git,..)
- Should we use github as mirror to the outside and use the code from elsewhere
- Can we build and provide binaries for different platforms
...
May be set up a page on wiki.tcl.tk and discuss there.
Regards
René
Оlе Ѕtrеісhеr
Jun 10, 2021, 11:15:49 AM6/10/21
to
Hi rene, EL,
rene <r.zau...@gmail.com> writes:
> Do you know the gutter at https://core.tcl-lang.org/jenglish/gutter/
> Just another attempt to get a central point to get the sources.
This is more a page that collects the meta-information than a
development place. It is a good resource, but not what I meant.
Isn't this Android specific?
> I personally have my repos under fossil at chiselapp.com.
> And I'm seldom use git. But I'm not against it.
>
> So you have to give some more details.
> - How will we identify packages on github
I am not sure that I understand this question. A repository in Github is
identified by its name, and for Tcl it would contain one package.
> - Who will be maintainer
The idea would be to create an "organization" in Github, which is
maintained by a team of reputable people. "Maintained" means mainly that
they create (empty) repositories on request for those who want to
maintain their stuff there, and add new members with write access on
their request.
Then the idea is "community maintainance", i.e. each package has a
"main" maintainer, but in principle everyone other team member can push
as well -- but shouldn't, as long as the main maintainer is responsive.
If in doubt, changes should always go through a Pull Request instead of
directly to the main branch, even if one has write access. Pull requests
are always the way to discuss the changes. If there is no response from
the maintainer, one can ofcourse also merge the change so that things go
on. If the maintainer does not respond at all, one could even ask to
take over if one wants.
If someone repeatedly tries to "abuse" the rights to force their own
development against the will of the "main" maintainer, they could be
excluded from the team (and lose write access).
This is a bit like Debian handles its team maintainance, and
pragmatically it works quite good. Everyone can join Debian team
maintainance, and it is really rarely (or never) abused.
> - Can we get existing packages with history to github (fossil2git,
> svn2git,..)
Yes.
> - Should we use github as mirror to the outside and use the code from
> elsewhere
That is not the idea, and does not healp to team-maintain. It rather
leads to forks of the Github repository without feeding back the
changes to the author.
> - Can we build and provide binaries for different platforms
One can attach binary files to a release which then can be downloaded.
The other -- very useful -- thing is that one can automatically run
tests for the package on different platforms (Linux, MacOS,
Windows). This includes "usual" unit tests, but also checking the code
style and similar. And this is done on Pull Requests as well, therefore
for a maintainer it is easy to see whether a change breaks something.
With some work, one could even auto-build the binaries for all platforms
and attach them to the release.
Best regards
Ole
rene <r.zau...@gmail.com> writes:
> Do you know the gutter at https://core.tcl-lang.org/jenglish/gutter/
> Just another attempt to get a central point to get the sources.
development place. It is a good resource, but not what I meant.
Isn't this Android specific?
> I personally have my repos under fossil at chiselapp.com.
> And I'm seldom use git. But I'm not against it.
>
> So you have to give some more details.
> - How will we identify packages on github
identified by its name, and for Tcl it would contain one package.
> - Who will be maintainer
maintained by a team of reputable people. "Maintained" means mainly that
they create (empty) repositories on request for those who want to
maintain their stuff there, and add new members with write access on
their request.
Then the idea is "community maintainance", i.e. each package has a
"main" maintainer, but in principle everyone other team member can push
as well -- but shouldn't, as long as the main maintainer is responsive.
If in doubt, changes should always go through a Pull Request instead of
directly to the main branch, even if one has write access. Pull requests
are always the way to discuss the changes. If there is no response from
the maintainer, one can ofcourse also merge the change so that things go
on. If the maintainer does not respond at all, one could even ask to
take over if one wants.
If someone repeatedly tries to "abuse" the rights to force their own
development against the will of the "main" maintainer, they could be
excluded from the team (and lose write access).
This is a bit like Debian handles its team maintainance, and
pragmatically it works quite good. Everyone can join Debian team
maintainance, and it is really rarely (or never) abused.
> - Can we get existing packages with history to github (fossil2git,
> svn2git,..)
> - Should we use github as mirror to the outside and use the code from
> elsewhere
leads to forks of the Github repository without feeding back the
changes to the author.
> - Can we build and provide binaries for different platforms
The other -- very useful -- thing is that one can automatically run
tests for the package on different platforms (Linux, MacOS,
Windows). This includes "usual" unit tests, but also checking the code
style and similar. And this is done on Pull Requests as well, therefore
for a maintainer it is easy to see whether a change breaks something.
With some work, one could even auto-build the binaries for all platforms
and attach them to the release.
Best regards
Ole
rene
Jun 11, 2021, 2:51:23 AM6/11/21
to
Оlе Ѕtrеісhеr schrieb am Donnerstag, 10. Juni 2021 um 17:15:49 UTC+2:
> Hi rene, EL,
No and yes :) It contains a lot of packages with patches and build for android, linux, windows,..
> > - Who will be maintainer
> The idea would be to create an "organization" in Github, which is
> maintained by a team of reputable people. "Maintained" means mainly that
> they create (empty) repositories on request for those who want to
> maintain their stuff there, and add new members with write access on
> their request.
>
> Then the idea is "community maintainance", i.e. each package has a
> "main" maintainer, but in principle everyone other team member can push
> as well -- but shouldn't, as long as the main maintainer is responsive.
>
> If in doubt, changes should always go through a Pull Request instead of
> directly to the main branch, even if one has write access. Pull requests
> are always the way to discuss the changes. If there is no response from
> the maintainer, one can ofcourse also merge the change so that things go
> on. If the maintainer does not respond at all, one could even ask to
> take over if one wants.
>
> If someone repeatedly tries to "abuse" the rights to force their own
> development against the will of the "main" maintainer, they could be
> excluded from the team (and lose write access).
>
> This is a bit like Debian handles its team maintainance, and
> pragmatically it works quite good. Everyone can join Debian team
> maintainance, and it is really rarely (or never) abused.
Interesting. Could you make a page on the wiki with this?
May be with a section to collect people who would join.
Regards
René
> Hi rene, EL,
No and yes :) It contains a lot of packages with patches and build for android, linux, windows,..
> > - Who will be maintainer
> The idea would be to create an "organization" in Github, which is
> maintained by a team of reputable people. "Maintained" means mainly that
> they create (empty) repositories on request for those who want to
> maintain their stuff there, and add new members with write access on
> their request.
>
> Then the idea is "community maintainance", i.e. each package has a
> "main" maintainer, but in principle everyone other team member can push
> as well -- but shouldn't, as long as the main maintainer is responsive.
>
> If in doubt, changes should always go through a Pull Request instead of
> directly to the main branch, even if one has write access. Pull requests
> are always the way to discuss the changes. If there is no response from
> the maintainer, one can ofcourse also merge the change so that things go
> on. If the maintainer does not respond at all, one could even ask to
> take over if one wants.
>
> If someone repeatedly tries to "abuse" the rights to force their own
> development against the will of the "main" maintainer, they could be
> excluded from the team (and lose write access).
>
> This is a bit like Debian handles its team maintainance, and
> pragmatically it works quite good. Everyone can join Debian team
> maintainance, and it is really rarely (or never) abused.
May be with a section to collect people who would join.
Regards
René
EL
Jun 11, 2021, 3:02:05 AM6/11/21
to
Hello Ole,
> The idea would be to create an "organization" in Github, which is
> maintained by a team of reputable people. "Maintained" means mainly that
> they create (empty) repositories on request for those who want to
> maintain their stuff there, and add new members with write access on
> their request.
>
> Then the idea is "community maintainance", i.e. each package has a
> "main" maintainer, but in principle everyone other team member can push
> as well -- but shouldn't, as long as the main maintainer is responsive.
>
> If in doubt, changes should always go through a Pull Request instead of
> directly to the main branch, even if one has write access. Pull requests
> are always the way to discuss the changes. If there is no response from
> the maintainer, one can ofcourse also merge the change so that things go
> on. If the maintainer does not respond at all, one could even ask to
> take over if one wants.
>
> If someone repeatedly tries to "abuse" the rights to force their own
> development against the will of the "main" maintainer, they could be
> excluded from the team (and lose write access).
Sounds good. But could not https://github.com/tcltk be that
organization, instead of creating a new one? I am afraid that creating a
new one adds more confusion.
>> - Can we get existing packages with history to github (fossil2git,
>> svn2git,..)
>
> Yes.
>
>> - Should we use github as mirror to the outside and use the code from
>> elsewhere
>
> That is not the idea, and does not healp to team-maintain. It rather
> leads to forks of the Github repository without feeding back the
> changes to the author.
We both could start as the initial maintainers and gradually import
abandoned Tcl extensions, as they come to mind. After confirming with
their old maintainers of course, if that is ok... as long as we find the
old maintainers. We could give the packages a new home on github, review
pull requests that might come from other users, and occasionally build
releases. I think that this could be doable, time-wise, even the
releases build step if that one can be automated.
What do you think? We could see if that works out, not much to loose
here if it doesn't. Maybe other Tcl'ers join the effort in the future,
as I've seen there are quite a few on github (including long standing
members of the Tcl community and the TCT).
First step (after sorting out the organization thing) would be to find
out which packages meet the criteria of being more or less abandoned,
and worthwhile to import there. I do for instance have some repos on my
private github account which fall in that category and which I would be
willing to contribute.
>> - Can we build and provide binaries for different platforms
>
> One can attach binary files to a release which then can be downloaded.
>
> The other -- very useful -- thing is that one can automatically run
> tests for the package on different platforms (Linux, MacOS,
> Windows). This includes "usual" unit tests, but also checking the code
> style and similar. And this is done on Pull Requests as well, therefore
> for a maintainer it is easy to see whether a change breaks something.
>
> With some work, one could even auto-build the binaries for all platforms
> and attach them to the release.
That sounds absolutely useful, indeed :). But I have no experience in
getting this started on github, so I'd personally leave it as a second
step. It would however be crucial for making releases of aggregated
contributions, which I wouldn't want to do manually.
Have you worked with the github automated build services already?
--
EL
> The idea would be to create an "organization" in Github, which is
> maintained by a team of reputable people. "Maintained" means mainly that
> they create (empty) repositories on request for those who want to
> maintain their stuff there, and add new members with write access on
> their request.
>
> Then the idea is "community maintainance", i.e. each package has a
> "main" maintainer, but in principle everyone other team member can push
> as well -- but shouldn't, as long as the main maintainer is responsive.
>
> If in doubt, changes should always go through a Pull Request instead of
> directly to the main branch, even if one has write access. Pull requests
> are always the way to discuss the changes. If there is no response from
> the maintainer, one can ofcourse also merge the change so that things go
> on. If the maintainer does not respond at all, one could even ask to
> take over if one wants.
>
> If someone repeatedly tries to "abuse" the rights to force their own
> development against the will of the "main" maintainer, they could be
> excluded from the team (and lose write access).
organization, instead of creating a new one? I am afraid that creating a
new one adds more confusion.
>> - Can we get existing packages with history to github (fossil2git,
>> svn2git,..)
>
> Yes.
>
>> - Should we use github as mirror to the outside and use the code from
>> elsewhere
>
> That is not the idea, and does not healp to team-maintain. It rather
> leads to forks of the Github repository without feeding back the
> changes to the author.
abandoned Tcl extensions, as they come to mind. After confirming with
their old maintainers of course, if that is ok... as long as we find the
old maintainers. We could give the packages a new home on github, review
pull requests that might come from other users, and occasionally build
releases. I think that this could be doable, time-wise, even the
releases build step if that one can be automated.
What do you think? We could see if that works out, not much to loose
here if it doesn't. Maybe other Tcl'ers join the effort in the future,
as I've seen there are quite a few on github (including long standing
members of the Tcl community and the TCT).
First step (after sorting out the organization thing) would be to find
out which packages meet the criteria of being more or less abandoned,
and worthwhile to import there. I do for instance have some repos on my
private github account which fall in that category and which I would be
willing to contribute.
>> - Can we build and provide binaries for different platforms
>
> One can attach binary files to a release which then can be downloaded.
>
> The other -- very useful -- thing is that one can automatically run
> tests for the package on different platforms (Linux, MacOS,
> Windows). This includes "usual" unit tests, but also checking the code
> style and similar. And this is done on Pull Requests as well, therefore
> for a maintainer it is easy to see whether a change breaks something.
>
> With some work, one could even auto-build the binaries for all platforms
> and attach them to the release.
getting this started on github, so I'd personally leave it as a second
step. It would however be crucial for making releases of aggregated
contributions, which I wouldn't want to do manually.
Have you worked with the github automated build services already?
--
EL
Rolf Ade
Jun 11, 2021, 8:50:44 PM6/11/21
to
rene <r.zau...@gmail.com> writes:
> This is IMHO a really good question. I already have done some work in BI creation.
> The main problem was always finding the correct source.
>
> Do you know the gutter at https://core.tcl-lang.org/jenglish/gutter/
> Just another attempt to get a central point to get the sources.
>
> Then there is androwish.org. Have a look on it.
Well curated.
rene
Jul 7, 2021, 9:51:50 AM7/7/21
to
Hello Rolf,
True, but imho the OP asked about a place to care about abandoned tcl/tk extensions.
The main problem is often to find the correct/best place to get the sources.
So a common starting place would be great. And the "community maintainance" from Ole sounds also good.
Another possible way would be to put these extensions on the core server. May be even as fossil repos.
And then create links on https://core.tcl-lang.org/index.html.
Currently there are already some extensions under "Other".
Regards
René
The main problem is often to find the correct/best place to get the sources.
So a common starting place would be great. And the "community maintainance" from Ole sounds also good.
Another possible way would be to put these extensions on the core server. May be even as fossil repos.
And then create links on https://core.tcl-lang.org/index.html.
Currently there are already some extensions under "Other".
Regards
René
Nicolas Robert
Jul 23, 2021, 12:30:17 PM7/23/21
to
I find his work fantastic...
A pity as on other languages that a platform or all packages would be mentioned like this
https://github.com/ray2501/Tcl-Related-Link
Nicolas
A pity as on other languages that a platform or all packages would be mentioned like this
https://github.com/ray2501/Tcl-Related-Link
Nicolas
Harald Oehlmann
Jul 28, 2021, 4:44:32 AM7/28/21
to
0 new messages