I have no problem doing self releases for time being. On Tue, Mar 5, 2019, 3:11 PM Albert Astals Cid <aa...@kde.org wrote:
> El dimarts, 19 de febrer de 2019, a les 7:35:58 CET, Kevin Funk va > escriure: > > On Monday, 18 February 2019 17:06:25 CET Michael Reeves wrote: > > > > https://download.kde.org/stable/applications/18.12.1/src/kdiff3-18.12.1.tar > . > > > xz > > > > > > Get some one tell me how to change where it's trying to download from. > > > KDiff3 is not part of applications and doesn't follow the same > versioning. > > > > Heya, > > > > Could you please reconsider that decision and check whether it's not > more > > worthwhile making kdiff3 part of KDE Applications? It will save you (as > the > > maintainer) and others (distribution packagers) a major headache. > > > > You'll be responsible for releasing kdiff3 now and in the future if you > choose > > to do your own release schedule. Let me just say: It's not something > which is > > particular entertaining in the long-term. Your KDiff3 involvement will > get > > less eventually, and then someone else needs to take over releasing it > -- if > > it's part of the KDE Apps cycle it'll be done automatically, no matter > what. > > > > KDiff3 is not the type of application which needs its own release cycle, > IMO, > > it's too small & "undynamic" [1] for that. > > Just answering now because i did ignore an email named "KDiff3 craft > setup" since i don't know anything about craft and it seems now this is > being used as some kind of agreement that KDiff3 should be moved to KDE > Applications. > > Personally given KDiff3 has not had any release on its own for a long time > I would very much prefer to get a few releases on its own. > > This way new features/fixes can be released sooner if needed and not tied > to the more strict KDE Applications schedule. > > There's also the matter of http://kdiff3.sourceforge.net/ being > outdated/wrong. Do we have a plan to fix that? > > Cheers, > Albert > > > > > Regards, > > Kevin > > > > > > [1] "Undynamic" in a sense that we're likely not going to see drastic UI > > changes on weekly basis which need to get out to users ASAP. At least > for > > kdiff3 I'd rather have a conservative approach in that regard, since > it's a > > complex tool by definition. > > > > > > > > > > >
