From: Stefan Schmidt <stefan@datenfreihafen.org>
To: openembedded-devel@lists.openembedded.org
Subject: Re: 2011.03 release testing, starts soon!
Date: Wed, 9 Feb 2011 10:56:45 +0100 [thread overview]
Message-ID: <20110209095644.GE28019@excalibur.local> (raw)
In-Reply-To: <09D9BE2AC4AA764DABAA8C91E48D819E011A79A329@DEMCHP99E35MSX.ww902.siemens.net>
Hello.
On Wed, 2011-02-09 at 10:25, Aeschbacher, Fabrice wrote:
>
> There are two things which could be useful (IMO) for OE users:
>
> 1. a small README file (or wiki page) just highlighting the main
> changes since last release (2010.12), e.g. something like
> "Prominent features (the cool stuff)" on http://kernelnewbies.org/LinuxChanges
> This would help us OE users to decice whether it is worth rebasing on the latest
> release now, or if it can wait
Good point. Getting such a high level changelog in place would indeed be a good
idea.
> 2. Do not delete the release branch after 2011.03 will be released (just like
> it was done for 2010.12), but let it live and allow developpers committing
> bug-fixes (backporting choosen things?) reported back by OE users (some would
> would be happy to contribute this way)
That was already discussed. We make a tag with the release rev from which can be
branched again _if_ people are stepping up to support this branch on a mid or
long term base.
The branch Tom is using until the release is pretty useless froma history point
of view (all changes must be in master as well). When he thinks the release is
good enough the tag gets added and the old branch deleted. For the last release
nobody cared to support it afterwards with bugfixes so no release branch was
created.
I'm thinking about this for the upcoming release. If all works well we will base
a product on it which I would like to support directly from such a release
branch.
The hard part is how people could decide on pooling resources on this. Defining
goals for such a branch and stuff. E.g. only take serious fixes? What about
package updates? Security fixes? changes on the toolchain or classes?
This is up to the group who wants to support such a branch. Anyone else
interested in doing this for 2011-03?
My alternative would be to branch of from the tag and do the maintenance in a
private branch.
regards
Stefan Schmidt
next prev parent reply other threads:[~2011-02-09 9:58 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-08 19:41 2011.03 release testing, starts soon! Tom Rini
2011-02-09 9:25 ` Aeschbacher, Fabrice
2011-02-09 9:56 ` Stefan Schmidt [this message]
2011-02-09 10:18 ` Koen Kooi
2011-02-09 10:42 ` Stefan Schmidt
2011-02-09 11:20 ` Koen Kooi
2011-02-09 20:30 ` Khem Raj
2011-02-10 8:31 ` Stefan Schmidt
2011-02-09 14:47 ` Tom Rini
2011-02-10 9:42 ` Aeschbacher, Fabrice
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=20110209095644.GE28019@excalibur.local \
--to=stefan@datenfreihafen.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox