Getting patches committed

Getting patches committed

[Paul Menzel]

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

Dear OE developers,


during the last week (or two) I have the feeling that a lot of patches
are send to the list by developers with no commit access and they are
not reviewed, commented or committed.

I am well aware that you all have better or more important things to do.
But the problem is you are the only one who can commit this stuff.

There is also Patchwork, where you can see what patches are sitting on
the list.

So now my question is, is there a temporary reason for this lack of time
by developers or is that a fundamental problem so a solution is needed?

1. It looks like nobody of the developers is using Patchwork yet. It
looks like everybody can register an account and update the statuses. Is
there a demand for it? Maybe we can find some non-developers (including
me) volunteering to do this?

2. Is there a way to have a staging branch where all patches are
committed to, which have not been reviewed for let us say one week, to
get more testing and before they go into the dev branch? Maybe it is
easier for people to at least test build such a branch?

Sorry if I made wrong assumptions and there is no problem at all.


Thanks,

Paul


[1] http://patchwork.openembedded.org/project/openembedded/list/

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: Getting patches committed

[Holger Hans Peter Freyther]

On Thursday 21 January 2010 10:43:44 Paul Menzel wrote:

> 
> So now my question is, is there a temporary reason for this lack of time
> by developers or is that a fundamental problem so a solution is needed?

I don't think this is temporary.

> 
> 1. It looks like nobody of the developers is using Patchwork yet. It
> looks like everybody can register an account and update the statuses. Is
> there a demand for it? Maybe we can find some non-developers (including
> me) volunteering to do this?

I could need a hand keeping it updated. E.g. I was busy the last weeks and 
couldn't remove items from the page and now we are up to three pages of data.


> 
> 2. Is there a way to have a staging branch where all patches are
> committed to, which have not been reviewed for let us say one week, to
> get more testing and before they go into the dev branch? Maybe it is
> easier for people to at least test build such a branch?

Would you be interested in creating such a branch for us? I assume it is 
certainly easier to git cherry-pick a patch than to download the mbox and use 
git am..

Re: Getting patches committed

[Dr. Michael Lauer]

Am 21.01.2010 um 11:02 schrieb Holger Hans Peter Freyther:

>> 
>> 2. Is there a way to have a staging branch where all patches are
>> committed to, which have not been reviewed for let us say one week, to
>> get more testing and before they go into the dev branch? Maybe it is
>> easier for people to at least test build such a branch?
> 
> Would you be interested in creating such a branch for us? I assume it is 
> certainly easier to git cherry-pick a patch than to download the mbox and use 
> git am..

I fully agree. I'm neither using patchwork nor do I find patches on the list a good idea.
I'd welcome for-oe-upstream trees that would contain patches that -- if good -- we could
just pull from.

:M:

Re: Getting patches committed

[Holger Hans Peter Freyther]

On Thursday 21 January 2010 11:20:13 Dr. Michael Lauer wrote:
> Am 21.01.2010 um 11:02 schrieb Holger Hans Peter Freyther:
> >> 2. Is there a way to have a staging branch where all patches are
> >> committed to, which have not been reviewed for let us say one week, to
> >> get more testing and before they go into the dev branch? Maybe it is
> >> easier for people to at least test build such a branch?
> >
> > Would you be interested in creating such a branch for us? I assume it is
> > certainly easier to git cherry-pick a patch than to download the mbox and
> > use git am..
> 
> I fully agree. I'm neither using patchwork nor do I find patches on the
>  list a good idea. I'd welcome for-oe-upstream trees that would contain
>  patches that -- if good -- we could just pull from.

I do like patches on the mailinglist. One thing we could try are the merge 
requests on gitorious? This way we can comment on the patches in a webui and 
they get automatically merged if we like it.

z.

Re: Getting patches committed

[Philip Balister]

