[jitsi-dev] Nightly broken


#1

Hi,

please do not cc dev@jitsi.java.net, as the only mailinglist it dev@jitsi.org

Hi,

in the hope of bugs being fixed and following
the recommendation of damencho in the mail "Re: Problems with latest
client", I switched to the nightly builds. I have a few problems with
this

1. The nightly is really more unstable than I thought.

2. I do get updates every day (this is because of nightly :wink: which
聽聽聽is very annoying also because of the slow server.

Yeah there are updates every day cause we are working on the project,
fixing stuff and adding new features.

Could you explain to me the release plan, how you fix bugs and merge
them into the stable releases? The bug, that sip forwarding is not
working is a high prio bug (my feeling) and should be delivered as
a patch to the stable release. What is the release interval of the
stable version? I see that it does not get fixes or new versions
in months.

We do not deliver fixes to stable. We release a new stable version.
Once we decide, we move one of the latest nightlies into stable and
that is all.

Currently nightly does not work at all:

1. Current nightly is broken on Kubuntu 13.10, Oracle Java 1.7.
聽聽聽It does not start up. Logs show the following error:

10:07:09.166 Schwerwiegend: [37]
util.UtilActivator.uncaughtException().108 An uncaught exception
occurred in thread=Thread[AWT-EventQueue-0,6,main] and message was: null
java.lang.NullPointerException
聽聽聽聽聽聽聽聽at
net.java.sip.communicator.impl.gui.main.presence.AccountStatusPanel.loadSkin(AccountStatusPanel.java:548)
聽聽聽聽聽聽聽聽at
net.java.sip.communicator.impl.gui.main.presence.AccountStatusPanel.<init>(AccountStatusPanel.java:181)
聽聽聽聽聽聽聽聽at
net.java.sip.communicator.impl.gui.main.MainFrame.<init>(MainFrame.java:188)
聽聽聽聽聽聽聽聽at
net.java.sip.communicator.impl.gui.UIServiceImpl.loadApplicationGui(UIServiceImpl.java:148)
聽聽聽聽聽聽聽聽at
net.java.sip.communicator.impl.gui.GuiActivator$1.run(GuiActivator.java:169)
聽聽聽聽聽聽聽聽at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:251)
聽聽聽聽聽聽聽聽at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:733)
聽聽聽聽聽聽聽聽at java.awt.EventQueue.access$200(EventQueue.java:103)
聽聽聽聽聽聽聽聽at java.awt.EventQueue$3.run(EventQueue.java:694)
聽聽聽聽聽聽聽聽at java.awt.EventQueue$3.run(EventQueue.java:692)
聽聽聽聽聽聽聽聽at java.security.AccessController.doPrivileged(Native Method)
聽聽聽聽聽聽聽聽at
java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
聽聽聽聽聽聽聽聽at java.awt.EventQueue.dispatchEvent(EventQueue.java:703)
聽聽聽聽聽聽聽聽at
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
聽聽聽聽聽聽聽聽at
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
聽聽聽聽聽聽聽聽at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
聽聽聽聽聽聽聽聽at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
聽聽聽聽聽聽聽聽at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
聽聽聽聽聽聽聽聽at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)

Thanks for the report will take a look what is the problem.

Regards
damencho

路路路

On Fri, Mar 21, 2014 at 11:21 AM, Buddy Butterfly <buddy.butterfly@web.de> wrote:

Cheers,
Matt

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#2

Hi Buddy,

You sure have a mouth full of negativity to discuss here!

I'm nothing more of an end user of Jitsi and I use the latest nightly every
week day at work. I've been doing this for months now. If you find a bug in
the latest nightly, report it.

Think of MS not being able to release patches but only complete releases.

If MS is microsoft, you cannot begin to compare a giant for-profit,
prosperity company to something open source with a set number of resources
on hand. You cannot even compare Mozilla's firefox (which has nightly
releases) to Jitsi since Mozilla has much larger resources.

