From: Koen Kooi <k.kooi@student.utwente.nl>
To: openembedded-devel@lists.openembedded.org
Subject: Re: release-2010.12 branch ready for testing
Date: Fri, 19 Nov 2010 15:16:02 +0100 [thread overview]
Message-ID: <ic60r2$hrs$1@dough.gmane.org> (raw)
In-Reply-To: <4CE67FA1.6020901@mentor.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 19-11-10 14:46, Tom Rini wrote:
> On 11/19/2010 03:34 AM, Koen Kooi wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 18-11-10 22:27, Khem Raj wrote:
>>> Hello all,
>>>
>>> The work branch for upcoming 2010.12 release has been created.
>>
>> Why was this created? We were *very* clear at OEDEM that there would be
>> no branch, only a tag.
>>
>> Why was this changed? I only see some vague handwaving from the TSC
>> (well, from Phil, saying it was the TSC) who didn't consult the OE
>> developers at all.
>>
>> The whole point of releases was that they are based of a tag from .dev,
>> not some random branch. Again, why was that changed?
>
> At least for making a release tag exist, if we can't have a freeze on
> .dev (or otherwise an agreement that .dev should focus on making the
> testing packages build and work, over new work) making a temporary
> branch to cherry-pick into seems to be the next possible solution.
> Otherwise the release tag is just another testing tag...
Well, that was the whole point. The release is supposed to be only a
testing tag...
We were very clear at OEDEM, no *branch* only a tag. If .dev isn't
working, find a testing tag in the past that does work and use that as a
release.
It seems people are trying to polarize issues, when they shouldn't. So
no "freeze .dev", but "pay more attention to .dev" and no "release
branch" but "encourage getting more green into tinderbox".
The idea was to get a release out and see how people are using it to
improve the process and test conditions, not making a kneejerk process
for this release.
I've seen no discussion on this list why we need a branch or a freeze
instead of following the OEDEM plam, only people stating that we need
it. So what's wrong with the original plan of getting the release out
and using actual experience as feedback for future releases?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
iD8DBQFM5oahMkyGM64RGpERAk1OAJ9Oo6sMLydFi5HYoVQAfQr4AoVVrQCfRd0V
v06+p6STeoj35fihSo/Lu2I=
=d9+8
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2010-11-19 14:17 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-18 21:27 release-2010.12 branch ready for testing Khem Raj
2010-11-19 8:38 ` Frans Meulenbroeks
2010-11-19 10:34 ` Koen Kooi
2010-11-19 13:46 ` Tom Rini
2010-11-19 14:16 ` Koen Kooi [this message]
2010-11-19 14:44 ` Martin Jansa
2010-11-19 17:34 ` Philip Balister
2010-11-21 2:48 ` Khem Raj
2010-11-19 18:21 ` Khem Raj
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='ic60r2$hrs$1@dough.gmane.org' \
--to=k.kooi@student.utwente.nl \
--cc=openembedded-devel@lists.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.