Hopbot log for 2008-09-05 - Helma IRC channel: #helma on irc.freenode.net

2008-09-05:

[11:46] <_daniel_> hi chris, my intention never was to step one someone's toes or to steel someone's copyright. just to have it mentioned: the original copyright notice is still in all the files not completely rewritten from scratch. the AGPL license as used by me with the additional terms is fully compatible with the Helma license. it is only a little bit more restrictive to ensure open source remains open source.
[11:48] <_daniel_> but, to shorten a discussion which i didn't want to start anyway: my eperience over the last weeks was that Helma 1.x is not about to die, but in fact already died. i don't see a reason why we couldn't move on by trashing my fork and having me to continue what hannes does not want to continue anymore.
[11:49] <_daniel_> lets simplify things (-:
[11:58] <_daniel_> i still believe something in between Hema 1.x and Helma-NG although closer to 1.x is the way to go. i am highly motivated to continue the development process i've started. may it be within the helma project or outside of it.
[11:58] <zumbrunn> hi daniel...
[11:59] <zumbrunn> I just got back from walking the dogs
[11:59] <zumbrunn> reading up right now...
[12:00] <zumbrunn> regarding the licensing/copyright-notice stuff, I didn't mean to jump around on you either...
[12:00] <zumbrunn> it's just a topic I'm interested in
[12:00] <zumbrunn> so I thought I share my two cents
[12:00] <zumbrunn> I don't agree that helma 1.x is dead
[12:01] <zumbrunn> it absolutely isn't
[12:01] <zumbrunn> there are to many apps out there for it to go anywhere anytime soon
[12:01] <zumbrunn> but I still think you are underestimating helma-ng
[12:02] <_daniel_> i din't mean it is not in use anymore or will not be in use anymore any soon
[12:02] <_daniel_> development however died for sure
[12:02] <zumbrunn> yeah, I know what you meant
[12:03] <zumbrunn> I do agree that helma 1.x development will focus more on actual project needs
[12:03] <zumbrunn> and more experimental development will likely happen more in helma-ng
[12:04] <zumbrunn> but that doesn't mean that helma 1.x development stops
[12:04] <_daniel_> i don't think i am underestimating Hema-NG, i only believe that JS is not the right language to write a secure and stable framework in
[12:05] <zumbrunn> but yeah, I agree that what you are doing with helma 1.x could go into helma 1.x development
[12:05] <zumbrunn> (which is why I suggested some time ago that you should talk to hannes about getting commit rights)
[12:06] <_daniel_> i'd say the door is still open on both sides (-:
[12:06] <zumbrunn> however, there is no problem with you developing on a separate fork either, if that's what you prefer
[12:07] <_daniel_> of course i would prefer to develop within the Helma project
[12:07] <_daniel_> but i do prefer developing over discussing (-;
[12:07] <zumbrunn> in your own fork, you can do as you please and move forward in the direction you want without always having to discuss details on the mailing list first
[12:07] <_daniel_> thats why i created the fork and just started off doing developent
[12:07] <zumbrunn> exactly
[12:09] <_daniel_> currently my helma 1.x development is focused on improving helma 1.x without breaking backwards compatibiity
[12:09] <decke> but there are many situations where you have to be smart to succeed... history shows many examples
[12:10] <decke> and what is bad with helma 1.x 's backward compatibility?
[12:11] <decke> i prefer stable software and frameworks for production use and do not want to risk business for new features that software does not use
[12:11] <_daniel_> nothing at all. so as i try to improve hema 1.x i way not breaking bckwards compatibility i do not even see a reason in discussing such improvements in detail on the mailing list
[12:12] <zumbrunn> well, you would have to discuss *that* on the mailing list ;-)
[12:12] <_daniel_> (-:
[12:12] <decke> you have to define stable then....
[12:12] <decke> breaking compatibility is one thing
[12:13] <decke> introducing new bugs with new code another one
[12:13] <decke> making regressions but not breaking compatibility another one too
[12:13] <decke> you cannot just hope to not introduce bugs just because you don't break compatiblity
[12:13] <decke> and stable has to be defined then
[12:15] <decke> what you describe obove is something in between i think.... you do want to introduce new code and new features but not break compatibility but you do not want to discuss things but you want that in an stable branch
[12:15] <zumbrunn> the best solution may be to add helma 1.x trunk to github as well, since there it is a lot easier to work on different branches without any fuzz
[12:15] <decke> yeah a fork or a new branch would be more appropriate i think...
[12:16] <zumbrunn> that way everybody can develop to their hearts contempt and only when it's time to put together a release we have to pull together the bits we want
[12:16] <decke> yeah and then you have do discuss only critical things
[12:17] <decke> but discussing is a good thing in my opinion... because you can gain acceptance quickly because people know what you are trying to do and how...
[12:17] <zumbrunn> with git and github each person basically works on their own "fork" by default
[12:18] <decke> helma has a git repo?
[12:18] <zumbrunn> helma-ng does, yes
[12:20] <decke> mhm nice...
[12:22] <zumbrunn> http://github.com/hns/helma-ng/tree/master
[12:22] <zumbrunn> that's hannes' "fork" ;-)
[12:23] <decke> yeah git is very decentralized... but i prefer centralization in that point...
[12:43] <zumbrunn> decke, what do you mean with that? why do you prefer centralization there?
[12:44] <zumbrunn> in a sense that's what github does, no?
[12:45] <decke> git is great for how the linux guys work - they have all their own goals and work in that direction
[12:45] <zumbrunn> it brings the different forked git repos back together and allows for them to be handled kind of like branches
[12:46] <decke> but with projects that work in a single direction such a development leads you nowhere...
[12:46] <decke> yeah exactly - first it forkes everything and lets you work on your own
[12:47] <decke> and then you have the headache of merging it back together
[12:47] <zumbrunn> :-)
[12:47] <decke> that is great if everyone loves to work on his own and then decides hey i like what the other do too so let's merge it back
[12:48] <decke> but in a real software i like it that all people around me have my newest code that i checked in a second before
[12:48] <decke> and they have to deal with it - be compatible with it - strike me if i made a mistake and discuss it if i broke someone's code
[12:49] <zumbrunn> yeah, I see your point
[12:49] <decke> things get different if you have something that is as big as a linux kernel is
[12:50] <decke> but at the moment i do not have such huge projects with soo many developers
[12:52] <decke> and my background in the company is based on High availability environments coded in C that have a strong will to be consistent, compatible, stable ....
[12:54] <decke> so there are big differences in what i do at work with high availabilty database crunching old fashioned apps ... and short living modern styled web development with all his ugly faces
[16:47] <GitHub123> helma-ng: Chris Zumbrunn master SHA1-02126dc
[16:47] <GitHub123> Merge commit 'hns/master'
[16:47] <GitHub123> http://github.com/zumbrunn/helma-ng/commit/02126dc362270def8389c988c2e3e6cfd17865d6

 

 

In the channel now:

Logs by date: