bp flag added to bug tracker (org.openembedded.stable)

bp flag added to bug tracker (org.openembedded.stable)

[Rolf Leggewie]

Hi,

it appears that org.openembedded.stable is not in addition to but a
replacement for org.oe.angstrom-2007.12-stable.  It also seems that the
policy so far of "two A* devs ACK any commit" has been thus replaced by
"two OE devs ACK any commit".  Correct so far?

I believe the BTS should help us out with flagging, granting and
documenting backport requests.  Which is why I have just added the bp
flag which can be applied to attachments in our BTS.  Anybody can
request the bp flag (which should trigger an email to oe-devel), but
only members of the OE group can grant it.  I am yet somewhat unfamiliar
with flags, but I guess we'll learn as we go.  My understanding is that
a grant can be given more than once.

IOW, very elegant solution that is tightly integrated with current
processes.

Regards

Rolf


PS: OE devs who are not yet a member of the OE group should please ping
mickey

Re: bp flag added to bug tracker (org.openembedded.stable)

[Rolf Leggewie]

Rolf Leggewie wrote:
> request the bp flag (which should trigger an email to oe-devel)

It appears the mail is not yet sent which is unfortunate but not a real
problem IMHO.  I'll look into making the mail trigger work correctly,
but I think we can start with this.

> IOW, very elegant solution that is tightly integrated with current
> processes.

A search for open bp request would look like this: http://tinyurl.com/5v993n

Re: bp flag added to bug tracker (org.openembedded.stable)

[Rolf Leggewie]

Rolf Leggewie wrote:
> Rolf Leggewie wrote:
>> request the bp flag (which should trigger an email to oe-devel)
> 
> It appears the mail is not yet sent which is unfortunate but not a real
> problem IMHO.  I'll look into making the mail trigger work correctly,
> but I think we can start with this.

looks like a problem on the receiving end.  I added my personal mail to
the bp queue CC list and am receiving the mails just fine.

Re: bp flag added to bug tracker (org.openembedded.stable)

[Koen Kooi]

Rolf Leggewie wrote:
> Hi,
>
> it appears that org.openembedded.stable is not in addition to but a
> replacement for org.oe.angstrom-2007.12-stable.  It also seems that the
> policy so far of "two A* devs ACK any commit" has been thus replaced by
> "two OE devs ACK any commit".  Correct so far?

"two stable branch developers" would be more like it.


>
> I believe the BTS should help us out with flagging, granting and
> documenting backport requests.  Which is why I have just added the bp
> flag which can be applied to attachments in our BTS.  Anybody can
> request the bp flag (which should trigger an email to oe-devel), but
> only members of the OE group can grant it.  I am yet somewhat unfamiliar
> with flags, but I guess we'll learn as we go.  My understanding is that
> a grant can be given more than once.
>
> IOW, very elegant solution that is tightly integrated with current
> processes.

Thanks for working on this.

regards,

Koen

Re: bp flag added to bug tracker (org.openembedded.stable)

[Graeme Gregory]

On Tue, May 06, 2008 at 07:43:34PM +0200, Koen Kooi wrote:
> Rolf Leggewie wrote:
>> Hi,
>>
>> it appears that org.openembedded.stable is not in addition to but a
>> replacement for org.oe.angstrom-2007.12-stable.  It also seems that the
>> policy so far of "two A* devs ACK any commit" has been thus replaced by
>> "two OE devs ACK any commit".  Correct so far?
>
> "two stable branch developers" would be more like it.
>
Yeah that makes sense, I'm an OE dev, but I never play with stable so
its pointless asking me to do backports.

Graeme

Re: bp flag added to bug tracker (org.openembedded.stable)

[Rolf Leggewie]

[resent as requested by list admin]

Koen Kooi wrote:
> "two stable branch developers" would be more like it.

Who defines that?

We already have an OE group in bugzilla and could use it if the
distinction was unnecessary.  Otherwise, it would certainly be easy to
add another group for this purpose once it is clear who should be a
member of that group.

