13:02:21 #startmeeting Env and Stacks (2014-02-18) 13:02:21 Meeting started Tue Feb 18 13:02:21 2014 UTC. The chair is bkabrda. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:02:21 Useful Commands: #action #agreed #halp #info #idea #link #topic. 13:02:30 #meetingname env-and-stacks 13:02:30 The meeting name has been set to 'env-and-stacks' 13:02:41 * jreznik is lurking 13:03:00 #chair abadger1999 pkovar tjanez samkottler bkabrda hhorak juhp mmaslano 13:03:00 Current chairs: abadger1999 bkabrda hhorak juhp mmaslano pkovar samkottler tjanez 13:03:08 #topic init process 13:03:15 hi 13:03:19 hi 13:03:20 * pingou 13:03:55 * tjanez says hi again (for the logs) 13:04:22 so if I'm reading marcela's mail right, we should mainly talk about the additional repository "fedora-ugly" (or how we'll name it) 13:05:04 jreznik, pingou, glad to have you around 13:05:15 #topic additional repository - fedora-{incubator,ugly} 13:05:25 * juhp is still wondering if one repo is enough... 13:05:33 tjanez: I probably won't make the whole meeting though 13:06:07 but need to start somewhere I guess :) 13:06:13 pingou, ok 13:06:13 juhp: I think we should have just one. having more would just confuse newcomers to fedora, I think 13:06:41 what about Fedora Commons then? 13:06:52 having one is nicer, but requires a little more work on the copr side 13:07:02 if you think about it, potential new contributors already need to do tons of reading about various stuff, so let's not complicate it more than we really need to 13:07:05 I'm also for one repo, but this repo would cater to both use-cases 13:07:11 well the thing is there are different use cases 13:07:17 (I'm thinking: each copr has a checkbox to indicate whether that specific copr should be integrated into the larger one) 13:07:50 how to prevent different coprs conflicting? :) 13:07:52 there might be different use-cases for more repos, but they we have to write another guidelines "how to figure out, which repo must be use" 13:07:57 pingou, should COPR authors care whether their content is ugly or incubating? 13:08:23 tjanez: do you want people to build stuff and not be aware that their build is being pulled into a repo? 13:08:31 (as in a larger repo) 13:08:33 (anyway I agree starting with a incubation repo is a good idea) 13:08:33 I pretty much like to know what is in a repository just from the name -- so I can expect what sort of packages I should expect.. so I'd actually like more repositories for more each specific set of packages (ugly, incubator, ...) 13:09:08 hhorak, right 13:09:35 pingou: no, I think the COPR author should manually specify that he want's to include his package in this new repo 13:09:39 hhorak: why do you think that these two need to be distinguished? 13:09:54 tjanez: +1 13:10:06 hhorak, I see your point from the user's perspective 13:10:06 but I guess coprs will still exist and can supplement the new reop 13:10:09 repo 13:10:12 tjanez: so we need to teach that to copr (the tool) 13:11:02 pingou: that shouldn't be a problem I think. for me personally, a minor problem is that there is no dist-git for copr 13:11:23 for one vs more - it depends on how it's going to be marketed and what kind of expectations users would have but better to start with something, so if it is one, it's one 13:11:25 eventually Fedora Commons (could also be called Mantle perhaps) would be stable repo though 13:11:30 pingou, yes that would be my vision (from COPR to this new repo and finally to the main repo) 13:12:08 so I think in the future we will need multiple repos anyway probably 13:12:16 ftr, I like the idea of incubator, it's something b/w coprs (rawhide) and stable (main repos) 13:12:16 I heard hughsie is working on picking various repos in PackageKit, but we probably want to add one repo (full of copr) for yum 13:12:17 bkabrda: it seems to me like how it works now - I should know what I get from a repository just by observing what the repository it is. 13:12:44 so let's focus on one repo now 13:13:00 we can additional really ugly repo and now work only with incubating projects 13:13:03 so overally, the process could be sth. like: copr---(some sort of autoQA/autoReview)-->fedora-"something-like-ugly"---(formal fedora review)-->fedora 13:13:21 tjanez: but I think the main reason why we established this repo was to have easy way how to distribute stuff never going to the main repository, incubator was on of the other requests to make it easy for some other packages to be available in main repo... 13:14:18 jreznik, I agree, I forgot to say that I see each of the steps as optional 13:14:23 mmaslano: I'd say ugly is more important to really make it easier for ugly to stuff to be available aka chromium and incubation could be one of the other use cases but market it as ugly 13:14:40 I just read pknirsch's use-case on devel list - wasn't clear to me though if those kde 5 packages were new or replacing existing kde 4 packages? 13:14:44 fedora-rearing? 13:14:52 pingou: lol 13:15:04 jreznik: KDE5 is not ugly! 13:15:04 juhp: kf 5 are new but for now coinstallable 13:15:08 * pingou tries to find a farming analogy 13:15:23 juhp: I think they're not GA yet so the packages would be there for now and then replace the other packages at the end of the day 13:15:32 mmaslano: kf5 packages are now really ugly :D that's what I'm talking about - what's expectation for users? 13:15:47 jreznik, ok 13:16:22 maybe let's really do fedora-ugly repo (call it better), set expectation to be "ugly" but if anyone is going to do nice things there and would like to use it as incubator - yes, but just beware it's ugly and it eats kitten 13:16:22 jreznik: um okay 13:16:24 I guess the repo would not be enabled by default, right? 13:16:38 juhp: definitely not 13:16:43 it won't be installed by default either 13:17:00 pingou: why not? 13:17:04 jreznik: if we are speaking about chromium, then we need ugly more than incubating 13:17:14 jreznik: not peer-reviewed 13:17:20 I don't like the name ugly 13:17:27 mmaslano: yep 13:17:36 juhp: yeah :) what would be better? 13:17:39 hmm true 13:17:41 +1 on not being enabled by default, but have a way to enable it after ticking some warning 13:17:50 juhp: it's just "working" name 13:17:50 mmaslano: I see a good (stable, current repo), a bad ( incubator) and an ugly \รณ/ 13:17:56 jreznik, I know :) 13:18:08 * samkottler is starting to see a stronger case for 2 repos 13:18:16 good :) 13:18:33 incubator vs. ugly (or new name) is a key difference IMO 13:18:40 samkottler: it is 13:18:47 we shouldn't forget that as soon as someone enables a repository, yum/dnf would update all packages of the same name, so user can't pick only "incubating" packages and ignore "ugly".. 13:18:48 samkottler: what do you like to see in those? 13:18:58 well if we have two repos - many ugly is not so bad :) ;) 13:18:59 samkottler: I received answer only from Base group and from jreznik 13:19:00 but let's start with one to make it easier, ugly, set expectations to ugly 13:19:07 erm s/many/maybe/ 13:19:36 mmaslano: incubator would be useful for the cloud WG to test early cloud-init and heat cfntools changes 13:19:43 and if it's going to work and it would be used by some projects as incubator repo, it should be easy to create one (ugly would be template) 13:19:48 ugly does give the idea that we did not check what it does and this might turn to be ugly 13:19:59 yes I think we need both ugly and incubator 13:20:04 pingou: that's probably true of both of them anyhow 13:20:05 incubator is wip to be better -> be integrated into the main repo 13:20:05 pingou, +1 13:20:13 yep 13:20:18 both would have the disclaimer of 'here be dragons' ;-) 13:20:32 samkottler: one aims to be better, chromium doesn't :) 13:20:37 samkottler: one headed for incubator, 5 headed for ugly :D 13:20:41 samkottler: but yeah, although dragons++ 13:21:02 okay 13:21:04 I think it would be good if all fedora package reviews were built first in incubator for example 13:21:06 but really to make it easier, let's start with that initial ugly to see how to do it, how it works etc 13:21:28 juhp: it would be fine if process of moving into main repo is automatic 13:21:29 juhp: and with review server pingou was talking about at devconf 13:21:31 juhp: I like the idea but I think the review process is already hard enough for new contributors 13:21:36 I agree with jreznik that we should start with one and set the expectations of users low 13:22:03 samkottler, you could build stacks in incubator but not koji 13:22:05 tjanez: yep and you know I was one who started with more repos but I really don't want to overengineer it from the beginning 13:22:14 another thing to figure out is whether any user can put packages from a COPR into ugly 13:22:21 or incubator 13:22:32 incubator cla+1 13:22:38 ugly, more relax? 13:22:39 because otherwise I'm sure we'd have malicious content in there pretty quickly 13:22:52 samkottler: to ugly - yes, with minimal policies/rules aka coninstallable with other packages in repo 13:22:54 it seems hard to control but I guess it should work - still not sure about conflict coprs 13:23:30 Also, there are not just expectations of users. With ugly, we can really set high expectations for new contributors/packagers 13:23:34 I mean two coprs can provide the same package 13:23:37 well, the idea is to make it as easy as possible, maybe some quick review... but in coprs itself, only allowed content should be included already 13:23:37 * samkottler is less worried about conflicts and more about someone putting a package called 'apache2' in with malware in it 13:23:42 and people will accidentally install it 13:23:47 juhp: in a way I wonder if we shouldn't approach this as: this is one of the dragons 13:23:56 samkottler++ 13:23:58 yeah maybe 13:24:00 * jreznik has meeting with his boss, has to leave 13:24:05 jreznik: g'd luck1 13:24:09 samkottler: you can do the same in the main repo too 13:24:19 samkottler, hehe 8) 13:24:52 jreznik: yeah but there's a higher level of trust in contributors to the main repos 13:24:53 copr only needs cla+1? 13:25:09 atm, I don't know 13:25:31 but I think incubator is at least packager, maybe cla+1 13:25:35 juhp: I think FAS is okay 13:25:42 I see 13:25:46 so just to sum up, we have few issues: 1) should we have one or more repos? 2) who and how can allow putting packages from a copr repo to the fedora-foo repo? 3) what sort of constraints should we put on the packages in fedora-foo repos and how to enforce these 13:25:47 mmaslano: do you know about COPR's permissions question? ^^ 13:25:54 bkabrda: ^? 13:26:11 bkabrda: do you know? 13:26:39 IIRC copr accepts lets anyone with fas account build, but that might have changed since I worked on it 13:26:52 how do you want to pick some repos? Most downloaded coprs? Or should it be based on packagers input? 13:27:03 or maybe we could restrict the copr repo button to some group 13:27:09 packagers + admin check I'd say 13:27:14 bkabrda: I don't think there is reason to make it strict. I believe only FAS is needed 13:27:55 bkabrda: that makes it a 4th point on your list :) 13:27:56 juhp: that would work for repos, but people with zero interest in Fedora couldn't build 13:27:57 perhaps it would be good to require cla? 13:28:08 if we restrict building in copr to just packagers, then noone else than packagers will be able to build for fedora-ugly-or-whatever repo, which is what we *don't* want, right? 13:28:40 we don't want to restrict people who build only for EL branches 13:28:50 bkabrda: we could restrict the 'add to fedora-{ugly,incubator} repo' checkbox 13:29:03 bkabrda: +1, I think we should be less strict here than for packages to core fedora 13:29:05 bkabrda: while keeping the coprs in general just require cla 13:29:14 pingou: +1 13:29:15 bkabrda: I think we want some kind of restriction on who can build, but being a packager shouldn't be one 13:29:43 pingou: I thought one of the ideas of fedora-ugly idea was to allow users who don't know that much about packaging (=non-packagers) to put their RPMs into the repo 13:29:48 maybe packagers could sponsor people? 13:29:51 samkottler: +1 13:30:02 samkottler: why? we wanted to have many users of copr. 13:30:08 bkabrda: that works for me, but for example for incubator we could make that restriction higher 13:30:27 mmaslano: I'm just saying that the people who build into the repo should have *some* level of trust 13:30:32 pingou: yes, if we create more repos with different expectation levels, we can do that 13:30:33 samkottler: ok 13:30:45 bkabrda: I do have the 2 repo model in mind ;) 13:31:07 pingou, I though we were leaning towards one :) 13:31:22 #info two repos seems like a must 13:31:22 tjanez: as a first step yes 13:31:37 mmaslano, why? 13:31:40 I'd still rather see just one for start and then add another if we need 13:31:51 tjanez: it would be definitley easier to define workflow just for one 13:32:03 we can probably set out with either ugly or incubator and then add the other once we have workflow done 13:32:05 I think we definitely need more than one but let's propose one initially? 13:32:08 yes 13:32:13 um, so who would be fine just with one repo for a start? 13:32:16 * mmaslano +1 13:32:23 mmaslano: +1 13:32:29 mmaslano: +1 13:32:33 at first +1 13:32:33 +1 13:32:48 #undo 13:32:48 Removing item from minutes: INFO by mmaslano at 13:31:22 : two repos seems like a must 13:32:50 what about let everyone with FAS build packages and then first inclusion to any repo would need manual review (see what is in it + click) of any usual packager? 13:33:01 mmaslano: +1 for one repo for start 13:33:11 yes, let's start with one repo with less restrictions 13:33:16 (i.e. ugly) 13:33:26 hhorak, right voting could also work 13:33:44 * samkottler is kind of concerned about any process that involves human review 13:33:44 I rather like that approach 13:33:50 samkottler: me too 13:33:56 samkottler, +1 13:34:05 samkottler, can you say more? 13:34:08 hhorak: I'm afraid it will be the same as bodhi (fedora updates) 13:34:11 (ftr, copr just requires a FAS account currently) 13:34:33 juhp: it's already such a burden to get people to review stuff and even with a larger pool of reviewers I think it'd be just as hard for unknown people 13:34:56 or same issue as reviews as samkottler said 13:35:01 samkottler: on the other hand, reviewing potentially ugly packages automatically doesn't make much sense, does it? 13:35:06 * pingou gtg 13:35:09 perhaps "review" is too strong - I thinking click a button or so 13:35:17 * tjanez is wondering whether we should just work out the part of removing/revoking packages instead of limiting what can go in 13:35:29 perhaps 13:35:32 tjanez: that's the copr's workflow right now 13:35:38 AFAIK there's been one legal issue so far 13:35:46 but this repo would be a bigger target 13:36:08 at first I was thinking about Change process, so FESCo would have to approve it, but it depends how many such Changes could be 13:36:14 how will conflicts with existing be prevented? by some script checking packages before creating the repo? 13:36:27 tjanez: that would make sense to me 13:36:55 juhp: yep I think so and then we could email the person who owns the COPR 13:37:11 juhp, I think it would be reasonable to have an automatic tool to do some basic policy enforcement and some basic QA 13:37:25 I think copr already a "flag" feature so maybe it could be extended to ugly 13:37:40 the hard parts are licensing checks and security/malware checks 13:37:55 #agreed only one repo should be created at the start 13:38:48 * samkottler has to get on a brief conf call, will be back in 15 if the meeting is still going on 13:39:09 I also wonder how packages could move from ugly to incubator etc but that is another discussion I guess 13:39:32 could we focus on one issue at the time? Now we have only ugly repo in plan. That's a good start 13:39:57 sorry too many ideas/questions coming up in my mind :) 13:40:01 what next? how to add repos into the ugly repo? 13:40:17 juhp: it's fine, we just need some plan what to do next :) 13:40:24 mmaslano: yeah, a good idea 13:40:28 mmaslano, good question 13:40:29 tjanez: these don't seem to me like the something hard or even something we should care too much; people can do the same damage now already 13:40:52 tjanez: I replied to licensing checks and security/malware checks 13:41:05 hhorak, yes, I see your point 13:41:44 already was mentioned repositories can be manually added by flag in copr, approved by reviewers, automatically added into repository if user has cla+1 13:42:05 if we have flags in copr, would it help? 13:42:11 that sounds like a good approach 13:42:21 there might be queue of flaged repositories for review 13:42:30 but who would do those reviews? 13:42:41 If I understand the "flags" correctly, the COPR author would push a button to propose his package(s) for inclusion in the ugly repo 13:42:47 I guess we need policy, what can get in first 13:42:54 tjanez: yes 13:42:59 mmaslano: I think we should do some flags in copr for this; the problem is specifying the process/criteria that a flagged repo has to undergo to reach the repo 13:43:27 bkabrda: after flag some basic tests to verify conflicts or whatever we agree is necesarry 13:43:54 mmaslano: yes. but specifying the tests is the hard part, I'd say 13:44:08 if there is a long queue and the just-FAS packager minds that.. he can become a real packager and submit it on his own 13:44:09 mmaslano, if we had automatic gating/policy enforcement, that would be better than manual review 13:44:36 we can check conflicts, if it can be installed (dependencies) 13:44:41 do we need more? 13:44:47 My question is, what would the manual review check that automatic checking can't do? 13:45:02 maybe obsoletes too 13:45:03 mmaslano: we need to care about conflicts within this "ugly" repository (more users would want to have the same package in it).. does "first-comes-wins" strategy works here? 13:45:25 tjanez, a sanity perhaps 13:45:28 tjanez: +1 good question 13:45:30 tjanez: malware? there should be a way to report baaad packages 13:45:36 hhorak: that is my concern as well. I guess FCFS is the only feasible approach, unfortunately 13:45:45 hhorak: aha, hm 13:45:57 hhorak: build everything in collections! 13:46:03 it would be kind of reassuring if someone had tried a brand new copr before it got added to ugly immediately 13:46:26 mmaslano: right, that would be an alternative way for those who are not first 13:46:31 * mmaslano was kidding 13:46:35 well that is would I meant earlier about being able to flag problematic repos in copr already 13:46:40 that wouldn't make builds easier 13:46:52 juhp: true, it's there 13:47:00 mmaslano, the problem with malware is re-occurring 13:47:16 there is flag - report bad repo 13:47:19 meaning, the packager can ship something clean at first 13:47:38 and add malware later -> hence first manual review is not helping 13:47:44 true 13:48:01 still some people are not so patient :) 13:48:14 mmaslano: tjanez: if we have some automatic malware checker and easy process to drop package from the repo, we can't do much more manually either 13:48:27 I agree that we should have an option to flag packages as malware/ incorrectly licensed 13:48:32 automatic malware checker? 13:48:40 * mmaslano is also surprised 13:49:12 * hhorak suprised as well :) but there could be something like that.. 13:49:17 hhorak: :) 13:49:32 * handsome_pirate thinks that actually adding things to the ugly repo should have some level of manual intervention from current packagers 13:49:56 or do we need a ugly staging repo? 13:50:01 * handsome_pirate also thinks that everything in the repo should be run against dependency checks and the like 13:50:49 maybe there will be only few repos, which can be checked by, um proven packagers? 13:51:00 well maybe we just need to try and see what happens a bit - I suspect the policy may evolve over time 13:51:09 I guess we need some security expert to tell us about the current state of automatic malware detection :) 13:51:34 juhp, +1 13:52:12 And I'm for being brave and developing a fully automatic gating / QA 13:52:20 #info does malware automatic check exist? 13:52:32 tjanez: good for us :) 13:52:53 * mmaslano needs to go to another meeting and will respond less 13:53:18 I hope it will spot %post -p rm -rf / :) 13:53:54 juhp, regarding %post %pre scripts, I would be for only allowing macroized commands 13:54:04 aha 13:54:17 and the set of macros would be controlled by Fedora *proper* 13:54:25 sounds good 13:54:25 e.g. a package with macros in the main repo 13:56:05 +1 13:56:37 tjanez, agree using approved macros only in scripplets sounds good 13:57:05 though it could be too restrictive for some friendly packages 13:57:35 juhp, I know, some small subset of packages would be hurt by this 13:57:42 but perhaps they will just have to do with some post install script run by user say if needed 13:58:18 or perhaps more experienced packagers could be waived from this restriction later 13:58:24 juhp, yes, or if the package is more complex/involved, just pursue the same review as now 13:58:35 right 13:59:06 juhp, I think you raised some very good questions in your email 13:59:20 e.g. will packages be in git? will packages be tracked by bugzilla? 13:59:41 yes - maybe more apply to incubator 13:59:43 juhp: right, I wouldn't make "checking of macros in scriptlets" a rule for ugly repo, maybe just one of the conditions for automatic inclusion.. 13:59:58 hhorak, okay good point 14:00:05 please, just not other dist-git, different than we already have :) 14:00:10 that would be confusing 14:00:14 so is this something that we really need? I mean, it seems nice, but what prevents the package of creating a systemd unit that will rm -rf / and enable it? or sth. similar. I really think that this is needles 14:00:16 mmaslano, right 14:00:40 also we can't use fedora dist-git if review didn't pass 14:01:05 bkabrda, hmm true maybe it is too easy to circumvent I dunno 14:01:10 mmaslano, I agree 14:01:39 maybe we need dist-incubator or something later 14:01:39 I spoke with pingou at Devconf and we both really wished we could have something like GitHub, just for our packages 14:01:47 right 14:01:57 Or maybe we can just use GitHub :) 14:02:01 it would be nice to be able to point copr at a git repo 14:02:07 nod 14:02:34 probably not that hard to implement 14:02:36 For example, currently in COPR, bug reporting is "send email to author" 14:03:36 so, shall we discuss the format of automatic copr repo checks on mailing list and vote on next meeting? 14:03:37 right so they could use github instead 14:03:38 Bugzilla component for each package in ugly would probably "kill" it 14:03:39 right 14:03:39 yes 14:03:39 Something light-weight like GitHub issues would be ok 14:03:39 yeah 14:03:39 Also, collaboration could be improved 10-fold by using Pull requests 14:03:46 and actually help co-packagers 14:04:24 Also, inline code-comments could be very useful to comment on each-other's SPEC files 14:05:09 Do you guys think that relying on GitHub would be an option? 14:05:20 one per copr or per package? 14:05:44 dunno if it has to be github though - maybe any git host would be okay? 14:06:04 tjanez: I'd prefer to have own gitlab instance instead, assuming fedora infra would have the hardware to run it 14:06:50 bkabrda, yes, I'd prefer that too, but Gitlab has a host of issues 14:07:01 juhp: +1 any git host should work and if we have own github-like instance in fedora, it would be one of them 14:07:40 juhp, hhorak, I don't think any git-host would do since GitHub is much more that just git 14:08:15 Gitlab is a clone of the GitHub experience, but as I hear not really usable 14:08:33 tjanez, well i agree github is nice there are also other services like gitorious for example 14:08:58 tjanez: yes, features for collaboration, but for the sake of keeping sources for copr somewhere, any git host could work. what the project would use in the end, would be a decision of the project itself 14:09:23 * mmaslano would rather live without git and bz for now 14:10:00 I think Fedora Commons or stable Ring 2 git repos should be fedora hosted though probably 14:10:43 well it could be optional at this stage 14:10:45 git can be optional. fedorahosted is not very popular 14:11:06 mmaslano, maybe we can skip bug reporting, but version control is really useful 14:11:15 (by hosted I meant under Fedora infra) 14:11:45 yes, but from quite easy add repo, you have big project with many dependencies 14:12:26 not having packages in scm is really messy though after a while at least for anything but the simplest coprs 14:13:06 I'm not saying it shouldn't be in scm, but peopleprobably have their scm somewhere already 14:13:15 right 14:13:42 mmaslano, I see, you think we can rely on external git repos that are optional for now 14:13:49 yes 14:14:24 as long as the copr UI encourages git use I think it may be okay 14:14:45 copr input is srpm :) 14:14:48 * hhorak agrees, I just would like to see copr more co-operating with external repos.. 14:14:51 currently yes 14:15:00 hhorak: +1 14:15:27 hhorak, +1 14:16:05 mmaslano, would it be hard to point COPR at a git URL containing the SPEC file and sources? 14:16:50 Or should we just use some tools on the client's side that create an SRPM from the repo and push it to COPR 14:17:00 or maybe copr client could do it - currently has to be url to srpm, hmm 14:17:16 juhp :) 14:17:23 :) 14:17:39 tjanez: we should discuss this with msuchy, who's working on copr most of his time, I think 14:18:16 tjanez: tools on user side will be better, because since start was input srpm only 14:18:26 in theory just spec could be enough 14:18:54 bkabrda, mmaslano: ok 14:19:25 we could create a "thin github-like layer" that would have "build" button, which would compose srpm, send start copr build and then delete the srpm 14:19:40 ftr. currently, the copr client would have to copy the srpm to some public place (where?), since copr doesn't accept srpm bytes, only url to srpm currently. so it's not about client side only. 14:20:06 hhorak: true 14:20:07 well if we continue with requiring srpm then git repo workfliw is kind of moot indeed - would just be link on the copr page... 14:20:28 hhorak, right 14:20:29 bkabrda: good idea, but I'd like to see this feature as a part of copr, not as a separated service 14:20:36 hhorak, +1 14:20:37 I meant the "thin layer" would put the srpm on some public url, where copr could download it - the srpm would get deleted after a while 14:20:50 bkabrda, I like your idea 14:21:10 I would rather have it addede to copr too 14:21:18 hhorak: I don't know, it can look like part of copr from user perspective, but can be a different application, doesn't really matter I think 14:21:33 I should not be that hard to do IMHO 14:21:54 bkabrda: are there any reasons why to separate that from copr? 14:22:00 hhorak: we could have sth. like git.copr.fedoraproject.org or copr.fedoraproject/git/// 14:22:25 hhorak: I think that msuchy doesn't want functionality like that in copr for some reason, we should ask him. 14:22:42 okay 14:22:50 bkabrda: right, msuchy should be involved in such plans 14:22:59 also, it'd allow us to do clear separation between the two apps and someone could provide different frontends 14:23:26 bkabrda: because he wants to have copr easy :) 14:23:38 mmaslano: right, that's it :) 14:23:47 I find the srpm upload slightly awkward but I guess it works 14:24:27 but I guess we shouldn't make this feature a showstopper for the "fedora-ugly" idea, right? 14:24:42 true 14:24:52 but it would make ugly less ugly ;) :) 14:25:01 bkabrda, agreed 14:25:38 this could be developed in parallel and be optional from packager's POV 14:25:44 yes 14:26:16 such things would make packages less ugly and more on the incubation path 14:26:49 true 14:27:15 I think git should be mandatory for incubator anyway 14:28:08 #proposal bkabrda will talk to msuchy about his thoughts on providing github-like frontend for copr (implement in copr itself vs. do it as a standalone app) 14:28:31 bkabrda, +1 14:28:52 * jreznik is back - rereading through the backlog 14:29:20 can we also ask him about accepting git repo urls in addition to srpm urls? 14:29:26 bkabrda: will you post the talk resolution to the list? 14:29:42 juhp: we can do that, but I don't think he'll agree :) 14:29:47 hhorak: sure 14:29:48 okay :) 14:29:55 just testing :) 14:30:01 bkabrda, +1 14:30:18 #action bkabrda will talk to msuchy about his thoughts on providing github-like frontend for copr (implement in copr itself vs. do it as a standalone app) and post discussion result on our mailing list 14:31:38 as for ideas for copr repo checks before inclusion to "fedora-ugly", should we discuss them on our ML before next meeting? 14:32:29 bkabrda: I guess so 14:32:29 bkabrda, yes, and have some proposals for a small policy that we will enforce 14:32:46 tjanez: sure, let's brainstorm that on the ML 14:33:01 also, I would be for brainstorming a better name than ugly 14:33:22 I like Playground and my proposals 14:33:24 I guess another question is what process or who would generate the ugly repo (daily?)? 14:33:41 #action all: discuss policies/procedures for accepting copr repo into "fedora-ugly" on our ML 14:33:44 I like Playground too 14:34:14 #proposal propose better names for "fedora-ugly" on our ML 14:34:21 +1 14:34:25 +1 14:34:59 fedora-ulgy 14:35:06 lol 14:35:14 #action all: propose better names for "fedora-ugly" on our ML 14:35:34 jreznik, did you caught up? 14:35:37 so, anything more to discuss today, or shall I end the meeting? 14:36:13 probably better to postpone the scl discussion for later 14:36:17 bkabrda, it's been very long already, I think we should finish 14:36:48 +1 finish ;) 14:39:04 tjanez: yep, I'm good with stuff written above 14:39:36 jreznik, ok, good to hear that you're on-board 14:40:20 * jreznik is just nobody :) 14:41:16 ok, I'll end the meeting in 1 minute or so 14:42:05 #endmeeting