OEDEM: Summary of 'OE and Poky', 'Hosting', 'Bugtracker'

OEDEM: Summary of 'OE and Poky', 'Hosting', 'Bugtracker'

[Michael 'Mickey' Lauer]

===========
Poky and OE
===========

RP still works on Poky, since Poky is easier to break, RP has more
freedom to break stuff and try new ideas for improvements that will
also benefit OE.

Intel owns Poky as the brandname, however there seems to be no clear
direction right now where they want to take it.

OE is being improved gradually to support the merits of Poky, although
due to the sheer amount of recipes it will probably always lack behind
in perceived quality. OE and Poky do try to remain in sync, though.

As a product, it is important for Poky to have a short list of
people with commit access. This already adds up to the quality of the
metadata. The dictator model works for Poky, but does not work for OE.

It is noted that the current dev process does not work particularly
well,
some people think it is too easy to get commit access to OE.
(Editor's note: See also stable branch session)

=======================================
Hosting
=======================================
The prefix of the member's mailinglist has been removed, reply-to-list
has been enabled. Various people work on getting the remaining services
on amethyst to work on LTG (which is a powerful machine these days).
Phil and Phillip are improving the server configuration to get rid
of our mail/DNS problems.

We will do changes on the git layout, e.g. org.oe.dev is becoming
'master'
and user branches will live in a seperate repository.

=======================================
Bugtracker
=======================================
We will keep the bugtracker, but perform a radical cleanup, i.e.
all non-OE and non-BB versions/milestones/components will be dumped.
We will improve the description of what belongs into the bugtracker
and what not. We will also reinstatiate the bug squashing weekends.

Cheers,

:M:

Re: OEDEM: Summary of 'OE and Poky', 'Hosting', 'Bugtracker'

[Stefan Schmidt]

Hello.

On Tue, 2009-11-10 at 14:07, Michael 'Mickey' Lauer wrote:
> 
> We will do changes on the git layout, e.g. org.oe.dev is becoming
> 'master'
> and user branches will live in a seperate repository.

While I can understand the former I can't see the reason for the later. Can you
explain why that was decided?

For me user and other topic branches worked well on the main repository. The
only issue I have is the flood of commits on the commit ml when a branch gets
rebased, but that is something that a filter in the commit mail hook should be
able to solve.

regards
Stefan Schmidt

Re: OEDEM: Summary of 'OE and Poky', 'Hosting', 'Bugtracker'

[Esben Haabendal]

On Tue, Nov 10, 2009 at 2:27 PM, Stefan Schmidt
<stefan@datenfreihafen.org> wrote:
> Hello.
>
> On Tue, 2009-11-10 at 14:07, Michael 'Mickey' Lauer wrote:
>>
>> We will do changes on the git layout, e.g. org.oe.dev is becoming
>> 'master'
>> and user branches will live in a seperate repository.
>
> While I can understand the former I can't see the reason for the later. Can you
> explain why that was decided?
>
> For me user and other topic branches worked well on the main repository. The
> only issue I have is the flood of commits on the commit ml when a branch gets
> rebased, but that is something that a filter in the commit mail hook should be
> able to solve.

Splitting out user branches into separate repository gives:

* option of giving developers access to push to user branches but not master
  branches

* git clone of master repository does not pull down all users objects

* namespace of master repository is not "polluted" by user branches.

Working with a master and a user repository should work just as well
as the current setup in all other aspects than having to do an (extra)
"git remote add" command.

/Esben

Re: OEDEM: Summary of 'OE and Poky', 'Hosting', 'Bugtracker'

[Otavio Salvador]

Hello,

On Tue, Nov 10, 2009 at 11:27 AM, Stefan Schmidt
<stefan@datenfreihafen.org> wrote:
> For me user and other topic branches worked well on the main repository. The
> only issue I have is the flood of commits on the commit ml when a branch gets
> rebased, but that is something that a filter in the commit mail hook should be
> able to solve.

In fact I believe that the best option would be to have individual
trees at the server as is done at git.kernel.org so people can work at
their individual tree and ask for pull or review. That avoids non-used
branches at the main repository.

My 2c.

-- 
Otavio Salvador                  O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854         http://projetos.ossystems.com.br

Re: OEDEM: Summary of 'OE and Poky', 'Hosting', 'Bugtracker'

[Michael 'Mickey' Lauer]

Am Dienstag, den 10.11.2009, 14:27 +0100 schrieb Stefan Schmidt:
> On Tue, 2009-11-10 at 14:07, Michael 'Mickey' Lauer wrote:
> > 
> > We will do changes on the git layout, e.g. org.oe.dev is becoming
> > 'master'
> > and user branches will live in a seperate repository.
> 
> While I can understand the former I can't see the reason for the later. Can you
> explain why that was decided?

The major two reasons were clarity and access control.

Clarity: Reducing the number of branches in the main tree to master and
a bunch of topic-branches was perceived as a good thing.

Access control: Having user branches in a dedicated tree means we can
give more users commit access so that they can prepare branches we can
pull. This might lead to (IMHO much appreciated) improvements in the
development model towards a pull model.

Cheers,

:M:

Re: OEDEM: Summary of 'OE and Poky', 'Hosting', 'Bugtracker'

[Esben Haabendal]

On Tue, Nov 10, 2009 at 3:38 PM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
> Hello,
>
> On Tue, Nov 10, 2009 at 11:27 AM, Stefan Schmidt
> <stefan@datenfreihafen.org> wrote:
>> For me user and other topic branches worked well on the main repository. The
>> only issue I have is the flood of commits on the commit ml when a branch gets
>> rebased, but that is something that a filter in the commit mail hook should be
>> able to solve.
>
> In fact I believe that the best option would be to have individual
> trees at the server as is done at git.kernel.org so people can work at
> their individual tree and ask for pull or review. That avoids non-used
> branches at the main repository.
>
> My 2c.

I agree 100% with you on that.  I don't see any advantage of trying to
stuff so much into common repositories. It just increases the
time/bandwidth needed by git fetch.  Nobody uses all branches anyway.

So I will throw 2c into that bucket as well :-)