Re: bp flag added to bug tracker (org.openembedded.stable)

[Koen Kooi]

Rolf Leggewie wrote:
> [resent as requested by list admin]
>
> Koen Kooi wrote:
>> "two stable branch developers" would be more like it.
>
> Who defines that?
>
> We already have an OE group in bugzilla and could use it if the
> distinction was unnecessary.  Otherwise, it would certainly be easy to
> add another group for this purpose once it is clear who should be a
> member of that group.

That isn't a problem right now, since a patch requires review and 
approval on the stable-branch *mailinglist*.

Re: bp flag added to bug tracker (org.openembedded.stable)

[Rolf Leggewie]

Hello Koen,

thank you for the answer.

Koen Kooi wrote:
> That isn't a problem right now, since a patch requires review and
> approval on the stable-branch *mailinglist*.

Well, I guess it was clear this whole thing is about the possibility of
circumventing that medium break and using the tools for what they are
meant to be.

Let me ask a blunt question: Is there really any activity on the stable
branch?  The mailing list (which I just found out about) seems rather
quiet to say the least.  And what I see in the bug tracker is mostly
just a bot dumping a lot of stuff that apparently nobody cares sh!t
about.  Bugs verified as WFM in .dev and claimed to exist in .stable are
completely ignored even after nagging oe-devel.

I don't see how the current setup helps.  I *do* see how having all that
in the bug tracker would help a lot.

Regards

Rolf

Re: bp flag added to bug tracker (org.openembedded.stable)

[Koen Kooi]

Rolf Leggewie wrote:
> Hello Koen,
>
> thank you for the answer.
>
> Koen Kooi wrote:
>> That isn't a problem right now, since a patch requires review and
>> approval on the stable-branch *mailinglist*.
>
> Well, I guess it was clear this whole thing is about the possibility of
> circumventing that medium