On 01/21/2010 05:20 AM, Dr. Michael Lauer wrote:
> Am 21.01.2010 um 11:02 schrieb Holger Hans Peter Freyther:
>
>>>
>>> 2. Is there a way to have a staging branch where all patches are
>>> committed to, which have not been reviewed for let us say one week, to
>>> get more testing and before they go into the dev branch? Maybe it is
>>> easier for people to at least test build such a branch?
>>
>> Would you be interested in creating such a branch for us? I assume it is
>> certainly easier to git cherry-pick a patch than to download the mbox and use
>> git am..
>
> I fully agree. I'm neither using patchwork nor do I find patches on the list a good idea.
> I'd welcome for-oe-upstream trees that would contain patches that -- if good -- we could
> just pull from.

I actually like patches on the list, because it makes me aware of how is 
doing work and keeps me aware of the kinds of things people without 
commit access are interested in. Also, it gives people with commit 
access a forum for changes they would like reviewed.

I am not opposed to someone creating a git branch or branches created 
from list patches, but do not want to see the patches disappear from the 
list.

If the patch that was sent to the list comes from git-send-patch (I hope 
I hve that correct) there is a script contrib/patchwork/git-am.sh that 
makes it really easy to apply the patch.

Philip

Re: Getting patches committed

[Thomas Zimmermann]

Am Donnerstag 21 Januar 2010 13:15:21 schrieb Philip Balister:
> On 01/21/2010 05:20 AM, Dr. Michael Lauer wrote:
> > Am 21.01.2010 um 11:02 schrieb Holger Hans Peter Freyther:
> >>> 2. Is there a way to have a staging branch where all patches are
> >>> committed to, which have not been reviewed for let us say one week, to
> >>> get more testing and before they go into the dev branch? Maybe it is
> >>> easier for people to at least test build such a branch?
> >>
> >> Would you be interested in creating such a branch for us? I assume it is
> >> certainly easier to git cherry-pick a patch than to download the mbox
> >> and use git am..
> >
> > I fully agree. I'm neither using patchwork nor do I find patches on the
> > list a good idea. I'd welcome for-oe-upstream trees that would contain
> > patches that -- if good -- we could just pull from.
> 
> I actually like patches on the list, because it makes me aware of how is
> doing work and keeps me aware of the kinds of things people without
> commit access are interested in. Also, it gives people with commit
> access a forum for changes they would like reviewed.
> 
> I am not opposed to someone creating a git branch or branches created
> from list patches, but do not want to see the patches disappear from the
> list.
> 
> If the patch that was sent to the list comes from git-send-patch (I hope
> I hve that correct) there is a script contrib/patchwork/git-am.sh that
> makes it really easy to apply the patch.
> 
> Philip

I'm one of those without commit rights :)
And i think the problem is, that nobody feels responsible for the patches on 
patchwork. I know this situation from SHR patchwork, when you don't ask 
someone directly to commit a patch from patchwork, nobody will do it.
That's the only way it really works currently.
I have 4 people with commit rights i can ask, so i have no problems but others 
probably doesn't know someone...

I think a sort of moderator for patchwork is needed, that assosiats patches to 
the maintainer.

Thomas

Re: Getting patches committed

[Philip Balister]

