Bugtracker Status

Bugtracker Status

[Michael 'Mickey' Lauer]

Hi guys,

we have 1141 open bugs in the bugtracker, a couple of hundreds from ancient 
autobuilder builds, some more hundreds application specific bugs, and then 
some actual ones.

I think there are two ways to deal with the mess:

1.) Officially close the bugtracker down.

2.) Attack the situation.

I'm fine with either way, though if we'd go for 2.), I'd propose:

2.1.) Removing all autobuilder bugs completely (how can we script that?) and 
stop autobuilder automatically adding bugs. It was a great idea, but it 
didn't work out. We do not have enough manpower and it just messes up the 
bugtracker.
2.2.) Remove all software specific bugs that have an upstream and are not 
distribution-relevant, such as GPE, Opie, Kernel, etc.
2.3.) Reinstate the monthly bug squashing weekends.

Opinions?
-- 
:M:

Re: Bugtracker Status

[Otavio Salvador]

"Michael 'Mickey' Lauer" <mickey@vanille-media.de> writes:

> Hi guys,
>
> we have 1141 open bugs in the bugtracker, a couple of hundreds from ancient 
> autobuilder builds, some more hundreds application specific bugs, and then 
> some actual ones.
>
> I think there are two ways to deal with the mess:
>
> 1.) Officially close the bugtracker down.
>
> 2.) Attack the situation.
>
> I'm fine with either way, though if we'd go for 2.), I'd propose:
>
> 2.1.) Removing all autobuilder bugs completely (how can we script that?) and 
> stop autobuilder automatically adding bugs. It was a great idea, but it 
> didn't work out. We do not have enough manpower and it just messes up the 
> bugtracker.
> 2.2.) Remove all software specific bugs that have an upstream and are not 
> distribution-relevant, such as GPE, Opie, Kernel, etc.
> 2.3.) Reinstate the monthly bug squashing weekends.
>
> Opinions?

I propose to change the workflow a bit (and reuse few points you've proposed):

 1. stop using bugtracker to handle patches
 2. use mailing list to handle patches (comments bellow)
 3. drop autobuilder bug reporting (comments bellow)

Besides, I have no objection about your points 2.2 and 2.3 but I'm too
new in the OE environment to comment about them so let me comment
about my points:

 1 and 2:

 We're trying to get more people to review the changes to be done in
 OE dev tree and bugzilla UI is horrible and difficult to use (at
 least for me). Most people ends up redoing someone else patch since
 we don't watch carefully the bugtrack.

 I propose we move to mailing list reviewing process mostly like Linux
 kernel does. We can use PatchWork (http://ozlabs.org/~jk/projects/patchwork/)
 tool to make our life easier. I see some pros for that:

  . people will get more review into the patches
  . people will be aware of ongoing work and what is being prepared to
    be merged
  . less forgotten patches
  . less duplicated work

 I also see a single con for that:

  . more mailing list traffic

 3:

 Instead of reporting bugs, we could mail mailing list with the
 failure and link a log for someone to take a look. It makes us to
 worry more about the change since if we break something _everyone_
 we'll know it :-)

My 2c :P

-- 
        O T A V I O    S A L V A D O R
---------------------------------------------
 E-mail: otavio@debian.org      UIN: 5906116
 GNU/Linux User: 239058     GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
---------------------------------------------
"Microsoft sells you Windows ... Linux gives
 you the whole house."

Re: Bugtracker Status

[Philip Balister]

[-- Attachment #1: Type: text/plain, Size: 2843 bytes --]

Otavio Salvador wrote:
> "Michael 'Mickey' Lauer" <mickey@vanille-media.de> writes:
> 
>> Hi guys,
>>
>> we have 1141 open bugs in the bugtracker, a couple of hundreds from ancient 
>> autobuilder builds, some more hundreds application specific bugs, and then 
>> some actual ones.
>>
>> I think there are two ways to deal with the mess:
>>
>> 1.) Officially close the bugtracker down.
>>
>> 2.) Attack the situation.
>>
>> I'm fine with either way, though if we'd go for 2.), I'd propose:
>>
>> 2.1.) Removing all autobuilder bugs completely (how can we script that?) and 
>> stop autobuilder automatically adding bugs. It was a great idea, but it 
>> didn't work out. We do not have enough manpower and it just messes up the 
>> bugtracker.
>> 2.2.) Remove all software specific bugs that have an upstream and are not 
>> distribution-relevant, such as GPE, Opie, Kernel, etc.

Can we at least markbugs that are upstream issues in such a way that we 
can track when they are fixed upstream?

>> 2.3.) Reinstate the monthly bug squashing weekends.

Dedicated bug squashing periods are good!