Sorry, that wasn't clear to me, it took me a while to realise that 'bp' 
means 'backport'. I thought you where cataloging bugs for Angstrom 
developers to review, which I think is very cool. The thing is that "OE 
stable branch patch process" is different from "Angstrom patch process", 
even if it involves largely the same people. Ideally angstrom developers 
review a patch and post a "ready to commit" one for review on the stable 
branch mailinglist.
If you don't use angstrom, or even no distro at all, you post your 
(hopefully "ready to commit") patch to the stablebranch mailinglist.
The main point is that your patch applies cleanly and has been tested 
before you post it (unless it's an RFC).

> Let me ask a blunt question: Is there really any activity on the stable
> branch?

There hasn't been much traffic on the mailinglist lately since I was on 
holiday and PaulS still is on holiday and Leon is swamped at work.
I am however currently cleaning up my patch queue to send them for 
review, but I need to test things on actual devices first, which takes 
time. I take "stable" seriously, sorry if that gets mistaken for sloth.

If you think you have patches that should get applied to the 
stablebranch, please post them for review on the stablebranch 
mailinglist. I can't speak for other developers, but I aim for a "same 
day review" timeframe.

Sorry if I caused confusion about this.

regards,

Koen

Re: bp flag added to bug tracker (org.openembedded.stable)

[Rolf Leggewie]

Koen Kooi wrote:
> Sorry, that wasn't clear to me, it took me a while to realise that 'bp'
> means 'backport'. 

My apologies if that got lost somewhere in between.  Yes, it stands for
backport (request).  I keep the flag names as short as possible because
otherwise the bugzilla UI soon becomes unbelievably ugly and bloated.

> There hasn't been much traffic on the mailinglist lately since I was on
> holiday and PaulS still is on holiday and Leon is swamped at work.

I appreciate that.  Thanks for the good work.

> If you think you have patches that should get applied to the
> stablebranch, please post them for review on the stablebranch
> mailinglist.

Would it be OK if I directed you to http://tinyurl.com/63674m instead?
Maybe you can save this search in your bugzilla account?  These are
patches tagged with the bp keyword request.  The Stable branch devs can
then ACK or NACK the patch right in the bug tracker.  Second person to
ACK makes the commit to .stable.  Isn't this the kind of review process
we are looking for?  Maybe you can over time move the complete review
process away from the mailing list and into bugzilla.  That would be my
suggestion.

I also did a bit of work on the autobuilder bugs which are fixed in .dev
but were filed against .stable in http://tinyurl.com/5th9yj  There are
no patches in there yet, but these should be easy to get with "mtn -r
$devheadrevision -r $stableheadrevision packages/$package", I assume
(haven't tried if mtn supports cross-branch diffs).

Re: bp flag added to bug tracker (org.openembedded.stable)

[Koen Kooi]

Rolf Leggewie wrote:
> Koen Kooi wrote:

>> If you think you have patches that should get applied to the
>> stablebranch, please post them for review on the stablebranch
>> mailinglist.
>
> Would it be OK if I directed you to http://tinyurl.com/63674m instead?
> Maybe you can save this search in your bugzilla account?  These are
> patches tagged with the bp keyword request.

Navigating bugzilla is sadly on the wrong side of my motivation (read: 
available time) threshold. Why? Because I spend a lot of time offline 
(no access to bugzilla) and I do have a local copy of the stablebranch 
mail folder. I'm sure I can configure bugzilla to mail me and all that, 
but I honestly have no time or inclination to look into that right now.

> The Stable branch devs can
> then ACK or NACK the patch right in the bug tracker.  Second person to
> ACK makes the commit to .stable.  Isn't this the kind of review process
> we are looking for?  Maybe you can over time move the complete review
> process away from the mailing list and into bugzilla.  That would be my
> suggestion.

Moving to bugzilla would be a good thing, but the policy right now works 
for the stable branch maintainers quite well and fits with out 
"lifestyle" (read: available time).

It's nothing against you or bugzilla, just people being (too) busy.

regards,

Koen

Re: bp flag added to bug tracker (org.openembedded.stable)

[Rolf Leggewie]

Koen Kooi wrote:
> mail folder. I'm sure I can configure bugzilla to mail me and all that,
> but I honestly have no time or inclination to look into that right now.

Done ;-)

For now, I added both oe-stablebranch and you to the list to cc whenever
the bp flag is requested.  Let me know if that doesn't work or you
receive mail twice (mail did not get through to oe-devel, because of a
filter, I assume)

Re: bp flag added to bug tracker (org.openembedded.stable)

[Rolf Leggewie]

Rolf Leggewie wrote:
> Koen Kooi wrote:
>> mail folder. I'm sure I can configure bugzilla to mail me and all that,
>> but I honestly have no time or inclination to look into that right now.
> 
> Done ;-)
> 
> For now, I added both oe-stablebranch and you to the list to cc whenever
> the bp flag is requested.

It doesn't look like the mails make it to the list.  Can you please
white-list bugzilla-daemon@amethyst.openembedded.net?

Koen, do you receive the notification mails?  We have quite a list of
backport request by now.  Most of them easily applicable.

http://bugs.openembedded.net/request.cgi?action=queue&requester=&product=&type=all&requestee=&component=&group=type

Re: bp flag added to bug tracker (org.openembedded.stable)

[Rolf Leggewie]

Rolf Leggewie wrote:
> Rolf Leggewie wrote:
>> Koen Kooi wrote:
>>> mail folder. I'm sure I can configure bugzilla to mail me and all that,
>>> but I honestly have no time or inclination to look into that right now.
>> Done ;-)
>>
>> For now, I added both oe-stablebranch and you to the list to cc whenever
>> the bp flag is requested.
> 
> It doesn't look like the mails make it to the list.  Can you please
> white-list bugzilla-daemon@amethyst.openembedded.net?
> 
> Koen, do you receive the notification mails?  We have quite a list of
> backport request by now.  Most of them easily applicable.
> 
> http://bugs.openembedded.net/request.cgi?action=queue&requester=&product=&type=all&requestee=&component=&group=type

