As far as I know from my 0.1 contribution, the biggest problem tring to help is diving into the code.
As any complex project, DbLinq have a complex architecture which should be documented a bit more. (I know I could do it myself...) Another thing we are really missing is a new "stable" release (actually I've promised to build one, but other problems steal me the time). BTW I actually fully agree. I'm just not so sure that System.Data.Linq is actually dead: for example it's a really good QueryObject [1] optimal for a Data Access Layer (at least if you use DbLinq :-D) In my opinion, OR/Ms like EF or NH has a different target, all those case that a Anemic Domain Model is enougth. But when the business rule are complex and change frequently, a home made DAL could be a better approach, and DbLinq is yet very good at it. That said, sometime I think we could do DbLinq a bit better then Linq2sql (a bit more flexible at least), since most of the Microsoft's addicteds will soon move out from it. Giacomo [1] http://martinfowler.com/eaaCatalog/queryObject.html [2] http://martinfowler.com/bliki/AnemicDomainModel.html On Wed, May 13, 2009 at 10:27 PM, Scott Peterson <[email protected]>wrote: > > Hi everybody. You probably don't know me. This is my first post to the > list. Well, my second. I posted a patch about three minutes ago. > Anyway, the point is, my name is Scott. I'm a Mono developer who is > using DbLinq for one of my projects. > > I have discussed the DbLinq project with Jon in the past. I expressed > to Jon my concerns about the state and structure of the project. I > would like to share those concerns with all of you so that the project > can grow and improve. Even though System.Data.Linq is now dead, > superseded by the Entity Framework, I believe that DbLinq is an > important and necessary project. > > I understand that the project has "changed hands" once already and > that the current active dev team is somewhere between 1.5 and 2 > contributors. DbLinq still has much work ahead of it [1]. If the > project is to achieve its goals, it will need more involvement by more > people. > > The recent post about a CodePlex fork epitomizes one of the main > problems with the project: barrier to entry. While the poster might > have handled the situation differently, the end result is revealing: a > developer submitted patches to no effect and forked the codebase in > order to continue development. > > There are a number of simple changes that will improve the vitality of > the project, lower the barrier to entry and attract more community > members. There are many ways to spruce up an OSS project, but these > are the high-impact tweaks which I think will give you the biggest > bang for your buck. If you want a more comprehensive exploration of > this topic, I highly recommend Producing Open Source Software [2] by > Karl Fogel. It is a must-read for anyone starting or managing an open > source project. The entire book is available online for free. > > IRC CHANNEL > An IRC channel serves as both a forum for the project members to > communicate and as a point of contact for users. Real-time guidance > and socializing makes the project much more approachable and improves > the productivity of the developers. Jon has started ##dblinq on > irc.freenode.net. I suggest everyone involved with the project idle > there. > > CENTRALIZATION > Searching for [dblinq] on Google reveals a number of project-related > domains: > http://code.google.com/p/dblinq2007/ > http://code2code.net/DB_Linq/ > http://groups.google.com/group/dblinq > http://linq.to/db > > It is unclear where the project "lives." Having a central location > will cut down on confusion and strengthen your visibility. It is fine > to use third parties for source control (Google Code) and mailing > lists (Google Groups), but all components must prominently link back > to the hub. Google code is the first result for [dblinq] so that is a > logical hub, but you ideally want your own domain which includes > "dblinq". > > BUG REVIEW > You have a bug database. You need to use it. A good handle on bug > reports is one of the most important indicators of a healthy open > source project. Who knows how many patches (like the ones now living > in CodePlex) are sitting in Google Code, collecting dust. Someone > should assume the responsibility of reviewing all new bugs and acting > upon them. This person should be showered with thanks and praise on a > regular basis, for they are doing the Lord's work. > > ROADMAP > The test coverage page [1] is the nearest thing to a project roadmap I > have seen. You need to define and prioritize specific goals for the > project. This will help focus development and provide a good answer to > the question, "what can I do to help?" The roadmap does not > necessarily need to have a timeline but if you feel comfortable > including one, it could help motivate people. > > AUTOTOOLS > Many of the people who want to help you are using some flavor of Unix > and these people expect an autogen.sh file (or equivalent). > Additionally, MonoDevelop has a bug involving assembly signing which > prevents the .sln file from building out of the box. While this is not > your bug, it is your problem: there is no way for Unix users to build > your code in one step. I am no fan of autotools but it is the best > solution. If no one on the project is familiar with autotools, I > highly suggest you get a savvy friend to hook you up with a low- > maintenance configuration. > > Those are the immediate things you can do to put DbLinq on better > footing. There are other things concerning code quality and API > design, but I am not familiar enough with the codebase itself to > comment and Jon has already brought up some things like the use of > interfaces. If anyone else has other suggesting, please share. I am > also happy to discuss these ideas and the project in general. > > With smart people and hard work, we can make that test page [1] all- > green. There are some easy changes to the project structure which will > attract more smart people and better facilitate hard work. The sooner > these changes are enacted, the faster we get to green. > > [1] http://linq.to/db/Tests > [2] http://producingoss.com/ > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "DbLinq" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/dblinq?hl=en -~----------~----~----~----~------~----~------~--~---
