2011-10-26 Meeting Log

Information

• Date: 26 October 2011, 17:00-18:00 UTC
• Agenda
• Moderator: Matthew Weier O'Phinney (nickname weierophinney)

Summary

ACL / RBAC

There have been some calls to either remove Zend\Acl, replace it, or add an alternative. The discussion centered around these questions, and goals for ACLs in ZF2.

• Zend\Acl certainly works now, but should be refactored to use SPL data structures, interfaces, and iterators internally, target for beta3 at the latest.
• Eventually (v2.1) an alternative RBAC implementation should be developed, but we need a comprehensive proposal. Ralph says if we do the refactor, getting RBAC behavior out of what we have may be relatively easy.

RFC vs Proposal

This was raised last minute by Mike Willbanks (nickname lubs), out of some confusion regarding the difference between proposals and RFCs.

• Rewrite/refactor of existing components, or new architecture == RFC, New component == Proposal
• lubs asked about Service components... Matthew says, 'I think with that stuff, it may be good enough to simply throw out on the ML and on the wiki, "Hey, I'm working on this" and do it in a branch of your own.'
• DASPRiD will email the CR-Team to organize a meeting to discuss timelines and processes. (done)
  • Matthew: "we need to get the proposal process working again. It's halted right now."
• We will reach out to current proposal authors to update their proposals for 2.0.
• robertbasic proposes we make the CR teams work more transparent / visible, "say, a digest blog post + ML thread once in a while"

Module Installation / Distribution

This conversation centered around Evan Coury's (nickname EvanDotPro) module distribution and installation RFC.

• Removal of modules should also remove application.config.php entry somehow (RFC will be updated)
• Zend is open to the idea of hosting a community module pyrus channel; details to be figured out later.
• Module installation / distribution is waiting on CLI work from robertbasic and mattcockayne (CLI will be a topic of the next meeting)

Log

Oct 26 17:00:13 <weierophinney>	Okay, everyone... starting.... NOW
Oct 26 17:00:26 <weierophinney>	EvanDotPro, have you updated the agenda?
Oct 26 17:00:28 <lubs>	damn... ok - brb grabbing coffee will catch back up soon :)
Oct 26 17:00:35 <EvanDotPro>	done
Oct 26 17:00:45 <EvanDotPro>	hurry go vote ;)
Oct 26 17:00:46 <weierophinney>	Agenda today is here: http://framework.zend.com/wiki/display/ZFDEV2/2011-10-26+Meeting+Agenda
Oct 26 17:00:49 <weierophinney>	I'll be moderator today
Oct 26 17:00:58 <weierophinney>	So, let's begin: ACLs
Oct 26 17:01:15 <weierophinney>	Can somebody explain what a "simplified RBAC component" would be, and why we might want it?
Oct 26 17:01:38 <EvanDotPro>	ralphschindler: want to take this?
Oct 26 17:01:50 <ralphschindler>	sure
Oct 26 17:02:10 <ralphschindler>	its basically ACL as we have it, but the ability to attach multiple roles to multiple resources
Oct 26 17:02:24 <ralphschindler>	so, instead of it looking like a tree, it looks more like a mesh
Oct 26 17:02:40 <weierophinney>	ralphschindler, so, instead of role inheritance, multiple roles?
Oct 26 17:02:49 <weierophinney>	how is that "simplified"? (just curious)
Oct 26 17:02:51 <intiilapa>	subject is ACL?
Oct 26 17:02:53 <weierophinney>	intiilapa, yes
Oct 26 17:03:31 <lubs>	it becomes more simplified in terms of the interface after it has been setup; the actual setup is more difficult IMO :)
Oct 26 17:03:58 <weierophinney>	So, my immediate question is: do we need it for 2.0, or could it wait until 2.1?
Oct 26 17:03:58 <ralphschindler>	well, iirc, there is a situation where if you want to simulate mutli-roles to multi-resources, it requires a lot of iterative boilerplate code
Oct 26 17:04:03 <lubs>	http://en.wikipedia.org/wiki/Role-based_access_control - look at the graph in how they kind of work... it can become increasingly difficult
Oct 26 17:04:11 <ralphschindler>	i think it can wait honestly, unless someone wants to do it
Oct 26 17:04:26 <ralphschindler>	I'd rather we ditch Zend\Authorization though
Oct 26 17:04:29 <intiilapa>	ZF need a drop-in solution for ACL IMHO
Oct 26 17:04:49 <lubs>	RBAC is highly needed in my world but we're also not the common use case
Oct 26 17:04:49 <ralphschindler>	i'd rather not ship Authorization at all, if we plan on doing RBAC
Oct 26 17:04:54 <weierophinney>	ralphschindler, if the current Zend\Acl works as an interim measure, why would we ditch it?
Oct 26 17:05:04 <robertbasic>	ralphschindler: but one can always create a group, which is basically multiroles, no? (have code for this, need to dig it up)
Oct 26 17:05:14 <ralphschindler>	80% of it can be replaced by the SPL
Oct 26 17:05:20 <weierophinney>	robertbasic, that's what I've done in the past.
Oct 26 17:05:27 <SpiffyJr>	weierophinney: same
Oct 26 17:05:34 <lubs>	robertbasic: kind of... it actually becomes extremely convoluted
Oct 26 17:05:36 <ralphschindler>	RecursiveIteratorIterator/RecursiveIterator instead of these nested multi-dim arrays with references
Oct 26 17:05:41 <weierophinney>	ralphschindler, what does Zend\Acl have to do with SPL? or are you talking about the data structures it implements?
Oct 26 17:05:45 <ralphschindler>	yes
Oct 26 17:05:46 <weierophinney>	ah, okay
Oct 26 17:05:49 <ralphschindler>	its very convoluted
Oct 26 17:05:53 <EvanDotPro>	i'd like to see rbac, but it's not a huge rush for me. it really just simplifies access control logic over ACL, imo.
Oct 26 17:06:02 <lubs>	EvanDotPro: +1
Oct 26 17:06:11 <weierophinney>	ralphschindler, so, could we refactor that to use the SPL data structures for now, and work on another solution for 2.1?
Oct 26 17:06:19 <weierophinney>	EvanDotPro, would that work for you as well?
Oct 26 17:06:21 <ralphschindler>	that sounds like a plan
Oct 26 17:06:37 <EvanDotPro>	The way Dolf Schimmel (he wrote the Zend_Rbac proposal) explained it to me was this: RBAC removes the the "permission" part and is really just roles->resource (yes or no)... but a resource could be like "edit_article"
Oct 26 17:06:38 <ralphschindler>	i'd like to see some interfaces for it, and example use cases- that would help us identify the workload
Oct 26 17:06:54 <intiilapa>	EvanDotPro: Dolf don't want RBAC since this proposal
Oct 26 17:07:08 <weierophinney>	EvanDotPro, yeah, that makes sense -- instead of having resource "article" with permission "edit"
Oct 26 17:07:11 <intiilapa>	I have discuss with hum about this subject a few months ago
Oct 26 17:07:21 <lubs>	EvanDotPro: generally speaking "permissions" are part of the RBAC but they are more or less a hand away...
Oct 26 17:07:25 <EvanDotPro>	intiilapa: i was just referencing him as my source for the definition :)
Oct 26 17:07:28 <intiilapa>	ok
Oct 26 17:07:32 <weierophinney>	intiilapa, do you recall why he no longer wants it?
Oct 26 17:07:56 <intiilapa>	weierophinney: no, I remember my discuss with Ralph about AccessControl ^^
Oct 26 17:07:57 <lubs>	IMO part of the issues that are faced with most ACL systems in general has a main issue: Role / Resource works just fine but when you get to finer grained permissions things fall apart and the interface becomes ugly.
Oct 26 17:08:07 <lubs>	we find we bolt those on
Oct 26 17:08:10 <mattcockayne>	ok.. for my pennys worth a simpler interface would be good... however I quite like the granularity i get out of the current ACL
Oct 26 17:08:23 <weierophinney>	So, what I'm hearing is:
Oct 26 17:08:47 <weierophinney>	* Zend\Acl certainly works now, but should be refactored to use SPL data structures, interfaces, and iterators internally
Oct 26 17:08:50 <EvanDotPro>	mattcockayne: from what i've seen, you don't lose any granularity with RBAC, it's really just a simpler interface to accomplish the same thing.
Oct 26 17:09:09 <weierophinney>	* Eventually an alternative RBAC implementation should be developed, but we need a comprehensive proposal.
Oct 26 17:09:21 <intiilapa>	weierophinney: rules should be array / _db_ / whatever
Oct 26 17:09:40 <mattcockayne>	i tend to find having permissions makes it appear more granular when implementing an ACL that the end user can manipulate
Oct 26 17:09:41 <weierophinney>	EvanDotPro, my understanding is that it would be simpler in terms of consumption, but more difficult in terms of definition?
Oct 26 17:10:16 <SpiffyJr>	Having rule adapters for ACL might be nice - DB, Doctrine, Array, etc.
Oct 26 17:10:18 <mattcockayne>	having an end user try to grasp that they have five resources instead of one resource where they define permissions its a lot harder
Oct 26 17:10:19 <weierophinney>	intiilapa, right -- if we make the roles/resources/permissions into granular objects, bridges for different storage become simpler.
Oct 26 17:10:25 <WalterTamboer>	The current ACL can be used without permissions so what would RBAC give as a benefit over the current ACL implementation? I have not seen an answer for this yet.
Oct 26 17:10:25 <intiilapa>	weierophinney: we should have a complete documention about usage for service or allow edit to owner of resource (by Di?)
Oct 26 17:10:33 <EvanDotPro>	weierophinney: sounds about right; Dolf's proposal is about the most i've gone into it.
Oct 26 17:10:39 <weierophinney>	kk
Oct 26 17:10:48 <weierophinney>	Can we agree on the above, then? If so, the action items are:
Oct 26 17:11:04 <weierophinney>	* identify what refactoring needs to be done, and if any public interfaces need to be changed, in Zend\Acl
Oct 26 17:11:10 <ralphschindler>	i think so, if we do the refactor, getting RBAC behavior out of what we have is easy
Oct 26 17:11:12 <weierophinney>	* eventually a proposal for an alternate acl solution
Oct 26 17:11:20 <intiilapa>	don't forget relation between Acl and Navigation to choose menu or a widget to login/logout
Oct 26 17:11:34 <weierophinney>	or, as ralphschindler points out, make the refactor work such that we may not need the alternate solution.
Oct 26 17:11:41 <ralphschindler>	yep
Oct 26 17:11:42 <mattcockayne>	intiilapa: dont get me started on navigation
Oct 26 17:11:50 <weierophinney>	intiilapa, right... I think that means ACL has to be for beta3 at the latest.
Oct 26 17:11:52 <intiilapa>	mattcockayne: why?
Oct 26 17:12:02 <lubs>	sure - we can continue to make it work for now...
Oct 26 17:12:14 <mattcockayne>	just spent 3 days ripping it out of a system cause of performance issues
Oct 26 17:12:30 <intiilapa>	review Naviation in a PR :D
Oct 26 17:12:34 <intiilapa>	Navigation*
Oct 26 17:12:43 <EvanDotPro>	one main advantage of rbac is that it only "allows" access to resources, there's no "disallow" so it solves some design flaws in ACL.
Oct 26 17:13:01 <mattcockayne>	EvanDotPro: like a global deny?
Oct 26 17:13:07 <EvanDotPro>	(See ZF-5369)
Oct 26 17:13:12 <EvanDotPro>	http://framework.zend.com/issues/browse/ZF-5369
Oct 26 17:14:23 <weierophinney>	EvanDotPro, I look at that, and I think, hey, they did things in the wrong order.
Oct 26 17:14:25 <EvanDotPro>	There's more information on Dolf's (albeit dated) Zend_Rbac proposal here: http://framework.zend.com/wiki/display/ZFPROP/Zend_Rbac+or+Zend~Access~Rbac+-+Dolf+Schimmel
Oct 26 17:14:49 <weierophinney>	I actually thought Zend\Acl was "deny all" by default. I need to look at it more closely later, though.
Oct 26 17:14:52 <intiilapa>	mattcockayne: yes, in zf1 some components have performance issues, but when you use a framework, you want a solution on Navigation/Acl/Sitemap/Menu for productivity
Oct 26 17:15:02 <intiilapa>	weierophinney: +1
Oct 26 17:15:24 <weierophinney>	So... move on to next topic?
Oct 26 17:15:32 <EvanDotPro>	yep, next topic.
Oct 26 17:15:43 <weierophinney>	RFC vs Proposal
Oct 26 17:15:51 <weierophinney>	Who's hear from the CR Team?
Oct 26 17:16:08 <mattcockayne>	CR team????
Oct 26 17:16:10 <weierophinney>	I see DASPRiD, kokx,...
Oct 26 17:16:11 <intiilapa>	-> DASPRiD :p
Oct 26 17:16:18 <weierophinney>	Bittarman, 
Oct 26 17:16:31 <robertbasic>	mattcockayne: Community Review Team. Nice guys, if you pay them.
Oct 26 17:16:32 <weierophinney>	We're missing padraic, farrelly and akrabat
Oct 26 17:16:39 <mattcockayne>	lol
Oct 26 17:16:43 <intiilapa>	robertbasic: pay :o
Oct 26 17:16:52 <weierophinney>	I'm trying to highlight you folks...
Oct 26 17:16:59 <weierophinney>	DASPRiD, Bittarman, kokx 
Oct 26 17:17:02 <weierophinney>	anybody home?
Oct 26 17:17:12 <weierophinney>	lubs, my inclination is as follows:
Oct 26 17:17:20 <EvanDotPro>	(CR team is fired)
Oct 26 17:17:23 <lubs>	*ping* ........ *no route to host*
Oct 26 17:17:29 <weierophinney>	* Rewrite/refactor of existing components, or new architecture: rfc
Oct 26 17:17:34 <weierophinney>	* New component: proposal
Oct 26 17:17:35 <hhatfield>	double their pay and see if that helps
Oct 26 17:17:46 <weierophinney>	hhatfield, 2 * 0 = 0
Oct 26 17:17:51 <ralphschindler>	+1 weierophinney
Oct 26 17:17:55 <hhatfield>	triple it then!
Oct 26 17:18:01 <intiilapa>	weierophinney: all IDLE since 30min or few hours
Oct 26 17:18:06 <lubs>	weierophinney: does that include existing Zend_Service* ?
Oct 26 17:18:08 <EvanDotPro>	+1 weierophinney
Oct 26 17:18:15 <robertbasic>	+1 weierophinney
Oct 26 17:18:18 <weierophinney>	lubs, that's a good question.
Oct 26 17:18:23 <intiilapa>	weierophinney: clean ZFPROP home page
Oct 26 17:18:40 <weierophinney>	I think with that stuff, it may be good enough to simply throw out on the ML and on the wiki, "Hey, I'm working on this" and do it in a branch of your own.
Oct 26 17:19:00 <weierophinney>	The bigger question right now is: what's going to happen with current proposals?
Oct 26 17:19:02 <robertbasic>	weierophinney: Service?
Oct 26 17:19:18 <weierophinney>	robertbasic, what's the question?
Oct 26 17:19:24 <lubs>	yeah - i was thinking that the Zend_Service components could be removed and distributed separately
Oct 26 17:19:27 <DASPRiD>	weierophinney, i'm here!
Oct 26 17:19:34 <DASPRiD>	(tho i'm always here)
Oct 26 17:19:38 <weierophinney>	DASPRiD, TOO LATE! YOU WERE AXED! (jk)
Oct 26 17:19:46 <lubs>	on current proposals; if they are not 2.x I think they should be removed :)
Oct 26 17:19:50 <robertbasic>	weierophinney: re: "Hey, I'm working on this" is that for the Service components?
Oct 26 17:20:02 <weierophinney>	robertbasic, yes, that's what I meant.
Oct 26 17:20:03 <DASPRiD>	weierophinney, :(
Oct 26 17:20:17 <weierophinney>	lubs, well, the question is if we can get the proposal authors to update them to ZF2
Oct 26 17:20:22 <robertbasic>	lubs: more like, ask the one who proposed if he's willing to update it to zf2, if not, then drop it
Oct 26 17:20:24 <intiilapa>	lubs: already say in RFC distribution
Oct 26 17:20:27 <DASPRiD>	moderator: current topic?
Oct 26 17:20:33 <lubs>	perfect
Oct 26 17:20:34 <lubs>	:)
Oct 26 17:20:35 <SpiffyJr>	RFC vs Proposal
Oct 26 17:20:52 <robertbasic>	DASPRiD: mod is weierophinney :)
Oct 26 17:20:59 <DASPRiD>	isn't a proposal an RFC (request for comments)?
Oct 26 17:21:00 <weierophinney>	DASPRiD, rfc vs proposal
Oct 26 17:21:02 <weierophinney>	read your backlog
Oct 26 17:21:22 <weierophinney>	robertbasic, exactly -- ask them to update if possible.
Oct 26 17:21:38 <lubs>	a proposal could likely become Proposal -> RFC -> x
Oct 26 17:21:49 <DASPRiD>	how far back that is? :x
Oct 26 17:21:56 <weierophinney>	DASPRiD, can you do me a favor: send an email to the cr-team to set up a meeting this week or early next AT THE LATEST so we can discuss timelines and processes?
Oct 26 17:21:57 <robertbasic>	weierophinney: or if not, maybe to hand over to someone else, who's willing to pick up finishing it
Oct 26 17:22:12 <WalterTamboer>	What is the whole idea behind the proposals anyway and does it actually work?
Oct 26 17:22:14 <weierophinney>	lots of backlash right now because folks don't know what the process is, or don't know why things are stalled.
Oct 26 17:22:18 <weierophinney>	robertbasic, yes.
Oct 26 17:22:23 <EvanDotPro>	DASPRiD: 7 minutes ago we started this topic
Oct 26 17:22:26 <intiilapa>	weierophinney: Must be clean before (all proposal of Paddy are promoted in core, etc)
Oct 26 17:22:43 <weierophinney>	WalterTamboer, the idea behind proposals is to make code better. With community review, you get new ideas and approaches, and ensure consistency with other components.
Oct 26 17:23:13 <DASPRiD>	weierophinney, sure
Oct 26 17:23:17 <lubs>	ok - seems like a good thing that we can move on from... action item: CR team discusses differences [if there is any] and brings it back with which way? :)
Oct 26 17:23:19 <weierophinney>	DASPRiD, thanks
Oct 26 17:23:20 <intiilapa>	archive proposal for ZF1 (= useless in ZF2 like application resource)
Oct 26 17:23:24 »»	denniswinter_ is now known as denniswinter
Oct 26 17:23:31 <weierophinney>	lubs, +1
Oct 26 17:23:32 <DASPRiD>	EvanDotPro, thanks, thats helpful :)
Oct 26 17:23:47 <DASPRiD>	about RBAC: it has no disallow/deny feature? that's somewhat sad
Oct 26 17:23:54 <WalterTamboer>	I pretty new to contributing to ZF and for me it feels like climbing a mountain since their is less to no feedback. Things move slowly so what would change when dropping the proposals and write RFC's? It looks like the same thing to me
Oct 26 17:24:19 <EvanDotPro>	DASPRiD: read Dolf's proposal for some info on that, we're on a new topic now though. ;)
Oct 26 17:24:19 <weierophinney>	DASPRiD, we've moved on from that topic.
Oct 26 17:24:21 <robertbasic>	as for the active proposals, once we get there, we'd need to promote them better, imho
Oct 26 17:24:40 <DASPRiD>	EvanDotPro, tho i can't find there where it says the difference between proposal and rfc
Oct 26 17:24:57 <weierophinney>	WalterTamboer, they _are_ different -- mainly because the RFCs generally are covering items with cross-cutting concerns or architectural concerns.
Oct 26 17:25:17 <weierophinney>	DASPRiD, proposal == new component, RFC == refactoring/rewriting or new architecture
Oct 26 17:25:20 <robertbasic>	DASPRiD: (07:17:30 PM)  * Rewrite/refactor of existing components, or new architecture: rfc
Oct 26 17:25:20 <robertbasic>	(07:17:35 PM) * New component: proposal
Oct 26 17:25:54 <weierophinney>	WalterTamboer, but we _need_ to get the proposal process working again. It's halted right now.
Oct 26 17:26:19 <DASPRiD>	robertbasic, weierophinney, i'm talking about the definition/contents, to me, RFC (request for comments) and proposal has so far be the same for me
Oct 26 17:26:36 <intiilapa>	everyone sleep or I have a bug? O_o
Oct 26 17:26:40 <weierophinney>	DASPRiD, they're similar, no doubt.
Oct 26 17:26:58 <weierophinney>	So, I'm going to sum up:
Oct 26 17:27:12 <weierophinney>	* We have a loose definition and differentiation between RFCs and proposals
Oct 26 17:27:45 <weierophinney>	* The CR-Team needs to meet and figure out how to unstall the process of proposals now that we know what's happening with the ZF 1.X and 2.X branches.
Oct 26 17:27:58 <weierophinney>	* DASPRiD will email the CR-Team to organize a meeting.
Oct 26 17:28:45 <weierophinney>	do we move on, or more discussion on the topic?
Oct 26 17:28:51 <robertbasic>	maybe find a new term for RFCs to avoid confusion? Something liek, brainstorming
Oct 26 17:28:56 <robertbasic>	(just an idea)
Oct 26 17:29:10 <SpiffyJr>	weierophinney: move on...
Oct 26 17:29:26 <robertbasic>	oh!
Oct 26 17:29:30 <robertbasic>	just 1 more thing
Oct 26 17:29:35 <weierophinney>	robertbasic, go for it
Oct 26 17:29:38 <hhatfield>	why would a pull request in github not be sufficient?
Oct 26 17:29:45 <robertbasic>	maybe make the cr teams work more visible?
Oct 26 17:29:50 <weierophinney>	robertbasic, btw, RFC is being used as the process largely mimics what PHP is doing now.
Oct 26 17:29:54 <weierophinney>	robertbasic, good point. :)
Oct 26 17:30:03 <weierophinney>	hhatfield, for what? new components?
Oct 26 17:30:12 <robertbasic>	say, a digest blog post + ML thread once in a while
Oct 26 17:30:16 <weierophinney>	because we should have many eyes looking at them.
Oct 26 17:30:18 <hhatfield>	weierophinney: yeah
Oct 26 17:30:20 <SpiffyJr>	roberbasic: +1
Oct 26 17:30:35 <intiilapa>	hhatfield: if you work 3 weeks on a new component, and we said no to your work. Are you happy?
Oct 26 17:30:39 <weierophinney>	robertbasic, I like that idea. We can likely make posting on the zf2 devblog possible for members.
Oct 26 17:30:54 <hhatfield>	pull requests don't have to be done at the completion of work
Oct 26 17:31:04 <hhatfield>	they can be done anytime during the process to elicit comments
Oct 26 17:31:05 <robertbasic>	cause honestly, I only ever saw the intro ML thread about the CR team, and nothing else :-/
Oct 26 17:31:21 <weierophinney>	hhatfield, basically, community helps review whether it's something we want to maintain long term, as well as helps identify architectural issues, consistency issues, etc. The proposal process is really, really good, when it's working.
Oct 26 17:31:37 <weierophinney>	robertbasic, agreed.
Oct 26 17:31:40 <weierophinney>	I'll note that.
Oct 26 17:31:56 <robertbasic>	so, no cookies for you DASPRiD! HAH!
Oct 26 17:32:08 <DASPRiD>	robertbasic, i dont care about cookies anymore, I got Bacon
Oct 26 17:32:10 <weierophinney>	Do we move on?
Oct 26 17:32:17 <robertbasic>	we can
Oct 26 17:32:18 »»	SpiffyJr nods
Oct 26 17:32:19 <weierophinney>	any more concerns?
Oct 26 17:32:31 <weierophinney>	kk, last topic: Modules Distribution / Installation RFC
Oct 26 17:32:41 <weierophinney>	EvanDotPro, YOUR TURN!
Oct 26 17:32:55 <EvanDotPro>	yay!
Oct 26 17:33:30 <EvanDotPro>	alright, so the questions are basically, how do we want to handle module distribution and installation as a community?
Oct 26 17:33:43 <DASPRiD>	weierophinney, mail sent
Oct 26 17:33:56 <SpiffyJr>	EvanDotPro: I think your current RFC (http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+Module+Installation+and+Distribution) sums it up nicely.
Oct 26 17:34:00 <weierophinney>	DASPRiD, thanks
Oct 26 17:34:04 <EvanDotPro>	and also is there anything large missing from the RFC i posted last week here: http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+Module+Installation+and+Distribution
Oct 26 17:34:47 <weierophinney>	EvanDotPro, one note: I think module removal also implies removing a module entry from the application config. Just deleting the module directory might lead to potential issues.
Oct 26 17:35:13 <EvanDotPro>	weierophinney: good point, i'll add that detail.
Oct 26 17:35:14 <SpiffyJr>	weierophinney: My mistake, I should have been more verbose on my comment.
Oct 26 17:35:32 <robertbasic>	weierophinney: EvanDotPro or just the tool writes out a message to remove the module by hand
Oct 26 17:35:41 <mattcockayne>	EvanDotPro: We may want to offer more detail on modules that can be considered for global use in a "tool" or as part of a project
Oct 26 17:35:59 <SpiffyJr>	matcockayne: What kind of detail?
Oct 26 17:36:07 <ralphschindler>	theres the problem of what happens to the files that are the "overrides" for a module too
Oct 26 17:36:13 <weierophinney>	EvanDotPro, another note: maybe discuss a little about channel naming? we don't want new channels being added with the same channel prefix
Oct 26 17:36:25 <mattcockayne>	SpiffyJr: mainly highlight that there may be two forms of module
Oct 26 17:36:38 <EvanDotPro>	weierophinney: very true.. that leads me to my next question:
Oct 26 17:36:45 <EvanDotPro>	What's Zend's stance on hosting a community pyrus repository for modules?
Oct 26 17:36:55 <EvanDotPro>	s/repository/channel
Oct 26 17:37:12 <ralphschindler>	i think we have a few details to work out first, but otherwise, i think its something we'd be capable of doing
Oct 26 17:37:28 <weierophinney>	EvanDotPro, what ralphschindler said.
Oct 26 17:37:31 <EvanDotPro>	(to clarify, we're just talking about a pyrus channel right now, not a site or anything)
Oct 26 17:37:47 <weierophinney>	Potentially something we can do in the devcloud, actually, which gives us better scaling as well.
Oct 26 17:37:54 <weierophinney>	since it's all static files
Oct 26 17:38:09 <ralphschindler>	EvanDotPro: correct (although, the channel infrastructure for something dynamic/non-static is more complex than just a static channel)
Oct 26 17:38:30 <EvanDotPro>	right, i would like us to have it be somewhat dynamic if possible.
Oct 26 17:38:35 <ralphschindler>	agreed
Oct 26 17:38:45 <dkarlovi>	are we on the modules thing?
Oct 26 17:38:46 <ralphschindler>	even if its a dynamic site that manages a static file channel
Oct 26 17:38:59 <EvanDotPro>	Node.js's NPM repository has been very successful with the ability to register and publish modules/packages right from the command line.
Oct 26 17:39:10 <ralphschindler>	same with the canonical rubygems.org
Oct 26 17:39:11 <weierophinney>	dkarlovi, yes
Oct 26 17:39:22 <EvanDotPro>	i think that might be a decent model to follow, and eliminates the burden of a UI as well.
Oct 26 17:39:39 <dkarlovi>	weierophinney: this is only about distribution, not the concepts?
Oct 26 17:40:40 <dkarlovi>	why not taking a look at RPM/DEB for packaging, yum/apt for distribution/installation?
Oct 26 17:40:45 <EvanDotPro>	dkarlovi: distribution / installation.. see the agenda here http://framework.zend.com/wiki/display/ZFDEV2/2011-10-26+Meeting+Agenda
Oct 26 17:40:57 <rizza>	dkarlovi: Using those directly?
Oct 26 17:41:00 <dkarlovi>	no
Oct 26 17:41:03 <ralphschindler>	dkarlovi: those have too much initial overhead in creating packages
Oct 26 17:41:15 <dkarlovi>	ralphschindler: not really
Oct 26 17:41:21 <weierophinney>	dkarlovi, because not everyone is on linux. We need something that's platform independent. PHP is.
Oct 26 17:41:30 <dkarlovi>	if you take a look at how Fedora packages PHP, it's all the same
Oct 26 17:41:47 <dkarlovi>	weierophinney: I'm not talking about USING them :)
Oct 26 17:41:48 <mattcockayne>	-1 for rpm/deb
Oct 26 17:41:50 <weierophinney>	dkarlovi, if somebody wants to take the ZF packages and distribute them in their distribution, that's fine.
Oct 26 17:41:56 <weierophinney>	:)
Oct 26 17:42:09 <dkarlovi>	I'm talking about taking a page from their book
Oct 26 17:42:10 <mattcockayne>	yes that was a minus
Oct 26 17:42:19 <SpiffyJr>	Can we not just use GitHub for distribution?
Oct 26 17:42:23 <dkarlovi>	the way it works
Oct 26 17:42:24 <DASPRiD>	-1 for rpm/deb, pyrus is more stuited for this
Oct 26 17:42:28 <SpiffyJr>	What benefit is a Pyrus channel?
Oct 26 17:42:30 <EvanDotPro>	dkarlovi: there's other logistic problems... yum/apt/rmp/deb were made for system package installation, so i'm pretty sure their packages define _where_ to install files to and such... ours needs to use relative paths.
Oct 26 17:42:32 <rizza>	dkarlovi: You're going to have to be more detailed about what you're saying.
Oct 26 17:42:51 <DASPRiD>	EvanDotPro, true
Oct 26 17:42:53 <dkarlovi>	rizza: OK, but I'm not much of an IRC guy :)
Oct 26 17:43:00 <dkarlovi>	it's kinda confusing :)
Oct 26 17:43:02 <rizza>	SpiffyJr: I'd prefer not. Can't expect everyone to be on GitHub. What about organizations that are private?
Oct 26 17:43:21 <SpiffyJr>	Why would a private organization distribute private modules?
Oct 26 17:43:25 <rizza>	Organizations not to be confused with GitHub organizations.
Oct 26 17:43:38 <EvanDotPro>	SpiffyJr: i think "git" should be one supported form of distribution by the cli tool (conditional on git being installed)
Oct 26 17:43:46 <ralphschindler>	btw- git repositories  can serve as channels
Oct 26 17:43:48 <dkarlovi>	anyway, what I meant is that the modules/packages should have a structure similar to that of RPM/DEB, but PHP specific, obviously
Oct 26 17:43:49 <intiilapa>	package = dependency / db migration / others problems
Oct 26 17:43:58 <rizza>	SpiffyJr: My company has it's own private repository for installing modules because clients buy different parts of our service.
Oct 26 17:44:11 <mattcockayne>	rizza: nothing stopping us offering by both pyrus and git
Oct 26 17:44:17 <weierophinney>	EvanDotPro, pyrus supports git at this point already
Oct 26 17:44:23 <EvanDotPro>	dkarlovi: take a look at pyrus packaging :)
Oct 26 17:44:30 <EvanDotPro>	weierophinney, ralphschindler: perfect.
Oct 26 17:44:32 <weierophinney>	ralphschindler, said it already though. I was simply not done skimming backlog. :)
Oct 26 17:44:42 <robertbasic>	just offer them .zip
Oct 26 17:44:50 <DASPRiD>	robertbasic, .rar :P
Oct 26 17:44:52 <rizza>	mattcockayne: I know,  but like Matthew says, Pyrus already supports git.
Oct 26 17:44:54 <ralphschindler>	+1 robertbasic - that works too
Oct 26 17:45:06 <nlundsten>	zip is allowed i think
Oct 26 17:45:17 <mattcockayne>	rizza: didnt know that... good to know
Oct 26 17:45:20 <dkarlovi>	EvanDotPro: seen that, yeah
Oct 26 17:45:22 <SpiffyJr>	Even better, if Pyrus supports Git.
Oct 26 17:45:35 <weierophinney>	nlundsten, pyrus builds phars, and then compiles those to tgz and zip. It can use a git repo and/or branch to create the packages, too.
Oct 26 17:45:37 <ralphschindler>	for the record: our current pyrus channel currently serves: phar, zip, tar, and tgz
Oct 26 17:45:59 <EvanDotPro>	weierophinney: a phar can also be a zip directly though... i'm assuming that's what nlundsten meant.
Oct 26 17:46:17 <robertbasic>	pyrus can do all that? guess that covers all/most of the bases
Oct 26 17:46:20 <ralphschindler>	our phars are not compressed
Oct 26 17:46:23 <weierophinney>	robertbasic, phar is amazing
Oct 26 17:46:35 <ralphschindler>	(b/c were not sure if the client has zip in the php runtime)
Oct 26 17:46:36 <nlundsten>	^^
Oct 26 17:46:40 <robertbasic>	weierophinney: never got around playing it with sadly
Oct 26 17:46:43 <EvanDotPro>	ralphschindler: good point
Oct 26 17:47:02 <ralphschindler>	but in 5.3, phar is always in the runtime afaik
Oct 26 17:47:12 <rizza>	Yes
Oct 26 17:47:19 <EvanDotPro>	i've outlined the different formats phar (and zf2 modules) support in the module documentation, btw.
Oct 26 17:48:01 <weierophinney>	EvanDotPro, overall, I think it's in the right direction.
Oct 26 17:48:03 <intiilapa>	EvanDotPro: and zpk? :p
Oct 26 17:48:15 <weierophinney>	intiilapa, don't get me started...
Oct 26 17:48:16 <EvanDotPro>	intiilapa: give up the zundle thing ;)
Oct 26 17:48:34 <weierophinney>	EvanDotPro, actually, intiilapa is referring to studio's deployment packaging system.
Oct 26 17:48:44 <weierophinney>	EvanDotPro, so, let me see if I understand:
Oct 26 17:48:49 <EvanDotPro>	great, so to recap: Zend is open to hosting a community module pyrus channel; with details to be fleshed out later.
Oct 26 17:49:00 <weierophinney>	* Your solution requires a working CLI tool
Oct 26 17:49:07 <weierophinney>	* Needs infrastructure (you noted this already)
Oct 26 17:49:11 <EvanDotPro>	weierophinney: ah didn't even know there was such a thing.
Oct 26 17:49:21 <EvanDotPro>	(studio deployment package _format_)
Oct 26 17:49:44 <weierophinney>	what timeline would you like?
Oct 26 17:49:48 <mattcockayne>	EvanDotPro: there is but i wouldnt recommend using for distributing modules
Oct 26 17:50:03 <dkarlovi>	can pyrus verify an installed package?
Oct 26 17:50:15 <intiilapa>	weierophinney: maybe wait after Tool/Console refactor?
Oct 26 17:50:18 <EvanDotPro>	mattcockayne: i'm not sure anyone would ;)
Oct 26 17:50:27 <EvanDotPro>	intiilapa: that's the current plan.
Oct 26 17:50:38 <EvanDotPro>	intiilapa: in fact, that's what started the refactor from mattcockayne's side.
Oct 26 17:50:57 <robertbasic>	as for the console stuff, mattcockayne and I need moar feedback/help :D
Oct 26 17:50:57 <weierophinney>	dkarlovi, yes, it has signed packaging capabilities
Oct 26 17:51:13 <robertbasic>	cause, on my side, work got really busy :(
Oct 26 17:51:17 <weierophinney>	so, EvanDotPro did you get the feedback you were looking for?
Oct 26 17:51:19 <mattcockayne>	yeah.. we have some ideas but could do with more to determine direction
Oct 26 17:52:04 <EvanDotPro>	weierophinney: for the core zf stuff, i think that's about it.
Oct 26 17:52:05 <dkarlovi>	weierophinney: for individual files? I need to see that! :)
Oct 26 17:52:14 <ralphschindler>	dkarlovi: for packages
Oct 26 17:52:28 <weierophinney>	dkarlovi, not for individual files, for packages
Oct 26 17:53:20 <weierophinney>	okay, so... anything else on the three topics we covered today?
Oct 26 17:53:29 <weierophinney>	We're approaching 18:00 UTC, so we should wrap up