three good reasons:
* the GetBundle bundle is a solid foundation; * in the community there is no shortage of server-side programming skills and, most of all * we have ten (10!) weeks without an official release, so that we can tinker with BundleForge!
so... why don't we start doing something? :P if there's any amount of python code involved, I'm ready to help!
On Dec 8, 2006, at 7:32 AM, domenico.carbotta@fastwebnet.it domenico.carbotta@fastwebnet.it wrote:
three good reasons:
- the GetBundle bundle is a solid foundation;
- in the community there is no shortage of server-side programming
skills and, most of all
- we have ten (10!) weeks without an official release, so that we
can tinker with BundleForge!
so... why don't we start doing something? :P if there's any amount of python code involved, I'm ready to help!
Agreed. How do you suppose such a thing should work?
I like how the official repo is a single svn server. But if bundleForge is only a single repo, then everyone has access to all of of the bundles.
In case you missed it, I actually already have a quasi-bundleForge now. It was primarily created for the completion stuff, so that non-core committers can still contribute to the BETA releases of the codeComplete bundle. With the idea that once it's done it'll go into core.
SVN http://projects.subtlegradient.com/tmcompletion_svn/
RSS SVN LOG http://trippledoubleyou.subtlegradient.com/textmate/ tmcompletion_svnlog.rss
BASECAMP http://tmcompletion.projectpath.com login: anonymous pass: nopass
If you want access to contribute, email me or reply to this message
thomas Aylott — design42 — subtleGradient — CrazyEgg
I already started to do some brainstorming about "BundleForge" and also started to code a bit. And also the GetBundle will get remake, maybe it will be a standalone app, but still will have a small Bundle to install other Bundles quickly.
2006/12/8, thomas Aylott oblivious@subtlegradient.com:
On Dec 8, 2006, at 7:32 AM, domenico.carbotta@fastwebnet.it domenico.carbotta@fastwebnet.it wrote:
three good reasons:
- the GetBundle bundle is a solid foundation;
- in the community there is no shortage of server-side programming skills
and, most of all
- we have ten (10!) weeks without an official release, so that we can
tinker with BundleForge!
so... why don't we start doing something? :P if there's any amount of python code involved, I'm ready to help!
Agreed. How do you suppose such a thing should work?
I like how the official repo is a single svn server. But if bundleForge is only a single repo, then everyone has access to all of of the bundles.
In case you missed it, I actually already have a quasi-bundleForge now. It was primarily created for the completion stuff, so that non-core committers can still contribute to the BETA releases of the codeComplete bundle. With the idea that once it's done it'll go into core.
SVN http://projects.subtlegradient.com/tmcompletion_svn/
RSS SVN LOG http://trippledoubleyou.subtlegradient.com/textmate/tmcompletion_svnlog.rss
BASECAMP http://tmcompletion.projectpath.com login: anonymous pass: nopass
If you want access to contribute, email me or reply to this message
thomas Aylott — design42 — subtleGradient — CrazyEgg
For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate
On Dec 8, 2006, at 10:52 AM, thomas Aylott wrote:
Agreed. How do you suppose such a thing should work?
I like that it's Subversion based now. I ask myself: What do we want that we don't currently have?
The main thing that comes to mind (which was recently discussed on this list) is some sort of description and/or documentation for each available bundle. I also would advocate some additional meta-data on top of that. For example, it would be nice to have attributes that allow you to see…
* Bundles that are considered obsolete * Bundles that the developer considers to be a work in progress and possibly not ready for prime time. "BETA", for lack of a better word. * Bundles that are included with TextMate by default (and of these, perhaps even show which have been updated since the last TextMate release?).
It might also be nice to know who "works on" each bundle, but I'm wondering if we should purposely not make that information available to those without "commit" access. The reason being that if you don't know who does a particular bundle and are forced to take your question to the entire list, there are a lot more eyes on the problem and we'll probably end up with a more elegant solution in the end.
I realize there a folks with an aversion to Subversion :), so should we do something to accommodate them or make them get with the program? I was thinking we could have a post-commit hook that would tar up a working copy of each bundle as it's updated. And maybe we strip out the `.svn` directories first or maybe we don't. Seems to me that if it's checked out a certain way and we leave the `.svn` dirs in place, the person who downloads the tarball version could run `svn update` on it at some later point if they wanted to. This would of course be unrealistic if we stick with one huge repository for everything (see below).
I'd be curious to hear what those with commit access think is missing.
I like how the official repo is a single svn server. But if bundleForge is only a single repo, then everyone has access to all of of the bundles.
From what I know of Subversion, a single server with multiple repositories could be "transparent" to all the clients doing checkouts, but it could be an access control nightmare depending on how fine-grained you want to make it. Is there a reason that there's currently only one repository?
--- Rob McBroom http://www.skurfer.com/ I didn't "switch" to Apple... my OS did.
The point why i (and i think Allan would agree) is to make contributing Bundles as easy as possible and not force people to learn Subversion. Another thing why i want to do something like that to make the GetBundle work with Bundles outside the Official Repository.
2006/12/8, Rob McBroom textmate@skurfer.com:
On Dec 8, 2006, at 10:52 AM, thomas Aylott wrote:
Agreed. How do you suppose such a thing should work?
I like that it's Subversion based now. I ask myself: What do we want that we don't currently have?
The main thing that comes to mind (which was recently discussed on this list) is some sort of description and/or documentation for each available bundle. I also would advocate some additional meta-data on top of that. For example, it would be nice to have attributes that allow you to see…
- Bundles that are considered obsolete
- Bundles that the developer considers to be a work in progress
and possibly not ready for prime time. "BETA", for lack of a better word.
- Bundles that are included with TextMate by default (and of
these, perhaps even show which have been updated since the last TextMate release?).
It might also be nice to know who "works on" each bundle, but I'm wondering if we should purposely not make that information available to those without "commit" access. The reason being that if you don't know who does a particular bundle and are forced to take your question to the entire list, there are a lot more eyes on the problem and we'll probably end up with a more elegant solution in the end.
I realize there a folks with an aversion to Subversion :), so should we do something to accommodate them or make them get with the program? I was thinking we could have a post-commit hook that would tar up a working copy of each bundle as it's updated. And maybe we strip out the `.svn` directories first or maybe we don't. Seems to me that if it's checked out a certain way and we leave the `.svn` dirs in place, the person who downloads the tarball version could run `svn update` on it at some later point if they wanted to. This would of course be unrealistic if we stick with one huge repository for everything (see below).
I'd be curious to hear what those with commit access think is missing.
I like how the official repo is a single svn server. But if bundleForge is only a single repo, then everyone has access to all of of the bundles.
From what I know of Subversion, a single server with multiple repositories could be "transparent" to all the clients doing checkouts, but it could be an access control nightmare depending on how fine-grained you want to make it. Is there a reason that there's currently only one repository?
Rob McBroom http://www.skurfer.com/ I didn't "switch" to Apple... my OS did.
For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate
-
domenico.carbotta＠fastwebnet.it -
Rob McBroom -
Sebastian Graessl -
thomas Aylott