<div dir="ltr">Hi,<div>for those who don't know me, I'm an AOSP developer at work and an OpenMandriva developer (including maintainer of its toolchains) outside of work, so I'm looking at this from (at least) 2 different perspectives and may jump around between them.</div><div>Replies inline...<br><div class="gmail_extra"><br><div class="gmail_quote">On 11 May 2016 at 16:08, Renato Golin <span dir="ltr"><<a href="mailto:renato.golin@linaro.org" target="_blank">renato.golin@linaro.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">There has been enough discussion about keeping development downstream<br>
and how painful that is. Even more so, I think we all agree, is having<br>
downstream releases while tracking upstream releases, trunk and other<br>
branches (ex. Android).<br></blockquote><div><br></div><div>In the OpenMandriva world, we usually try to have clang (our primary compiler) as close as possible to the latest upstream stable release.</div><div>We're currently following the release_38 branch, and expect to jump on trunk as soon as our distro release has happened (because we expect 3.9 to be ready before we'll make our subsequent release - better to get on the branch we'll be using for the next release early than to suddenly face problems when updating to the next release).</div><div><br></div><div>In the AOSP world, we obviously have to (somewhat) follow what Google does, which is typically pick a trunk snapshot and work from there - but we have some work underway to extract their patches so we can apply them on top of a release or snapshot of our choice (current thought is mostly nightly builds for testing).</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">This work involves a *lot* of premises that are not encoded yet, so<br>
we'll need a lot of work from all of us. But from the recent problems<br>
with GCC abi_tag and the arduous job of downstream release managers to<br>
know which patches to pick, I think there has been a lot of wasted<br>
effort by everyone, and that generates stress, conflicts, etc.<br></blockquote><div><br></div><div>From both perspectives, it would be great to have a common set of "known good" and relevant patches like gcc abi_tag, or fixes for bugs commonly encountered.</div><div>Ideally, I'd like to see those patches just backported on the release_38 branch to keep the number of external patches low.</div><div><br></div><div>gcc abi_tag is a bit of a headache in the OpenMandriva world, while we build just about everything with clang these days, of course it would be good to restore binary compatibility with the bigger distributions (almost all of which are using current gcc with the new abi enabled).</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Many downstream release managers, as well as distro maintainers have<br>
complained about the timing of our releases,</blockquote><div><br></div><div>The timing has been quite predictable lately -- but of course the website still says "TBD" for both 3.8.1 and 3.9.0, maybe communicating the (likely) plan could use some improvement.</div><div><div> </div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
 * Do the same average on the projects that are willing to lend a<br>
serious hand to the upstream release process.</blockquote><div><br></div><div>What can we (this time being OpenMandriva) do? We don't have any great compiler engineers, but we're heavy users - would it help to run a mass build of all packages for all supported architectures (at this time: i586, x86_64, armv7hnl, aarch64) to detect errors on a prerelease builds? We have the infrastructure in place, even showing a fairly nice list of failed builds along with build logs. (But of course we there will be false positives caused by e.g. a library update that happened around the same time as the compiler update.)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"> * Try to release more often. The current cost of a release is high,<br>
but if we managed to lower it (by having more people, more automation,<br>
shared efforts), than it could be feasible and much fairer than<br>
weighted averages.<br></blockquote><div><br></div><div>That would be a good idea IMO, we've run into "current trunk is much better than the last stable release anyway" situations more than once (in both projects).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">For example, we have no defined date to start, or to end. We have no<br>
assigned people to do the official releases, or test the supported<br>
targets. We still rely on voluntary work from all parties. That's ok<br>
when the release is just "a point in time", but if downstream releases<br>
and OS distributions start relying on our releases, we really should<br>
get a bit more professional.<br></blockquote><div><br></div><div>Backporting some more fixes to the stable branches would be great too (but of course I realize that's a daunting and not very interesting task).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"> * Downstream managers should be an integral part of the upstream<br>
release process. Whenever the release manager sends the email, they<br>
should test on their end and reply with GREEN/RED flags.<br>
 * Downstream managers should also propose back-ports that are<br>
important to them in the upstream release. It's likely that a fix is<br>
important to a number of downstream releases but not many people<br>
upstream (since we're all using trunk). So, unless they tell us, we<br>
won't know.<br></blockquote><div><br></div><div>Sounds good to me, volunteering to participate in both.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"> * We could have the scripts that distros use for building their own<br>
packages in our tree, so they could maintain them locally and we'd<br>
know which changes are happening and would be much easier to warn the<br>
others, common up the interface, etc.<br></blockquote><div><br></div><div>While interesting from an upstream perspective, I doubt that will happen reliably -- there's too many people working on the build scripts who would not automatically have write access to the tree etc. and most distro build farms rely on having the build scripts in a common place, so duplication would be unavoidable.</div><div><br></div><div>ttyl</div><div>bero </div></div></div></div></div>