Re: [oe-commits] org.oe.dev - Ignore false toggle signals (work-around for OE#3390).

Re: [oe-commits] org.oe.dev - Ignore false toggle signals (work-around for OE#3390).

[Paul Sokolovsky]

Hello,

On Wed, 20 Feb 2008 00:16:17 +0100
"utx commit" <openembedded-commits@lists.openembedded.org> wrote:

> - Ignore false toggle signals (work-around for OE#3390).
> - Fixed default ALSA state for SL-Cxx00 (OE#2617).
> - Do not alter incorrect mixer levels by zaurus-mixer-callback.
> - Allow to disable rotation by touch ~/.norot.
> - Fixed detection of panel_user.
> 
> Author: utx@openembedded.org

Stanislav, congratulations on getting commit access to OE! There're few
guidelines for developers at
http://www.openembedded.org/wiki/Policies . In particular, adhering to
http://www.openembedded.org/wiki/CommitPolicy allows for easy peer
review and per-package commit search.

[]

-- 
Best regards,
 Paul                          mailto:pmiscml@gmail.com

Re: [oe-commits] org.oe.dev - Ignore false toggle signals (work-around for OE#3390).

[Paul Sokolovsky]

Hello,

On Wed, 20 Feb 2008 01:58:17 +0200
Paul Sokolovsky <pmiscml@gmail.com> wrote:

> Hello,
> 
> On Wed, 20 Feb 2008 00:16:17 +0100
> "utx commit" <openembedded-commits@lists.openembedded.org> wrote:
> 
> > - Ignore false toggle signals (work-around for OE#3390).
> > - Fixed default ALSA state for SL-Cxx00 (OE#2617).
> > - Do not alter incorrect mixer levels by zaurus-mixer-callback.
> > - Allow to disable rotation by touch ~/.norot.
> > - Fixed detection of panel_user.
> > 
> > Author: utx@openembedded.org
> 
> Stanislav, congratulations on getting commit access to OE! There're
> few guidelines for developers at
> http://www.openembedded.org/wiki/Policies . In particular, adhering to
> http://www.openembedded.org/wiki/CommitPolicy allows for easy peer
> review and per-package commit search.

P.S.
More formal and detailed description of commit message format:
http://www.openembedded.org/wiki/MonotonePhraseBook , section 
"Committing". I happen to to not have login for that wiki, so cannot
consolidate that info, but someone should do that.

[]

-- 
Best regards,
 Paul                          mailto:pmiscml@gmail.com

Re: [oe-commits] org.oe.dev - Ignore false toggle signals (work-around for OE#3390).

[Stanislav Brabec]

Paul Sokolovsky wrote:

> > On Wed, 20 Feb 2008 00:16:17 +0100
> > "utx commit" <openembedded-commits@lists.openembedded.org> wrote:
> > 
> > > - Ignore false toggle signals (work-around for OE#3390).
> > > - Fixed default ALSA state for SL-Cxx00 (OE#2617).
> > > - Do not alter incorrect mixer levels by zaurus-mixer-callback.
> > > - Allow to disable rotation by touch ~/.norot.
> > > - Fixed detection of panel_user.
> > > 
> > > Author: utx@openembedded.org
> > 
> > Stanislav, congratulations on getting commit access to OE! There're
> > few guidelines for developers at
> > http://www.openembedded.org/wiki/Policies . In particular, adhering to
> > http://www.openembedded.org/wiki/CommitPolicy allows for easy peer
> > review and per-package commit search.

I seen bad formatting in http://monotone.openembedded.org/ and gathered
bad format of the message. Further messages will be correct (I hope).

My current fixes were done long time ago and ported several times, so I
no more had one patch per particular change. All future changes will
follow the rule "each change as separate changeset".

Note that the policy is missing "Closing bugs policy". Bug was reported
against Angstrom, now it is fixed in OE.dev. Should the bug be closed
now, or after backporting the fix to stable Angstrom?

-- 
Stanislav Brabec
http://www.penguin.cz/~utx/zaurus

Re: [oe-commits] org.oe.dev - Ignore false toggle signals (work-around for OE#3390).

[Paul Sokolovsky]

Hello,

On Wed, 20 Feb 2008 11:15:45 +0100
Stanislav Brabec <utx@penguin.cz> wrote:

> Paul Sokolovsky wrote:
> 
> > > On Wed, 20 Feb 2008 00:16:17 +0100
> > > "utx commit" <openembedded-commits@lists.openembedded.org> wrote:
> > > 
> > > > - Ignore false toggle signals (work-around for OE#3390).
> > > > - Fixed default ALSA state for SL-Cxx00 (OE#2617).
> > > > - Do not alter incorrect mixer levels by zaurus-mixer-callback.
> > > > - Allow to disable rotation by touch ~/.norot.
> > > > - Fixed detection of panel_user.
> > > > 
> > > > Author: utx@openembedded.org
> > > 
> > > Stanislav, congratulations on getting commit access to OE!
> > > There're few guidelines for developers at
> > > http://www.openembedded.org/wiki/Policies . In particular,
> > > adhering to http://www.openembedded.org/wiki/CommitPolicy allows
> > > for easy peer review and per-package commit search.
> 
> I seen bad formatting in http://monotone.openembedded.org/ and
> gathered bad format of the message. Further messages will be correct
> (I hope).
> 
> My current fixes were done long time ago and ported several times, so
> I no more had one patch per particular change. All future changes will
> follow the rule "each change as separate changeset".
> 
> Note that the policy is missing "Closing bugs policy". Bug was
> reported against Angstrom, now it is fixed in OE.dev. Should the bug
> be closed now, or after backporting the fix to stable Angstrom?

The idea of Angstrom Release bugs (rooted at
http://bugs.openembedded.org/show_bug.cgi?id=1573 ) is to provide list
of known issues to the end user. End user sees only release images and
feeds. So, if bug is fixed in source, but corresponding package hasn't
made to feeds, then per above idea (hopefully pretty obvious and
no-nonsense), the bug should not be closed.

It practice that means that developers should annotate the bug with
"pushed to .dev", "RFCed for merging to stable", "pushed to stable",
and ultimately, "package in feed, closing".

There're possibly other ways to make process more explicit, for
example, there're FIXED and CLOSED status in bugzilla, so it could be
FIXED when fix committed to main branch, and closed once fix is
confirmed to have solved the issue on user system. But CLOSED is not
used in existing OE bug process, and I'm in no authority to propose it
specifically for Angstrom - even the workflow above is pretty complex,
not really followed much and used to raise misunderstandings with other
bug maintainers.

> 
> -- 
> Stanislav Brabec
> http://www.penguin.cz/~utx/zaurus
> 



-- 
Best regards,
 Paul                          mailto:pmiscml@gmail.com

what is a fixed bug? (was: [oe-commits] org.oe.dev - Ignore false toggle signals (work-around for OE#3390).)

[Rolf Leggewie]

Paul Sokolovsky wrote:
> feeds. So, if bug is fixed in source, but corresponding package hasn't
> made to feeds, then per above idea (hopefully pretty obvious and
> no-nonsense), the bug should not be closed.

I disagree (see mail about Angstrom usurping bugs.oe.org).

I have yet to come up with a complete plan how things should work (one
idea fell apart because a partner had to retract their offer).  But
let's discuss this piece since it came up: when to consider a normal bug
closed.

The above are really two or more issues.

a) fix the problem itself
b) propagate the fix to A*
c) propagate the fix to PS Distro

IMO, any bug fixed in .dev ought to be closed.  If it needs to be
backported or released to A*, then a separate ticket should be opened
(one issue, one bug, remember!).  The cloning function from bugzilla can
easily be used for that.

We just face the problem that - unlike launchpad - bugzilla is incapable
of tracking the status according to project for the same issue (open for
ubuntu, closed in debian for example)

Re: what is a fixed bug? (was: [oe-commits] org.oe.dev - Ignore false toggle signals (work-around for OE#3390).)

[Paul Sokolovsky]

Hello,

On Wed, 20 Feb 2008 19:38:40 +0100
Rolf Leggewie <no2spam@nospam.arcornews.de> wrote:

> Paul Sokolovsky wrote:
> > feeds. So, if bug is fixed in source, but corresponding package
> > hasn't made to feeds, then per above idea (hopefully pretty obvious
> > and no-nonsense), the bug should not be closed.
> 
> I disagree (see mail about Angstrom usurping bugs.oe.org).
> 
> I have yet to come up with a complete plan how things should work (one
> idea fell apart because a partner had to retract their offer).  But
> let's discuss this piece since it came up: when to consider a normal
> bug closed.
> 
> The above are really two or more issues.
> 
> a) fix the problem itself
> b) propagate the fix to A*
> c) propagate the fix to PS Distro
> 
> IMO, any bug fixed in .dev ought to be closed.  If it needs to be
> backported or released to A*, then a separate ticket should be opened
> (one issue, one bug, remember!).  

When you'll find someone who will dup tickets in such way (with the
rest of associated management!), invite them to join this discussion,
until then, that's simply how it is, and let's not go thru that again.

> The cloning function from bugzilla
> can easily be used for that.
> 
> We just face the problem that - unlike launchpad - bugzilla is
> incapable of tracking the status according to project for the same
> issue (open for ubuntu, closed in debian for example)

[]


-- 
Best regards,
 Paul                          mailto:pmiscml@gmail.com

Re: what is a fixed bug?

[Rolf Leggewie]

Junqian Gordon Xu wrote:
> I prefer this approach to opening a separate dup ticket.

This will and has led to problems in that some A* dev has in the past
repeatedly closed valid bugs as invalid because his interpration was
"not an A* RC bug".  The bug of course was a perfectly valid one, if not
for A* (they are free to choose) it was for OE.

Furthermore, I don't see why my already long list of open bugs shall be
made any longer (I have a search function defined in bugzilla) without
merit.  Essentially, Angstrom is demanding that only they can close bugs
because how is anyone to know whether A* intends to push a fix into
stable?  This aggressive behaviour of Angstrom is essentially what I
mean by "usurpation of bugs.oe.net".  Why should the folks interested in
OE-derived SharpROM not be afforded that luxury of "don't you dare to
close bugs unless you have the OK from us"?

I am sorry, but I have to maintain that Distro bugs/tasks and OE
bugs/tasks are different animals and while our tools are not ideal to
reflect this, we need to properly represent that.  The only way I see to
do that is to have two tickets which is right, it is two issues.  The
chain is "fix it in dev" and then Angstrom or any other distro not made
from .dev can decide whether they want to propagate the fix.

Cloning a ticket and titling it with "push bug #123 into A* stable" is 5
seconds work at most, link back to original bug automatically included.
 Too much?

Paul wrote:
> that's simply how it is, and let's not go thru that again.

My impression was that we had already established that bugs.oe.net was
not Angstrom property.  Does not look like your interpretation.

I think A* should fully embrace the proposed clone-solution because
AFAICS it is the only proper one for them to have a list of tickets open
for  A* 2007 vs. A* 2008.  The solution serves their interest.

Re: what is a fixed bug?

[Paul Sokolovsky]

Hello,

On Thu, 21 Feb 2008 11:57:06 +0100
Rolf Leggewie <no2spam@nospam.arcornews.de> wrote:

> Junqian Gordon Xu wrote:
> > I prefer this approach to opening a separate dup ticket.
> 
> This will and has led to problems in that some A* dev has in the past
> repeatedly closed valid bugs as invalid because his interpration was
> "not an A* RC bug".  The bug of course was a perfectly valid one, if
> not for A* (they are free to choose) it was for OE.

That was at the time when there was no bug overlord for OE. Otherwise,
I'm personally pretty happy to just not include fishy bugs into
Angstrom Release set, as someone else has better plan of what to do
with those fishy bugs except closing.

> Furthermore, I don't see why my already long list of open bugs shall
> be made any longer (I have a search function defined in bugzilla)
> without merit.  

One good way to not make list of open bug longer than needed is to
close out invalid bugs. Criteria of invalidness varies though.

> Essentially, Angstrom is demanding that only they can
> close bugs because how is anyone to know whether A* intends to push a
> fix into stable?  

Communication, communication. Also, Angstrom is a one-word moniker for
"QAed and stable subset of OE", so it's not that bad as you trying it
to put.

> This aggressive behaviour of Angstrom is
> essentially what I mean by "usurpation of bugs.oe.net".  Why should
> the folks interested in OE-derived SharpROM not be afforded that
> luxury of "don't you dare to close bugs unless you have the OK from
> us"?

Folk interested in OE-derived SharpROM can dup bug as you proposed -
just to have it immediately closed out, in current cases, I guess ;-E.

> I am sorry, but I have to maintain that Distro bugs/tasks and OE
> bugs/tasks are different animals and while our tools are not ideal to
> reflect this, we need to properly represent that.  The only way I see
> to do that is to have two tickets which is right, it is two issues.
> The chain is "fix it in dev" and then Angstrom or any other distro
> not made from .dev can decide whether they want to propagate the fix.
> 
> Cloning a ticket and titling it with "push bug #123 into A* stable"
> is 5 seconds work at most, link back to original bug automatically
> included. Too much?

Yes. Why bother, if there's only one party of one person waves and
screams on that? What to talk about that right now, if bugs fixed even
in Angstrom branch are *not* closed out?

> 
> Paul wrote:
> > that's simply how it is, and let's not go thru that again.
> 
> My impression was that we had already established that bugs.oe.net was
> not Angstrom property.  Does not look like your interpretation.

Yes, but OE's tracker always included bugs for distributions. That was
for OpenZaurus, now that's the same for Angstrom. If you personally
don't get along with that distro, just take it easy.

> I think A* should fully embrace the proposed clone-solution because
> AFAICS it is the only proper one for them to have a list of tickets
> open for  A* 2007 vs. A* 2008.  The solution serves their interest.

I think it should to. So once that happen, it will be just like you
want, so keep arguing. Until then, there's just existing Release Bugs
procedure, for the lack of something better.

Ah, and there's Angstrom Coreteam, you can apply to it for it to be
changed - maybe it will set something by fiat (whereas the current
procedure is per "no objections" mode). Also, most of Angstrom Coreteam
members also OE Core developers, so hopefully, they can think of a
compromise. Or how do you like following scenario: you keep screaming
and spreading FUD, blackmailing them into making an "affirmative action
inversion" decision which would complicate life for the most common and
all-encompassing distro for the benefit of fringe fractions?

As for me, I'm personally not interested in politics and bureaucracy.
I'm interested in aims, one of which is to maintain "right here,
right now" list of Known Issue for the common distro, which is important
attribute of any mass-market product.

[]

-- 
Best regards,
 Paul                          mailto:pmiscml@gmail.com

Re: what is a fixed bug?

[Rolf Leggewie]

Paul,

let's make your long story short.

Essentially, the question amounts to whether I (and everybody else) need
to consult with A* people first before closing a bug that is fixed in
.dev from now on?  Once we have established that, we can either outright
forget about my proposal, accept it or try and find something better.

My interpretation:
* I believe we have already heard the result of that vote previously,
  but it seems you did not get the message, so I guess the question
  needs to be answered again.  RP?
* I already mentioned that IMHO A* should heartily embrace the changes I
  proposed because of the benefits it brings to them, but A* is free to
  reject my ideas.  But IMNSHO it cannot and should not force their
  rejection on others who use OE as a basis IMNSHO.

Regards

Rolf


PS: I'd also like you to finally stop your (unfounded) accusations
against my person.

Re: what is a fixed bug?

[Paul Sokolovsky]

Hello,

On Thu, 21 Feb 2008 13:40:35 +0100
Rolf Leggewie <no2spam@nospam.arcornews.de> wrote:

> Paul,
> 
> let's make your long story short.
> 
> Essentially, the question amounts to whether I (and everybody else)
> need to consult with A* people first before closing a bug that is
> fixed in .dev from now on?  Once we have established that, we can
> either outright forget about my proposal, accept it or try and find
> something better.

Rolf, my answers to your mails are in the following vien: 1) to
describe why it is now like it is; 2) to express my opinion why it
cannot change immediately to something else.

Otherwise, I'm all for the changes you propose - if they will work.
That depends not on you, not on me, and even not on coredevs, but on
each and every developer to follow it. As we now have situation that
bugs are not processed, and fixed bugs are not closed for long time, I
don't think that setting a process with more legwork to perform will
improve *real* situation any better.

As for consulting A* devs, each bug has list of other bug it blocks.
I'm trying to keep A* release bug hierarchy shallow and simple (hence
the tree'iness preference I expressed). Bugzilla also shows tooltip
when hovering an pausing cursor on a bug in Blocks/Depends on lists.
Summing up, it's pretty easy to see that a bug is included in
A*-stable release set, and thus takes special care to close. And
Angstrom is not just some niche thing, we all know about it, so taking
care that that fix went to stable user is in each of us best interests,
I would guess.

> 
> My interpretation:
> * I believe we have already heard the result of that vote previously,
>   but it seems you did not get the message, so I guess the question
>   needs to be answered again.  RP?
> * I already mentioned that IMHO A* should heartily embrace the
> changes I proposed because of the benefits it brings to them, but A*
> is free to reject my ideas.  But IMNSHO it cannot and should not
> force their rejection on others who use OE as a basis IMNSHO.
> 
> Regards
> 
> Rolf
> 
> 
> PS: I'd also like you to finally stop your (unfounded) accusations
> against my person.

Please take it easy, those are not accusations, and I apologize if they
sounded so to you, and I myself hope too that we'll keep to core
technical and organizational matters.


-- 
Best regards,
 Paul                          mailto:pmiscml@gmail.com

Re: what is a fixed bug?

[Rolf Leggewie]

Paul Sokolovsky wrote:
> it cannot change immediately to something else.
> 
> Otherwise, I'm all for the changes you propose 

Great.  Sorry I missed that drift.

I am certainly more than willing to try and understand the Angstrom
position and accomodate them where possible (I think that should have
been clear from my previous responses where I indicated the benefit I
see for A*).  Angstrom plays an important role for OE, no doubt about that.

> - if they will work.

I'd propose to try the process out.  I think you will even like it.
Maybe I was also misunderstood in that I think we need to have two bugs
for everything now, absolutely not.  My proposition is to just close
bugs when a fix has been pushed to .dev.  Angstrom should then keep a
watch on things and if necessary clone a bug that still needs fixing in
.stable (when for some reason the push cannot be done immediately).
Take look at bug 3838 which I created for illustration purposes of how I
think this should be done.

Regards

Rolf

Re: [oe-commits] org.oe.dev - Ignore false toggle signals (work-around for OE#3390).

[Junqian Gordon Xu]

On 02/20/2008 08:53 AM, Paul Sokolovsky wrote:
> It practice that means that developers should annotate the bug with
> "pushed to .dev", "RFCed for merging to stable", "pushed to stable",
> and ultimately, "package in feed, closing".

I prefer this approach to opening a separate dup ticket. If we can 
streamline the process of "RFCed for merging to stable" and "package in 
feed", we only need the "pushed to .dev" and/or "pushed to stable" as 
sufficient landmarks for closing a bug.

IMHO, whatever definition for closing a bug is not that much a big deal. 
Instead we should focus on how to streamline the process of getting 
fixes from .dev --->  feed.

Regards
Gordon