On Sat, Dec 6, 2014 at 1:38 PM, Antonio Rojas <nqn76sw@xxxxxxxxx> wrote: > > There are usually very specific reasons why beta packages are pushed to the > repos. For instance krecipes and krusader haven't seen a stable release for > 5+ years and Sourceforge lists the betas as default download for both > projects. Understood - I think grub is sort of in the same category, so these types of decisions make sense intrinsically to me and there's no question here about these types of examples. Sad that we have abandoned upstream dev, but that's how it goes until a new dev comes along and picks up the project. > As for freerdp, you can see the reason here [1]. The upstream bug that is > referenced in your second link mentions that krdc should be patched in > distributions that ship freerdp>1.1, so a feature request should be filed > against krdc in the bug tracker. > > [1] https://www.archlinux.org/todo/freerdp-bump/ Great, thanks for that link (did not know about it) - logistically it makes sense. But now I have to ask - remmina is not required to use freerdp, many folks to not use remmina (just as many do use it I'm sure). If this is our logic, if seahorse starts using beta features of gnupg do we upgrade to beta releases of gnupg and put everyone at risk? (you see where I'm going with this, we could find examples all day) Where is the line drawn? How is it decided to risk everyone to beta software just to get a "helper" software to work with it? In this case, it seems to me the better decision would have been to produce a "freerdp-beta" package (or whatnot) and make the remmina upgrade depend on it, instead of subjecting all non-remmina users to a freerdp upgrade that may be buggy. The real error is in the upstream dev of remmina for relying on non-released software, which is kind of a no-no but hey they did it, so here we are and have to deal. $0.02, -te