/Esben

Re: OEDEM: Summary of 'OE and Poky', 'Hosting', 'Bugtracker'

[Stefan Schmidt]

Hello.

On Tue, 2009-11-10 at 15:35, Esben Haabendal wrote:
> On Tue, Nov 10, 2009 at 2:27 PM, Stefan Schmidt
> <stefan@datenfreihafen.org> wrote:
> >
> > On Tue, 2009-11-10 at 14:07, Michael 'Mickey' Lauer wrote:
> >>
> >> We will do changes on the git layout, e.g. org.oe.dev is becoming
> >> 'master'
> >> and user branches will live in a seperate repository.
> >
> > While I can understand the former I can't see the reason for the later. Can you
> > explain why that was decided?
> >
> > For me user and other topic branches worked well on the main repository. The
> > only issue I have is the flood of commits on the commit ml when a branch gets
> > rebased, but that is something that a filter in the commit mail hook should be
> > able to solve.
> 
> Splitting out user branches into separate repository gives:
> 
> * option of giving developers access to push to user branches but not master
>   branches

Maybe it's time to do the full step then go over to a pull based model?

> * git clone of master repository does not pull down all users objects

Is that really an issue for people?

> * namespace of master repository is not "polluted" by user branches.

The real problem is here that the git commit hooks forbid a branch delete in our
setup. If you want to ahve a branch removed you have to ping an admin.

> Working with a master and a user repository should work just as well
> as the current setup in all other aspects than having to do an (extra)
> "git remote add" command.

I know and I don't have a problem with the change. Just curious what the reasons
are. I neither have a problem with Otavios proposal that everytone should have
their own tree. The point is more about a good way of getting the changes _back
into master_. :)

regards
Stefan Schmidt

Re: OEDEM: Summary of 'OE and Poky', 'Hosting', 'Bugtracker'

[Stefan Schmidt]

Hello.

On Tue, 2009-11-10 at 15:50, Michael 'Mickey' Lauer wrote:
> Am Dienstag, den 10.11.2009, 14:27 +0100 schrieb Stefan Schmidt:
> > On Tue, 2009-11-10 at 14:07, Michael 'Mickey' Lauer wrote:
> > > 
> > > We will do changes on the git layout, e.g. org.oe.dev is becoming
> > > 'master'
> > > and user branches will live in a seperate repository.
> > 
> > While I can understand the former I can't see the reason for the later. Can you
> > explain why that was decided?
> 
> The major two reasons were clarity and access control.
> 
> Clarity: Reducing the number of branches in the main tree to master and
> a bunch of topic-branches was perceived as a good thing.

ok

> Access control: Having user branches in a dedicated tree means we can
> give more users commit access so that they can prepare branches we can
> pull. This might lead to (IMHO much appreciated) improvements in the
> development model towards a pull model.

But why the hassle of administrate an own git repo service for this? I always
thought OE was small on admin power.

regards
Stefan Schmidt

Re: OEDEM: Summary of 'OE and Poky', 'Hosting', 'Bugtracker'

[Richard Purdie]

On Tue, 2009-11-10 at 16:14 +0100, Stefan Schmidt wrote:
> > Access control: Having user branches in a dedicated tree means we can
> > give more users commit access so that they can prepare branches we can
> > pull. This might lead to (IMHO much appreciated) improvements in the
> > development model towards a pull model.
> 
> But why the hassle of administrate an own git repo service for this? I always
> thought OE was small on admin power.

Note that we're taking about one extra "contrib" repository with user
branches so the extra admin overhead is minimal. People proposed a repo
per user but that wasn't felt to be acceptable due to the admin
concerns.

Cheers,

Richard

Re: OEDEM: Summary of 'OE and Poky', 'Hosting', 'Bugtracker'

[Michael 'Mickey' Lauer]

