Helping Coolo

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Helping Coolo

Cristian Morales Vega-3
Since I am not it Prague any more. My POV about the "Release Schedule
Discussion".

Basically people mostly cares about his particular work, and not about
the distribution as a whole. The work in the distribution as a whole
is left to Coolo and few more people. Since what we need is more
people to look at it, some problems/things to do:

- Make https://build.opensuse.org/project/status?project=openSUSE%3AFactory
the homepage of more people
Too many clicks are required to reach the Factory status page. It's
like if someone wanted to hide it. Not that I think it actually makes
such a difference, but we should try to make it more visible.
But the big problem is that it takes 30+ seconds to load it. Sometimes
I actually don't look at it just because I don't want to wait. There
is nothing that can be done about it? Caching?

Make it fast and visible and more people will know about Factory
status. The essential first step to get people to help.

- Make people want to work on the problems
Now I already loaded the Factory status page. I look at the list and I
usually find two kind of entries: the ones that are so important that
I am sure somebody else is already working on it (or is already fixed
but lacks a rebuild), and the ones I don't care about.

I mean, yast2-network has been failing to build for 11 days??? It
can't actually be true, is it? And if it is for sure it's just because
it's a complex problem, but somebody has been working on it for 10
days. I guess something similar is happening with libreoffice.

But "qutim"? Yet another instant messenger? It's the first time I
listen about it. I just can't find the motivation to look into it.

For the first problem we need some easy and visible way to see if
somebody else already took responsibility to fix a problem. Without
this people just doesn't help because they don't think their help is
needed. The Factory status page needs an extra column with the name of
the person working on the problem.

For the second problem we need a defined policy for dropping packages.
If a package doesn't build for a long time and nobody fixes it...
well, just drop it. It's clear nobody cares enough.
I am sure it could be improved, but let's say: "If a package doesn't
build for 30 days mark it for dropping. Announce it, with a list of
all the current packages marked for dropping everywhere. Send the
announcement to -factory/-packaging. Put it in news.opensuse.org. Have
it in the forums so users also now. Perhaps let forum users vote for
the packages they actually care. If after 60 days it still fails to
build the package gets dropped, with also an announcement."

- Inform maintainers when their update breaks other packages
Sure, perhaps the kernel maintainer doesn't care if an out-of-tree
module breaks. But some people *may* actually care if their update of
a library breaks an application. Let's send an automatic email to
them. If they don't care they will just ignore the email, if they
care... great!
I guess it's not so obvious to automatically know what package broke
another one. But we can know the problem was caused by a package in a
subset, at the very least "the whole list of modified packages".
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Helping Coolo

Stephan Kulow-3
Am 23.10.2012 12:09, schrieb Cristian Morales Vega:

> Since I am not it Prague any more. My POV about the "Release Schedule
> Discussion".
>
> Basically people mostly cares about his particular work, and not about
> the distribution as a whole. The work in the distribution as a whole
> is left to Coolo and few more people. Since what we need is more
> people to look at it, some problems/things to do:
>
> - Make https://build.opensuse.org/project/status?project=openSUSE%3AFactory
> the homepage of more people
> Too many clicks are required to reach the Factory status page. It's
> like if someone wanted to hide it. Not that I think it actually makes
> such a difference, but we should try to make it more visible.
> But the big problem is that it takes 30+ seconds to load it. Sometimes
> I actually don't look at it just because I don't want to wait. There
> is nothing that can be done about it? Caching?
It's already cached for openSUSE:Factory - it takes over an hour to
gather all the information ;(

And the reason it's hidden - as you say - is exactly the speed issue.

>
> Make it fast and visible and more people will know about Factory
> status. The essential first step to get people to help.
>
> - Make people want to work on the problems
> Now I already loaded the Factory status page. I look at the list and I
> usually find two kind of entries: the ones that are so important that
> I am sure somebody else is already working on it (or is already fixed
> but lacks a rebuild), and the ones I don't care about.
>
> I mean, yast2-network has been failing to build for 11 days??? It
> can't actually be true, is it? And if it is for sure it's just because
> it's a complex problem, but somebody has been working on it for 10
> days. I guess something similar is happening with libreoffice.

As usually people do not even know the build fails, I wouldn't assume that.


> But "qutim"? Yet another instant messenger? It's the first time I
> listen about it. I just can't find the motivation to look into it.
Fine, but at least someone could ping the maintainer - that someone is
coolo too and as the topic is about helping coolo... ;)

