2014/1/4 Pawel <[email protected]>
> You know what ? No one here is "against" Jacob idea. No one here think
> about H3. Most people here are for keep this alive ( including me ) what
> was said before by Sebastian and Wolke. IMHO door are open just "HERE" for
> news. Seems that Jacob just want fork because of "political" reasons ie.
> build system, license , file names etc.
>
> This is his right to be independent if he want, but for me this is insane
> because this make mess in community and IMHO one guy can't support such app
> alone
'insane' might be a bit strong, but it's a fact that it's _very_ hard for 1
person to keep a project like hydrogen alive especially if you want to keep
supporting 3 OS's + want to provide a proper website with a forum and
up-to-date info and manual etc etc ... and want to have a social life as
well ;-)
in short : it's not just the code that needs to be written and maintained,
there is a hell of a lot more that needs to be done
(of course if you want to create your own 'private' hydrogen version you
dont need to put any effort into all of these things ... but that's a
different story)
as we all know, it's hard to find people that are committed to an open
source project so we should welcome _anyone_ that wants to contribute with
open arms !
the tricky question is 'how can we contribute as efficiently as possible ?'
i su*k at writing code so forgive me if the below makes no sense at all ;-)
IMO there are 2 ways to contribute :
1) working on the normal "evolution" of an application : fixing bugs,
adding features, testing, maintaining the site and documentation ...
2) preparing for the "next generation" step
obviously '1)' is an ongoing process that is relatively 'easy' to do and
follows a 'natural flow'
'2)' is a different story. It can have huge consequences, requires a huge
amount of work and raises a lot of fundamental questions about what way to
go
we already know how hard it is to find people to work on '1)', so it seems
very unlikely that we will be able to find enough people/time to
successfully complete '2)' ...
however, we all know that eventually '2)' is a necessary step to take and
the longer we wait the harder it will get to make the switch from the
currently used technology to the newer technologies
If we are really talking about fundamental changes (type '2)') i think it's
clear that this requires a new branch that exists next to the main branch
until it is mature enough to be used in the main branch
note that i used 'branch' and not 'fork'
branching means that all hydrogen code remains in the same place (sort of)
and thus simplifies merges and also simplifies communication between the
devs that work on these branches
communication is key here !
lets work together to find a way that benefits us all !
grtz
Thijs
and there is no one on the other side of bogus barricade, but I'm also not
> right person to say here what is right or not. I'm just voice who say "it's
> better to work together than alone". Trivial I know ;-)
>
> P.
>
> Dnia Sobota, 4 Stycznia 2014 13:38 Patrick Shirkey <
> [email protected]> napisał(a)
> >
> > On Sat, January 4, 2014 9:59 pm, Jacob Dawid wrote:
> > >> I'm QT newbie, I'm not much interested to learn it even more, so I
> > >> can't even defend ( or not ) current approach.
> > >> I only think that, because H2 is internally modularized, you can do
> > >> your job in H2 domain - let's say in gui2 directory. There is already
> > >> player, cli etc, so one module more is not a problem. OFC you can
> > >> work
> > >> in your branch/fork - and when you close some stage we can even
> > >> release H2 with both - new and old GUI.
> > >
> > > Qt is not a GUI framework, it's an application framework and an
> > > extension of the C++ language by OO features. It's an "evolution" of
> > > C++. Most people get that wrong, thinking Qt is a GUI-only thing. That
> > > is where the modularization already fails. This leads to strange code
> > > like the mixer widget that needs polling. Usually this is done via
> > > signals and slots.
> > >
> > > Also, you are using Qt3 legacy classes, like QHttp. I am already
> > > building with Qt5, which does not support theses classes anymore.
> > >
> > > There are some fundamental questions in our ways I think. For example
> > > the build system, which should be qmake for a Qt application imho. I
> > > always prefer to do things like they were intended to be done. The
> > > directory structure, coding style, license and so on. For example, I
> > > will rather release my fork under GPLv3 or later.
> > >
> > >> One real benefit of such approach is that if you hit some problem in
> > >> core module we can fix it here for both versions. Your fork stay
> > >> consistent with official release and we can work together - because
> > >> our goals about cleaning code are the same.
> > >
> > > I fear they are not, because the road to achieve clean code leads
> > > through unstable versions of Hydrogen. That's why I say it's good there
> > > are people like you providing patches that make Hydrogen stable. But
> > > these are rather minor changes and I would advise you to not put to
> much
> > > efforts into establishing new concepts. Of course, you are free to do
> > > whatever you want to :P
> > >
> > > Intentionally, I started this fork, because I gave Hydrogen to our
> > > (music theory experienced) drummer so that he can program in our songs
> > > for practice. He noticed a couple things he would like to have
> > > different, so in a certain way I am scratching a personal itch here. I
> > > want to use Hydrogen and I improve it based on what a drummer thinks
> can
> > > be improved.
> > >
> > >>> That's up to you. Just give me final decision on that.
> > >>
> > >> I'm not sure who exactly should make such decision. My opinion is
> > >> that - if you want rewrite GUI , improve core code etc. then there is
> > >> place to work in current domain. If you want rewrite entire app , or
> > >> most .. then this will be no longer hydrogen - and it shouldn't
> > >> confuse users... but IMHO it's better to work together anyway.
> > >>
> > >> hydrogen future is not in fork - but in cleaning mess in code and
> > >> recruiting more contributors , official fork can only confuse
> > >> community.
> > >>
> > >> P.
> > >>
> > >
> > > Okay, I will rename it as soon as there is a possible release
> > > candidate.
> > >
> >
> > In the past other forks of other apps such as zynadsubfx to yoshimi have
> > resulted in significant improvements to the fork which were rolled back
> > (in part) to the original source but it was mostly driven by one
> > developers motivation. However the fork was originally started as a
> result
> > of complete lack of feedback from the core developer which caused the
> > developer of the fork to have to go it alone if he wanted to make any
> > progress.
> >
> > It seems to me that you are more interested in building the features that
> > you personally want rather than contributing to the development of the
> > Hydrogen project as a team effort so IMO a fork would be more appropriate
> > as that way you don't have to debate or compromise your development plans
> > and/or ruffle any feathers if your vision is different from the rest of
> > the Hydrogen team.
> >
> > BTW, there is already a fork of Hydrogen called Composite which also
> > provides the Tritium library and can be run as an LV2 plugin. If you
> > haven't already looked into it you might find that there is some useful
> > code in there too.
> >
> > On the other hand your development so far seems mostly cosmetic and
> useful
> > for the core functionality of Hydrogen as a drum sequencer so it could be
> > hosted in the Hydrogen repo and tagged as a new development branch for
> > example Hydrogen-3.0. However that could end up with a similar outcome to
> > JACK where we have jack1 and jack2.
> >
> > IMO, if you are not making significant changes to the core functionality
> > of the app then a fork would be bad manners as it would cause some hassle
> > for the core devs to integrate your additions at a later date and bypass
> > the effort that has been put into building the Hydrogen codebase and
> > community to this point.
> >
> > In the end it doesn't really matter as long as people can build and use
> > the new functionality. Drama or not. if the code is good some people will
> > appreciate it.
> >
> >
> >
> > Cheers
> >
> > --
> > Patrick Shirkey
> > Boost Hardware Ltd
> >
> >
> ------------------------------------------------------------------------------
> > Rapidly troubleshoot problems before they affect your business. Most IT
> > organizations don't have a clear picture of how application performance
> > affects their revenue. With AppDynamics, you get 100% visibility into
> your
> > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
> AppDynamics Pro!
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Hydrogen-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/hydrogen-devel
>
>
>
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> Hydrogen-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/hydrogen-devel
>
--
follow me on my Audio & Linux blog <http://audio-and-linux.blogspot.com/> !
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Hydrogen-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/hydrogen-devel
