[Ktechlab-devel] I googled recent pages with ktechlab

[Juan De Vincenzo]

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 <santigoro at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ktechlab-devel
>
>