Keep in mind that this is open source, free software and no one is making
you use the software. I'm thankful for 100% of the project that has been
put forth by the Jitsi team and those individuals who have donated their
time and efforts to make the project.
This article seems to speak to you:
http://mhall119.com/2014/02/a-new-8020-rule-for-open-source/
Put simply, this rule says that people will tend to appreciate it more when
you give them 20% of something, and resent you if you give them 80%.

Best,
Jungle

路路路

On 21 March 2014 03:05, Buddy Butterfly <buddy.butterfly@web.de> wrote:

OK, that is one way to decide for. But this is not feasable for "end"
users as they can not switch to the nightly and have to live with the
bugs for a long time. So there is nothing inbetween getting important
bugs fixed. This could be one reason for turning away from
jitsi an look for alternatives (not me, I am adicted to, though have
thought about it as we definitely need the basic functions stable).

Think of MS not being able to release patches but only complete
releases. Either way you turn it. Either the release interval should
be reduced (shorter decision intervals) or patches to releases would
be a nice.

How do you decide a nightly is stable? Do you have some metrics like
number of JUnit tests passed, code coverage etc.? Do you have a
web page where we can see the result of the automatic build?
Jenkins? Which code quality checkers do you use (full warnings/errors in
Eclipse with stuff like "possible NullPointers", checkstyle, findbugs,
etc.)?
Welcomde. At least here the nightly is of advantage as the change
leading to the error could have happened only 1 or 2 days ago :wink:

--
-------
inum: 883510009902611
sip: jungleboogie@sip2sip.info
xmpp: jungle-boogie@jit.si


#3

Hi,

this is all we can afford for now.
There are tests that run on every build. We currently do not have the
tests results public, but don't think it is of interest anybody than
the devs, because when the build is out this means all the test that
are in the code had passed successfully.

Regards
damencho

路路路

On Fri, Mar 21, 2014 at 12:05 PM, Buddy Butterfly <buddy.butterfly@web.de> wrote:

Am 21.03.2014 10:37, schrieb Damian Minkov:

Hi,

please do not cc dev@jitsi.java.net, as the only mailinglist it dev-st2Kn3bmYpHYtjvyW6yDsg@public.gmane.org

On Fri, Mar 21, 2014 at 11:21 AM, Buddy Butterfly >> <buddy.butterfly@web.de> wrote:

Hi,

in the hope of bugs being fixed and following
the recommendation of damencho in the mail "Re: Problems with latest
client", I switched to the nightly builds. I have a few problems with
this

1. The nightly is really more unstable than I thought.

2. I do get updates every day (this is because of nightly :wink: which
聽聽聽is very annoying also because of the slow server.

Yeah there are updates every day cause we are working on the project,
fixing stuff and adding new features.

Could you explain to me the release plan, how you fix bugs and merge
them into the stable releases? The bug, that sip forwarding is not
working is a high prio bug (my feeling) and should be delivered as
a patch to the stable release. What is the release interval of the
stable version? I see that it does not get fixes or new versions
in months.

We do not deliver fixes to stable. We release a new stable version.
Once we decide, we move one of the latest nightlies into stable and
that is all.

OK, that is one way to decide for. But this is not feasable for "end"
users as they can not switch to the nightly and have to live with the
bugs for a long time. So there is nothing inbetween getting important
bugs fixed. This could be one reason for turning away from
jitsi an look for alternatives (not me, I am adicted to, though have
thought about it as we definitely need the basic functions stable).

Think of MS not being able to release patches but only complete
releases. Either way you turn it. Either the release interval should
be reduced (shorter decision intervals) or patches to releases would
be a nice.

How do you decide a nightly is stable? Do you have some metrics like
number of JUnit tests passed, code coverage etc.? Do you have a
web page where we can see the result of the automatic build?
Jenkins? Which code quality checkers do you use (full warnings/errors in
Eclipse with stuff like "possible NullPointers", checkstyle, findbugs,
etc.)?

Currently nightly does not work at all:

1. Current nightly is broken on Kubuntu 13.10, Oracle Java 1.7.
聽聽聽It does not start up. Logs show the following error:

10:07:09.166 Schwerwiegend: [37]
util.UtilActivator.uncaughtException().108 An uncaught exception
occurred in thread=Thread[AWT-EventQueue-0,6,main] and message was: null
java.lang.NullPointerException
聽聽聽聽聽聽聽聽at
net.java.sip.communicator.impl.gui.main.presence.AccountStatusPanel.loadSkin(AccountStatusPanel.java:548)
聽聽聽聽聽聽聽聽at
net.java.sip.communicator.impl.gui.main.presence.AccountStatusPanel.<init>(AccountStatusPanel.java:181)
聽聽聽聽聽聽聽聽at
net.java.sip.communicator.impl.gui.main.MainFrame.<init>(MainFrame.java:188)
聽聽聽聽聽聽聽聽at
net.java.sip.communicator.impl.gui.UIServiceImpl.loadApplicationGui(UIServiceImpl.java:148)
聽聽聽聽聽聽聽聽at
net.java.sip.communicator.impl.gui.GuiActivator$1.run(GuiActivator.java:169)
聽聽聽聽聽聽聽聽at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:251)
聽聽聽聽聽聽聽聽at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:733)
聽聽聽聽聽聽聽聽at java.awt.EventQueue.access$200(EventQueue.java:103)
聽聽聽聽聽聽聽聽at java.awt.EventQueue$3.run(EventQueue.java:694)
聽聽聽聽聽聽聽聽at java.awt.EventQueue$3.run(EventQueue.java:692)
聽聽聽聽聽聽聽聽at java.security.AccessController.doPrivileged(Native Method)
聽聽聽聽聽聽聽聽at
java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
聽聽聽聽聽聽聽聽at java.awt.EventQueue.dispatchEvent(EventQueue.java:703)
聽聽聽聽聽聽聽聽at
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
聽聽聽聽聽聽聽聽at
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
聽聽聽聽聽聽聽聽at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
聽聽聽聽聽聽聽聽at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
聽聽聽聽聽聽聽聽at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
聽聽聽聽聽聽聽聽at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)

Thanks for the report will take a look what is the problem.

Welcomde. At least here the nightly is of advantage as the change
leading to the error could have happened only 1 or 2 days ago :wink:

Regards
damencho

Cheers,
Matt

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#4

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

路路路

Am 21.03.2014 19:22, schrieb jungleboogie0:

Hi Buddy,

You sure have a mouth full of negativity to discuss here!

I'm nothing more of an end user of Jitsi and I use the latest nightly
every week day at work. I've been doing this for months now. If you
find a bug in the latest nightly, report it.

>Think of MS not being able to release patches but only complete releases.

If MS is microsoft, you cannot begin to compare a giant for-profit,
prosperity company to something open source with a set number of
resources on hand. You cannot even compare Mozilla's firefox (which
has nightly releases) to Jitsi since Mozilla has much larger resources.

Keep in mind that this is open source, free software and no one is
making you use the software. I'm thankful for 100% of the project that
has been put forth by the Jitsi team and those individuals who have
donated their time and efforts to make the project.
This article seems to speak to
you: http://mhall119.com/2014/02/a-new-8020-rule-for-open-source/
Put simply, this rule says that people will tend to appreciate it more
when you give them 20% of something, and resent you if you give them
80%.

Best,
Jungle

On 21 March 2014 03:05, Buddy Butterfly <buddy.butterfly@web.de > <mailto:buddy.butterfly@web.de>> wrote:

OK, that is one way to decide for. But this is not feasable for "end"
users as they can not switch to the nightly and have to live with the
bugs for a long time. So there is nothing inbetween getting important
bugs fixed. This could be one reason for turning away from
jitsi an look for alternatives (not me, I am adicted to, though have
thought about it as we definitely need the basic functions stable).

Think of MS not being able to release patches but only complete
releases. Either way you turn it. Either the release interval should
be reduced (shorter decision intervals) or patches to releases would
be a nice.