>
> For the first problem we need some easy and visible way to see if
> somebody else already took responsibility to fix a problem. Without
> this people just doesn't help because they don't think their help is
> needed. The Factory status page needs an extra column with the name of
> the person working on the problem.
It's fair, but so far the build service does not have support for that
level of collaboration - perhaps it should, basically creating an
"issue" (in github terms) for every build failure to discuss and assign.

>
> For the second problem we need a defined policy for dropping packages.
> If a package doesn't build for a long time and nobody fixes it...
> well, just drop it. It's clear nobody cares enough.
I already do that - my limit is > 100 days though.

> I am sure it could be improved, but let's say: "If a package doesn't
> build for 30 days mark it for dropping. Announce it, with a list of
> all the current packages marked for dropping everywhere. Send the
> announcement to -factory/-packaging. Put it in news.opensuse.org. Have
> it in the forums so users also now. Perhaps let forum users vote for
> the packages they actually care. If after 60 days it still fails to
> build the package gets dropped, with also an announcement."
Sounds like a perfect job for a volunteer - build failure drop police
officer? :)

>
> - Inform maintainers when their update breaks other packages
> Sure, perhaps the kernel maintainer doesn't care if an out-of-tree
> module breaks. But some people *may* actually care if their update of
> a library breaks an application. Let's send an automatic email to
> them. If they don't care they will just ignore the email, if they
> care... great!
> I guess it's not so obvious to automatically know what package broke
> another one. But we can know the problem was caused by a package in a
> subset, at the very least "the whole list of modified packages".
>
Yeah, that would be good to have. That brings us into the "hermes needs
closer integration with OBS" topic we had at the "future of OBS" BoF.
People should get a mail whenever their package fails in factory with
the information of the changeset of depending packages since the last
successful build - for example.

Greetings, Stephan

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Helping Coolo

Larry Finger
On 10/25/2012 10:40 AM, Stephan Kulow wrote:

>
>> I am sure it could be improved, but let's say: "If a package doesn't
>> build for 30 days mark it for dropping. Announce it, with a list of
>> all the current packages marked for dropping everywhere. Send the
>> announcement to -factory/-packaging. Put it in news.opensuse.org. Have
>> it in the forums so users also now. Perhaps let forum users vote for
>> the packages they actually care. If after 60 days it still fails to
>> build the package gets dropped, with also an announcement."
> Sounds like a perfect job for a volunteer - build failure drop police
> officer? :)

I am willing to take on that job, but I will need some training.

Larry

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Helping Coolo

Cristian Morales Vega-3
In reply to this post by Stephan Kulow-3
On 25 October 2012 16:40, Stephan Kulow <[hidden email]> wrote:

> Am 23.10.2012 12:09, schrieb Cristian Morales Vega:
>> Since I am not it Prague any more. My POV about the "Release Schedule
>> Discussion".
>>
>> Basically people mostly cares about his particular work, and not about
>> the distribution as a whole. The work in the distribution as a whole
>> is left to Coolo and few more people. Since what we need is more
>> people to look at it, some problems/things to do:
>>
>> - Make https://build.opensuse.org/project/status?project=openSUSE%3AFactory
>> the homepage of more people
>> Too many clicks are required to reach the Factory status page. It's
>> like if someone wanted to hide it. Not that I think it actually makes
>> such a difference, but we should try to make it more visible.
>> But the big problem is that it takes 30+ seconds to load it. Sometimes
>> I actually don't look at it just because I don't want to wait. There
>> is nothing that can be done about it? Caching?
> It's already cached for openSUSE:Factory - it takes over an hour to
> gather all the information ;(
>
> And the reason it's hidden - as you say - is exactly the speed issue.

Kind of a problem, but OK. Let's pass to the workarounds...

>> Make it fast and visible and more people will know about Factory
>> status. The essential first step to get people to help.
>>
>> - Make people want to work on the problems
>> Now I already loaded the Factory status page. I look at the list and I
>> usually find two kind of entries: the ones that are so important that
>> I am sure somebody else is already working on it (or is already fixed
>> but lacks a rebuild), and the ones I don't care about.
>>
>> I mean, yast2-network has been failing to build for 11 days??? It
>> can't actually be true, is it? And if it is for sure it's just because
>> it's a complex problem, but somebody has been working on it for 10
>> days. I guess something similar is happening with libreoffice.
>
> As usually people do not even know the build fails, I wouldn't assume that.

Can someone clear this for me? Right now if a package fails to build
in Factory I don't get notified just by this fact? But I will get
notified once it fails in the devel project (and I guess... *hope*
that this is the case for most people). Now, the devel project
probably is building against "snapshot", not against "standard". So
people is usually notified after... how often there are snapshots?

>> But "qutim"? Yet another instant messenger? It's the first time I
>> listen about it. I just can't find the motivation to look into it.
> Fine, but at least someone could ping the maintainer - that someone is
> coolo too and as the topic is about helping coolo... ;)