Am Dienstag, den 10.11.2009, 16:14 +0100 schrieb Stefan Schmidt:
> > Access control: Having user branches in a dedicated tree means we can
> > give more users commit access so that they can prepare branches we can
> > pull. This might lead to (IMHO much appreciated) improvements in the
> > development model towards a pull model.
> 
> But why the hassle of administrate an own git repo service for this? I always
> thought OE was small on admin power.

Sorry, this might have been unclear on my part, it's just different
projects on the same repository, not different repositories. We'd like
to and recommend OE developers to host their branch in a 'contrib'
project on git.oe.org.

Cheers,

:M:

Re: OEDEM: Summary of 'OE and Poky', 'Hosting', 'Bugtracker'

[Stefan Schmidt]

Hello.

On Tue, 2009-11-10 at 15:38, Richard Purdie wrote:
> On Tue, 2009-11-10 at 16:14 +0100, Stefan Schmidt wrote:
> > > Access control: Having user branches in a dedicated tree means we can
> > > give more users commit access so that they can prepare branches we can
> > > pull. This might lead to (IMHO much appreciated) improvements in the
> > > development model towards a pull model.
> > 
> > But why the hassle of administrate an own git repo service for this? I always
> > thought OE was small on admin power.
> 
> Note that we're taking about one extra "contrib" repository with user
> branches so the extra admin overhead is minimal. People proposed a repo
> per user but that wasn't felt to be acceptable due to the admin
> concerns.

For both you would have to fetch the ssh key and put it into gitosis. The later
one would also need an initial tree creation. The point I'm making is that on an
external git repo hoster even that work would be gone.

Anyway, I stop here. I was mostly interested in the reasons behing the
decisions not more.

regards
Stefan Schmidt

OEDEM: Summary of 'OE and Poky', 'Hosting', 'Bugtracker'

[Otavio Salvador]

Hello,

On Tue, Nov 10, 2009 at 1:52 PM, Michael 'Mickey' Lauer
<mickey@vanille-media.de> wrote:
> Sorry, this might have been unclear on my part, it's just different
> projects on the same repository, not different repositories. We'd like
> to and recommend OE developers to host their branch in a 'contrib'
> project on git.oe.org.

I see no point in having a contrib tree with many users on it; I much
prefer to have a by-user tree and then allowing them to do whatever
they want on this tree.

If someone needs to contribute on a tree, he can fork it and make it
available for pulling. This is the easiest way of starting to  "train"
people to get used to the pull-model.

A simple solution might be to use gitorious for oe as being done in
qt; that avoids the admin hassle and provides more user friendly
interface for it.

-- 
Otavio Salvador                  O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854         http://projetos.ossystems.com.br

Re: OEDEM: Summary of 'OE and Poky', 'Hosting', 'Bugtracker'

[Esben Haabendal]

On Tue, Nov 10, 2009 at 6:19 PM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
> Hello,
>
> On Tue, Nov 10, 2009 at 1:52 PM, Michael 'Mickey' Lauer
> <mickey@vanille-media.de> wrote:
>> Sorry, this might have been unclear on my part, it's just different
>> projects on the same repository, not different repositories. We'd like
>> to and recommend OE developers to host their branch in a 'contrib'
>> project on git.oe.org.
>
> I see no point in having a contrib tree with many users on it; I much
> prefer to have a by-user tree and then allowing them to do whatever
> they want on this tree.
>
> If someone needs to contribute on a tree, he can fork it and make it
> available for pulling. This is the easiest way of starting to  "train"
> people to get used to the pull-model.

Exactly.  It is quite hard to appreciate the pull-model before trying it
for some real work.

> A simple solution might be to use gitorious for oe as being done in
> qt; that avoids the admin hassle and provides more user friendly
> interface for it.

Good idea.  Git admin overhead could definitely be reduced/simplified
by switching to gitorious.  And it doesn't seem like OE is crowded
by people with system administration as their 2nd hobby...

/Esben

Re: OEDEM: Summary of 'OE and Poky', 'Hosting', 'Bugtracker'

[Holger Hans Peter Freyther]

> It is noted that the current dev process does not work particularly
> well,
> some people think it is too easy to get commit access to OE.

At WebKit we hand out commit access easily as well, this doesn't mean that 
people can commit at free will... We still require review for every change.

z.

Re: OEDEM: Summary of 'OE and Poky', 'Hosting', 'Bugtracker'

[Phil Blundell]

On Wed, 2009-11-11 at 02:07 +0100, Holger Hans Peter Freyther wrote:
> > It is noted that the current dev process does not work particularly
> > well,
> > some people think it is too easy to get commit access to OE.
> 
> At WebKit we hand out commit access easily as well, this doesn't mean that 
> people can commit at free will... We still require review for every change.

Yes, this is quite a common paradigm.  GCC works the same way: there are
many people with "write after approval" access, which means that they
are technically able to check in to the tree but they are expected to
get their patches reviewed first.

p.