On 01/21/2010 07:36 AM, Thomas Zimmermann wrote:
> Am Donnerstag 21 Januar 2010 13:15:21 schrieb Philip Balister:
>> On 01/21/2010 05:20 AM, Dr. Michael Lauer wrote:
>>> Am 21.01.2010 um 11:02 schrieb Holger Hans Peter Freyther:
>>>>> 2. Is there a way to have a staging branch where all patches are
>>>>> committed to, which have not been reviewed for let us say one week, to
>>>>> get more testing and before they go into the dev branch? Maybe it is
>>>>> easier for people to at least test build such a branch?
>>>>
>>>> Would you be interested in creating such a branch for us? I assume it is
>>>> certainly easier to git cherry-pick a patch than to download the mbox
>>>> and use git am..
>>>
>>> I fully agree. I'm neither using patchwork nor do I find patches on the
>>> list a good idea. I'd welcome for-oe-upstream trees that would contain
>>> patches that -- if good -- we could just pull from.
>>
>> I actually like patches on the list, because it makes me aware of how is
>> doing work and keeps me aware of the kinds of things people without
>> commit access are interested in. Also, it gives people with commit
>> access a forum for changes they would like reviewed.
>>
>> I am not opposed to someone creating a git branch or branches created
>> from list patches, but do not want to see the patches disappear from the
>> list.
>>
>> If the patch that was sent to the list comes from git-send-patch (I hope
>> I hve that correct) there is a script contrib/patchwork/git-am.sh that
>> makes it really easy to apply the patch.
>>
>> Philip
>
> I'm one of those without commit rights :)
> And i think the problem is, that nobody feels responsible for the patches on
> patchwork. I know this situation from SHR patchwork, when you don't ask
> someone directly to commit a patch from patchwork, nobody will do it.
> That's the only way it really works currently.
> I have 4 people with commit rights i can ask, so i have no problems but others
> probably doesn't know someone...
>
> I think a sort of moderator for patchwork is needed, that assosiats patches to
> the maintainer.

There is nothing wrong with nagging people on the list and on irc to 
commit your patch :) Sometimes I will commit stuff just because the 
author takes a little time to explain the patch to me.

Philip

Re: Getting patches committed

[Paul Menzel]

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

Am Donnerstag, den 21.01.2010, 07:45 -0500 schrieb Philip Balister:
> On 01/21/2010 07:36 AM, Thomas Zimmermann wrote:

[…]

> > I think a sort of moderator for patchwork is needed, that assosiats patches to
> > the maintainer.
> 
> There is nothing wrong with nagging people on the list and on irc to 
> commit your patch :) Sometimes I will commit stuff just because the 
> author takes a little time to explain the patch to me.

If that is needed, the commit message is not complete, or am I wrong.


Thanks,

Paul

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: Getting patches committed

[Konrad Mattheis]

> On 01/21/2010 05:20 AM, Dr. Michael Lauer wrote:
> > Am 21.01.2010 um 11:02 schrieb Holger Hans Peter Freyther:
> >>> 2. Is there a way to have a staging branch where all patches are
> >>> committed to, which have not been reviewed for let us say one week, to
> >>> get more testing and before they go into the dev branch? Maybe it is
> >>> easier for people to at least test build such a branch?
> >>
> >> Would you be interested in creating such a branch for us? I assume it is
> >> certainly easier to git cherry-pick a patch than to download the mbox
> >> and use git am..
> >
> > I fully agree. I'm neither using patchwork nor do I find patches on the
> > list a good idea. I'd welcome for-oe-upstream trees that would contain
> > patches that -- if good -- we could just pull from.
> 
> I actually like patches on the list, because it makes me aware of how is
> doing work and keeps me aware of the kinds of things people without
> commit access are interested in. Also, it gives people with commit
> access a forum for changes they would like reviewed.
> 
> I am not opposed to someone creating a git branch or branches created
> from list patches, but do not want to see the patches disappear from the
> list.
> 
> If the patch that was sent to the list comes from git-send-patch (I hope
> I hve that correct) there is a script contrib/patchwork/git-am.sh that
> makes it really easy to apply the patch.
> 
> Philip

>I'm one of those without commit rights :)
>And i think the problem is, that nobody feels responsible for the patches on 
>patchwork. I know this situation from SHR patchwork, when you don't ask 
>someone directly to commit a patch from patchwork, nobody will do it.
>That's the only way it really works currently.
>I have 4 people with commit rights i can ask, so i have no problems but others 
>probably doesn't know someone...

