Hi,
As we near final release it is even more important that bugs which
effect the LEB's and other images are caught early and fixed as soon as
possible. To help aid the Linaro Release Team [1] in identifying and
dealing with these types of bugs the following procedure significantly
helps on projects which produce, or are installed on the images:
1) All bugs in a 'New' state should be sufficiently triaged to
determine their 'Importance'.
2) All bugs which are deemed 'High' or 'Critical' should be
highlighted to the Release Team. To do this use the 'Subscribe
someone else' link on the right hand side of the bug. When the
pop-up appears type 'linaro-release' into the box and select the
release team when it is found.
3) If the bug needs discussion please add it to the wiki page for the
current weeks Release meeting. The calendar for the Release
meeting can be found at:
https://wiki.linaro.org/Cycles/WeeklyReleaseMeeting
Meetings are currently on a Thursday so add the bug to the 'Bugs'
section of the next meeting. If possible please attend the meeting.
The Release Team will go through the list of bugs [2] regularly and help
to get fixes in place ready for milestone releases [3]. This information
can also be found on the wiki at:
https://wiki.linaro.org/Cycles/BugManagement
Regards,
Jamie.
--
Linaro Release Manager | Platform Project Manager
[1] https://launchpad.net/~linaro-release
[2] https://bugs.launchpad.net/~linaro-release
[3] https://wiki.linaro.org/Cycles/1105#Milestones
All these git related puns are killing me :-)
On Fri, Apr 8, 2011 at 8:46 AM, Will Deacon <will.deacon(a)arm.com> wrote:
> > On Fri, Apr 8, 2011 at 3:45 PM, Tixy <tixy(a)yxit.co.uk> wrote:
> > > On Fri, 2011-04-08 at 10:16 +0100, Dave Martin wrote:
> > >> one reason why my understanding of the actual problem here was a bit
> > >> patchy.
> > >
> > > <groan> :-)
> >
> > _not_ intentional! (if you believe me)
>
> I don't believe you; I think you should consider branching out
> into comedy...
>
> Will
>
>
>
>
> _______________________________________________
> linaro-dev mailing list
> linaro-dev(a)lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-dev
>
Enclosed you'll find a link to the agenda, minutes and actions from the
Linaro Toolchain working group weekly meetings of April 04 & 07, 2011.
https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2011-04-04https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2011-04-07
== Summary ==
* More vectoriser patches including if-conversion, different vector sizes,
and vzip/vunzip are going upstream
* Chung-Lin continues to knock off a good set of bugs
* QEMU consolidation continues
* A fair set of patches were accepted upstream recently
* The OMAP3 patch set has been split further up.
* A separate set of discussions on Thumb-2 performance improvements will
start soon
* Andrew is running a Linaro Android baseline build to prepare for the
Android GCC patches later
* Linaro GCC 4.6 is being updated to the new FSF 4.6 release branch
* Cleaning up the libunwind testsuite for use exercising the ARM port
Regards,
Mounir
Hi all,
I've encountered a problem trying to unpick the history of the linaro
git trees, but I don't think it's specific to us:
The problem seems to be that when a merge is committed, git references
the merged commits in their original context: no information is
recorded about how the merge was resolved. The result just appears by
magic as the new tree recorded for the merge commit.
This seems to mean that git format-patch x..y (where x is an ancestor
of y) does _not_ necessarily give you a patch series which actually
applies on x (indeed, the generated patch series may not be appliable
on any commit, in any order). This is certainly my experience.
As a result, it seems very difficult to pick apart the history of a
branch beyond the last merge commit, because the git repo only records
the logical ancestry (i.e., which upstream patches got merged) rather
than any "physical" history (i.e., what sequence of actual changes
would be needed to reconstruct the branch). In fact, it seems to be
nonsense to think in terms of a sequence of patches beyond a merge
commit.
What I'm actually trying to do is cherry-pick a few omap- and Thumb-
specific commits out of the linaro tree to apply on v2.6.39-rc2 --
just the minimum subset so that I can develop Thumb stuff on a tree
which is as clean and close to upstream as possible. But I repeatedly
run into problems where patch p from branch b depends on
cherry-picking some other patch q merged branch b, but the cherry pick
fails since the actual delta recorded for q is in the context of
someone else's branch (the branch that was merged from).
If anyone knows a straightforward way to achieve this, I'd be interested ...
Of course, I may be trying to do entirely the wrong thing.
Cheers
---Dave
FYI:
----- Forwarded message from Gunnar Wolf <gwolf(a)debian.org> -----
Date: Thu, 7 Apr 2011 14:16:33 -0500
From: Gunnar Wolf <gwolf(a)debian.org>
To: debian-devel-announce(a)lists.debian.org
Subject: Registration now open for DebConf11
User-Agent: Mutt/1.5.20 (2009-06-14)
Registration is now open for DebConf11. For registration instructions,
please see:
http://debconf11.debconf.org/register.xhtml
DebConf11 will take place in Banja Luka, in Republika Srpska, Bosnia
and Herzegovina from Sunday 24th to Saturday 30th July, 2011. DebConf
will be preceded by DebCamp, from Sunday 17th to Saturday 23rd July,
2011. DebCamp is a smaller, less formal event intended for group work
on Debian projects.
The sponsored registration deadline is 8 May.
Again, this year, we will have basic, sponsored, professional (€450),
and corporate (€1000) registration categories. Travel sponsorship is
again available.
----- End forwarded message -----
Cheers,
--
Steve McIntyre
steve.mcintyre(a)linaro.org