Are "the stable guys" gonna let them rot in the BTS despite the efforts
I made to accomodate the requests you made?  If you are continuing to
ignore the patches (some of which I prepared just so you would not have
to inspect the changes between .stable and .dev yourselves), I might as
well close them all out as wontfix with a comment that .stable is
unsupported and the people "supporting" it don't care unless you jump
through whatever hoops-of-the-day they present you with.

So much for "same day review".

Last warning to take at least a little care about your .stable bugs and
patches in the tracker or have them all auto-closed.  If .stable chooses
to ignore the BTS we might as well make that transparent and inform the
poor fellows making the reports and hoping for support that they are out
of luck.

Re: bp flag added to bug tracker (org.openembedded.stable)

[Koen Kooi]

Rolf Leggewie wrote:
> Rolf Leggewie wrote:
>> Rolf Leggewie wrote:
>>> Koen Kooi wrote:
>>>> mail folder. I'm sure I can configure bugzilla to mail me and all that,
>>>> but I honestly have no time or inclination to look into that right now.
>>> Done ;-)
>>>
>>> For now, I added both oe-stablebranch and you to the list to cc whenever
>>> the bp flag is requested.
>> It doesn't look like the mails make it to the list.  Can you please
>> white-list bugzilla-daemon@amethyst.openembedded.net?
>>
>> Koen, do you receive the notification mails?  We have quite a list of
>> backport request by now.  Most of them easily applicable.
>>
>> http://bugs.openembedded.net/request.cgi?action=queue&requester=&product=&type=all&requestee=&component=&group=type
>
> Are "the stable guys" gonna let them rot in the BTS despite the efforts
>  I made to accomodate the requests you made?

Quoting myself upthread:

