Cheers Matt,
I do not want to spread out a lot of negativity but was
suggesting / wanted to discuss how the process of handling
patches could be enhanced
Thanks for the clarification. There's hundreds and hundreds of
projects that probably would be very beneficial if they had technical
writers and very formal processes. I don't know if that's how
Jitsi operates.
Regarding the bug reports for the nightly, I do report
them. So there is no problem. damencho already fixed
it.
Well done! I've found a couple bugs and they get fixed pretty
promptly as well.
I just experienced with the so called stable version
(which is called unstable in the ubuntu repo) not only
progression but also regression which disables base
functionality that was there earlier.
I stopped using GNU/Linux when I realized that I couldn't get
updated software very easily with apt or with yum without the need
to add a bunch of repos. Some people call Centos a stable OS since
you know what version of php will be there forever, but others call
it outdated and only critical security flaws are patched.
For important
bugs I waited a while because I thought, this would
be fixed very quick anyway because it will be noticed
quickly.
I suppose things could be fixed quickly but it wouldn't be
pushed into the latest stable until the next release (IF I'M
UNDERSTANDING THE PROCESS CORRECTLY). This is the same for CentOS, though.
Unless you add a third party repo to yum, your version of php won't
increment.
In Ubuntu, can you choose between what php versions you have without
adding additional repos?
Then, after waiting a long time I reported the
bug to hear it has been fixed in nightly. I just
want to kick off a discussion on how to handle this.
Good point. As mentioned, having good documentation for an
organization or project is very helpful. The FreeBSD foundation,
FreeNAS, PCBSD have well written and often updated documentation--for free.
Does, if someone really likes jitsi like me (am also
100% thankful for what has been done already) and you
mean that we should not discuss about improvement?
Not in my opinion. In fact, the request I've made is for
Jitsi to have some way to clear the recent call log.
Since I'm no developer, I can' make the change and send in
some patch. Unfortunately, this means my requests could
fall on deaf ears. There's many things I would like different
in paid software/services, too, but my requests could also
fall on deaf ears if there's not enough requests for that to
be improved.
So what you are telling me is basically anyone out
there keep quiet and take jitsi like we give it to you.
Not true. I just linked to an article that was written shortly
after Mozilla said FireFox will have ads on your tiles in place of
your recent website visits.
You can believe me, I would not spend my time reporting
bugs, using and testing jitsi if I would not care about
it. I want to help it make better.
That seems like a very reasonable approach to take!
So questioning again the stable/nightly stuff. If,
when discovering bugs, it is always recommended to use
the nightly, then why not drop the stable version and
only run the nightly?
A few weeks ago, there was a Debian guy that I chatted with
that appreciates 'stable' software as he believes it to
not contain anything worse than the previous stable version.
I said that nightly versions often have more features and bug fixes
but he is willing to wait for the Jitsi group to determine when
the next stable release is and he will us that. It seems jitsi
already has a repo for nightly on debian...but it's the old adding the repo
bit: https://jitsi.org/Main/DebianNightlyRepository
Could debian/ubuntu have a nightly repo for Jitsi or would that not be in
compliance?
You do not do this because
all of you have decided to have some stable release
that does not get updated so often and has undergone
some more intensive tests (you must have had a reason
for this!?). If so, and I support this, then why not
think about releasing patches / minor releases for the
stable?
If you take a look at the debian stable and compare to Windows
and Mac, the version will be different, so patches could be made
to stable versions, but those that already have the stable verion
installed, may not get the newest updates. Jitsi does have a check
for updates option that may tell the user to get latest stable--I don't
know.
I really would like to help jitsi to become more
known and more widely used. This is not only achieved
with features but also with stability. So, if you have
your next feature freeze then just prolong it a bit
further (2-3 month) and make a short test plan for
the different parts of jitsi. You then can ask here
in the list who will want to take which part and
people can take over the testing.
I will also be happy tho help out here.
I share the same feeling here.
Ciao,
Jungle
路路路
On 21 March 2014 13:30, Buddy Butterfly <buddy.butterfly@web.de> wrote:
Hi Jungle,
I do not want to spread out a lot of negativity but was
suggesting / wanted to discuss how the process of handling
patches could be enhanced. Ok, the comparison with MS was
not appropriate. But even small projects normally have some
kind of organizational workflow for patches and their
prioritization. I guess that all developers of jitsi
are developers by profession in software companies and
I just wanted to ask which of their standard quality
assurance they use at work are also applied to Jitsi.
Regarding the bug reports for the nightly, I do report
them. So there is no problem. damencho already fixed
it.
I just experienced with the so called stable version
(which is called unstable in the ubuntu repo) not only
progression but also regression which disables base
functionality that was there earlier. For important
bugs I waited a while because I thought, this would
be fixed very quick anyway because it will be noticed
quickly. Then, after waiting a long time I reported the
bug to hear it has been fixed in nightly. I just
want to kick off a discussion on how to handle this.
Does, if someone really likes jitsi like me (am also
100% thankful for what has been done already) and you
mean that we should not discuss about improvement?
So what you are telling me is basically anyone out
there keep quiet and take jitsi like we give it to you.
You can believe me, I would not spend my time reporting
bugs, using and testing jitsi if I would not care about
it. I want to help it make better.
So questioning again the stable/nightly stuff. If,
when discovering bugs, it is always recommended to use
the nightly, then why not drop the stable version and
only run the nightly? You do not do this because
all of you have decided to have some stable release
that does not get updated so often and has undergone
some more intensive tests (you must have had a reason
for this!?). If so, and I support this, then why not
think about releasing patches / minor releases for the
stable?
I really would like to help jitsi to become more
known and more widely used. This is not only achieved
with features but also with stability. So, if you have
your next feature freeze then just prolong it a bit
further (2-3 month) and make a short test plan for
the different parts of jitsi. You then can ask here
in the list who will want to take which part and
people can take over the testing.
I will also be happy tho help out here.
Cheers,
Matt
--
-------
inum: 883510009902611
sip: jungleboogie@sip2sip.info
xmpp: jungle-boogie@jit.si
which