Could you please tell us more about the release cycle? Could we only release when KDE decides it's time?
Simon 2010/8/31 Evert Vorster <evors...@gmail.com>: > Hi there... > > I follow DigiKam development too. They were not too happy with the > release schedule in some situations, as they were still doing rapid > development on the kipi-plugins which is a part of KDE now, and did > not get released till months later, whereby holding back releases of > the main package. > > Kdenlive seems to have a slower release cycle, so it might be better > suited to the KDE release cycle. > > -Evert- > > On Tue, Aug 31, 2010 at 1:34 PM, Simon Eugster <simon...@gmail.com> wrote: >> 2010/8/29 Markus Slopianka <marku...@kdemail.net>: >>> Hi. >>> I gave it a few thoughts and I think Kdenlive should apply to become a KDE >>> Extragear >>> application. >>> So far I can't think of any counter arguments but the pro arguments to the >>> status quo are >> >> No obligations? >> >>> IMO: >>> >>> 1.) Documentation. Unilike WikiBooks KDE's UserBase is meant to be used >>> with applications. >>> The KDE team is currently in the process (mostly finished already, btw) to >>> auto-generate >>> DocBooks for offline use and try to fit it as smoothly as possible into >>> KDE's automated >>> translation workflow. >> >> (as far as I've understood, being an extragear app is not a >> requirement for the UserBase?) >> >>> 2.) KDE's automated translation workflow. 'Scripty' generates new >>> translation templates >>> automatically and also updates existing translations with new strings etc. >>> KDE's existing translation teams could take also look over Kdenlive. >>> Existing Kdenlive >>> translators can continue to maintain it. >> >> Sounds useful. If special video terms are not translated incorrectly, that >> is ;) >> >>> 3.) git. KDE is setting up its own git infrastructure. Kdenlive could use >>> it (in the past >>> SVN was the only option which made some projects migrate away from KDE >>> servers and other >>> projects not become part of the KDE Family in the first place. >> >> The kdenlive repository would have to be moved from sf.net to kde, right? >> >>> 4.) KDE's SysAdmin Team. Forums, git server, translation work flow, etc. >>> are maintained by >>> a dedicated team -- taking load from the shoulders of the ones maintaining >>> Kdenlive's own >>> forum. >> >> I think we'd rather keep the current forums (drupal integration is neat.) >> >>> 5.) Increased visibility via news posts on dot.kde.org. >> >> This would be a benefit :) >> >> Other thoughts welcomed. >> >> Simon >> >> ------------------------------------------------------------------------------ >> This SF.net Dev2Dev email is sponsored by: >> >> Show off your parallel programming skills. >> Enter the Intel(R) Threading Challenge 2010. >> http://p.sf.net/sfu/intel-thread-sfd >> _______________________________________________ >> Kdenlive-devel mailing list >> Kdenlive-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/kdenlive-devel >> > > > > -- > http://magnatune.com - Music shared the way it should be. > > ------------------------------------------------------------------------------ > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > _______________________________________________ > Kdenlive-devel mailing list > Kdenlive-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/kdenlive-devel > ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ Kdenlive-devel mailing list Kdenlive-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kdenlive-devel
