Well guys, I know I'm not a developer, which seems to render any e-mail I send kind of useless to some of you, but I do have an opinion about what's being said, partly related to the other e-mail I sent a couple of days ago about the site.
Many times it has been discussed on this list the topic of where is the project going, and every time it was agreed that nobody was very sure about that, and that nobody was also sure of how to organize things. I can tell you that even though I'm not a developer, I have been sort of studying the anatomy of a project from the open source view (I mean, I'm not talking about "professional", corporation style project management, cause that's just BS), and I think that if nobody is certain about how to do it, then the most logical thing would be to copy successful models, because if the project doesn't move forward by achieving goals, people, even you guys, will at some point get bored, besides the fact that instead of moving forward, things will more or less resemble a dog trying to catch it's own tale. So, I support Santiago's proposal of going for an official release, and I'd like to extend it with a few points I feel would help: 1.- Adopt a development cycle, which I think should be 6 months, just like that of KDE's itself. It could be more or less, but that would tie the project to the "release early, release often" principle. 2.- By releasing like that, users will be able to test the software, and they could find things not even you guys are aware of. Just check out Alan's e-mail. 3.- Set clear goals for every development cycles. This should be divided into bugfixing and feature adding. Just put things on the table, discuss and decide to work together on one aspect, one bug or one code section and work together on that until it has been solved, or at least works, there's always time for improvement later, the important thing is to always move forward. 4.- There shouldn't be only one codebase, but two at least, one for Production and testing and the second one for playground (also from KDE's model), so you avoid creating new bugs if just trying something. 5.- There should not only be a bug tracking system, but a feature request one. That is something I could take care of if I get the green light for the website. 6.- One more thing I offer myself to take care of, is to make some publicity of the software, and that is why I feel the website should be given more importance, it is what everyone wanting to learn more about the project itself sees. I could start to go around electronics websites and forums and invite people to check out the project. I don't think people gets a very good impression of the project today from that point of view. 7,- At some point, despite personal opinions, KTechLab should officially start moving towards QT 4 and KDE 4, and give everyone an option to use this great tool. I don't claim to hold all the truth, I insist, I'm totally aware that I'm not a developer, but I do feel involved with this project, and I'd love to see it succeed. I just hope this e-mail does not get ignored, and at least serves the purpose of starting a useful discussion about where it should go. I have a lot of ideas for the site and some other things, but I have felt utterly ignored up until now, because some people seems to not talk to non-developers, or just people that doesn't see the world as they do. Let me remind you how Julian Baume, one very active developer, valuable as a developer and as a team member, ended up working alone on a port to KDE 4, and finally stopped collaborating because he was being ignored as well. Regards, Juan On Fri, Oct 9, 2009 at 11:19 PM, santiago gonzalez <santig...@gmail.com> wrote: > Why not doing a relase from ktl-0.3.7? > > It works good enought for me, just need to fix the flowcode (changing 1 line > in fpnode) and fix some problems in pic simulation (changing 1 line in > gpsimprocessor). > There is also a bug when closing files directly shown in screen (created in > /temp/k.. ) that can be easily fixed (just don't creating a new temp file). > > For the piccomponent is not very difficult to add a property to choose clock > MHz and add a loop in simulator to manage speed. > > Running the qtimer at 10 ms does the simulation to go at real time for me. > > I know there are a lot of people that wants to use Ktechlab for educational > purposes, but actually they can't find a ktechlab that works properly. > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Ktechlab-devel mailing list > Ktechlab-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/ktechlab-devel > > ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Ktechlab-devel mailing list Ktechlab-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ktechlab-devel
