14:01:07 #startmeeting fedora-qa-devel 14:01:07 Meeting started Mon Jun 2 14:01:07 2014 UTC. The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:01:07 Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:01:13 #meetingname fedora-qa-devel 14:01:13 The meeting name has been set to 'fedora-qa-devel' 14:01:18 #topic Roll Call 14:01:27 * roshi is here 14:01:28 * mkrizek is here 14:02:12 * kparal here 14:03:07 welcome, welcome 14:03:20 #chair kparal 14:03:20 Current chairs: kparal tflink 14:04:28 kparal: do you know if josef is planning/able to attend? 14:04:50 nvm, just saw your poke in #fedora-qa 14:05:11 Hi all. Have I missed something? 14:05:18 he should be comming 14:06:00 cool, and we're complete 14:06:25 ok, lets get started, then 14:06:26 hi there! /me is out on luch and it is taking loinger than expected (so i'll be a bit slower as i'm on thr phone) 14:07:01 #topic Taskotron 0.2 Release 14:07:17 As folks may have noticed, 0.2 hasn't actually been released yet 14:07:34 we hit some build issues that delayed deployment of new code until late on Friday 14:08:22 * tflink fixed a minor config issue that was breaking bodhi reporting but everything seems to be working well 14:08:42 unless someone has noticed something else, I'll plan on wrapping up the 0.2 release later today 14:09:09 #info 0.2 release is expected later today, delayed due to build issues 14:09:59 feel free to help keep an eye on execution status if you have spare cycles 14:10:10 good idea 14:10:49 #topic Licencing Fun 14:11:23 I just wanted to mention the conversation on qa-devel@ and see if anyone had more questions 14:11:59 IIUIC, the project overall license is only important (and only applies) for those files which don't have a different license specified inline 14:12:04 I want to get the licensing stuff figured out so it isn't a potential issue anymore 14:12:36 yeah, pretty much. it also dictates how the project is distributed 14:12:56 so for our purposes, we simply put gpl2+ headers into some files, gpl3+ headers into other files, and then include both license texts in our root directory. and in readme, we say that files which don't have a concrete license fall into gpl2+ 14:13:07 and in RPM, we specify "GPL2+ and GPL3+" 14:13:14 (in rpm spec file) 14:13:22 is that correct? 14:13:26 rpm would be gpl3(+) 14:13:42 not both but otherwise, yes, that is my understanding 14:13:44 I think there can actually be several options included 14:13:44 what does that (the "how the project is distributed") mean, exactly, Tim? Is it about the rpm license, or also something completely different? 14:14:09 the rpm license and the produced tarball 14:14:23 * jskladan meh, I gues I'll just be mostly reading this with my typing speed :D 14:14:56 so as long as we had gpl3 code in libtaskotron, libtaskotron would be distributed as a gpl3 licensed project 14:15:35 I'm not complete sure about the implications of the overall license vs the individual licensed files, but I don't see any problem here 14:15:52 but if we wanted/needed to fall back to gpl2+ in the future, we could remove the gpl3 files and relicense the project 14:15:54 taskotron as gpl3 overall seems fine 14:16:24 * tflink asked on the legal list and nobody said "no, you can't do that!" and I assume the concept isn't completely crazy :) 14:16:37 has somebody responded at all? :) 14:16:50 yeah, several folks responded 14:16:57 just checking :) 14:17:00 ok, sounds good 14:17:14 is this the correct time to discuss my annoyingly long comment in https://phab.qadevel.cloud.fedoraproject.org/T199 as well? 14:17:38 https://lists.fedoraproject.org/pipermail/legal/2014-May/002458.html 14:18:44 kparal: or we can have that discussion on the list, in the ticket 14:19:05 oh, the overall project license affect just the binary, not the source code - the source is affected just by individual source licenses. now I finally get it 14:19:13 (spot's answer) 14:19:24 tflink: I'm fine with that 14:20:46 proposed #agreed change libtaskotron to a gpl3 license for the project but keep individual source files as gpl2+ where possible 14:21:19 is it actually possible to say gpl3+, or does it not exist yet? 14:21:35 proposed #agreed change libtaskotron to a gpl3+ license for the project but keep individual source files as gpl2+ where possible 14:21:41 I think we can say "or later" if we wish 14:21:44 yeah, gpl3+ is valid AFAIK 14:21:56 ack 14:22:03 ack 14:22:19 the only potential snag is that the source from ansible is gpl3, not gpl3+ 14:22:32 ack 14:22:50 #agreed change libtaskotron to a gpl3+ license for the project but keep individual source files as gpl2+ where possible 14:23:07 tflink: not sure if that's a problem or not 14:23:47 as long as we don't alter the license on that imported code, I don't think it would be 14:24:05 ok 14:24:50 my other question is whether we want to start following a DCO (developer certificate of origin) process similar to what the kernel folks do 14:25:31 tflink: can you show me how their git commit message looks? 14:25:53 * tflink had an example, looks for it again 14:26:07 * kparal is interested how much clutter it adds 14:26:16 * danofsatx-work is late 14:26:16 it's a line or two per person, IIRC 14:26:22 mornin' fellas 14:27:21 is the certificate digitally signed, or is it just a piece of text? 14:27:50 the certificate itself is just a piece of text 14:28:01 in what way it is different than saying "contributed by $name <$email>" in the commit message? 14:28:18 in case someone sends a patch and I commit it 14:28:33 the process that the kernel folks use is to say that "by signing off on the commit, you certify that you have fulfilled the conditions in the DCO" 14:28:55 yeah, you do a 'git commit -s ' 14:29:28 kpral: the difference is, taht the contributor says "I know about DCO and the code is OK by the DCO strandards" (IMHO) 14:29:30 can I still adjust his/her patch someone? 14:29:37 *somehow? 14:29:55 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8212f58a9b151d842fa60a70f354e43c61fad839 14:30:19 kparal: yeah, but you'd have to sign off on it as well 14:30:30 I don't see the DCO text in that link 14:30:37 http://developercertificate.org/ 14:30:46 kparal: Signed-off-by: Benjamin Herrenschmidt 14:30:52 kparal: lines 370-376 here: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches 14:32:04 so, the sign off act means "I read the submission requirements" 14:32:15 basically, yes 14:32:37 but it's soft, it's not actually written there. the person can sign it off without actually reading the docs 14:32:43 it's just not that likely 14:32:56 still it doesn't seem to _prove_ much 14:33:15 yeah, it's more of an accountability trail for the kernel AFAIK 14:33:34 keeping track of which folks contributed/modified what 14:33:59 I don't reject the idea, I just wonder whether it would be easier to ask the person to say "I agree to submit this patch under XYZ license" in Phab 14:34:16 that would be a better proof that the person is aware of it 14:34:22 and still trackable 14:34:54 yeah, we're small enough that we could get away with something that requires more effort 14:34:56 and of course it would apply to just third-party patch submissions 14:35:24 * tflink is OK with making sure license headers are present in every new and existing file, though 14:35:36 and outside of @redhat.com, because otherwise the person doesn't have a copyright anyway 14:35:42 it's pretty hard to argue that you didn't know about the license when its in the header of every file :) 14:36:07 * kparal is supporter of a reasonably short file header 14:36:30 * roshi just commented on T199 to the same effect 14:36:31 shall we push the DCO specifics conversation to the list? 14:36:40 probably 14:36:46 since we have ~25 minutes left and haven't gotten to 0.3 planning yet 14:37:15 I don't really mind if we do DCO, I'm just not sure if it can't be done in an easier way in our case 14:37:30 yeah, I'm of a similar mind 14:37:42 but one more non-planning thing 14:37:51 #topic Bodhi2/Taskotron FAD 14:38:20 I don't know how much this was discussed beforehand, but there's a group of us in Denver, CO, USA that are working on bodhi2/taskotron stuff 14:39:02 the biggest things I'm looking to get out of it are: bodhi2 integration plans (aka kill the results in bodhi comments initiative) and more details on integration with fedora infra 14:39:38 great to have you as our representative 14:39:43 I'll be writing blog posts and updating the list as things happen but figured I would mention it here in case folks wanted to participate in #fedora-fad or in hangout/jitmeet etc. 14:40:33 * kparal will join the irc channel 14:40:33 * tflink assumes there are no concerns here, moves on 14:40:41 #topic Taskotron 0.3 Planning 14:41:09 #info list of proposed tickets is available at https://phab.qadevel.cloud.fedoraproject.org/w/taskotron-0.3/ 14:41:23 tflink: but don't feel forced to discuss things on irc rather than in person, I'll just have a look from time to time if something interesting is happening 14:42:03 kparal: yeah, I think it'll be a mixture of irc conversation and reporting as email/blog posts 14:42:30 the biggest things that I'd like to see happen for 0.3 are: 14:42:51 1) documentation for directives (including the licensing fun) 14:43:05 agreed 14:43:10 2) have depcheck closer to running in stg if not running in stg 14:43:37 * kparal nods 14:44:10 jskladan: are you OK with https://phab.qadevel.cloud.fedoraproject.org/T195 ? Do you think it can be done and tested in 2 weeks? 14:44:37 tflink: yup 14:44:45 * jskladan grabs the ticket 14:45:06 hrm, it looks like this list of tickets may not be long enough for 2 weeks 14:45:31 I have a few backup tickets for myself, no worry 14:45:48 roshi: do you think you could wrap up the non-content work on T142 by friday at the latest? 14:46:12 kparal: I assume you're ok with keeping T143? 14:46:22 tflink: sure 14:46:24 yeah 14:47:55 kparal: can you take T201 as well since you're already somewhat familiar with the reporting code? 14:48:12 tflink: ok 14:48:30 do we have something for mkrizek? 14:49:08 * tflink is thinking about that 14:49:33 I think we should create some tickets from https://phab.qadevel.cloud.fedoraproject.org/D104#2 14:49:42 that's going to be needed soon anyway 14:50:08 also, I have give him T201 and can work on upgradepath unit tests instead, after T143 is done 14:50:12 yeah, threebean has some ideas for tasks in taskotron that'll require some changes there 14:50:34 *have give -> can give 14:51:08 why is it that I always write something else than I want to say? :) 14:51:27 that works, I'll get tickets filed from D104 later today 14:51:53 the other thing is eventual fedmsg emission from resultsdb 14:53:20 mkrizek: I assume that you have enough to keep you busy until tomorrow, at least? 14:53:48 * tflink will plan on sheparding the license change stuff 14:54:11 mkrizek: not sure now, will you take T201 or should I? 14:55:00 actually, how about the "delay" scheduler in trigger? 14:55:11 * tflink isn't sure if there is a ticket filed for that or not 14:55:11 * mkrizek looks 14:55:27 tflink: ah, right. that would be very handy 14:55:45 T200 is another one 14:56:01 kparal: I can do the T201 14:56:24 * mkrizek needs to go afk for hour or so 14:56:31 mkrizek: maybe take T200 first, because you have more experience with the trigger 14:56:48 sure 14:56:50 yeah, I'm thinking the same thing 14:57:03 ok, didn't know about T200, I will take it 14:57:05 I'll get a ticket found/filed for the delay scheduler as well 14:57:07 * kparal claiming T201 14:57:18 tflink: please assign to mkrizek afterwards 14:57:24 yep, will do 14:57:33 * mkrizek claimed T200 14:57:48 tflink: also if you find some nice small tasks, please assign to papercuts, I'll get them distributed :) 14:58:06 yeah, I've been trying to do that as I find them 14:58:16 found a small issue with fake_fedorainfra yesterday 14:59:33 pschindl: I assume you'll continue to work on T119? 14:59:48 pschindl: do you think that will be ready for review soon? 15:01:15 * tflink will pester him about that later 15:01:46 anyhow, we're about out of time - is there anyone who needs/wants tasks other than what we've already talked about? 15:02:23 if I run out of tasks, I'll start looking at upgradepath unit tests 15:02:42 hopefully I run out of them :) 15:02:53 sounds good 15:03:30 another general thing that would be good is to keep testing libtaskotron as a standalone runner 15:03:46 make sure that we're not overlooking some local usabiliy issue 15:04:13 but I think that's all for 0.3 tasks 15:04:16 actually I only run tasks using `runtask` 15:04:22 I don't have the full suite set up 15:04:27 #topic Open Floor 15:04:39 kparal: cool, that's how it's supposed to work :) 15:04:59 * tflink may be able to get more folks to try it out at the FAD, will see what happens 15:05:14 Anything else to bring up or that was missed? 15:05:24 not here 15:05:59 * tflink sets the patent-pending fedora-qa quantum fuse for [0,5] minutes 15:06:46 I'll send out minutes shortly 15:06:51 Thanks for coming, everyone! 15:06:55 #endmeeting