Monday, January 31, 2011
Rebuild of Banshee 1.8.0 to 1.9.2
I initially had built Banshee 1.8.0 from its source, but after a while I thought that it would be more beneficial to uninstall 1.8.0 and install the latest version, 1.9.2. I came to this decision because the new version has a lot more bugs to choose from, which would give my group and I more options to choose from. Our group chose a possible bug to correct and it has to do with Banshee crashing due to the Music source library being set to the home or file system directory in Ubuntu. After searching through the source code, I believe I have found where the problem may be occurring according to the bug report, but I'm not quite sure what part actually sets the default source for the library on a clean install. I will probably have to send an email to the developers and see if anyone can point me in the right direction. For now though, the code has been built successfully and my whole experience is listed on my team's wiki page. For this week, my plan is to discuss this bug with the developers, see if they can point me in the right direction, see if I can locate it and suggest a possible way to fix it.
Wednesday, January 26, 2011
Subversion Experience
As an assignment, we had to setup a subversion client on our machines and then either use that client to access a SVN repository that our instructor had setup for us or we could setup a web server on our local machines and create our own repository. For my svn client I went with the svn package that is run from the command line with the svn command in Ubuntu. From that point I did some experimenting with the class's SVN. I did not experiment too much with the repository, but I was able to check out the repository and from there look up information about files that were located within it.
After having some fun with that, I decided to setup my own personal repository on my Ubuntu machine. I found a tutorial on the web that walked through how to create your own repository and decided to use that. I utilized an Apache 2.2 web server and created an svn folder in my home directory with two subfolders. From there the tutorial walked me through some commands to execute in order to make that subversion folder an actual SVN repository. From there I edited some username and password info on some of the created files with in the two subfolders in order to create some authentication for external users. I then chose the svn protocol for my access to my repository, so access to a folder or file would be svn://svn/<folder>/<file>.
I have not had the chance to really dig down deep and experiment with SVN's features, but I will experiment more in a day or two.
After having some fun with that, I decided to setup my own personal repository on my Ubuntu machine. I found a tutorial on the web that walked through how to create your own repository and decided to use that. I utilized an Apache 2.2 web server and created an svn folder in my home directory with two subfolders. From there the tutorial walked me through some commands to execute in order to make that subversion folder an actual SVN repository. From there I edited some username and password info on some of the created files with in the two subfolders in order to create some authentication for external users. I then chose the svn protocol for my access to my repository, so access to a folder or file would be svn://svn/<folder>/<file>.
I have not had the chance to really dig down deep and experiment with SVN's features, but I will experiment more in a day or two.
Monday, January 24, 2011
A Warm Welcome Committee
Last week I wrote out an email on the mailing list stating my group's intentions on the Banshee project, our inexperience with an open source project as well as asking for a good place to start. I received a few emails from a few of the developers who pointed us in the right direction and also gave us a very warm welcome to the community.
Olivier Dufour pointed us toward the GNOME-Love Bug which is a site for those beginner GNOME project contributors. This site gave a lot of insight on how to proceed with contributing. It contains information about another IRC channel named #gnome-love as well as a mailing list for beginners. It also contains guidelines for code formatting, tutorials on languages such as C#, C++, Perl, Python, etc. as well as tutorials on the gtk+ and Glade 3 GUI libraries. The list of features goes on, but it is a great place to begin looking at because Banshee uses C# and the gtk+ library for the project.
Another Developer, David, pointed us to areas that we knew about from our initial research. He suggested that we should join the #banshee IRC channel, look at common questions and check out the bug list. Our whole group has covered this ground but it is still nice to get guidance.
The last developer to give us direction was one of the core developers, Bertrand Lorentz. He gave us a link to Gabriel Burt's talk about Banshee as well as a link to his own little idea for an extension that we could use. I have not checked out Burt's talk yet or the extension idea but if the idea is feasible for our group then I will add it to our list of possible contributions.
At this point my group and I have received plenty of places to get started. Our report on the Banshee project and our list of possible contributions to the project are up on the wiki. Our report looks to be finished but we still need a few more ideas for our project. The idea that is up right now for the project is a guard against Banshee setting the music library to default to the home directory in Linux. There is a way to fix this from the command line but the developers are thinking that there should be a guard against this happening. That way users do not have to go through the command line process to fix it.
My next step in this project is to look more in depth at the code to get an understanding of C# and how it utilizes some of Banshee's third party libraries as well as to get an svn client and experiment with that a little.
Olivier Dufour pointed us toward the GNOME-Love Bug which is a site for those beginner GNOME project contributors. This site gave a lot of insight on how to proceed with contributing. It contains information about another IRC channel named #gnome-love as well as a mailing list for beginners. It also contains guidelines for code formatting, tutorials on languages such as C#, C++, Perl, Python, etc. as well as tutorials on the gtk+ and Glade 3 GUI libraries. The list of features goes on, but it is a great place to begin looking at because Banshee uses C# and the gtk+ library for the project.
Another Developer, David, pointed us to areas that we knew about from our initial research. He suggested that we should join the #banshee IRC channel, look at common questions and check out the bug list. Our whole group has covered this ground but it is still nice to get guidance.
The last developer to give us direction was one of the core developers, Bertrand Lorentz. He gave us a link to Gabriel Burt's talk about Banshee as well as a link to his own little idea for an extension that we could use. I have not checked out Burt's talk yet or the extension idea but if the idea is feasible for our group then I will add it to our list of possible contributions.
At this point my group and I have received plenty of places to get started. Our report on the Banshee project and our list of possible contributions to the project are up on the wiki. Our report looks to be finished but we still need a few more ideas for our project. The idea that is up right now for the project is a guard against Banshee setting the music library to default to the home directory in Linux. There is a way to fix this from the command line but the developers are thinking that there should be a guard against this happening. That way users do not have to go through the command line process to fix it.
My next step in this project is to look more in depth at the code to get an understanding of C# and how it utilizes some of Banshee's third party libraries as well as to get an svn client and experiment with that a little.
Wednesday, January 19, 2011
Response to The Cathedral and Bazaar
The Cathedral and Bazaar was a very interesting read. The author, Eric S. Raymond, incorporated his experiences with the success of open source code through his Fetchmail application. I enjoyed reading this article because all the numbered lessons were very insightful into the world of open source software development. Lessons such "Good progammers know what to write. Great ones know what to rewrite (and reuse).", ""Plan to throw one away; you will, anyhow."(Fred Brooks, The Mythical Man-Month, Chapter 11)", "When you lose interest in a program, your last duty to it is to hand it off to a competent successor.", "Release early. Release often. And listen to your customers." and Linus's Law, "Given enough eyeballs, all bugs are shallow."
From the aspect of the lesson of "Good programmers know what to write. Great ones know what to rewrite (and reuse)." I find truth in that. Any programmer that is good can think of what to write and then write it themselves. From this they understand the code at hand and can then understand the bugs that come with it. The great programmers can take a piece of a program, analyze the code, understand it, rewrite it and then reuse that piece of a program for that particular program or another program. From this lesson I believe that greater skill come out of rewriting and reusing someone else's code rather than writing your own, in most cases.
The second lesson I found to be interesting was ""Plan to throw one away; you will, anyhow."(Fred Brooks, The Mythical Man-Month, Chapter 11)". A programmer can tackle a problem when working with an open source project, but whether they fully understand that problem is another thing. If that programmer does not quite understand the problem the first time they come across it and implement a solution, then more than likely they will throw that solution away at least once and have a better grasp of the problem next time. Thus, implementing a solution the next time for the same problem will more likely be a better solution.
Every body in the open source world strikes up an interest in a program; whether they are starting their own or contributing to another. Of course, sometimes over the time of a project, developers lose interest and do not wish to contribute any more to the project. In this case, it is better to hand it off to someone else than it is to let it die. If it is a project that will benefit users in some way, letting it die is probably the worst thing to do. Before reading this article, I would have been one of those developers who just let it die because if I lost interest in it then I would not take the time to pass it off to someone else. However, I guess if someone took interest in it before I let go of the project then I would pass it off.
The idea of "Release Early. Release Often. And listen to your customers" is in my opinion a great idea! If you want your software to be successful release it as early as possible, that way users aren't waiting and waiting for the product. This way users can start using and testing it right away and report bugs back to you. While that is happening you can continue working on other features for the software while working out bugs as well. Bugs with this method are easier to fix, because there aren't thousands of lines of code to search through to find what's wrong and you aren't dealing with tons of functionality.
Raymond's dubbed "Linus's Law" of putting more eyes on a project makes bugs look shallow is great. The more people you have with more backgrounds looking at code and bugs, then someone is bound to find a solution to it. After reading that lesson and before reading it from a large scale close source software project, I thought, "Why do more people on an open source project work better than a team on a close source project?". I found that answer with reading onward. In a closed source project, the more people you add, the later the project will be because all the developers talk with each other individually and try to implement things in smaller groups sometimes without consulting others. In the open source world all the co-developers report their solutions and problems to a small group of developers that then handle everything in a centralized manner. This makes me wonder why this open source method is not used in the closed source world?
I found that this collection of essays really brought me into the open source world and how successful it can be. There were a lot of lessons that I will keep in mind when I'm working on software projects for this Banshee product and more projects to come.
From the aspect of the lesson of "Good programmers know what to write. Great ones know what to rewrite (and reuse)." I find truth in that. Any programmer that is good can think of what to write and then write it themselves. From this they understand the code at hand and can then understand the bugs that come with it. The great programmers can take a piece of a program, analyze the code, understand it, rewrite it and then reuse that piece of a program for that particular program or another program. From this lesson I believe that greater skill come out of rewriting and reusing someone else's code rather than writing your own, in most cases.
The second lesson I found to be interesting was ""Plan to throw one away; you will, anyhow."(Fred Brooks, The Mythical Man-Month, Chapter 11)". A programmer can tackle a problem when working with an open source project, but whether they fully understand that problem is another thing. If that programmer does not quite understand the problem the first time they come across it and implement a solution, then more than likely they will throw that solution away at least once and have a better grasp of the problem next time. Thus, implementing a solution the next time for the same problem will more likely be a better solution.
Every body in the open source world strikes up an interest in a program; whether they are starting their own or contributing to another. Of course, sometimes over the time of a project, developers lose interest and do not wish to contribute any more to the project. In this case, it is better to hand it off to someone else than it is to let it die. If it is a project that will benefit users in some way, letting it die is probably the worst thing to do. Before reading this article, I would have been one of those developers who just let it die because if I lost interest in it then I would not take the time to pass it off to someone else. However, I guess if someone took interest in it before I let go of the project then I would pass it off.
The idea of "Release Early. Release Often. And listen to your customers" is in my opinion a great idea! If you want your software to be successful release it as early as possible, that way users aren't waiting and waiting for the product. This way users can start using and testing it right away and report bugs back to you. While that is happening you can continue working on other features for the software while working out bugs as well. Bugs with this method are easier to fix, because there aren't thousands of lines of code to search through to find what's wrong and you aren't dealing with tons of functionality.
Raymond's dubbed "Linus's Law" of putting more eyes on a project makes bugs look shallow is great. The more people you have with more backgrounds looking at code and bugs, then someone is bound to find a solution to it. After reading that lesson and before reading it from a large scale close source software project, I thought, "Why do more people on an open source project work better than a team on a close source project?". I found that answer with reading onward. In a closed source project, the more people you add, the later the project will be because all the developers talk with each other individually and try to implement things in smaller groups sometimes without consulting others. In the open source world all the co-developers report their solutions and problems to a small group of developers that then handle everything in a centralized manner. This makes me wonder why this open source method is not used in the closed source world?
I found that this collection of essays really brought me into the open source world and how successful it can be. There were a lot of lessons that I will keep in mind when I'm working on software projects for this Banshee product and more projects to come.
IRC Traffic
After returning from school, I was able to connect to the Banshee IRC channel and listen to the traffic that was incoming. When I logged in there wasn't any traffic except for people joining the channel as well as leaving the channel. But there was some traffic last night that was still on the chat board. It was between two users possibly about resolving some bug in the Banshee software. One user mentioned something about cargo-culting a setup file for something on the order of a thousand lines and the other user was impressed by how much that user put into the possible problem. Now, I was not familiar with the term of cargo-culting so I did a little search into the world of Google and found that it is a style of programming, but it really isn't the best style to use. From what I read it is a way of plugging code into a piece of software that does not serve any real purpose for that software. Apparently this tends to happen when someone who does not understand the code or the bug at hand. They pop in a piece of code just to see if it will fix the problem. This user apparently did this with a huge setup file which to me seems to be a very bad and ineffective way to fix a problem. Of course when it comes to open source projects, with different co-developers comes different methods which can be very good of a piece of software.
Successful Install on Banshee
Last night after getting my IRC client to work and joining the Banshee mailing list, I built Banshee from it's source code on Ubuntu, since Windows is not quite supported yet. The documentation for building it was straight forward actually and is right on the website. The source code is kept in the Git SVN and it requires a few dependencies and libraries before actually being able to install it. While trying to install I came across trouble when actually going to run the build script called ./autogen.sh before running make and make install. I kept getting errors with the ./Configure script not being able to run, so I was checking the script code based on the errors I was receiving.
The first error had to do with a line in the script code that was not being recognized as a command. When I looked that up it just needed to be commented out because it was plain text and not apart of the script code.
The second error I received was to do with the Apple drivers not being supported, so it recommended a command to disable Apple support and that goe me a bit further.
My third error came after disabling Apple device support. It had something to do with a constant with part of the name beginnig with GCONF. It was saying that the variable was not defined when it hit a conditional. So from there I did some searching about the error and tried some solutions that were suggested but nothing seemed to work. I then though to myself maybe I need to update Ubuntu, since I have run into install problems before due to outdated Ubuntu software. After that endeavor, I still had no luck so I decided to go back and make sure I had every dependency it required installed. I went through each of them one at a time until I found one that never did install. The one I though I had installed but didn't was the libgconf2-dev dependency. After I installed this dependency I tried installing again and was able to run ./autogen.sh without any problems. I then ran the make and make install commands and I came out with a successful install of Banshee.
NOTE: Since I disabled the Apple Support, I would not think it would support Apple Devices. Will have to look into that later and try it out with an ipod or something. Also, I need to check if that is a bug currently under Banshee.
After my music class this morning I decided to load all of the music I had from my Droid phone and create my Banshee music library. So I copied all my music into my Ubuntu Music folder and set my music library preferences to point to that music folder as a source. Once all my songs were loaded, I found that every song that was not of m4a format would play just fine. My initial thought was that Banshee did not support the m4a format, but after experimenting with it the next day, it decided to support the format. Every now and again the software will choose or not choose to play m4a format. Sometimes I have to restart the software in order for the m4a to play.
NOTE: I have that was not mpeg 4 format would play fine. I am wondering if maybe disabling apple support caused my mpeg 4's not too play or if that is just for the Apple devices itself? I'm thinking here that Banshee probably does not support apple media files just like almost every other media player, but the reason it takes Apple devices is because every apple device can support other popular formats other than m4a.
I will continue to look into bugs and play with Banshee some more to see what else I can find.
The first error had to do with a line in the script code that was not being recognized as a command. When I looked that up it just needed to be commented out because it was plain text and not apart of the script code.
The second error I received was to do with the Apple drivers not being supported, so it recommended a command to disable Apple support and that goe me a bit further.
My third error came after disabling Apple device support. It had something to do with a constant with part of the name beginnig with GCONF. It was saying that the variable was not defined when it hit a conditional. So from there I did some searching about the error and tried some solutions that were suggested but nothing seemed to work. I then though to myself maybe I need to update Ubuntu, since I have run into install problems before due to outdated Ubuntu software. After that endeavor, I still had no luck so I decided to go back and make sure I had every dependency it required installed. I went through each of them one at a time until I found one that never did install. The one I though I had installed but didn't was the libgconf2-dev dependency. After I installed this dependency I tried installing again and was able to run ./autogen.sh without any problems. I then ran the make and make install commands and I came out with a successful install of Banshee.
NOTE: Since I disabled the Apple Support, I would not think it would support Apple Devices. Will have to look into that later and try it out with an ipod or something. Also, I need to check if that is a bug currently under Banshee.
After my music class this morning I decided to load all of the music I had from my Droid phone and create my Banshee music library. So I copied all my music into my Ubuntu Music folder and set my music library preferences to point to that music folder as a source. Once all my songs were loaded, I found that every song that was not of m4a format would play just fine. My initial thought was that Banshee did not support the m4a format, but after experimenting with it the next day, it decided to support the format. Every now and again the software will choose or not choose to play m4a format. Sometimes I have to restart the software in order for the m4a to play.
NOTE: I have that was not mpeg 4 format would play fine. I am wondering if maybe disabling apple support caused my mpeg 4's not too play or if that is just for the Apple devices itself? I'm thinking here that Banshee probably does not support apple media files just like almost every other media player, but the reason it takes Apple devices is because every apple device can support other popular formats other than m4a.
I will continue to look into bugs and play with Banshee some more to see what else I can find.
Joining an IRC and Mailing List
Yesterday in class I began with finding a suitable IRC client in order to view and participate in Banshee's IRC channel. Oh, by the way my team did choose to go with the Banshee Media Player. I started out with installing Pidgin and from there I tried to create and IRC account that connected to Banshee's IRC server which is irc.gnome.org. I was having a lot of trouble with trying to connect to the gnome server with Pidgin. Another student from another team overheard my troubles and suggested I install XChat because it was an easier IRC client to use. So I installed XChat, created a user name, and searched for the gnome network in the list of networks supplied by XChat. What I found though is that by default, XChat does not contain the gnome irc channel network, so I had to add it to the list. Once I created that network with the correct IRC path, it still could not connect to the server. The classmate that assisted me with the XChat said he was able to connect to his server and view traffic. Of course, his group could be using another IRC network other than Gnome. I figured it had to do something with the school's network setup so I decided to try it at home. Later that night I tried it again and this time the client was able to connect me to the Gnome network, but I found you have to specify the actual channel under the created network because it could not find a designated channel. So after I edited my Gnome network with the #banshee channel tag under my favorite channels, it connected to the channel and I was able to view everyone who uses the channel. There was not too much traffic going on, so I will try it later tonight and submit another blog based on the traffic experiences. Since I am at school right now my IRC client will not connect.
Also, after messing around with my IRC client last night I also joined the mailing list for the Banshee project. I have never joined one of these lists before so I did not know really what to expect, but so far this morning I have experience about four e-mails relating to Banshee bugs and questions. The one e-mail thread that I decided to follow was about a user who was looking for bugs under Banshee's bugzilla account relating to Windows. Right now, the developers of the Banshee project are working on getting the software to run well on Windows. One of the developers, Gabriel Burt replied to the user's thread with a link to all the bugs relating to Windows. I followed the link to see what bugs are currently open. From looking at the list there is a lot of work to do with the Windows bugs. Some of the critical ones I came across are:
For the future I will continue to look into IRC traffic and look into other threads on the mailing list. I am still excited for this project and cannot wait to see what my group and I can do with it.
Also, after messing around with my IRC client last night I also joined the mailing list for the Banshee project. I have never joined one of these lists before so I did not know really what to expect, but so far this morning I have experience about four e-mails relating to Banshee bugs and questions. The one e-mail thread that I decided to follow was about a user who was looking for bugs under Banshee's bugzilla account relating to Windows. Right now, the developers of the Banshee project are working on getting the software to run well on Windows. One of the developers, Gabriel Burt replied to the user's thread with a link to all the bugs relating to Windows. I followed the link to see what bugs are currently open. From looking at the list there is a lot of work to do with the Windows bugs. Some of the critical ones I came across are:
- Playing a song on Windows causes Banshee to crash
- Crash on Win32
- NowPlaying extension causes Banshee to crash on Windows
For the future I will continue to look into IRC traffic and look into other threads on the mailing list. I am still excited for this project and cannot wait to see what my group and I can do with it.
Friday, January 14, 2011
Choosing Top Three
On Thursday, all of the teams in class were assigned to start choosing their top three projects. We have to choose the three we want to do, rank them, and publish our findings of these three projects on our teams' wiki. My group has finally chosen a name and put up a wiki. We're the BandOfBoyz and we have a pretty sweet picture of all of us on our main page. You can check it out by visiting this link. Now to get back on track with our project selections. So far our team has chosen 6 projects and we are in the process of cutting that list in half by doing some research about each projects developer acceptability, architecture, the presence of a bug tracker, the language of the code, build feasibility, and difficulty on how to contribute. You can view our choices so far on our wiki, but a few of our choices include Apache Lenya, phpMyAdmin, and Pidgin. As of right now, my choices are biased by the language each is written in. Right now my top three are Apache Lenya, phpMyAdmin, and Banshee, but my choices are subject to change after doing closer review of the rest of my group's choices. I can't wait to get one chosen and started!
Wednesday, January 12, 2011
1st Day of Class
The first day of class was nothing new. There was the going over of the syllabus and an overview of the class. Just about everybody from CSCI 362 is in 462, so there aren't really any new faces. I'm excited with the fact that we have a lot more FOSS choices to choose from this semester. We broke up into groups on the first day and my group is team 6 (A name is coming soon). I was very comfortable withe everyone in my group, because I know most of them already. I think the comfort level is the same through out the group and that is a big boost in the team building process. We went over the team building exercise assigned and we breezed through that because it was the same exercise as the one given in 362. We assigned all the roles in our team and turned in our deliverable. For the time being we are thinking of a name for our group, getting our wiki up and running, and selecting our 3 choices for our FOSS project. I know this semester will bring about challenges, but I am optimistic and excited about overcoming these challenges.
Subscribe to:
Posts (Atom)