Yes, this is a coup....
Well, i don't think i'm saying anything controversial, when i'm saying
that pearson has no time for trinity, and the project is effectively
leaderless.
From the perspective of an outsider (me),
Slavek seams the most invested in the project....
Maybe he should be in charge.
Ok, everyone listen.
I'm proposing to split the programs, in official trinity
and extra. The list of official packages should be restricted.
They should be of good enough quality and as a whole should
be close to the functionality of DE like MATE and xfce. The devs
should decide upon the list, and then make sure they maintain
their quality. They should be renamed, with proper names, not
kdename-trinity, and pulled out of opt. In extra will be everything
else. The idea is, for the official part to be more appealing to distros.
If trinity get's in to distros, it will have more exposure and get more devs.
an initial proposal of what the official packages could be:
all the base system and libs of course
kdesktop, kicker, tdenetwork manager, tdm, kmix, klipper, control center,
dolphin, kwrite, kmail, kwallet, kaffeine, konsole, amarok, kalculator,
gwenview, ark, kpdf other?.
konqueror is not good enough for a default file manager because of
it's outdated web browsing component.
all the above should get proper names, not kdename-trinity
and moved out of opt. Even the libs, should be renamed something
like trinity libs, not tqt. The stuff in extra can stay in opt as it is.
And don't forget, the quality of what will be in the list must stay
good enough, you can't just shove everything. Once the list will
be desided, then it will need to be decided how to rename them.
The whole point of this, is to have something nice, the distros can
accept taking in. They should not see "Konqueror-trinity" that
can't render facebook or youtube. The whole point of getting accepted
by distros, is so that the project gets more exposure and hence more devs.
I'm proposing to move to github.
Not for technical reasons.
Github is the facebook of open source.
Been there, should attract more devs....
Moving the code will be simple enough.
The bugs however will not be straight forward....
I hope i'll get more responces then usual. -_-
If no one responds, a kitten will die.
I think trinity doesn't has much of a strategy.
Here some ideas
----------------------------------------------
trinity would be split in to two parts
1.trinity proper
This will be a relatively restricted set of important components
of high quality. This will be a bit like other normal DE, like xfce and mate.
For example, it will have the libs, kdesktop, kicker, tdm, konsole, amarok,
kaffeine, dolphin, klipper etc... See restricted, important and high quality.
2. trinity extra apps
Here goes everything else
trinity proper will be given priority in fixing bugs.
Also, all of trinity proper would be properly renamed
and moved out of opt. for example tqt becomes
trinity libs, konsole becomes trinity terminal
or something like that. See proper names, not kdename-trinity.
Then, an attempt would be made, to push trinity proper
to debian. And from there it would move up ubuntu.
Trinity will get more exposure, more users and more bug fixes,
including for trinity extra apps.
For the extra apps, users would use an extra repo like now.
The names can stay "kdename-trinity" or be fully renamed.
And the quality maters less. At some unspecified time in the
future, apps from here will be moved to trinity proper.
--------------------------------
an other idea would be, to move the code to github
Not for technical reasons. Many developers are already there.
This will increase the probability that the project will get more
exposure and devs.
alex couture has made a pclinuxos remaster with tde.
He's asking to be uploaded on trinity servers.
https://bugs.pearsoncomputing.net/show_bug.cgi?id=2864
Maybe this should be decided upon, before 14.0.5 comes out....
Hi,
I looked yesterday in kmix code and I see this, which I think is a bit
wrong, or I do not understand why close() is called even if open fails - we
just want to know if mixer is valid.
bool Mixer_Backend::isValid() {
bool valid = false;
int ret = open();
if ( ret == 0 && m_mixDevices.count() > 0) {
valid = true;
}
close();
return valid;
}
regards
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Dear all,
re-sending without autocrypt option. There has been some reports of problems with SPAM filters discarding the previous
email.
If you already received the first message yesterday, please ignore this one and accept our apologies for the double
sending.
If you didn't get the original email, please read below.
Cheers
Michele, Slavek
- --------------------
Dear all,
we would like to explain the process of how bug reports get added to
the next release bug list.
As many of you probably know, there are some bug reports (that we call
meta bugs) that serve as an index for bugs to fix or already fixed for
the next maintenance and minor release. For example bug 2247 for
R14.1.0, bug 2696 for R14.0.5 and bug 2885 for R14.0.6.
These meta bugs are intended to list bugs that have been selected by
the developers for the mentioned coming release, so we would like to
invite all of you to refrain from directly adding bugs to those lists
on your own. Instead you should first discuss with one of the
developers (say Tim, Slavek or Michele) and if agreed, you can then add
the bug to the discussed list.
The reason for this logic (and limitation) is that if anyone just add
bugs indiscriminately based on their own needs, those lists would grow
out of control and out of what is physically possible to achieve with
the development workforce that TDE has at the moment.
We encourage all of you to participate in making TDE better, but please
take note of the above procedure and try sticking to it as much as
possible.
On a side note, R14.0.5 bug list has been frozen and no other bugs will
go into it unless critical of blockers. Of course, if a working patch
is provided before the release of R14.0.5, we will consider that for
inclusion.
Feel free to provide your feedback on the process explain above
Cheers
Michele, Slavek
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEjhl1z5vbYB3YbFTiKnW3yore1c8FAlsD2uwACgkQKnW3yore
1c9tjw/9GTvzkZULvstj5VBBWjdJgfbkFQ+hDq8c7cRleKDqDwwK89uSdWshe6G7
VU5fwH82CScdF4itYr8GxZvwmZPcLtPvy83WLsEPL4pvC8oNoUZtHkqNniL8CP14
wfiUZcFuQvMa251i2KP0a1QBREd8xJhbj09obfz8YFa9sRQq0cauMgMDqxVOR+6U
0MU8CgTNplh49XWAjX9e5upwsgvqEb58e53h0XsYOn9aM+tvUOnCaKA83eIlICUe
R6qt5807sKPbd2fXlpSNmtprPllwo/OKse/KUrCq0a3hifG64xapwub/S+ylGFpf
Q2RfHxvKVUnSOyElNe7wYYjVhBv5qCcGO4mE7uR8TwsN3ta2vL226aw5rNv8Oarb
nNKrjBO5Ey3F4wxhFI5ZNOmQqU6eqSvqwiT2lN2nVZ0CCuXGDScXcHo8gLM3j6la
9hSE/R8KouLtef2NyrFB1ObWtn2p4geAbQKVTyr9sQyS2K07Fyub2qeamdJeOyEV
1HtCzK+ot3QwD+jrTfQEigJGUitW4DPfy6iVLHBJz+B5kkOspYJq8Ks9EQh/Zya0
BNRKpqettm6RlOchuNHa7NWuPOyQUyyPnBI371+EsBAohZdgm0Nuis9RYVnoXII0
YO9F31g8dfY9rCTJ9CkFV4GpA6879uswTcxEf/AEod/m4ZdhnR8=
=lSLn
-----END PGP SIGNATURE-----