RFC: RW for otavio

RFC: RW for otavio

[Rolf Leggewie]

Hi,

I'd like to propose rw access for another contributor, Otavio Salvador.
 Otavio is a Debian developper, so I guess the issue should be already
settled right there ;-)  Some of his commit history can be seen at CIA

http://cia.vc/stats/author/otavio

Some of his work has already made it into OE (bugs 3342, 3371, 3372,
3373 and the all-otavio-bug 4340).  Lately, his patches have been coming
in faster than I can look at and verify them and it would be a shame to
slow him down or build up a queue.

The solution is simple: RW access for otavio.

Regards

Rolf

Re: RFC: RW for otavio

[Robert Schuster]

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

Hi.

Rolf Leggewie schrieb:
> I'd like to propose rw access for another contributor, Otavio Salvador.
>  Otavio is a Debian developper,
We need more DDs to convince them to use OE later. ;) ;)

 > Some of his work has already made it into OE (bugs 3342, 3371, 3372,
> 3373 and the all-otavio-bug 4340).  Lately, his patches have been coming
> in faster than I can look at and verify them and it would be a shame to
> slow him down or build up a queue.
Sounds good.

> The solution is simple: RW access for otavio.
+1

Regards
Robert


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: RFC: RW for otavio

[Henning Heinold]

On Fri, Jun 06, 2008 at 10:41:20AM +0200, Robert Schuster wrote:
> Hi.
> 
> Rolf Leggewie schrieb:
> > I'd like to propose rw access for another contributor, Otavio Salvador.
> >  Otavio is a Debian developper,
> We need more DDs to convince them to use OE later. ;) ;)
> 
I agree.

>  > Some of his work has already made it into OE (bugs 3342, 3371, 3372,
> > 3373 and the all-otavio-bug 4340).  Lately, his patches have been coming
> > in faster than I can look at and verify them and it would be a shame to
> > slow him down or build up a queue.
> Sounds good.
> 
> > The solution is simple: RW access for otavio.
> +1
+1 from me too.


Bye,

Henning

Re: RFC: RW for otavio

[Marcin Juszkiewicz]

Dnia piątek, 6 czerwca 2008, Rolf Leggewie napisał:
> The solution is simple: RW access for otavio.

+1 from me

-- 
JID: hrw-jabber.org
OpenEmbedded developer/consultant

             I do not fear computers. I fear the lack of them.
             		-- Isaac Asimov

Re: RFC: RW for otavio

[Michael 'Mickey' Lauer]

Ok, seems people are convinced this is a good idea.

Otavio, please send your mtn and ssh keys to
Koen <k.kooi@student.utwente.nl> and me <mlauer@vanille-media.de>.

:M:
-- 
Dr. Michael 'Mickey' Lauer | IT-Freelancer | http://www.vanille-media.de

Re: RFC: RW for otavio

[Richard Purdie]

On Fri, 2008-06-06 at 15:02 +0200, Michael 'Mickey' Lauer wrote:
> Ok, seems people are convinced this is a good idea.
> 
> Otavio, please send your mtn and ssh keys to
> Koen <k.kooi@student.utwente.nl> and me <mlauer@vanille-media.de>.

I have no objection to Otavio having access so please don't
misunderstand this email in that regard. This is more a general issue I
want to raise.

What I'd like to see is some kind of code of conduct for developers,
particularly new ones to ensure changes get appropriate review and we
don't see cause any conflict.

As guidelines:

* Changes to class files need review on the mailing list
* Changes to more global .conf files need review (e.g. bitbake.conf)
* Changes to core toolchain components need review (gcc, binutils, 
  libtool, pkgconfig, automake, autoconf etc.)
* Machine configs are less sensitive but machine maintainers should be 
  consulted where present and known
* Distro config changes should be reviewed by the distro maintainers 
  where known
* Recipe changes are less sensitive but maintainers should be consulted 
  where known

The point here is to let people build up gradually. Changing the core
infrastructure can influence a lot of people and whilst I don't want to
discourage people hacking on it, we do need to take more care on those
changes than ones in "lower" level recipes. I'm fairly sure most of the
devs know and respect this, I just wonder if having some kind of more
formal policy written down would be a good idea so people know where
they stand?

Opinions?

Cheers,

Richard

Re: RFC: RW for otavio

[Otavio Salvador]

Richard Purdie <rpurdie@rpsys.net> writes:

> The point here is to let people build up gradually. Changing the core
> infrastructure can influence a lot of people and whilst I don't want to
> discourage people hacking on it, we do need to take more care on those
> changes than ones in "lower" level recipes. I'm fairly sure most of the
> devs know and respect this, I just wonder if having some kind of more
> formal policy written down would be a good idea so people know where
> they stand?

This is usual in most projects.

I fully agree that this should be a policy and would be nice to have a
cannonical place to look for maintainers. That avoids mistakes from
begginers (like me).

