All of lore.kernel.org
 help / color / mirror / Atom feed
From: Otavio Salvador <otavio@debian.org>
To: openembedded-devel@lists.openembedded.org
Cc: openembedded-devel@openembedded.org
Subject: Re: Switching SCM to git and commit/review policy
Date: Mon, 16 Jun 2008 12:48:54 -0300	[thread overview]
Message-ID: <87myllz8gp.fsf@neumann.lab.ossystems.com.br> (raw)
In-Reply-To: <g35tdc$upb$1@ger.gmane.org> (Rolf Leggewie's message of "Mon\, 16 Jun 2008 16\:30\:06 +0200")

Rolf Leggewie <no2spam@nospam.arcornews.de> writes:

> Otavio Salvador wrote:
>>  - the tree will be a moving target, without stable revision numbers
>>    and difficult to merge, base work in and like
>
> OE is always a moving target.  I don't see how the policy would change that.

The revisions will be a moving target. To tag a commit as "not-ok"
you'd need to amend it and  them change it rev number.

>>  - most of the pros can be done using the oe-next tree. Doing a full
>>    compilation of changed modules before and after each merge gives a
>>    nice feedback for trivial problems
>
> Modules?  Are you talking kernel?  Or are you using modules as a synonym
> for recipe?

recipe, sorry.

>>  - Being available on unstable doesn't mean it'll be tested
>
> Neither does any of the other proposals ensure that.  "tested" sounds
> like 0 or 1, but in fact it is a continuum.  I can at least think of the
> following
>
> - compiles fine
> - compiles fine from scratch
> - compiles fine from scratch for MACHINE/DISTRO X and Y
> - tested to run on MACHINE X
> - tested to run on all supported MACHINEs
> - does not interfere with another package
>
> What do you mean by "tested"?  How will other processes and policies
> ensure that?

We can't ensure that also because most of tests need to be done by an
human. I think that a sort of compile tests are enough to kill most of
problems.

We can also think about make a specific distro that is need to be
booted, using qemu or whatever, that ensures that basic stuff isn't
break due the change.

>>  - 2 days is a too short testing window
>
> well, that is of course just a proposal and thus easy to fix if necessary.
>
> PS: This is not a rebuttal or a claim that the proposed policy is even a
> desirable one.  But I feel there is more need for clarification.

Sure. I also believe this all need more discussion and
clarification. Mostly because I'm a begginer at OE world and then I
can miss understand a lot of things, sure.

-- 
        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."



  reply	other threads:[~2008-06-16 15:47 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-13  8:20 Switching SCM to git and commit/review policy Richard Purdie
2008-06-13 10:06 ` pHilipp Zabel
2008-06-13 12:43   ` Cliff Brake
2008-06-13 14:16     ` Koen Kooi
2008-06-16 16:35       ` Rolf Leggewie
2008-06-13 17:17     ` Otavio Salvador
2008-06-13 17:49     ` Tom Rini
2008-06-13 14:09   ` Koen Kooi
2008-06-13 16:25     ` pHilipp Zabel
2008-06-13 17:38       ` Koen Kooi
2008-06-13 18:38         ` Otavio Salvador
2008-06-13 19:37           ` Holger Freyther
2008-06-13 21:00             ` Otavio Salvador
2008-06-16 11:10               ` Rolf Leggewie
2008-06-16 13:16                 ` Otavio Salvador
2008-06-16 14:30                   ` Rolf Leggewie
2008-06-16 15:48                     ` Otavio Salvador [this message]
2008-06-16 16:27                       ` Rolf Leggewie
2008-06-16 17:03                         ` Otavio Salvador
2008-06-16 14:17               ` Rolf Leggewie
2008-06-16 22:42                 ` Florian Boor
2008-06-16 23:21                 ` Michael 'Mickey' Lauer
2008-06-16 13:09           ` Mark Brown
2008-06-17  9:51             ` Jan Lübbe
2008-06-24  9:57 ` Graeme Gregory
2008-06-24 14:01   ` Alain M.
2008-06-24 18:48     ` Leon Woestenberg
2008-06-24 20:13       ` Philip Balister
2008-06-24 18:33   ` Koen Kooi
2008-06-24 19:06     ` Tom Rini
2008-06-24 20:51       ` Florian Boor
2008-06-24 21:29         ` Tom Rini
2008-06-24 22:51           ` Leon Woestenberg
2008-06-25  1:22             ` Luís Vitório Cargnini
2008-07-14 12:22 ` Rolf Leggewie
2008-07-14 18:57   ` Koen Kooi
2008-07-14 23:24     ` Core team (was: Switching SCM to git and commit/review policy) Rolf Leggewie
2008-07-14 23:24     ` Rolf Leggewie
2008-07-15  9:45       ` Richard Purdie
2008-07-18 18:30         ` Shane Volpe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87myllz8gp.fsf@neumann.lab.ossystems.com.br \
    --to=otavio@debian.org \
    --cc=openembedded-devel@lists.openembedded.org \
    --cc=openembedded-devel@openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.