How do you decide a nightly is stable? Do you have some metrics like
number of JUnit tests passed, code coverage etc.? Do you have a
web page where we can see the result of the automatic build?
Jenkins? Which code quality checkers do you use (full warnings/errors in
Eclipse with stuff like "possible NullPointers", checkstyle, findbugs,
etc.)?
Welcomde. At least here the nightly is of advantage as the change
leading to the error could have happened only 1 or 2 days ago :wink:

--
-------
inum: 883510009902611
sip: jungleboogie@sip2sip.info <mailto:jungleboogie@sip2sip.info>
xmpp: jungle-boogie@jit.si <mailto:jungle-boogie@jit.si>


#5

The error in the nightly should be fixed in next build which is on the way.

路路路

On Fri, Mar 21, 2014 at 12:17 PM, Damian Minkov <damencho@jitsi.org> wrote:

Hi,

this is all we can afford for now.
There are tests that run on every build. We currently do not have the
tests results public, but don't think it is of interest anybody than
the devs, because when the build is out this means all the test that
are in the code had passed successfully.

Regards
damencho

On Fri, Mar 21, 2014 at 12:05 PM, Buddy Butterfly > <buddy.butterfly@web.de> wrote:

Am 21.03.2014 10:37, schrieb Damian Minkov:

Hi,

please do not cc dev@jitsi.java.net, as the only mailinglist it dev-st2Kn3bmYpHYtjvyW6yDsg@public.gmane.org

On Fri, Mar 21, 2014 at 11:21 AM, Buddy Butterfly >>> <buddy.butterfly@web.de> wrote:

Hi,

in the hope of bugs being fixed and following
the recommendation of damencho in the mail "Re: Problems with latest
client", I switched to the nightly builds. I have a few problems with
this

1. The nightly is really more unstable than I thought.

2. I do get updates every day (this is because of nightly :wink: which
聽聽聽is very annoying also because of the slow server.

Yeah there are updates every day cause we are working on the project,
fixing stuff and adding new features.

Could you explain to me the release plan, how you fix bugs and merge
them into the stable releases? The bug, that sip forwarding is not
working is a high prio bug (my feeling) and should be delivered as
a patch to the stable release. What is the release interval of the
stable version? I see that it does not get fixes or new versions
in months.

We do not deliver fixes to stable. We release a new stable version.
Once we decide, we move one of the latest nightlies into stable and
that is all.

OK, that is one way to decide for. But this is not feasable for "end"
users as they can not switch to the nightly and have to live with the
bugs for a long time. So there is nothing inbetween getting important
bugs fixed. This could be one reason for turning away from
jitsi an look for alternatives (not me, I am adicted to, though have
thought about it as we definitely need the basic functions stable).

Think of MS not being able to release patches but only complete
releases. Either way you turn it. Either the release interval should
be reduced (shorter decision intervals) or patches to releases would
be a nice.

How do you decide a nightly is stable? Do you have some metrics like
number of JUnit tests passed, code coverage etc.? Do you have a
web page where we can see the result of the automatic build?
Jenkins? Which code quality checkers do you use (full warnings/errors in
Eclipse with stuff like "possible NullPointers", checkstyle, findbugs,
etc.)?

Currently nightly does not work at all:

1. Current nightly is broken on Kubuntu 13.10, Oracle Java 1.7.
聽聽聽It does not start up. Logs show the following error:

10:07:09.166 Schwerwiegend: [37]
util.UtilActivator.uncaughtException().108 An uncaught exception
occurred in thread=Thread[AWT-EventQueue-0,6,main] and message was: null
java.lang.NullPointerException
聽聽聽聽聽聽聽聽at
net.java.sip.communicator.impl.gui.main.presence.AccountStatusPanel.loadSkin(AccountStatusPanel.java:548)
聽聽聽聽聽聽聽聽at
net.java.sip.communicator.impl.gui.main.presence.AccountStatusPanel.<init>(AccountStatusPanel.java:181)
聽聽聽聽聽聽聽聽at
net.java.sip.communicator.impl.gui.main.MainFrame.<init>(MainFrame.java:188)
聽聽聽聽聽聽聽聽at
net.java.sip.communicator.impl.gui.UIServiceImpl.loadApplicationGui(UIServiceImpl.java:148)
聽聽聽聽聽聽聽聽at
net.java.sip.communicator.impl.gui.GuiActivator$1.run(GuiActivator.java:169)
聽聽聽聽聽聽聽聽at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:251)
聽聽聽聽聽聽聽聽at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:733)
聽聽聽聽聽聽聽聽at java.awt.EventQueue.access$200(EventQueue.java:103)
聽聽聽聽聽聽聽聽at java.awt.EventQueue$3.run(EventQueue.java:694)
聽聽聽聽聽聽聽聽at java.awt.EventQueue$3.run(EventQueue.java:692)
聽聽聽聽聽聽聽聽at java.security.AccessController.doPrivileged(Native Method)
聽聽聽聽聽聽聽聽at
java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
聽聽聽聽聽聽聽聽at java.awt.EventQueue.dispatchEvent(EventQueue.java:703)
聽聽聽聽聽聽聽聽at
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
聽聽聽聽聽聽聽聽at
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
聽聽聽聽聽聽聽聽at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
聽聽聽聽聽聽聽聽at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
聽聽聽聽聽聽聽聽at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
聽聽聽聽聽聽聽聽at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)