I'm in the same situation. Till now I only changed things in my own copy
of the tree, because I don't understand how the patching is working. For example
I read a lot of patches which are send to the mailing list, but no
discussion, no NACK or ACK. 
I also working on u-boot and this development mailing list is complete
different. If I send a patch to the list I get in less than 2 days an
answer. And then the patch is discussed it always ends with a ACK or NACK.

> I think a sort of moderator for patchwork is needed,
> that associates patches to the maintainer.
yes ! and also more discussions about

Konrad

Re: Getting patches committed

[Paul Menzel]

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

Am Donnerstag, den 21.01.2010, 07:15 -0500 schrieb Philip Balister:
> On 01/21/2010 05:20 AM, Dr. Michael Lauer wrote:
> > Am 21.01.2010 um 11:02 schrieb Holger Hans Peter Freyther:
> >
> >>> 2. Is there a way to have a staging branch where all patches are
> >>> committed to, which have not been reviewed for let us say one week, to
> >>> get more testing and before they go into the dev branch? Maybe it is
> >>> easier for people to at least test build such a branch?
> >>
> >> Would you be interested in creating such a branch for us? I assume it is
> >> certainly easier to git cherry-pick a patch than to download the mbox and use
> >> git am..
> >
> > I fully agree. I'm neither using patchwork nor do I find patches on the list a good idea.
> > I'd welcome for-oe-upstream trees that would contain patches that -- if good -- we could
> > just pull from.
> 
> I actually like patches on the list, because it makes me aware of how is 
> doing work and keeps me aware of the kinds of things people without 
> commit access are interested in. Also, it gives people with commit 
> access a forum for changes they would like reviewed.
> 
> I am not opposed to someone creating a git branch or branches created 
> from list patches, but do not want to see the patches disappear from the 
> list.

See my answer to Frans. The idea was to only apply those patches to the
new branch if they did not receive an answer for a certain amount of
time.

> If the patch that was sent to the list comes from git-send-patch (I hope 
> I hve that correct) there is a script contrib/patchwork/git-am.sh that 
> makes it really easy to apply the patch.

Thank you for this tip. Are the others developers aware of it. And if
yes and they do not use it, what are the reasons?


Thanks,

Paul

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: Getting patches committed

[Rolf Leggewie]

Dr. Michael Lauer wrote:
> I fully agree. I'm neither using patchwork nor do I find patches on the list a good idea.
> I'd welcome for-oe-upstream trees that would contain patches that -- if good -- we could
> just pull from.

Yes, me too would prefer to pull another branch from somewhere and
cherry-pick from it over other solutions.

I have two questions.

1) is it possible to host such a free-for-all branch somewhere?
2) although generally not a good idea, would it be possible to rebase
   this branch frequently so that the unapplied patches always come
   up first in "git log"?

OE needs a stronger community culture.  Too many devs are just contempt
with "my stuff works fine for me".

Re: Getting patches committed

[Frans Meulenbroeks]

Even if there is a git branch there needs to be a mail to the list
describing that the git should be pulled. With that there should be a
description on what has changed.
And basically I fear that we are just shifting the problem.
If no one picks up the patches from the list, what makes you guys
think that once they are in a git they get added.

One of the problems with patches (and probably also with git) is who
picks them up.
If someone is sent to the list and it is related to something that I
am knowledgeable in, I'll try to look into it.
If not, I tend to avoid, first of all because of the burden (i feel
that before committing I need to compile it and if possible do some
basic testing, which is tough if it is not really something I have the
knowledge or hw for), and secondly because someone who feels more
attached with the area is also working on it.

Frans

Re: Getting patches committed

[Paul Menzel]

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

Am Donnerstag, den 21.01.2010, 13:34 +0100 schrieb Frans Meulenbroeks:
> Even if there is a git branch there needs to be a mail to the list
> describing that the git should be pulled.

My idea was to send that patch to the list and that it gets committed to
this new branch if there has not been an answer for a certain amount of
time, for example a week.

