Thread: [SQLObject] PROJECT - Some suggestions subjecting project continuation
SQLObject is a Python ORM.
Brought to you by:
ianbicking,
phd
From: Ilias L. <il...@la...> - 2006-10-09 00:16:25
|
I have decided to not use SqlObject [1]. What the project should possibly do: * Create a new mailinglist (e.g. on Google Groups), thus the spam-problem is reduced. The new groups should of course still be available with the nntp interface (gmane). This step enables _communication_ around SQLObject. (SQLAlchemy has recently moved to google groups and I assume the would assist this project with this step). * The remaining developers should focus to provide an sqlobject API compatibility layer for SQLAlchemy. This way existent software can migrate without many effort. I am sure that some projects would provide support for this (SQLAlchemy itself, TurboGears). * The project should move away from sourceforge. Trac provides nice functionality for small to medium scale open source projects. * At a minimum, the project should inform potential users about the low activity on the SQLObject project. The project lead should of course support all this moves. - [1] http://case.lazaridis.com/wiki/SqlObjectAudit . |
From: Jorge V. <jor...@gm...> - 2006-10-09 01:54:19
|
On 10/8/06, Ilias Lazaridis <il...@la...> wrote: > I have decided to not use SqlObject [1]. > > What the project should possibly do: > > * Create a new mailinglist (e.g. on Google Groups), thus the > spam-problem is reduced. The new groups should of course still be > available with the nntp interface (gmane). This step enables > _communication_ around SQLObject. (SQLAlchemy has recently moved to > google groups and I assume the would assist this project with this step). > I agree with that googlegroups is great at filtering spam. > * The remaining developers should focus to provide an sqlobject API > compatibility layer for SQLAlchemy. This way existent software can > migrate without many effort. I am sure that some projects would provide > support for this (SQLAlchemy itself, TurboGears). > I don't see why #1 SQLObject2 will provide much of the stuff SA currently does. #2 this "layer" already exists and it's call active mapper which is in SA trunk. > * The project should move away from sourceforge. Trac provides nice > functionality for small to medium scale open source projects. > yes and you need to host it. I don't see why sf is so bad, I use trac for my stuff but that's me. > * At a minimum, the project should inform potential users about the low > activity on the SQLObject project. > Honestly I don't see why SO is "low activity" at the moment all the features it's supposed to have are there and working. > The project lead should of course support all this moves. > man... I just wasted my time, take a look at http://en.wikipedia.org/wiki/Ilias_Lazaridis > - > > [1] > http://case.lazaridis.com/wiki/SqlObjectAudit > > . > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > sqlobject-discuss mailing list > sql...@li... > https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss > |
From: Ilias L. <il...@la...> - 2006-10-09 02:31:05
|
Jorge Vargas wrote: > On 10/8/06, Ilias Lazaridis <il...@la...> wrote: >> I have decided to not use SqlObject [1]. >> >> What the project should possibly do: >> >> * Create a new mailinglist (e.g. on Google Groups), thus the >> spam-problem is reduced. The new groups should of course still be >> available with the nntp interface (gmane). This step enables >> _communication_ around SQLObject. (SQLAlchemy has recently moved to >> google groups and I assume the would assist this project with this step). >> > I agree with that googlegroups is great at filtering spam. ok >> * The remaining developers should focus to provide an sqlobject API >> compatibility layer for SQLAlchemy. This way existent software can >> migrate without many effort. I am sure that some projects would provide >> support for this (SQLAlchemy itself, TurboGears). >> > I don't see why > #1 SQLObject2 will provide much of the stuff SA currently does. SQLObject2 is even more inactive: http://www.webwareforpython.org/archives/message/20060223.053837.bacf323d.en.html http://sqlobject.org/2/ > #2 this "layer" already exists and it's call active mapper which is in SA trunk. I don't think it's API compatible with SQLObject. But of course developers could contribute to this, too. >> * The project should move away from sourceforge. Trac provides nice >> functionality for small to medium scale open source projects. >> > yes and you need to host it. I don't see why sf is so bad, I use trac > for my stuff but that's me. I (and many other's, including the python foundation) seem to see them. >> * At a minimum, the project should inform potential users about the low >> activity on the SQLObject project. >> > Honestly I don't see why SO is "low activity" at the moment all the > features it's supposed to have are there and working. An ORM for a dynamic language without schema evolution support? Additionally, please review the statements of some team members within this thread: http://thread.gmane.org/gmane.comp.python.sqlobject/6910/focus=6910 >> The project lead should of course support all this moves. >> > man... I just wasted my time, take a look at > http://en.wikipedia.org/wiki/Ilias_Lazaridis I see. Hopefully the project-lead makes the right steps to save the (ptential) userbase from future trouble. >> [1] >> http://case.lazaridis.com/wiki/SqlObjectAudit >> >> . -- http://lazaridis.com |
From: Jorge V. <jor...@gm...> - 2006-10-09 02:48:10
|
On 10/8/06, Ilias Lazaridis <il...@la...> wrote: > Jorge Vargas wrote: > > On 10/8/06, Ilias Lazaridis <il...@la...> wrote: > >> I have decided to not use SqlObject [1]. > >> > >> What the project should possibly do: > >> > >> * Create a new mailinglist (e.g. on Google Groups), thus the > >> spam-problem is reduced. The new groups should of course still be > >> available with the nntp interface (gmane). This step enables > >> _communication_ around SQLObject. (SQLAlchemy has recently moved to > >> google groups and I assume the would assist this project with this step). > >> > > I agree with that googlegroups is great at filtering spam. > > ok > > >> * The remaining developers should focus to provide an sqlobject API > >> compatibility layer for SQLAlchemy. This way existent software can > >> migrate without many effort. I am sure that some projects would provide > >> support for this (SQLAlchemy itself, TurboGears). > >> > > I don't see why > > #1 SQLObject2 will provide much of the stuff SA currently does. > > SQLObject2 is even more inactive: > > http://www.webwareforpython.org/archives/message/20060223.053837.bacf323d.en.html > > http://sqlobject.org/2/ > then get the code and start working on it. > > #2 this "layer" already exists and it's call active mapper which is in SA trunk. > > I don't think it's API compatible with SQLObject. > it's goal is to emulate SO-like interfaces. of course it can't be 100% because the underlaying layer is not SO > But of course developers could contribute to this, too. > > >> * The project should move away from sourceforge. Trac provides nice > >> functionality for small to medium scale open source projects. > >> > > yes and you need to host it. I don't see why sf is so bad, I use trac > > for my stuff but that's me. > > I (and many other's, including the python foundation) seem to see them. > then provide a trac for SO, I don't see why trac is so important vrs SF, it's a matter of taste. > >> * At a minimum, the project should inform potential users about the low > >> activity on the SQLObject project. > >> > > Honestly I don't see why SO is "low activity" at the moment all the > > features it's supposed to have are there and working. > > An ORM for a dynamic language without schema evolution support? > actually who doesn't supports dynamic language schema evolution is the underlaying DBs, on the other hard SO can add and remove cols at runtime, it is not the best thing I have to admit but it's there. I seems to me that you only know SO from it's integration to TG, and at that point your right from TG perspective the only way to change the db schema is tg-admin sql drop && tg-admin sql create. > Additionally, please review the statements of some team members within > this thread: > > http://thread.gmane.org/gmane.comp.python.sqlobject/6910/focus=6910 > that is what you get went a project has more people using it then maintaining it. > >> The project lead should of course support all this moves. > >> > > man... I just wasted my time, take a look at > > http://en.wikipedia.org/wiki/Ilias_Lazaridis > > I see. > and looking at the TG thread it seems you made quite a reputation on the django list. > Hopefully the project-lead makes the right steps to save the (ptential) > userbase from future trouble. > I don't want to know what that means Removed spam > sqlobject-discuss mailing list > sql...@li... > https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss > |
From: Ilias L. <il...@la...> - 2006-10-09 03:08:58
|
Jorge Vargas wrote: > On 10/8/06, Ilias Lazaridis <il...@la...> wrote: >> Jorge Vargas wrote: >>> On 10/8/06, Ilias Lazaridis <il...@la...> wrote: >>>> I have decided to not use SqlObject [1]. >>>> >>>> What the project should possibly do: >>>> >>>> * Create a new mailinglist (e.g. on Google Groups), thus the >>>> spam-problem is reduced. The new groups should of course still be >>>> available with the nntp interface (gmane). This step enables >>>> _communication_ around SQLObject. (SQLAlchemy has recently moved to >>>> google groups and I assume the would assist this project with this step). >>>> >>> I agree with that googlegroups is great at filtering spam. >> ok >> >>>> * The remaining developers should focus to provide an sqlobject API >>>> compatibility layer for SQLAlchemy. This way existent software can >>>> migrate without many effort. I am sure that some projects would provide >>>> support for this (SQLAlchemy itself, TurboGears). >>>> >>> I don't see why >>> #1 SQLObject2 will provide much of the stuff SA currently does. >> SQLObject2 is even more inactive: >> >> http://www.webwareforpython.org/archives/message/20060223.053837.bacf323d.en.html >> >> http://sqlobject.org/2/ >> > then get the code and start working on it. why? to backup you statement "#1 SQLObject2 will provide much of the stuff SA currently does." ? No need, I'll choose another product, where contribution makes sense. >>> #2 this "layer" already exists and it's call active mapper which is in SA trunk. >> I don't think it's API compatible with SQLObject. >> > it's goal is to emulate SO-like interfaces. of course it can't be 100% > because the underlaying layer is not SO So, some developers with SQLObject knowledge could possibly contribute, would make the situation better. >> But of course developers could contribute to this, too. >> >>>> * The project should move away from sourceforge. Trac provides nice >>>> functionality for small to medium scale open source projects. >>>> >>> yes and you need to host it. I don't see why sf is so bad, I use trac >>> for my stuff but that's me. >> I (and many other's, including the python foundation) seem to see them. >> > then provide a trac for SO, I don't see why trac is so important vrs > SF, it's a matter of taste. consistency and coherency. >>>> * At a minimum, the project should inform potential users about the low >>>> activity on the SQLObject project. >>>> >>> Honestly I don't see why SO is "low activity" at the moment all the >>> features it's supposed to have are there and working. >> An ORM for a dynamic language without schema evolution support? >> > actually who doesn't supports dynamic language schema evolution is the > underlaying DBs, on the other hard SO can add and remove cols at > runtime, it is not the best thing I have to admit but it's there. > > I seems to me that you only know SO from it's integration to TG, and > at that point your right from TG perspective the only way to change > the db schema is tg-admin sql drop && tg-admin sql create. SQLObject does not support schema evolution (the underlying databases do). There's really no need to twist the facts. >> Additionally, please review the statements of some team members within >> this thread: >> >> http://thread.gmane.org/gmane.comp.python.sqlobject/6910/focus=6910 >> > that is what you get went a project has more people using it then > maintaining it. Or when not providing the right motivation to maintain it. >>>> The project lead should of course support all this moves. >>>> >>> man... I just wasted my time, take a look at >>> http://en.wikipedia.org/wiki/Ilias_Lazaridis >> I see. >> > and looking at the TG thread it seems you made quite a reputation on > the django list. http://case.lazaridis.com/wiki/DjangoAudit >> Hopefully the project-lead makes the right steps to save the (ptential) >> userbase from future trouble. >> > I don't want to know what that means As suggested, the project lead should shutdown this project (or at least place a visible remark on the website), thus other people to not loose time in evaluating an non-maintained solution. > Removed spam . -- http://lazaridis.com |
From: Jorge V. <jor...@gm...> - 2006-10-09 03:46:53
|
On 10/8/06, Ilias Lazaridis <il...@la...> wrote: > Jorge Vargas wrote: > > On 10/8/06, Ilias Lazaridis <il...@la...> wrote: > >> Jorge Vargas wrote: > >>> On 10/8/06, Ilias Lazaridis <il...@la...> wrote: > >>>> I have decided to not use SqlObject [1]. > >>>> > >>>> What the project should possibly do: > >>>> > >>>> * Create a new mailinglist (e.g. on Google Groups), thus the > >>>> spam-problem is reduced. The new groups should of course still be > >>>> available with the nntp interface (gmane). This step enables > >>>> _communication_ around SQLObject. (SQLAlchemy has recently moved to > >>>> google groups and I assume the would assist this project with this step). > >>>> > >>> I agree with that googlegroups is great at filtering spam. > >> ok > >> > >>>> * The remaining developers should focus to provide an sqlobject API > >>>> compatibility layer for SQLAlchemy. This way existent software can > >>>> migrate without many effort. I am sure that some projects would provide > >>>> support for this (SQLAlchemy itself, TurboGears). > >>>> > >>> I don't see why > >>> #1 SQLObject2 will provide much of the stuff SA currently does. > >> SQLObject2 is even more inactive: > >> > >> http://www.webwareforpython.org/archives/message/20060223.053837.bacf323d.en.html > >> > >> http://sqlobject.org/2/ > >> > > then get the code and start working on it. > > why? > > to backup you statement "#1 SQLObject2 will provide much of the stuff SA > currently does." ? > > No need, I'll choose another product, where contribution makes sense. > then don't complain and leave. I don't see what's the idea of complaining and not doing anything to help. > >>> #2 this "layer" already exists and it's call active mapper which is in SA trunk. > >> I don't think it's API compatible with SQLObject. > >> > > it's goal is to emulate SO-like interfaces. of course it can't be 100% > > because the underlaying layer is not SO > > So, some developers with SQLObject knowledge could possibly contribute, > would make the situation better. > why? have you even seen active mapper? it's as closest as it can be. > >> But of course developers could contribute to this, too. > >> > >>>> * The project should move away from sourceforge. Trac provides nice > >>>> functionality for small to medium scale open source projects. > >>>> > >>> yes and you need to host it. I don't see why sf is so bad, I use trac > >>> for my stuff but that's me. > >> I (and many other's, including the python foundation) seem to see them. > >> > > then provide a trac for SO, I don't see why trac is so important vrs > > SF, it's a matter of taste. > > consistency and coherency. > huh? if they like SF then let them. > >>>> * At a minimum, the project should inform potential users about the low > >>>> activity on the SQLObject project. > >>>> > >>> Honestly I don't see why SO is "low activity" at the moment all the > >>> features it's supposed to have are there and working. > >> An ORM for a dynamic language without schema evolution support? > >> > > actually who doesn't supports dynamic language schema evolution is the > > underlaying DBs, on the other hard SO can add and remove cols at > > runtime, it is not the best thing I have to admit but it's there. > > > > I seems to me that you only know SO from it's integration to TG, and > > at that point your right from TG perspective the only way to change > > the db schema is tg-admin sql drop && tg-admin sql create. > > SQLObject does not support schema evolution (the underlying databases do). > > There's really no need to twist the facts. > I know see why people don't like you. Are you saying SO is bad because it doesn't has X or Y feature. if that the case I guess all your "reviews" are bad > >> Additionally, please review the statements of some team members within > >> this thread: > >> > >> http://thread.gmane.org/gmane.comp.python.sqlobject/6910/focus=6910 > >> > > that is what you get went a project has more people using it then > > maintaining it. > > Or when not providing the right motivation to maintain it. > or because it was not written to do that and people want it to be therefore summiting bad patches and going mad because "those bastards don't like my code" > >>>> The project lead should of course support all this moves. > >>>> > >>> man... I just wasted my time, take a look at > >>> http://en.wikipedia.org/wiki/Ilias_Lazaridis > >> I see. > >> > > and looking at the TG thread it seems you made quite a reputation on > > the django list. > > http://case.lazaridis.com/wiki/DjangoAudit > dude you got banned from the list. I think you should take that out of your "resume" > >> Hopefully the project-lead makes the right steps to save the (ptential) > >> userbase from future trouble. > >> > > I don't want to know what that means > > As suggested, the project lead should shutdown this project (or at least > place a visible remark on the website), thus other people to not loose > time in evaluating an non-maintained solution. I'm sorry but who are you to suggest that kind of thing? I have never seen you post on this list and you come in as if you have authority to anything. SO is a great tool at what it was made to do, and that is make ORM a no brainer with nice flexibility, now today people want to push non Object Oriented Relational tables into ORM and they expect it to work? I mean do your stuff and do it right. ORM are not easy ways to access a database, it's a whole diferent thing. now if (and i'm sure your thinking of this) SA is great at doing that then let it be it's goal is to provide a nice mapper pattern in which you tell your object where to pull it's data. Which for a pure Object - DB abstraction is not the best aprroach. SO serves a purpose that SA can't fill in that's why they are 2 approaches to the same problem. Projects like TG are moving to SA not because SO is bad or not maintained, is because SA is more flexible to the TG userbase. and if you "wasted your time evaluating this" then why your replying to my emails? > > Removed spam Do you spam with every message you send out? > _______________________________________________ > sqlobject-discuss mailing list > sql...@li... > https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss > |
From: Ilias L. <il...@la...> - 2006-10-09 04:32:35
|
Jorge Vargas wrote: > On 10/8/06, Ilias Lazaridis <il...@la...> wrote: ... >> No need, I'll choose another product, where contribution makes sense. >> > then don't complain and leave. I don't see what's the idea of > complaining and not doing anything to help. I've already started to help out. ... >> So, some developers with SQLObject knowledge could possibly contribute, >> would make the situation better. >> > why? have you even seen active mapper? it's as closest as it can be. ok ... >>> then provide a trac for SO, I don't see why trac is so important vrs >>> SF, it's a matter of taste. >> consistency and coherency. >> > huh? if they like SF then let them. fine. >> There's really no need to twist the facts. >> > I know see why people don't like you. Are you saying SO is bad because > it doesn't has X or Y feature. if that the case I guess all your > "reviews" are bad http://case.lazaridis.com/wiki/SqlObjectAudit >> http://case.lazaridis.com/wiki/DjangoAudit >> > dude you got banned from the list. I think you should take that out of > your "resume" " This audit demonstrates mainly: * Open Source does not mean "a right to participate" * Change Resistance within Open Source Projects * Methods to apply a Rework without any support from the project/community " > and if you "wasted your time evaluating this" then why your replying > to my emails? Just as I've not yet lost my hope. With all disagreement, I think anyone should agree to the first point I've raised: Move the list to a spam free place (e.g. google groups). . -- http://lazaridis.com |
From: Peter B. <pet...@14...> - 2006-10-09 03:35:35
|
Hi Ilias I don't profess to speak for the developers of SQLObject but I like the project and find it extremely useful. Oleg does a fantastic job of maintaining the project and responds to intelligent queries and bug reports quickly. >>> SQLObject2 is even more inactive: >>> >> then get the code and start working on it. >> > why? > This is the idea behind open-source software. If you see a lack in some area then you are welcome to contribute code and documentation. > No need, I'll choose another product, where contribution makes sense. > You are most welcome to choose another product. I hope they appreciate your contribution as much as we have. > SQLObject does not support schema evolution (the underlying databases do). > > There's really no need to twist the facts. > As suggested, the project lead should shutdown this project (or at least > place a visible remark on the website), thus other people to not loose > time in evaluating an non-maintained solution. You have made your points perfectly clear, and there is no need to reiterate them in separate messages. If you are not happy with the solution provided by SQLObject then please do find another project to get involved with. Cheers Peter Butler |
From: Ilias L. <il...@la...> - 2006-10-09 04:22:19
|
Peter Butler wrote: > Hi Ilias > > I don't profess to speak for the developers of SQLObject but I like the > project and find it extremely useful. Oleg does a fantastic job of > maintaining the project and responds to intelligent queries and bug > reports quickly. ok, very nice. Possibly he can setup a google-group, thus the mailing-list becomes cleaner. >>>> SQLObject2 is even more inactive: >>>> >>> then get the code and start working on it. >>> >> why? >> > This is the idea behind open-source software. If you see a lack in some > area then you are welcome to contribute code and documentation. But the project resources are non-operative. >> No need, I'll choose another product, where contribution makes sense. >> > You are most welcome to choose another product. I hope they appreciate > your contribution as much as we have. >> SQLObject does not support schema evolution (the underlying databases do). >> >> There's really no need to twist the facts. >> As suggested, the project lead should shutdown this project (or at least >> place a visible remark on the website), thus other people to not loose >> time in evaluating an non-maintained solution. > You have made your points perfectly clear, and there is no need to > reiterate them in separate messages. If you are not happy with the > solution provided by SQLObject then please do find another project to > get involved with. I am not yet ready to leave, as I really like the simplicity behing SQLObject. . -- http://lazaridis.com |
From: Oleg B. <ph...@ph...> - 2006-10-09 08:59:43
|
Hello! On Mon, Oct 09, 2006 at 03:16:01AM +0300, Ilias Lazaridis wrote: > I have decided to not use SqlObject [1]. Thank you for stopping by and for your valuable contribution. Unfortunately you observations are a bit biased. Let me show another point of view. > What the project should possibly do: > > * Create a new mailinglist (e.g. on Google Groups), thus the > spam-problem is reduced. There is no any "spam-problem". In 10 days of October there were 18 messages in the mailing list, only two of them were spam. No problem here, a little annoyance at best. On the other hand asking a hundred of people to resubscribe would be a real pain. > * The remaining developers should focus They should not. There are a lot of tasks in our TODO, some bigger, some smaller. SQLObject is being used in free and proprietary applications, so these tasks are real tasks. No need to invent tasks nobody is interested in. > * The project should move away from sourceforge. Trac provides nice > functionality for small to medium scale open source projects. Absolutely! This time I agree with you 100%! Please install Trac at your hosting provider and be our Trac admin. Import the data from the SF tracker. You don't need to do it manually - there are tools for automatic import. When you are ready - send instructions how to register and where to login. > * At a minimum, the project should inform potential users about the low > activity on the SQLObject project. May be activity here is so low there is nobody who really can make such a warning. ;) Or may be activity is high enough there is no need in any false warning. 2All: Many thanks to all good people who have expressed support! Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Ilias L. <il...@la...> - 2006-10-10 01:04:30
|
Oleg Broytmann wrote: > Hello! > > On Mon, Oct 09, 2006 at 03:16:01AM +0300, Ilias Lazaridis wrote: >> I have decided to not use SqlObject [1]. > > Thank you for stopping by and for your valuable contribution. > Unfortunately you observations are a bit biased. Let me show another point > of view. ok >> What the project should possibly do: >> >> * Create a new mailinglist (e.g. on Google Groups), thus the >> spam-problem is reduced. > > There is no any "spam-problem". In 10 days of October there were 18 > messages in the mailing list, only two of them were spam. No problem here, > a little annoyance at best. I see >10 spam messages within the gmane archive (which means more spam than messages) > On the other hand asking a hundred of people to resubscribe would be a > real pain. very simple: * Anoounce that the group will move on day x * create a google group. * announce (on the list) that people should subscribe to the list * switch to the google group * remember to update gmane to get the google email >> * The remaining developers should focus > > They should not. There are a lot of tasks in our TODO, some bigger, some > smaller. SQLObject is being used in free and proprietary applications, so > these tasks are real tasks. No need to invent tasks nobody is interested in. One of the most important points within development is: knowing when to stop. possibly this point is reached for SQLObject, not sure yet, see below. >> * The project should move away from sourceforge. Trac provides nice >> functionality for small to medium scale open source projects. > > Absolutely! This time I agree with you 100%! Please install Trac at your > hosting provider and be our Trac admin. Import the data from the SF > tracker. You don't need to do it manually - there are tools for automatic > import. > When you are ready - send instructions how to register and where to > login. I provide such services, commercially: http://dev.lazaridis.com/base/wiki/CommercialServices Although I _would_ possibly provide this for free for SQLObject, but I should see some activity, see below. >> * At a minimum, the project should inform potential users about the low >> activity on the SQLObject project. > > May be activity here is so low there is nobody who really can make such > a warning. ;) Or may be activity is high enough there is no need in any > false warning. > > 2All: Many thanks to all good people who have expressed support! May I suggest that you move over to google groups (= mailinglist with good spamfilter, web-interface, search-functionality). This has the additional benefit of giving sqlobject some more visibility. Having an communication-resource again, I would the want to implement the schema-evolution support (in cooperation with the existent people here). If things go fine with 0.7.2 (including basic evolution support), I would then provide the setup of the trac-infrastructure (_possibly_ I could provide the hosting, too) How does this sound? . -- http://lazaridis.com |
From: Ilias L. <il...@la...> - 2006-10-10 21:23:48
|
Jorge Vargas wrote: ... Sorry, I'm awaiting the response of Mr. Broytmann . -- http://lazaridis.com |
From: Oleg B. <ph...@ph...> - 2006-10-10 10:30:57
|
Hello. On Tue, Oct 10, 2006 at 03:55:34AM +0300, Ilias Lazaridis wrote: > I see >10 spam messages within the gmane archive (which means more spam > than messages) At http://news.gmane.org/gmane.comp.python.sqlobject I see one spam message in about every ten SQLObject message. A bit annoying but certainly far from "more spam than messages". > > On the other hand asking a hundred of people to resubscribe would be a > > real pain. > > very simple: > > * Anoounce that the group will move on day x > * create a google group. > * announce (on the list) that people should subscribe to the list > * switch to the google group > * remember to update gmane to get the google email What to do with people who will be more annoyed by the switch than by the spam? with people who will decide that the switch isn't worth the trouble and will leave the community? "Ignore" is not an option, IMO. > One of the most important points within development is: > > knowing when to stop. > > possibly this point is reached for SQLObject, not sure yet, see below. I am sure it is not. There is no a least reason to stop developing, and there are many reasons to continue: 1) there are many people who relies on SQLObject, it would be pity to disappoint them by abandoning the project; 2) I enjoy working on SQLObject; 3) I use SQLObject in free programs, our company uses it in a number of commercial programs, we are satisfied with SQLObject, no need to bother ourselves with switching. > May I suggest that you move over to google groups (= mailinglist with > good spamfilter, web-interface, search-functionality). You may. But the suggestion was not supported by the active majority. May be people don't feel the pain, especially comparing with the pain of switching. > Having an communication-resource again, I would the want to implement > the schema-evolution support (in cooperation with the existent people here). Patches of appropriate quality will be gladly accepted! > If things go fine with 0.7.2 0.7-bugix branch is reserved for bugfixes. New feature will go to the trunk and will be available in release 0.8. Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Ilias L. <il...@la...> - 2006-10-10 20:49:35
|
Oleg Broytmann wrote: > Hello. > > On Tue, Oct 10, 2006 at 03:55:34AM +0300, Ilias Lazaridis wrote: >> I see >10 spam messages within the gmane archive (which means more spam >> than messages) > > At http://news.gmane.org/gmane.comp.python.sqlobject I see one spam > message in about every ten SQLObject message. A bit annoying but certainly > far from "more spam than messages". ok, then: more spam topics than real topics. Do you really have to discuss this? The list is amateurish. >>> On the other hand asking a hundred of people to resubscribe would be a >>> real pain. >> very simple: >> >> * Anoounce that the group will move on day x >> * create a google group. >> * announce (on the list) that people should subscribe to the list >> * switch to the google group >> * remember to update gmane to get the google email > > What to do with people who will be more annoyed by the switch than by > the spam? with people who will decide that the switch isn't worth the > trouble and will leave the community? "Ignore" is not an option, IMO. You should think more about _new_ people which like to join the project. when looking at the archives, they see more spam threads the development threds. Really nice impression. Who would join a project seeing such a list? >> One of the most important points within development is: >> >> knowing when to stop. >> >> possibly this point is reached for SQLObject, not sure yet, see below. > > I am sure it is not. There is no a least reason to stop developing, and > there are many reasons to continue: > > 1) there are many people who relies on SQLObject, it would be pity to > disappoint them by abandoning the project; > 2) I enjoy working on SQLObject; > 3) I use SQLObject in free programs, our company uses it in a number of > commercial programs, we are satisfied with SQLObject, no need to bother > ourselves with switching. ok >> May I suggest that you move over to google groups (= mailinglist with >> good spamfilter, web-interface, search-functionality). > > You may. But the suggestion was not supported by the active majority. > May be people don't feel the pain, especially comparing with the pain of > switching. > >> Having an communication-resource again, I would the want to implement >> the schema-evolution support (in cooperation with the existent people here). > > Patches of appropriate quality will be gladly accepted! > >> If things go fine with 0.7.2 > > 0.7-bugix branch is reserved for bugfixes. New feature will go to the > trunk and will be available in release 0.8. > > Oleg. You've ommitted the central par of my message: [REQUOTE] I provide such services, commercially: http://dev.lazaridis.com/base/wiki/CommercialServices Although I _would_ possibly provide this for free for SQLObject, but I should see some activity, see below. [...] May I suggest that you move over to google groups (= mailinglist with good spamfilter, web-interface, search-functionality). This has the additional benefit of giving sqlobject some more visibility. Having an communication-resource again, I would the want to implement the schema-evolution support (in cooperation with the existent people here). If things go fine with 0.7.2 (including basic evolution support), I would then provide the setup of the trac-infrastructure (_possibly_ I could provide the hosting, too) How does this sound? [/REQUOTE] So, i've offered to contribute a basic schema-evolution-support to SQLObject (for version 0.8) _and_ a setup of a trac based infrastructure and (possibly) the hosting, too. I ask the project just to get control over this "more spam-threads than content-threads" problem, (_one_ solution: move to google groups). . -- http://lazaridis.com |
From: Jorge V. <jor...@gm...> - 2006-10-10 21:12:30
|
On 10/10/06, Ilias Lazaridis <il...@la...> wrote: > Oleg Broytmann wrote: > > Hello. > > > > On Tue, Oct 10, 2006 at 03:55:34AM +0300, Ilias Lazaridis wrote: > >> I see >10 spam messages within the gmane archive (which means more spam > >> than messages) > > > > At http://news.gmane.org/gmane.comp.python.sqlobject I see one spam > > message in about every ten SQLObject message. A bit annoying but certainly > > far from "more spam than messages". > > ok, then: more spam topics than real topics. > > Do you really have to discuss this? > > The list is amateurish. > news flash amateur today is many times better then corporate. and spam is spam your changing the topic here, if you really want something you will get it. lists are lists they are emails going back and forth it's no measure of the quality of the project. much less of the code of the project. > >>> On the other hand asking a hundred of people to resubscribe would be a > >>> real pain. > >> very simple: > >> > >> * Anoounce that the group will move on day x > >> * create a google group. > >> * announce (on the list) that people should subscribe to the list > >> * switch to the google group > >> * remember to update gmane to get the google email > > > > What to do with people who will be more annoyed by the switch than by > > the spam? with people who will decide that the switch isn't worth the > > trouble and will leave the community? "Ignore" is not an option, IMO. > > You should think more about _new_ people which like to join the project. > > when looking at the archives, they see more spam threads the development > threds. > then write a plugin/extension/etc for the mailing list software this is help a LOT of opensource groups, instead of avoiding the real problem. > Really nice impression. > > Who would join a project seeing such a list? > noone goes to the list they download the code and check it out, they go to the website and just then (if ever) go to the mailing list. > >> One of the most important points within development is: > >> > >> knowing when to stop. > >> FUD > You've ommitted the central par of my message: > > [REQUOTE] > I provide such services, commercially: > > http://dev.lazaridis.com/base/wiki/CommercialServices > > Although I _would_ possibly provide this for free for SQLObject, but I > should see some activity, see below. > I'll do it for free to SO. > > May I suggest that you move over to google groups (= mailinglist with > good spamfilter, web-interface, search-functionality). > > This has the additional benefit of giving sqlobject some more visibility. > that's ridiculous noone browsers googlegroup looking for projects.... > Having an communication-resource again, I would the want to implement > the schema-evolution support (in cooperation with the existent people here). > > If things go fine with 0.7.2 (including basic evolution support), I > would then provide the setup of the trac-infrastructure (_possibly_ I > could provide the hosting, too) dude please read your replies 0.7.2 will be bug fix only ANY new features aka evolution support will go in 0.8 on the other hand I don't see why you have to precondition your support... > > How does this sound? show me the code. > [/REQUOTE] > > So, i've offered to contribute a basic schema-evolution-support to > SQLObject (for version 0.8) _and_ a setup of a trac based infrastructure > and (possibly) the hosting, too. > > I ask the project just to get control over this "more spam-threads than > content-threads" problem, (_one_ solution: move to google groups). > > . > > -- > http://lazaridis.com > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > sqlobject-discuss mailing list > sql...@li... > https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss > |
From: Dan P. <da...@ag...> - 2006-10-10 21:56:55
|
On Monday 09 October 2006 07:21, Ilias Lazaridis wrote: > >> No need, I'll choose another product, where contribution makes > >> sense. > >> > >> As suggested, the project lead should shutdown this project (or at > >> least place a visible remark on the website), thus other people to > >> not loose time in evaluating an non-maintained solution. > > > > You have made your points perfectly clear, and there is no need to > > reiterate them in separate messages. If you are not happy with the > > solution provided by SQLObject then please do find another project to > > get involved with. > > I am not yet ready to leave, as I really like the simplicity behing > SQLObject. You are the most confused individual I have ever seen (or maybe you are not, but you try to confuse us to get to your ends). One paragraph you suggest that the project should be shut down because it's inactive and tell us that you are looking for another project to contribute to, and 5 lines later you say that you are not ready to leave?!? Make up your mind. If it's really that dead to you and not worth considering just leave and don't look back, else if it's worth to you but incomplete, then start contributing something (other than annoying indications of what others should do to improve things). -- Dan |
From: Ilias L. <il...@la...> - 2006-10-10 22:15:44
|
Dan Pascu wrote: > On Monday 09 October 2006 07:21, Ilias Lazaridis wrote: >>>> No need, I'll choose another product, where contribution makes >>>> sense. >>>> >>>> As suggested, the project lead should shutdown this project (or at >>>> least place a visible remark on the website), thus other people to >>>> not loose time in evaluating an non-maintained solution. >>> You have made your points perfectly clear, and there is no need to >>> reiterate them in separate messages. If you are not happy with the >>> solution provided by SQLObject then please do find another project to >>> get involved with. >> I am not yet ready to leave, as I really like the simplicity behing >> SQLObject. > > You are the most confused individual I have ever seen (or maybe you are > not, but you try to confuse us to get to your ends). > > One paragraph you suggest that the project should be shut down because > it's inactive and tell us that you are looking for another project to > contribute to, and 5 lines later you say that you are not ready to > leave?!? what's so special with this? people have convinced me that the project is not _thus_ inactive as I have seen it. > Make up your mind. If it's really that dead to you and not worth > considering just leave and don't look back, else if it's worth to you but > incomplete, then start contributing something (other than annoying > indications of what others should do to improve things). I've 'made up my mind' and have suggested several things to the project maintainer. . -- http://lazaridis.com |
From: Jorge V. <jor...@gm...> - 2006-10-10 22:26:34
|
On 10/10/06, Ilias Lazaridis <il...@la...> wrote: > Jorge Vargas wrote: > ... > > Sorry, I'm awaiting the response of Mr. Broytmann > now I see why you got banned from django. just to remind you I'll do what you offer FOR FREE, at least what you have on your "site" which says nothing about the actual hosting and bandwidth. |
From: Ilias L. <il...@la...> - 2006-10-10 22:45:18
|
Jorge Vargas wrote: > On 10/10/06, Ilias Lazaridis <il...@la...> wrote: >> Jorge Vargas wrote: >> ... >> >> Sorry, I'm awaiting the response of Mr. Broytmann >> > now I see why you got banned from django. > > just to remind you I'll do what you offer FOR FREE, Ok, then setup a trac for SQLObject. > at least what you > have on your "site" which says nothing about the actual hosting and > bandwidth. I do not offer hosting services. . -- http://lazaridis.com |
From: Dan P. <da...@ag...> - 2006-10-10 22:27:33
|
On Tuesday 10 October 2006 23:48, Ilias Lazaridis wrote: > You've ommitted the central par of my message: Maybe it was his polite way of saying he is not interested. You really insult the intelligence of people on this list continuing to make these posts after your modus operandi was exposed by some people who found out how you interacted with other opensource projects. Considering your dubious record on interaction with other projects, the fact that you managed the sad record of having a wikipedia page that portrays you in a bad light and shows you use dubious practices when you interact with an opensource project, and also the fact that you were banned from multiple project's mailing list where project authors claim you blackmailed them, tell more than enough about you to prevent you from fooling people anymore with posts like the one below. Given what people working on respected opensource projects have to say about you, I wouldn't trust you with taking out my garbage can. Even though you claim to consider providing free infrastructure and hosting for sqlobject, I wouldn't be surprised if that would change soon after the project would be moved to your premises, seeing how you advertise your commercial offer here. And even if not, I believe it's just a way to get yourself more leverage in pushing your agenda regarding the management of the project resources your way. I'm sure Oleg is smart enough to understand that hosting the project on a public dedicated hosting server is much better than using a private individual's hosting offer. Even if that individual would be honest in his intentions (which I do not believe you are), sooner or later he will stop supporting the project, either because he looses interest or because he is no longer able to. At that point the project will have to move again with all the implied annoyances. So stop your FUD and if you want to contribute something, just provide the patches as everybody else, instead of empty promises conditioned by things being changed your way first. > > [REQUOTE] > I provide such services, commercially: > > http://dev.lazaridis.com/base/wiki/CommercialServices > > Although I _would_ possibly provide this for free for SQLObject, but I > should see some activity, see below. > > [...] > > May I suggest that you move over to google groups (= mailinglist with > good spamfilter, web-interface, search-functionality). > > This has the additional benefit of giving sqlobject some more > visibility. > > Having an communication-resource again, I would the want to implement > the schema-evolution support (in cooperation with the existent people > here). > > If things go fine with 0.7.2 (including basic evolution support), I > would then provide the setup of the trac-infrastructure (_possibly_ I > could provide the hosting, too) > > How does this sound? > [/REQUOTE] > > So, i've offered to contribute a basic schema-evolution-support to > SQLObject (for version 0.8) _and_ a setup of a trac based > infrastructure and (possibly) the hosting, too. > > I ask the project just to get control over this "more spam-threads than > content-threads" problem, (_one_ solution: move to google groups). > > . -- Dan |
From: Ilias L. <il...@la...> - 2006-10-10 22:40:37
|
Dan Pascu wrote: > On Tuesday 10 October 2006 23:48, Ilias Lazaridis wrote: >> You've ommitted the central par of my message: > > Maybe it was his polite way of saying he is not interested. You really ... > I'm sure Oleg is smart enough to understand that hosting the project on a > public dedicated hosting server is much better than using a private > individual's hosting offer. ... [REQUOTE Oleg Broytmann] " Absolutely! This time I agree with you 100%! Please install Trac at your hosting provider and be our Trac admin. Import the data from the SF tracker. You don't need to do it manually - there are tools for automatic import. When you are ready - send instructions how to register and where to login. " [/REQUOTE] (clarification: I do _not_ provide hosting services.) So, to summarize: I am willing to contribute (for free or course), code level work (schema evolution support) and project support (trac _setup_, eventually(!!!) hosting), after this project moves it's spam loaded list elsewere. >> [REQUOTE] >> I provide such services, commercially: >> >> http://dev.lazaridis.com/base/wiki/CommercialServices >> >> Although I _would_ possibly provide this for free for SQLObject, but I >> should see some activity, see below. >> >> [...] >> >> May I suggest that you move over to google groups (= mailinglist with >> good spamfilter, web-interface, search-functionality). >> >> This has the additional benefit of giving sqlobject some more >> visibility. >> >> Having an communication-resource again, I would the want to implement >> the schema-evolution support (in cooperation with the existent people >> here). >> >> If things go fine with 0.7.2 (including basic evolution support), I >> would then provide the setup of the trac-infrastructure (_possibly_ I >> could provide the hosting, too) >> >> How does this sound? >> [/REQUOTE] >> >> So, i've offered to contribute a basic schema-evolution-support to >> SQLObject (for version 0.8) _and_ a setup of a trac based >> infrastructure and (possibly) the hosting, too. >> >> I ask the project just to get control over this "more spam-threads than >> content-threads" problem, (_one_ solution: move to google groups). >> >> . > -- http://lazaridis.com |
From: Oleg B. <ph...@ph...> - 2006-10-11 08:23:39
|
On Wed, Oct 11, 2006 at 12:22:22AM +0300, Ilias Lazaridis wrote: > Sorry, I'm awaiting the response of Mr. Broytmann I have already gave the answer, and the answer was: if you are going to be be member of the community - please help; setup a Trac environment and send your patches; if you don't like the SF tracker - put your patches in your Trac. But if you are going to trade your patches in exchange to manipulating the community, moving developers to different directions or force users to switch mailing list - forget about it. If you want to be a user - ask questions on how to install and use SQLObject. If you want to become a developer - learn the code and send patches. But before trying to influence the community you have to gain some merits by showing your commitment to the development of SQLObject. Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Ilias L. <il...@la...> - 2006-10-11 08:49:17
|
Oleg Broytmann wrote: > On Wed, Oct 11, 2006 at 12:22:22AM +0300, Ilias Lazaridis wrote: >> Sorry, I'm awaiting the response of Mr. Broytmann > > I have already gave the answer, and the answer was: if you are going to > be be member of the community - please help; setup a Trac environment and > send your patches; if you don't like the SF tracker - put your patches in > your Trac. > But if you are going to trade your patches in exchange to manipulating > the community, moving developers to different directions or force users to > switch mailing list - forget about it. > If you want to be a user - ask questions on how to install and use > SQLObject. If you want to become a developer - learn the code and send > patches. But before trying to influence the community you have to gain some > merits by showing your commitment to the development of SQLObject. > > Oleg. Thank you for your comments. Personally, I give SQLObject up. I cannot take a project serious which is incapable of providing very basic project resources like a mailinglist. Keep the list. The spam-threads warn at least the visitors about the project activity. . -- http://lazaridis.com |