15:01:27 <langdon> #startmeeting modularity_wg
15:01:27 <zodbot> Meeting started Thu May 12 15:01:27 2016 UTC.  The chair is langdon. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:27 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:01:27 <zodbot> The meeting name has been set to 'modularity_wg'
15:01:33 <contyk> .hello psabata
15:01:34 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
15:01:39 <langdon> #topic roll call
15:01:40 <tflink> .hello tflink
15:01:44 <langdon> .hello langdon
15:01:46 <zodbot> tflink: tflink 'Tim Flink' <tflink@redhat.com>
15:01:49 <zodbot> langdon: langdon 'Langdon White' <langdon@fishjump.com>
15:01:56 <nils> .hello nphilipp
15:01:57 <zodbot> nils: nphilipp 'Nils Philippsen' <nphilipp@redhat.com>
15:02:07 <Kick_> .hello karsten
15:02:08 <zodbot> Kick_: karsten 'Karsten Hopp' <karsten@redhat.com>
15:02:26 <sct> .hello sct
15:02:27 <zodbot> sct: sct 'Stephen Tweedie' <sct@redhat.com>
15:02:27 <langdon> minor update as we get started.. i update the wg page with minutes..
15:02:42 <maxamillion> .hello maxamillion
15:02:42 <zodbot> maxamillion: maxamillion 'Adam Miller' <maxamillion@gmail.com>
15:02:46 <langdon> #info i updated the WG page with minutes
15:02:49 <langdon> #link https://fedoraproject.org/wiki/Modularity_Working_Group#Status_Reports
15:02:59 <langdon> #undo
15:02:59 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x7f34ae078050>
15:03:12 <langdon> #link https://fedoraproject.org/wiki/Modularity_Working_Group#Meeting_Minutes
15:04:15 <langdon> #chair tflink ausil harald sct cydrobolt mikedep333
15:04:15 <zodbot> Current chairs: ausil cydrobolt harald langdon mikedep333 sct tflink
15:04:23 <langdon> typing slowly today
15:04:26 <langdon> don't know why
15:04:36 <maxamillion> langdon: get it together man!
15:04:37 <maxamillion> >.>
15:04:57 <langdon> #link http://piratepad.nl/modularity-wg-agendas agenda
15:05:14 <langdon> #topic Review meeting time
15:05:30 <langdon> ok.. anyone know how to share the results from whenisgood?
15:06:36 <langdon> not that they are pretty... basically.. no one can do any time :/
15:06:40 <tflink> other than typing them out, no :(
15:07:02 <langdon> OH i found it! super small font
15:07:06 <tflink> how close do we get?
15:07:09 <langdon> #link http://whenisgood.net/hzd7x2b/results/72k7tq5
15:07:27 * threebean is here.
15:07:57 <langdon> 11am on mondays seems to be better for most
15:08:16 <langdon> #chair jkurik
15:08:16 <zodbot> Current chairs: ausil cydrobolt harald jkurik langdon mikedep333 sct tflink
15:08:25 <langdon> but.. tflink and jkurik have conflicts
15:08:35 <maxamillion> I somehow missed the whenisgood, but I'm a chicken in this chicken/pig breakfast scenario so it probably doesn't matter  .... also, 11am on mondays is good
15:08:36 <tflink> I can look into moving that conflict
15:08:40 <maxamillion> langdon: also, note the TZ ;)
15:08:42 <vkaras> what about using doodle?
15:08:53 <maxamillion> vkaras: doodle?
15:08:54 <tflink> wait, what timezone is that?
15:08:57 <langdon> maxamillion, sorry.. yeah.. mine is in ET
15:09:01 <maxamillion> 11am ET
15:09:03 <maxamillion> rgr
15:09:20 <langdon> maxamillion, vkaras doodle competitor to whenisgood
15:09:41 <langdon> jkurik seems not to be around..
15:09:45 <nils> can doodle do TZs?
15:09:55 <vkaras> yep, but you see all the people's votes
15:09:56 <langdon> nils, i think they both can.. no?
15:10:06 <langdon> and the link above will show you the results
15:10:11 <tflink> hrm, that's the qa meeting, not sure I can move that but I guess I can try doing 2 meetings at the same time
15:10:17 <sct> Monday 11am ET is probably the single hardest slot in my entire week to reschedule. :(
15:10:31 <maxamillion> langdon: ah ok
15:10:31 <sct> I simply can't move that one
15:10:33 <langdon> so.. we do not have responses from mikedep333 and cydrobolt who are think were the major conflicting ones
15:10:36 <nils> langdon: no idea, genuinely curious ;)
15:10:52 <langdon> sct, you are green for that..
15:11:21 <langdon> sct, do we have tz confusion?
15:11:27 <sct> langdon: uhoh.  I must have been looking at the wrong week --- my conflict is usually only every second week
15:11:38 <langdon> sct, ohh.. i think i have that one too
15:12:00 <langdon> but i am a chicken in that meeting.. so usually i could multi-task :)
15:12:19 <sct> langdon: Yeah.  I updated my response in whenisgood
15:12:31 <langdon> ok.. i say we table this and ask for the other members to respond.. and keep this time for now
15:12:33 <sct> so 7am on Tuesdays now looks better. :)
15:12:35 <langdon> sound like a plan?
15:12:41 <dgilmore> sorry I am late
15:12:45 <dgilmore> was in another meeting
15:12:49 <langdon> yes... i was avoiding that as i would be commuting ..
15:12:56 <langdon> but.. i think i can make it work..
15:13:01 <tflink> i'd rather not do 7am on tuesdays ... that's 5am for me
15:13:11 <tflink> but i can do my best to make it work
15:13:14 <dgilmore> 7am Eastern ?
15:13:15 <langdon> tflink, yeah.. you and yaakov
15:13:24 <dgilmore> I can not make that ever
15:13:27 <langdon> dgilmore, correct.. showing my bias ;)
15:13:34 <dgilmore> it is when I am taking my daughter to school
15:13:35 <langdon> dgilmore, ha.. i hear ya..
15:13:43 <langdon> i wonder if we should alternate
15:13:46 <yselkowitz> langdon, 07:00 ET? not happening, sorry
15:13:51 <lkocman_> let’s do something else than “when should we do this meeting” :-)
15:14:01 <langdon> like 7am 1 week and 11am thurs the alt week
15:14:05 <lkocman_> what about what’s the best way to start using koji sign repos instead of pungi createrepos :-)
15:14:06 <vkaras> I think Langdon has all the responses
15:14:15 <dgilmore> sorry its when I am getting up and getting her ready for school
15:14:17 <langdon> vkaras, no.. not yet
15:14:21 <dgilmore> wrong hour offset
15:14:35 <threebean> dgilmore: yeah, those early morning meetings are a no go for me too, same reason.  :(
15:14:53 <vkaras> so please can all people fill in the When Is Good?
15:14:54 <tflink> +1 on getting the remaining folks to respond to whenisgood, tabling for now
15:14:57 <langdon> dgilmore, can you do the whenisgood poll?
15:14:58 <bconoboy> even 11:00 ET is going to be a stretch for people on PDT
15:15:07 <langdon> bconoboy, right
15:15:10 <dgilmore> where is the whenisgood? I have not seen it
15:15:15 <tflink> bconoboy: better than 07:00 ET :)
15:15:25 <langdon> #link http://whenisgood.net/hzd7x2b
15:15:27 <bconoboy> tflink: Depends, I know some engineers who are still up at 07:00 ET :-)
15:15:29 <langdon> dgilmore, ^^
15:15:50 <langdon> ok.. agreed on tabling for more data?
15:15:52 <tflink> bconoboy: fair enough
15:16:04 <tflink> +1 on tabling for more data
15:16:40 <langdon> #action mikedep333 cydrobolt to fill in http://whenisgood.net/hzd7x2b
15:16:47 <langdon> did i do that right?
15:16:59 <langdon> #agreed table meeting time discussion for more data
15:16:59 <sct> looks good
15:17:13 <langdon> ok.. moving on
15:17:23 <langdon> #topic review package lifecycle diagrams (lead by threebean):
15:17:26 <threebean> hola!
15:17:28 <langdon> #undo
15:17:28 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x7f34af058c90>
15:17:31 <lkocman_> langdon: dgilmore, threebean http://taiga.fedorainfracloud.org/project/langdon-modularity/us/61?kanban-status=411
15:17:31 <threebean> doh.
15:17:31 <langdon> #topic review package lifecycle diagrams
15:17:34 <lkocman_> can I have some feedback?
15:17:40 <lkocman_> uh sorry for jumping in
15:17:49 <langdon> lkocman_, let's wait for the open floor part
15:17:54 <lkocman_> langdon: +1
15:17:57 <langdon> i am not sure anyone has enough context yet
15:18:07 <langdon> #chair threebean
15:18:07 <zodbot> Current chairs: ausil cydrobolt harald jkurik langdon mikedep333 sct tflink threebean
15:18:16 <langdon> threebean, care to link? start discussion?
15:18:19 <threebean> yeah, one sec.
15:18:27 <threebean> so, for context, here's the diagram we put up last week:
15:18:29 <threebean> http://threebean.org/img/modularity/life-of-a-package-update-current.png
15:18:46 <threebean> that's a depiction of the lifecycle of an rpm package update through our systems.
15:19:00 <langdon> #link http://threebean.org/img/modularity/life-of-a-package-update-current.png package lifecycle (future, proposed)
15:19:20 <threebean> it's relevant only because however we end up doing modules, I don't think we want to reinvent too many wheels.  we can't overburden the infra teams by creating two separate pipelines.
15:19:28 <threebean> so, here's the diagram for today:
15:19:30 <threebean> http://threebean.org/img/modularity/life-of-a-package-update-future-no-automation.png
15:19:46 <langdon> oops..
15:19:46 <dgilmore> langdon: ausil as a chair does not work for me
15:19:50 <langdon> #undo
15:19:50 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x7f34ae2f5ed0>
15:19:54 <threebean> that's a depiction of the lifecycle of a package update and module updates in the modularity world, as far as we have a proposal so far.
15:19:59 <langdon> #chair dgilmore
15:19:59 <zodbot> Current chairs: ausil cydrobolt dgilmore harald jkurik langdon mikedep333 sct tflink threebean
15:20:05 <maxamillion> threebean++
15:20:06 <threebean> note that it intentionally does not include any of the automation components that we know we'll need.
15:20:28 <threebean> it describes what packagers would have to do to buildand maintain modules.. so that we know what we will need to be automating.
15:20:48 <threebean> see the four different scenarios at the top.  for a new package, updating modules, updating rpms, and backporting a security patch.
15:20:57 <lkocman_> the maintenance of module and packager relationship is difficult
15:21:09 <sct> threebean: Is there a draft that includes automation?  The first thing that struck me on this diagram was the lack of automated module rebuilds when an included component gets rebuilt.
15:21:09 <threebean> I think the first two are unsurprising.  but the second two will probably generate some questions.
15:21:22 <maxamillion> threebean: right
15:21:31 <threebean> sct: not at the moment.  but we know we'll need exactly that, yes.
15:21:55 <sct> threebean: yeah.  I'd like to see that, because I think it sheds a different light on the bits even in this picture;
15:22:09 <langdon> sct not yet.. we wanted to make sure we knew every step first.. then figure out where to automate.. without automation this thing doesn't work at all
15:22:14 <Mathnerd314> there's also my diagram, it combines everything in one confusing mess: https://insearchoftheultimateprogramming.blogspot.com/2016/05/fedora-workflow-diagram.html
15:22:20 <sct> threebean: for example, having a git hash for a component as input to the module sort of works here
15:22:26 <langdon> sct, can you elaborate on how it would be different?
15:22:49 <sct> threebean: but as soon as we automate rebuilds, we can't really do that --- we need the *branch* to specify the input to the module, and detect when the head of that branch changes;
15:22:55 * threebean nods
15:22:56 <threebean> I agree.
15:23:18 <threebean> using git hashes of the components as the inputs for modules doesn't allow us to constrain what combinations of components are supported.
15:23:19 <sct> and the git hash is still important, but it's only set as/when the module is built, it's not input to that process.
15:23:47 <sct> Well, we need to constrain which branches are built, and which subpackages of the builds from components on those branches
15:23:48 <langdon> why not? shouldn't the module owner specify which git-hash to use for their module?
15:23:51 <sct> git hash isn't quite enough
15:24:01 <threebean> if we have some ancient build of a component.. some old module could depend on it, and we'll be stuck backporting patches to that for eternity.
15:24:17 <sct> eg. we don't necessarily have -devel in a runtime module, it could conceivably be in a separate developer module
15:24:25 <langdon> just because fedora-infra knows about every git-hash doesn't mean the policy can't disallow use of most..
15:24:42 * threebean nods
15:24:48 <sct> so git hash can tell us which component version we're looking at, but it's still not sufficient to tell us what we're putting in the module.
15:25:07 * contyk disagrees
15:25:10 <threebean> langdon: then we'll need a system to represent that allowance.  we learned something from the exercise!  :)
15:25:31 <sct> So I really think the module owner needs to specify component + branch + (optional) subpackage-list
15:25:33 <dgilmore> sct: git hash changing could/should set off module rebuild
15:25:53 <sct> dgilmore: Only if we know which branch to look at to see if the hash of HEAD has changed
15:26:16 <sct> We definitely need to *record* the git hash
15:26:21 <threebean> sct: +1
15:26:27 <sct> it represents precisely which moment in time goes into the build
15:26:33 <langdon> sct, i think you need to define what you mean by "branch" .. obviously git-branch.. but branch of what?
15:26:44 <threebean> the dist-git rpm repo.
15:26:46 <threebean> right?
15:26:58 <sct> langdon: That's a deeper question in its own right. :)
15:27:02 <langdon> lol
15:27:02 <threebean> oh my..
15:27:15 <sct> langdon: I think we need consistency between the branching in dist-git, and the tagging in koji,
15:27:21 <sct> so "branch" *should* have a consistent meaning across those
15:27:31 <langdon> i guess i am just thinking there is a component.. which i want to include in a module.. so i say "give me component x at git-hash y" ..
15:27:51 <sct> langdon: I don't think that's as useful as a branch ---
15:28:03 <lkocman_> sct: well we do have branch to target consistency now … but I thought that we want to break that
15:28:14 <sct> langdon: if it's just a hash, then when a developer updates one of the components in my module (eg. somebody contributes a security fix),
15:28:40 <sct> then I have no idea if that fix has been applied to, and built, in the branch I care about... all I see is the hash, that's still there, and might or might not be obsolete
15:28:48 * threebean nods
15:29:00 <sct> I can't update a hash because a hash is *by definition* referencing a fixed point in time.
15:29:07 <sct> I can update a branch, and see that the hash has changed
15:29:14 <sct> but only if I have the branch information
15:29:20 <langdon> right.. thats why i was asking about "what you mean by branch" ..
15:29:37 <sct> and when that branch (in dist-git --- which is where we have hashes) is updated
15:29:39 <threebean> sct: we don't necessarily need to store the git hash history.  we could fire a message bus event when a branch is updated, and use that to trigger rebuilds.
15:29:50 <langdon> ok.. so component-x, branches for "in use versions" (or policy decision), hash on the branch
15:29:54 <sct> we need to track where it is built and tagged in koji so we pick up the right binaries from it
15:30:32 <lkocman_> sct: well the module would be represent by tag right? and the specific build would get tagged into specific tag in order to be part of module
15:30:32 <threebean> sct: that gets into another question, about re-using binaries.  can we do that at all?
15:30:56 <sct> threebean: We could use message bus, yes; but if we can record hashes from the outset, that helps our ability to backtrack later on
15:31:05 <threebean> sure, yes.
15:31:13 <sct> to check exactly what went into a build when we're debugging it later.
15:31:29 <sct> We don't necessarily need the hash to trigger the rebuild, but the hash is still useful to record.
15:31:48 * langdon notes that automatic rebuilds are part of automation.. and should be (probably) off topic for now..
15:31:55 <threebean> ;)
15:32:10 <langdon> like lets figure out what each step is.. and then we can figure out how to make it more performant/automated
15:32:22 <langdon> or where we can short-circuit
15:32:22 <sct> langdon: Yes.  As long as the schema we are defining here can do the automation part later on (which was my concern about getting the use of hashes right)
15:32:47 <langdon> sct, right.. i gotcha.. we need a little future thinkgin.. i just don't want to go to far
15:33:11 <threebean> yeah, I think we still have disagreement about that question.  How about we take that up further in #fedora-modularity after the meeting?
15:33:17 <sct> langdon: Yep.
15:33:23 <langdon> threebean, which part?
15:33:32 <threebean> langdon: handling of hashes, branches, tags, etc.
15:33:34 <contyk> hashes as build input
15:33:51 <langdon> sure.. or ML.. or irc -> ml.. :)
15:33:57 <threebean> cool.
15:34:02 <langdon> ok.. do you want to talk about more of the diagram?
15:34:10 <threebean> I have a separate place in the diagram to point out.. yes.
15:34:26 <threebean> the big box in the middle, describing a koji module build.
15:34:52 <threebean> contyk and lkocman_ have sketched out some plans and questions about that here:  piratepad.nl/module-build
15:35:23 <langdon> #link http://threebean.org/img/modularity/life-of-a-package-update-current.png life of a package (present)
15:35:41 <langdon> #link https://insearchoftheultimateprogramming.blogspot.com/2016/05/fedora-workflow-diagram.html life of a package (present, alternate)
15:35:46 <threebean> there are a number of things to consider.. but one to point out is the potential lack of re-using binary components.
15:35:59 <threebean> of instead building components from source for each module build.
15:36:05 <langdon> #link http://threebean.org/img/modularity/life-of-a-package-update-future-no-automation.png life of a package (future, proposed, no-automation)
15:36:17 <contyk> threebean: I *think* we could detect when it's not necessary
15:36:28 <contyk> threebean: the same hash, the same buildroot
15:36:29 <langdon> #link http://piratepad.nl/module-build thoughts on module-build
15:36:36 <langdon> sorry for all the links
15:36:55 <threebean> ok.  but the default state would be to rebuild everything from source, yes contyk?  and then we would only try to not rebuild components if we could, for optimization's sake?
15:37:12 * contyk nods
15:37:20 <langdon> yes ... else it is automation/optimization :)
15:37:43 <langdon> to elaborate.. where does it get build-root-type information from?
15:37:50 <lkocman_> threebean: what does pungi nightly job does in your “future-no-automation” document?
15:38:10 <threebean> lkocman_: oh, that's hand-wavy stuff for the work you've been doing.  ;)
15:38:12 <lkocman_> threebean: it looks like it produces repo + usual stuff to me
15:38:19 <langdon> lkocman_, let's come back to that
15:38:32 <langdon> lets stick with "how things get built" for the moment
15:38:33 <threebean> yeah.  nothing major.  puts the repos together into the compose directory, to be shipped out to mirrors.
15:38:48 <threebean> stores stuff in pdc, etc.
15:38:51 <lkocman_> threebean: uh so we do create repo in it or get it from koji?
15:39:00 <lkocman_> threebean: that’s basically my question
15:39:06 <lkocman_> threebean: otherwise yes I agree
15:39:13 <langdon> lkocman_, threebean  later please
15:39:48 <langdon> contyk, threebean sct are build-roots specified in the module? where do they come from? are they built from source each time too?
15:40:17 <contyk> langdon: they are defined by other modules, listed as build deps of the module
15:40:22 * threebean nods
15:40:33 <contyk> langdon: these would be represented as koji tags and your buildroot would inherit from them
15:40:46 <sct> langdon: That's complex.  Really complex.  It's a whole next set of discussions around branching
15:41:12 <sct> and whether to have module branches that cross over different build roots and create multiple binary instances, one per build-root.
15:41:26 <sct> langdon: My gut reaction is to come back and think about that much more deeply later on.
15:41:35 <maxamillion> +1 buildroots, branches, and targets gets off in the weeds fast
15:41:52 <threebean> maxamillion: we're getting close to needing to solve that.  but, yes.
15:41:53 <sct> But it's definitely an important topic.
15:41:57 <langdon> don't we need to know it now?
15:42:09 <maxamillion> threebean: fair
15:42:19 <langdon> or at least have a hack that we think is possibly the right answer?
15:42:24 <langdon> to experiment with
15:42:48 <threebean> langdon: some of those are elaborated in the pad here:  http://piratepad.nl/module-build
15:42:49 <contyk> langdon: we'd like to implement the thing we were talking about now
15:42:50 <maxamillion> threebean: I'm still playing catch up and reading everything, I've been kind of disconnected to what y'all have been up to for the last few weeks
15:43:03 <contyk> if it proves to be wrong/insufficient, we can always create something else
15:43:32 <langdon> ack .. ok.. i wasn't sure if it was covered in there and an agreed upon "start"
15:43:54 <threebean> see line 97:  "card idea:  what will be installed in buildroot"
15:44:25 <langdon> threebean, ok.. cool
15:44:57 <threebean> ok.  thanks all.  I hope its okay that we deferred the automation stuff to another week.  it was really helpful for me to work through the details of what would need to be done without automation first.
15:45:03 <langdon> threebean, so do feel like the big-koji-box is covered? do we have any open questions?
15:45:20 <threebean> langdon: good to go for now.  just wanted to draw attention to it and see if any questions jumped out.
15:45:41 <sct> langdon: Well... we're starting with the idea of module owners specifying which branches a build comes out of
15:45:59 <sct> and we're sort-of assuming there that it might not be the same branching that the major distro version follows
15:46:20 * threebean nods
15:46:22 <maxamillion> threebean: seems sane at face value, I'm sure the pain points will be in the details somewhere though ... granted I'm sure they can be resolved, just someone is going to have to do the potentially painful work to resolve them
15:46:22 <sct> so I think we're at least building in the right assumptions to have modules not tied to a build-root
15:46:33 <sct> even if we haven't got all the details planned.
15:47:02 <langdon> ok.. i also want to propose here.. rather than in just one off convos.. modules can not depend on other modules (except core and non-runtime-deps) for the near term... to get us to think about this in terms of "big modules" without having to look at sharing..
15:47:48 <langdon> e.g. the drupal-module does *not* depend on a php module or a httpd-module even if we ship all 3 and they share binaries (most of the time)
15:48:13 <geppetto> langdon: But then we have to solve packages in multiple modules … which I thought we didn't want?
15:48:50 <contyk> we need to solve parallel installability
15:49:13 <langdon> geppetto, you mean depsolve? well.. the depsolve step is really a user convenience right? we want to specify, specifically, all deps in the module-definition right?
15:49:17 <contyk> we need to figure out how to deal with file conflicts (at least) without changing rpms
15:49:35 <langdon> contyk, sorta.. or, we can cheat via policy for now..
15:49:56 <langdon> aka .. guidelines: you may only use this version of httpd-rpm in any module
15:50:35 <contyk> that wouldn't be enough
15:51:03 <threebean> yeah, they'd have different buildroots ;)  different bits?
15:51:03 <contyk> the exactly same version built exactly the same sources might differ on binary level if it was built in different buildroots
15:51:10 <threebean> contyk++
15:51:10 <zodbot> threebean: Karma for psabata changed to 1 (for the f23 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:51:46 <langdon> well.. this isn't prod yet.. so .. while that is true.. it is unlikely to actually result in a prblem, right?
15:52:06 <geppetto> langdon: define problem?
15:52:18 <langdon> geppetto, stuff doesn't run ;)
15:52:30 <geppetto> yeh, rpm will go nuts
15:53:00 <langdon> ahh.. yes.. hmmm
15:53:12 <threebean> proposal:  table the parallel installability question for another day.
15:53:25 <geppetto> There's always rpm2cpio … /me runs
15:53:40 <langdon> other ideas of how to implement it that way? i just don't want us to fall in to the trap of looking for module re-use.. because we have that already.. in the current model (fedora-today)
15:53:41 <nils> geppetto: +1 :)
15:54:02 <contyk> langdon: and it's a good thing! :)
15:54:08 * nils gotta split soon
15:54:16 <contyk> but I know it's not what you want
15:54:25 * maxamillion needs to duck out, thanks all!
15:54:29 <langdon> ok.. lkocman_ did you get your answer on pungi post koji?
15:54:31 * contyk waves
15:54:42 <sct> langdon: Modules *need* to depend on other modules from a module maintainer/developer perspective
15:54:42 <geppetto> langdon: you mean non-bundling and you want to allow bundling? … that's fine, just the bundled bits can't go where the normal bits go
15:54:51 <lkocman_> langdon: let me bring it up
15:54:58 <sct> langdon: but a user needs to be able to deal with the module stack as a single whole
15:55:01 <lkocman_> http://taiga.fedorainfracloud.org/project/langdon-modularity/us/61
15:55:09 <lkocman_> I was especially intersted in you guys watching this thing
15:55:19 <langdon> lkocman_, u sure that is the right link?
15:55:24 <sct> langdon: I'm writing up right now something to try to help make that distinction so we don't talk ourselves in circles confusing the different use cases!
15:55:36 <Kick_> that link doesn't work for me
15:55:44 <lkocman_> langdon: is taiga so dumb that it produces urls which are not working?
15:56:05 <langdon> lkocman_, nice.. may be about the redirect.. langdon-modularity doesn't exist any more
15:56:37 <lkocman_> sure wait a sec
15:56:43 <langdon> ok.. only 4 minutes left.. should this move to the ML?
15:57:50 <langdon> ok.. i am saying let's move it there.. or next week.. or #fedora-modularization
15:58:08 <langdon> #topic open floor
15:58:20 <lkocman_> http://taiga.fedorainfracloud.org/project/modularity/us/235
15:58:20 <langdon> i think lkocman_ you had something you wanted to put here too?
15:58:49 <lkocman_> pretty much just this link
15:58:55 <lkocman_> and I’d like to see people agree about this
15:58:59 <lkocman_> or tell me something different
15:59:09 <lkocman_> since we don’t want to invest in something that we don’t agree on
15:59:21 <lkocman_> I’d like ralph and dennis gilmore on watchlist
15:59:26 <lkocman_> and see some comments
15:59:35 <lkocman_> threebean: dgilmore ^
15:59:37 <langdon> lkocman_, i think you should take the question and put it to the ML? then they can reply offline
15:59:38 * threebean clicks
15:59:55 <lkocman_> langdon: I thought that’s what taiga and comments section is for
15:59:57 <nils> gtg, see ya
16:00:01 <lkocman_> let’s drop taiga then :-)
16:00:04 <langdon> lkocman_, no.. not really
16:00:07 <dgilmore> q/me reads
16:00:10 * dgilmore reads
16:00:25 <langdon> the cards should be about actions and outcomes.. not about questions.. not really a ticketing system..
16:00:30 <lkocman_> spike?
16:00:32 <dgilmore> lkocman_: today its not possible to use signed repos
16:00:41 <sct> Yeah, it's OK to have a card for a spike / research topic
16:00:41 <lkocman_> dgilmore: I know
16:00:45 <dgilmore> lkocman_: signed repos can only make a repo of the entire contents on the tag
16:00:49 <lkocman_> I know
16:00:58 <sct> as long as somebody owns figuring things out and can take ownership of the card
16:00:59 <lkocman_> dgilmore: we did have some discussion about it
16:01:06 <lkocman_> with mikeb and ralph
16:01:08 <geppetto> lkocman_: So the idea is that pungi is just a clever mergerepo for multiple koji builds?
16:01:10 <langdon> lkocman_, a spike is a research project.. this isn't a research project it is a decision about direction.. which should be done in the normal models of ML or perhaps an agenda item for a WG session
16:01:24 <lkocman_> geppetto: not mergerepo but “clerver metadata wrapper that connects stuff"
16:01:29 <dgilmore> lkocman_: I would also say that we need another way to work as well
16:01:32 <lkocman_> the question is whether we still see pungi ad generating repos
16:01:49 <dgilmore> lkocman_: kji signed repos are not an option to run at home
16:01:53 <lkocman_> dgilmore: okay so we all agree that we still want pungi to generate repos till signed repo is more advanced?
16:01:57 <lkocman_> threebean: ^
16:02:05 <lkocman_> dgilmore: or cover local usecases
16:02:10 <lkocman_> just like I wrote in spike
16:02:11 <dgilmore> lkocman_: signed repos should only be a process optimisation
16:02:16 <lkocman_> dgilmore: okay
16:02:21 <lkocman_> threebean: ^ agree?
16:02:24 <threebean> there we go.  sure.
16:02:27 <dgilmore> unless we decide people can not do testing at home
16:02:28 <lkocman_> okay
16:02:34 <lkocman_> dgilmore: +1
16:02:36 * lkocman_ is very happy
16:02:36 <threebean> dgilmore: -1 to that.
16:02:45 <dgilmore> threebean: indeed
16:02:45 <lkocman_> ban people from that?
16:03:14 <dgilmore> so we need to be able to do everything without koji, but we can do thinsg in koji as an optimisation
16:03:21 <lkocman_> dgilmore: and the future goes pungi-createrepo -> for local usecases and try to go to koji signed repo for production stuff?
16:03:25 <langdon> ok.. we are definitely over time.. i think this needs to be on the mailing list.. not everyone is here..
16:03:32 <dgilmore> lkocman_: sure
16:03:35 <lkocman_> dgilmore: so createiso in koji can use it (like from koji)?
16:03:44 <threebean> and we should get pungi createrepo and koji's signed repo stuff to share code
16:03:52 <threebean> so we're not maintaining two stacks that do something Very Important.
16:03:53 <lkocman_> threebean: yup
16:03:56 <dgilmore> lkocman_: yep
16:04:00 <lkocman_> okay
16:04:01 <lkocman_> thanks
16:04:09 <lkocman_> threebean: I totally agree … I’ll create card on that
16:04:13 <lkocman_> threebean: they should do the same thing
16:04:19 <lkocman_> just from different sources
16:04:19 <threebean> yes, thanks!  :)
16:04:24 <langdon> lkocman_, what will you create a card for?
16:04:38 <lkocman_> pungi-createrepo being local representation of koji signed repo
16:04:41 <lkocman_> not something different
16:04:47 <dgilmore> langdon: do I need to be added to taiga?
16:04:47 <lkocman_> I mean as far as behavior and output goes
16:04:51 <langdon> not a decision i hope.. 1) it isn't decided 2) taiga is not for capturing decisions
16:05:14 <lkocman_> langdon: that’s what pub discussions are for right
16:06:17 <langdon> lkocman_, yes.. mailing list.. possibly irc channel.. on ML you can ask for a vote.. if necessary.. but.. the decision belongs in a document about how things work.. probably like the one threebean is doing the drawing for.. the cards are to "write a document"
16:06:44 <langdon> ok.. gonna end the meeting
16:06:47 <threebean> +1
16:06:52 <langdon> lets move to #fedora-modularization
16:06:58 <langdon> #endmeeting