On Sat, Dec 3, 2011 at 9:19 PM, Timothy Pearson kb9vqf@pearsoncomputing.net wrote:
Most likely you will have to wait for the next release. I assume you have bug reports in for the problems you are experiencing?
Tim
Hi Tim,
Although Trinity is great and is already very stable, you had previously recognized that the TDE 3.5.13 release lacks some polishing.
So, if some bugs and corrections are being done by the devs, why not let the users get them now, instead of waiting 6 or more months?
The point here, is that with Debian, people are used to get new upgrades, new versions, and more important, bug corrections via apt-get, _all the time_.
So, maybe Trinity lacks here is a maintainer for the Debian packages, so that they can been regularly upgraded, at least if not with new features, with bug corretions and general polishing??
Thanks.
Am Sonntag, 4. Dezember 2011 schrieb Jorge Gonçalves:
On Sat, Dec 3, 2011 at 9:19 PM, Timothy Pearson
kb9vqf@pearsoncomputing.net wrote:
Most likely you will have to wait for the next release. I assume you have bug reports in for the problems you are experiencing?
Tim
Hi Tim,
Although Trinity is great and is already very stable, you had previously recognized that the TDE 3.5.13 release lacks some polishing.
So, if some bugs and corrections are being done by the devs, why not let the users get them now, instead of waiting 6 or more months?
The point here, is that with Debian, people are used to get new upgrades, new versions, and more important, bug corrections via apt-get, _all the time_.
So, maybe Trinity lacks here is a maintainer for the Debian packages, so that they can been regularly upgraded, at least if not with new features, with bug corretions and general polishing??
I think it's a manpower problem.
On Sunday 04 December 2011 12:41:30 Jorge Gonçalves wrote:
The point here, is that with Debian, people are used to get new upgrades, new versions, and more important, bug corrections via apt-get, _all the time_.
I take it you run Wheezy and or Sid? What you say is not true of Lenny or Squeeze!!! Security updates only.
Lisi
On Sat, Dec 3, 2011 at 9:19 PM, Timothy Pearson kb9vqf@pearsoncomputing.net wrote:
Most likely you will have to wait for the next release. I assume you have bug reports in for the problems you are experiencing?
Tim
Hi Tim,
Although Trinity is great and is already very stable, you had previously recognized that the TDE 3.5.13 release lacks some polishing.
So, if some bugs and corrections are being done by the devs, why not let the users get them now, instead of waiting 6 or more months?
The point here, is that with Debian, people are used to get new upgrades, new versions, and more important, bug corrections via apt-get, _all the time_.
So, maybe Trinity lacks here is a maintainer for the Debian packages, so that they can been regularly upgraded, at least if not with new features, with bug corretions and general polishing??
Thanks.
At this point it is a combination of several factors: 1.) What you have mentioned already; that is, I am the defacto Debian maintainer and don't have much free time. QuickBuild should allow an interested maintainer to step up and start working on this part of the project without much difficulty. 2.) The fixes simply aren't in GIT yet. The GIT transition is scheduled to be finished by the end of December. 3.) During the GIT transition we are renaming a bunch of *KDE* strings to *TDE*. This makes it extremely difficult to fire off a build from the sources in GIT and actually have it work with the 3.5.13 builds. Instead, someone would have to be willing to cherry pick the patches into the Debian build files for 3.5.13, and remove any renaming that has already been completed.
To summarize, in principle I would love to see SRUs for the main supported distributions. In practice we need more manpower to see it happen. ;-)
Tim
On Sun, Dec 4, 2011 at 7:30 PM, Timothy Pearson kb9vqf@pearsoncomputing.net wrote:
On Sat, Dec 3, 2011 at 9:19 PM, Timothy Pearson kb9vqf@pearsoncomputing.net wrote:
Most likely you will have to wait for the next release. I assume you have bug reports in for the problems you are experiencing?
Tim
Hi Tim,
Although Trinity is great and is already very stable, you had previously recognized that the TDE 3.5.13 release lacks some polishing.
So, if some bugs and corrections are being done by the devs, why not let the users get them now, instead of waiting 6 or more months?
The point here, is that with Debian, people are used to get new upgrades, new versions, and more important, bug corrections via apt-get, _all the time_.
So, maybe Trinity lacks here is a maintainer for the Debian packages, so that they can been regularly upgraded, at least if not with new features, with bug corretions and general polishing??
Thanks.
At this point it is a combination of several factors: 1.) What you have mentioned already; that is, I am the defacto Debian maintainer and don't have much free time. QuickBuild should allow an interested maintainer to step up and start working on this part of the project without much difficulty. 2.) The fixes simply aren't in GIT yet. The GIT transition is scheduled to be finished by the end of December. 3.) During the GIT transition we are renaming a bunch of *KDE* strings to *TDE*. This makes it extremely difficult to fire off a build from the sources in GIT and actually have it work with the 3.5.13 builds. Instead, someone would have to be willing to cherry pick the patches into the Debian build files for 3.5.13, and remove any renaming that has already been completed.
To summarize, in principle I would love to see SRUs for the main supported distributions. In practice we need more manpower to see it happen. ;-)
Tim
Yes, now I understand why there will be no upgrade to 3.5.13.
But it seems it's not a comfortable situation for TDE, it's a circle: without resource$ that leads to manpower, Trinity does progress very slow, BUT if it progresses slow, large corporations or else that can sponsor TDE development will run away.
May I gave a suggestion?
Why not make a release, 3.5.14, in early January, after the move to Git and the rename thing is completed?? Even if it cures only a small bunch of bugs, it will be good, in many respects.
I don't know about others, but for myself, I can wait till January, but I will not wait for six months to have some needed polishing done, and will go away from TDE.
What you think?
May I gave a suggestion?
Why not make a release, 3.5.14, in early January, after the move to Git and the rename thing is completed?? Even if it cures only a small bunch of bugs, it will be good, in many respects.
I don't know about others, but for myself, I can wait till January, but I will not wait for six months to have some needed polishing done, and will go away from TDE.
Where do you run when there's no place to go? KDE4 and Gnome3 are stillborn IMO. XFCE works only with doubleclick (which is a decent way to end with RSI). Oh, I had the opportunity to test Windows7. If you ever want to see something clumsy, go there :-)
Maybe it's just me, but I have not found a showstopper bug in TDE. Anoyances, ok, but nothing severe. I was always able to track the problem down (on Debian it's mostly some piece of KDE4 that backstabed me).
I was plesed to see that ksm works with firefox at last.
On 5 December 2011 10:22, Mag. Dr. Nikolaus Klepp office@klepp.biz wrote:
Maybe it's just me, but I have not found a showstopper bug in TDE. Anoyances, ok, but nothing severe.
+1
Sure there are bugs, mostly concerning specific apps.
There is usually a gtk alternative for the apps awaiting bugfixes, without having to install gnome DE itself, or another workaround can be found.
Comparing with the mainstream DE's out there, the overall functionality of TDE tips the balance in it's favour here. XFCE is about the only alternative unless you like glitz in your face and have the hardware to run it.
And the "glitz" DE's have plenty of bugs too, look at the gnome3 fiasco. Who would replace TDE with that?
On Monday 05 December 2011 10:04:41 Jorge Gonçalves wrote:
but I will not wait for six months to have some needed polishing done, and will go away from TDE.
Do the polishing and feed it back for everyone else to use?
Trinity is always going to be slow when it has so few people. I think that they already work miracles. Number of developers or funders would, I would have thought, be of more interest to the Trinity developers than number of users.
I would also have thought that, if a commercial enterprise is interested in Trinity, it is more likely to sponsor it in order to speed things up. If things were already perfect, why would they spend their money?
Lisi
Le lundi 05 décembre 2011, Jorge Gonçalves a écrit :
Why not make a release, 3.5.14, in early January, after the move to Git and the rename thing is completed??
I am waiting too! I wish I could tinker with a few specific applications (kate, kmail), to see if I "am still capable" (-: the latest exerience make me seriously doubt) and because I have some wishes about them! I wait to be sure to be able to compile TDE on my current system without "breaking" anything and without the unexpected messages, the kind that I have placed on this list!
Le lundi 05 décembre 2011, Mag. Dr. Nikolaus Klepp a écrit :
Where do you run When There's no place to go? KDE4 and are Gnome3 IMO stillborn. XFCE works only with doubleclick (Which is a decent way to End with RSI). Oh, I Had the Opportunity to test Windows 7. If you ever Want to see Something clumsy, go there :-)
I do not speak of going "elsewhere" and agree with David! For me, the options are: continue using what I use now (OSS 11.1 repeating "the repo is outdated"), and nothing else of non-functional.
Good luck to everyone, Patrick
Why not make a release, 3.5.14, in early January, after the move to Git and the rename thing is completed?? Even if it cures only a small bunch of bugs, it will be good, in many respects.
+1
I like this idea
Doing a release properly requires a little over a month dedicated to release tasks such as beta testing, compiling packages on all distributions, compiling release notes, etc. Also, building binary packages is not cheap, in terms of both time (of our distribution maintainers) and money (to feed everyone's build computers with electricity).
Releasing after the move to GIT would not cure a lot of the more stubborn bugs. Additionally, due to the renaming of *KDE* strings, the distribution maintainers have some work to do in order to update their packaging files. I don't want to place that kind of demand on our volunteer staff during the Christmas season, and then turn right around and demand the same thing a couple months later.
Thoughts?
Tim
Am Montag, 5. Dezember 2011 schrieb Timothy Pearson:
Why not make a release, 3.5.14, in early January, after the move to Git and the rename thing is completed?? Even if it cures only a small bunch of bugs, it will be good, in many respects.
+1
I like this idea
Doing a release properly requires a little over a month dedicated to release tasks such as beta testing, compiling packages on all distributions, compiling release notes, etc. Also, building binary packages is not cheap, in terms of both time (of our distribution maintainers) and money (to feed everyone's build computers with electricity).
Releasing after the move to GIT would not cure a lot of the more stubborn bugs. Additionally, due to the renaming of *KDE* strings, the distribution maintainers have some work to do in order to update their packaging files. I don't want to place that kind of demand on our volunteer staff during the Christmas season, and then turn right around and demand the same thing a couple months later.
Thoughts?
What if not the whole TDE gets released but "only" bugfixed packages? It's clear it won't work during transition and renaming phase, but when that is settled (probably with 3.5.14) I think it would be a lot easier.
Nik
Am Montag, 5. Dezember 2011 schrieb Timothy Pearson:
Why not make a release, 3.5.14, in early January, after the move to Git and the rename thing is completed?? Even if it cures only a small bunch of bugs, it will be good, in many respects.
+1
I like this idea
Doing a release properly requires a little over a month dedicated to release tasks such as beta testing, compiling packages on all distributions, compiling release notes, etc. Also, building binary packages is not cheap, in terms of both time (of our distribution maintainers) and money (to feed everyone's build computers with electricity).
Releasing after the move to GIT would not cure a lot of the more stubborn bugs. Additionally, due to the renaming of *KDE* strings, the distribution maintainers have some work to do in order to update their packaging files. I don't want to place that kind of demand on our volunteer staff during the Christmas season, and then turn right around and demand the same thing a couple months later.
Thoughts?
What if not the whole TDE gets released but "only" bugfixed packages? It's clear it won't work during transition and renaming phase, but when that is settled (probably with 3.5.14) I think it would be a lot easier.
Nik
That would be much more managable. As you said it won't work for this cycle, but it is a possibility for future releases.
Tim
On Mon, Dec 5, 2011 at 5:48 PM, Timothy Pearson kb9vqf@pearsoncomputing.net wrote:
That would be much more managable. As you said it won't work for this cycle, but it is a possibility for future releases.
Tim
Hi!
By "this cycle" you mean the current 3.5.13 or else?
I really didn't understand why the Nikolaus suggestion could not be done, i.e., only release some bug fixing packages in January, after the move to GIt and the renaming is completed??
I think that after the patches there are waiting now are integrated into trunk, it will not take more than a few days to do some proper QA before releasing the packages.
So, it will be a 3.5.14 release, yes, but in fact it will not be a full release, only with some updated packages. As I said before, I think this approach has a few great advantages:
- testing building and releasing from Git as early as possible - testing the first steps towards serious QA testing and assurance - no need to do much about release notes, etc., because it will be a minor release - it will look like Trinity is a dynamic project - and, more important, _looking more dynamic_ means much more community involvement and voluntary help, in many ways (take my word, I know what I'm talking about)
If none of the above arguments works, then there is this:
- it cannot get bad or be worse ! ;-)
Another thing: " I don't want to place that kind of demand on our volunteer staff during the Christmas season "
Ok, but maybe they will not be worried to do that extra effort??
So, yes it will mean some effort, but in the end, the outcome could only be good for the Trinity project. Or so I think.
Jorge
PS: Tim, one other suggestion: If you start talking that you can not do a release because "is not cheap, in terms of (...) money (to feed everyone's build computers with electricity)." then you can be sure no one will ever take the Trinity project seriously and believe Trinity could grow up by itself !!
Hello!
I've been off-line for a few days, but it seems no one commented more on this subject, and I even did not see any response to the post below. I really would like your opinions! :-)
Thanks, Jorge
---------- Forwarded message ---------- Date: 2011/12/6 Subject: Re: [trinity-users] Upgrades to TDE 3.5.13 ... To: trinity-users@lists.pearsoncomputing.net
On Mon, Dec 5, 2011 at 5:48 PM, Timothy Pearson kb9vqf@pearsoncomputing.net wrote:
That would be much more managable. As you said it won't work for this cycle, but it is a possibility for future releases.
Tim
Hi!
By "this cycle" you mean the current 3.5.13 or else?
I really didn't understand why the Nikolaus suggestion could not be done, i.e., only release some bug fixing packages in January, after the move to GIt and the renaming is completed??
I think that after the patches there are waiting now are integrated into trunk, it will not take more than a few days to do some proper QA before releasing the packages.
So, it will be a 3.5.14 release, yes, but in fact it will not be a full release, only with some updated packages. As I said before, I think this approach has a few great advantages:
- testing building and releasing from Git as early as possible - testing the first steps towards serious QA testing and assurance - no need to do much about release notes, etc., because it will be a minor release - it will look like Trinity is a dynamic project - and, more important, _looking more dynamic_ means much more community involvement and voluntary help, in many ways (take my word, I know what I'm talking about)
If none of the above arguments works, then there is this:
- it cannot get bad or be worse ! ;-)
Another thing: " I don't want to place that kind of demand on our volunteer staff during the Christmas season "
Ok, but maybe they will not be worried to do that extra effort??
So, yes it will mean some effort, but in the end, the outcome could only be good for the Trinity project. Or so I think.
Jorge
PS: Tim, one other suggestion: If you start talking that you can not do a release because "is not cheap, in terms of (...) money (to feed everyone's build computers with electricity)." then you can be sure no one will ever take the Trinity project seriously and believe Trinity could grow up by itself !!
On Monday 05 December 2011 18:49:48 Timothy Pearson wrote:
Why not make a release, 3.5.14, in early January, after the move to Git and the rename thing is completed?? Even if it cures only a small bunch of bugs, it will be good, in many respects.
+1
I like this idea
Doing a release properly requires a little over a month dedicated to release tasks such as beta testing, compiling packages on all distributions, compiling release notes, etc. Also, building binary packages is not cheap, in terms of both time (of our distribution maintainers) and money (to feed everyone's build computers with electricity).
Releasing after the move to GIT would not cure a lot of the more stubborn bugs. Additionally, due to the renaming of *KDE* strings, the distribution maintainers have some work to do in order to update their packaging files. I don't want to place that kind of demand on our volunteer staff during the Christmas season, and then turn right around and demand the same thing a couple months later.
Thoughts?
My heart sank when I saw the suggestion! And why necessarily 6 monthly? It makes sense for the Ubuntu build, but that is faster than Debian's own release cycle. I personally would rather that Trinity 3.x.x were released when it is ready, rather than on time, but buggy.
And surely people can wait a bit? The more of us users you lot have, the more of a demanding nuisance we shall become. We do not forward the project at all. I think all of us should shut up or put up. (Doesn't quite fit my pleas over the web-site, but you have no idea what a rare luxury your website is.)
When a job applicant once told me that, if I didn't give him the job I was advertising, he would emigrate, I had to exert considerable self control to stop myself briefly replying: "Bon voyage!"
If someone says "Do this or I'll go", my response is "goodbye!" (And that is if I'm feeling polite!)
Carry on as you wish to. I shall continue to sit in my little corner crossing my fingers for the things that are dear to my heart.
And if we have a little something that is annoying us, or that we feel we cannot live with, we can always try asking David Hare. He is a genius at workarounds.
Lisi
On Monday 05 December 2011 18:49:48 Timothy Pearson wrote:
Why not make a release, 3.5.14, in early January, after the move to Git and the rename thing is completed?? Even if it cures only a small bunch of bugs, it will be good, in many respects.
+1
I like this idea
Doing a release properly requires a little over a month dedicated to release tasks such as beta testing, compiling packages on all distributions, compiling release notes, etc. Also, building binary packages is not cheap, in terms of both time (of our distribution maintainers) and money (to feed everyone's build computers with electricity).
Releasing after the move to GIT would not cure a lot of the more stubborn bugs. Additionally, due to the renaming of *KDE* strings, the distribution maintainers have some work to do in order to update their packaging files. I don't want to place that kind of demand on our volunteer staff during the Christmas season, and then turn right around and demand the same thing a couple months later.
Thoughts?
My heart sank when I saw the suggestion! And why necessarily 6 monthly? It makes sense for the Ubuntu build, but that is faster than Debian's own release cycle. I personally would rather that Trinity 3.x.x were released when it is ready, rather than on time, but buggy.
<snip>
That is what I would like to see as well. I just wanted to make sure I wasn't the only one. ;-)
Tim
On 5 December 2011 15:29, Timothy Pearson kb9vqf@pearsoncomputing.netwrote:
On Monday 05 December 2011 18:49:48 Timothy Pearson wrote:
Why not make a release, 3.5.14, in early January, after the move to Git and the rename thing is completed?? Even if it cures only a small bunch of bugs, it will be good, in many respects.
+1
I like this idea
Doing a release properly requires a little over a month dedicated to release tasks such as beta testing, compiling packages on all distributions, compiling release notes, etc. Also, building binary packages is not cheap, in terms of both time (of our distribution maintainers) and money (to feed everyone's build computers with electricity).
Releasing after the move to GIT would not cure a lot of the more stubborn bugs. Additionally, due to the renaming of *KDE* strings, the distribution maintainers have some work to do in order to update their packaging files. I don't want to place that kind of demand on our volunteer staff during the Christmas season, and then turn right around and demand the same thing a couple months later.
Thoughts?
My heart sank when I saw the suggestion! And why necessarily 6 monthly? It makes sense for the Ubuntu build, but that is faster than Debian's own release cycle. I personally would rather that Trinity 3.x.x were
released
when it is ready, rather than on time, but buggy.
<snip>
That is what I would like to see as well. I just wanted to make sure I wasn't the only one. ;-)
Tim
. Stability is always first and foremost. But if the current version has stability issues that are compromising the users ability to work, shouldn't we be focusing on that as well.
This is where maintainers come in. we have over 50 patches already sitting in Bugzilla, and many other bugs already have workarounds. It's up to them to push these patches out before the next release, if they feel that is their job.
As for Arch Linux, we maintain strictly vanilla upstream sources. What can happen when you have maintainers doing more than just maintaining packages is not good. It can end up with a lot of system specific hacks or even outdated repositories (like ones currently still supporting GNOME2 or vanilla KDE3 branches) which become convoluted messes (ahem).
And once nightly builds become available again, the latest and most unstable, but also the one getting bugfixes, will be there for anyone who needs it.
Calvin Morrison.
On Mon, Dec 5, 2011 at 7:02 PM, Calvin Morrison mutantturkey@gmail.com wrote:
. Stability is always first and foremost. But if the current version has stability issues that are compromising the users ability to work, shouldn't we be focusing on that as well.
This is where maintainers come in. we have over 50 patches already sitting in Bugzilla, and many other bugs already have workarounds. It's up to them to push these patches out before the next release, if they feel that is their job.
As for Arch Linux, we maintain strictly vanilla upstream sources. What can happen when you have maintainers doing more than just maintaining packages is not good. It can end up with a lot of system specific hacks or even outdated repositories (like ones currently still supporting GNOME2 or vanilla KDE3 branches) which become convoluted messes (ahem).
And once nightly builds become available again, the latest and most unstable, but also the one getting bugfixes, will be there for anyone who needs it.
Calvin Morrison.
+1
This comment by Calvin is very relevant!
And remember that, even if 3.5.13 is very stable and has no *serious* bug, for many people, small annoying little problems repeated over and over again tend to become a "greater" problem!
And that could push users away from TDE...
On Tuesday 06 December 2011 12:08:02 Jorge Gonçalves wrote:
And that could push users away from TDE...
Why does that matter? No-one is forcing anyone to use TDE. Surely, if someone is unhappy with TDE, leaving is the obvious thing to do.
As I have already said, I think, if anything, having lots of users who make demands and contribute nothing is detrimental to the project.
A commercial enterprise needs a lot of users to earn the money they are there to earn. At this stage TDE needs lots of contributors and developers.
Lisi
On Tue, 6 Dec 2011 12:22:02 +0000 Lisi lisi.reisz@gmail.com wrote:
Hello Lisi,
On Tuesday 06 December 2011 12:08:02 Jorge Gonçalves wrote:
And that could push users away from TDE...
Why does that matter? No-one is forcing anyone to use TDE. Surely,
One word; Reputation.
if someone is unhappy with TDE, leaving is the obvious thing to do.
Certainly, but the "bad press" that's likely to be associated with the departure cannot do TDE any good. You can picture the scene, I'm sure:-
"I used to use $projectname (it's not just TDE that's affected, obviously), but there were some really niggling bugs that the developers just didn't want to fix."
Whether it's true that developers didn't want to fix them is irrelevant, the bad press will gain $projectname a reputation for being buggy and/or not listening to its users. Like Gnome.
On Tuesday 06 December 2011 16:27:46 Brad Rogers wrote:
On Tue, 6 Dec 2011 12:22:02 +0000 Lisi lisi.reisz@gmail.com wrote:
Hello Lisi,
On Tuesday 06 December 2011 12:08:02 Jorge Gonçalves wrote:
And that could push users away from TDE...
Why does that matter? No-one is forcing anyone to use TDE. Surely,
One word; Reputation.
if someone is unhappy with TDE, leaving is the obvious thing to do.
Certainly, but the "bad press" that's likely to be associated with the departure cannot do TDE any good. You can picture the scene, I'm sure:-
"I used to use $projectname (it's not just TDE that's affected, obviously), but there were some really niggling bugs that the developers just didn't want to fix."
Whether it's true that developers didn't want to fix them is irrelevant, the bad press will gain $projectname a reputation for being buggy and/or not listening to its users. Like Gnome.
I take your point. But does that mean that the people who are dissatisfied must hold sway, whatever other people think, so that they will not moan? We, surely, almost by definition, are mostly people who are dissatisfied with KDE4. We were not forced to use it - tho', I confess, some people did try to force us - but they didn't succeed did they? ;-)
And releasing too early didn't exactly help KDE4 did it?
I think that Trinity's great problem is that it has simply got too little man(or woman, of course!)power. Giving those valiantly working away something extra to do is not going to help.
Lisi
On Tuesday 06 December 2011 16:27:46 Brad Rogers wrote:
On Tue, 6 Dec 2011 12:22:02 +0000 Lisi lisi.reisz@gmail.com wrote:
Hello Lisi,
On Tuesday 06 December 2011 12:08:02 Jorge Gonçalves wrote:
And that could push users away from TDE...
Why does that matter? No-one is forcing anyone to use TDE. Surely,
One word; Reputation.
if someone is unhappy with TDE, leaving is the obvious thing to do.
Certainly, but the "bad press" that's likely to be associated with the departure cannot do TDE any good. You can picture the scene, I'm sure:-
"I used to use $projectname (it's not just TDE that's affected, obviously), but there were some really niggling bugs that the developers just didn't want to fix."
Whether it's true that developers didn't want to fix them is irrelevant, the bad press will gain $projectname a reputation for being buggy and/or not listening to its users. Like Gnome.
I take your point. But does that mean that the people who are dissatisfied must hold sway, whatever other people think, so that they will not moan? We, surely, almost by definition, are mostly people who are dissatisfied with KDE4. We were not forced to use it - tho', I confess, some people did try to force us - but they didn't succeed did they? ;-)
And releasing too early didn't exactly help KDE4 did it?
I think that Trinity's great problem is that it has simply got too little man(or woman, of course!)power. Giving those valiantly working away something extra to do is not going to help.
Lisi
This is correct. I have stated before that I agree in principle with SRUs, but that I personally don't have the time to generate them. If the distribution maintainers have the time and desire to generate distribution-specific SRUs based on patches on Bugzilla there is nothing standing in their way.
Until we get a team dedicated to handling nothing but bug repair and patching/testing, I don't think official source SRUs are prudent. Instead, I'd like to suggest a list of suggested cherry-picked patches from the latest dvelopment HEAD. This could go on the Wiki and would allow the distribution maintainers to easily pull those patches they deem critical for their userbase out of the list of patches that we suggest.
Tim
On Tue, 6 Dec 2011 16:53:33 +0000 Lisi lisi.reisz@gmail.com wrote:
Hello Lisi,
I take your point. But does that mean that the people who are dissatisfied must hold sway, whatever other people think, so that they will not moan? We, surely, almost by definition, are mostly people
That's possibly the other extreme. Which would cause different people to moan, and leave. Sometimes, you just can't win. :-)
Timothy and the rest of the team have to balance the needs of all sorts of people, often pulling in different directions, with the practicality of achieving what those people want. You're aware, no doubt, that what /seems/ to be a trivial matter to fix may not in fact be that easy to overcome.
who are dissatisfied with KDE4. We were not forced to use it - tho', I confess, some people did try to force us - but they didn't succeed did they? ;-)
True. Same seems to be happening with Gnome, with the change from 2 to 3. The resentment seems to be much greater there, though. Or maybe my memory of the complaints when KDE went to v4 is failing.
And releasing too early didn't exactly help KDE4 did it?
Agreed, although that's only for certain values of "early". IDK, but wouldn't mind placing a small wager that the initial release date for KDE4 were put back. Possibly more than once. Either way, as you say, v4 wasn't a good release.
I think that Trinity's great problem is that it has simply got too little man(or woman, of course!)power. Giving those valiantly working away something extra to do is not going to help.
Sadly, it seems to be a truism that there's *never* enough manpower for a project like Trinity. :-(
<snip>
Sadly, it seems to be a truism that there's *never* enough manpower for a project like Trinity. :-(
Basic economics. :-) Those products which appeal to the masses (usually the Lowest Common Denominator) will always receive more sales/support/attention than specialized products do.
Tim
On Tuesday 06 December 2011 18:00:26 Brad Rogers wrote:
Timothy and the rest of the team have to balance the needs of all sorts of people, often pulling in different directions, with the practicality of achieving what those people want. You're aware, no doubt, that what /seems/ to be a trivial matter to fix may not in fact be that easy to overcome.
I clearly have a quirky view of this. It seems to me that Timothy and the others working hard at this do not have to "balance the needs of all sorts of people". Why should they take any notice of those needs? If they just chose a path and stick to it, and if that path lead to somewhere of their own choosing, rather than those of the conflicting claims of others, that seems to me fine.
I am grateful for what they do. I am grateful for being allowed to travel in their slipstream. I reckon that I can take it or leave it. If I choose to take it, I do so on my own responsibility and Timothy et al owe me nothing and are not required to "meet my needs". It is not as though I am contributing anything.
And anyway, whatever they do they will never please everybody. I hate the revolving cube. I have just seen a eulogy from someone who loves it.
Lisi
On Tue, 6 Dec 2011 18:38:52 +0000 Lisi lisi.reisz@gmail.com wrote:
Hello Lisi,
I clearly have a quirky view of this. It seems to me that Timothy and
Not necessarily. It could be mine that's the bizarre take. Although some of what I said in previous messages were not necessarily my take, just a "devils advocate" sort of thing.
the others working hard at this do not have to "balance the needs of all sorts of people". Why should they take any notice of those needs? If they just chose a path and stick to it, and if that path
It's not just the users, but other members of the dev team that might have differing views as to what "the project" should be. That sort of thing happens quite often, otherwise Trinity wouldn't have forked from KDE (obviously).
lead to somewhere of their own choosing, rather than those of the conflicting claims of others, that seems to me fine.
I don't disagree with that view. It's the bugs I was talking about initially, and users complaining about them. You're talking about the big picture or general overview of the project. Maybe I picked up the wrong end of the stick.
I am grateful for what they do. I am grateful for being allowed to
As am I. I wouldn't even know where to start. I'm glad that people like writing software, all the way from little one-liner bash scripts right up to full blown DEs and beyond.
And anyway, whatever they do they will never please everybody. I hate
That is another truism, of course.
the revolving cube. I have just seen a eulogy from someone who loves
I quite like it, but it's not a "must have". I can easily see how others would get annoyed by it. Possibly even feel slightly ill viewing it.
On Tue, Dec 6, 2011 at 10:27 AM, Mag. Dr. Nikolaus Klepp office@klepp.biz wrote:
And that could push users away from TDE...
.. to where?
nik
Hi Nikolaus!
When I'm talking about "pushing users away", I'm not thinking about us, the people that already use Trinity for some time, because for us we already know what we want, and what is better for each one case.
I'm thinking about the many people that had see the 3.5.13 announcement and had the curiosity to install and try the new Trinity version. The question here is: - how many of them had stayed in Trinity, and not reverted back to their usual desktop??
And, other questions, that in fact are the motivation for this thread, is: - what is Trinity doing to expand is user base?? - is Trinity doing the right steps towards that goal? - or, having more people using Trinity really isn't important and does not matter to the TDE developers??
And, responding to Nikolaus, yes, there are other good desktop alternatives, but of course it depends of your use cases.
Personally, besides the "old" KDE 3.5.10, that still works well for me, for work I like very much the KNOPPIX 6.7 desktop (CD version), simple but effective, and for leisure (or light work) Windows 7 is perfect.
Jorge.
-
Brad Rogers -
Calvin Morrison -
David Hare -
Jorge Gonçalves -
Lisi -
Mag. Dr. Nikolaus Klepp -
Patrick Serru -
Timothy Pearson