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