7 Jan
2018
7 Jan
'18
7:44 p.m.
Time for a new release?
More then a year passed with out a new release.
Maybe a new point release with what ever got fixed since then?
11 Jan
11 Jan
9:20 a.m.
New subject: [trinity-devel] Time for a new release?
Envoyé : 7 janvier 2018 22:44
À : trinity-devel(a)lists.pearsoncomputing.net
Objet : [trinity-devel] Time for a new release?
Time for a new release?
More then a year passed with out a new release.
Maybe a new point release with what ever got fixed since then?
Hi,
+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.
-Alexandre
11:06 a.m.
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
11:26 a.m.
New subject: [trinity-devel] RE: Time for a new release?
À : trinity-devel(a)lists.pearsoncomputing.net
Objet : [trinity-devel] RE: Time for a new release?
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
6:36 p.m.
New subject: [trinity-devel] RE: Time for a new release?
On Thursday 11 of January 2018 20:26:46 Alexandre Couture wrote:
À : trinity-devel(a)lists.pearsoncomputing.net
Objet : [trinity-devel] RE: Time for a new release?
Alexandre Couture wrote:
Hi to all,
thank you for your interest in the release of a new version. You can
believe that we - the team of developers - have the same interest.
I add a few notes:
1) We hope to be able to resolve some of the bugs on list for R14.0.5. See
http://bugs.pearsoncomputing.net/showdependencytree.cgi?id=2696&hide_re…
2) Yes, repository Preliminary Stable Builds directly from its name is not
the final version. And yes, it does not cover all distributions -
especially distributions using RPM.
3) We have not yet announced the availability of additional repository -
Preliminary Testing Builds. This repository contains preliminary packages
for R14.1.0 (git master branch) for newer Debian and Ubuntu releases -
see http://mirror.ppa.trinitydesktop.org/trinity-testing/
Our closest goal is to finish R14.0.5. This is probably well tested
through the Preliminary Stable Builds repository. Although some users use
preliminary R14.1.0, this is still far from the final release.
Note for Emanoil: The complete size of the Preliminary Stable Builds
repository is 44 GiB, the complete size of the Preliminary Testings
Builds repository is 15 GiB. A complete rebuild of Preliminary Stable
Builds repository for all distrubutions and architectures will take about
14 days. Because Preliminary Testing Builds repository include fewer
distributions and fewer architectures, a complete rebuild requires a
fewer days.
Note for Alexandre: Please set up in your mail client some way of
indenting the original quotes, to make us better recognize quotes from
your new text.
Thank you for your patience and support. Please do not forget that your
donations are also important to keep the project alive.
Cheers
--
Slávek
+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
11:25 p.m.
Slávek Banko wrote:
Note for Emanoil: The complete size of the Preliminary
Stable Builds
repository is 44 GiB, the complete size of the Preliminary Testings
Builds repository is 15 GiB. A complete rebuild of Preliminary Stable
Builds repository for all distrubutions and architectures will take about
14 days. Because Preliminary Testing Builds repository include fewer
distributions and fewer architectures, a complete rebuild requires a
fewer days.
Thank you Slavek,
I knew you would answer, so I passed.
What I meant was the debian packages for 14.1 only - otherwise it is huge
and I have not build all the packages, but the one that I use.
du -hs stretch/
1.2G stretch/
However someone could use similar setup to mine or request some packages to
be included. So this is why I thought it might be interesting to have
debian repository for 14.1 and user feedback is important.
So the conclusion of this discussion is that it all depends on the man power
and available time to work on the bugs
20 Aug
20 Aug
7:21 a.m.
New subject: [trinity-devel] Re: RE: Time for a new release?
Dne pá 12. ledna 2018 deloptes napsal(a):
Thank you Slavek,
I knew you would answer, so I passed.
What I meant was the debian packages for 14.1 only - otherwise it is
huge and I have not build all the packages, but the one that I use.
du -hs stretch/
1.2G stretch/
However someone could use similar setup to mine or request some
packages to be included. So this is why I thought it might be
interesting to have debian repository for 14.1 and user feedback is
important.
So the conclusion of this discussion is that it all depends on the man
power and available time to work on the bugs
As I mentioned in the previous mail in this thread, new repository called
Preliminary Testing Builds is now available. It is based on the 'master'
branch == contains the preliminary packages for the future R14.1.0. This
is a complete repository == contains all packages, not just some. And
includes current and testing distributions on main architectures.
I suppose this should be rich to meet what you intended.
Note:
$ du -csh trinity-testing
19G trinity-testing
Cheers
--
Slávek
11 Jan
11 Jan
11:28 p.m.
Alexandre Couture wrote:
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.
I was thinking that bug fixes are pushed to stable (14.0.4) as well.
Slavek, are packages in 14.0.4 rebuild and uploaded after bugs are fixed?
If no, is it possible without putting the release in danger?
regards
20 Aug
20 Aug
7:10 a.m.
New subject: [trinity-devel] RE: RE: Time for a new release?
Dne pá 12. ledna 2018 deloptes napsal(a):
Alexandre Couture wrote:
For clarification, my repository is not "R14.0.4 with some fixes" but
preliminary packages for R14.0.5. As you can see, these packages were
released a few days ago as the official final release R14.0.5.
Cheers
--
Slávek
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.
I was thinking that bug fixes are pushed to stable (14.0.4) as well.
Slavek, are packages in 14.0.4 rebuild and uploaded after bugs are
fixed? If no, is it possible without putting the release in danger?
regards
2288
days inactive
2512
days old
8 comments
4 participants
participants (4)
-
Alexandre Couture -
deloptes -
Slávek Banko -
wofgdkncxojef＠gmail.com