> With that there should be a description on what has changed.

Is not that the commit message?

> And basically I fear that we are just shifting the problem.
> If no one picks up the patches from the list, what makes you guys
> think that once they are in a git they get added.

For some this seems to be a better usability since they can just
checkout that branch and work with it as they are used to.

[…]


Thanks,

Paul

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: Getting patches committed

[Martin Jansa]

On Thu, Jan 21, 2010 at 01:16:26PM +0100, Rolf Leggewie wrote:
> Dr. Michael Lauer wrote:
> > I fully agree. I'm neither using patchwork nor do I find patches on the list a good idea.
> > I'd welcome for-oe-upstream trees that would contain patches that -- if good -- we could
> > just pull from.
> 
> Yes, me too would prefer to pull another branch from somewhere and
> cherry-pick from it over other solutions.
> 
> I have two questions.
> 
> 1) is it possible to host such a free-for-all branch somewhere?

Would be OK to create also branch for stuff I'm going to push upstream
soon? with developer name prefix like WIP branches ie
martin_jansa/for-oe-upstream ?

When I'm changing something far from my comfort zone, and I would like to 
discuss it on ML/get ACK before pushing. It would be nice to send just
summary to ML with link to that branch instead of whole patch-series.

And creating new branch for every occasion like this would be overkill
as branch delete needs admin hand.

> 2) although generally not a good idea, would it be possible to rebase
>    this branch frequently so that the unapplied patches always come
>    up first in "git log"?

Yes rebase would be really usefull in this type of branch also to be
able to integrate changes from ML discussion or some minor bug noticed
just after pushing. 

Also if some modified solution to some problem is already pushed to
oe.dev by someone else to see after rebase what is left and if not
needed then remove that change.

Sometimes I got feeling that I should push something ASAP as there is
high probability that someone else would like to test some new version
too and when I already have those recipes and checksums etc I want to
share at least to avoid duplicate work. 
ie xorg recipe upgrades... which I have in semi-automated way.


BTW: Maybe there should be some info from sender, if he has commit right
or not. Because if someone sends patch just for discussion (like me)
then it should be clear if someone else is needed to call 
contrib/patchwork/git-am.sh or not. (not sure how to indicate that in git
send-mail without introductory e-mail and still valid commit message)

Regards,
-- 
uin:136542059                jid:Martin.Jansa@gmail.com
Jansa Martin                 sip:jamasip@voip.wengo.fr 
JaMa                         

Re: Getting patches committed

[Stanislav Brabec]

Martin Jansa wrote:

> Would be OK to create also branch for stuff I'm going to push upstream
> soon? with developer name prefix like WIP branches ie
> martin_jansa/for-oe-upstream ?

Yes, WIP free-for-all branches would be a good idea. Something like this
exists in openSUSE Build Service and it is used by many users for their
experiments.

As OE uses git, maybe by purpose hierarchy could be better than by user,
for example:
wip/org.openembedded.dev.no_static_libraries

Every branch should contain README with this information:
Who created it
Why it was created
Why it is not in mainline
What needs to be done to merge it with mainline.
When the branch becomes obsolete.

I guess that many patches are lost just because the original author lost
effort to finish the work and make the patch good for mainline.

With such public wip branches, anybody can take the work, improve it or
finish it.



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

Re: Getting patches committed

[Stanislav Brabec]

Rolf Leggewie wrote:

> 2) although generally not a good idea, would it be possible to rebase
>    this branch frequently so that the unapplied patches always come
>    up first in "git log"?

Just a rough idea:


mailing list

Anybody can send a mail with:

[DRAFT] ... controversial patch that needs discussion

[REVIEW] ... core patch or patch that needs review or ACK

[RFC] ... request for comments for large change before starting to do
anything.

[PATCH] ... patch from people that afraid of submitting to git or first
attempts. If no one complies, script auto-moves the patch to
org.openembedded.open


