On Thu, 2016-12-22 at 12:24 +0100, Miro Hrončok wrote: > On 22.12.2016 11:53, Peter Robinson wrote: > > > > > On Wed, 21 Dec 2016 17:06:03 +0100 > > > > > gil <puntogil@xxxxxxxxx> wrote: > > > > > > > > > > > from: Task info: > > > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=17017344 > > > > > > > > > > > > https://kojipkgs.fedoraproject.org//work/tasks/7345/17017345/root.log > > > > > > > > > > > > " Error: nothing provides libpython3.6m.so.1.0 needed by > > > > > > gdb-headless-7.12-31.fc26.i686" > > > > > > > > > > > > any ideas? > > > > > > > > > > > > > > > Yes. Please wait a few hours... the python3.6 rebuild tag is being > > > > > merged back into rawhide and it's taking a few to sign all the builds. > > > > > > > > > > This should get fixed up after everything is signed and lands. > > > > > > > > > > > > The timing on this seems bizarre. A mail went out yesterday with a list > > > > of (as it said) ">200" packages which failed to build with Python > > > > 3.6...and now, before anyone gets a chance to fix any of those, we're > > > > just going to go ahead and merge the entire side tag? Why not wait a > > > > bit to see if we could clean up at least the more important FTBFSes? > > > > > > > > > That was me. The idea was let's just fix the remaining packages in rawhide. > > > Because, as I was told, the side-tag should only last for two weeks max. > > > Sorry if this was not done 100 % perfect, this was our fist attempt (all the > > > people who done the 3.5 rebuild are doing something else now). > > > > The reason for that guidance is that things move on the main branch > > and you end up chasing your tail with multiple bumps. Basically you > > want to build as quick as possible and get it done else you'll do a > > lot multiple times. > > Yes and also we didn't want to let it live during Christmas. > > Sorry if we made rawhide broken by our decision to merge early :( I don't want to sound too harsh, sorry. Indeed this isn't hugely different from the way things have been done previously, to be fair. However, we *have* been making a concerted effort lately to improve the ongoing quality of Rawhide. Think about changes to general software development lately. Most software projects these days don't work by accepting massive, disruptive commits to master without any checks and then cleaning up the mess bit-by-bit later, right? Many of us would like Fedora to work the same way: you don't just dump the Latest Shiny in as soon as it passes 'fedpkg build' and then wait for the bug reports and compose failures to roll in, but make an effort to ensure the change will, broadly speaking, work *when it lands*. Indeed not all the corresponding tools / processes are available yet (we don't attempt composes or run automated tests on side tags, for e.g.), but it is possible to do *better*. It only took me five minutes of eyeballing the list of broken packages to spot several important ones that it would be easy to think 'hmm, maybe we should fix that before merging the tag'. And if you talk to releng and QA about it, it's quite possible that we could do some manual compose attempts and test runs on the side tag; it's not Jenkins, but it's something. Just like a code project, I think everyone will ultimately be happier if we strive to keep Rawhide roughly working - not perfect, but at least composing and installing - all the time if we can, and everyone gets that itchy feeling if the compose check report says '50 tests failed' or the nightly compose doesn't work at all (in fact, I think we should have pungi send out a mail whenever a nightly compose fails, because right now when Rawhide or Branched aren't composing, this isn't very 'visible' unless you're one of the QA or releng folks who actively goes looking for the nightlies). It should be the same feeling you get when you go to a software project's front page and see the big red 'build failing' Light Of Failure. The old mindset that 'hey, it's only Rawhide, it's fine if it doesn't compose for three weeks at a a time!' ultimately just makes our lives harder, because we wind up getting to, say, the branch point or the Alpha freeze, not with a generally-functional distribution we can start polishing up, but with a bag of broken bits we have to spend two weeks just getting to the point that we can build all the deliverables. It's true that this approach results in you having to do a bit more work before merging, and maybe we'd have to write a script or something to help with the "I built 1.0-2 against NEWSHINY in the side tag but then the maintainer built 2.0-1 against OLDBORING in the main tag!" problem. But that shouldn't be insurmountable. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