You are scaring me here. Doesn't people usually get automatically
"pinged" when the package starts to fail in the devel project?

>> For the first problem we need some easy and visible way to see if
>> somebody else already took responsibility to fix a problem. Without
>> this people just doesn't help because they don't think their help is
>> needed. The Factory status page needs an extra column with the name of
>> the person working on the problem.
> It's fair, but so far the build service does not have support for that
> level of collaboration - perhaps it should, basically creating an
> "issue" (in github terms) for every build failure to discuss and assign.
>
>>
>> For the second problem we need a defined policy for dropping packages.
>> If a package doesn't build for a long time and nobody fixes it...
>> well, just drop it. It's clear nobody cares enough.
> I already do that - my limit is > 100 days though.
>
>> I am sure it could be improved, but let's say: "If a package doesn't
>> build for 30 days mark it for dropping. Announce it, with a list of
>> all the current packages marked for dropping everywhere. Send the
>> announcement to -factory/-packaging. Put it in news.opensuse.org. Have
>> it in the forums so users also now. Perhaps let forum users vote for
>> the packages they actually care. If after 60 days it still fails to
>> build the package gets dropped, with also an announcement."
> Sounds like a perfect job for a volunteer - build failure drop police
> officer? :)

If for Saturday/Sunday nobody has done it before I will try to do a test.

>> - Inform maintainers when their update breaks other packages
>> Sure, perhaps the kernel maintainer doesn't care if an out-of-tree
>> module breaks. But some people *may* actually care if their update of
>> a library breaks an application. Let's send an automatic email to
>> them. If they don't care they will just ignore the email, if they
>> care... great!
>> I guess it's not so obvious to automatically know what package broke
>> another one. But we can know the problem was caused by a package in a
>> subset, at the very least "the whole list of modified packages".
>>
> Yeah, that would be good to have. That brings us into the "hermes needs
> closer integration with OBS" topic we had at the "future of OBS" BoF.
> People should get a mail whenever their package fails in factory with
> the information of the changeset of depending packages since the last
> successful build - for example.

There are videos of the BoFs?
The conclusion was "needs it" or "needs it, it should be ready in two months"?
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Helping Coolo

Claudio Freire
In reply to this post by Stephan Kulow-3
On Thu, Oct 25, 2012 at 12:40 PM, Stephan Kulow <[hidden email]> wrote:

>> - Make https://build.opensuse.org/project/status?project=openSUSE%3AFactory
>> the homepage of more people
>> Too many clicks are required to reach the Factory status page. It's
>> like if someone wanted to hide it. Not that I think it actually makes
>> such a difference, but we should try to make it more visible.
>> But the big problem is that it takes 30+ seconds to load it. Sometimes
>> I actually don't look at it just because I don't want to wait. There
>> is nothing that can be done about it? Caching?
> It's already cached for openSUSE:Factory - it takes over an hour to
> gather all the information ;(
>
> And the reason it's hidden - as you say - is exactly the speed issue.

Any idea what the bottleneck is?

Maybe it can be improved.
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Helping Coolo

Stephan Kulow-3
Am 25.10.2012 18:58, schrieb Claudio Freire:

> On Thu, Oct 25, 2012 at 12:40 PM, Stephan Kulow <[hidden email]> wrote:
>>> - Make https://build.opensuse.org/project/status?project=openSUSE%3AFactory
>>> the homepage of more people
>>> Too many clicks are required to reach the Factory status page. It's
>>> like if someone wanted to hide it. Not that I think it actually makes
>>> such a difference, but we should try to make it more visible.
>>> But the big problem is that it takes 30+ seconds to load it. Sometimes
>>> I actually don't look at it just because I don't want to wait. There
>>> is nothing that can be done about it? Caching?
>> It's already cached for openSUSE:Factory - it takes over an hour to
>> gather all the information ;(
>>
>> And the reason it's hidden - as you say - is exactly the speed issue.
>
> Any idea what the bottleneck is?
>
Yeah, the build service :)

Greetings, Stephan

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Helping Coolo

Claudio Freire
On Thu, Oct 25, 2012 at 2:08 PM, Stephan Kulow <[hidden email]> wrote:
>> Any idea what the bottleneck is?
>>
> Yeah, the build service :)
>
> Greetings, Stephan