org.openembedded.open (or .staging or .public)

Tree for changes expected to be safe (by the submitter).

Anybody can submit to org.openembedded.open tree.

Anybody can veto (bad approach), amend (fix added to the commit) or
postpone (needs fix) any change in org.openembedded.open. Email will be
generated to discuss and learn submitter.

Changes that did not get veto or postponed will be pushed to
org.openembedded.dev (in most cases with a defined delay, in specific
cases (bug fixes) manually).

Is there any git expert that can comment, whether git makes something
like this possible?


org.openembedded.dev

Users with commit access can commit directly patches expected to be
save.

Everything other goes through .open.

> OE needs a stronger community culture.  Too many devs are just contempt
> with "my stuff works fine for me".

Not as easy as it sounds. OE is a heterogeneous environment. Knowing
that things may break on some platform need non-trivial knowledge.



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

Re: Getting patches committed

[Rolf Leggewie]

Stanislav Brabec wrote:
> org.openembedded.open (or .staging or .public)

funny thing.  I was discussing something like this with RP just when you
sent this mail.  It's not as straightforward as it may sound, though.
First of all, I think we'd need several, possibly unlimited number of
FFA branches.  Second, RP and I agreed that security implications are a
concern if we allow commit access completely uninhibited.

>> OE needs a stronger community culture.  Too many devs are just contempt
>> with "my stuff works fine for me".
> 
> Not as easy as it sounds. OE is a heterogeneous environment. Knowing
> that things may break on some platform need non-trivial knowledge.

If things are non-trivial, they should be reviewed.  If a committer is
unsure, when in doubt, go for a review.

I'm talking of things like new bb recipes that can really do no harm
unless someone explicitly builds them.  There are still a number of them
in the bug tracker that are 2, 3 or even more years old.  There really
is no excuse for that IMHO, not even "I'm not interested in the recipe
in question".  Recently, I closed a significant number of tickets with
recipes that had been reinvented and committed by somebody else in the
meantime.  What a waste of time on both sides

Re: Getting patches committed

[Stanislav Brabec]

Rolf Leggewie wrote:
> Stanislav Brabec wrote:
> > org.openembedded.open (or .staging or .public)
> 
> funny thing.  I was discussing something like this with RP just when you
> sent this mail.  It's not as straightforward as it may sound, though.
> First of all, I think we'd need several, possibly unlimited number of
> FFA branches.  Second, RP and I agreed that security implications are a
> concern if we allow commit access completely uninhibited.

Security in world of open source is is always based on web of trust.

If any enterprise OE customer wants, it's possible to introduce digital
signatures of recipes including digital signatures of checksums and all
referred sources, classes etc.

Then anybody can create virtual team of trusted people and ignore
unsigned recipes.

But this alone does not prevent use of hacked upstream tarballs or
malicious software.

Well, and OE probably has vulnerable software.

For example CVE-2008-1372 was present in bzip2 for more than a year:
Full disclosure date: 10/17/2008
Fixed in OE: 01/10/2010

Watching this would probably require professional team subscribed to
vendor-sec, and backporting fixes to stable branches.


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

Re: Getting patches committed

[Rolf Leggewie]

Stanislav Brabec wrote:
>> FFA branches.  Second, RP and I agreed that security implications are a
>> concern if we allow commit access completely uninhibited.
> 
> Security in world of open source is is always based on web of trust.

Hehe, I was really referring to something else, namely the security of
the git repository host computer.

Re: Getting patches committed

[Richard Purdie]

On Fri, 2010-01-22 at 01:13 +0100, Stanislav Brabec wrote:
> Rolf Leggewie wrote:
> > funny thing.  I was discussing something like this with RP just when you
> > sent this mail.  It's not as straightforward as it may sound, though.
> > First of all, I think we'd need several, possibly unlimited number of
> > FFA branches.  Second, RP and I agreed that security implications are a
> > concern if we allow commit access completely uninhibited.
> 
> Security in world of open source is is always based on web of trust.
[...]
> Watching this would probably require professional team subscribed to
> vendor-sec, and backporting fixes to stable branches.

