From: Tom R. <Tom...@nc...> - 2001-09-30 20:36:29
|
Tom Roche <Tom...@nc...> wrote: >> * create projects Actually, I should have said "packages"; apologies for confusion. >> "tramp-stable" (for believed-good code) and "tramp-development" >> (for ... other code) Kai.Grossjohann@CS.Uni-Dortmund.DE Fri, 28 Sep 2001 14:04:28 +0200 > I tried to fork into a stabe and a development release, but it was > quite a bit of a hassle. Yes, and IMHO SourceForge should fix that, hence my request. > In the end, I didn't really have two different versions anyway What about tramp2? I guess this is a good time to discuss the <usage? relationship? status?> of the various files in the project. My initial idea was that: - tramp-stable would include some agreed-upon set of versions of the lisp/tramp-*.el, as well as "version-neutral stuff" (related elisp (e.g. base64.el), /texi, and /test) - tramp-development would include the latest versions of lisp/tramp2-*.el, as well as the "version-neutral stuff" So perhaps my first question should be: what's the "version-neutral stuff"? Then: what's the status of the tramp2-*.el? <rearranged> > Then people without CVS could have access to the current sources. Actually, they do: e.g. if one wants tramp-util.el, one can go to (broken for mail) http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/tramp/tramp/lisp/ tramp-util.el and download the version of one's choice ... which is nice if someone just needs a few files to fix something, but would be quite tedious for downloading an entire package. > Or maybe you mean that from time to time a stable version should > be released, but the development version is a nightly snapshot or > something like that? That would be cool. I didn't think about that, but that _is_ a good idea. I guess what I need now is * for SourceForge to fix the package-creation problem. Note that it's "in the pipeline" at http://sourceforge.net/tracker/?func=detail&atid=200001&aid=465857 &group_id=1 * to know, what's "the development version"? Is there still a tramp1 (== tramp-*.el) and a tramp2? Are both still being actively developed? If so, then perhaps there should be 4 packages: (tramp1, tramp2) x (stable, development)? Then development versions would be the "nightly" (or as-changed) snapshots. FWIW, Tom...@nc... |
From: Tom R. <Tom...@nc...> - 2001-10-01 19:10:39
|
Kai.Grossjohann@CS.Uni-Dortmund.DE Fri, 28 Sep 2001 14:04:28 +0200 >> I tried to fork into a stabe and a development release, but it was >> quite a bit of a hassle. Kai.Grossjohann@CS.Uni-Dortmund.DE Mon, 01 Oct 2001 11:46 > This was before Tramp was moved to SourceForge. The hassle does not > have anything to do with SourceForge, it's the fact that there are > two branches in the sources. Ah: one more area of confusion: the difference between branching in CVS and packages in SF. > What happens if the two versions are not in sync and a bad problem > is reported? Then the fix needs to be applied to both versions, > which is more work than just applying it to one version. Umm ... it's hard for me to say, without actually having exercised SF's packaging functionality, but I suspect this wouldn't actually be a problem: * I would hope that there would be some "proof period" for the stable code. I.e. the rule should be that nothing goes into a stable package that's less than n days old. (Any candidates for n? Just offhand I'd say n = 14.) * SF packages are essentially just tar- or zipballs (see https://sourceforge.net/docman/display_doc.php?docid=6445&group_id=1 ) so releasing a package involves essentially just snapshotting (identifying versions of files suitable for the package) and twiddling. In case of the "worst-case scenario" above, just rollback to pre-bad-problem versions. This can be done outside of CVS: > in the end, I ended up with just making snapshots of the devel > branch and calling them stable. And this is something we can do > without having two branches, right? Correct ... I think :-) Tom Roche <Tom...@nc...> writes: >> What about tramp2? I guess this is a good time to discuss the >> <usage? relationship? status?> of the various files in the project. Kai.Grossjohann@CS.Uni-Dortmund.DE Mon, 01 Oct 2001 11:47:56 +0200 > Well, Daniel started to work on tramp2*.el, and I like what's in it. > Alas, some features are missing. So when I fix a bug I go to the > other version and fix stuff there. This is just laziness on my part; > I know that the right way to proceed is to just finish Daniel's > rewrite. > So, the status of tramp2*.el is unclear. Maybe Daniel wants to chime > in here? Indeed: is he on the new list? Perhaps tramp2 would make a good subproject for SF's Task Manager? See http://sourceforge.net/pm/?group_id=34545 FWIW, Tom...@nc... |
From: Kai.Grossjohann@CS.Uni-Dortmund.DE (K. ) - 2001-10-01 22:37:42
|
Tom Roche <Tom...@nc...> writes: > Kai.Grossjohann@CS.Uni-Dortmund.DE Fri, 28 Sep 2001 14:04:28 +0200 > >> What happens if the two versions are not in sync and a bad problem >> is reported? Then the fix needs to be applied to both versions, >> which is more work than just applying it to one version. > > Umm ... it's hard for me to say, without actually having exercised > SF's packaging functionality, but I suspect this wouldn't actually be > a problem: > > * I would hope that there would be some "proof period" for the stable > code. I.e. the rule should be that nothing goes into a stable > package that's less than n days old. (Any candidates for n? Just > offhand I'd say n = 14.) > > * SF packages are essentially just tar- or zipballs (see > > https://sourceforge.net/docman/display_doc.php?docid=6445&group_id=1 > > ) so releasing a package involves essentially just snapshotting > (identifying versions of files suitable for the package) and > twiddling. > > In case of the "worst-case scenario" above, just rollback to > pre-bad-problem versions. This can be done outside of CVS: So your suggestion is to proceed as follows: When we think that it's a good time, we make a snapshot from CVS and call it a tentative release. Then people try that for a while, and if they find it works, we call it a real release. Yeah, that would be easy, and we could add tags to CVS to keep track of what has been released. And stuff. Good idea! > >> So, the status of tramp2*.el is unclear. Maybe Daniel wants to chime >> in here? > > Indeed: is he on the new list? Yep. > Perhaps tramp2 would make a good subproject for SF's Task Manager? See > > http://sourceforge.net/pm/?group_id=34545 This gives me an empty list of subprojects. I skimmed the list of documentation but didn't find anything which looked promising to explain what is a subproject. What is it? kai -- Abort this operation? [OK] [Cancel] |
From: Tom R. <Tom...@nc...> - 2001-10-03 02:34:47
|
Kai Gro=DFjohann Tue, 02 Oct 2001 00:36:58 +0200 > So your suggestion is to proceed as follows: > When we think that it's a good time, we make a snapshot from CVS and > call it a tentative release. Then people try that for a while, and > if they find it works, we call it a real release. Yes: if it's stable, we call it "stable" :-) And we use the release mechanism to make it easier to retrieve: this encourages new/casual users to exercise _that_. And, if someone sends a tramp-bug, and they're using devel code, if all else fails you tell them to download the stable code and see if that makes it go away :-) Tom Roche <Tom...@nc...> writes: >> Perhaps tramp2 would make a good subproject for SF's Task Manager? >> See >> http://sourceforge.net/pm/?group_id=3D34545 > This gives me an empty list of subprojects. Better than me: I click "Task Manager Admin" and get https://sourceforge.net/pm/admin/?group_id=3D34545 > Permission Denied > This project's administrator will have to grant you permission to > view this page. Hmm ... do I have permissions to make packages? Back to the present topic: Kai Gro=DFjohann Tue, 02 Oct 2001 00:36:58 +0200 > I skimmed the list of documentation but didn't find anything which > looked promising to explain what is a subproject. That appears to be because ... it's undocumented :-) > What is it? It seems pretty intuitive to me: it's part of their way of administering tasks (being part of Task Manager :-) I guess the best way to illustrate it is to view a project that has subprojects. Among which is SF itself; this URI works for me: https://sourceforge.net/pm/?group_id=3D1 > Project: SourceForge=20 > Task Manager: Subprojects And Tasks > Subproject List | Reporting | Admin > Choose a Subproject and you can browse/edit/add tasks to it. > 3.0 Development Cycle=20 > Oct-Jan - Development Schedule =20 > To Do List > Features that we want to add to the codebase. > Assignable to anyone. So choose "To Do List": > Project SourceForge Task Manager=20 > Browse My Tasks > Browse Tasks by User and/or Status: > No Matching Tasks found Doh! Gotta twiddle the pulldowns: set the latter two to "Any", and hit "Browse": I get a happy table > Browsing Custom Task List In To Do List with columns > Task ID > Summary > Start Date > End Date > Percent Complete So, presuming we had "tramp1" and "tramp2" subprojects: if you find a bug, you could=20 * fix it in tramp1, or make it a task in tramp1 for someone else to do * make it a task in tramp2 for someone else to do. It doesn't _fix_ the bugs, but it should help manage them. HTH, Tom...@nc... |
From: Tom R. <Tom...@nc...> - 2001-10-05 01:52:53
|
Tom Roche <Tom...@nc...> Thu, 04 Oct 2001 20:51:40 -0400 > OK, so I made three packages (feel free to add/rename/delete/ > whatever): > tramp-stable > tramp1-development > tramp2-development Now, how to populate them? My initial guesses are: tramp-stable: - All tramp/*, latest versions (Necessary? I'm thinking that we might wanna keep tramp-stable "lean," for folks on slow downloads.) - All tramp/lisp, latest versions, EXCEPT no tramp2* Are all the latest versions stable-worthy? Also I dunno about the "no tramp2*" My idea is that, at this point, they don't really _do_ anything, and could only cause problems. Your thoughts? (The leanness argument also applies, if valid.) - No tramp/test (unnecessary) - All tramp/texi, latest versions tramp2-development: - All everything, latest versions. Presumably folks might want to be able to see/borrow tramp1 code, and leanness doesn't apply to devel. tramp1-development: - All everything, latest versions. Presumably folks might want to be able to see/borrow tramp2 code, and leanness doesn't apply to devel. Does this sound right? TIA, Tom...@nc... |
From: Kai.Grossjohann@CS.Uni-Dortmund.DE (K. ) - 2001-10-05 10:14:04
|
Tom Roche <Tom...@nc...> writes: > Tom Roche <Tom...@nc...> Thu, 04 Oct 2001 20:51:40 -0400 >> OK, so I made three packages (feel free to add/rename/delete/ >> whatever): > >> tramp-stable >> tramp1-development >> tramp2-development > > Now, how to populate them? May I suggest tramp-stable to contain everything except the tramp2* files, and the others to contain all files? Is somebody willing to augment the Makefile to do this? And then we need some mechanism for uploading stuff from time to time. And maybe also a person to do that? Any takers? kai -- Abort this operation? [OK] [Cancel] |
From: Kai.Grossjohann@CS.Uni-Dortmund.DE (K. ) - 2001-10-05 10:15:38
|
Tom Roche <Tom...@nc...> writes: > Are all the latest versions stable-worthy? I've only been doing bugfixes (very few) for a while, so the current version should be the best candidate for stable. > Also I dunno about the "no tramp2*" My idea is that, at this point, > they don't really _do_ anything, and could only cause problems. Your > thoughts? (The leanness argument also applies, if valid.) I wonder what Daniel says? I figure since tramp2 is his baby, we should do what he wants. kai -- Abort this operation? [OK] [Cancel] |
From: Tom R. <Tom...@nc...> - 2001-10-08 01:18:13
|
Kai Gro=DFjohann Sun, 07 Oct 2001 12:04:25 +0200 >> Ah, after reading the FRS documentation, I now see that one uses >> anon ftp to upload the file to the /incoming directory And unfortunately it does not yet allow scp there. > I've got something in Makefile which uses scp to copy a tarball to the > web space. There's a link to that tarball from the Tramp manual. > Maybe this stuff should be changed to use the FRS from SourceForge? Why modify the current procedure? If you've got that working, and automagically, I vote to leave it as it is. When we get FRS working as well, we can add support that to the Makefile. > Is it possible to make it as automatic as what I now have? I dunno: that is what I posted to Alexandre Duret-Lutz about. Certainly if this _has_ been implemented, it has not yet been documented. Meanwhile: perhaps you could hack your Makefile to also * make a tramp-stable.tar.gz (i.e. no test/ or lisp/tramp2*) * ftp it and tramp.tar.gz to ano...@up...:/incoming (bleah! there's gotta be away to just copy across their filesystems...) ? Then, I could periodically release (presumably after notification by tramp-checkins) merely by accessing the FRS and manually twiddling: the files would already be in place. Err ... no: apparently when you attach a file in the FRS it disappears. So could you copy tramp.tar.gz as both tramp1-development.tar.gz and tramp2-development.tar.gz ? Should work until we find a better way ... YMMV, Tom...@nc... |
From: Kai.Grossjohann@CS.Uni-Dortmund.DE (K. ) - 2001-10-08 07:23:29
|
Tom Roche <Tom...@nc...> writes: > Meanwhile: perhaps you could hack your Makefile to also > > * make a tramp-stable.tar.gz (i.e. no test/ or lisp/tramp2*) Done. > * ftp it and tramp.tar.gz to ano...@up...:/incoming > (bleah! there's gotta be away to just copy across their > filesystems...) Does that work without entering a passwd? > ? Then, I could periodically release (presumably after notification by > tramp-checkins) merely by accessing the FRS and manually twiddling: > the files would already be in place. > > Err ... no: apparently when you attach a file in the FRS it > disappears. So could you copy tramp.tar.gz as both > tramp1-development.tar.gz and tramp2-development.tar.gz ? Done. kai -- Linux provides a nice `poweroff' command, but where is `poweron'? |
From: Tom R. <Tom...@nc...> - 2001-10-08 01:38:13
|
Kai Gro=DFjohann Sun, 07 Oct 2001 12:04:25 +0200 > I've got something in Makefile which uses scp to copy a tarball to > the web space. There's a link to that tarball from the Tramp manual. > Maybe this stuff should be changed to use the FRS from SourceForge? > Is it possible to make it as automatic as what I now have? I have submitted a Feature Request (URI broken for mail) https://sourceforge.net/tracker/index.php? func=3Ddetail&aid=3D468890&group_id=3D1&atid=3D350001 FWIW, Tom...@nc... |
From: Tom R. <Tom...@nc...> - 2001-10-08 21:02:03
|
>> * ftp it and tramp.tar.gz to >> ano...@up...:/incoming (bleah! there's gotta >> be a way to just copy across their filesystems...) Kai Gro=DFjohann Mon, 08 Oct 2001 09:22:46 +0200 > Does that work without entering a passwd? With .netrc > machine upload.sourceforge.net > login anonymous > password tom...@nc... or even .netrc > machine upload.sourceforge.net > login anonymous > password=20 I can login without entering a passwd. Is that enough? HTH, Tom...@nc... |
From: Kai.Grossjohann@CS.Uni-Dortmund.DE (K. ) - 2001-10-10 12:02:05
|
Tom Roche <Tom...@nc...> writes: >>> * ftp it and tramp.tar.gz to >>> ano...@up...:/incoming (bleah! there's gotta >>> be a way to just copy across their filesystems...) >=20 > Kai Gro=DFjohann Mon, 08 Oct 2001 09:22:46 +0200 >> Does that work without entering a passwd? >=20 > With [...] I can login without entering a passwd. Is that enough? Sure. Thanks! kai --=20 Linux provides a nice `poweroff' command, but where is `poweron'? |
From: Kai.Grossjohann@CS.Uni-Dortmund.DE (K. ) - 2001-10-01 09:47:07
|
Tom Roche <Tom...@nc...> writes: > Tom Roche <Tom...@nc...> wrote: > > Kai.Grossjohann@CS.Uni-Dortmund.DE Fri, 28 Sep 2001 14:04:28 +0200 > > I tried to fork into a stabe and a development release, but it was >> quite a bit of a hassle. > > Yes, and IMHO SourceForge should fix that, hence my request. This was before Tramp was moved to SourceForge. The hassle does not have anything to do with SourceForge, it's the fact that there are two branches in the sources. What happens if the two versions are not in sync and a bad problem is reported? Then the fix needs to be applied to both versions, which is more work than just applying it to one version. Maybe the word `hassle' is too strong. But in the end, I ended up with just making snapshots of the devel branch and calling them stable. And this is something we can do without having two branches, right? kai -- Abort this operation? [OK] [Cancel] |
From: Kai.Grossjohann@CS.Uni-Dortmund.DE (K. ) - 2001-10-01 09:48:38
|
Tom Roche <Tom...@nc...> writes: > What about tramp2? I guess this is a good time to discuss the <usage? > relationship? status?> of the various files in the project. Well, Daniel started to work on tramp2*.el, and I like what's in it. Alas, some features are missing. So when I fix a bug I go to the other version and fix stuff there. This is just laziness on my part; I know that the right way to proceed is to just finish Daniel's rewrite. So, the status of tramp2*.el is unclear. Maybe Daniel wants to chime in here? kai -- Abort this operation? [OK] [Cancel] |