Then it's easy to fix. Just swap it with a faster one.

:)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Helping Coolo

Wolfgang Rosenauer-4
In reply to this post by Cristian Morales Vega-3
Hi,

Am 25.10.2012 18:56, schrieb Cristian Morales Vega:

> On 25 October 2012 16:40, Stephan Kulow <[hidden email]> wrote:
>>>
>>> I mean, yast2-network has been failing to build for 11 days??? It
>>> can't actually be true, is it? And if it is for sure it's just because
>>> it's a complex problem, but somebody has been working on it for 10
>>> days. I guess something similar is happening with libreoffice.
>>
>> As usually people do not even know the build fails, I wouldn't assume that.
>
> Can someone clear this for me? Right now if a package fails to build
> in Factory I don't get notified just by this fact? But I will get
> notified once it fails in the devel project (and I guess... *hope*
> that this is the case for most people). Now, the devel project
> probably is building against "snapshot", not against "standard". So
> people is usually notified after... how often there are snapshots?
>
>>> But "qutim"? Yet another instant messenger? It's the first time I
>>> listen about it. I just can't find the motivation to look into it.
>> Fine, but at least someone could ping the maintainer - that someone is
>> coolo too and as the topic is about helping coolo... ;)
>
> You are scaring me here. Doesn't people usually get automatically
> "pinged" when the package starts to fail in the devel project?

I _think_ people are actually not pinged.
And I'm not sure if my Hermes just is configured the wrong way or
something else is not as it should be.
OBS knows that I'm the maintainer apparently:

wolfi@Hygiea:~> osc maintainer openSUSE:Factory MozillaFirefox
bugowner of mozilla:Factory/MozillaFirefox :
-

maintainer of mozilla:Factory/MozillaFirefox :
wrosenauer

Actually I'm not sure if I get notified since I cannot remember it
failing but I filter OBS mails away since I get too many.

I would propose that OBS needs to create a bug @ bugzilla for a failing
package in OBS and assign it to the maintainer and a certain other group
so they notice if the maintainer does not react.

I'm just not sure if we swamp bugzilla then by strange build issues
caused by broken workers but still bugzilla is _the_ system for that stuff.


Wolfgang
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Helping Coolo

Claudio Freire
On Thu, Oct 25, 2012 at 2:24 PM, Wolfgang Rosenauer
<[hidden email]> wrote:
> I would propose that OBS needs to create a bug @ bugzilla for a failing
> package in OBS and assign it to the maintainer and a certain other group
> so they notice if the maintainer does not react.

That would create thousands of bugs. I get regular notifications of
OBS-related failures, fixed trivially with a rebuild. Sometimes it's a
genuine problem in some dependency, fixed by fixing the offending lib.
In most cases, a bug @ bugzilla would be overkill.
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Helping Coolo

Joop Boonen-2
On 2012-10-25 19:33, Claudio Freire wrote:

> On Thu, Oct 25, 2012 at 2:24 PM, Wolfgang Rosenauer
> <[hidden email]> wrote:
>> I would propose that OBS needs to create a bug @ bugzilla for a
>> failing
>> package in OBS and assign it to the maintainer and a certain other
>> group
>> so they notice if the maintainer does not react.
>
> That would create thousands of bugs. I get regular notifications of
> OBS-related failures, fixed trivially with a rebuild. Sometimes it's
> a
> genuine problem in some dependency, fixed by fixing the offending
> lib.
> In most cases, a bug @ bugzilla would be overkill.

I prefer that OBS a bug report for a failed package, but only for
openSUSE:Factory, only once until it's fixed, not every time it fails
due to a rebuild.
If I look at the page Cristian sent
https://build.opensuse.org/project/status?project=openSUSE%3AFactory,
that would currently mean about 62 bug reports, if the kiwi build
failures aren't included.

Regards,

Joop.
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Helping Coolo

Stephan Kulow-3
Am 26.10.2012 09:21, schrieb Joop Boonen:

