Re: [Ubuntu-phone] ANNOUNCEMENT: snap support in bileto
On Nov 9, 2016 2:19 AM, "Lukasz Zemczak" wrote: > > Hey Robert! > > Excellent, I suppose that's a good first stage to start off from - > thanks! Just to make sure: so right now the snap builds are being made > from existing snap recipes, right? That's correct, the snap support currently takes existing snap recipes inputs similar to how it takes MPs as inputs to build debs. > This means that every lander > wanting to rebuild a snap from a silo has to have his/her own recipe > set up for the given project? Yes. > Ideally we'd like all this to happen > automatically by Bileto, since basically setting up a recipe for the > given snap anyway gives a 'one click' experience of building snaps. > Right now it's just redirecting people to press a button on Bileto > instead of Launchpad. Not true. The current iteration automates the addition of the bileto ppa during the snap build. So if you have a ticket that is just a snap, you're right, clicking snap in bileto is not very different than clicking build on an lp snap recipe. But if you have a ticket with a pile of packages in the ppa, and your snap is built from those debs, then it makes sense to use the bileto snap button. > > Hope to see things automated even more! Yep, i will continue working on it. Just want to release early and often so i can iterate on feedback from users. -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] ANNOUNCEMENT: snap support in bileto
Hi all! Happy US election day! Today I've rolled out the very first iteration of snap support in bileto. It's very rudimentary at this point but it does appear to work, so I'm opening it up for a public pre-pre-pre-alpha. Here's how to use it: 1. Commit your snapcraft.yaml to your project trunk. 2. Create a snap recipe from your project trunk. 3. Create a ticket at bileto.ubuntu.com 4. In the snaps field, list your snap as team/recipe, eg, if your snap recipe is at https://launchpad.net/~foo/+snap/bar then you'd enter "foo/bar" 5. Click the new "snap" button 6. Trigger the job page that opens 7. See the snap builds appear on the ticket page 8. Download your snap and enjoy! Known issues: A. Doesn't report build progress in the ticket like it does for debs. B. Only works if your snap is built exclusively from debs, eg, if your snapcraft references your source tree, the source tree used will be your trunk instead of the branch with all your merges merged in C. Requires you to trigger snap builds manually rather than doing it automatically after detecting your debs finished building. Solving those issues are all on my radar, but please do give it a shot today and tell me how it goes! -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] ANNOUNCING: bileto.ubuntu.com
Hi all, I've just completed the new rollout of bileto.ubuntu.com. User-visible changes here are minimal, but behind the scenes we've now migrated from trusty to xenial, allowing us to discard a great deal of backported packages that were necessary for bileto to run on trusty. So update your bookmarks, because requests.ci-train.ubuntu.com will redirect to bileto.ubuntu.com for a while but not forever! Thanks, any questions don't hesitate to ask me. Have a great day! -- robru -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] ANNOUNCEMENT: "citrain" script changes
Hi all, For those of you using the "citrain" script to consistently install packages from bileto landing tickets onto your ubuntu phones, there have been some changes: 1. The script has been renamed to "bileto" to reflect the fact that ci train is no longer a thing that exists. If you use the old name you'll see a deprecation warning. 2. It no longer accepts the old-style PPA number (0 - 100) as an argument. Instead, it now takes the bileto ticket number, and looks up the PPA name from the ticket. This is because it is impossible to infer the PPA name from the ticket number, so the ticket must be consulted in all cases. All users of the script should update to the latest version, which is available in yakkety, and in xenial can be found in both the overlay PPA and the phablet-team/tools PPA. -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] ANNOUNCING: Ephemeral PPAs!
WOW! Git support and ephemeral PPAs in one week, what a crazy whirlwind of progress! Yes, that's right: Starting now, all new tickets in Bileto will have PPAs dynamically created for them. All existing tickets will continue using the "old" PPAs without any disruption. Have a great day! -- robru -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] [Bileto-announce] OPEN BETA: Git support in Bileto!
Ah, looks like there's a firewall issue with production that didn't affect staging, so I've filed an RT to get the firewall opened up for git. Should be resolved hopefully soon? Hopefully soon, the ticket status should eventually change to 'Ready to build' or at least to whatever the next error to iterate on is. On Wed, Aug 31, 2016 at 2:26 AM, Simon Fels wrote: > I've just did a quick test on > https://requests.ci-train.ubuntu.com/log/1889/build/latest/ which tries to > build from > https://code.launchpad.net/~morphis/aethercast/+git/aethercast/+merge/304460 > but this directly fails with missing access rights. > > Any idea? > > regards, > Simon > > On Wed, Aug 31, 2016 at 11:22 AM, Konrad Zapałowicz > wrote: >> >> Awesome! >> >> On Wed, Aug 31, 2016 at 11:10 AM, Simon Fels >> wrote: >>> >>> This is awesome!!! Great work! >>> >>> On Wed, Aug 31, 2016 at 9:44 AM, Lukasz Zemczak >>> wrote: >>>> >>>> Sweet! >>>> >>>> On 30 August 2016 at 21:45, Robert Park >>>> wrote: >>>> > Hi all, >>>> > >>>> > I've just rolled experimental git support into production Bileto. This >>>> > means it's now possible for Bileto to merge git merges for you in >>>> > addition to the usual bzr. I know some people were wanting this for a >>>> > long time, and some people are using git for development then export >>>> > to bzr just to use Bileto, well those days are over! Now you can use >>>> > your git branches natively! >>>> > >>>> > The support has been tested and works well in staging, but the test >>>> > data set was somewhat small so it won't surprise me if not everything >>>> > works perfect right out of the gate. Please do try it out and report >>>> > issues to me ASAP and I will fix up whatever problems are found. >>>> > >>>> > Thanks! >>>> > >>>> > -- >>>> > robru >>>> > >>>> > -- >>>> > Mailing list: https://launchpad.net/~ubuntu-phone >>>> > Post to : ubuntu-phone@lists.launchpad.net >>>> > Unsubscribe : https://launchpad.net/~ubuntu-phone >>>> > More help : https://help.launchpad.net/ListHelp >>>> >>>> >>>> >>>> -- >>>> Łukasz 'sil2100' Zemczak >>>> Foundations Team >>>> lukasz.zemc...@canonical.com >>>> www.canonical.com >>>> >>>> -- >>>> Mailing list: https://launchpad.net/~ubuntu-phone >>>> Post to : ubuntu-phone@lists.launchpad.net >>>> Unsubscribe : https://launchpad.net/~ubuntu-phone >>>> More help : https://help.launchpad.net/ListHelp >>> >>> >>> >>> -- >>> Mailing list: https://launchpad.net/~ubuntu-phone >>> Post to : ubuntu-phone@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~ubuntu-phone >>> More help : https://help.launchpad.net/ListHelp >>> >> > > > -- > Mailing list: https://launchpad.net/~bileto-announce > Post to : bileto-annou...@lists.launchpad.net > Unsubscribe : https://launchpad.net/~bileto-announce > More help : https://help.launchpad.net/ListHelp > -- robru -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] ANNOUNCEMENT: Bileto no longer blocks on no-change rebuilds
Hi all, In addition to the big git announcement earlier, here's a small behavioral change to make your lives easier: When scanning for unexpected uploads in the destination archive, bileto will now inspect those changes and ignore them if they are no-change rebuilds. If the changes are found to be meaty, the log will print the precise diff you need to apply to your trunk to get things going again. Looking at production I see a few cases where "destination version missing from changelog" has disappeared, because those missing versions were merely no-change rebuilds. But still some more cases remain as it turns out that packaging fixes have been uploaded. So, going forward, "destination version missing from changelog" is no longer an ignorable message and it can't be overridden. Action is required to fix it, and the log says exactly what to do so you don't need to go hunting for diffs. Enjoy! -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] OPEN BETA: Git support in Bileto!
Hi all, I've just rolled experimental git support into production Bileto. This means it's now possible for Bileto to merge git merges for you in addition to the usual bzr. I know some people were wanting this for a long time, and some people are using git for development then export to bzr just to use Bileto, well those days are over! Now you can use your git branches natively! The support has been tested and works well in staging, but the test data set was somewhat small so it won't surprise me if not everything works perfect right out of the gate. Please do try it out and report issues to me ASAP and I will fix up whatever problems are found. Thanks! -- robru -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] ANNOUNCEMENT: Bileto style tweaks
Hi guys, I've taken some time to iterate on the way bileto displays statuses and signoffs. In particular, instead of calculating one color for the whole ticket, I've given the three signoffs and the status independent coloring, and I've also introduced some whimsical icons. Every icon is a unique shape and color so this should be very friendly to colorblind individuals. As always there's probably some obscure corner cases i've overlooked. Please do let me know if there are any cases where the color/icon chosen for a given status/signoff doesn't make sense. I've done my best to ensure there are no cases of "GIANT RED X: Success!" but probably other strange combinations might have slipped in. Enjoy! -- robru -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] Note, workaround for bug in automated signoff of tickets (britney)
Hi all, A few people have been bitten by this bug recently: https://bugs.launchpad.net/britney/+bug/1608635 That is, your automated signoff fails and then you click on the excuses.html and all you see is "not considered" with no explanation of what went wrong. For now, as a workaround, just replace "html" with "yaml" in the URL and you'll see the raw data file with the explanation of what went wrong, which will provide some clues on how to proceed. Often this requires trainguard intervention so don't hesitate to ping "trainguards" in #ubuntu-ci-eng when you see this. Thanks! -- robru -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] ANNOUNCING: New Bileto Status Job
Hi all, Just a quick update, Bileto has taken over the role of the status-updater, which means jenkins is no longer performing this action. This change should be largely transparent to everybody, but please do ping me if you see anything unusual happening. You may notice that when you click through the status to see the log that generated the status, you're no longer taken to a jenkins page, but instead stay within bileto. And if you're really attentive you may notice that the jenkins status jobs which usually took 10-20 minutes now often take 2-3 minutes ;-) The rollout is already done and as far as I can see everything was a total success, but I am monitoring everything for anomalies, just in case. Take care! -- robru -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] ANNOUNCING: Bileto can now revert landings after they've merged.
Hi all, happy Canada Day! CI Train had a little-known feature to revert landings, which was severely bit-rotted for some time. I've resurrected this in Bileto with some shiny new unit tests to stave off the bitrot in spite of it's infrequent use. Documentation is here, enjoy: https://wiki.ubuntu.com/citrain/LandingProcess#Reverting_a_Landing -- robru -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] ANNOUNCEMENT: PPAs are now automatically assigned to tickets at build time.
On Mon, Jun 20, 2016 at 1:53 PM, Lukasz Zemczak wrote: > Less clicks is always good! But I don't really like how bileto handles > cases of manual-source-only tickets right now. If you don't have any > MPs but only want to assign a silo to get a PPA for manual upload, > pressing build just does the thing but the silo is then in an ugly > error state. Could you maybe fix it so that pressing build without any > MPs when the silo is unassigned is a normal operation? We have a lot > of silos like that. Ok, I'll clean up that error. > I always liked the idea of assigning silos explicitly first. Removing > the assign step completely makes super sense when ephemeral PPAs are > available, meaning - each ticket is automatically assigned a PPA. Indeed, this idea originated from the ephemeral PPA work. It just happened to be super easy to do now that jenkins is out of the way, even though we don't even have ephemeral PPAs yet. > Right now, at least for the manual source part, it's a bit unintuitive > - I have a ticket, I know I can't build anything as I don't have a > silo: duh, how am I supposed to get a PPA? Pressing 'Build'? Uh, build > like... what? Yeah. It all works, but feels artificial ;) Indeed it's a little counter-intuitive, but I don't think that's a big deal. The people who need to know will learn it, but the vast majority of silos build from MPs so it makes sense to just drop your MPs in the ticket and click build. Assignment doesn't even cross your mind anymore ;-) -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] ANNOUNCEMENT: PPAs are now automatically assigned to tickets at build time.
Greetings from sunny Athens! While I'm enjoying my vacation, it is incredibly hot here! I just couldn't help implementing this fun little feature while hiding from the midday heat in my hotel room. Assigning PPAs to tickets is now fully automated. There is no longer an 'assign' button on tickets, instead just click Build and a PPA will be automatically assigned if one hasn't already been. In the event that there are no PPAs available, the build job will error out the same way the assign job used to, and you can ask a trainguard to find a stale one to free for you. Much efficiency! Less clicks! Wow ;-) -- robru -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] Where's robru?
Hi all, Just a heads up, I will be on vacation June 20th to 24th here in beautiful Greece. If you have any problems with CI Train / Bileto, these are the best people to contact: Ken VanDine Barry Warsaw (although he's only around Monday and Friday) Ted Gould Lukasz Zemczak Also any Ubuntu Core Dev has permission to do everything that trainguards can do, so worst case if you need a build or an autopkgtest retried, just find the button that needs to be clicked and send it to any of these people: https://launchpad.net/~ubuntu-core-dev/+members#active I'll be trying to limit my exposure to IRC / emails., but in case of some really horrible explosion I will be reachable by SMS. Thanks! -- robru -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] ANNOUNCEMENT: More Jenkins jobs migrated into Bileto
Hi all, The inevitable march of progress continues! Today I have ported the Assign, Merge&Clean (now called "Finalize"), and Abandon jobs from Jenkins to Bileto. This should be a relatively transparent switch, just click the buttons on the bileto ticket and the correct thing should happen. No behavioral changes are required on your part, but you may notice, eg, that Bileto doesn't log you out every 10 seconds like jenkins does, so things work more smoothly with less re-logging-in every time you want to run one of those jobs. As always, there are risks of regression, so please do let me know if anything isn't working for you! -- robru -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] ANNOUNCEMENT: Bileto jobs are now cancellable.
Hello, Just a quick update that the jobs which run in bileto (currently the build & diff jobs, hopefully more soon), are now cancellable. When you run jobs you'll now see a big cancel button in the log output as long as the job is still running. This cancellation is much more sophisticated than the jenkins cancellation feature. Under jenkins it would simply kill the process, but the bileto cancellation is more polite and requests the process to shutdown, which it does only at certain safe points. In particular, once the job begins uploading packages to the PPA, the cancellation requests will be ignored, so it should not be possible to cancel uploads halfway through uploading and get an inconsistent PPA as a result. Cancelling is however possible throughout the merging and source build stages of the build job, which takes up most of the time. If you realize you need to cancel a build, best be quick on that cancel button! The average run time for the build job is just 3 minutes and 18 seconds. As always, please do let me know if you have any troubles with this or anything else at ci-train.ubuntu.com. -- robru -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] IMPORTANT: Note about changelogs
On Thu, Jun 2, 2016 at 6:55 PM, Robert Park wrote: > TL;DR: Bileto is currently unconditionally forcing all MP Commit > Messages into the changelog, so leave that field blank if your branch > supplies it's own changelog. TL;DR: Bileto has been fixed to ignore the MP Commit Message when a manual debian/changelog entry is supplied, please inform me ASAP if you see any unexpected results in your debian/changelogs. Thanks! -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] ANNOUNCEMENT: Changes to how Britney runs on Bileto tickets / CI Train Silos
Hi, I noticed recently that it was taking approximately 80 minutes for britney to churn through all the silos, so I've made a simple change to speed things up: >From now on, if a ticket has been approved either by britney or by qa, britney will no longer inspect that silo. This has been in production for a couple hours and already the britney run time is down to about 19 minutes, so that's a big win. The only drawback is that if you believe britney has approved your ticket by mistake, it'll be "stuck" in the approved state and you'll have to clear & reset your lander signoff in order to clear the britney signoff for it to re-process your silo. I don't expect this to happen very often but it's theoretically possible. Please do let me know if you're seeing unexpected results in your excuses files. -- robru -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] CI Train / Bileto offline
Alright we are now back online. On Jun 7, 2016 10:45 AM, "Robert Park" wrote: > Hi all, > > Canonical is currently experiencing a major outage which has taken > bileto offline, in addition to many other services. > > IS is aware of the issue and working on a fix. > > Apologies for the inconvenience. > > -- > robru > -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] CI Train / Bileto offline
Hi all, Canonical is currently experiencing a major outage which has taken bileto offline, in addition to many other services. IS is aware of the issue and working on a fix. Apologies for the inconvenience. -- robru -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] ANNOUNCEMENT: Phasing out xenial+vivid silos.
It's come to my attention that there are 20 silos that are still xenial+vivid "dual" silos, which were never converted into yakkety+xenial+vivid "trio" silos when those became available. This configuration ceased being supported on May 19th (when yakkety was enabled in Bileto), and was only left around to ease people's transition to yakkety, eg, so not everybody was forced to transition immediately. Anyway, it's been two weeks now, and everybody should be building for yakkety at this point, which is the development focus of Ubuntu. To this end I've now added a check that prevents bileto from building xenial+vivid silos. For those of you who still have xenial+vivid silos that you're developing, you'll need to change the series to yakkety+xenial+vivid in order to perform any more builds on your silo. Hopefully this isn't too disruptive for anybody, but at least we're early in the OTA cycle so people shouldn't be rushing to get their builds out the door. -- robru -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] IMPORTANT: Note about changelogs
Hi guys, TL;DR: Bileto is currently unconditionally forcing all MP Commit Messages into the changelog, so leave that field blank if your branch supplies it's own changelog. So with the big rollout a couple days ago I've been keeping a close eye on the builds and seeing what's happening. One thing I'm seeing is a lot of duplicate changelog entries, like this: + * New upstream release +- blah +- blah + * New upstream release What's happening here is that the input MP writes it's own debian/changelog, but then also supplies a commit message on the MP, so when building it calls dch with the MP commit message, adding a duplicate changelog entry to what was already there. I realize this is a regression from the previous behavior which was able to not duplicate messages in this way, so I'll work on fixing this. For now, however, as a workaround please leave the "Commit Message" field on your merge proposal empty, if you've written your own debian/changelog. When you leave the commit message field blank, bileto (and the old train code) use debcommit to commit your branch, which reads the message from debian/changelog and makes the bzr commit from that (debcommit was always a supported feature, it's just that now bileto is getting confused when MPs supply both a commit message and a debian/changelog entry). Apologies for the inconvenience! -- robru -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] [Bileto-announce] ANNOUNCEMENT: short CI Train outage & big rollout
On Wed, Jun 1, 2016 at 6:55 AM, Marco Trevisan
wrote:
> Il 31/05/2016 23:06, Robert Park ha scritto:
>> * Totally new debian/changelog generation
>
> It seems it doesn't take care of rebuilds now, so rebuilt packages
> aren't properly sent to the PPA again.
Ah yes, apologies, there was a minor bug in the version generation
code that prevented it from incrementing the version properly, this is
now fixed!
> In the mean time, people can still rebuild using jenkins by (thanks
> dobey for the tip!) going at
> https://ci-train.ubuntu.com/job/ubuntu-landing-${SILO}-1-build/build
Ok, it should no longer be necessary to use the old style jobs, if
you're still using those please tell me why. That will be discontinued
in a few days.
--
robru
--
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] ANNOUNCEMENT: short CI Train outage & big rollout
Alright, this is live and looking good! Please do not hesitate to ping me on IRC if you have any questions or problems. Thanks! On Tue, May 31, 2016 at 2:06 PM, Robert Park wrote: > This is to inform you that the CI Train will be taken offline at UTC > 01:00 (that is, 4 hours from now) in order to roll out new features. I > expect the outage to last 1 to 2 hours. > > This is a BIG rollout with many bug fixes and features, here are some > of the highlights: > > * Source package build parallelization, allowing source packages to be > prepared & uploaded to the PPA in parallel, for which you should see > dramatic speedups for silos containing 2 or more source packages. > Particularly large silos (*cough* Timo, *cough*) become I/O bound and > will only see a small speedup. Silos containing a handful of "small" > packages should see the largest speedup. In my testing I've seen silos > branch, merge, build source, upload, and diff in just 3 minutes. > > * First step of jenkins replacement. The build job now no longer runs > in Jenkins but runs directly inside Bileto. This provides a > significantly nicer interface (no more of that pesky "I clicked Build > but nothing happened because the Build button redirected through SSO > and dropped me back at the build form" bug, at least for building. > other jobs will come in the next iterations). > > * No git support yet, but the aforementioned parallelization also > brings with it an encapsulation layer around bzr that should make git > support much easier to add in the coming months. > > * Totally new debian/changelog generation, for those of you who have > complained about your debian/changelogs recently, it is now guaranteed > that the debian/changelog will match exactly the commit messages of > the input MPs (previously there were some weird corner cases causing > strange changelogs that have now been eliminated). > > * Build logs will now explicitely tell you what order your MPs will be > merged in (as this can sometimes differ from the order you specify in > the ticket), as well as more specifically tell you exactly the > destination that each package is targetted at, as some people have > complained that this was unclear in the past. > > * MP field on the ticket now supports comments, so eg, if you want to > disable an MP temporarily, you can prefix it with '#'. You can also > write arbitrary comments this way, eg you can prefix a block of MPs > with a header like "# foo feature" to make it more clear what you're > doing with your MP list, which in some cases can get quite large. > > * probably lots of other fun things you'll discover as you go. > > > > As usual, a rollout this large carries with it some risk of > regressions, so please do inform me at the first sign of trouble and > I'll do my best to make sure everything goes smoothly for everybody. > I've timed this rollout for early in the OTA cycle so nobody should be > in that last-second release rush at least. > > Thanks! > > -- > robru -- robru -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] ANNOUNCEMENT: short CI Train outage & big rollout
This is to inform you that the CI Train will be taken offline at UTC 01:00 (that is, 4 hours from now) in order to roll out new features. I expect the outage to last 1 to 2 hours. This is a BIG rollout with many bug fixes and features, here are some of the highlights: * Source package build parallelization, allowing source packages to be prepared & uploaded to the PPA in parallel, for which you should see dramatic speedups for silos containing 2 or more source packages. Particularly large silos (*cough* Timo, *cough*) become I/O bound and will only see a small speedup. Silos containing a handful of "small" packages should see the largest speedup. In my testing I've seen silos branch, merge, build source, upload, and diff in just 3 minutes. * First step of jenkins replacement. The build job now no longer runs in Jenkins but runs directly inside Bileto. This provides a significantly nicer interface (no more of that pesky "I clicked Build but nothing happened because the Build button redirected through SSO and dropped me back at the build form" bug, at least for building. other jobs will come in the next iterations). * No git support yet, but the aforementioned parallelization also brings with it an encapsulation layer around bzr that should make git support much easier to add in the coming months. * Totally new debian/changelog generation, for those of you who have complained about your debian/changelogs recently, it is now guaranteed that the debian/changelog will match exactly the commit messages of the input MPs (previously there were some weird corner cases causing strange changelogs that have now been eliminated). * Build logs will now explicitely tell you what order your MPs will be merged in (as this can sometimes differ from the order you specify in the ticket), as well as more specifically tell you exactly the destination that each package is targetted at, as some people have complained that this was unclear in the past. * MP field on the ticket now supports comments, so eg, if you want to disable an MP temporarily, you can prefix it with '#'. You can also write arbitrary comments this way, eg you can prefix a block of MPs with a header like "# foo feature" to make it more clear what you're doing with your MP list, which in some cases can get quite large. * probably lots of other fun things you'll discover as you go. As usual, a rollout this large carries with it some risk of regressions, so please do inform me at the first sign of trouble and I'll do my best to make sure everything goes smoothly for everybody. I've timed this rollout for early in the OTA cycle so nobody should be in that last-second release rush at least. Thanks! -- robru -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] [Bileto-announce] ANNOUNCING: Trio silos!
On Thu, May 19, 2016 at 11:29 AM, Olivier Tilloy wrote: > So all dual silos currently in the QA queue need to be rebuilt, > re-validated by their owners, and put in the QA queue again? > An advance notice would have been welcome. Apologies for that. Anything that is currently being validated by QA can perhaps have a manual exception, where a core dev would need to manually copy xenial and vivid binaries to overlay PPA and then also copy the xenial version to yakkety. This is unfortunately not supported by the train itself however so you'll have to negotiate that with a core dev (perhaps lukasz since he's doing the xenial overlay copy to yakkety anyway). Unless you're at the top of the QA queue it's best to just switch to trio and rebuild. -- robru -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] ANNOUNCING: Trio silos!
On Thu, May 19, 2016 at 9:43 AM, Robert Park wrote: > so if you currently have any active dual > silos, you need to edit your ticket, switch to yakkety+xenial+vivid > and rebuild. To clarify, switching to trio silos is *required* before publishing. Publishing an old dual silo will not work, as the xenial half will be treated as an SRU, which isn't what you want. xenial+vivid is considered deprecated and must all be switched to yakkety+xenial+vivid. Also there appears to be a small glitch where the auto-version-number magic isn't choosing a high enough version number for the uploads to be accepted to the PPA. This won't affect anybody but will affect xenial+vivid silos that were built during UTC today. You might have to rebuild a couple times for the auto generated version number to "catch up" to where it was before, or you can wait for UTC tomorrow (just a few hours from now), and it'll also sort itself out then. -- robru -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] ANNOUNCING: Trio silos!
Hi everybody! We've just enabled TRIO silos in Bileto. What this means: * All new "dual" landings are now trio landings: yakkety, xenial, and vivid. * All existing dual landings will stay as xenial+vivid (eg they are not automatically converted), so if you currently have any active dual silos, you need to edit your ticket, switch to yakkety+xenial+vivid and rebuild. We are hoping that xenial enablement goes quickly and smoothly so that we may drop vivid ASAP however for the time being we will be doing trio landings. If anything at ci-train.ubuntu.com or requests.ci-train.ubuntu.com goes wrong please report issues directly to me! Thanks! -- robru -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] CALL FOR TESTING: New parallelized build job.
On Sat, May 14, 2016 at 6:02 PM, Robert Park wrote: > On May 14, 2016 5:01 PM, "Marco Trevisan" > wrote: >> >> > 6. Inspect https://code.launchpad.net/~untrusted-ci-dev-bot to see if >> > the resulting source package has the contents you expected. >> >> I've given this a try, and it seems to work quite well... However, >> there's also another issue you didn't mention as known: the generated >> changelogs don't include the LP: #xx numbers with the bugs fixed by >> a given MP. Thanks again for pointing this out, I believe I've fixed the issue, can you double-check that this meets your expectations? https://code.launchpad.net/~untrusted-ci-dev-bot/ Also, to anybody else reading this, please do try out a build or two in the new system: https://requests.ci-train.staging.ubuntu.com/ Thanks! -- robru -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] CALL FOR TESTING: New parallelized build job.
Wow, thanks for this feedback on a Saturday ;-) Do you have the same branches in production so you can show me the expected changelog entries? Thanks! On May 14, 2016 5:01 PM, "Marco Trevisan" wrote: > > 6. Inspect https://code.launchpad.net/~untrusted-ci-dev-bot to see if > > the resulting source package has the contents you expected. > > I've given this a try, and it seems to work quite well... However, > there's also another issue you didn't mention as known: the generated > changelogs don't include the LP: #xx numbers with the bugs fixed by > a given MP. > > -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] CALL FOR TESTING: New parallelized build job.
Hi everybody! I've been working on some experimental changes in Bileto, and I'd like to get some early feedback before forcing these changes on everybody in the next week or so. In the staging instance, I have a quite large experimental refactoring of the train code, with a number of advantages: * builds are now parallelized instead of serialized, which means source packages can be built & uploaded much faster than they currently are. By rough estimation, a silo with a few packages in it might have taken 20 minutes to build source packages before, now it takes just a couple minutes. * bzr knowledge is being encapsulated in a way that will make it easy to implement git support later (yes, sadly, git support is still not here, but this is a step in that direction) * jenkins is being replaced, so no more stupid issues with clicking 'build' and then nothing happens because the button just redirected you through SSO and back without actually triggering the build, among many more jenkins-isms being nuked from orbit. for now only the build job is replaced, the others remain. So if you are a user of requests.ci-train.ubuntu.com, please help me find regressions by doing these quick steps for me: 1. Visit https://requests.ci-train.staging.ubuntu.com/ and sign in with SSO 2. Create a new request and put some MPs in it 3. Click 'Assign' and run that jenkins job as per usual 4. Click 'Build' and marvel at the new Bileto job page, then run that too 5. Observe the console output and make sure nothing explodes, and then at the end observe the low, low build times. 6. Inspect https://code.launchpad.net/~untrusted-ci-dev-bot to see if the resulting source package has the contents you expected. 7. Check back later to see if your binary packages built successfully or not. Note that packages built this way are not actually releasable to ubuntu, so your help here is purely a selfless effort to find bugs in bileto. You're so kind! Thank you! Here's an example of a simple one I grabbed from production: https://requests.ci-train.staging.ubuntu.com/log/1170/build/1 92 seconds to build, upload, and diff yakkety, xenial, and vivid copies of ubuntu-system-settings! Blazing fast! KNOWN ISSUES: * the staging version of the stable-phone-overlay ppa is woefully incomplete and so most vivid builds are expected to fail and generated diffs will be much larger than you expect. * the feature where it automatically detects new commits is sadly missing, this is because the code that does that detection hasn't been ported over yet, but once I get this rolling, restoring that feature will be my top priority. * builds can't be cancelled, but I suspect that they happen so quickly now that cancelling them isn't really terribly feasible. let me know if I'm wrong about this. Also, friendly reminder, please subscribe to bileto-announce list if you are a regular user of requests.ci-train.ubuntu.com, as I will sooner or later phase out posting updates to ubuntu-phone list. Thanks! https://launchpad.net/~bileto-announce -- robru -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] IMPORTANT: Changes to CI Train / Bileto announcements.
Hi all, Due to high email volumes on ubuntu-phone mailing list, I'm creating a new list strictly for train / bileto announcements, which includes important updates that you'll need to know for the continuing operation of ci-train.ubuntu.com and requests.ci-train.ubuntu.com. Please join this team & subscribe to it's ML: https://launchpad.net/~bileto-announce I expect volume to be quite low, perhaps 1 to 2 mails per month. Thanks! -- robru -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] ANN: CI Train dual-landings now targeting vivid-overlay and xenial-overlay
On Apr 11, 2016 1:33 PM, "Stephen M. Webb" wrote: > > On 16-04-11 04:08 PM, Łukasz 'sil2100' Zemczak wrote: > > > > With xenial nearing Final Freeze (this week), we will be shortly > > switching dual landings to target the stable-phone-overlay PPA for both > > the xenial and vivid part in the CI Train. Robert has the branch ready > > and will be deploying it in the nearest time. > > Along with this we'll also be enabling the landing-team-changes+1 [1] > > mailing-list for xenial-overlay landings. > > How does this work with the Y archives not yet opened? As of now, when a dual silo is published, both the xenial and vivid packages are copied into the overlay PPA. Once y series is opened then we will manually copy xenial overlay packages into y. If you are working on a silo that really does need to be released to real xenial archive, you can either use a xenial-only silo, or find a core dev and ask them nicely to copy your xenial packages from your dual silo to xenial-proposed for you. -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] ACTION REQUIRED: Big CI Train changes just around the corner!
This change is now live, and I've submitted branches that fix unity8, unity-scopes-api, unity-scopes-shell, and mediascanner2. If you have a train silo with one of those packages in it that's already built, that's fine to leave as is, but you will need to include my branch in the event of a rebuild, otherwise your vivid packages will not build correctly. Pay attention to the build logs, if you have an affected source package you'll see this warning in the build log: WARNING! Found override_dh_auto_clean but not bileto_pre_release_hook defined in this package. "./debian/rules clean" is no longer called during source package builds! If you have code you need to be run prior to the source package build, you must create a new script: ./debian/bileto_pre_release_hook If you see this message in your build logs, notify me immediately and I'll work with you to bring your package up to the new standards. Thanks. On Mon, Mar 21, 2016 at 1:00 PM, Robert Park wrote: > The vast majority of packages should be unaffected by this, however if > you are using the debian/rules clean target in order to modify your > debian/control file prior to source package build (which is an > officially supported CI Train feature), you'll need to stop using > debian/rules and start using a special hook script which we've created > for this purpose. -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] ACTION REQUIRED: Big CI Train changes just around the corner!
Hi everybody! In a few days I will be rolling out a big change to the way CI Train builds source packages, however this change is not compatible with all source packages and some may require changes in order to remain compatible with the new behavior. The change is that the train will no longer install build dependencies and run "debian/rules clean" during the *source* package build (these will of course still be run in the PPA during binary package build), which will dramatically reduce the time it takes to build source packages in the train, allowing people to iterate on their silo builds more rapidly (one test reduced source package build time from 100 minutes to 35 minutes on a large silo). The vast majority of packages should be unaffected by this, however if you are using the debian/rules clean target in order to modify your debian/control file prior to source package build (which is an officially supported CI Train feature), you'll need to stop using debian/rules and start using a special hook script which we've created for this purpose. So far I'm aware of unity-scopes-api and unity8 being affected by this change, however I've already submitted branches fixing those ones. If you believe your source package is affected by this change, please contact me and I'll get your code up to speed. Here are example MPs showing what the new hook script looks like: https://code.launchpad.net/~robru/unity8/pre_release_hook/+merge/289550 https://code.launchpad.net/~robru/unity-scopes-api/vivid-tweaks/+merge/288865 In short: You need a new script, debian/bileto_pre_release_hook, which will be called with $PWD set as your source tree root (not the debian/ dir), and no arguments. If you want to do different things depending on what ubuntu release you are building for, the environment variable $SERIES will be set to the name of the release, eg, "vivid". -- robru -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] ANNOUNCEMENT: change to CI train artifacts
Hi all, I'm excited to announce the next step in our march away from Jenkins: Build artifacts (packaging diffs and full content diffs) are now uploaded to swift rather than being stored in Jenkins. What this means for you: When looking at your ticket in bileto, the "artifacts" field will now* contain direct links to the diff files rather than a link to the Jenkins job page which contains the file. One less click to get to the diffs! If you run into any problems please let me know right away, and if your Jenkins build log shows any swift-related errors try running a DIFF_ONLY build to regenerate the diffs and reupload to swift. There will be a transitional period during which the artifacts appear both in Jenkins and swift but if all goes well I'll be dropping the Jenkins artifacts entirely within a week or two. * "now" meaning "for all future builds". Silos built before today will still show the link to Jenkins -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] Low on silos -- please consider freeing if you're not using yours
Hi everybody! Here are some lonely silos that look forgotten about, I'd appreciate it if the owners could take a look and possibly free them if they aren't needed anymore: These ones have been "Needs rebuild" for over a week: https://requests.ci-train.ubuntu.com/#/ticket/692 jonas-drange https://requests.ci-train.ubuntu.com/#/ticket/764 mzanetti Failed to build since December 2nd: https://requests.ci-train.ubuntu.com/#/ticket/737 mterry Assigned December 18th and then was never built: https://requests.ci-train.ubuntu.com/#/ticket/804 dbarth alex-abreu Last built over a week ago: https://requests.ci-train.ubuntu.com/#/ticket/866 michael-sheldon https://requests.ci-train.ubuntu.com/#/ticket/880 bfiller artmello https://requests.ci-train.ubuntu.com/#/ticket/763 timo-jyrinki zsombi kalikiana https://requests.ci-train.ubuntu.com/#/ticket/720 diwic Thanks everybody! -- robru -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] ANNOUNCEMENT: CI Train Changes (Britney Phase 2)
Apologies, there's been a minor glitch in the transition. In a few cases, the 'Britney Signoff' field has been filled with a stale value from the britney results of the ticket that was in your silo before you. If you're looking at your ticket, and you see 'Lander Signoff' is blank, 'Bileto Signoff' has any value (Running/Approved/Failed), and the 'Autopkgtest Results' field contains links to excuses.html files that 404, you should just ignore it. It should sort itself out once you set 'Lander Signoff' to 'Approved' and britney does a fresh run. Please notify me if you set 'Lander Signoff' to 'Approved' and still see weird results more than an hour later. Thanks! On Wed, Jan 13, 2016 at 1:43 PM, Robert Park wrote: > Hello! Exciting news! > > I've just rolled out Phase 2 of the Britney implementation within the CI > Train. > > What does this mean? > > It means that all train silos **MUST** be approved by Britney before > they can be entered into the QA queue. If your package has > autopkgtests, it means autopkgtest regressions are discovered BEFORE > we waste QA's time verifying a silo. There are other checks, too, in > addition to autopkgtests. Essentially we are running packages through > proposed-migration first, then doing human QA second. > > There are some fun changes to watch out for in the Bileto UI: > > * "QA Signoff" has been split into three separate fields: "Lander > Signoff", "Britney Signoff", and "QA Signoff". The intended workflow > looks like this: > > 1. You create a ticket, and you assign & build it yourself. You test > it yourself and make sure it works to your satisfaction. Once you're > happy, you set Lander Signoff to "Approved". > > 2. When Lander Signoff is "Approved", britney takes over and runs your > autopkgtests. The "Britney Signoff" field will indicate either > Running, Failed, or Approved (if it's blank that means it didn't start > yet, I expect it should start within 30 minutes of setting Lander > Signoff to Approved) > > 3. If and only if Lander Signoff and Britney Signoff are both > Approved, *then* QA Signoff is automatically set to 'Ready' and QA > people will be notified to verify your silo. > > 4. Once all three signoffs are Approved, the silo can be published. > > > * It's now possible to modify the Lander Signoff and QA Signoff fields > "live", eg, without having to click edit / change the signoff / click > save. I hope everybody enjoys the reduction in clicking ;-) > > * I reversed the sort order of the audit logs, those messages are now > newest-first. I did this because some of them were getting mighty long > and the newest info was most relevant so it made more sense to see it > first. > > As usual if there's any problems please don't hesitate to message me, > also if you need help interpreting the "excuses" page, a good person > to talk to is Martin Pitt. > > Thanks everybody! Enjoy! > > > -- > robru -- robru -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] ANNOUNCEMENT: CI Train Changes (Britney Phase 2)
Hello! Exciting news! I've just rolled out Phase 2 of the Britney implementation within the CI Train. What does this mean? It means that all train silos **MUST** be approved by Britney before they can be entered into the QA queue. If your package has autopkgtests, it means autopkgtest regressions are discovered BEFORE we waste QA's time verifying a silo. There are other checks, too, in addition to autopkgtests. Essentially we are running packages through proposed-migration first, then doing human QA second. There are some fun changes to watch out for in the Bileto UI: * "QA Signoff" has been split into three separate fields: "Lander Signoff", "Britney Signoff", and "QA Signoff". The intended workflow looks like this: 1. You create a ticket, and you assign & build it yourself. You test it yourself and make sure it works to your satisfaction. Once you're happy, you set Lander Signoff to "Approved". 2. When Lander Signoff is "Approved", britney takes over and runs your autopkgtests. The "Britney Signoff" field will indicate either Running, Failed, or Approved (if it's blank that means it didn't start yet, I expect it should start within 30 minutes of setting Lander Signoff to Approved) 3. If and only if Lander Signoff and Britney Signoff are both Approved, *then* QA Signoff is automatically set to 'Ready' and QA people will be notified to verify your silo. 4. Once all three signoffs are Approved, the silo can be published. * It's now possible to modify the Lander Signoff and QA Signoff fields "live", eg, without having to click edit / change the signoff / click save. I hope everybody enjoys the reduction in clicking ;-) * I reversed the sort order of the audit logs, those messages are now newest-first. I did this because some of them were getting mighty long and the newest info was most relevant so it made more sense to see it first. As usual if there's any problems please don't hesitate to message me, also if you need help interpreting the "excuses" page, a good person to talk to is Martin Pitt. Thanks everybody! Enjoy! -- robru -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Find out if running on a phone
But dynamically changing between a desktop and a phone doesn't make, eg, the accelerometer appear and disappear. So if you have code that says "if phone: use accelerometer", can you see how broken that is? Plugging in a screen and keyboard will effectively disable your accelerometer, because your code assumes desktops don't have those. You should absolutely not be writing code that makes assumptions about what features desktops have or what phones have. You need to detect the feature itself and use it if you have it. On Jan 11, 2016 12:08 PM, "Lorn Potter" wrote: > > > On 12/01/16 05:35, Robert Park wrote: > >> But the point is that you can't have coffee that says "if desktop: x; if >> phone: y" because it can change at any time and you can't rely on that. >> > > Yes this desktop/phablet mode thing would be dynamic. It can change at any > time, which is why it needs to be detected dynamically. > > When you connect bt keyboard & external display, phone is now in desktop > mode. When you flip back your laptop's touchscreen, it's it now phablet > mode. It already does the first one except there is no API to let > developers know for certain what mode it is in. > > >> **MUCH** better user experience if you do feature detection, eg "if >> push_notifications_available: enable_push_notifications()", this way >> they work everywhere they exist, rather than trying to guess whether or >> not they exist by making assumptions about what is a "phone" vs what is >> a "desktop". >> >> > It really depends on what you are doing. > > We can either provide an API to do so or developers will try and guess > these things on their own. > -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Find out if running on a phone
On Jan 11, 2016 11:29 AM, "Lorn Potter" wrote: > > > > On 12/01/16 04:56, Stephen M. Webb wrote: >> >> On 16-01-11 01:26 PM, Lorn Potter wrote: >>> >>> >>> imho, we need some way that contained apps know if the device is desktop or phablet mode, which I assumed the QInputInfo >>> API was helping to detect. Right now, phablet mode becomes desktop mode when adding a bluetooth keyboard. Where as it >>> probably should be keyboard + external display on small display, because windowed mode on small screen is horrible to use. >> >> >> We need contained apps to be written in such a way that they don't need to know if they are on a phone, tablet, a >> laptop, or a desktop. They should only need to know that they have a certain size of display surface to render to. >> >> Yes, there are exceptions for things that need certain hardware. A step counter needs an accelerometer, for example. >> Just the like one I have in my Lenovo Yoga 2 Pro laptop. Detecting available codecs in a gstreamer pipeline might also >> qualify. None of these are phone/desktop checks, they're checks for available system functionality. *Thats* where >> solutions need to live, not in an unreliable and poorly-defined proxy like "form factor." > > > Form factor is the basis for how we use and interact with these things. > This review even points out use cases for desktop/phablet mode, detected in part with the accelerometer (yay!): > http://www.theverge.com/2014/2/5/5377754/lenovo-yoga-2-pro-review > > >> >> There is just no such thing as a phone or a desktop as separate entities. > > > Maybe not below the UI, but the UI sure needs to be different. In this respect they are different, in the least to the user. > > > I can turn my phone into a desktop at any >> >> time, and I have laptops I can turn into a tablet at any time. There is only one Ubuntu Personal. >> > > I think you just argued for having phablet/desktop mode and a need to detect it, otherwise your phone would already just be a desktop and would not need to 'be turned into' one. It's a dynamic thing. and it's because there is only one Ubuntu Personal that we need mode detection to allow developers to optimize their apps for the different use cases of different form factors. But the point is that you can't have coffee that says "if desktop: x; if phone: y" because it can change at any time and you can't rely on that. **MUCH** better user experience if you do feature detection, eg "if push_notifications_available: enable_push_notifications()", this way they work everywhere they exist, rather than trying to guess whether or not they exist by making assumptions about what is a "phone" vs what is a "desktop". -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Find out if running on a phone
Ah, i thought you were working on a system service, didn't realize it would be confined. I wouldn't make the assumption that confined processes are necessarily running in the phone as i believe the convergence plan is to have confined apps on the desktop. Aside from that, i would just try to do whatever it is you're trying to do and then catch the failure as gracefully as possible when it fails on the phone, if you can. Better to ask forgiveness than permission ;-) On Jan 10, 2016 8:16 PM, "Michi Henning" wrote: > > On 11 Jan 2016, at 14:12 , Robert Park wrote: > > Pardon my ignorance, buy can you not just check which codecs are > installed/in use and then make the right decisions based on that? It is a > really bad practice to write code that says "desktops be like this while > phones be like that" because you never know when one day a new device might > come along that shatters your expectations. > > Feature detection > device detection > > I agree with the sentiment. But how would I, from a confined process, work > out what’s installed? I won’t even be allowed to look there. > > I guess I can conclude that, if I’m not allowed to look, I’m confined. > And, if I’m allowed to look, use what I can see. But it also seems a very > round-about way of figuring this out. > > The real question actually is “If I thumbnail from an audio or video file, > will I be using the android/hybris hardware codecs or a software codec?” > > But there is no API for that either, as far as I know. > > Michi. > -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Find out if running on a phone
Pardon my ignorance, buy can you not just check which codecs are installed/in use and then make the right decisions based on that? It is a really bad practice to write code that says "desktops be like this while phones be like that" because you never know when one day a new device might come along that shatters your expectations. Feature detection > device detection On Jan 10, 2016 7:58 PM, "Michi Henning" wrote: > > Right... forgot that it's a gerrit MR, not Launchpad: > > https://codereview.qt-project.org/#/c/101049/ > > > Thanks for that! > > I just had a look at > https://codereview.qt-project.org/#/c/101049/15/src/systeminfo/qinputinfo.h > > But this requires an input to then find out what the source was (mouse, > touch screen, etc.). > > I need to know whether I’m running on touch or on the desktop, without any > input events. > > Any other ideas? Is there some place in the filesystem I could look at, or > test some env var or whatever? > It has to work under confinement though. > > Thanks, > > Michi. > > -- > Mailing list: https://launchpad.net/~ubuntu-phone > Post to : ubuntu-phone@lists.launchpad.net > Unsubscribe : https://launchpad.net/~ubuntu-phone > More help : https://help.launchpad.net/ListHelp > > -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] ANNOUNCEMENT: New train features!
Hi guys! During the break I had a chance to fix some papercuts in Bileto, which I've only just rolled out today, so next time you use it you might notice a couple things: 1. It now has a rudimentary input validation in the client side, so if you put in bad inputs (in particular if you try to put a branch in the MPs field), it will light up in pink and prevent you from saving the request. This should hopefully save you a bit of frustration of submitting invalid inputs and then only finding out later on when jenkins doesn't do what you expect. 2. When editing requests, only modified fields are submitted through JSON rather than resubmitting the whole request, which means it's now possible for two people to edit different fields on the same request at the same time and not get into "revert wars" unless you're both editing the same field. This probably isn't a huge deal for most people but in the event that the request status changes while you have the edit screen open you'll no longer see "Updated status" in the audit log, which was caused by you reverting the automatically-set status with your edit. 3. Speaking of the audit log, newly created "Updated foo, bar" messages will now be hidden just like the links to the jenkins jobs, which means the comment area now only displays hand-written human comments, which should make it less cluttered and easier to read. Just click 'Show Audit Log' to reveal all the recorded activity on the ticket. (older "Updated..." comments will still remain visible and haven't changed, this change only affects newly created ones) As always, I'm happy to iterate on your feedback, so let me know what's working for you and what isn't! Happy new year! -- robru -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] ATTENTION: requests.ci-train.ubuntu.com going offline briefly for a hardware upgrade.
So Bileto (aka requests.ci-train.ubuntu.com) is gaining some exciting new features that require a beefier VM to run, so it will be taken offline briefly and redeployed with more CPU, more RAM, and more HD space. I expect the outage to last only 30 minutes, and should begin shortly. Apologies for any inconvenience! -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] ANNOUNCEMENT: Happy American Thanksgiving! I'm thankful for... new CI Train features! ; -)
I've now updated the train logs to indicate where the POINT OF NO RETURN is, so watch for that in your next builds ;-) -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] ANNOUNCEMENT: Happy American Thanksgiving! I'm thankful for... new CI Train features! ; -)
Hi everybody! Hope everybody enjoyed their Turkey. While you were away, I did a fun little train feature! Train builds are now cancellable! Well, you could cancel them before, but the difference is that now there's a decent chance that cancelling the job won't destroy the silo! Previously, the first thing the build job would do is delete all it's state and start your build fresh. This meant that if you cancelled the build, the silo would be left without any state, and you'd be forced to rebuild anyway in order to get the train back into a good state. Now, the train prepares source packages in a temporary directory, and only clears the previous state towards the end of the job. So this means that if you cancel the job, the previous state is preserved and the half-built packages are discarded. The only catch is that the previous state is discarded at the point where package branches are pushed to launchpad. So cancelling the build job towards the end can still put the silo into an inconsistent state. But if you're looking at your build log and the last line of the log is at or before "Building foobar source package.", it is totally safe to cancel the job at that point. Fortunately that is by far the longest and slowest part of the build job, so by my rough estimation, the job is safe to cancel during the first 90% of the time it is running. Enjoy! -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] BlueZ 5.x finally landed on Touch
On Nov 20, 2015 8:29 AM, "Simon Fels" wrote: > > Hey everyone, > > it finally happened: We are switching to BlueZ 5.x on our Touch images on all supported devices. To make this happen a huge amount of work through the last five months from different people was needed. Thank you all for the great work and support to make this happen! Wow, congrats! > > This is just a first step for better Bluetooth support on Ubuntu Touch. We now have the same bluetooth stack in the kernel on all our devices which makes it a lot easier to fix bugs at the same time across all our devices. Does this mean we can finally stop using an ancient kernel in the touch stack? -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] ANNOUNCEMENT: CI Train Status Reporting Changes
On Wed, Nov 18, 2015 at 10:05 AM, Robert Park wrote: > Hopefully that isn't too confusing! I can iterate on this if people > have difficulty interpreting the results, and as usual if you find any > issues in general please let me know immediately! Well as usual there's some sneaky corner cases that I didn't discover in my testing, it looks like some silos are falsely reporting "destination version changed" for some packages due to a bug in the way that information was being recorded. The good news is that we're discovering this now rather than when trying to publish ;-) I'm working to resolve these cases, but I may miss some, as it's a bit tricky to discern a false positive from a real result. If your silo status contains "Destination version changed from X to Y" and it doesn't make sense to you, please contact me and I'll take a look. -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] ANNOUNCEMENT: CI Train Status Reporting Changes
Hi everybody! In a few moments I'll be rolling out a major change to the way CI Train reports it's silo status. Put simply, the train will become much more verbose/accurate about the state that silos are in, and get much better about detecting problems sooner rather than having surprises later. In general, you can keep using the train the same way you always have. There's no UI changes today. But there are a lot of bugs fixed! * The bug where you can no longer un-dirty a silo by uncommitting new commits on your MPs is resolved; if you push new commits the train will detect that and indicate that a package needs to be rebuilt, and if you uncommit those commits the train will detect that also and go back to indicating the previous status. * Many publish-time checks are now being run on a timer so you can learn about problems well before you go to publish the silo. No more surprises when you click publish! * No more premature marking silos as dirty. Previously, if one silo was published, it would mark conflicting packages dirty with a big scary message saying "you must rebuild!", but if you rebuilt right when that message popped up, it didn't actually fix the problem! This is because you have to wait for the other silo to merge before a rebuild actually resolves the conflict. I noticed this was causing a lot of people to do pointless rebuilds prematurely, so I've eliminated this. Now when you publish a conflicting silo, the other silos will notice that there's a new upload at dest, but won't say "you must rebuild" until there are actually new commits on the trunk branch for you to incorporate. * If your silo has multiple dirty packages and you only rebuild one of them, the resulting status will explicitly tell you that the new build succeeded, which is a big improvement over the old behavior of just saying the one you weren't even building is still dirty, leaving you to assume that the other was successful by a lack of error message. So generally speaking you can look forward to train statuses that more accurately and verbosely reflect the state the silo is in. The only downside is that the new statuses are a little bit information-dense, particularly with silos that have a lot of packages. Typically speaking most of the packages in a silo will all be in the same state (all built, or all in proposed), so instead of repeating the same message multiple times, I've condensed redundant messages. So a typical status may now look like this: Successfully built [amd64 i386 armhf] (foo/xenial, foo/vivid, bar/xenial, bar/vivid) This means that packages foo and bar, in both xenial and vivid, and on all the listed arches, has built successfully. If there's a build failure on a single arch, it would look like this: Failed to build [amd64] Successfully built [i386 armhf] (foo/xenial). Successfully built [amd64 i386 armhf] (foo/vivid, bar/xenial, bar/vivid) Hopefully that isn't too confusing! I can iterate on this if people have difficulty interpreting the results, and as usual if you find any issues in general please let me know immediately! Have a great day! -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] WARNING: CI Train "force merge" ability will be going away...
I've noticed recently that some people are force merging silos in order to ignore problems with xenial-proposed migration while continuing development in vivid. This is a Very Bad Thing as it causes xenial to rot, without anybody paying attention or fixing it. I've discussed the issue with Steve, and we've decided to remove the ability for landers to force merge their own silos (only trainguards will be able to do this from now on). The force merge is largely just a holdover from the days before automatic merging was implemented, so this shouldn't really be a problem for anybody in practise. I'll probably roll out the change tomorrow, so if you feel this is a grievous mistake you have 24 hours to convince us otherwise. -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] OUT OF SILOS - Please free any you aren't using.
As of a few minutes ago we officially hit zero free silos. These people are hogging at least 3 silos: 8 https://requests.ci-train.ubuntu.com/#/user/timo-jyrinki 5 https://requests.ci-train.ubuntu.com/#/user/dbarth 4 https://requests.ci-train.ubuntu.com/#/user/saviq 4 https://requests.ci-train.ubuntu.com/#/user/pstolowski 4 https://requests.ci-train.ubuntu.com/#/user/morphis 3 https://requests.ci-train.ubuntu.com/#/user/tiagosh 3 https://requests.ci-train.ubuntu.com/#/user/seb128 3 https://requests.ci-train.ubuntu.com/#/user/mzanetti 3 https://requests.ci-train.ubuntu.com/#/user/boiko These silos are at least one day stale (build job last run over 24 hours ago): Thu 10 Sep 2015 04:36:10 PM UTC https://requests.ci-train.ubuntu.com/#/silo/ubuntu/landing-037 Thu 10 Sep 2015 04:36:10 PM UTC https://requests.ci-train.ubuntu.com/#/silo/ubuntu/landing-050 Tue 22 Sep 2015 01:26:12 AM UTC https://requests.ci-train.ubuntu.com/#/silo/ubuntu/landing-036 Tue 29 Sep 2015 11:42:26 AM UTC https://requests.ci-train.ubuntu.com/#/silo/ubuntu/landing-058 Wed 30 Sep 2015 03:16:43 PM UTC https://requests.ci-train.ubuntu.com/#/silo/ubuntu/landing-003 Fri 02 Oct 2015 03:21:40 PM UTC https://requests.ci-train.ubuntu.com/#/silo/ubuntu/landing-029 Wed 07 Oct 2015 08:21:00 PM UTC https://requests.ci-train.ubuntu.com/#/silo/ubuntu/landing-038 Thu 08 Oct 2015 01:29:20 PM UTC https://requests.ci-train.ubuntu.com/#/silo/ubuntu/landing-044 Tue 13 Oct 2015 01:05:41 PM UTC https://requests.ci-train.ubuntu.com/#/silo/ubuntu/landing-005 Wed 14 Oct 2015 04:30:03 AM UTC https://requests.ci-train.ubuntu.com/#/silo/ubuntu/landing-053 Wed 14 Oct 2015 08:57:03 AM UTC https://requests.ci-train.ubuntu.com/#/silo/ubuntu/landing-006 Thu 15 Oct 2015 08:35:01 PM UTC https://requests.ci-train.ubuntu.com/#/silo/ubuntu/landing-028 Fri 16 Oct 2015 08:12:01 AM UTC https://requests.ci-train.ubuntu.com/#/silo/ubuntu/landing-034 Fri 16 Oct 2015 10:22:46 AM UTC https://requests.ci-train.ubuntu.com/#/silo/ubuntu/landing-060 Tue 20 Oct 2015 02:55:03 PM UTC https://requests.ci-train.ubuntu.com/#/silo/ubuntu/landing-030 Thu 22 Oct 2015 06:06:56 AM UTC https://requests.ci-train.ubuntu.com/#/silo/ubuntu/landing-012 Thu 22 Oct 2015 06:16:02 AM UTC https://requests.ci-train.ubuntu.com/#/silo/ubuntu/landing-045 Thu 22 Oct 2015 05:53:38 PM UTC https://requests.ci-train.ubuntu.com/#/silo/ubuntu/landing-007 Fri 23 Oct 2015 10:58:37 AM UTC https://requests.ci-train.ubuntu.com/#/silo/ubuntu/landing-026 Fri 23 Oct 2015 11:13:08 AM UTC https://requests.ci-train.ubuntu.com/#/silo/ubuntu/landing-059 Fri 23 Oct 2015 02:28:05 PM UTC https://requests.ci-train.ubuntu.com/#/silo/ubuntu/landing-010 Fri 23 Oct 2015 03:13:08 PM UTC https://requests.ci-train.ubuntu.com/#/silo/ubuntu/landing-043 Tue 27 Oct 2015 04:20:52 PM UTC https://requests.ci-train.ubuntu.com/#/silo/ubuntu/landing-013 Wed 28 Oct 2015 02:43:01 PM UTC https://requests.ci-train.ubuntu.com/#/silo/ubuntu/landing-019 Wed 28 Oct 2015 03:56:28 PM UTC https://requests.ci-train.ubuntu.com/#/silo/ubuntu/landing-052 Wed 28 Oct 2015 08:01:57 PM UTC https://requests.ci-train.ubuntu.com/#/silo/ubuntu/landing-057 Fri 30 Oct 2015 09:35:04 AM UTC https://requests.ci-train.ubuntu.com/#/silo/ubuntu/landing-027 Fri 30 Oct 2015 04:22:25 PM UTC https://requests.ci-train.ubuntu.com/#/silo/ubuntu/landing-042 Fri 30 Oct 2015 05:01:57 PM UTC https://requests.ci-train.ubuntu.com/#/silo/ubuntu/landing-041 Fri 30 Oct 2015 07:26:42 PM UTC https://requests.ci-train.ubuntu.com/#/silo/ubuntu/landing-023 Please consider freeing one or two or EIGHT *ahem* *ahem* so other people can have silos. If nobody frees any silos I will be forced to free the stalest ones owned by the biggest hoggers first! -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Landing team 22.10.15
On Oct 22, 2015 4:59 PM, "Łukasz 'sil2100' Zemczak" < lukasz.zemc...@canonical.com> wrote: > Anyway, Robert switched our CI Train infrastructure to now support > xenial and all dual landings target that archive. Correction, all future dual silos will target xenial and vivid, current silos targeting wily and vivid will require manual transition to xenial before publishing. But the good news is that this doesn't require any rebuilds, just binary copying packages from wily to xenial within the silo. -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] ANNOUNCEMENT: Xenial open in CI Train
Hi all, Just a quick note to mention the new xenial series is now supported by CI Train, and what you should expect for "dual" silos. Requests that are literally "series: dual" will always build packages for wily & vivid. This is because, if I switched "dual" to mean xenial & vivid, then any dual silos that were already built would contain wrong contents (eg, the train would expect xenial packages in the PPA but only find wily) and generally the train would not understand what to do with them. So there are new series options offered by the train: "wily+vivid" and "xenial+vivid". xenial+vivid is the new default and should be used for all new phone development going forward. If you currently have a "dual" or "wily+vivid" silo in the train, eg if you find yourself on either of these pages: https://requests.ci-train.ubuntu.com/#/tickets?active_only&series=dual https://requests.ci-train.ubuntu.com/#/tickets?active_only&series=wily%2Bvivid Then you need to transition your silo to be xenial+vivid. There are two options for this transition: 1. If your silo is still being actively developed (eg, you anticipate needing to rebuild your silo before it's ready to publish anyway), just edit your landing request and select the new xenial+vivid option prior to your next rebuild. Then ask me nicely and I'll remove the obsolete wily packages from the PPA and you'll be good to go. 2. If your silo is complete but not published yet, eg if it's waiting in the QA Queue and you don't want to rebuild the silo at all, we can do some manual surgery in this case. What I will do is copy the existing wily packages into xenial series within the same PPA, then change the request to xenial+vivid and it should be safe to continue testing the existing builds in the silo. There are 34 silos needing to be transitioned off of wily+vivid, so just ping me when you're ready to do the transition and I can take care of it. Thanks! -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] ANNOUNCEMENT: New train feature
On Wed, Oct 21, 2015 at 8:26 AM, Olivier Tilloy wrote: > On Wed, Oct 21, 2015 at 5:23 PM, Marco Trevisan > wrote: >> Il 20/10/2015 21:58, Robert Park ha scritto: >>> The train build job, when run with the default parameters, now detects >>> which MPs have new commits and only builds those projects (but you can >>> still override this with FORCE_REBUILD or PACKAGES_TO_REBUILD as >>> usual). >> >> Nice. >> >> Does it detect --overwrites? I mean, does it use the commit id or the >> commit number as reference? > > Using --overwrite to change a branch’s history when it’s been > published to the outside world sounds like a bad idea, why would you > do that? Indeed, using --overwrite is generally a bad idea unless you're fixing a mistake 2s after you pushed it and nobody else pulled it yet. That said, however, the train does record commit IDs rather than revnos, which means it will detect changed commits and include those for rebuilding, so the train won't give you any hassle if you're using --overwrite on your MPs. -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] ANNOUNCEMENT: New train feature
Hi all, Today I rolled out a small new feature for the train that I'm sure some people will enjoy. The train build job, when run with the default parameters, now detects which MPs have new commits and only builds those projects (but you can still override this with FORCE_REBUILD or PACKAGES_TO_REBUILD as usual). So if your old workflow looked like this: 1. Build silo for first time. 2. Push new commits at MPs (or add new MPs) 3. Run build job and get "No packages being considered!" error 4. Run build job again with package name in PACKAGES_TO_REBUILD The new workflow looks like this: 1. Build silo for first time. 2. Push new commits at MPs (or add new MPs) 3. Run build job, only projects with new commits are rebuilt. Note that, for the time being, it only detects commits in the MP source branch, not in the project trunk, so if some other silo lands and you need to rebuild due to new commits at trunk you may still need to use PACKAGES_TO_REBUILD to force rebuilding of a given package. But in the general case that you're iterating on an MP the train should be a lot smarter now about what needs to be rebuilt and what doesn't. Enjoy! And as usual let me know if you run into any problems. -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] ANNOUNCEMENT: Some small train changes
Hi all, Just thought I'd let everybody know about some small new features & bugfixes that change train behavior: 1. The "manual sources" field is now automatically filled by scanning the PPA. So if you're working on a silo that has one or more (or entirely) non-MP manual sources, you can just leave that field blank and the train will Do The Right Thing and everything will Just Work. Hopefully this saves everybody some typing! 2. Manual sources are now supported in "dual" silos. If you are wanting to include manual sources in a dual silo, it is your responsibility to make sure that both wily and vivid versions of the manual package are manually uploaded into the PPA, but once that is done the train will be able to correctly watch the build status & publish those packages as usual. 3. New "Artifacts" listing. If you look at a request detail page (like /#/ticket/NNN), immediately under the 'Status' field there's a new 'Artifacts' field. This field will display a single link to the most recent jenkins job that has been run in the silo, regardless of whether it was a build or publish job. So if you're a core dev trying to do a packaging ACK, it should now be easier to find the most recent job with the most current artifacts in it, without having to bumble around looking at two different jenkins jobs. (if the field appears blank, it's because the request is a bit older and doesn't have any entries in the audit log yet. you can fix this by doing a WATCH_ONLY build) As usual, let me know if you find any problems and I'll take a look. Enjoy! -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] ANNOUNCEMENT: New CI Train site design
On Wed, Oct 7, 2015 at 2:47 AM, Michal Karnicki wrote: >> I do agree generally that "menu on right" is unconventional, > > Unconventional, and so more useful at the same time. That's what I was thinking, thanks ;-) -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Landing team 06.10.15
On Oct 6, 2015 2:56 PM, "Łukasz 'sil2100' Zemczak" < lukasz.zemc...@canonical.com> wrote: > have been fixed and, additionally, the webbrowser now runs apparmor > confined. Wow, for real? Congrats to everybody that made that happen! That sounds like an enormous undertaking. -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] ANNOUNCEMENT: New CI Train site design
On Tue, Oct 6, 2015 at 12:32 PM, Gustavo Boiko wrote: > Hi > > This new version looks better than the previous one, nice work. > One suggestion: would it be possible to move the menus to the left? I think > it would be more intuitive. This I'm not sure about. I chose the right side for a couple reasons: * It's easier for thumbing on mobile (and I do use the site on mobile a lot) * I think the requests themselves are the primary thing people want to see so it makes more sense for them to have the "top priority" lefthand space... I do agree generally that "menu on right" is unconventional, so I guess it comes down to whether or not people feel convention trumps those other factors. If enough people complain about this I can switch it. OR, we could create a launchpad team for people who prefer lefthanded menus and then the display could alternate based on membership in that team :-D -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] ANNOUNCEMENT: New CI Train site design
Hi all, I worked hard through the weekend to revamp the CI Train website and after getting some helpful responses from testers, the site is now live! Say goodbye to: * Clicking 'build' on the wrong request * horizontal scrolling * buttons that are too small to click on mobile * and a pile of other annoying bugs! Say hello to: https://requests.ci-train.ubuntu.com/ Let me know what you think! I'm happy to iterate on this if anybody has any concerns. -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] CALL FOR TESTING: Early access to new CI Train redesign.
OK, I've put a bunch of work into this over the weekend and it's really starting to shape up. It could probably use a little more polish, but I've added a bunch of fun new features: - nicer error pages than just popping up a dialog box - dynamic multi-column view if your screen is wide enough - detects if new train rollout has happened and automatically reloads html - new "migrating" page for tracking silos that are in flight - new "jump to request" if you know the request id you want to see All in all I'm really happy with this and would like to go live soon, so please take a quick look and raise any concerns you may have now! On Oct 2, 2015 5:28 PM, "Robert Park" wrote: > Hi all, > > So I've been working on a new design for Bileto that should address > many people's concerns. > > In particular, my goal has been to make a responsive design that works > well on both mobile & desktop, doesn't bother certain > narrow-screen-using-people with horizontal scrolling, avoids > accidentally clicking on wrong requests, and fixing a few other UI > annoyances. > > It's not finished yet, but I've put up an early version at the staging > train here: > > https://requests.ci-train.staging.ubuntu.com/ > > > You should see so far: > > * on mobile you get a single-column view (nav bar in-line with requests) > * on desktop you get a two-column view (well, one column of requests, > but nav bar moves to right side) > * action buttons are only displayed when only one request is visible > so it's no longer possible to trigger jobs / comment on the wrong > request by mistake. > * fields are displayed with proper labels rather than relying on the > form at the top of the page to explain what values mean > > > Not finished yet: > > * looks rough around the edges, needs lots of polish yet > * full audit log still always visible, need to make it default to only > show comments then click to expand full log > * need to double check that these changes don't regress other things > people complained about in the past. > * probably other things, please let me know what you think! > -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] CALL FOR TESTING: Early access to new CI Train redesign.
Hi all, So I've been working on a new design for Bileto that should address many people's concerns. In particular, my goal has been to make a responsive design that works well on both mobile & desktop, doesn't bother certain narrow-screen-using-people with horizontal scrolling, avoids accidentally clicking on wrong requests, and fixing a few other UI annoyances. It's not finished yet, but I've put up an early version at the staging train here: https://requests.ci-train.staging.ubuntu.com/ You should see so far: * on mobile you get a single-column view (nav bar in-line with requests) * on desktop you get a two-column view (well, one column of requests, but nav bar moves to right side) * action buttons are only displayed when only one request is visible so it's no longer possible to trigger jobs / comment on the wrong request by mistake. * fields are displayed with proper labels rather than relying on the form at the top of the page to explain what values mean Not finished yet: * looks rough around the edges, needs lots of polish yet * full audit log still always visible, need to make it default to only show comments then click to expand full log * need to double check that these changes don't regress other things people complained about in the past. * probably other things, please let me know what you think! -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] ANNOUNCEMENT: New Bileto features & fixes
New & Shiny: * The audit logs have been expanded at the request of jibel. Now, in addition to recording all the jenkins jobs that you run, it also records when you edit the request, stating which fields you changed. So now eg if somebody changes the qa signoff status, we'll have a record of who did that. * The much requested "search only active requests" feature is finally here, now the search box has three buttons: one for searching all requests, one for searching only active requests, and one for searching just on active silonames. The UI for that is a bit rough but I promise that'll get cleaned up in the redesign I'll be starting shortly. * Fixed a bug where the audit logs weren't being displayed in order. Apparently you can't trust the db to list those in creation order, you have to explicitly sort it. Who knew? ¯\_(ツ)_/¯ * Fixed a bug where audit log timestamps were being displayed incorrectly. * Fixed a bug in the search system that might have resulted in searches returning false positives (eg things that shouldn't have matched your search but did). Old & Busted: * there is currently a bug which allows you to enter comments in situations where the comments are hidden, making it look like your comment wasn't saved. don't worry, your comment IS saved, just click the request permalink (the link on the right which has a number + date) to see the comments. The redesign I'm doing will fix this & a bunch of other UI annoyances. Take luck, and care for it! -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] ANNOUNCEMENT: Bileto Audit Logs
Hi everybody! Today I rolled out a new train feature, auditable logs. What this means is, in addition to jenkins setting the status of your bileto request, jenkins will now also make an immutable (=auditable) comment explaining who ran what job and when. You can see an example in the staging server here: https://requests.ci-train.staging.ubuntu.com/#/ticket/623 Also, in anticipation of the deluge of comment spam that this will generate on every request, I've made the comments only display if there are fewer than 5 requests on the page (so if you're looking at the request page as per the above link, or even a search that only has a few results, you can see the full log, but the front page of bileto won't show comments anymore). NOTE: if you are seeing broken links in Bileto, it's because you're using a stale cached copy of the page, just reload the page and you should be fine. I expect this might be a little bit rough around the edges but I'm hoping to start on that redesign soon, should fix everything. Let me know if you have any issues! Thanks! -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Request for Comments: Potential New CI Train design
On Wed, Sep 30, 2015 at 4:33 AM, Jean-Baptiste Lallement wrote: > Le 29/09/2015 17:41, Michael Zanetti a écrit : >> Same here. In general, when it comes to searching/filtering, the old >> dashboard was quite a bit ahead of bileto. I miss the life-filtering a >> lot, and I constantly get confused by already landed silos. > > > The name of the source package(s) in the silo like on the old dashboard is > also pretty useful. > > Actually it looks like poeple want the old dashboard back :) The *live* filtering is never going to come back. The difference between the old dashboard and the bileto is that the old dashboard *could only* access live silos and therefore it just loaded all of them and provided live filtering, but in the dashboard it has to deal with all requests and it's not as easy to tell which are active and which aren't, so it has to load more of them and can't hold them all in memory at the same time without a big slowdown. So the best I can offer here is AJAX-y searches which are a bit slower than just live-filtering a bunch of stuff that's already in memory. I was hoping that the various views I've added would satisfy people rather than having a search that hides old requests but people keep complaining so I guess I have to add that. It'll probably be a week or two though as I have some bigger priorities at the moment. -- -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] Request for Comments: Potential New CI Train design
Hi everybody. Based on feedback from a few people I am considering redesigning https://requests.ci-train.ubuntu.com/ One thing several people have asked for is they want the front page to just have a summary of the requests (not showing all data), and make you click through to individual request in order to show full details & action buttons. This would, eg, prevent people clicking on action buttons on the wrong row. So the big question is -- what information is critical to display in a summary and what information can be relegated to an expanded detail view? I'm thinking the summary view would need at least: - description - siloname - status / qa status - request id / creation date Any other fields that anybody considers absolutely critical to be on the summary view? Anything not in this list would require a click in order to reveal. Thanks. -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] New CI Train "search by siloname" feature
Hello, As requested by a couple people, the train now allows to search and link by siloname. If you notice at the top of https://requests.ci-train.ubuntu.com/ there are now two buttons next to the search box. The button labelled "Requests" performs a full-text search on all request fields, and includes landed/abandoned requests. The button labelled "Siloname" searches only silonames, and hides landed/abandoned requests. The siloname search is a substring search, so currently the 3 digit number of the silo is all you need to enter in order to be unique, however if RTM ever comes back to life you'll need to enter the full siloname "ubuntu/landing-NNN" to guarantee uniqueness. This also comes with a new URL for accessing requests by silos, so eg you can bookmark and share around links like this: https://requests.ci-train.ubuntu.com/#/silo/001 (shorthand) https://requests.ci-train.ubuntu.com/#/silo/ubuntu/landing-042 But just keep in mind the request will disappear from those pages when the silo lands/abandons, so if you're looking for a request "permalink" you really need to be using the request id, which is this URL: https://requests.ci-train.ubuntu.com/#/ticket/7 -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Stuck during apt-get upgrade
On Wed, Sep 23, 2015 at 11:56 PM, Simon Fels wrote: > The reason for this isn't clear yet however I modified the citrain utility > to do an device upgrade without service restart and then directly reboot the > device recently. See > https://code.launchpad.net/~morphis/phablet-tools/citrain-changes > > This should let the upgrade run through. > > Not sure when ogra has time to land that change. Is there a reason you're waiting for ogra? As the author of citrain tool I might be more appropriate to work on that, but I'm reluctant to release this change if it's causing this issue. Also I'd like to consult other users of citrain tool (QA people mostly) to make sure this change doesn't break anything for them. CC'd Jibel for input on how this MP impacts QA's use of citrain tool. -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] IMPORTANT ANNOUNCEMENT: CI Train changes
I never spoke with the DMB directly, I only know what Steve told me from when he spoke to them. Steve's comments on this bug are what I've been working of of: https://bugs.launchpad.net/cupstream2distro/+bug/1459186 On Tue, Sep 22, 2015, 6:09 AM Łukasz 'sil2100' Zemczak < lukasz.zemc...@canonical.com> wrote: > Hey Robert! > > Excellent news in overall. Just a quick question I already asked on > multiple other occasions: is the DMB fine with such an approach? I know > it all sounds sane and safe as is but I just want to make sure the DMB > is fine with letting everyone unprivileged push out new versions of > packages (even if only those without any packaging changes). Did you or > Steve consult this with them? In the normal Ubuntu release process users > need sponsors for everything. In the past only the trainguards and/or > core-developers had this privilege in the CI Train. > > Cheers, > > W dniu 22.09.2015 o 09:21, Robert Park pisze: > > On Mon, Sep 21, 2015 at 9:59 PM Robert Park > > wrote: > > > >> This means that if your silo does not touch any files under debian/, you > >> can publish your own silos totally by yourself, no trainguards required. > >> > > > > Ooops, this statement is not totally clear, as raised by some people on > > IRC. The official policy for publishing is as follows: > > > > The publish job now honors real archive upload permissions, that is, only > > core-dev can upload main packages, only MOTU+core-dev can upload universe > > packages, and also per-package uploaders can upload their packages. > > > > The exception is, in the case of projects that canonical owns, if the > silo > > contains a package that didn't touch any files under debian/, the > developer > > can publish by themselves without anybody else helping them along. This > > means only MPs, not source packages. > > > > So the new workflow should look like this: > > > > 1. You create your own ticket at https://requests.ci-train.ubuntu.com/ > > > > 2. You assign your own silo. > > > > 3. You build your own silo and do your own testing. > > > > 4. Submit your silo to QA and wait for them to approve it, if necessary > > (only necessary for overlay PPA releases, not necessary for wily) > > > > 5. You publish your own silo. If it works, great, if not it may say > you're > > not authorized, at that point you should find a core dev, show them the > > packaging diffs, and ask them to publish for you. When hassling your > > favorite core dev, best practice is to link to the publish job page with > > the build number at the end of the URL, like [0], as this will show the > > diffs and then easily allow the core dev to publish. If you just link the > > publish job page without the build number like [1], you get "last > > successful artifacts" which won't show the right diffs because the job > > technically failed. > > > > 6. The train will monitor the publication and once the package is > > successfully landed in ubuntu archive, it will automatically merge your > > merges and free the silo. > > > > [0] https://ci-train.ubuntu.com/job/ubuntu-landing-019-2-publish/97/ > > [1] https://ci-train.ubuntu.com/job/ubuntu-landing-019-2-publish/ > > > > > > > > > -- > Łukasz 'sil2100' Zemczak > Foundations Team > lukasz.zemc...@canonical.com > www.canonical.com > > -- > Mailing list: https://launchpad.net/~ubuntu-phone > Post to : ubuntu-phone@lists.launchpad.net > Unsubscribe : https://launchpad.net/~ubuntu-phone > More help : https://help.launchpad.net/ListHelp > -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] IMPORTANT ANNOUNCEMENT: CI Train changes
On Mon, Sep 21, 2015 at 9:59 PM Robert Park wrote: > This means that if your silo does not touch any files under debian/, you > can publish your own silos totally by yourself, no trainguards required. > Ooops, this statement is not totally clear, as raised by some people on IRC. The official policy for publishing is as follows: The publish job now honors real archive upload permissions, that is, only core-dev can upload main packages, only MOTU+core-dev can upload universe packages, and also per-package uploaders can upload their packages. The exception is, in the case of projects that canonical owns, if the silo contains a package that didn't touch any files under debian/, the developer can publish by themselves without anybody else helping them along. This means only MPs, not source packages. So the new workflow should look like this: 1. You create your own ticket at https://requests.ci-train.ubuntu.com/ 2. You assign your own silo. 3. You build your own silo and do your own testing. 4. Submit your silo to QA and wait for them to approve it, if necessary (only necessary for overlay PPA releases, not necessary for wily) 5. You publish your own silo. If it works, great, if not it may say you're not authorized, at that point you should find a core dev, show them the packaging diffs, and ask them to publish for you. When hassling your favorite core dev, best practice is to link to the publish job page with the build number at the end of the URL, like [0], as this will show the diffs and then easily allow the core dev to publish. If you just link the publish job page without the build number like [1], you get "last successful artifacts" which won't show the right diffs because the job technically failed. 6. The train will monitor the publication and once the package is successfully landed in ubuntu archive, it will automatically merge your merges and free the silo. [0] https://ci-train.ubuntu.com/job/ubuntu-landing-019-2-publish/97/ [1] https://ci-train.ubuntu.com/job/ubuntu-landing-019-2-publish/ -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] IMPORTANT ANNOUNCEMENT: CI Train changes
On Mon, Sep 21, 2015, 10:28 PM Timo Jyrinki wrote: On Tue, Sep 22, 2015 at 7:59 AM, Robert Park wrote: > If your silo does touch debian/ files, then you need to get a packaging ACK > from a core dev (not a trainguard!) so your best bet is to make friends with > these people if you haven't already: Me and Łukasz are MOTU:s so we can review and publish all 'universe' packages' packaging changes as before, which includes a lot of the touch stack. Trainguards can also help finding a core-dev when needed for main repository packages. -Timo Right, but the fact that you guys are MOTU is just a coincidence, nothing inherent about trainguard status gives you any power anymore ;-) I should really get MOTU myself... -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] IMPORTANT ANNOUNCEMENT: CI Train changes
On Mon, Sep 21, 2015 at 8:38 PM Robert Park wrote: > Sorry for the inconvenience! Now with that out of the way, there is some > good news > But wait! There's more! I've now opened up publication permissions to everybody. So now trainguards have no special publication powers at all, a trainguard is just somebody that knows slightly more about the train than you. This means that if your silo does not touch any files under debian/, you can publish your own silos totally by yourself, no trainguards required. If your silo does touch debian/ files, then you need to get a packaging ACK from a core dev (not a trainguard!) so your best bet is to make friends with these people if you haven't already: https://launchpad.net/~ubuntu-core-dev/+members#active -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] IMPORTANT ANNOUNCEMENT: CI Train changes
Hello! So today has been an exciting and terrifying day for the train, as I've attempted to fix some issues discovered during my vacation, and created more problems, and then worked to fix those, too. First, the bad news: I've made a horrible, horrible mistake that resulted in at least 10 silos being deleted. I've done my best to restore & rebuild them but as usual I'm only human. Everybody should check over their silos, and if possible do a quick smoketest to make sure nothing has exploded. Most of the silos I rebuilt succeeded but in particular there are these 4 failures: timo-jyrinki wellark charles dobey, ubuntu/landing-026: Build failed: pay-service failed to build: https://requests.ci-train.ubuntu.com/#/ticket/284 oSoMoN, ubuntu/landing-035: Build failed: webbrowser-app failed to build: https://requests.ci-train.ubuntu.com/#/ticket/386 mandel, ubuntu/landing-030: Build failed: ubuntu-download-manager failed to build. unity-scope-click failed to build: https://requests.ci-train.ubuntu.com/#/ticket/394 bzoltan, ubuntu/landing-038: Build failed: ubuntu-ui-toolkit failed to build: https://requests.ci-train.ubuntu.com/#/ticket/369 Since all of the failures are PPA build failures, this means most likely they were broken before I accidentally deleted them and you're already aware of these failures and are already working on them anyway, but still best to double-check that I didn't make things worse. There is also a possibility that I've resurrected extra silos by mistake, so everybody should check their requests to make sure that things you thought were landed/abandoned aren't back from the dead. Here is the full list of rebuilds I performed: http://paste.ubuntu.com/12518903/ Sorry for the inconvenience! Now with that out of the way, there is some good news: * The prepare-silo job now can no longer fail/explode when somebody else's request is malformed, so silo assignments should be bulletproof at this point. The only failure mode should be if we're out of silos, if you see anything else please inform me. Actually, inform me if we're out of silos as well and I'll try to free some up ;-) * When assigning silos, instead of always getting the lowest-numbered available one, you will get a random one. This isn't perfect, but can be helpful in the situation where you've uploaded an incorrectly high version number to a PPA and want to downgrade your version number in a rebuild. PPAs don't allow this, so in order to do this you need to free your silo then reassign. Previously since assignment always gave you the lexically-first silo, you'd find yourself freeing & reassigning and ending up back in the same silo. Now there's at least a chance you'll get a different silo. * There is a new 'abandon' job that is more along the lines of what people have been expecting. If you want to free a silo, you no longer run the "Merge & Clean" job with ONLY_FREE_SILO, there's now a separate "Abandon" link in Bileto. And this works whether or not the request has a silo assigned or not. So if you're done with a request, just click Abandon then Build on the jenkins form, if you had a silo it will be released, and then the status will unconditionally be set to 'Abandoned' which hides the request. Any questions or concerns please let me know, that's all for now! The iterations continue!! -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] PSA: train assignment issues.
OK so there's some issues in the prepare-silo job that are causing silos to be assigned but the assignment not reflected in bileto. I have a fix for this but it's untested so you'll have to wait until next week for me to get back and finish it off. If this happens to you in the meantime, you need to review the log from the prepare silo job from the first time you ran it (you probably ran it a couple times and on subsequent runs saw the message "already assigned", so go back to the first time you ran it, there'll be a traceback but just before the traceback it'll say " configuring for silo ubuntu/landing-xxx" Just copy & paste the silo name from that log to the siloname field in bileto and then everything will work after that. Sorry for the inconvenience! -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] ANNOUNCEMENT: New CI Train Happenings.
Glad you like it, it can only get better! I'm on vacation this week but I'll probably get bored and work on it more at some point ;-) On Sun, Sep 13, 2015 at 3:28 PM, Olivier Tilloy wrote: > On Thu, Sep 10, 2015 at 10:53 PM, Robert Park > wrote: >> Hey everybody! >> >> After a gruelling week deep in the salt mines, I'm happy to report the >> latest CI Train development: >> >> "Silo Reconfiguring" is no longer a thing that exists. >> >> From now on, every time you run a build, it reads the data directly >> from Bileto, so changes you make in Bileto are reflected "live" (well, >> you have to run the build job to see the changes, but you don't have >> to reconfigure first in order to see the changes). >> >> If you click 'Assign' on an already assigned request, you'll get an >> error saying the request is already assigned. >> >> Enjoy! > > Thanks Robert, I’d been waiting for that one for a long time. > Just made use of it, and I confirm adding a branch to an existing silo > is easy and painless. Go bileto, go! -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] ANNOUNCEMENT: New CI Train Happenings.
Hey everybody! After a gruelling week deep in the salt mines, I'm happy to report the latest CI Train development: "Silo Reconfiguring" is no longer a thing that exists. >From now on, every time you run a build, it reads the data directly from Bileto, so changes you make in Bileto are reflected "live" (well, you have to run the build job to see the changes, but you don't have to reconfigure first in order to see the changes). If you click 'Assign' on an already assigned request, you'll get an error saying the request is already assigned. Enjoy! -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Problems with duplicated Abandoned requests?
On Mon, Aug 31, 2015 at 10:29 AM, Sergio Schvezov wrote: > On Mon, Aug 31, 2015 at 1:53 PM, Robert Park > wrote: >> I've just realized that bileto doesn't give any immediate feedback >> upon clicking the button. I don't think it's a huge issue because the >> API seems to me to return quickly enough. But if you guys are finding >> it feels a bit unresponsive I can try adding a little spinner or >> greying out the button after clicking it or something. > > > I'd still add something client side just in case someone is a on a slow or > bad network :-) Ok, I've fixed it in trunk so that when you click Save/Create buttons, they dim until it recieves the response from the API. It isn't live in production yet, I'll roll it out a bit later bundled with some other fixes. -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Problems with duplicated Abandoned requests?
You're welcome! On Mon, Aug 31, 2015 at 10:04 AM, Jim Hodapp wrote: > Thanks robru, I've done the same thing as Alfonso and Michael and these > changes will be greatly appreciated. > > On Mon, Aug 31, 2015 at 12:53 PM, Robert Park > wrote: >> >> Ok, just went live with a fix that causes bileto to clear the form and >> jump to the new request upon successful creation. Let me know if >> that's working for you. >> >> I've just realized that bileto doesn't give any immediate feedback >> upon clicking the button. I don't think it's a huge issue because the >> API seems to me to return quickly enough. But if you guys are finding >> it feels a bit unresponsive I can try adding a little spinner or >> greying out the button after clicking it or something. >> >> On Mon, Aug 31, 2015 at 1:57 AM, Alfonso Sanchez-Beato >> wrote: >> > >> > >> > On Mon, Aug 31, 2015 at 10:53 AM, Michael Zanetti >> > wrote: >> >> >> >> +1 for jumping to the new request >> > >> > >> > +1 too >> > >> >> >> >> >> >> On 31.08.2015 10:51, Robert Park wrote: >> >> > Hmmm i remember writing code that made the form clear but it must >> >> > not be getting called for some reason. >> >> > >> >> > How about this: i make the form clear and also redirect to the >> >> > permalink >> >> > page so you only see the new ticket. Is that a good idea? Or will >> >> > people >> >> > prefer to stay on the same page even if it means the new ticket >> >> > potentially not being visible? >> >> > >> >> > Another option: dialogue box indicating successful ticket creation. >> >> > >> >> > Let me know what you prefer and I'll implement it on my Monday >> >> > morning >> >> > (us west). >> >> > >> >> > On Aug 31, 2015 1:33 AM, "Alfonso Sanchez-Beato" >> >> > > >> > <mailto:alfonso.sanchez-be...@canonical.com>> wrote: >> >> > >> >> > >> >> > >> >> > On Mon, Aug 31, 2015 at 10:21 AM, Michael Zanetti >> >> > > >> > <mailto:michael.zane...@canonical.com>> wrote: >> >> > >> >> > So right now for example I was on the "Mine" page. The newly >> >> > created >> >> > request appeared on the bottom of the list. But even if it >> >> > appears as >> >> > the first entry, I would expect the form that I just filled >> >> > in >> >> > to do >> >> > something visually (clearing the fields, add a green >> >> > highlight >> >> > like LP >> >> > does or something) to give some feedback that the button >> >> > press >> >> > was >> >> > successfull. >> >> > >> >> > >> >> > I experienced the same issue: I did not notice that the request >> >> > had >> >> > been added to the top and clicked again. Clearing the fields or >> >> > some >> >> > additional feedback as mzanetti suggest would help. >> >> > >> >> > >> >> > >> >> > On 31.08.2015 10 :12, Robert Park wrote: >> >> > > Hmmm, so you were on a page that hid the new request? >> >> > If >> >> > you're on >> >> > > the front page the new request would appear at the top of >> >> > the >> >> > list. >> >> > > >> >> > > On Aug 31, 2015 12:42 AM, "Michael Zanetti" >> >> > > > >> > <mailto:michael.zane...@canonical.com> >> >> > <mailto:michael.zane...@canonical.com >> >> > <mailto:michael.zane...@canonical.com>>> >> >> > > wrote: >> >> > > >> >> > > Hi, >> >> > > >> >> > > yes, when you click the "Create new request" button, it >> >> > does create a >> >> > > new row, but it doesn't clear the input fields, or >>
Re: [Ubuntu-phone] Problems with duplicated Abandoned requests?
Ok, just went live with a fix that causes bileto to clear the form and jump to the new request upon successful creation. Let me know if that's working for you. I've just realized that bileto doesn't give any immediate feedback upon clicking the button. I don't think it's a huge issue because the API seems to me to return quickly enough. But if you guys are finding it feels a bit unresponsive I can try adding a little spinner or greying out the button after clicking it or something. On Mon, Aug 31, 2015 at 1:57 AM, Alfonso Sanchez-Beato wrote: > > > On Mon, Aug 31, 2015 at 10:53 AM, Michael Zanetti > wrote: >> >> +1 for jumping to the new request > > > +1 too > >> >> >> On 31.08.2015 10:51, Robert Park wrote: >> > Hmmm i remember writing code that made the form clear but it must >> > not be getting called for some reason. >> > >> > How about this: i make the form clear and also redirect to the permalink >> > page so you only see the new ticket. Is that a good idea? Or will people >> > prefer to stay on the same page even if it means the new ticket >> > potentially not being visible? >> > >> > Another option: dialogue box indicating successful ticket creation. >> > >> > Let me know what you prefer and I'll implement it on my Monday morning >> > (us west). >> > >> > On Aug 31, 2015 1:33 AM, "Alfonso Sanchez-Beato" >> > > > <mailto:alfonso.sanchez-be...@canonical.com>> wrote: >> > >> > >> > >> > On Mon, Aug 31, 2015 at 10:21 AM, Michael Zanetti >> > > > <mailto:michael.zane...@canonical.com>> wrote: >> > >> > So right now for example I was on the "Mine" page. The newly >> > created >> > request appeared on the bottom of the list. But even if it >> > appears as >> > the first entry, I would expect the form that I just filled in >> > to do >> > something visually (clearing the fields, add a green highlight >> > like LP >> > does or something) to give some feedback that the button press >> > was >> > successfull. >> > >> > >> > I experienced the same issue: I did not notice that the request had >> > been added to the top and clicked again. Clearing the fields or some >> > additional feedback as mzanetti suggest would help. >> > >> > >> > >> > On 31.08.2015 10 :12, Robert Park wrote: >> > > Hmmm, so you were on a page that hid the new request? If >> > you're on >> > > the front page the new request would appear at the top of the >> > list. >> > > >> > > On Aug 31, 2015 12:42 AM, "Michael Zanetti" >> > > > > <mailto:michael.zane...@canonical.com> >> > <mailto:michael.zane...@canonical.com >> > <mailto:michael.zane...@canonical.com>>> >> > > wrote: >> > > >> > > Hi, >> > > >> > > yes, when you click the "Create new request" button, it >> > does create a >> > > new row, but it doesn't clear the input fields, or gives >> > any other >> > > visual clue that it has happened. This caused me to hit >> > that button >> > > mulitiple times too until I realized I created multiple >> > requests >> > > with that. >> > > >> > > Cheers, >> > > Michael >> > > >> > > On 31.08.2015 09 >> > :27, >> > Robert Park wrote: >> > > > Hi everybody, I just glanced over the abandoned requests >> > page today: >> > > > >> > > > >> > https://requests.ci-train.ubuntu.com/#/tickets?status=Abandoned >> > > > >> > > > And I'm seeing lots of groups of 3 or 4 near-identical >> > (or totally >> > > > identical) requests that are all abandoned. >> > > > >> > > > Is something going wrong that's causing people to create >> > multiple >> > > > requests by mistake? Can somebody f
Re: [Ubuntu-phone] Problems with duplicated Abandoned requests?
Hmmm i remember writing code that made the form clear but it must not be getting called for some reason. How about this: i make the form clear and also redirect to the permalink page so you only see the new ticket. Is that a good idea? Or will people prefer to stay on the same page even if it means the new ticket potentially not being visible? Another option: dialogue box indicating successful ticket creation. Let me know what you prefer and I'll implement it on my Monday morning (us west). On Aug 31, 2015 1:33 AM, "Alfonso Sanchez-Beato" < alfonso.sanchez-be...@canonical.com> wrote: > > > On Mon, Aug 31, 2015 at 10:21 AM, Michael Zanetti < > michael.zane...@canonical.com> wrote: > >> So right now for example I was on the "Mine" page. The newly created >> request appeared on the bottom of the list. But even if it appears as >> the first entry, I would expect the form that I just filled in to do >> something visually (clearing the fields, add a green highlight like LP >> does or something) to give some feedback that the button press was >> successfull. >> > > I experienced the same issue: I did not notice that the request had been > added to the top and clicked again. Clearing the fields or some additional > feedback as mzanetti suggest would help. > > >> >> On 31.08.2015 10:12, Robert Park wrote: >> > Hmmm, so you were on a page that hid the new request? If you're on >> > the front page the new request would appear at the top of the list. >> > >> > On Aug 31, 2015 12:42 AM, "Michael Zanetti" >> > mailto:michael.zane...@canonical.com>> >> > wrote: >> > >> > Hi, >> > >> > yes, when you click the "Create new request" button, it does create >> a >> > new row, but it doesn't clear the input fields, or gives any other >> > visual clue that it has happened. This caused me to hit that button >> > mulitiple times too until I realized I created multiple requests >> > with that. >> > >> > Cheers, >> > Michael >> > >> > On 31.08.2015 09 :27, Robert Park wrote: >> > > Hi everybody, I just glanced over the abandoned requests page >> today: >> > > >> > > https://requests.ci-train.ubuntu.com/#/tickets?status=Abandoned >> > > >> > > And I'm seeing lots of groups of 3 or 4 near-identical (or totally >> > > identical) requests that are all abandoned. >> > > >> > > Is something going wrong that's causing people to create multiple >> > > requests by mistake? Can somebody fill me in on what led to this >> > > situation so I can prevent it from happening again? >> > > >> > > Thanks! >> > > >> > >> > >> > -- >> > Mailing list: https://launchpad.net/~ubuntu-phone >> > Post to : ubuntu-phone@lists.launchpad.net >> > <mailto:ubuntu-phone@lists.launchpad.net> >> > Unsubscribe : https://launchpad.net/~ubuntu-phone >> > More help : https://help.launchpad.net/ListHelp >> > >> >> >> -- >> Mailing list: https://launchpad.net/~ubuntu-phone >> Post to : ubuntu-phone@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~ubuntu-phone >> More help : https://help.launchpad.net/ListHelp >> >> > -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Problems with duplicated Abandoned requests?
Hmmm, so you were on a page that hid the new request? If you're on the front page the new request would appear at the top of the list. On Aug 31, 2015 12:42 AM, "Michael Zanetti" wrote: > Hi, > > yes, when you click the "Create new request" button, it does create a > new row, but it doesn't clear the input fields, or gives any other > visual clue that it has happened. This caused me to hit that button > mulitiple times too until I realized I created multiple requests with that. > > Cheers, > Michael > > On 31.08.2015 09:27, Robert Park wrote: > > Hi everybody, I just glanced over the abandoned requests page today: > > > > https://requests.ci-train.ubuntu.com/#/tickets?status=Abandoned > > > > And I'm seeing lots of groups of 3 or 4 near-identical (or totally > > identical) requests that are all abandoned. > > > > Is something going wrong that's causing people to create multiple > > requests by mistake? Can somebody fill me in on what led to this > > situation so I can prevent it from happening again? > > > > Thanks! > > > > > -- > Mailing list: https://launchpad.net/~ubuntu-phone > Post to : ubuntu-phone@lists.launchpad.net > Unsubscribe : https://launchpad.net/~ubuntu-phone > More help : https://help.launchpad.net/ListHelp > > -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] Problems with duplicated Abandoned requests?
Hi everybody, I just glanced over the abandoned requests page today: https://requests.ci-train.ubuntu.com/#/tickets?status=Abandoned And I'm seeing lots of groups of 3 or 4 near-identical (or totally identical) requests that are all abandoned. Is something going wrong that's causing people to create multiple requests by mistake? Can somebody fill me in on what led to this situation so I can prevent it from happening again? Thanks! -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] WARNING: CI Train Dashboard removal imminent
Hello, Unless there are any strong objections, I'd like to eliminate the train dashboard[0] completely on Monday, August 31st (this Monday!) in favor of using the bileto requests[1] page exclusively for all train related tasks. To the best of my knowledge the requests page has achieved feature parity with the dashboard page and I've taken care to address everybody's concerns from the previous email thread about this. Normally I'd go for a longer deprecation period, but in this case the continued existence of the dashboard is holding back some other important work* I'd like to get started on ASAP. [0] https://requests.ci-train.ubuntu.com/static/dashboard.html [1] https://requests.ci-train.ubuntu.com/ * I'll go into some boring details about the inner working of the train now, stop reading here unless you're fascinated by ci train internals. The difference between the requests page and the dashboard is that the requests page shows information exclusively from a postgres database, while the dashboard page shows information mostly from json files that jenkins is using internally to store silo state. These json files are the reason that "silo reconfiguration" is a thing, because "reconfiguring" a silo means "processing bileto db data and storing it into json files in jenkins". I'll soon be working towards eliminating these json files, so that jenkins refers to bileto directly. This will make bileto be the authoritative source of silo configuration data, and it also means that you'll never need to reconfigure a silo again. But because the dashboard relies on those json files in order to display silo information, it needs to die before I can get started on this. -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] ANNOUNCEMENT: Bileto improvements, Dashboard deprecation
On Fri, Aug 28, 2015 at 7:24 AM, Alberto Mardegan wrote: > Yep, I don't see a big need for linking to the user's launchpad page; in > fact, I clicked on the user name, expecting this to result in having the > view filtered by that user. Alright, I've just gone live with that. Clicking on a username shows the outstanding requests with that username in the "landers" field (not necessarily created by that user: anybody can type anything into the landers field). -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] ANNOUNCEMENT: Bileto improvements, Dashboard deprecation
On Aug 27, 2015 11:33 PM, "Alberto Mardegan" wrote: > > On 08/27/2015 03:17 AM, Robert Park wrote: > > Anyway, take it for a spin, please let me know what you think! > > Hopefully this is helpful ;-) > > I'd like the search box to act as a filter, or have a checkbox which Is not clear to me how "act as a filter" is different than the current behavior. You mean filter the displayed requests without making an ajax request? That would not work due to the way the api is paginated, so if you did a filter search, it wouldn't show things from subsequent pages and you'd get mysterious behavior like a new request that's hidden by the filter pushing a request you want to see into the second page, effectively hiding it without any clue why. > toggles whether landed requests are shown. "Toggles" are hard because it would need to make an ajax request when you turn it on or off, which would be slow. > I don't have any requests filed under my name, but still I want to see > all requests made by dbarth (who generally creates the requests for our > team) which need attention. I know the ui doesn't expose this, but just bookmark this, it works even if you're logged out: https://requests.ci-train.ubuntu.com/#/user/dbarth The /user/ endpoint was created specifically to show pending requests and hide landed/abandoned ones for any user. I'm open to suggestions on how to make that more usable. Two search boxes side by side, one for searching users and one for searching other fields? I guess i could linkify the lander names to that user page rather than to the launchpad page which is the current link target. Technically the backend api supports decent "advanced" searching on a per field basis but i have no ui for this either. You can manually fiddle the urls to do advanced searching if you want, eg: https://requests.ci-train.ubuntu.com/#/tickets?qa_signoff=Ready%20for%20QA&status=Packages%20built Supported fields are defined here: http://bazaar.launchpad.net/+branch/bileto/view/head:/tickets/models.py#L131 > > Currently this is very hard to do, because the board is filled with > landed requests, and it's difficult to have a clear overview of the > current situation. This is only true if you are using the search box. -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] ANNOUNCEMENT: Bileto improvements, Dashboard deprecation
On Aug 27, 2015 3:24 AM, "Timo Jyrinki" wrote: > > Thanks Robert for all the great improvements again! You're welcome! It's super fun working on user-facing features, a lot of the internal code cleanup & test writing was really thankless ;-) > > Visual cues are what I miss from the dashboard the most now. When > publishing a silo, I first felt something was "wrong". And what was > wrong was that the bold, friendly blue was missing from the "QA > granted" text. All of the color coding on the dashboard was really > helpful, so it'd be nice to get some of it back. OK I've just gone live with status colors, as far as i know I've hit feature parity with the Dashboard's colors, let me know if i overlooked anything. > And one more thing: I now noticed that as a trainguard I really miss > the "N silos in use" text. That helps to know the general status and > eg when going up to the 50-60 one knows we're approaching limits while > at sub-40 no thoughts need to be put to the direction of checking up > the silo usage. OK, i added this too, but be warned it's a little experimental. Where the dashboard was counting actual Jenkins silos, bileto is counting "requests with silioname set and status not Landed or Abandoned". So far the numbers are matching but it's not impossible for them to get out of sync. This situation will improve however as i continue working towards integrating everything. -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] ANNOUNCEMENT: Bileto improvements, Dashboard deprecation
On Thu, Aug 27, 2015 at 4:07 AM, Łukasz 'sil2100' Zemczak < lukasz.zemc...@canonical.com> wrote: > Hey Robert, > > Looking nice so far, thanks for the enhancements! You're welcome! > > Some ideas for improvement that might also help out with one of the > issues that Michael mentioned below: > > The generall idea is to de-clutter the bileto interface. The hover > overlay menu is a step in the right direction, but I was actually > thinking of doing something different. What if each bileto landing could > be click-to-expand? Generally speaking, i think a true click-to-expand would be a lot more trouble than it's worth. However, i think the dashboard has some good inspiration here: currently in the dashboard, if you view all silos, the MPs are hidden. If you search, fewer silos are displayed and then the merges appear. Similarly, it would be easy to set some kind of threshold, say if more than 5 requests are visible, then some fields are hidden, but if 5 or less are visible then display all fields. This way, you could simulate "click to expand" by clicking on the permalink or narrowing your search. Would also be nicer for users who only have a few requests seeing everything. The raises a few questions in my mind: 1. Which fields can be hidden? 2. What do we do with the new request form at the top? It doubles as a header to explain what fields your seeing, it would be weird if it displayed fields that were hidden, but it would also be weird if fields were hidden when you try to use it. 3. If we minimize the number of fields displayed, does it still make sense to use a full-width row to represent a request? Maybe the requests could be displayed in a "card" style like the dashboard is. Again this gives me reservations about how the new request form would adapt to these changes. > > The good ol' Issue Tracker I once made has something similar, but > not-too-fancy as it has no animations of the expanding: > http://people.canonical.com/~lzemczak/issues/ > > This was also basically the main idea of the CI Airline UI we were > preparing. > > On the spreadsheet there was no other choice but include ALL the > required data in the main row - with our custom tools we should only > show the most important, and leave the rest visible to only those that > want to see it. Well, there is already some hidden data. Bileto doesn't display pkgversionlist for instance ;-) > Then things like 'what merges are actually configured' > or all the comments for a silo etc. could be in the details. Then we > could only show the top-most comment on the main view. > > What do you think? Yeah, i agree we need to declutter for sure, i think it's going to take some iterations until we get it right. -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] ANNOUNCEMENT: Bileto improvements, Dashboard deprecation
On Thu, Aug 27, 2015 at 3:15 AM, Michael Zanetti wrote: > * when adding a new branch to an existing silo and then reconfiguring > it, before one could easily see if the reconfigure step was successful > or not, depending if the new MR would show up on the dashboard or not. > Now, adding it will always make it appear there and in order to see if > it really ended up in the silo config, I think one needs to either check > the configure job's history to find out. Ah yes, I had the same problem. This is now solved by visiting the PPA page: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-054 The information listed here can be considered equally authoritative as the dashboard page was, so if your MP isn't on that page, it won't get built when you run the build job. This also solves the problem of bileto not having the link to the jenkins console output when you want to investigate a failure status. First click through to the PPA, and the link to the console log is there. The ultimate goal is to make jenkins query bileto for the data every time, so that you never need to reconfigure, but this will work as a stop-gap until that is achieved. > * I find it a little harder to find my silos in bileto, I think that's > partially because the list has less spacing than the entries in the > dashboard had, I mentioned in another mail you just need to click 'Mine' to see only your own open requests. > but also because bileto still shows my old, already > landed silos. This is only true if you are searching your own name rather than using the 'Mine' page. -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] ANNOUNCEMENT: Bileto improvements, Dashboard deprecation
On Aug 27, 2015 9:54 AM, "Rodney Dawes" wrote: > > Hi Robert, > > One small thing that I think would help a lot, is to have the link to > the PPA, have the "/+packages" added to the end of the URL. The main PPA > page by itself is pretty much useless, and what I need is to get at the > links to download the armhf .debs that were built, or to see build logs, > which are all on the +packages page. Hmmm, I'm not sure about this one. I /just/ went live with a change that puts a ton of useful (to me) info in the ppa description field, if i make this change as you say then I'd have to click extra to get to what i want. Unfortunately the description isn't shown on the other page. Maybe we could have both links? That might clutter it a bit too much, not sure what would be best. -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] ANNOUNCEMENT: Bileto improvements, Dashboard deprecation
On Aug 27, 2015 9:51 AM, "Rodney Dawes" wrote: > > On Thu, 2015-08-27 at 12:15 +0200, Michael Zanetti wrote: > > * I find it a little harder to find my silos in bileto, I think that's > > partially because the list has less spacing than the entries in the > > dashboard had, but also because bileto still shows my old, already > > landed silos. > > I think this is hard, because it's just a large list, and the only > separation of anything really, is with whitespace. Even just keeping > track of the row for your landing can be a bit difficult, if you are > scrolling horizontally in a window, versus using a full screen browser. > One thing that would help here, I think, is simply changing the UI to > show "My Requests" separately from all the others, and always at the > top. Providing clear separation for the requests I make, from the > hundreds being made by others, will certainly make it easier to track my > own, especially when other requests come in after mine. This already exists, click "Mine" and bookmark that page, it shows only your pending requests. (If your irc nick doesn't match your launchpad id you may need to fiddle the URL manually to get the right results) -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] ANNOUNCEMENT: Bileto improvements, Dashboard deprecation
On Wed, Aug 26, 2015 at 5:17 PM, Robert Park wrote: > * and probably other things I can't remember. There's now also a 'Ready for QA' link[0] that shows only requests that are built and ready to be QA'd. So between that, the trainguards view, and the 'Mine' view that shows each user their own open requests, I think all types of users are represented in having special views that show them only what they want to see. [0] https://requests.ci-train.ubuntu.com/#/tickets?qa_signoff=Ready%20for%20QA&status=Packages%20built -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] ANNOUNCEMENT: Bileto improvements, Dashboard deprecation
Hi everybody! A quick heads up about some improvements I've made to the Bileto Requests page, here: https://requests.ci-train.ubuntu.com/ Most notably, for requests that have silos assigned, I've added links to the Build/Publish/Clean jobs, which for most people should alleviate the need to ever visit the dashboard[0] ever again. If you find there's something missing from the requests page and you're going to the dashboard for any reason, please let me know ASAP! My goal is to remove the dashboard soon, as it's existence is blocking my ability to get some other exciting work done. This update also comes with a slew of smaller niceties: * The cluttered Assign/Edit/Comment/etc actions are now swept into a hidden pop-up that only appears when you hover on each request. This cuts down on visual clutter significantly, hopefully without being too unintuitive (let me know if you have any problems using the new actions menu). * when logging in, SSO now redirects you back to the page you were on, rather than the front page. * if you ever tried to manually fiddle with the URL before, you might have noticed that you had to reload the page to make bileto notice your URL changes. This is now fixed and bileto will now respond to manual URL manipulations in a live and responsive way. * I've changed the way the URLs are interpreted, which has changed all the URLs (sorry if you had bookmarks!) but this allowed me to eliminate several dozen lines of weird corner cases in the code, and better future-proof against expansions of backend API features. * There's a new "trainguards" page[1] which highlights only requests that are ready to be published, so us trainguards don't have to hunt around for such things. * and probably other things I can't remember. Anyway, take it for a spin, please let me know what you think! Hopefully this is helpful ;-) [0] https://requests.ci-train.ubuntu.com/static/dashboard.html [1] https://requests.ci-train.ubuntu.com/#/trainguards -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] ANNOUNCING: Slight change to CI Train behavior
Hi everybody, Just a quick heads up so nobody is surprised by this change. Next time you go to assign/reconfigure a silo, the "prepare-silo" jenkins job will only have one field for the REQUEST_ID rather than having all necessary fields. The fields that have been removed are now queried directly from Bileto's JSON API rather than being passed in as HTTP GET parameters as was our custom. This simplifies the form a bit, hides some implementation details, and especially nice is that that whole "double urlencoded" issue is just gone. So, if you go to assign a silo and wonder why all the jenkins form fields are missing, the answer is: magic. Have a great day! -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] PSA: Packaging requirements for CI Train users
Hi everybody, I just wanted to take a moment to remind people that if you're making a change to any files in the debian/ directory of a CI Train managed project, those changes need to be noted in the debian/changelog. If you're using the debian/changelog auto-generation (which most people are), this means you need to mention the changes in the commit message field of the MP which makes the change. The archive admins used to let this sort of thing slide but they are getting stricter about wanting more verbose changelogs explaining why the debian packaging is changing. It's causing some issues as people are building their packages, doing all sorts of testing, and then needing to rebuild afterwards because the changelog was wrong, which wastes time & resources for both the developer and the package reviewer. Please get your changelogs correct in the first place! Thanks. -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Out of silos!
On Tue, Aug 11, 2015 at 1:13 PM, Steve Langasek wrote: > Can we consider the g++ transition a special case, and ask for silos to be > merge-and-cleaned now if they've been published to wily-proposed - trusting > that they'll be shepherded the rest of the way on the archive side? Yes, this is totally reasonable and I've already seen this happen in a couple of cases anyway. If you have a silo stuck in wily-proposed (particularly if this is a dual silo as your vivid packages will already be safely in the overlay ppa), and you want to merge your silo and begin a new silo, without concern for your package actually making it into wily proper, you can just click 'Clean' on the dashboard, check FORCE in the jenkins job, and then click 'Build'. Your merges will be merged, your silo will be freed, and then you'll be free to start a new silo with new work that builds atop the previous merges. -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] Out of silos!
Alright everybody, you know the drill! We're out of silos so I'm trying to free up as many as I can. These silos haven't moved since July 31st: https://requests.ci-train.ubuntu.com/static/dashboard.html#?q=ubuntu/landing-025 https://requests.ci-train.ubuntu.com/static/dashboard.html#?q=ubuntu/landing-024 https://requests.ci-train.ubuntu.com/static/dashboard.html#?q=ubuntu/landing-022 https://requests.ci-train.ubuntu.com/static/dashboard.html#?q=ubuntu/landing-007 https://requests.ci-train.ubuntu.com/static/dashboard.html#?q=ubuntu/landing-003 These silos haven't moved since August 3th: https://requests.ci-train.ubuntu.com/static/dashboard.html#?q=ubuntu/landing-042 https://requests.ci-train.ubuntu.com/static/dashboard.html#?q=ubuntu/landing-053 These silos haven't moved since August 4th: https://requests.ci-train.ubuntu.com/static/dashboard.html#?q=ubuntu/landing-037 https://requests.ci-train.ubuntu.com/static/dashboard.html#?q=ubuntu/landing-006 These silos haven't moved since August 5th: https://requests.ci-train.ubuntu.com/static/dashboard.html#?q=ubuntu/landing-021 https://requests.ci-train.ubuntu.com/static/dashboard.html#?q=ubuntu/landing-049 GCC5 mega-silos, are we done with these yet? https://requests.ci-train.ubuntu.com/static/dashboard.html#?q=ubuntu/landing-039 https://requests.ci-train.ubuntu.com/static/dashboard.html#?q=ubuntu/landing-016 The worst silo-hog offenders are: Jim Hodapp with EIGHT. Timo Jyrinki with six. Kevin Gunn with four. David Barth with four. Bill Filler with four. If everybody could take a moment to review the dashboard and free 1 or 2 silos that they aren't using, that would be super. Also be aware that clicking 'Abandon' in the requests page DOES NOT free the silo, it just sets the request status. You have to click 'Clean' in the dashboard, check ONLY_FREE_SILO, and then click 'Build'. -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] Vote for your favorite CI Train bugs!
Hi everybody! Now that the dust has settled from the CI Train spreadsheet replacement rollout, I have some more time on my hands to go back and start fixing all those bug reports that have been languishing for the last 6 months or so. In order to be most effective though, I need to know which bugs are the most annoying! So if everybody could take a couple minutes to look over the ci-train.ubuntu.com[0] and requests.ci-train.ubuntu.com[1] bug trackers and "vote"* for your favourite bugs, I would appreciate it! Also if there's a bug / missing feature not reported, please file a new report. Thanks! [0] https://bugs.launchpad.net/cupstream2distro [1] https://bugs.launchpad.net/bileto * by "vote" I mean "mark the bug as affecting you" -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] ANNOUNCEMENT: Train Spreadsheet now fully migrated
On Jul 30, 2015 11:35 PM, "Jean-Baptiste Lallement" < jean-baptiste.lallem...@canonical.com> wrote: > > Hi Robert, > > Thanks for migrating the data. You're welcome! >> * you see HTTP500 coming fromhttps:// requests.ci-train.ubuntu.com/v1/tickets >> > It's less frequent but still happening with the API. Yes I've resolved most of the tracebacks i was seeing in the logs by there's still one left. I have a fix in staging but wasn't confident enough to go live at eod Friday. Will push it out Monday to solve all the world problems ;-) -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