'Ideally angstrom developers review a patch and post a "ready to commit" 
one for review on the stable branch mailinglist.
If you don't use angstrom, or even no distro at all, you post your 
(hopefully "ready to commit") patch to the stablebranch mailinglist.
The main point is that your patch applies cleanly and has been tested 
before you post it (unless it's an RFC).'

> If you are continuing to
> ignore the patches (some of which I prepared just so you would not have
> to inspect the changes between .stable and .dev yourselves), I might as
> well close them all out as wontfix with a comment that .stable is
> unsupported and the people "supporting" it don't care unless you jump
> through whatever hoops-of-the-day they present you with.
>
> So much for "same day review".

Again quoting myself from upthread:

"If you think you have patches that should get applied to the 
stablebranch, please post them for review on the stablebranch 
mailinglist. I can't speak for other developers, but I aim for a "same 
day review" timeframe."

I have seen *one* patch being posted to the mailinglist with the 
[Review] flag, that was reviewed within 24 hours and committed soon 
thereafter. So the system works as defined.
So far the stable branch people have a defined system that has been 
extensively, publically RFC'ed and agreed upon that delivers on its 
promises.

Links to patches aren't patches. Bugzilla spam that might link to 
patches aren't patches. Talk about mails that haven't appeared isn't 
patches.

> Last warning to take at least a little care about your .stable bugs and
> patches in the tracker or have them all auto-closed.

Whatever, do as you like.

Re: bp flag added to bug tracker (org.openembedded.stable)

[Rolf Leggewie]

Koen Kooi wrote:
> Links to patches aren't patches. Bugzilla spam that might link to
> patches aren't patches.

I'd quote myself here about hoop-of-the-day

>> Last warning to take at least a little care about your .stable bugs and
>> patches in the tracker or have them all auto-closed.
> 
> Whatever, do as you like.

OK, I'll let the guys looking for help about .stable in the bug tracker
know that the .stable guys are not interested in the BTS and that they
should be pet-like in being prepared to jump through whatever hoops they
are presented with.

Re: bp flag added to bug tracker (org.openembedded.stable)

[Philip Balister]

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

Rolf Leggewie wrote:

> Let me ask a blunt question: Is there really any activity on the stable
> branch?  The mailing list (which I just found out about) seems rather
> quiet to say the least.  And what I see in the bug tracker is mostly
> just a bot dumping a lot of stuff that apparently nobody cares sh!t
> about.  Bugs verified as WFM in .dev and claimed to exist in .stable are
> completely ignored even after nagging oe-devel.

Rolf,

Can you remind me what the stable branch mailing list is? I suspect many 
devs are more interested in .dev than .stable and are not on the list.

I would guess that most users of .stable are more focused on their 
product work than keeping up with listservs.

Another case you should think of is that it is likely that .stable will 
start to have changes that do not make sense for .dev. Also with time 
.stable will be "replaced" with a new branch from .dev. (I use the 
quotes, because the original branch may have users for a long time).

Pplease remember we are all very busy and have a great deal of trouble 
keeping up with all of our responsibilities.

Philip



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

Re: bp flag added to bug tracker (org.openembedded.stable)

[Richard Purdie]

On Wed, 2008-05-07 at 09:37 -0400, Philip Balister wrote:
> Another case you should think of is that it is likely that .stable will 
> start to have changes that do not make sense for .dev. Also with time 
> .stable will be "replaced" with a new branch from .dev. (I use the 
> quotes, because the original branch may have users for a long time).

On this note, I would like to raise the question of whether a new
'stable' branch may make sense and make a better target to organise
effort around? I ask since we've had a round of fairly invasive changes
to .dev, hopefully for the better and syncing between this and the older
stable branch is going to get painful. I don't know what Angstrom is
planning for any new release?

I guess a useful question to ask at this point is "Whats brewing
for .dev in the next six months?"

From my perspective I see the following *possible* ideas which have the
potential for disruption:

* a new bitbake release and making this the minimum version for .dev
* make multimachine.bbclass the default
* make packaged-staging opt-out
* resolve some issues I've just noticed with pkgconfig[1]
* libtool experimentation[2]

[1] pkgconfig.bbclass and autotools.bbclass are now overlapping
functionality. We can probably drop pkgconfig.bbclass now or at least
split the staging bit into a separate class since autotools shouldn't
need it anymore. The functionality in autotools.bbclass should be
opt-out, not opt-in as it is at present IMO though.

[2] I've been meaning to mail about this for a while. Poky has upgraded
from 1.5.10 to 2.2.2 and then 2.2.4. This has to be one of the most
painful things I've ever done. On the plus side, we're down to two
libtool patches now. I did find two bugs in the 2.2.2 release but these
have been fixed upstream after I reported them. For .dev, I propose
adding Poky's recipes as DEFAULT_PREFERENCE = "-1" and then brave souls
can enable it and fix up their favourite targets or at least report the
issues. The fixes in Poky should provide a good start.

So all things considered, there isn't anything too disruptive in that
list IMO. I don't know if anyone else has any infrastructure changes
planned?

Cheers,

Richard

Re: bp flag added to bug tracker (org.openembedded.stable)

[Koen Kooi]

Richard Purdie wrote:
> On Wed, 2008-05-07 at 09:37 -0400, Philip Balister wrote:
>> Another case you should think of is that it is likely that .stable will
>> start to have changes that do not make sense for .dev. Also with time
>> .stable will be "replaced" with a new branch from .dev. (I use the
>> quotes, because the original branch may have users for a long time).
>
> On this note, I would like to raise the question of whether a new
> 'stable' branch may make sense and make a better target to organise
> effort around?

Since .stable is actually the second stable branch I can say from 
experience: "not really".

The current branch was started with the aim of being stable (sic) and 
supported for a defined period. From the announcement:

"The stable branch is not intended to keep up with the pace of
development on the development branch. Planned is to create new stable
branches every year; the next stable branch is scheduled to branch of
the development tree during 2008.12. Old stable branches will go in
unmaintained mode 3 months after a new stable branch is created; the
current stable will retire 2009.2."

Since there is at least one company basing products on it 
(http://linuxdevices.com/news/NS6292990557.html) we would be stupid to 
start a new one right now. If we go back on our promises like that, we 
can just stop pretending we care about stability and tell everyone to 
use .dev.

> I ask since we've had a round of fairly invasive changes
> to .dev, hopefully for the better and syncing between this and the older
> stable branch is going to get painful.

"The stable branch is not intended to keep up with the pace of
development on the development branch."

We saw the merge problems coming and that's why we have the review 
process, since applying diffs 1:1 isn't possible or even wanted.


> I don't know what Angstrom is planning for any new release?

"somewhere in 2008" is the current consensus. The quality of the 2008 
distro has improved a lot lately, thanks to some donations and 
consultant work (the user experience) and of course your 
packaged-staging work (The developer experience).

> I guess a useful question to ask at this point is "Whats brewing
> for .dev in the next six months?"
>
>> From my perspective I see the following *possible* ideas which have the
> potential for disruption:
>
> * a new bitbake release and making this the minimum version for .dev
> * make multimachine.bbclass the default
> * make packaged-staging opt-out
> * resolve some issues I've just noticed with pkgconfig[1]
> * libtool experimentation[2]
>
> [1] pkgconfig.bbclass and autotools.bbclass are now overlapping
> functionality. We can probably drop pkgconfig.bbclass now or at least
> split the staging bit into a separate class since autotools shouldn't
> need it anymore. The functionality in autotools.bbclass should be
> opt-out, not opt-in as it is at present IMO though.
>
> [2] I've been meaning to mail about this for a while. Poky has upgraded
> from 1.5.10 to 2.2.2 and then 2.2.4. This has to be one of the most
> painful things I've ever done. On the plus side, we're down to two
> libtool patches now. I did find two bugs in the 2.2.2 release but these
> have been fixed upstream after I reported them. For .dev, I propose
> adding Poky's recipes as DEFAULT_PREFERENCE = "-1" and then brave souls
> can enable it and fix up their favourite targets or at least report the
> issues. The fixes in Poky should provide a good start.
>
> So all things considered, there isn't anything too disruptive in that
> list IMO. I don't know if anyone else has any infrastructure changes
> planned?

For the stable branch "disruptive" is not really a good metric, "how 
well tested are the changes across the complete OE metadata" is a better 
one.

regards,

Koen

Re: bp flag added to bug tracker (org.openembedded.stable)

[Leon Woestenberg]

Koen, Richard,

On Wed, May 7, 2008 at 5:47 PM, Koen Kooi <k.kooi@student.utwente.nl> wrote:
> Richard Purdie wrote:
> > On this note, I would like to raise the question of whether a new
> > 'stable' branch may make sense and make a better target to organise
> > effort around?
> >
>
Maybe it's better to put effort in working towards a *planned* new
base point for the next stable branch-off.

Koen, thanks for re-establishing that branching off too often is not
good, I retract my 2008.6 question :-)

 > > I guess a useful question to ask at this point is "Whats brewing
> > for .dev in the next six months?"
> >
> > > From my perspective I see the following *possible* ideas which have the
> > >
Your perspective is widely recognized as broad and good :-)

