tapper-pm-devel Mailing List for Tapper Package Manager
Status: Planning
Brought to you by:
nix-dev
Menu
▾
▴
tapper-pm-devel — Development list
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(11) |
Nov
|
Dec
|
|---|
|
From: Dag R. S. <con...@du...> - 2005-10-21 22:07:19
|
So yeah, hacked up a rudimentary draft of the daemon now. CVS repository is live as well! The branch is called tap-daemon, you can browse it by anoncvs, or view it online; http://cvs.sourceforge.net/viewcvs.py/tapper-pm/tap-daemon/ *I've* made a chief decision to implement tapper/tapd in Python and not C++ as originally intended. Python is nearly enterprise now, or perhaps it's been enterprise for a long time, who knows? Also it gives extremely rapid development, which is always lovely. ;) Perhaps the C/C++ daemon can be written later, if someone has such urges... Cheers, Dag Rune Sneeggen(ni...@du...) --- Tapper Package Manager (http://sourceforge.net/projects/tapper-pm/) --> Do you want to miss the fun? :o |
|
From: junkdashawn <jun...@gm...> - 2005-10-17 17:08:02
|
Also what languages would we like to use? I was thinking 1. Python alone. 2. C++/Python I say Python alone since it will cut down on the development time. I also feel it's better to stick with one language. It also can call c libraries already so there would be no gain in C++ besides speed. That's another debate though. Shawn Dag Rune Sneeggen wrote: > So, how does your scheduals look in the near future? > Should I start giving project memberships so that we can set up cvs > and start doing some work? > > To summarize a bit, if this is allright with ya'll; > 1. CVS will be used, simply because it's easier to submit patches and > keep version control. > 2. GNU coding standards, as Shawn made a pretty good argument for > that. And Jason didn't really have a strong sentiment? > > Shawn talked about wanting to make some diagrams? Feel free hehe... > I can get some drafting done with AnyFile pretty soon I suspect. |
|
From: Dag R. S. <con...@du...> - 2005-10-17 15:22:35
|
So, how does your scheduals look in the near future? Should I start giving project memberships so that we can set up cvs and start doing some work? To summarize a bit, if this is allright with ya'll; 1. CVS will be used, simply because it's easier to submit patches and keep version control. 2. GNU coding standards, as Shawn made a pretty good argument for that. And Jason didn't really have a strong sentiment? Shawn talked about wanting to make some diagrams? Feel free hehe... I can get some drafting done with AnyFile pretty soon I suspect. -- Cheers, Dag Rune Sneeggen(ni...@du...) --- Tapper Package Manager (http://sourceforge.net/projects/tapper-pm/) --> Do you want to miss the fun? :o |
|
From: Asheley L. <jun...@gm...> - 2005-10-13 18:07:49
|
I say use GNU coding standards since it is more widely used. I don't know about complete documentation before starting a project. In my experience it never turns out the way your first document says it should work. I say a list of goals and features is better then we decide which features go into releases. After we pick the release feature set we should draft class diagrams and any standard interfaces that the classes should need to communicate with each other then split the classes up amongst the developers. Shawn - Hide quoted text - On 10/13/05, Dag Rune Sneeggen <con...@du...> wrote: > > Any File wrote: > > ----- Original Message ----- > > From: "Dag Rune Sneeggen" <con...@du...> > > Subject: [Tapper-pm-docteam] Getting this party started! > > Date: Wed, 12 Oct 2005 23:48:41 +0200 > > > > > >>As soon as I get my new domain registered, this should be replaced > >>with something more useful and tidy. > > > > > > What domain name would you like? > I'll be buying nixdev.io <http://nixdev.io/>, sort of fallen in love with > the whole .io domain. It opened for public regs not long ago hehe. > Input/Output? Get it, hehe... > > > > There is also the possibility of using the sourceforge website at > http://tapper-pm.sourceforge.net/ in the meantime. > > > > > >>Anything we'd like to see on the soon-to-come page? Do we want a > >>wiki or more static? Or...? > > > > > > I am pretty used to wiki (particularry MediaWiki), but I do not think w= e > really need it t the moment. We can also use it but it would be not so > useful. Wiki are useful when everybody on the web should be able to edit = the > page or when you need some feature it proviedes (e.g. to retrive previous > version). Untill we are a very small group of develepors any type of syst= em > that allow as to publish (in any way) can works enought. > Perhaps I'll set up something like Plone or drupal soon-ish. Quite decent > systems... > > > > > >>But concerning the actual tapper package manager. As for now, > >>there's been a lot of thoughts floating around > >>in *my* head mainly. > >>Over the next few posts and discussions, we can get this "set in > >>stone" if you'd like. > > > > > > Yes, it would a good thing to have something written. There is no need > at all that it should be unchangeble thing (if I undestand the meaning of > "set in stone"). A written document about the current situation would be > very important to us to undestand what we shall do. Moreover writing down > thing make them cleare than havingit in mind and the problems and the > solutions that are hidden into the mind came out more easely. > Absolutely, well said. > > > > > >>A different point of view, is with the documentation, or design if you'= d > like. > >>We need to document both the actual layout and workings of the > >>*handling* of packages locally and on servers. > >>Which formats for what? Where should what be stored? Standards and > >>a set of rules perhaps. > > > > > > Yes, and before writting down the documentation we have to decide how i= t > should work. At this point of the development we can try to use the easie= st > way to be implemented (untill it remains portable and do not cause any > problems). > > > > In my opinion (but I am open to hear anything about that on this) we ca= n > implement as a first step a simple program letting us open the possibilit= y > of using more complicated and powerful solutions. This would give us a > quicker way to have something real on every aspect of the project to be > improved. For instance we can choose an easy to implement and easy to man= age > database, even if not powerful and optimized and improve it or change it = in > the future. If thing are done in modular way (as I suppose it is the bett= er > way to implement a thing that should be portable and standard) there shou= ld > not be many problems in changing things on the way while they are improov= ed. > Yeah, on the one hand, it would be nice if the application development > moved forward very modular. So that things can be compiled > and tested from an early stage. Then again, the coders should have the > freedom to do it anyway they wish. > > > > But actually I have not very clear what should we do. I have not > partecipated to your previous brainstorm, since I have just joined your > project. I hope things will be more clear to me when waht extabilshed in > previous discussion will be written down. > Go figure, I were basically brainstorming by myself then... :D > > > > On the other hand what the program should do and how it is done the dat= a > exchange among the structures (server/client) should be fixed more > precisely, both in order to be able to write the draft and both to be abl= e > to develop the pogram in order to respect these rules. > > > > > >>On the other hand is writing (and getting approved) the > >>Internet-Draft for the tapper protocol. Which shouldn't be *too* > >>hard. > >> > >>So, what I suggest is getting between 2-3 C/C++ coders starting on > >>tapd firstly, and moving on to the client at a later date? > > > > > > This could work, but we definetively need to extablish what everything > (taht is both server and client) is expected to do before starting > programming. > Well yes, that's true. But as soon as the general workings are down, the > *details* in protocols etc can be adjusted along the way. > > > > > >>Another point, is codingstyle/guidelines. Do we need one? > > > > > > Weel this should be not a serious point since there are program like > indent that make easy to change the style. > > > >>While perhaps me and "AnyFile"(what's your name..?) > >>(an...@us...) > > > > > > Well, let me introduce myself. My name is Andrea Fascilla. I am from > Italy (and I ask you pardom in advance for the many English error I will > make) and I am I boy (I just tell you this since I know that every Englis= h > belive me a girl from my name). To e-mail me you can use > afa...@ma... or an...@us... . I know my skill in > programming and similar are limited. I have some knowledge in C, HTML, I = am > (actually I was) somehow familar to RFC standards and their procedures, I > can easely translate English into Italian. I have some familiarity to lin= ux > system (expecially old redHat version), I know something about linux > administrations and system installation, program installation both manual= ly > (from source) and with packager manager (actully limited to rpm, which I > studied at some depth some time ago) > Hi Andrea, nice to know you hehe... > > > > > >>could get started on the > >>documentation. > >>First writing the I-D, then drafting out some sort of docs for > >>other stuff that might appear. > >> > > > > > > Have you got any contact with the IETF folks? > > > > Whiche is the rivelant area? The Applications Area ( > http://www.apps.ietf.org/) > Well, these two pages are good reads for a start; > http://www.ietf.org/ID.html & http://www.ietf.org/ietf/1id-guidelines.htm= l > > Especially the part about Submissions... > Afaik, there's no need to have a specific contact within the IETF, as all > I-D draft submissions are sent to a common > adress and approved/disapproved. > > Cheers, > > AnyFile > > > > > -- > > Cheers, > Dag Rune Sneeggen(ni...@du...) > --- > > Tapper Package Manager ( http://sourceforge.net/projects/tapper-pm/) --> > Do you want to miss the fun? :o > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Tapper-pm-devel mailing list > Tap...@li... > https://lists.sourceforge.net/lists/listinfo/tapper-pm-devel |
|
From: Asheley L. <jun...@gm...> - 2005-10-13 17:55:01
|
1. Use of source compiling instead of package system. I feel that Gentoo is already doing a good job at source compilation. This would offer nothing new IMHO. A multi version package system though is something new and something administrators could use. The current philosoph= y of major distributors is to simple compile all functions into there package= s making them blotted and more difficult to administer and secure. The idea o= f the power and easy of apt-get/RPM with the advanced controls of gentoo is a new concept. 2. CVS use I think we should use it. As in all open source projects, new developers will start to come on board. Patches will be developed by outsiders and be submitted for insertion into the code base. I think CVS is necessary to the growth and expandability of the project. Shawn On 10/13/05, Dag Rune Sneeggen <con...@du...> wrote: > > Jason Kielpinski wrote: > > I think we should use a source-based package format, and compile it on > > each system, sort of like gentoo's portage. If this package manager > > won't be tied to any one distro, it would be a major headache to compil= e > > binaries for each and every platform. It'll need some sort of config > > file put into the tarball, to specify different things. > Oh, the whole concept of tapper is to attempt creating a binary based > package manager. Sure this has been done before. > But not with "extentions", which are basically binary rdiff patches. Sure > it will be a bit painful at times before we figure it all out. > On the other hand, those who wont try certainly wont achieve anything ;) > Perhaps it's never been done because its practically impossible, or > perhaps because people assume it is. > I'm pretty certain in can be done, and that's what we're going to find > out. > > In many respects, if the package maintainers does a wonderful job for eac= h > and every package, and the basic system > is layed out intelligently; this is the holy grail of package management > if you ask me. > No waiting for (virtually) endless builds over and over again, but still > enabling quasi-buildtime optimization. > > > > Personally, I prefer to follow the Linux Kernel > > Documentation/CodingStyle rather than the GNU, but I will work with > > either it doesn't really matter. I think it's best to have some kind of > > coding style guidelines. > > > Sounds fine by me. ;) > > If we carefully plan and split up tasks in tapperd by function, and > > individually work on the functions, then I think working on together > > would be fine. CVS seems like a little bit overkill, but we could use i= t > > I guess... though I'd prefer not. > > > Yeah, perhaps CVS is overkill. I don't feel very strongly for these issue= , > whatever works out I say! > > Just my initial thoughts, > > > > > -- > > Cheers, > Dag Rune Sneeggen(ni...@du...) > --- > > Tapper Package Manager (http://sourceforge.net/projects/tapper-pm/) --> D= o > you want to miss the fun? :o > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Tapper-pm-devel mailing list > Tap...@li... > https://lists.sourceforge.net/lists/listinfo/tapper-pm-devel > |
|
From: Dag R. S. <con...@du...> - 2005-10-13 17:12:37
|
Any File wrote: > ----- Original Message ----- > From: "Dag Rune Sneeggen" <con...@du...> > Subject: [Tapper-pm-docteam] Getting this party started! > Date: Wed, 12 Oct 2005 23:48:41 +0200 > > >>As soon as I get my new domain registered, this should be replaced >>with something more useful and tidy. > > > What domain name would you like? I'll be buying nixdev.io, sort of fallen in love with the whole .io domain. It opened for public regs not long ago hehe. Input/Output? Get it, hehe... > > There is also the possibility of using the sourceforge website at http://tapper-pm.sourceforge.net/ in the meantime. > > >>Anything we'd like to see on the soon-to-come page? Do we want a >>wiki or more static? Or...? > > > I am pretty used to wiki (particularry MediaWiki), but I do not think we really need it t the moment. We can also use it but it would be not so useful. Wiki are useful when everybody on the web should be able to edit the page or when you need some feature it proviedes (e.g. to retrive previous version). Untill we are a very small group of develepors any type of system that allow as to publish (in any way) can works enought. Perhaps I'll set up something like Plone or drupal soon-ish. Quite decent systems... > > >>But concerning the actual tapper package manager. As for now, >>there's been a lot of thoughts floating around >>in *my* head mainly. >>Over the next few posts and discussions, we can get this "set in >>stone" if you'd like. > > > Yes, it would a good thing to have something written. There is no need at all that it should be unchangeble thing (if I undestand the meaning of "set in stone"). A written document about the current situation would be very important to us to undestand what we shall do. Moreover writing down thing make them cleare than havingit in mind and the problems and the solutions that are hidden into the mind came out more easely. Absolutely, well said. > > >>A different point of view, is with the documentation, or design if you'd like. >>We need to document both the actual layout and workings of the >>*handling* of packages locally and on servers. >>Which formats for what? Where should what be stored? Standards and >>a set of rules perhaps. > > > Yes, and before writting down the documentation we have to decide how it should work. At this point of the development we can try to use the easiest way to be implemented (untill it remains portable and do not cause any problems). > > In my opinion (but I am open to hear anything about that on this) we can implement as a first step a simple program letting us open the possibility of using more complicated and powerful solutions. This would give us a quicker way to have something real on every aspect of the project to be improved. For instance we can choose an easy to implement and easy to manage database, even if not powerful and optimized and improve it or change it in the future. If thing are done in modular way (as I suppose it is the better way to implement a thing that should be portable and standard) there should not be many problems in changing things on the way while they are improoved. Yeah, on the one hand, it would be nice if the application development moved forward very modular. So that things can be compiled and tested from an early stage. Then again, the coders should have the freedom to do it anyway they wish. > > But actually I have not very clear what should we do. I have not partecipated to your previous brainstorm, since I have just joined your project. I hope things will be more clear to me when waht extabilshed in previous discussion will be written down. Go figure, I were basically brainstorming by myself then... :D > > On the other hand what the program should do and how it is done the data exchange among the structures (server/client) should be fixed more precisely, both in order to be able to write the draft and both to be able to develop the pogram in order to respect these rules. > > >>On the other hand is writing (and getting approved) the >>Internet-Draft for the tapper protocol. Which shouldn't be *too* >>hard. >> >>So, what I suggest is getting between 2-3 C/C++ coders starting on >>tapd firstly, and moving on to the client at a later date? > > > This could work, but we definetively need to extablish what everything (taht is both server and client) is expected to do before starting programming. Well yes, that's true. But as soon as the general workings are down, the *details* in protocols etc can be adjusted along the way. > > >>Another point, is codingstyle/guidelines. Do we need one? > > > Weel this should be not a serious point since there are program like indent that make easy to change the style. > >>While perhaps me and "AnyFile"(what's your name..?) >>(an...@us...) > > > Well, let me introduce myself. My name is Andrea Fascilla. I am from Italy (and I ask you pardom in advance for the many English error I will make) and I am I boy (I just tell you this since I know that every English belive me a girl from my name). To e-mail me you can use afa...@ma... or an...@us... . I know my skill in programming and similar are limited. I have some knowledge in C, HTML, I am (actually I was) somehow familar to RFC standards and their procedures, I can easely translate English into Italian. I have some familiarity to linux system (expecially old redHat version), I know something about linux administrations and system installation, program installation both manually (from source) and with packager manager (actully limited to rpm, which I studied at some depth some time ago) Hi Andrea, nice to know you hehe... > > >>could get started on the >>documentation. >>First writing the I-D, then drafting out some sort of docs for >>other stuff that might appear. >> > > > Have you got any contact with the IETF folks? > > Whiche is the rivelant area? The Applications Area (http://www.apps.ietf.org/) Well, these two pages are good reads for a start; http://www.ietf.org/ID.html & http://www.ietf.org/ietf/1id-guidelines.html Especially the part about Submissions... Afaik, there's no need to have a specific contact within the IETF, as all I-D draft submissions are sent to a common adress and approved/disapproved. > Cheers, > AnyFile > -- Cheers, Dag Rune Sneeggen(ni...@du...) --- Tapper Package Manager (http://sourceforge.net/projects/tapper-pm/) --> Do you want to miss the fun? :o |
|
From: Dag R. S. <con...@du...> - 2005-10-13 17:04:36
|
Jason Kielpinski wrote: > I think we should use a source-based package format, and compile it on > each system, sort of like gentoo's portage. If this package manager > won't be tied to any one distro, it would be a major headache to compile > binaries for each and every platform. It'll need some sort of config > file put into the tarball, to specify different things. Oh, the whole concept of tapper is to attempt creating a binary based package manager. Sure this has been done before. But not with "extentions", which are basically binary rdiff patches. Sure it will be a bit painful at times before we figure it all out. On the other hand, those who wont try certainly wont achieve anything ;) Perhaps it's never been done because its practically impossible, or perhaps because people assume it is. I'm pretty certain in can be done, and that's what we're going to find out. In many respects, if the package maintainers does a wonderful job for each and every package, and the basic system is layed out intelligently; this is the holy grail of package management if you ask me. No waiting for (virtually) endless builds over and over again, but still enabling quasi-buildtime optimization. > > Personally, I prefer to follow the Linux Kernel > Documentation/CodingStyle rather than the GNU, but I will work with > either it doesn't really matter. I think it's best to have some kind of > coding style guidelines. > Sounds fine by me. ;) > If we carefully plan and split up tasks in tapperd by function, and > individually work on the functions, then I think working on together > would be fine. CVS seems like a little bit overkill, but we could use it > I guess... though I'd prefer not. > Yeah, perhaps CVS is overkill. I don't feel very strongly for these issue, whatever works out I say! > Just my initial thoughts, > -- Cheers, Dag Rune Sneeggen(ni...@du...) --- Tapper Package Manager (http://sourceforge.net/projects/tapper-pm/) --> Do you want to miss the fun? :o |
|
From: Any F. <an...@ma...> - 2005-10-13 15:04:34
|
----- Original Message ----- From: "Dag Rune Sneeggen" <con...@du...> Subject: [Tapper-pm-docteam] Getting this party started! Date: Wed, 12 Oct 2005 23:48:41 +0200 >=20 > As soon as I get my new domain registered, this should be replaced=20 > with something more useful and tidy. What domain name would you like? There is also the possibility of using the sourceforge website at http://ta= pper-pm.sourceforge.net/ in the meantime. > Anything we'd like to see on the soon-to-come page? Do we want a=20 > wiki or more static? Or...? I am pretty used to wiki (particularry MediaWiki), but I do not think we re= ally need it t the moment. We can also use it but it would be not so useful= . Wiki are useful when everybody on the web should be able to edit the page= or when you need some feature it proviedes (e.g. to retrive previous versi= on). Untill we are a very small group of develepors any type of system that= allow as to publish (in any way) can works enought. >=20 > But concerning the actual tapper package manager. As for now,=20 > there's been a lot of thoughts floating around > in *my* head mainly. > Over the next few posts and discussions, we can get this "set in=20 > stone" if you'd like. Yes, it would a good thing to have something written. There is no need at a= ll that it should be unchangeble thing (if I undestand the meaning of "set = in stone"). A written document about the current situation would be very im= portant to us to undestand what we shall do. Moreover writing down thing ma= ke them cleare than havingit in mind and the problems and the solutions tha= t are hidden into the mind came out more easely. >=20 > A different point of view, is with the documentation, or design if you'd = like. > We need to document both the actual layout and workings of the=20 > *handling* of packages locally and on servers. > Which formats for what? Where should what be stored? Standards and=20 > a set of rules perhaps. Yes, and before writting down the documentation we have to decide how it sh= ould work. At this point of the development we can try to use the easiest w= ay to be implemented (untill it remains portable and do not cause any probl= ems). In my opinion (but I am open to hear anything about that on this) we can im= plement as a first step a simple program letting us open the possibility of= using more complicated and powerful solutions. This would give us a quicke= r way to have something real on every aspect of the project to be improved.= For instance we can choose an easy to implement and easy to manage databas= e, even if not powerful and optimized and improve it or change it in the fu= ture. If thing are done in modular way (as I suppose it is the better way t= o implement a thing that should be portable and standard) there should not = be many problems in changing things on the way while they are improoved. But actually I have not very clear what should we do. I have not partecipat= ed to your previous brainstorm, since I have just joined your project. I ho= pe things will be more clear to me when waht extabilshed in previous discus= sion will be written down. On the other hand what the program should do and how it is done the data ex= change among the structures (server/client) should be fixed more precisely,= both in order to be able to write the draft and both to be able to develop= the pogram in order to respect these rules.=20 > On the other hand is writing (and getting approved) the=20 > Internet-Draft for the tapper protocol. Which shouldn't be *too*=20 > hard. >=20 > So, what I suggest is getting between 2-3 C/C++ coders starting on=20 > tapd firstly, and moving on to the client at a later date? This could work, but we definetively need to extablish what everything (tah= t is both server and client) is expected to do before starting programming. > Another point, is codingstyle/guidelines. Do we need one? Weel this should be not a serious point since there are program like indent= that make easy to change the style. >=20 > While perhaps me and "AnyFile"(what's your name..?)=20 > (an...@us...) Well, let me introduce myself. My name is Andrea Fascilla. I am from Italy = (and I ask you pardom in advance for the many English error I will make) an= d I am I boy (I just tell you this since I know that every English belive = me a girl from my name). To e-mail me you can use afa...@ma... or any= fi...@us... . I know my skill in programming and similar are= limited. I have some knowledge in C, HTML, I am (actually I was) somehow f= amilar to RFC standards and their procedures, I can easely translate Englis= h into Italian. I have some familiarity to linux system (expecially old red= Hat version), I know something about linux administrations and system insta= llation, program installation both manually (from source) and with packager= manager (actully limited to rpm, which I studied at some depth some time a= go) > could get started on the=20 > documentation. > First writing the I-D, then drafting out some sort of docs for=20 > other stuff that might appear. >=20 Have you got any contact with the IETF folks? Whiche is the rivelant area? The Applications Area (http://www.apps.ietf.or= g/) Cheers, AnyFile --=20 ___________________________________________________ Play 100s of games for FREE! http://games.mail.com/ |
|
From: Jason K. <jas...@gm...> - 2005-10-13 12:02:11
|
I think we should use a source-based package format, and compile it on each system, sort of like gentoo's portage. If this package manager won't be tied to any one distro, it would be a major headache to compile binaries for each and every platform. It'll need some sort of config file put into the tarball, to specify different things. Personally, I prefer to follow the Linux Kernel Documentation/CodingStyle rather than the GNU, but I will work with either it doesn't really matter. I think it's best to have some kind of coding style guidelines. If we carefully plan and split up tasks in tapperd by function, and individually work on the functions, then I think working on together would be fine. CVS seems like a little bit overkill, but we could use it I guess... though I'd prefer not. Just my initial thoughts, -- jason kielpinski |
|
From: Dag R. S. <con...@du...> - 2005-10-12 21:48:55
|
So yes, Finally some useful posting to this/these list(s), see if we can get this= ball rolling. I'm sure we all keep a keen eye at the wiki http://nix-dev.dudcore.net/Cu= rrProjects/TapperPM page(s)? As soon as I get my new domain registered, this should be replaced with s= omething more useful and tidy. For now, the most useful thing is perhaps the schematic image, as well as= the project description? Anything we'd like to see on the soon-to-come page? Do we want a wiki or = more static? Or...? But concerning the actual tapper package manager. As for now, there's bee= n a lot of thoughts floating around in *my* head mainly. Over the next few posts and discussions, we can get this "set in stone" i= f you'd like. For tapper, there is mainly two large programming jobs, the d=E6mon and t= he client interface. The client might be slightly larger and more complex than tapd, as a d=E6= mon has no direct input/output (as I'm sure we all realize). A different point of view, is with the documentation, or design if you'd = like. We need to document both the actual layout and workings of the *handling*= of packages locally and on servers. Which formats for what? Where should what be stored? Standards and a set = of rules perhaps. On the other hand is writing (and getting approved) the Internet-Draft fo= r the tapper protocol. Which shouldn't be *too* hard. So, what I suggest is getting between 2-3 C/C++ coders starting on tapd f= irstly, and moving on to the client at a later date? Or would you folks prefer to start at one each? Or perhaps something enti= rely else? Here I'm talking mainly about Jason Kielpinski (def...@us...u= rceforge.net) and Shawn Lee (das...@us...). I see my part as an over-all "watchdog" and co-ordinator for this. Perhap= s the (un)regular fixes and hacks... Another point, is codingstyle/guidelines. Do we need one? I propose either the GNU coding standard (http://www.gnu.org/prep/standar= ds/standards.html) or the Linux Kernel Documentation/CodingStyle (http://kerneltrap.org/file= s/Jeremy/CodingStyle.txt). Or perhaps we need none? While perhaps me and "AnyFile"(what's your name..?) (an...@us...urce= forge.net) could get started on the documentation. First writing the I-D, then drafting out some sort of docs for other stuf= f that might appear. Does all this sound swell and dandy folks? ;) Perhaps anything we should discuss right away do you feel? Brainstorm anything here on the list, the more posting the better! :D Really, just flush it all out... PS: At a slightly later date, we'd need a few people creating packages. B= ut as this is a bit ahead in time, lets hope for a healty bunch of trusty hard-working men(read: slaves) to do this. As lo= ng as the tools and helper scripts are layed down, it shouldn't be too much of a hassle! ^_^ Cheers, Dag Rune Sneeggen(ni...@du...) --- Tapper Package Manager (http://sourceforge.net/projects/tapper-pm/) --> D= o you want to miss the fun? :o |
|
From: Dag R. S. <con...@du...> - 2005-10-03 19:58:52
|
-------- Original Message -------- Subject: Tapper-pm developer mailing list. Date: Mon, 03 Oct 2005 21:27:39 +0200 From: Dag Rune Sneeggen <con...@du...> To: tap...@li... Hi folks! I've been getting lots of good mail from developers and doc-writers the last couple of weeks. For now, I'd greatly appreciate it if you'd all sign up for the tapper-pm developer mailinglist here; https://lists.sourceforge.net/lists/listinfo/tapper-pm-devel It's time to start discussing and really figuring out the practical and best ways to accomplish things. If you feel its a bit 'abstract' tapper-pm at the moment, I'll try to give a more concrete impression on this list! Hopefully we can get some good activity going, while we shape up stuff and get ready to start developing ;) Cheers, Dag Rune Sneeggen(ni...@du...) --- Tapper Package Manager (http://sourceforge.net/projects/tapper-pm/) --> Do you want to miss the fun? :o -- Cheers, Dag Rune Sneeggen(ni...@du...) --- Tapper Package Manager (http://sourceforge.net/projects/tapper-pm/) --> Do you want to miss the fun? :o |
