Alexandre Couture wrote:

> +1 I totally agree. At this point, I think that it is doing bad to the
> image of the project to have no recent release. It's as if things are
> fixed, but you won't get the fix until a year or two.

I thought that Slaveks repo on 14.0.5 would mitigate this.

I personally compiled last code from git master (14.1) and can not complain.
I was willing to setup debian repo as code is not that much in size and I
have space on a server somewhere in Germany, but things are far from ready
for it - I have no glue how repo is setup and put on my todo to read about
it - I just found out there 10 ways to setup repo - what is best? and who
would use it?
IMO there are very interesting changes in 14.1 (at least for me) but also
few things did not pass to git master.

In my opinion it would be good to have few flavors (stable/testing/dev)
available so that people can test and report issues. On the other hand
there are many issues but limited resources to work on them.
If only few people are involved how can this be achieved?
For example upgrade of Kgpg to support gnupg2 took my free time for 1month
last summer - about 50-60h.

IMO Slavek and the rest of the team are doing great job, because all
relevant changes are pushed to the user as patches, so the necessity of new
release is at the end also debatable.

Do you have cases where patches did not make it to stable?

regards

Hi.

The thing is that Slavek's repo is not the regular release, and not every distro has access to these .deb packages.

So no, the changes are not pushed to all the users.

Yes I have an example of patches not making their way to stable: Everything since the last release.

I am certainly not talking against Slavek's repo, but it is not the stable release offered to every users. It is mostly a rolling-release.

Why not just taking Slavek's code and say tat twice a year, it becomes the stable release instead?

It appears to me to be much easier to manage than version trees.

-Alexandre