>>
>> Opinions?
> 
> I propose to change the workflow a bit (and reuse few points you've proposed):
> 
>  1. stop using bugtracker to handle patches
>  2. use mailing list to handle patches (comments bellow)
>  3. drop autobuilder bug reporting (comments bellow)

Basically, I agree with Otavio.

What about a new list for patches and discussion? I don't know if this 
is a good idea though.

I think the tinderbox work may be a better way of tracking auto-builder 
issues.

Philip



> 
> Besides, I have no objection about your points 2.2 and 2.3 but I'm too
> new in the OE environment to comment about them so let me comment
> about my points:
> 
>  1 and 2:
> 
>  We're trying to get more people to review the changes to be done in
>  OE dev tree and bugzilla UI is horrible and difficult to use (at
>  least for me). Most people ends up redoing someone else patch since
>  we don't watch carefully the bugtrack.
> 
>  I propose we move to mailing list reviewing process mostly like Linux
>  kernel does. We can use PatchWork (http://ozlabs.org/~jk/projects/patchwork/)
>  tool to make our life easier. I see some pros for that:
> 
>   . people will get more review into the patches
>   . people will be aware of ongoing work and what is being prepared to
>     be merged
>   . less forgotten patches
>   . less duplicated work
> 
>  I also see a single con for that:
> 
>   . more mailing list traffic
> 
>  3:
> 
>  Instead of reporting bugs, we could mail mailing list with the
>  failure and link a log for someone to take a look. It makes us to
>  worry more about the change since if we break something _everyone_
>  we'll know it :-)
> 
> My 2c :P
> 

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3303 bytes --]

Re: Bugtracker Status

[Otavio Salvador]

Philip Balister <philip@balister.org> writes:

<...>
> What about a new list for patches and discussion? I don't know if this
> is a good idea though.

Personally I dislikes it ... it won't make "everyone" aware of what is
being done and if someone wants to play with OE he/she can live with a
high traffic mailing list. ;-)

-- 
        O T A V I O    S A L V A D O R
---------------------------------------------
 E-mail: otavio@debian.org      UIN: 5906116
 GNU/Linux User: 239058     GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
---------------------------------------------
"Microsoft sells you Windows ... Linux gives
 you the whole house."

Re: Bugtracker Status

[Otavio Salvador]

Philip Balister <philip@balister.org> writes:

>> "Michael 'Mickey' Lauer" <mickey@vanille-media.de> writes:
<...>
>>> 2.2.) Remove all software specific bugs that have an upstream and
>>> are not distribution-relevant, such as GPE, Opie, Kernel, etc.
>
> Can we at least markbugs that are upstream issues in such a way that
> we can track when they are fixed upstream?

I believe that the effort to track what is fixed upstream is too big
for low gain.

-- 
        O T A V I O    S A L V A D O R
---------------------------------------------
 E-mail: otavio@debian.org      UIN: 5906116
 GNU/Linux User: 239058     GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
---------------------------------------------
"Microsoft sells you Windows ... Linux gives
 you the whole house."

Re: Bugtracker Status

[Khem Raj]

On Thu, Jan 22, 2009 at 5:51 PM, Otavio Salvador <otavio@debian.org> wrote:
> Philip Balister <philip@balister.org> writes:
>
>>> "Michael 'Mickey' Lauer" <mickey@vanille-media.de> writes:
> <...>
>>>> 2.2.) Remove all software specific bugs that have an upstream and
>>>> are not distribution-relevant, such as GPE, Opie, Kernel, etc.
>>
>> Can we at least markbugs that are upstream issues in such a way that
>> we can track when they are fixed upstream?
>
> I believe that the effort to track what is fixed upstream is too big
> for low gain.
>
> --
>        O T A V I O    S A L V A D O R
> ---------------------------------------------
>  E-mail: otavio@debian.org      UIN: 5906116
>  GNU/Linux User: 239058     GPG ID: 49A5F855
>  Home Page: http://otavio.ossystems.com.br
> ---------------------------------------------
> "Microsoft sells you Windows ... Linux gives
>  you the whole house."
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

We could offloads some stuff (patches) to mailing lists and report
real problems in bugzilla which are not yet fixed and fix is not
available.

-Khem

Re: Bugtracker Status

[Koen Kooi]

On 23-01-09 01:55, Otavio Salvador wrote:

>
> I propose to change the workflow a bit (and reuse few points you've proposed):
>
>   1. stop using bugtracker to handle patches
>   2. use mailing list to handle patches (comments bellow)
>   3. drop autobuilder bug reporting (comments bellow)

I agree on all points, I have been advocating 2) for a long time :)

regards,

Koen

