[arch-general] Official policy on beta releases in mainline repos

[Troy Engel]

On Sat, Dec 6, 2014 at 1:38 PM, Antonio Rojas <nqn76sw at gmail.com> 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