> On 2012-10-25 19:33, Claudio Freire wrote:
>> On Thu, Oct 25, 2012 at 2:24 PM, Wolfgang Rosenauer
>> <[hidden email]> wrote:
>>> I would propose that OBS needs to create a bug @ bugzilla for a failing
>>> package in OBS and assign it to the maintainer and a certain other group
>>> so they notice if the maintainer does not react.
>>
>> That would create thousands of bugs. I get regular notifications of
>> OBS-related failures, fixed trivially with a rebuild. Sometimes it's a
>> genuine problem in some dependency, fixed by fixing the offending lib.
>> In most cases, a bug @ bugzilla would be overkill.
>
> I prefer that OBS a bug report for a failed package, but only for
> openSUSE:Factory, only once until it's fixed, not every time it fails
> due to a rebuild.
> If I look at the page Cristian sent
> https://build.opensuse.org/project/status?project=openSUSE%3AFactory,
> that would currently mean about 62 bug reports, if the kiwi build
> failures aren't included.
>
I don't want them to be in bugzilla, so they can be easily auto closed.

Greetings, Stephan


--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Helping Coolo

Detlef Steuer-2
On Fri, 26 Oct 2012 09:52:28 +0200
Stephan Kulow <[hidden email]> wrote:

> > If I look at the page Cristian sent
> > https://build.opensuse.org/project/status?project=openSUSE%3AFactory,

From my point of view of a "simple" packager without deeper involvement
in openSUSE this list is near to ideal. I don't want any further
automatic mails.

May be coolo can send a notice maybe 14 (21?) days before the first
beta to the maintainers of those packages, that they won't be included
in next release if still in that state at release time of first beta
(or whatever seeems appropriate). Just drop those that are not important
from the next release.

If there are packages on this list important for the distribution there
is a more serious problem: a maintainer of critical infrastructure does
not care. No bugzilla and no other formalism will solve that.  

Detlef
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Helping Coolo

Joop Boonen-2
In reply to this post by Stephan Kulow-3
On 2012-10-26 09:52, Stephan Kulow wrote:

> Am 26.10.2012 09:21, schrieb Joop Boonen:
>> On 2012-10-25 19:33, Claudio Freire wrote:
>>> On Thu, Oct 25, 2012 at 2:24 PM, Wolfgang Rosenauer
>>> <[hidden email]> wrote:
>>>> I would propose that OBS needs to create a bug @ bugzilla for a
>>>> failing
>>>> package in OBS and assign it to the maintainer and a certain other
>>>> group
>>>> so they notice if the maintainer does not react.
>>>
>>> That would create thousands of bugs. I get regular notifications of
>>> OBS-related failures, fixed trivially with a rebuild. Sometimes
>>> it's a
>>> genuine problem in some dependency, fixed by fixing the offending
>>> lib.
>>> In most cases, a bug @ bugzilla would be overkill.
>>
>> I prefer that OBS a bug report for a failed package, but only for
>> openSUSE:Factory, only once until it's fixed, not every time it
>> fails
>> due to a rebuild.
>> If I look at the page Cristian sent
>>
>> https://build.opensuse.org/project/status?project=openSUSE%3AFactory,
>> that would currently mean about 62 bug reports, if the kiwi build
>> failures aren't included.
>>
> I don't want them to be in bugzilla, so they can be easily auto
> closed.
>
> Greetings, Stephan

Would it be an option to have a different sender ([hidden email] for
instance) for the "broken" factory packages, so it won't be overlooked
in the hermes mails.

I would like that the mails in general would be more tunable.
When your a member of a project you get mails for all failed packages.
When you have broken packages in your home project you'll also get
mails for them.

I would purpose that you can select which packages you want to monitor.
openSUSE:Factory packages that your the maintainer of are always
monitored.
Other non home projects can selected to be monitored, when your the
dedicated maintainer it's always monitored.
Home projects can selected to be monitored, if they are not monitored
they won't be rebuild automatically.

Regards,

Joop.

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Helping Coolo

Claudio Freire
On Fri, Oct 26, 2012 at 6:14 AM, Joop Boonen <[hidden email]> wrote:

>> I don't want them to be in bugzilla, so they can be easily auto closed.
>>
>> Greetings, Stephan
>
>
> Would it be an option to have a different sender ([hidden email] for
> instance) for the "broken" factory packages, so it won't be overlooked in
> the hermes mails.
>
> I would like that the mails in general would be more tunable.
> When your a member of a project you get mails for all failed packages.
> When you have broken packages in your home project you'll also get mails for
> them.
>
> I would purpose that you can select which packages you want to monitor.
> openSUSE:Factory packages that your the maintainer of are always monitored.
> Other non home projects can selected to be monitored, when your the
> dedicated maintainer it's always monitored.
> Home projects can selected to be monitored, if they are not monitored they
> won't be rebuild automatically.