> Besides, I have no objection about your points 2.2 and 2.3 but I'm too
> new in the OE environment to comment about them so let me comment
> about my points:
>
>   1 and 2:
>
>   We're trying to get more people to review the changes to be done in
>   OE dev tree and bugzilla UI is horrible and difficult to use (at
>   least for me). Most people ends up redoing someone else patch since
>   we don't watch carefully the bugtrack.
>
>   I propose we move to mailing list reviewing process mostly like Linux
>   kernel does. We can use PatchWork (http://ozlabs.org/~jk/projects/patchwork/)
>   tool to make our life easier. I see some pros for that:
>
>    . people will get more review into the patches
>    . people will be aware of ongoing work and what is being prepared to
>      be merged
>    . less forgotten patches
>    . less duplicated work
>
>   I also see a single con for that:
>
>    . more mailing list traffic
>
>   3:
>
>   Instead of reporting bugs, we could mail mailing list with the
>   failure and link a log for someone to take a look. It makes us to
>   worry more about the change since if we break something _everyone_
>   we'll know it :-)
>
> My 2c :P
>

Re: Bugtracker Status

[Vitus Jensen]

Am Thu, 22 Jan 2009 22:55:17 -0200 schrieb Otavio Salvador:

> "Michael 'Mickey' Lauer" <mickey@vanille-media.de> writes:
> 
>> Hi guys,
>>
>> we have 1141 open bugs in the bugtracker, a couple of hundreds from
>> ancient autobuilder builds, some more hundreds application specific
>> bugs, and then some actual ones.
>>
>> I think there are two ways to deal with the mess:
>>
>> 1.) Officially close the bugtracker down.
>>
>> 2.) Attack the situation.
>>
>> I'm fine with either way, though if we'd go for 2.), I'd propose:
>>
>> 2.1.) Removing all autobuilder bugs completely (how can we script
>> that?) and stop autobuilder automatically adding bugs. It was a great
>> idea, but it didn't work out. We do not have enough manpower and it
>> just messes up the bugtracker.
>> 2.2.) Remove all software specific bugs that have an upstream and are
>> not distribution-relevant, such as GPE, Opie, Kernel, etc. 2.3.)
>> Reinstate the monthly bug squashing weekends.
>>
>> Opinions?
> 
> I propose to change the workflow a bit (and reuse few points you've
> proposed):
> 
>  1. stop using bugtracker to handle patches
>  2. use mailing list to handle patches (comments bellow)
>  3. drop autobuilder bug reporting (comments bellow)
...

While I just occasional work with OpenEmbedded I have to remark that I 
have two patches patches published which didn't make it into the 
repository the last months:

1. posted to this list (adds htmldoc)
2. in bugzilla (fixes php 5 compile)

I can live with that, just using my private branch.  But having gotten no 
comments what's wrong with those patches I think this shows that either 
way doesn't work at the moment.

And --- if you want my opinion --- it's much easier for me to monitor my 
comments in bugzilla or search patches there.

By[t]e,
   Vitus

-- 
Vitus Jensen, Hannover, Germany, Earth, Milky Way, Universe (current)

Re: Bugtracker Status

[Valentin Longchamp]