Thanks for the report will take a look what is the problem.

Welcomde. At least here the nightly is of advantage as the change
leading to the error could have happened only 1 or 2 days ago :wink:

Regards
damencho

Cheers,
Matt

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#6

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


#7

Interesting discussion. I use the nightly in my stable environment due to the reasons you mention. It has so far worked more reliable then most Jitsi stables I tried.

I learned to live with the occasional glitch here and there and try to report issues as I see them.

2Cent, mine.

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

Hi Buddy,

You sure have a mouth full of negativity to discuss here!

I'm nothing more of an end user of Jitsi and I use the latest nightly every week day at work. I've been doing this for months now. If you find a bug in the latest nightly, report it.

Think of MS not being able to release patches but only complete releases.

If MS is microsoft, you cannot begin to compare a giant for-profit, prosperity company to something open source with a set number of resources on hand. You cannot even compare Mozilla's firefox (which has nightly releases) to Jitsi since Mozilla has much larger resources.

Keep in mind that this is open source, free software and no one is making you use the software. I'm thankful for 100% of the project that has been put forth by the Jitsi team and those individuals who have donated their time and efforts to make the project.
This article seems to speak to you: http://mhall119.com/2014/02/a-new-8020-rule-for-open-source/
Put simply, this rule says that people will tend to appreciate it more when you give them 20% of something, and resent you if you give them 80%.

Best,
Jungle

路路路

Am 21.03.2014 um 21:30 schrieb Buddy Butterfly <buddy.butterfly@web.de>:
Am 21.03.2014 19:22, schrieb jungleboogie0:

On 21 March 2014 03:05, Buddy Butterfly <buddy.butterfly@web.de> wrote:

OK, that is one way to decide for. But this is not feasable for "end"
users as they can not switch to the nightly and have to live with the
bugs for a long time. So there is nothing inbetween getting important
bugs fixed. This could be one reason for turning away from
jitsi an look for alternatives (not me, I am adicted to, though have
thought about it as we definitely need the basic functions stable).

Think of MS not being able to release patches but only complete
releases. Either way you turn it. Either the release interval should
be reduced (shorter decision intervals) or patches to releases would
be a nice.

How do you decide a nightly is stable? Do you have some metrics like
number of JUnit tests passed, code coverage etc.? Do you have a
web page where we can see the result of the automatic build?
Jenkins? Which code quality checkers do you use (full warnings/errors in
Eclipse with stuff like "possible NullPointers", checkstyle, findbugs,
etc.)?
Welcomde. At least here the nightly is of advantage as the change
leading to the error could have happened only 1 or 2 days ago :wink:

--
-------
inum: 883510009902611
sip: jungleboogie@sip2sip.info
xmpp: jungle-boogie@jit.si

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev