Menu
▾
▴
tcllib-devel
|
From: Harald O. <har...@el...> - 2011-02-15 07:54:06
|
Am 15.02.2011 02:10, schrieb Andreas Kupries: > On 2/14/2011 4:36 PM, Will Duquette wrote: >> It probably makes sense to adopt whatever is adopted for the Tcl core. > > Gerald Lester made the same point in direct mail. > Same opinion, tcllib is tcl - keep it close. Sorry Andreas, I have checked in bwidget stuff yesterday. -Harald |
|
From: Donald G P. <don...@ni...> - 2011-02-15 14:34:10
|
Andreas Kupries wrote: > One last issue. As (1) shows, we have lots of subprojects. Seven. While these > are all handled by a single CVS repository directory hierarchy, when going to > DVCS we should really split them up, each as their own XXX repository. One of > them, tclbench, should possibly even migrate out of the tcllib more to the core > itself, given that it is the core whose performance this project is testing. Something to consider, if only briefly... One guideline that came out of the chat discussion on these matters is "Separately releaseable things should have separate repositories" So, if there's ever a dream to make separate releases of the packages that make up tcllib, that task will be far easier if they each go into their own repositories now, as part of this transition. (*) OTOH, if that's never going to happen, then that would be significant work for no benefit. I can support either choice, but I mention the question so the choice is made actively, not passively. (*) Or to support the ability to take a select subset of tcllib for re-distribution under tcl/pkgs/ -- | Don Porter Mathematical and Computational Sciences Division | | don...@ni... Information Technology Laboratory | | http://math.nist.gov/~DPorter/ NIST | |______________________________________________________________________| |
|
From: Andreas K. <and...@ac...> - 2011-02-15 17:53:41
|
On 2/15/2011 6:33 AM, Donald G Porter wrote: > Andreas Kupries wrote: >> One last issue. As (1) shows, we have lots of subprojects. Seven. While these >> are all handled by a single CVS repository directory hierarchy, when going to >> DVCS we should really split them up, each as their own XXX repository. One of >> them, tclbench, should possibly even migrate out of the tcllib more to the >> core itself, given that it is the core whose performance this project is >> testing. > > Something to consider, if only briefly... > > One guideline that came out of the chat discussion on these matters is > "Separately releaseable things should have separate repositories" > > So, if there's ever a dream to make separate releases of the packages > that make up tcllib, that task will be far easier if they each go into > their own repositories now, as part of this transition. (*) > > OTOH, if that's never going to happen, then that would be significant > work for no benefit. > > I can support either choice, but I mention the question so the choice > is made actively, not passively. > (*) Or to support the ability to take a select subset of tcllib for > re-distribution under tcl/pkgs/ Huh. Yes. A difficult topic. On the one hand, each of the packages inside the tcllib and tklib bundles can, theoretically, be released on its own. On the other hand, the forces which drove the bundling are not really gone. The TEA framework we have is very good for binary packages, and not so much for pure Tcl. With a package consisting of two files (.tcl and pkgIndex) the overhead is high, plus impedance mismatches in the standard code. The bundling allowed us to amortize the cost of maintaining a pseudo-TEA configure/Makefile across many packages. That is still true, I believe. And yes, I am aware that I am possibly opening another can of worms^W^W^Wline of discussion here which is, I believe one of our big pain points. -- Andreas Kupries Senior Tcl Developer ActiveState, The Dynamic Language Experts P: 778.786.1122 F: 778.786.1133 and...@ac... http://www.activestate.com Get insights on Open Source and Dynamic Languages at www.activestate.com/blog |
|
From: Donald G P. <don...@ni...> - 2011-02-15 18:01:58
|
Andreas Kupries wrote: Donald G Porter wrote: >> So, if there's ever a dream to make separate releases of the packages >> that make up tcllib, that task will be far easier if they each go into >> their own repositories now, as part of this transition. (*) Andreas Kupries wrote: > Huh. Yes. A difficult topic. Just a bit more on it. The same issues confront the tcl/library/* subdirs in a Tcl distro. In principle, we can imagine the msgcat, tcltest, opt, http, etc. packages getting released separate from Tcl. And I find something attractive about imagining that's a state we will reach one day. But... ...that's not been the history of these packages, and since a big part of SCM is preserving history, that presses toward keeping things together. Also, those packages are not separately releaseable in their current state. (All the control over `make install` for them is over in Tcl's Makefile, etc.; their tests, docs, and ChangeLogs are all mixed into Tcl's). So for now, I've decided not to do that level of breaking up, and just accept that if breaking apart does become feasible later, it will be a more difficult task to confront then. If similar descriptions cover the tcllib packages, I think it sensible to reach the same conclusion. Contrast with the Thread package, which has a separate history, has made separate releases, and is only now coming into tcl/pkgs. That one made sense to make a separate repository from the beginning. -- | Don Porter Mathematical and Computational Sciences Division | | don...@ni... Information Technology Laboratory | | http://math.nist.gov/~DPorter/ NIST | |______________________________________________________________________| |
|
From: Kevin K. <kk...@ny...> - 2011-02-16 02:21:58
|
On 02/15/2011 01:01 PM, Donald G Porter wrote: > ...that's not been the history of these packages, and since a big part > of SCM is preserving history, that presses toward keeping things > together. > > Also, those packages are not separately releaseable in their current > state. (All the control over `make install` for them is over in Tcl's > Makefile, etc.; their tests, docs, and ChangeLogs are all mixed into > Tcl's). > > So for now, I've decided not to do that level of breaking up, and just > accept that if breaking apart does become feasible later, it will be a > more difficult task to confront then. And not even *much* more difficult. It's easy to *extract* history. What's insanely difficult is to *merge* history. Which is what we face in any CVS->DVCS conversion; CVS maintains all history on the individual files, and we're trying to reconstruct coherent changesets and branch histories from the histories of the files. Once you have changesets, it's easy to filter out only those changesets that affect a given set of files and lift them out. (Not trivial, but much easier than a CVS conversion.) -- 73 de ke9tv/2, Kevin |
|
From: Pat T. <pat...@us...> - 2011-02-17 05:56:03
|
Only the tcl community would agonize about this. Anyone else would be picking between bzr/hg/git. If we use git then someone used to using hg can use hg-git and keep using hg even with a git backend. There is a similar bzr-git shim for people who like using bzr (wierd though that might seem). Anyway - I agree they should get split into multiple repos. The only reason tcllib,tklib,tclapps etc are together was administration of the users (and the bug trackers to a lesser extent). -- Pat Thoyts http://www.patthoyts.tk/ PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X