Otavio Salvador wrote:
> 
> I propose to change the workflow a bit (and reuse few points you've proposed):
> 
>  1. stop using bugtracker to handle patches
>  2. use mailing list to handle patches (comments bellow)
>  3. drop autobuilder bug reporting (comments bellow)
> 
> Besides, I have no objection about your points 2.2 and 2.3 but I'm too
> new in the OE environment to comment about them so let me comment
> about my points:
> 
>  1 and 2:
> 
>  We're trying to get more people to review the changes to be done in
>  OE dev tree and bugzilla UI is horrible and difficult to use (at
>  least for me). Most people ends up redoing someone else patch since
>  we don't watch carefully the bugtrack.
> 
>  I propose we move to mailing list reviewing process mostly like Linux
>  kernel does. We can use PatchWork (http://ozlabs.org/~jk/projects/patchwork/)
>  tool to make our life easier. I see some pros for that:
> 
>   . people will get more review into the patches
>   . people will be aware of ongoing work and what is being prepared to
>     be merged
>   . less forgotten patches
>   . less duplicated work
> 
>  I also see a single con for that:
> 
>   . more mailing list traffic
> 

Even if I am not very much involved in the OE development, I completely
agree with Otavio. The few patches that I have proposed are often stuck
on the bugzilla. Maybe it would be better with a mailing-list.

Furthermore, now that we use git, we have plenty of tools to send
patches to a mailing-list (format-patch, send-email and am).

I would definitely support a patch review style like on the linux kernel
mailing-lists even if this implies a high-traffic list (with simple
filter rules in your mail client, it's easy to handle). However, I don't
think it would be a good idea to have two lists.

My 2 c.

Val

-- 
Valentin Longchamp, PhD Student, EPFL-STI-LSRO1
valentin.longchamp@epfl.ch, Phone: +41216937827
http://people.epfl.ch/valentin.longchamp
MEA3485, Station 9, CH-1015 Lausanne

Mailinglists, was: Re: Bugtracker Status

[Koen Kooi]

On 23-01-09 11:30, Valentin Longchamp wrote:
> Otavio Salvador wrote:
>> I propose to change the workflow a bit (and reuse few points you've proposed):
>>
>>   1. stop using bugtracker to handle patches
>>   2. use mailing list to handle patches (comments bellow)
>>   3. drop autobuilder bug reporting (comments bellow)
>>
>> Besides, I have no objection about your points 2.2 and 2.3 but I'm too
>> new in the OE environment to comment about them so let me comment
>> about my points:
>>
>>   1 and 2:
>>
>>   We're trying to get more people to review the changes to be done in
>>   OE dev tree and bugzilla UI is horrible and difficult to use (at
>>   least for me). Most people ends up redoing someone else patch since
>>   we don't watch carefully the bugtrack.
>>
>>   I propose we move to mailing list reviewing process mostly like Linux
>>   kernel does. We can use PatchWork (http://ozlabs.org/~jk/projects/patchwork/)
>>   tool to make our life easier. I see some pros for that:
>>
>>    . people will get more review into the patches
>>    . people will be aware of ongoing work and what is being prepared to
>>      be merged
>>    . less forgotten patches
>>    . less duplicated work
>>
>>   I also see a single con for that:
>>
>>    . more mailing list traffic
>>
>
> Even if I am not very much involved in the OE development, I completely
> agree with Otavio. The few patches that I have proposed are often stuck
> on the bugzilla. Maybe it would be better with a mailing-list.
>
> Furthermore, now that we use git, we have plenty of tools to send
> patches to a mailing-list (format-patch, send-email and am).
>
> I would definitely support a patch review style like on the linux kernel
> mailing-lists even if this implies a high-traffic list (with simple
> filter rules in your mail client, it's easy to handle). However, I don't
> think it would be a good idea to have two lists.

I'd go even further by saying we should reorganize the mailinglists into 
this:

* oe mailinglist for humans
* combined commit + autobuild log list for non-humans

That should reduce confusion which list to use (oe-user, oe-devel, etc) 
for sending mails and more people get to see patches flying by. Even if 
you don't review them having more code snippets on the list is usefull 
for newcomers.

regards,

Koen

Re: Mailinglists, was: Re: Bugtracker Status

[Petr Stetiar]

Koen Kooi <k.kooi@student.utwente.nl> [2009-01-23 12:06:54]:

> On 23-01-09 11:30, Valentin Longchamp wrote:
> >I would definitely support a patch review style like on the linux kernel
> >mailing-lists even if this implies a high-traffic list (with simple
> >filter rules in your mail client, it's easy to handle). However, I don't
> >think it would be a good idea to have two lists.
> 
> I'd go even further by saying we should reorganize the mailinglists into 
> this:
> 
> * oe mailinglist for humans
> * combined commit + autobuild log list for non-humans
> 
> That should reduce confusion which list to use (oe-user, oe-devel, etc) 
> for sending mails and more people get to see patches flying by. Even if 
> you don't review them having more code snippets on the list is usefull 
> for newcomers.

That would be awesome.

-- ynezz

Re: Bugtracker Status

[Florian Boor]

HI,

Michael 'Mickey' Lauer schrieb:
> 2.1.) Removing all autobuilder bugs completely (how can we script that?) and 
> stop autobuilder automatically adding bugs. It was a great idea, but it 
> didn't work out. We do not have enough manpower and it just messes up the 
> bugtracker.

that would be a good idea. Most of these have never been relevant and unless we
have someone who volunteers tracking them down they only mess up the database.
It should be quite easy to get rid of them with a short shell+sql script. The
GPE 'product' and 'version' entries in the bugtracker database are created from
a script as well.

> 2.2.) Remove all software specific bugs that have an upstream and are not 
> distribution-relevant, such as GPE, Opie, Kernel, etc.

Yes, but we should make sure no patches and other important information gets lost.

> 2.3.) Reinstate the monthly bug squashing weekends.

Yes!

Greetings

Florian

-- 
The dream of yesterday                  Florian Boor
is the hope of today                    Tel: +49 271-771091-15
and the reality of tomorrow.            Fax: +49 271-771091-19
[Robert Hutchings Goddard, 1904]        florian.boor@kernelconcepts.de
                                        http://www.kernelconcepts.de/en

Re: Bugtracker Status

[Florian Boor]

Hi,

Koen Kooi schrieb:

>>   2. use mailing list to handle patches (comments bellow)
>>   3. drop autobuilder bug reporting (comments bellow)
> 
> I agree on all points, I have been advocating 2) for a long time :)

+1 from me

Greetings

Florian

-- 
The dream of yesterday                  Florian Boor
is the hope of today                    Tel: +49 271-771091-15
and the reality of tomorrow.            Fax: +49 271-771091-19
[Robert Hutchings Goddard, 1904]        florian.boor@kernelconcepts.de
                                        http://www.kernelconcepts.de/en

Re: Bugtracker Status

[Marcin Juszkiewicz]

[-- Attachment #1: Type: text/plain, Size: 434 bytes --]

On Friday 23 of January 2009 14:36:28 Florian Boor wrote:
> >>   2. use mailing list to handle patches (comments bellow)
> >>   3. drop autobuilder bug reporting (comments bellow)
> >
> > I agree on all points, I have been advocating 2) for a long time :)
>
> +1 from me

Also +1

Regards, 
-- 
JID:      hrw@jabber.org
Website:  http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 204 bytes --]

