Where is Jason when we need him? There are quite a few things to do on the sourceforge project. (1)
Also I haven't heard about Lawrence Shafer for a while. If we want to upload some content to ktechlab.org, we should contact him. (2) More text inline follows: 2009/10/10, Juan De Vincenzo <juandevince...@gmail.com>: > 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: > Official release: it should be ready, but see problem (1) > 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. > We should define a "stable" base to start from... maybe the 0.3.7 is suitable. > 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. > Note: Some packages / nightly builds would be nice. Julian Baume tried to build some packages at a moment. > 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. > This model IMHO works best in GIT style code repositories. We have just to move patches around. Currently there are some branches / tags for stable and trunk for everything else. > 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. > See (1) and maybe (2) > 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. > Again (2) :( > 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. > Sounds very well in theory, but this means a _lot_ of work. And for instance I have very little free time to help this project (studies...). > 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. > Sad and true :( At the end of the discussion we should note the conclusions on some webpage, but --again--, see (1) and (2). > 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 > ------------------------------------------------------------------------------ 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