I also believe this makes easier and avoid stupid mistakes to get in
SCM. More people checking is always good and I see no problem in
requiring it.

Cheers,

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

Re: RFC: RW for otavio

[Koen Kooi]

Richard Purdie wrote:
> On Fri, 2008-06-06 at 15:02 +0200, Michael 'Mickey' Lauer wrote:
>> Ok, seems people are convinced this is a good idea.
>>
>> Otavio, please send your mtn and ssh keys to
>> Koen<k.kooi@student.utwente.nl>  and me<mlauer@vanille-media.de>.
>
> I have no objection to Otavio having access so please don't
> misunderstand this email in that regard. This is more a general issue I
> want to raise.
>
> What I'd like to see is some kind of code of conduct for developers,
> particularly new ones to ensure changes get appropriate review and we
> don't see cause any conflict.
>
> As guidelines:
>
> * Changes to class files need review on the mailing list
> * Changes to more global .conf files need review (e.g. bitbake.conf)
> * Changes to core toolchain components need review (gcc, binutils,
>    libtool, pkgconfig, automake, autoconf etc.)
> * Machine configs are less sensitive but machine maintainers should be
>    consulted where present and known
> * Distro config changes should be reviewed by the distro maintainers
>    where known
> * Recipe changes are less sensitive but maintainers should be consulted
>    where known
>
> The point here is to let people build up gradually. Changing the core
> infrastructure can influence a lot of people and whilst I don't want to
> discourage people hacking on it, we do need to take more care on those
> changes than ones in "lower" level recipes. I'm fairly sure most of the
> devs know and respect this, I just wonder if having some kind of more
> formal policy written down would be a good idea so people know where
> they stand?
>
> Opinions?

Developers that get access trough proper channels get this text sent to 
them after their key has been added:

---
Hi,

If you are reading this, you have been granted commit access to the 
award winning OpenEmbedded Project. To make things go smoothly we have 
some basic rules:

  1) Everything outside org.openembedded.dev/packages/ should be treated 
with extreme care. Please communicate with other developers first if you 
want to touch that area. If you are a distro maintainer you are of 
course free to touch your distro config files without asking. If you are 
a machine maintainer, please communicate first, since it's easy to get 
things wrong and not all machines are good examples to copy from.

  2) Think twice before using an override, usually overrides can be 
avoided, especially ones like these:

      do_compile() {
          oe_runmake
      }	

      do_compile_myfirstdisto() {
          oe_runmake -D_GNU_SOURCE
      }

     You may think "I don't want to break other distributions", but in 
99% of the cases your fix will unbreak other distros as well, so using 
an override will cause more work for other developers, since they have 
to work out the fix by themselves. You don't want other people to spend 
weeks trying to solve a problem which solution is masked by a bogus 
override.

  3) It's fine to fix a recipe you don't maintain, but if you are unsure 
of your change, try to contact the maintainer or, if no maintainer is 
listed, send a note to the OE developer mailinglist.

  4) Split your changes into their logical subparts. It's easier to 
track down problems afterwards with a binary search.

  5) Have a clear commit messages, and mention the affected bugnumbers 
if appropriate.

  6) Sync early, sync often. Nobody likes to reinvent the wheel. Merging 
is easy with monotone, so don't hesitate to run sync just before your 
plane takes off and your wifi gets disconnected.

You can view our policies and cheatsheets at:

  * http://www.openembedded.org/wiki/Policies
  * http://www.openembedded.org/wiki/MonotonePhrasebook

---

I think we discussed the above text at the first OEDEM :)

Re: RFC: RW for otavio

[Rolf Leggewie]

Hi Richard

Richard Purdie wrote:
> What I'd like to see is some kind of code of conduct for developers,
> particularly new ones

Good point.

In fact, I've been thinking about how to get new devs up to speed more
quickly as well.  I thought the new wiki would be a good place to have
this and so I started http://wiki.openembedded.net/index.php/New_Dev
Right now, there is nothing there yet, except a list of things to touch
on.  I guess the points you and Koen raised would make good additions.

Regards

Rolf

Weird build failures

[Otavio Salvador]

Hello,

Bellow goes a weird build failure that I see no reason for it. It
fails but if I rebuild the package it works. It has happened to many
packages while I were building my image and I would like to know if
someone has a tip where the problem is.

,----
| otavio@neumann:~/hacking/ossystems/oe$ ../../bitbake/bin/bitbake angstrom-version
| NOTE: Handling BitBake files: | (6168/6168) [100 %]
| NOTE: Parsing finished. 5911 cached, 0 parsed, 257 skipped, 0 masked.
| NOTE: Cache is clean, not saving.
| NOTE: build 200811102310: started
| 
| OE Build Configuration:
| BB_VERSION        = "1.8.11"
| METADATA_BRANCH   = "master"
| METADATA_REVISION = "0e42d3070e612a4c90f0f13ccd7e20bf0e823863"
| TARGET_ARCH       = "i586"
| TARGET_OS         = "linux"
| MACHINE           = "oppitz-lx800"
| DISTRO            = "ossystems"
| DISTRO_VERSION    = "7.1-20081111"
| TARGET_FPU        = ""
| 
| NOTE: Resolving any missing task queue dependencies
| NOTE: Preparing runqueue
| NOTE: Executing runqueue
| NOTE: Running task 333 of 460 (ID: 9, /home/otavio/hacking/ossystems/oe/packages/angstrom/angstrom-version.bb, do_populate_staging)
| NOTE: Running task 335 of 460 (ID: 15, /home/otavio/hacking/ossystems/oe/packages/angstrom/angstrom-version.bb, do_package_write_ipk)
| NOTE: package angstrom-version-7.1-20081111: started
| NOTE: package angstrom-version-1_7.1-20081111-r1: task do_populate_staging: started
| NOTE: package angstrom-version-7.1-20081111: started
| NOTE: package angstrom-version-1_7.1-20081111-r1: task do_package_write_ipk: started
| ERROR: Error in executing: /home/otavio/hacking/ossystems/oe/packages/angstrom/angstrom-version.bb
| ERROR: Exception:<type 'exceptions.IOError'> Message:[Errno 2] No such file or directory: '/home/otavio/hacking/ossystems/oe/tmp/work/oppitz-lx800-ossystems-linux/angstrom-version-1_7.1-20081111-r1/install/angstrom-version.lock'
| ERROR: Printing the environment of the function
| ERROR: Error in executing: /home/otavio/hacking/ossystems/oe/packages/angstrom/angstrom-version.bb
| ERROR: Exception:<type 'exceptions.IOError'> Message:[Errno 2] No such file or directory: '/home/otavio/hacking/ossystems/oe/tmp/work/oppitz-lx800-ossystems-linux/angstrom-version-1_7.1-20081111-r1/install/angstrom-version.lock'
| ERROR: Printing the environment of the function
| ERROR: Build of /home/otavio/hacking/ossystems/oe/packages/angstrom/angstrom-version.bb do_package_write_ipk failed
| Traceback (most recent call last):
|   File "/home/otavio/hacking/bitbake/bin/bitbake", line 136, in <module>
|     main()
|   File "/home/otavio/hacking/bitbake/bin/bitbake", line 133, in main
|     cooker.cook()
|   File "../../bitbake/lib/bb/cooker.py", line 641, in cook
|   File "../../bitbake/lib/bb/cooker.py", line 551, in buildTargets
|   File "../../bitbake/lib/bb/runqueue.py", line 842, in execute_runqueue
|   File "../../bitbake/lib/bb/runqueue.py", line 951, in execute_runqueue_internal
|   File "../../bitbake/lib/bb/cooker.py", line 137, in tryBuild
|   File "../../bitbake/lib/bb/cooker.py", line 111, in tryBuildPackage
|   File "../../bitbake/lib/bb/build.py", line 278, in exec_task
|   File "../../bitbake/lib/bb/build.py", line 113, in exec_func
|   File "../../bitbake/lib/bb/build.py", line 136, in exec_func_python
|   File "../../bitbake/lib/bb/utils.py", line 171, in better_exec
|   File "do_package_write_ipk", line 11, in <module>
|   File "do_package_write_ipk", line 9, in do_package_write_ipk
|   File "../../bitbake/lib/bb/build.py", line 113, in exec_func
|   File "../../bitbake/lib/bb/build.py", line 136, in exec_func_python
|   File "../../bitbake/lib/bb/utils.py", line 171, in better_exec
|   File "do_package_ipk", line 182, in <module>
|   File "do_package_ipk", line 32, in do_package_ipk
|   File "../../bitbake/lib/bb/utils.py", line 249, in lockfile
| IOError: [Errno 2] No such file or directory: '/home/otavio/hacking/ossystems/oe/tmp/work/oppitz-lx800-ossystems-linux/angstrom-version-1_7.1-20081111-r1/install/angstrom-version.lock'
| ERROR: Task 15 (/home/otavio/hacking/ossystems/oe/packages/angstrom/angstrom-version.bb, do_package_write_ipk) failed
| NOTE: Waiting for 1 active tasks to finish
| NOTE: 1: /home/otavio/hacking/ossystems/oe/packages/angstrom/angstrom-version.bb, do_populate_staging (24297)
| NOTE: package angstrom-version-1_7.1-20081111-r1: task do_populate_staging: completed
| NOTE: package angstrom-version-7.1-20081111: completed
| NOTE: Tasks Summary: Attempted 453 tasks of which 453 didn't need to be rerun and 1 failed.
| ERROR: '/home/otavio/hacking/ossystems/oe/packages/angstrom/angstrom-version.bb' failed
| NOTE: build 200811102310: completed
`----

Cheers,

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