> > potential for disruption:
> >
> > * a new bitbake release and making this the minimum version for .dev
> > * make multimachine.bbclass the default
> > * make packaged-staging opt-out
> > * resolve some issues I've just noticed with pkgconfig[1]
> > * libtool experimentation[2]
> >
> > [1] pkgconfig.bbclass and autotools.bbclass are now overlapping
> > functionality. We can probably drop pkgconfig.bbclass now or at least
> > split the staging bit into a separate class since autotools shouldn't
> > need it anymore. The functionality in autotools.bbclass should be
> > opt-out, not opt-in as it is at present IMO though.
> >
> > [2] I've been meaning to mail about this for a while. Poky has upgraded
> > from 1.5.10 to 2.2.2 and then 2.2.4. This has to be one of the most
> > painful things I've ever done. On the plus side, we're down to two
> > libtool patches now. I did find two bugs in the 2.2.2 release but these
> > have been fixed upstream after I reported them. For .dev, I propose
> > adding Poky's recipes as DEFAULT_PREFERENCE = "-1" and then brave souls
> > can enable it and fix up their favourite targets or at least report the
> > issues. The fixes in Poky should provide a good start.
> >
> > So all things considered, there isn't anything too disruptive in that
> > list IMO. I don't know if anyone else has any infrastructure changes
> > planned?
> >
>
>  For the stable branch "disruptive" is not really a good metric, "how well
> tested are the changes across the complete OE metadata" is a better one.
>
What if we plan to have the disruptive changes breed and sit in .dev
first until the devs are fine with them, plan towards a branch-off (a
few weeks of keeping infrastructure changes in our .dev metadata,
package recipe work is always fine of course) and branch off then?

