[Ktechlab-devel] I googled recent pages with ktechlab

Sat Oct 10 16:57:27 UTC 2009

 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 <juandevincenzo at 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 <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
>>
>>
>
> ------------------------------------------------------------------------------
> 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
>