Sorry, posted this to the wrong list the first time. Thanks Frank ----
Hallo, I'd like to be added to the CVS dev list, such that I can begin posting a few of the publicly-useful abstractions I've been working on, and more presently to get the mmonoplayer externals added.
I'd also still be interested in getting us over to Subversion, if there is still a supportive group for this? I've maintained several SVN repos now, and feel a bit more up to the task of organizing the project.
Reasons for my admission include the bad luck of a prime number of developers.
Thanks! Luke proyekto.net
On Wed Feb 14, 2007 at 03:15:10PM -0700, Luke Iannini (pd) wrote:
Sorry, posted this to the wrong list the first time. Thanks Frank
Hallo, I'd like to be added to the CVS dev list, such that I can begin posting a few of the publicly-useful abstractions I've been working on, and more presently to get the mmonoplayer externals added.
I'd also still be interested in getting us over to Subversion, if there is still a supportive group for this? I've maintained several SVN repos now, and feel a bit more up to the task of organizing the project.
i'd be more interested in moving us over to Git, so i can stop getting these emails. what do we need. a webpage to register repos?
Reasons for my admission include the bad luck of a prime number of developers.
Thanks! Luke proyekto.net
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
carmen wrote:
I'd also still be interested in getting us over to Subversion, if there is still a supportive group for this? I've maintained several SVN repos now, and feel a bit more up to the task of organizing the project.
there are definitely a lot of supporters for this. i think the main problem (were we stopped last time) was to find a directory layout. otoh, the beauty about svn is, that the directory layout can be changed...
i'd be more interested in moving us over to Git, so i can stop getting these emails.
why would "these" emails stop more if we were using Git than they would if we were using svn?
personally i'd like to investigate about SVK (even though i have no experience with that)
what do we need. a webpage to register repos?
no. we could use either sourceforge's SVN or host our own at puredata.info.
the good thing about the 1st is, that we don't have to care about hardware, backups and the like (even if "we" only means "me") the bad thing is that sourceforge is really overloaded. the good thing about the 2nd is, that the repository is under our full control. we can also use the puredata.info accounts to access the repository (this is already set up) the bad thing is, that we have to take full control over the repository.
of course we could also use other hosts (but then each dev has to sign up at yet another website).
mfga.sdr IOhannes
On Thu, Feb 15, 2007 at 09:59:59AM +0100, IOhannes m zmoelnig wrote:
i'd be more interested in moving us over to Git, so i can stop getting these emails.
why would "these" emails stop more if we were using Git than they would if we were using svn?
I could be wrong, but I think git is a decentralised code management system. With decentralised code management systems like git and bzr you don't need to have a 'central' repository. Everyone has their own copy of the code in their own repository and patches are posted to a common place (like this mailing list). Each person can then decide to accept or reject those patches into their own codebase. So becoming a developer is as easy as checking out a local copy of the code, signing up to the mailing list, and starting to post patches. It's a more democratic way of developing, and more subject to software evolution.
I am not sure if that development model suits Pure Data though. It might be a bit unrealistic to think everyone here could work in that style.
Best,
Chris.
------------------- chris@mccormick.cx http://mccormick.cx
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
hardware, backups and the like (even if "we" only means "me") the bad thing is that sourceforge is really overloaded. the good thing about the 2nd is, that the repository is under our full control. we can also use the puredata.info accounts to access the repository (this is already set up)
This is set up? Way cool! You know, I'm actually getting a bit worried about the increasing number of developers on the Sourceforge project. I mean, not that I wouldn't want e.g. Luke to be a part of it, he's a long-standing member of the community, posts the hell on the list and would be a good addition.
However we already have a huge amount of members, who all have access to the whole tree except Miller's branch, and I'd guess, that most of the developers only need to have access to their own directory so that their stuff can be checked out easily, can be included in pd-extended etc.
Maybe it would be better to organize the (future SVN) repository a bit differently: A "default member" would just get write access to one (SVN) directory. Then e.g. Luke could put his abstractions and the mmonoplayer and whatever comes up there, pd-extended could still collect it. I guess this would be sufficient for a large number of developers. (Many people recently added as members, like Eric Lyon etc., "just" put their externals and abstractions there and all is fine.)
Addition of such "default members" could be handled very informally as they cannot break anything and thus they wouldn't have to be checked as "thoroughly" as they currently are ... not. ;)
Of course we would loose the possibility that everyone can quickly fix a bug everywhere, but then, I don't see this as such a big problem. There still would be "trusted core developers" with access to almost everything - or maybe we could let each user decide with an ACL file in her/his user directory, who should have access to it.
Anyway this ACL won't work at Sourceforge's SVN and I don't think, we really should fiddle around with SF's CVS too much anymore, so it would be something that ideally would be handled by a SVN at IEM.
Ciao
Frank Barknecht wrote:
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
hardware, backups and the like (even if "we" only means "me") the bad thing is that sourceforge is really overloaded. the good thing about the 2nd is, that the repository is under our full control. we can also use the puredata.info accounts to access the repository (this is already set up)
This is set up? Way cool! You know, I'm actually getting a bit worried
please note that the only thing that is set up is, that the users from puredata.info are accessible for other services (like SVN). subversion itself has not really been setup (apart from some simple testings, proving that the authentication works). furthermore we still would need a way to administer the authorization. (i think you are right about that)
fmasdr. IOhannes
Hallo!
However we already have a huge amount of members, who all have access to the whole tree except Miller's branch, and I'd guess, that most of the developers only need to have access to their own directory so that their stuff can be checked out easily, can be included in pd-extended etc.
Maybe it would be better to organize the (future SVN) repository a bit differently: A "default member" would just get write access to one (SVN) directory. Then e.g. Luke could put his abstractions and the
[...]
Of course we would loose the possibility that everyone can quickly fix a bug everywhere, but then, I don't see this as such a big problem. There still would be "trusted core developers" with access to almost everything - or maybe we could let each user decide with an ACL file in her/his user directory, who should have access to it.
I think this is only a good idea if there were already problems, that other developers broke things ... which I cannot really remember. If not, it will only prevent some people from developing, trying to improve other code, improving the build system etc.
I see your point, but I think this is more appropriate for a project, where you really have some core developers (or maintainers) which work quite a lot on the code - but I don't think that it is like that in pd! (exception: millers main, maybe the pd-extended-release branch from hans and pd-devel-core)
LG Georg
On Thu, 2007-02-15 at 13:55 +0100, Georg Holzmann wrote:
Of course we would loose the possibility that everyone can quickly
fix
a bug everywhere, but then, I don't see this as such a big problem. There still would be "trusted core developers" with access to almost everything - or maybe we could let each user decide with an ACL file in her/his user directory, who should have access to it.
I think this is only a good idea if there were already problems, that other developers broke things ... which I cannot really remember. If not, it will only prevent some people from developing, trying to improve other code, improving the build system etc.
iirc, carmen once messed with the plugin~ help files, which was not in everyone's interest.
I see your point, but I think this is more appropriate for a project, where you really have some core developers (or maintainers) which work quite a lot on the code - but I don't think that it is like that in pd! (exception: millers main, maybe the pd-extended-release branch from hans and pd-devel-core)
it would have the advantage, that there is a certain amount of quality assurance, so no one messes with other people's code ... but i guess your observation is correct, currently the cvs is not used as version control system, but rather as a code publishing system.
tim
-- tim@klingt.org ICQ: 96771783 http://www.mokabar.tk
Which is more musical, a truck passing by a factory or a truck passing by a music school? John Cage
Hallo, Tim Blechmann hat gesagt: // Tim Blechmann wrote:
it would have the advantage, that there is a certain amount of quality assurance, so no one messes with other people's code ... but i guess your observation is correct, currently the cvs is not used as version control system, but rather as a code publishing system.
Which IMO is even more an argument for a more fine-grained permissions system, because only a handful of the 60 developers actually *need* access to everything.
Ciao
On Thu Feb 15, 2007 at 03:21:08PM +0100, Tim Blechmann wrote:
On Thu, 2007-02-15 at 13:55 +0100, Georg Holzmann wrote:
Of course we would loose the possibility that everyone can quickly
fix
a bug everywhere, but then, I don't see this as such a big problem. There still would be "trusted core developers" with access to almost everything - or maybe we could let each user decide with an ACL file in her/his user directory, who should have access to it.
I think this is only a good idea if there were already problems, that other developers broke things ... which I cannot really remember. If not, it will only prevent some people from developing, trying to improve other code, improving the build system etc.
iirc, carmen once messed with the plugin~ help files, which was not in everyone's interest.
i also ch ecked in some minor 'fixes' to the devel build files and similar that got reverted. sometimes this might have even been accidental. eg making changes in an external dir, then running CVS diff, then cd .. then commit.. the user-level dirs does sound good. no worrying about messing stuff up :)
I see your point, but I think this is more appropriate for a project, where you really have some core developers (or maintainers) which work quite a lot on the code - but I don't think that it is like that in pd! (exception: millers main, maybe the pd-extended-release branch from hans and pd-devel-core)
it would have the advantage, that there is a certain amount of quality assurance, so no one messes with other people's code ... but i guess your observation is correct, currently the cvs is not used as version control system, but rather as a code publishing system.
tim
-- tim@klingt.org ICQ: 96771783 http://www.mokabar.tk
Which is more musical, a truck passing by a factory or a truck passing by a music school? John Cage
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Hallo, Georg Holzmann hat gesagt: // Georg Holzmann wrote:
I think this is only a good idea if there were already problems, that other developers broke things ... which I cannot really remember. If not, it will only prevent some people from developing, trying to improve other code, improving the build system etc.
I didn't really happen in the past, except in some minor cases that were possible to work out, but it may happen in the future. Everytime a new developer is added I as one of the admins get a little bit nervous if I don't know that person.
Just to give some numbers: Currently we have 59 developers according to http://sourceforge.net/projects/pure-data and I just saw, that some like said Eric Lyon are still missing - at least I do know *him* personally ;) - so we are already past 60!
Ciao
Hallo!
Just to give some numbers: Currently we have 59 developers according to http://sourceforge.net/projects/pure-data and I just saw, that some like said Eric Lyon are still missing - at least I do know *him* personally ;) - so we are already past 60!
Yes, but how many developers are active ATM ? I don't think that much more than 10 commited something in the last month ...
LG Georg
Hallo, Georg Holzmann hat gesagt: // Georg Holzmann wrote:
Hallo!
Just to give some numbers: Currently we have 59 developers according to http://sourceforge.net/projects/pure-data and I just saw, that some like said Eric Lyon are still missing - at least I do know *him* personally ;) - so we are already past 60!
Yes, but how many developers are active ATM ? I don't think that much more than 10 commited something in the last month ...
Again I think this is even more reason to handle write-everywhere permissions a bit less liberal according to a principle of least damage.
If only 10 developers actually commit regularily, dealing with permissions more restrictive wouldn't affect the others at all. And OTOH it would allow us to give out the restricted permissions to a lot more people much easier and without worries.
Ciao
Hi
On 15 Feb 2007, at 15:35, Frank Barknecht wrote:
Yes, but how many developers are active ATM ? I don't think that much more than 10 commited something in the last month ...
Again I think this is even more reason to handle write-everywhere permissions a bit less liberal according to a principle of least damage.
If only 10 developers actually commit regularily, dealing with permissions more restrictive wouldn't affect the others at all. And OTOH it would allow us to give out the restricted permissions to a lot more people much easier and without worries.
Speaking as one of the committers who don't really need access to everything, I would welcome more controlled ACL personally. I would be comfortable submitting patches to a core group of developers such as yourselves, and otherwise having access only to my externals.
d
On Feb 15, 2007, at 10:35 AM, Frank Barknecht wrote:
Hallo, Georg Holzmann hat gesagt: // Georg Holzmann wrote:
Hallo!
Just to give some numbers: Currently we have 59 developers according to http://sourceforge.net/projects/pure-data and I just saw, that some like said Eric Lyon are still missing - at least I do know *him* personally ;) - so we are already past 60!
Yes, but how many developers are active ATM ? I don't think that much more than 10 commited something in the last month ...
Again I think this is even more reason to handle write-everywhere permissions a bit less liberal according to a principle of least damage.
If only 10 developers actually commit regularily, dealing with permissions more restrictive wouldn't affect the others at all. And OTOH it would allow us to give out the restricted permissions to a lot more people much easier and without worries.
I am a big fan of "if it ain't broke, don't fix it". So far, the only bad commits have been by people who would have had commit access anyway. I don't think setting up ACLs would be a good way to spend a bunch of time, unless bad commits become a problem. CVS keeps old revisions, all commits are reported to the pd-cvs list (which at least I check, among others), and the build farm makes a full backup of the CVS repository every night.
As for the issue of too many devs, I think if people are worried about there being too many in the sourceforge project, we should purge people who haven't committed in a year. That would probably remove 20 people from the list. Then if they want commit access again, then just post to pd-dev, just like Luke just did. Just to be clear, this isn't a judgment on those people, just purely a practical matter. I think we could send them all an email asking if they want to keep the access.
.hc
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------
Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith
On 2/15/07, IOhannes m zmoelnig zmoelnig@iem.at wrote:
carmen wrote:
I'd also still be interested in getting us over to Subversion, if there is still a supportive group for this? I've maintained several SVN repos now, and feel a bit more up to the task of organizing the project.
there are definitely a lot of supporters for this. i think the main problem (were we stopped last time) was to find a directory layout. otoh, the beauty about svn is, that the directory layout can be changed...
i'd be more interested in moving us over to Git, so i can stop getting these emails.
why would "these" emails stop more if we were using Git than they would if we were using svn?
personally i'd like to investigate about SVK (even though i have no experience with that)
I'd certainly be interested in checking out SVK. I have been in a net-less situation many times where it would have been nice to be able to do a "check-in" locally before making a big change. It is very similar to subversion (well, it is subversion, plus more), so I don't think there would be too much additional use overhead.
One benefit of SVN, on the other hand, is the wide choice of OS and App integration tools, for example: TextMate and SCPlugin (as of the recent update) integrate wonderfully with Subversion, as does TortoiseSVN on Windows and I suppose VIM and SubCommander on Linux (and probably others, haven't spend much time with svn clients besides stock CLI on linux, only servers).
Finally there is the issue of converting the CVS; Tigris's CVStoSVN has been around for quite some time and is really simple to get going http://sam.zoy.org/writings/programming/svn2cvs.html.
I'm not as sure about the SVK solution of http://svk.bestpractical.com/view/MirrorVCP But maybe we can just two-step it, once to SVN, then again to SVK.
I'll grab SVK and give it an actual lookover. <time passes> Well, I haven't downloaded it yet, but I have done a lot of reading on it, and the general feeling I'm getting is that it is not quite mature enough that we should be moving to it yet... it looks like a very cool system but I'd feel safer making the smaller step to Subversion first, then maybe reconsidering SVK later, once everyone is comfortable (since at that point it would be very easy to switch).
what do we need. a webpage to register repos?
no. we could use either sourceforge's SVN or host our own at puredata.info.
the good thing about the 1st is, that we don't have to care about hardware, backups and the like (even if "we" only means "me") the bad thing is that sourceforge is really overloaded. the good thing about the 2nd is, that the repository is under our full control. we can also use the puredata.info accounts to access the repository (this is already set up) the bad thing is, that we have to take full control over the repository.
On the issue of accounts, I think it would be useful to have the two layer authentication at minimum so that those uninterested in working with the core source could make checkins with the "basic user" account without the worry of somehow causing trouble for the "core developer" account. This might be a nice compromise between dozens of accounts and just one.
Finally, if any are interested, I'd be willing to mirror the CVS repository on my server and convert it to Subversion just for research and general interest purposes. Then everyone could have a sandbox to checkout SVN before the move is made.
of course we could also use other hosts (but then each dev has to sign up at yet another website).
mfga.sdr IOhannes
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Regards, Luke
OK, well if this is not quite ready to be discussed, could someone at least add me to the dev list? (or write a counter proposal for my non admission : ))
Thanks, Luke
On 2/23/07, Luke Iannini (pd) lukexipd@gmail.com wrote:
On 2/15/07, IOhannes m zmoelnig zmoelnig@iem.at wrote:
carmen wrote:
I'd also still be interested in getting us over to Subversion, if there is still a supportive group for this? I've maintained several SVN repos now, and feel a bit more up to the task of organizing the project.
there are definitely a lot of supporters for this. i think the main problem (were we stopped last time) was to find a directory layout. otoh, the beauty about svn is, that the directory layout can be changed...
i'd be more interested in moving us over to Git, so i can stop getting these emails.
why would "these" emails stop more if we were using Git than they would if we were using svn?
personally i'd like to investigate about SVK (even though i have no experience with that)
I'd certainly be interested in checking out SVK. I have been in a net-less situation many times where it would have been nice to be able to do a "check-in" locally before making a big change. It is very similar to subversion (well, it is subversion, plus more), so I don't think there would be too much additional use overhead.
One benefit of SVN, on the other hand, is the wide choice of OS and App integration tools, for example: TextMate and SCPlugin (as of the recent update) integrate wonderfully with Subversion, as does TortoiseSVN on Windows and I suppose VIM and SubCommander on Linux (and probably others, haven't spend much time with svn clients besides stock CLI on linux, only servers).
Finally there is the issue of converting the CVS; Tigris's CVStoSVN has been around for quite some time and is really simple to get going http://sam.zoy.org/writings/programming/svn2cvs.html.
I'm not as sure about the SVK solution of http://svk.bestpractical.com/view/MirrorVCP But maybe we can just two-step it, once to SVN, then again to SVK.
I'll grab SVK and give it an actual lookover.
<time passes> Well, I haven't downloaded it yet, but I have done a lot of reading on it, and the general feeling I'm getting is that it is not quite mature enough that we should be moving to it yet... it looks like a very cool system but I'd feel safer making the smaller step to Subversion first, then maybe reconsidering SVK later, once everyone is comfortable (since at that point it would be very easy to switch).
what do we need. a webpage to register repos?
no. we could use either sourceforge's SVN or host our own at puredata.info.
the good thing about the 1st is, that we don't have to care about hardware, backups and the like (even if "we" only means "me") the bad thing is that sourceforge is really overloaded. the good thing about the 2nd is, that the repository is under our full control. we can also use the puredata.info accounts to access the repository (this is already set up) the bad thing is, that we have to take full control over the repository.
On the issue of accounts, I think it would be useful to have the two layer authentication at minimum so that those uninterested in working with the core source could make checkins with the "basic user" account without the worry of somehow causing trouble for the "core developer" account. This might be a nice compromise between dozens of accounts and just one.
Finally, if any are interested, I'd be willing to mirror the CVS repository on my server and convert it to Subversion just for research and general interest purposes. Then everyone could have a sandbox to checkout SVN before the move is made.
of course we could also use other hosts (but then each dev has to sign up at yet another website).
mfga.sdr IOhannes
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Regards, Luke
hi.
Quoting "Luke Iannini (pd)" lukexipd@gmail.com:
OK, well if this is not quite ready to be discussed, could someone at least add me to the dev list?
man, this _is_ the dev list!
(or write a counter proposal for my non admission : ))
as hans has often pointed out, pd-community mainly decides on a "lazy consensus".
i was not aware that you have applied for repositry dev access (but i generally leave this to the other, more "organized" admins)
mfg.asdr IOhannes
Haha, please look at the first message in (or the subject of) this thread... we have gone far off topic : )
Yes, the counter proposal bit was a jab at the fact that the lazy consensus has been a bit too lazy, and if the consensus is that I am rejected perhaps a counter-proposal (for my rejection) is needed to confirm that, lazily.
Finally, does anyone have any opinions on http://code.google.com as a cantidate? It would perhaps lighten your load, IOhannes (in that you wouldn't have to assemble the server at IEM).
Luke
On 3/2/07, zmoelnig@iem.at zmoelnig@iem.at wrote:
hi.
Quoting "Luke Iannini (pd)" lukexipd@gmail.com:
OK, well if this is not quite ready to be discussed, could someone at least add me to the dev list?
man, this _is_ the dev list!
(or write a counter proposal for my non admission : ))
as hans has often pointed out, pd-community mainly decides on a "lazy consensus".
i was not aware that you have applied for repositry dev access (but i generally leave this to the other, more "organized" admins)
mfg.asdr IOhannes
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Hallo!
Haha, please look at the first message in (or the subject of) this thread... we have gone far off topic : )
that's true ...
Please someone should add Luke !
Finally, does anyone have any opinions on http://code.google.com as a cantidate? It would perhaps lighten your load, IOhannes (in that you wouldn't have to assemble the server at IEM).
Sorry, I don't undestand this: google as a candidate for what ? for the SVN server (do they do that) ?
LG Georg
Yes, they started their own sourceforge type thing a few months back. They'll host any open source project's SVN server, along with a spartan interface (guaranteed to be a leap above sourceforge) that includes a wiki, file hosting and a bug tracker.
http://code.google.com/hosting is the relevant link. See "create new project" or search/click tags to see some examples.
On 3/2/07, Georg Holzmann grhPD@gmx.at wrote:
Hallo!
Haha, please look at the first message in (or the subject of) this thread... we have gone far off topic : )
that's true ...
Please someone should add Luke !
Finally, does anyone have any opinions on http://code.google.com as a cantidate? It would perhaps lighten your load, IOhannes (in that you wouldn't have to assemble the server at IEM).
Sorry, I don't undestand this: google as a candidate for what ? for the SVN server (do they do that) ?
LG Georg
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On 2 Mar 2007, at 09:19, Georg Holzmann wrote:
Finally, does anyone have any opinions on http://code.google.com as a cantidate? It would perhaps lighten your load, IOhannes (in that you wouldn't have to assemble the server at IEM).
Sorry, I don't undestand this: google as a candidate for what ? for the SVN server (do they do that) ?
Yes they do, and it wouldn't necessarily be a bad thing (I have a project there, SVN access is clean and fast), but puredata.info makes much more sense in terms of coherence, and not mixing concerns.
d
LG Georg
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Mar 2, 2007, at 11:53 AM, David Plans Casal wrote:
On 2 Mar 2007, at 09:19, Georg Holzmann wrote:
Finally, does anyone have any opinions on http://code.google.com as a cantidate? It would perhaps lighten your load, IOhannes (in that you wouldn't have to assemble the server at IEM).
Sorry, I don't undestand this: google as a candidate for what ? for the SVN server (do they do that) ?
Yes they do, and it wouldn't necessarily be a bad thing (I have a project there, SVN access is clean and fast), but puredata.info makes much more sense in terms of coherence, and not mixing concerns.
I have to say that I don't want to use google. I think they are the next microsoft+big brother. Other than that, I am not too particular.
.hc
d
LG Georg
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I have to say that I don't want to use google. I think they are the next microsoft+big brother. Other than that, I am not too particular.
Agreed. Also moving to some other "Sourceforge" with a different name IMO isn't worth the effort, so I still favour IEM.
Ciao
hi.
Luke Iannini (pd) wrote:
Haha, please look at the first message in (or the subject of) this thread... we have gone far off topic : )
ah yes, sorry for this. i was reading my email via a webmail interface and did not have the entire thread at hand. i usually use subjects to determine whether i should read the email now or later, and do not consider it a substantial part of the mail body itself. this is definitely my problem.
Yes, the counter proposal bit was a jab at the fact that the lazy consensus has been a bit too lazy, and if the consensus is that I am rejected perhaps a counter-proposal (for my rejection) is needed to confirm that, lazily.
true. otoh, if i was to add you, whom am i going to add? probably i missed this information, but i am not going to search all lukes on sourceforge whether they are you or not. a username would be helpful.
Finally, does anyone have any opinions on http://code.google.com as a cantidate? It would perhaps lighten your load, IOhannes (in that you wouldn't have to assemble the server at IEM).
well, the server is assembled (it would be the puredata.info host). (i have already noted the pros and cons of hosting the svn at puredata.info; i think the main pro is, that we don't have to create another bunch of users on yet another site; since the community is so lazy when it comes to decisions i fear that it will also be a major pain to migrate people to a new provider (and sometimes i am a bit afraid of google)).
but of course it would be an option to host it elsewhere
mfg.asdr. IOhannes
PS: if this post gets through 2 times, i apologize; was hittin send to early and tried to cancel...
Hallo IOhannes, My username on sourceforge is "lukeiannini". Creative!
Thanks! Luke
On 3/2/07, IOhannes m zmoelnig zmoelnig@iem.at wrote:
hi.
Luke Iannini (pd) wrote:
Haha, please look at the first message in (or the subject of) this thread... we have gone far off topic : )
ah yes, sorry for this. i was reading my email via a webmail interface and did not have the entire thread at hand. i usually use subjects to determine whether i should read the email now or later, and do not consider it a substantial part of the mail body itself. this is definitely my problem.
Yes, the counter proposal bit was a jab at the fact that the lazy consensus has been a bit too lazy, and if the consensus is that I am rejected perhaps a counter-proposal (for my rejection) is needed to confirm that, lazily.
true. otoh, if i was to add you, whom am i going to add? probably i missed this information, but i am not going to search all lukes on sourceforge whether they are you or not. a username would be helpful.
Finally, does anyone have any opinions on http://code.google.com as a cantidate? It would perhaps lighten your load, IOhannes (in that you wouldn't have to assemble the server at IEM).
well, the server is assembled (it would be the puredata.info host). (i have already noted the pros and cons of hosting the svn at puredata.info; i think the main pro is, that we don't have to create another bunch of users on yet another site; since the community is so lazy when it comes to decisions i fear that it will also be a major pain to migrate people to a new provider (and sometimes i am a bit afraid of google)).
but of course it would be an option to host it elsewhere
mfg.asdr. IOhannes
PS: if this post gets through 2 times, i apologize; was hittin send to early and tried to cancel...
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Sorry, I thought you'd been added. What's your sourceforge ID? I couldn't find it.
.hc
On Mar 1, 2007, at 3:04 PM, Luke Iannini (pd) wrote:
OK, well if this is not quite ready to be discussed, could someone at least add me to the dev list? (or write a counter proposal for my non admission : ))
Thanks, Luke
On 2/23/07, Luke Iannini (pd) lukexipd@gmail.com wrote:
On 2/15/07, IOhannes m zmoelnig zmoelnig@iem.at wrote:
carmen wrote:
I'd also still be interested in getting us over to Subversion, if there is still a supportive group for this? I've maintained several SVN repos now, and feel a bit more up to the task of organizing the project.
there are definitely a lot of supporters for this. i think the main problem (were we stopped last time) was to find a directory layout. otoh, the beauty about svn is, that the directory layout can be changed...
i'd be more interested in moving us over to Git, so i can stop getting these emails.
why would "these" emails stop more if we were using Git than they would if we were using svn?
personally i'd like to investigate about SVK (even though i have no experience with that)
I'd certainly be interested in checking out SVK. I have been in a net-less situation many times where it would have been nice to be able to do a "check-in" locally before making a big change. It is very similar to subversion (well, it is subversion, plus more), so I don't think there would be too much additional use overhead.
One benefit of SVN, on the other hand, is the wide choice of OS and App integration tools, for example: TextMate and SCPlugin (as of the recent update) integrate wonderfully with Subversion, as does TortoiseSVN on Windows and I suppose VIM and SubCommander on Linux (and probably others, haven't spend much time with svn clients besides stock CLI on linux, only servers).
Finally there is the issue of converting the CVS; Tigris's CVStoSVN has been around for quite some time and is really simple to get going http://sam.zoy.org/writings/programming/svn2cvs.html.
I'm not as sure about the SVK solution of http://svk.bestpractical.com/view/MirrorVCP But maybe we can just two-step it, once to SVN, then again to SVK.
I'll grab SVK and give it an actual lookover.
<time passes> Well, I haven't downloaded it yet, but I have done a lot of reading on it, and the general feeling I'm getting is that it is not quite mature enough that we should be moving to it yet... it looks like a very cool system but I'd feel safer making the smaller step to Subversion first, then maybe reconsidering SVK later, once everyone is comfortable (since at that point it would be very easy to switch).
what do we need. a webpage to register repos?
no. we could use either sourceforge's SVN or host our own at puredata.info.
the good thing about the 1st is, that we don't have to care about hardware, backups and the like (even if "we" only means "me") the bad thing is that sourceforge is really overloaded. the good thing about the 2nd is, that the repository is under our full control. we can also use the puredata.info accounts to access the repository (this is already set up) the bad thing is, that we have to take full control over the repository.
On the issue of accounts, I think it would be useful to have the two layer authentication at minimum so that those uninterested in working with the core source could make checkins with the "basic user" account without the worry of somehow causing trouble for the "core developer" account. This might be a nice compromise between dozens of accounts and just one.
Finally, if any are interested, I'd be willing to mirror the CVS repository on my server and convert it to Subversion just for research and general interest purposes. Then everyone could have a sandbox to checkout SVN before the move is made.
of course we could also use other hosts (but then each dev has to sign up at yet another website).
mfga.sdr IOhannes
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Regards, Luke
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------
Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra
Hi Hans, ID # is 1541432 Username is lukeiannini
On 3/2/07, Hans-Christoph Steiner hans@eds.org wrote:
Sorry, I thought you'd been added. What's your sourceforge ID? I couldn't find it.
.hc
On Mar 1, 2007, at 3:04 PM, Luke Iannini (pd) wrote:
OK, well if this is not quite ready to be discussed, could someone at least add me to the dev list? (or write a counter proposal for my non admission : ))
Thanks, Luke
On 2/23/07, Luke Iannini (pd) lukexipd@gmail.com wrote:
On 2/15/07, IOhannes m zmoelnig zmoelnig@iem.at wrote:
carmen wrote:
I'd also still be interested in getting us over to Subversion, if there is still a supportive group for this? I've maintained several SVN repos now, and feel a bit more up to the task of organizing the project.
there are definitely a lot of supporters for this. i think the main problem (were we stopped last time) was to find a directory layout. otoh, the beauty about svn is, that the directory layout can be changed...
i'd be more interested in moving us over to Git, so i can stop getting these emails.
why would "these" emails stop more if we were using Git than they would if we were using svn?
personally i'd like to investigate about SVK (even though i have no experience with that)
I'd certainly be interested in checking out SVK. I have been in a net-less situation many times where it would have been nice to be able to do a "check-in" locally before making a big change. It is very similar to subversion (well, it is subversion, plus more), so I don't think there would be too much additional use overhead.
One benefit of SVN, on the other hand, is the wide choice of OS and App integration tools, for example: TextMate and SCPlugin (as of the recent update) integrate wonderfully with Subversion, as does TortoiseSVN on Windows and I suppose VIM and SubCommander on Linux (and probably others, haven't spend much time with svn clients besides stock CLI on linux, only servers).
Finally there is the issue of converting the CVS; Tigris's CVStoSVN has been around for quite some time and is really simple to get going http://sam.zoy.org/writings/programming/svn2cvs.html.
I'm not as sure about the SVK solution of http://svk.bestpractical.com/view/MirrorVCP But maybe we can just two-step it, once to SVN, then again to SVK.
I'll grab SVK and give it an actual lookover.
<time passes> Well, I haven't downloaded it yet, but I have done a lot of reading on it, and the general feeling I'm getting is that it is not quite mature enough that we should be moving to it yet... it looks like a very cool system but I'd feel safer making the smaller step to Subversion first, then maybe reconsidering SVK later, once everyone is comfortable (since at that point it would be very easy to switch).
what do we need. a webpage to register repos?
no. we could use either sourceforge's SVN or host our own at puredata.info.
the good thing about the 1st is, that we don't have to care about hardware, backups and the like (even if "we" only means "me") the bad thing is that sourceforge is really overloaded. the good thing about the 2nd is, that the repository is under our full control. we can also use the puredata.info accounts to access the repository (this is already set up) the bad thing is, that we have to take full control over the repository.
On the issue of accounts, I think it would be useful to have the two layer authentication at minimum so that those uninterested in working with the core source could make checkins with the "basic user" account without the worry of somehow causing trouble for the "core developer" account. This might be a nice compromise between dozens of accounts and just one.
Finally, if any are interested, I'd be willing to mirror the CVS repository on my server and convert it to Subversion just for research and general interest purposes. Then everyone could have a sandbox to checkout SVN before the move is made.
of course we could also use other hosts (but then each dev has to sign up at yet another website).
mfga.sdr IOhannes
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Regards, Luke
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-
carmen -
Chris McCormick -
David Plans Casal -
Frank Barknecht -
Georg Holzmann -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Luke Iannini (pd) -
Plans Casal David
-
Tim Blechmann -
zmoelnigļ¼ iem.at