Re: Mailinglists, was: Re: Bugtracker Status

[Chris Larson]

On Fri, Jan 23, 2009 at 5:00 AM, Petr Stetiar <ynezz@true.cz> wrote:
> Koen Kooi <k.kooi@student.utwente.nl> [2009-01-23 12:06:54]:
>
>> On 23-01-09 11:30, Valentin Longchamp wrote:
>> >I would definitely support a patch review style like on the linux kernel
>> >mailing-lists even if this implies a high-traffic list (with simple
>> >filter rules in your mail client, it's easy to handle). However, I don't
>> >think it would be a good idea to have two lists.
>>
>> I'd go even further by saying we should reorganize the mailinglists into
>> this:
>>
>> * oe mailinglist for humans
>> * combined commit + autobuild log list for non-humans
>>
>> That should reduce confusion which list to use (oe-user, oe-devel, etc)
>> for sending mails and more people get to see patches flying by. Even if
>> you don't review them having more code snippets on the list is usefull
>> for newcomers.
>
> That would be awesome.

I don't know if you guys are aware, but the pybugz project has a
commandline tool that interfaces with bugzilla.  It actually works
really well from the little time I've spent with it so far.  It'd be
much, much nicer than the web interface for people's workflows, and
then we wouldn't lose the advantages of a bts.

See http://www.liquidx.net/pybugz/ - the example workflow section, specifically.
-- 
Chris Larson
clarson at kergoth dot com
clarson at mvista dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Software Engineer
MontaVista Software, Inc.

Re: Mailinglists, was: Re: Bugtracker Status

[Koen Kooi]

On 23-01-09 12:06, Koen Kooi wrote:
> On 23-01-09 11:30, Valentin Longchamp wrote:
>> Otavio Salvador wrote:
>>> I propose to change the workflow a bit (and reuse few points you've
>>> proposed):
>>>
>>> 1. stop using bugtracker to handle patches
>>> 2. use mailing list to handle patches (comments bellow)
>>> 3. drop autobuilder bug reporting (comments bellow)
>>>
>>> Besides, I have no objection about your points 2.2 and 2.3 but I'm too
>>> new in the OE environment to comment about them so let me comment
>>> about my points:
>>>
>>> 1 and 2:
>>>
>>> We're trying to get more people to review the changes to be done in
>>> OE dev tree and bugzilla UI is horrible and difficult to use (at
>>> least for me). Most people ends up redoing someone else patch since
>>> we don't watch carefully the bugtrack.
>>>
>>> I propose we move to mailing list reviewing process mostly like Linux
>>> kernel does. We can use PatchWork
>>> (http://ozlabs.org/~jk/projects/patchwork/)
>>> tool to make our life easier. I see some pros for that:
>>>
>>> . people will get more review into the patches
>>> . people will be aware of ongoing work and what is being prepared to
>>> be merged
>>> . less forgotten patches
>>> . less duplicated work
>>>
>>> I also see a single con for that:
>>>
>>> . more mailing list traffic
>>>
>>
>> Even if I am not very much involved in the OE development, I completely
>> agree with Otavio. The few patches that I have proposed are often stuck
>> on the bugzilla. Maybe it would be better with a mailing-list.
>>
>> Furthermore, now that we use git, we have plenty of tools to send
>> patches to a mailing-list (format-patch, send-email and am).
>>
>> I would definitely support a patch review style like on the linux kernel
>> mailing-lists even if this implies a high-traffic list (with simple
>> filter rules in your mail client, it's easy to handle). However, I don't
>> think it would be a good idea to have two lists.
>
> I'd go even further by saying we should reorganize the mailinglists into
> this:
>
> * oe mailinglist for humans
> * combined commit + autobuild log list for non-humans
>
> That should reduce confusion which list to use (oe-user, oe-devel, etc)
> for sending mails and more people get to see patches flying by. Even if
> you don't review them having more code snippets on the list is usefull
> for newcomers.

15:01 < _boto> i have posted into issue ml
15:02 < _boto> i wondered that the rest of mails were created by bugzilla

No objections, only support for my proposal, so can this get implemented 
now?

regards,

Koen

Re: Mailinglists, was: Re: Bugtracker Status

[Roman I Khimov]

[-- Attachment #1: Type: text/plain, Size: 871 bytes --]

Koen Kooi:
> >> Otavio Salvador wrote:
> >>> I propose to change the workflow a bit (and reuse few points you've
> >>> proposed):
> >>>
> >>> 1. stop using bugtracker to handle patches
> >>> 2. use mailing list to handle patches (comments bellow)
> >>> 3. drop autobuilder bug reporting (comments bellow)
> 15:01 < _boto> i have posted into issue ml
> 15:02 < _boto> i wondered that the rest of mails were created by bugzilla

Huh. Read the thread. And I've been wondering why there is exactly zero 
reaction to my bugz, which are numbers 5000, 5002, 5007 and 5012. ;)

So, what should I do now, re-post my patches for above bugs there, or maybe 
someone would review/comment/grab them from bugzilla?

-- 
                            Roman
 http://roman.khimov.ru
mailto: roman@khimov.ru
gpg --keyserver hkp://subkeys.pgp.net --recv-keys 0xE5E055C3

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 204 bytes --]

Re: Mailinglists, was: Re: Bugtracker Status

[Koen Kooi]

On 05-02-09 15:06, Koen Kooi wrote:
> On 23-01-09 12:06, Koen Kooi wrote:
>> On 23-01-09 11:30, Valentin Longchamp wrote:
>>> Otavio Salvador wrote:
>>>> I propose to change the workflow a bit (and reuse few points you've
>>>> proposed):
>>>>
>>>> 1. stop using bugtracker to handle patches
>>>> 2. use mailing list to handle patches (comments bellow)
>>>> 3. drop autobuilder bug reporting (comments bellow)
>>>>
>>>> Besides, I have no objection about your points 2.2 and 2.3 but I'm too
>>>> new in the OE environment to comment about them so let me comment
>>>> about my points:
>>>>
>>>> 1 and 2:
>>>>
>>>> We're trying to get more people to review the changes to be done in
>>>> OE dev tree and bugzilla UI is horrible and difficult to use (at
>>>> least for me). Most people ends up redoing someone else patch since
>>>> we don't watch carefully the bugtrack.
>>>>
>>>> I propose we move to mailing list reviewing process mostly like Linux
>>>> kernel does. We can use PatchWork
>>>> (http://ozlabs.org/~jk/projects/patchwork/)
>>>> tool to make our life easier. I see some pros for that:
>>>>
>>>> . people will get more review into the patches
>>>> . people will be aware of ongoing work and what is being prepared to
>>>> be merged
>>>> . less forgotten patches
>>>> . less duplicated work
>>>>
>>>> I also see a single con for that:
>>>>
>>>> . more mailing list traffic
>>>>
>>>
>>> Even if I am not very much involved in the OE development, I completely
>>> agree with Otavio. The few patches that I have proposed are often stuck
>>> on the bugzilla. Maybe it would be better with a mailing-list.
>>>
>>> Furthermore, now that we use git, we have plenty of tools to send
>>> patches to a mailing-list (format-patch, send-email and am).
>>>
>>> I would definitely support a patch review style like on the linux kernel
>>> mailing-lists even if this implies a high-traffic list (with simple
>>> filter rules in your mail client, it's easy to handle). However, I don't
>>> think it would be a good idea to have two lists.
>>
>> I'd go even further by saying we should reorganize the mailinglists into
>> this:
>>
>> * oe mailinglist for humans
>> * combined commit + autobuild log list for non-humans
>>
>> That should reduce confusion which list to use (oe-user, oe-devel, etc)
>> for sending mails and more people get to see patches flying by. Even if
>> you don't review them having more code snippets on the list is usefull
>> for newcomers.
>
> 15:01 < _boto> i have posted into issue ml
> 15:02 < _boto> i wondered that the rest of mails were created by bugzilla
>
> No objections, only support for my proposal, so can this get implemented
> now?

Still no objections and still no action. Can I shut down the unneeded 
lists myself now?

regards,

Koen

Re: Mailinglists, was: Re: Bugtracker Status

[Koen Kooi]

On 05-02-09 15:06, Koen Kooi wrote:
> On 23-01-09 12:06, Koen Kooi wrote:
>> On 23-01-09 11:30, Valentin Longchamp wrote:
>>> Otavio Salvador wrote:
>>>> I propose to change the workflow a bit (and reuse few points you've
>>>> proposed):
>>>>
>>>> 1. stop using bugtracker to handle patches
>>>> 2. use mailing list to handle patches (comments bellow)
>>>> 3. drop autobuilder bug reporting (comments bellow)
>>>>
>>>> Besides, I have no objection about your points 2.2 and 2.3 but I'm too
>>>> new in the OE environment to comment about them so let me comment
>>>> about my points:
>>>>
>>>> 1 and 2:
>>>>
>>>> We're trying to get more people to review the changes to be done in
>>>> OE dev tree and bugzilla UI is horrible and difficult to use (at
>>>> least for me). Most people ends up redoing someone else patch since
>>>> we don't watch carefully the bugtrack.
>>>>
>>>> I propose we move to mailing list reviewing process mostly like Linux
>>>> kernel does. We can use PatchWork
>>>> (http://ozlabs.org/~jk/projects/patchwork/)
>>>> tool to make our life easier. I see some pros for that:
>>>>
>>>> . people will get more review into the patches
>>>> . people will be aware of ongoing work and what is being prepared to
>>>> be merged
>>>> . less forgotten patches
>>>> . less duplicated work
>>>>
>>>> I also see a single con for that:
>>>>
>>>> . more mailing list traffic
>>>>
>>>
>>> Even if I am not very much involved in the OE development, I completely
>>> agree with Otavio. The few patches that I have proposed are often stuck
>>> on the bugzilla. Maybe it would be better with a mailing-list.
>>>
>>> Furthermore, now that we use git, we have plenty of tools to send
>>> patches to a mailing-list (format-patch, send-email and am).
>>>
>>> I would definitely support a patch review style like on the linux kernel
>>> mailing-lists even if this implies a high-traffic list (with simple
>>> filter rules in your mail client, it's easy to handle). However, I don't
>>> think it would be a good idea to have two lists.
>>
>> I'd go even further by saying we should reorganize the mailinglists into
>> this:
>>
>> * oe mailinglist for humans
>> * combined commit + autobuild log list for non-humans
>>
>> That should reduce confusion which list to use (oe-user, oe-devel, etc)
>> for sending mails and more people get to see patches flying by. Even if
>> you don't review them having more code snippets on the list is usefull
>> for newcomers.
>
> 15:01 < _boto> i have posted into issue ml
> 15:02 < _boto> i wondered that the rest of mails were created by bugzilla
>
> No objections, only support for my proposal, so can this get implemented
> now?

OK, Philip indicated he got confused by the proposals, so here's a rundown

current situation:

Openembedded-announce	
Openembedded-commits	
Openembedded-devel	
Openembedded-issues	
Openembedded-stablebranch
Openembedded-users
Openembedded-private

new situation:

openembedded-devel - for humans to post patches and ask questions
openembedded-bots - commits, bugs, logs, etc
Openembedded-private - core team

regards,

Koen

Re: Mailinglists, was: Re: Bugtracker Status

[Philip Balister]

[-- Attachment #1: Type: text/plain, Size: 606 bytes --]



Koen Kooi wrote:
> On 05-02-09 15:06, Koen Kooi wrote:
> 
> OK, Philip indicated he got confused by the proposals, so here's a rundown
> 
> current situation:
> 
> Openembedded-announce   
> Openembedded-commits   
> Openembedded-devel   
> Openembedded-issues   
> Openembedded-stablebranch
> Openembedded-users
> Openembedded-private
> 
> new situation:
> 
> openembedded-devel - for humans to post patches and ask questions
> openembedded-bots - commits, bugs, logs, etc
> Openembedded-private - core team

+1

Although I would keep the stable branch list for now.

Philip

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3303 bytes --]

Re: Mailinglists, was: Re: Bugtracker Status

[Sledz, Steffen]

> OK, Philip indicated he got confused by the proposals, so 
> here's a rundown
> 
> current situation:
> 
> Openembedded-announce	
> Openembedded-commits	
> Openembedded-devel	
> Openembedded-issues	
> Openembedded-stablebranch
> Openembedded-users
> Openembedded-private
> 
> new situation:
> 
> openembedded-devel - for humans to post patches and ask questions
> openembedded-bots - commits, bugs, logs, etc
> Openembedded-private - core team

+1

Re: Mailinglists, was: Re: Bugtracker Status

[Otavio Salvador]

Philip Balister <philip@balister.org> writes:

> Although I would keep the stable branch list for now.

Personally I think it should be at same development list since even
using the stable branch it is a development of a distribution using OE.

This also makes easier to spot bugs that needs fixing and/or backporting
of fixes.

-- 
        O T A V I O    S A L V A D O R
---------------------------------------------
 E-mail: otavio@debian.org      UIN: 5906116
 GNU/Linux User: 239058     GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
---------------------------------------------
"Microsoft sells you Windows ... Linux gives
 you the whole house."

Re: Mailinglists, was: Re: Bugtracker Status

[Bernhard Guillon]

Otavio Salvador wrote:
> Philip Balister <philip@balister.org> writes:
>
>   
>> Although I would keep the stable branch list for now.
>>     
>
> Personally I think it should be at same development list since even
> using the stable branch it is a development of a distribution using OE.
>
> This also makes easier to spot bugs that needs fixing and/or backporting
> of fixes.
>
>   
+1 the stable branch list had the problem of too few readers.

Re: Mailinglists, was: Re: Bugtracker Status

[Rodrigo Vivi]

On Wed, Feb 11, 2009 at 10:20 AM, Philip Balister <philip@balister.org> wrote:
>
>
> Koen Kooi wrote:
>>
>> On 05-02-09 15:06, Koen Kooi wrote:
>>
>> OK, Philip indicated he got confused by the proposals, so here's a rundown
>>
>> current situation:
>>
>> Openembedded-announce   Openembedded-commits   Openembedded-devel
>> Openembedded-issues   Openembedded-stablebranch
>> Openembedded-users
>> Openembedded-private
>>
>> new situation:
>>
>> openembedded-devel - for humans to post patches and ask questions
>> openembedded-bots - commits, bugs, logs, etc
>> Openembedded-private - core team

+1

>
> +1
>
> Although I would keep the stable branch list for now.
>
> Philip
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
>



-- 
Rodrigo Vivi
INdT - Instituto Nokia de Tecnologia
Blog: http://blog.vivi.eng.br
GPG: 0x905BE242 @ wwwkeys.pgp.net

Re: Bugtracker Status

[Rolf Leggewie]

Hi,

I have closed all autobuilder bugs in the tracker (and those against 
.stable after Mickey took the lead in bug 4243).

Feel free to open new tickets for compile-time bugs, better yet, use 
http://tinderbox.openembedded.net to communicate these kinds of problems.

Regards

Rolf

Re: Mailinglists, was: Re: Bugtracker Status

[Martyn Welch]

Sledz, Steffen wrote:
>> OK, Philip indicated he got confused by the proposals, so 
>> here's a rundown
>>
>> current situation:
>>
>> Openembedded-announce	
>> Openembedded-commits	
>> Openembedded-devel	
>> Openembedded-issues	
>> Openembedded-stablebranch
>> Openembedded-users
>> Openembedded-private
>>
>> new situation:
>>
>> openembedded-devel - for humans to post patches and ask questions
>> openembedded-bots - commits, bugs, logs, etc
>> Openembedded-private - core team
> 
> +1
> 

+1

I know this thread is a little old, but I notice that the Openembedded-users list still seems to be active. Has there been a change of heart, I this thread seems to contain nothing but approval? Also, I haven't seen anything about this on Openembedded-users, might it be worth asking the subscribers of that list how they feel about this?

Martyn

-- 
Martyn Welch MEng MPhil MIET (Principal Software Engineer)   T:+44(0)1327322748
GE Fanuc Intelligent Platforms Ltd,        |Registered in England and Wales
Tove Valley Business Park, Towcester,      |(3828642) at 100 Barbirolli Square,
Northants, NN12 6PF, UK T:+44(0)1327359444 |Manchester,M2 3AB  VAT:GB 729849476

Re: Mailinglists, was: Re: Bugtracker Status

[Michael 'Mickey' Lauer]

Am Dienstag, den 24.02.2009, 09:20 +0000 schrieb Martyn Welch:
> Sledz, Steffen wrote:
> >> OK, Philip indicated he got confused by the proposals, so 
> >> here's a rundown
> >>
> >> current situation:
> >>
> >> Openembedded-announce	
> >> Openembedded-commits	
> >> Openembedded-devel	
> >> Openembedded-issues	
> >> Openembedded-stablebranch
> >> Openembedded-users
> >> Openembedded-private
> >>
> >> new situation:
> >>
> >> openembedded-devel - for humans to post patches and ask questions
> >> openembedded-bots - commits, bugs, logs, etc
> >> Openembedded-private - core team

I'm ok with that in principle, but I'm not really fond of renaming
existing mailing lists. I'd rather keep openembedded-commits intact and
have the bugtracker send its reports there.

>the Openembedded-users list still seems to be active. Has there been a
>change of heart, I this thread seems to contain nothing but approval?

It looks like all people who cared to comment are in favour of the
changes. If you want me to do that, you have to wait until I have some
admin-time-slots free -- probably on weekend.

>Also, I haven't seen anything about this on Openembedded-users, might
>it be worth asking the subscribers of that list how they feel about
>this?

Sounds good, can do you that, please?

:M:

Re: Mailinglists, was: Re: Bugtracker Status

[Koen Kooi]

On 24-02-09 17:11, Michael 'Mickey' Lauer wrote:
> Am Dienstag, den 24.02.2009, 09:20 +0000 schrieb Martyn Welch:
>> Sledz, Steffen wrote:
>>>> OK, Philip indicated he got confused by the proposals, so
>>>> here's a rundown
>>>>
>>>> current situation:
>>>>
>>>> Openembedded-announce	
>>>> Openembedded-commits	
>>>> Openembedded-devel	
>>>> Openembedded-issues	
>>>> Openembedded-stablebranch
>>>> Openembedded-users
>>>> Openembedded-private
>>>>
>>>> new situation:
>>>>
>>>> openembedded-devel - for humans to post patches and ask questions
>>>> openembedded-bots - commits, bugs, logs, etc
>>>> Openembedded-private - core team
>
> I'm ok with that in principle, but I'm not really fond of renaming
> existing mailing lists. I'd rather keep openembedded-commits intact and
> have the bugtracker send its reports there.

I don't have a strong opionion on naming, let's take one step at a time 
and start 'merging' lists by closing a few and promote the remaining ones.

regards,

Koen

Re: Mailinglists, was: Re: Bugtracker Status

[Andrea Adami]

> I don't have a strong opionion on naming, let's take one step at a time and
> start 'merging' lists by closing a few and promote the remaining ones.
>
> regards,
>
> Koen

+1 for closing as above