Lets live in the real world here. Allowing what amounts to anonymous
access to an account on the server is not what I'd call sensible. No, OE
isn't perfect about security fixes but thats totally unrelated to
whether we'd like the main server to be secure.

Yes, there are ways of restricting access to the commands anonymous
access could run but we don't have a full time team of admins looking
after it and I don't like the idea of painting a target on the machine.

I would be perfectly happy to see a repo that anyone can request access
to and maintain branches in of their patches. This would make it easier
to review and for devs to pull from. If an enterprising person starts
collating patches and does a good job they stand a good chance of
getting .dev access - the subsystem maintainer model of the Linux kernel
works well.

There is a new gitosis replacement available that allows branch level
access control and I'd like us to start using it.

Cheers,

Richard

Re: Getting patches committed

[Holger Hans Peter Freyther]

On Friday 22 January 2010 01:13:34 Stanislav Brabec wrote:

> Well, and OE probably has vulnerable software.
> 
> For example CVE-2008-1372 was present in bzip2 for more than a year:
> Full disclosure date: 10/17/2008
> Fixed in OE: 01/10/2010

Yupp... that was something that bothered me at Openmoko. I tried to talk 
Julian into writing a script to go through the debian security uploads and 
compare that with versions we have in OE...

yet another topic to take care of.
	z.

Re: Getting patches committed

[Petr Štetiar]

Rolf Leggewie <no2spam@nospam.arcornews.de> [2010-01-22 00:11:54]:

> Stanislav Brabec wrote:
> > org.openembedded.open (or .staging or .public)
> 
> funny thing.  I was discussing something like this with RP just when you
> sent this mail.  It's not as straightforward as it may sound, though.
> First of all, I think we'd need several, possibly unlimited number of
> FFA branches.  Second, RP and I agreed that security implications are a
> concern if we allow commit access completely uninhibited.

What's wrong with public Git hostings? Everyone can create one on
Git(orious|hub) or repo.or.cz. OE isn't that big as Linux kernel yet, so the
size of the repo shouldn't be problem for a free hosting.

-- ynezz

Re: Getting patches committed

[Rolf Leggewie]

Petr Štetiar wrote:
> What's wrong with public Git hostings?

Nothing.  In fact, it would be preferred for various reasons.  But I
haven't yet found anything that works the way I was envisioning this to
work.  The mob branch concept of repo.or.cz comes close.  But it's just
one branch, I'd prefer to have several.

Re: Getting patches committed

[Petr Štetiar]

Rolf Leggewie <no2spam@nospam.arcornews.de> [2010-01-22 15:53:06]:

> Petr Štetiar wrote:
> > What's wrong with public Git hostings?
> 
> Nothing.  In fact, it would be preferred for various reasons.  But I
> haven't yet found anything that works the way I was envisioning this to
> work.  The mob branch concept of repo.or.cz comes close.  But it's just
> one branch, I'd prefer to have several.

Well, I meant, that everyone without r/w to OE would create his own account on
preffered Git hosting and there his own OE fork. He'll just send pull request
to mailing list with URL to repository or branch on his own box or somewhere
on public Git hosting, let the contributor decide. This way you don't need to
maintain anything, you'll just cherry-pick what you like or understand from
those branches.

Well, to not overload those public hostings it would be nice/necessary to
mirror OE repo on few of them so the contributors can just fork it, which is
always cheaper and preffered way I think.

-- ynezz

Re: Getting patches committed

[Rolf Leggewie]

Petr Štetiar wrote:
> He'll just send pull request to mailing list

That media break adds no value and barely improves the current situation
IMO.  I want a work-flow where a dev doesn't ever need to leave working
with git.