Regards,
-- 
Leon

Re: bp flag added to bug tracker (org.openembedded.stable)

[Rolf Leggewie]

Philip,

thank you for your mail.

> Can you remind me what the stable branch mailing list is? 

You should really ask koen ;-)  I didn't know about it until this
morning either and had to google for it.  Since I already did:

http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-stablebranch

> I would guess that most users of .stable are more focused on their
> product work than keeping up with listservs.
[...]
> Pplease remember we are all very busy and have a great deal of trouble
> keeping up with all of our responsibilities.

I'm 100% with you there.  Which is exactly why IMHO it makes so much
sense to move away the review process from mailing lists into something
we *all* already use and where we can collaborate better.  A bug tracker
is just so much more appropriate than a mailing list to manage the workflow.

But, I guess that is neither up to you or me to decide, since we are
both mostly by-standers.

Regards

Rolf

Re: bp flag added to bug tracker (org.openembedded.stable)

[Leon Woestenberg]

Hello all,

On Wed, May 7, 2008 at 4:39 PM, Rolf Leggewie
<no2spam@nospam.arcornews.de> wrote:
>  > Can you remind me what the stable branch mailing list is?
>
>  You should really ask koen ;-)  I didn't know about it until this
>  morning either and had to google for it.  Since I already did:
>
1) Stuff had been discussed on multiple mailing lists (oe/angstrom).
2) There is that news item trying to be seen on www.openembedded.org.

Summary: stable is mostly for having a set of metadata that works
within a set of parameters, and the ability to fix any outstanding
bugs in there. Mostly useful for basing off product development (third
parties to us). Also, third parties and newbies can be pointed to
stable.

> > Pplease remember we are all very busy and have a great deal of trouble
>  > keeping up with all of our responsibilities.
>
>  I'm 100% with you there.  Which is exactly why IMHO it makes so much
>  sense to move away the review process from mailing lists into something
>  we *all* already use and where we can collaborate better.  A bug tracker
>  is just so much more appropriate than a mailing list to manage the workflow.
>
Intention is that we should really prevent (heavy) breakage on the
stable branch and reviews are necessary to have more eyes on commits.

Yes, we could do this in the bugtracker. I'm OK with that but we need
to define a proper workflow.

>  But, I guess that is neither up to you or me to decide, since we are
>  both mostly by-standers.
>
Frankly me too, as at this moment I'm not using stable, simply because
I did not base new products off 'stable' yet. So my personal interest
is not so much in the current stable tree, but in the process of
getting the next stable tree base point. (I have to spend my limited
time wisely, like everybody else, and that means putting some effort
in a future stable tree instead of the current, for me.)

Despite everyone's limited time, I think OE is gaining momentum again
on getting our workflow and new ideas going, and I would like to thank
everyone on OpenEmbedded for that.

In response to Richard:

When we have a stabilized .dev tree, we could branch off a stable
tree, but not to often please.

The plan was for 2008.12 but responding to RP: maybe we should
consider a 2008.6 base?

Regards,

Leon.

Re: bp flag added to bug tracker (org.openembedded.stable)

[Rolf Leggewie]

Leon Woestenberg wrote:
>>  You should really ask koen ;-)  I didn't know about it until this
>>  morning either and had to google for it.  Since I already did:
>>
> 1) Stuff had been discussed on multiple mailing lists (oe/angstrom).