Yes, and edge-triggered notifications.

If a package fails to build due to a broken dependency, I may choose
not to act immediately, to give the maintainer of that other package
time to react. In those cases, getting notified of a successful build
can be useful in those cases (to let me know all is ok again, no need
to go to obs and check). But if I enable successful build
notifications, I will also get hundreds of uninteresting
notifications, every time an automatic rebuild is triggered. This
makes success notifications useless.

A more effective hermes system would IMHO be better than automatic bug reports.

Also, I'm thinking, whether users' home page in OBS could have a
version of the status page, but limited to the user's packages. When I
want to check if my projects build, I have to go to the my projects
page and click on all the "Monitor" links, manually. It would be far
more efficient and attention-grabbing if there was a status page
there, with the information handy as in the case of Factory's status
page. The performance issue would be sidestepped by only including
packages (not projects) of which I have direct maintainership.
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Helping Coolo

Henne Vogelsang-2
Hey,

On 26.10.2012 14:12, Claudio Freire wrote:

> A more effective hermes system would IMHO be better than automatic bug reports.

It's open source, kind of unmaintained. Hermes seriously needs your
help. Get going :-)

http://en.opensuse.org/openSUSE:Hermes_hacking

Henne

--
Henne Vogelsang
http://www.opensuse.org
Everybody has a plan, until they get hit.
        - Mike Tyson
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Helping Coolo

Togan Muftuoglu-3
On 10/26/2012 03:42 PM, Henne Vogelsang wrote:
> Hey,
>
> On 26.10.2012 14:12, Claudio Freire wrote:
>
>> A more effective hermes system would IMHO be better than automatic bug reports.
>
> It's open source, kind of unmaintained. Hermes seriously needs your
> help. Get going :-)

Just curious if not maintained why aren't we looking for something else
that is maintained and fits to the needs.

Togan
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Helping Coolo

Claudio Freire
In reply to this post by Henne Vogelsang-2
On Fri, Oct 26, 2012 at 10:42 AM, Henne Vogelsang <[hidden email]> wrote:
>> A more effective hermes system would IMHO be better than automatic bug reports.
>
> It's open source, kind of unmaintained. Hermes seriously needs your
> help. Get going :-)
>
> http://en.opensuse.org/openSUSE:Hermes_hacking

I'll take a look, but perl's not my strong suit. It's not even my weak
suit. I even hate it.

But I'll take a look.
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Helping Coolo

Stephan Kulow-3
In reply to this post by Togan Muftuoglu-3
Am 26.10.2012 16:17, schrieb Togan Muftuoglu:

> On 10/26/2012 03:42 PM, Henne Vogelsang wrote:
>> Hey,
>>
>> On 26.10.2012 14:12, Claudio Freire wrote:
>>
>>> A more effective hermes system would IMHO be better than automatic bug reports.
>>
>> It's open source, kind of unmaintained. Hermes seriously needs your
>> help. Get going :-)
>
> Just curious if not maintained why aren't we looking for something else
> that is maintained and fits to the needs.
>
Like?

Greetings, Stephan


--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Helping Coolo

Togan Muftuoglu-3
On 10/26/2012 04:35 PM, Stephan Kulow wrote:

> Am 26.10.2012 16:17, schrieb Togan Muftuoglu:
>> On 10/26/2012 03:42 PM, Henne Vogelsang wrote:
>>> Hey,
>>>
>>> On 26.10.2012 14:12, Claudio Freire wrote:
>>>
>>>> A more effective hermes system would IMHO be better than automatic bug reports.
>>>
>>> It's open source, kind of unmaintained. Hermes seriously needs your
>>> help. Get going :-)
>>
>> Just curious if not maintained why aren't we looking for something else
>> that is maintained and fits to the needs.
>>
> Like?

Don't know if there is something that would do the job. I just had a
quick look to the page Henne posted it looks as if it was made to
measure for opensuse, which in that case logical for looking out new
tailors.

Togan





--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Helping Coolo

Philipp Thomas-3
In reply to this post by Cristian Morales Vega-3
On Thu, 25 Oct 2012 17:56:26 +0100, Cristian Morales Vega
<[hidden email]> wrote:

>Can someone clear this for me? Right now if a package fails to build
>in Factory I don't get notified just by this fact? But I will get
>notified once it fails in the devel project

AFAIK, you're only notified if you configured Hermes to do so, no
matter if it's factory or devel project.

Philipp
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

12