I'm absolutely aware of the .stable branch, the existence of it has been
clearly communicated.  I was not quite so clear until yesterday as to
how it related to the previous stable branch maintained by A*.  I heard
about the stablebranch ml and that it is the place to discuss backports
first time in koen's mail today around noon.  The ml is what Philip
asked about and what I was referring to above.

Re: bp flag added to bug tracker (org.openembedded.stable)

[Leon Woestenberg]

Hello Rolf,

On Wed, May 7, 2008 at 7:23 PM, Rolf Leggewie
<no2spam@nospam.arcornews.de> wrote:
> Leon Woestenberg wrote:
>  >>  You should really ask koen ;-)  I didn't know about it until this
>  >>  morning either and had to google for it.  Since I already did:
>  >>
>  > 1) Stuff had been discussed on multiple mailing lists (oe/angstrom).
>
>  I'm absolutely aware of the .stable branch, the existence of it has been
>  clearly communicated.  I was not quite so clear until yesterday as to
>  how it related to the previous stable branch maintained by A*.  I heard
>
Sorry for my misunderstanding.

Regards,
-- 
Leon

Re: bp flag added to bug tracker (org.openembedded.stable)

[Koen Kooi]

Rolf Leggewie wrote:
> Leon Woestenberg wrote:
>>>   You should really ask koen ;-)  I didn't know about it until this
>>>   morning either and had to google for it.  Since I already did:
>>>
>> 1) Stuff had been discussed on multiple mailing lists (oe/angstrom).
>
> I'm absolutely aware of the .stable branch, the existence of it has been
> clearly communicated.  I was not quite so clear until yesterday as to
> how it related to the previous stable branch maintained by A*.  I heard
> about the stablebranch ml and that it is the place to discuss backports
> first time in koen's mail today around noon.  The ml is what Philip
> asked about and what I was referring to above.

As has been mentioned, the top news item on http://wwww.openembedded.org 
has a link to the mailinglist. It doesn't mention the review criteria, 
though.

Re: bp flag added to bug tracker (org.openembedded.stable)

[Florian Boor]

Hi,

Philip Balister wrote:
> I would guess that most users of .stable are more focused on their
> product work than keeping up with listservs.

I suppose this is the key problem with .stable. Its quite likely that people
will take it, modify it to fit their needs and do not send patches because it
takes too much of their precious time.

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

1D78 2D4D 6C53 1CA4 5588  D07B A8E7 940C 25B7 9A76

Re: bp flag added to bug tracker (org.openembedded.stable)

[Leon Woestenberg]

Hello,

On Sun, May 11, 2008 at 1:18 AM, Florian Boor
<florian.boor@kernelconcepts.de> wrote:

>  > I would guess that most users of .stable are more focused on their
>  > product work than keeping up with listservs.
>
>  I suppose this is the key problem with .stable. Its quite likely that people
>  will take it, modify it to fit their needs and do not send patches because it
>  takes too much of their precious time.
>
I think the model that works is as follows:

- there are some dev's using (1) and maintaining (2) a stable branch.
A subset of the people reporting the bugs should be able to fix them.
- there are additional users doing the same.

Note that there is a chicken and egg (or catch22) situation, as I
based my work of .dev currently, not having any other choices.

Regards,

Leon.

-- 
Leon

Re: bp flag added to bug tracker (org.openembedded.stable)

[Rolf Leggewie]

Florian Boor wrote:
>> I would guess that most users of .stable are more focused on their
>> product work than keeping up with listservs.
> 
> I suppose this is the key problem with .stable. Its quite likely that people
> will take it, modify it to fit their needs and do not send patches because it
> takes too much of their precious time.

Not sure if this is the key problem.  But having your patches ignored
unless you jump through the hoop-of-the-day (which in this case is a
listserv) is also unlikely to increase your motivation next time around.
 At least that is my uneducated and inflammatory guess.