[09:10:44 CDT(-0500)] <fairwinds> serac: heh
[09:11:51 CDT(-0500)] <fairwinds> serac, apetro: was thinking of using xStream to stick Ticket objects into couch as JSON. That should work well
[09:12:24 CDT(-0500)] <fairwinds> serac, apetro: this is my project for today
[09:12:28 CDT(-0500)] <serac> We've used xstream for similar stuff and it's worked well.
[09:12:41 CDT(-0500)] <fairwinds> k, cool
[09:12:52 CDT(-0500)] <serac> I've never used the JSON output, tho. We use XML.
[09:13:11 CDT(-0500)] <fairwinds> since in couchdb everything json, it is perfect fit
[09:13:45 CDT(-0500)] <serac> We should actually consider JSON for our use case – didn't know it supported that.
[09:13:50 CDT(-0500)] <serac> Nice mention 
[09:14:35 CDT(-0500)] <fairwinds> serac: heh, well I am looking to make everything work in JSON, since this is all I want to work with generally
[09:15:40 CDT(-0500)] <fairwinds> serac: I didn't know xstream did this until this morning either
[09:16:11 CDT(-0500)] <fairwinds> serac: here is the gist of it http://xstream.codehaus.org/json-tutorial.html
[09:16:24 CDT(-0500)] <fairwinds> serac: pretty easy
[09:16:49 CDT(-0500)] <serac> Yup. The interesting part for us is that we've run into space issues serializing data into XML and stuffing it into Oracle BLOBs.
[09:16:56 CDT(-0500)] <serac> JSON should compact the data nicely.
[09:17:15 CDT(-0500)] <fairwinds> yeah, XML is bulk for sure
[09:17:40 CDT(-0500)] <serac> It's nice for configuration and Web services, sux for just about every other use case I've seen.
[09:18:09 CDT(-0500)] <serac> Verbosity in the context of configuration is actually helpful IMO.
[09:18:19 CDT(-0500)] <serac> So there it's a benefit; elsewhere not so much.
[09:19:11 CDT(-0500)] <apetro> I think the XML CAS2 ticket validation responses are inspired
[09:19:39 CDT(-0500)] <apetro> sounds like a good project for the day.
[09:19:44 CDT(-0500)] <serac> yup
[09:20:57 CDT(-0500)] <fairwinds> apetro: gmorning
[09:34:41 CDT(-0500)] <apetro> morning.
[11:18:02 CDT(-0500)] <fairwinds> serac, apetro: a json Ticket https://gist.github.com/d00b403ffa522cd92aa5
[11:19:08 CDT(-0500)] <serac> That looks dramatically more succinct than XStream XML. Nice.
[11:22:12 CDT(-0500)] <fairwinds> serac: its cool. I will be using the TicketId as key in couch since they are unique, no point in generating a uuid as key
[11:22:41 CDT(-0500)] <serac> agreed
[11:24:36 CDT(-0500)] <fairwinds> serac: also there is an option with the json to remove the json root ie. the "org.jasig.cas.ticket.TicketGrantingTicketImpl". I think I will use this option as it doesn't affect the reconstitution of the object
[11:25:15 CDT(-0500)] <fairwinds> serac: leaves the json a bit cleaner this way
[11:26:47 CDT(-0500)] <serac> I could see it either way. If everything in that store is of the same type, then you could infer from context.
[11:27:10 CDT(-0500)] <serac> But here you're storing both TGTs and STs, so that context might be helpful. (But not necessary as you noted.)
[11:27:32 CDT(-0500)] <fairwinds> serac: right, its all going into a cas_tickets db
[11:28:09 CDT(-0500)] <fairwinds> serac: what would you rather see?
[11:28:36 CDT(-0500)] <serac> I'm leaning toward keeping the class name for context. No big deal either way, just tend that way.
[11:31:06 CDT(-0500)] <fairwinds> serac: k, when you take the root element out it exposes the object nicely like using in a dashboard ui.
[11:32:38 CDT(-0500)] <fairwinds> serac: my goal is to get this into a ui as well
[11:34:02 CDT(-0500)] <serac> Couldn't you easily strip the root element with JSON in hand for UI use case?
[11:36:05 CDT(-0500)] <fairwinds> serac: I could yes, but I am also thinking about performing map reduce on the data. A more open structure is better for that
[11:36:43 CDT(-0500)] <serac> What's the purpose of map-reduce here?
[11:38:10 CDT(-0500)] <fairwinds> serac: In couch map reduce is used for virtually all forms of lookups
[11:38:22 CDT(-0500)] <serac> I see.
[11:38:32 CDT(-0500)] <serac> Go with whatever meets all the use cases you know about, then.
[11:38:40 CDT(-0500)] <serac> Those trump the need for context I mentioned.
[11:38:47 CDT(-0500)] <fairwinds> so it is just the common way of being able to look at your date in different ways
[11:38:54 CDT(-0500)] <fairwinds> s/ data even
[11:39:00 CDT(-0500)] <serac> understood
[11:39:24 CDT(-0500)] <fairwinds> serac: and its blood fast with large sets also
[11:39:34 CDT(-0500)] <fairwinds> s/ bloody
[11:40:24 CDT(-0500)] <fairwinds> serac: once you create the views of the data you want, everything in ms just like an index
[11:41:35 CDT(-0500)] <fairwinds> serac: is there anything in CAS at the moment that lets you visualize your data. just curious. Maybe this will be first?
[11:41:45 CDT(-0500)] <serac> The scale of most ticket registries I've seen is 10^4-10^5. All the registry impls work well at that scale.
[11:42:03 CDT(-0500)] <serac> There's really no use case for detailed data visualization.
[11:42:13 CDT(-0500)] <serac> There is a use case for dashboard with high-level stats.
[11:42:22 CDT(-0500)] <serac> If you're thinking about building that, build on top of JMX.
[11:42:41 CDT(-0500)] <serac> That supports interrogation via tool chains as well as user interfaces.
[11:42:44 CDT(-0500)] <serac> Which is what you want.
[11:43:06 CDT(-0500)] <fairwinds> serac: the dashboard approach what I am looking to do
[11:43:12 CDT(-0500)] <serac> I honestly don't care how many tickets I have.
[11:43:20 CDT(-0500)] <fairwinds> heh
[11:43:21 CDT(-0500)] <serac> What I do care about is how many users are authenticated and to what services.
[11:43:26 CDT(-0500)] <fairwinds> right
[11:43:40 CDT(-0500)] <serac> I believe there's general interest in dashboard with that data.
[11:43:53 CDT(-0500)] <fairwinds> k
[11:44:07 CDT(-0500)] <serac> There is a dashboard in CAS right now, though.
[11:44:19 CDT(-0500)] <serac> It shows some high-level JVM and app stats, but not the detail I mentioned.
[11:44:26 CDT(-0500)] <serac> And it's not built on JMX.
[11:44:32 CDT(-0500)] <serac> Those are the growth plans I mentioned tho.
[11:45:09 CDT(-0500)] <fairwinds> serac: k, I don't know anything about JMX 
[11:45:27 CDT(-0500)] <serac> It's just the de-facto management API in java.
[11:46:11 CDT(-0500)] <serac> The existing dashboard page is at /services/, so you can check it out.
[11:46:22 CDT(-0500)] <serac> Maybe just build on that for your use case.
[11:46:32 CDT(-0500)] <serac> I should say it's under /services/
[11:47:00 CDT(-0500)] <fairwinds> serac: k, will look
[11:50:25 CDT(-0500)] <fairwinds> serac: I will read about JMX nonetheless
[11:51:12 CDT(-0500)] <fairwinds> serac: I don't really know much of Java but its going ok at least, I don't feel that blind
[11:51:14 CDT(-0500)] <serac> It's very unsexy technology.
[11:51:28 CDT(-0500)] <fairwinds> serac: oh no
[11:51:36 CDT(-0500)] <serac> The fact that good resources for it probably speaks to that point.
[11:51:46 CDT(-0500)] <serac> fact there are few/no good resources, that is
[11:51:55 CDT(-0500)] <fairwinds> heh
[11:52:35 CDT(-0500)] <fairwinds> serac: that initilizing bean worked great yesterday btw.
[11:52:41 CDT(-0500)] <serac> sweet
[11:53:00 CDT(-0500)] <fairwinds> initializing even
[11:53:09 CDT(-0500)] <apetro> I find JMX sexy.
[11:53:22 CDT(-0500)] <serac> I see this going downhill quick 
[11:53:40 CDT(-0500)] * fairwinds thinks apetro needs a girl friend
[11:53:47 CDT(-0500)] <serac> Today's wisdom: keep sex out of discussion of code.
[11:53:52 CDT(-0500)] <fairwinds> hehe
[11:53:57 CDT(-0500)] <apetro> heh. I'll go ahead and not touch that.
[11:54:07 CDT(-0500)] <serac> You are wise, indeed.
[11:54:25 CDT(-0500)] <apetro> Might be an interesting cas-dev talk to chat a bit about the vision for that monitoring / management console tho
[11:54:38 CDT(-0500)] <apetro> if we run out of discussions of source control migrations today.
[11:54:38 CDT(-0500)] <serac> Yeah, it is. We should flesh that out some more.
[11:54:51 CDT(-0500)] <serac> I have this vision in my head that I'm sure has never made it to light.
[11:55:03 CDT(-0500)] <fairwinds>
[11:55:06 CDT(-0500)] <serac> And yes, I expect repo migration to take up most if not all of our time.
[11:55:40 CDT(-0500)] <fairwinds> serac, apetro: right, you guys are talking every friday
[11:55:44 CDT(-0500)] <apetro> that's fine. Looking for that 3.5 dev branch to be unblocked for better pointing UX devs at improving that management console
[11:56:01 CDT(-0500)] <serac> Yup, today @2.
[11:56:15 CDT(-0500)] <serac> apetro: I think it's top of the list for post 3.4.9 release tasks.
[11:56:29 CDT(-0500)] <serac> I may even change priority to Critical.
[11:56:44 CDT(-0500)] <fairwinds> serac: k, I better stop chatting soon, only 4 minutes left till 2PM
[11:56:48 CDT(-0500)] <apetro> it == unblock or it == management console
[11:57:06 CDT(-0500)] <apetro> fairwinds, 2pm Eastern. You still have another hour.
[11:57:16 CDT(-0500)] <fairwinds> heh
[11:57:23 CDT(-0500)] <serac> Where in the world are you, fairwinds?
[11:57:27 CDT(-0500)] <serac> Central time?
[11:57:42 CDT(-0500)] <apetro> and as long as we're just chatting, had anyone else lost track of fact that Kuali Rice is shipping a Kuali IdM integrated CAS server?
[11:57:52 CDT(-0500)] <serac> I don't think I ever knew it.
[11:58:03 CDT(-0500)] <fairwinds> just outside of Halifax, Nova Scotia (Atlantic time)
[11:58:03 CDT(-0500)] <apetro> stumbled across that again today, CAS project should, like, get some buzz out of that.
[11:58:27 CDT(-0500)] <serac> fairwinds: Ah, wrong direction I see.
[11:58:35 CDT(-0500)] <serac> apetro: +1
[11:58:38 CDT(-0500)] <apetro> cranking out "quick" emphatically boring workflow apps using Rice, KEW, and its preferred CAS server backed by Kuali IdM looks pretty darn compelling.
[11:58:42 CDT(-0500)] <serac> I said as much in cas-steering thread.
[11:58:58 CDT(-0500)] <serac> "emphatically boring" – awesome
[11:59:12 CDT(-0500)] <fairwinds> Kauli Rice?
[11:59:15 CDT(-0500)] <apetro> hey, this stuff isn't nearly as sexy as JMX
[11:59:24 CDT(-0500)] <serac> There he goes again
[11:59:30 CDT(-0500)] <fairwinds> hehe
[11:59:39 CDT(-0500)] <apetro> Kuali Rice. open source development framework for building boring, useful, enterprise process applications.
[11:59:41 CDT(-0500)] <serac> fairwinds: You're right to question the name. Open source could do better with names.
[12:00:16 CDT(-0500)] <apetro> I wouldn't say it's higher-ed specific as such, but I would say it's better designed to cope with higher ed use cases which tend to be... complicated in special ways.
[12:00:29 CDT(-0500)] <fairwinds> serac: At one time, I saw a supermarket chain was using CAS
[12:00:30 CDT(-0500)] <serac> http://users.skynet.be/fa258499/mozproductname.html
[12:00:33 CDT(-0500)] <serac> Sounds like it fell out of there.
[12:00:53 CDT(-0500)] <apetro> (lunch, back certainly in time for cas-dev chat)
[12:00:56 CDT(-0500)] <serac> What supermarket? We'll go bug them to be added to our deployers page
[12:02:23 CDT(-0500)] <fairwinds> serac: I thought they were there a couple of years ago. Can't remember their name now
[12:02:30 CDT(-0500)] <fairwinds> it was American
[12:03:18 CDT(-0500)] <fairwinds> serac: Hmm. Sunpenguin, that's a good name
[12:03:26 CDT(-0500)] <fairwinds>
[12:03:51 CDT(-0500)] <serac> Kuali in my mind is a one-off of Koala, so guess that's what sent me to that name generator.
[12:03:58 CDT(-0500)] <serac> Maybe it's just me.
[12:04:48 CDT(-0500)] <fairwinds> serac: where are you btw, in the US?
[12:07:49 CDT(-0500)] <serac> http://maps.google.com/maps?client=ubuntu&channel=fs&q=blacksburg,+va&oe=utf-8&um=1&ie=UTF-8&hq=&hnear=0x884d950adc06dcc3:0x86ceb8ea4842da2d,Blacksburg,+VA&gl=us&ei=2OgyTovaLsnn0QHSzYGVDA&sa=X&oi=geocode_result&ct=image&resnum=2&ved=0CC4Q8gEwAQ
[12:14:08 CDT(-0500)] <fairwinds> serac: ah, k. I have been to DC a couple of times and Baltimore. I think only time I was in Virginia was to see George Washington's Plantation
[12:15:30 CDT(-0500)] <serac> I'm in the southwest part of the state, which is vastly different from the DC area.
[12:15:55 CDT(-0500)] <serac> Here it's cool, quiet, and beautiful.
[12:15:59 CDT(-0500)] <serac> DC none of those.
[13:00:24 CDT(-0500)] <apetro> checking in
[13:00:50 CDT(-0500)] <wgthom> hi andrew
[13:00:57 CDT(-0500)] <serac> I'm here
[13:01:11 CDT(-0500)] <serac> Let's wait a couple for battags.
[13:06:19 CDT(-0500)] <apetro> Safeway appears to be using OpenSSO https://auth.safeway.com/opensso/UI/Login?goto=http%3A%2F%2Fwww.safeway.com%2FIFL%2FGrocery%2FOffers-Landing-IMG
[13:08:07 CDT(-0500)] <wgthom> interesting
[13:10:59 CDT(-0500)] <serac> It's 10 after, let's get to it.
[13:11:09 CDT(-0500)] <serac> Anyone have anything to say about GitHub transition?
[13:12:07 CDT(-0500)] <wgthom> hooray!
[13:12:20 CDT(-0500)] <serac> I'm getting more excited the more I think about it.
[13:12:21 CDT(-0500)] <apetro> agreed. I'm in favor of it.
[13:14:00 CDT(-0500)] <apetro> not sure what more there is to say useful about it
[13:14:40 CDT(-0500)] <serac> Anyone have resources to cite for howtos, best practices, lessons learned? There's a couple such resources on https://issues.jasig.org/browse/CAS-997 presently, but you can't know too much going in.
[13:15:07 CDT(-0500)] <serac> Jen Bourey mentioned the Fluid project's transition.
[13:15:11 CDT(-0500)] <serac> Anyone have a reference for that?
[13:15:14 CDT(-0500)] <wgthom> I found this to be good background: http://eagain.net/articles/git-for-computer-scientists/
[13:15:43 CDT(-0500)] <serac> Looks like a fresh take on it.
[13:15:44 CDT(-0500)] <serac> Nice.
[13:17:02 CDT(-0500)] <wgthom> love that git has real tags and branches
[13:17:19 CDT(-0500)] <wgthom> that always bothered me with svn...coming from a mostly cvs background
[13:17:59 CDT(-0500)] <serac> There's both beauty and frustration in the "everything is a path" model of svn.
[13:18:16 CDT(-0500)] <wgthom> lol.. mostly frustration!
[13:19:00 CDT(-0500)] <serac> I'm pretty sure everyone falls somewhere different along that broad spectrum. I'm mostly in the middle.
[13:19:25 CDT(-0500)] <serac> But between the new workflows we'll be able to do with git and services of GitHub, I'm a fan.
[13:19:33 CDT(-0500)] <wgthom> indeed!
[13:19:47 CDT(-0500)] <apetro> I love SVN. Git is the right next step forward for CAS. It scratches itches we actually have involving being more effective and organic at encouraging contribution of and maintenance of mods.
[13:20:01 CDT(-0500)] <serac> Indeed.
[13:20:19 CDT(-0500)] <serac> We can support much more than simply accepting patches on Jira issues.
[13:20:23 CDT(-0500)] <serac> That will be huge.
[13:20:24 CDT(-0500)] <wgthom> anything else to discuss, besides rehashing the git decissinon
[13:20:34 CDT(-0500)] <apetro> tactically
[13:20:53 CDT(-0500)] <apetro> I believe serac continues to own the concretely how do we migrate from existing svn to git on github task?
[13:21:09 CDT(-0500)] <apetro> you seem to be doing a fine job gathering input, options, and actually testing it out.
[13:21:11 CDT(-0500)] <serac> I'm certainly doing investigation, but Scott owns it.
[13:21:15 CDT(-0500)] <apetro> k
[13:21:22 CDT(-0500)] <serac> I have a feeling he'll delegate at least some of the work to me.
[13:22:00 CDT(-0500)] <apetro> and scm migration is blocke by waiting for 3.4.9 to be released, which is blocked by waiting for 3.4.9 to be releaseable?
[13:22:14 CDT(-0500)] <serac> That's right.
[13:23:14 CDT(-0500)] <apetro> k
[13:23:29 CDT(-0500)] <wgthom> does it make any sense to out my mirroring svn into git...?
[13:23:33 CDT(-0500)] <wgthom> to start out...
[13:23:51 CDT(-0500)] <wgthom> so as not to be totally blocked by 3.4.9
[13:23:58 CDT(-0500)] <serac> No further details on the release blocker, so Scott may release this weekend without a fix.
[13:24:05 CDT(-0500)] <wgthom> ah
[13:24:07 CDT(-0500)] <serac> I think the stated plan is fine.
[13:24:09 CDT(-0500)] <wgthom> k
[13:24:17 CDT(-0500)] <serac> Still lots of research we can do in the interim.
[13:24:32 CDT(-0500)] <serac> It's absolutely imperative we get the history preserved right.
[13:24:54 CDT(-0500)] <serac> I'm mostly confident we can do that np, but still it's wise to do as much planning as possible before execution.
[13:24:59 CDT(-0500)] <wgthom> i'm actually not that bothered by history, as long as the svn repo can be archived.
[13:25:14 CDT(-0500)] <serac> Module maintainers will care.
[13:25:17 CDT(-0500)] <wgthom> history is preserved.
[13:25:38 CDT(-0500)] <apetro> let's just stipulate that we rehash that whole conversation where I value history a lot less than you seem to, serac, and I'll certainly agree that I'm supportive of your and battags executing the migration as you see best can be executed.
[13:25:51 CDT(-0500)] <serac> I need my scm tools to allow me to look back in time on my working copy. Anything less is unacceptable.
[13:26:36 CDT(-0500)] <apetro> I don't agree, but I certainly don't want to stop you from seeking excellence rather than good enough so long as the excellence does not protract the timeline and increase the complexity to the point of inaction.
[13:26:45 CDT(-0500)] <serac> You guys are nuts.
[13:26:49 CDT(-0500)] <serac>
[13:26:57 CDT(-0500)] <apetro> but pleasantly, accomodatingly so
[13:27:10 CDT(-0500)] <serac> indeed
[13:27:18 CDT(-0500)] <apetro> would that certain other institutions could compromise as effectively.
[13:27:49 CDT(-0500)] <serac> No doubt.
[13:27:56 CDT(-0500)] <apetro> ok
[13:28:13 CDT(-0500)] <apetro> so, the interesting part of that, is that this desire for history preservation is actionable inasmuch as research and testing?
[13:28:44 CDT(-0500)] <serac> I did the conversion yesterday and it looked good in all ways I could tell. So very actionable.
[13:28:52 CDT(-0500)] <wgthom> nice
[13:29:10 CDT(-0500)] <serac> I plan to dig a little deeper in next few days.
[13:29:18 CDT(-0500)] <serac> But surface scans looked solid.
[13:31:01 CDT(-0500)] <serac> On a related topic...
[13:31:13 CDT(-0500)] <serac> Could we implement the "Dictator and Lieutenants Workflow"?
[13:31:19 CDT(-0500)] <serac> cf http://whygitisbetterthanx.com/
[13:31:32 CDT(-0500)] <serac> Where each lieutenant is a module maintainer?
[13:31:58 CDT(-0500)] <serac> And we have 2 "dictators" – a primary release manager and backup, both of whom have access to push to the GitHub repo?
[13:32:25 CDT(-0500)] <serac> Technically we can do it of course.
[13:32:49 CDT(-0500)] <serac> But is it practical? Do we have enough active maintainers to make it work?
[13:33:44 CDT(-0500)] <serac> I like it because it makes module maintainers authorities for their domains of expertise and spreads the work out a bit. The release managers just blindly trust them for pull merges.
[13:34:23 CDT(-0500)] <wgthom> i lean towards this model.
[13:35:06 CDT(-0500)] <wgthom> like the lieutenants to module binding
[13:35:39 CDT(-0500)] <serac> They use the word "subsystem" in the explanation I cited, but module maps nicely to CAS.
[13:36:23 CDT(-0500)] <serac> Problem is that I really don't know whether we have enough active devs maintaining modules to make it any different than the "Integration Manager Workflow." But maybe that's a benefit.
[13:36:35 CDT(-0500)] <serac> It scales up and down well.
[13:36:53 CDT(-0500)] <wgthom> yeah, was just thinking that it probably is more realistic to start with IMW
[13:37:22 CDT(-0500)] <apetro> I don't feel qualified to have an opinion about this, but it intuitively sounds good.
[13:37:28 CDT(-0500)] <serac> I guess the only practical difference is the amount of review the release manager/dictator gives during pull merges.
[13:37:33 CDT(-0500)] <wgthom> especially since it maps to github flow and current cas practices
[13:37:57 CDT(-0500)] <serac> I would argue that for CAS we need primary/backup release managers/dictators.
[13:38:07 CDT(-0500)] <serac> Which in practice means two folks that can push to GitHub.
[13:38:16 CDT(-0500)] <wgthom> well, it all boils down to who has "committer" access on the blessed. and communication.
[13:38:23 CDT(-0500)] <serac> Exactly.
[13:38:35 CDT(-0500)] <serac> I'm suggesting limiting access.
[13:38:47 CDT(-0500)] <serac> Which is different than current Jasig svn model.
[13:38:51 CDT(-0500)] <wgthom> should all cas commiters should ahve acess to the primary github repo?
[13:39:19 CDT(-0500)] <serac> I'd like to stick with a flow there, and the only one where that's the case is the "Subversion Workflow."
[13:39:40 CDT(-0500)] <serac> What I like about small number of access to master is that we can totally avoid votes on comitter access.
[13:40:09 CDT(-0500)] <serac> We can keep the "commiter" notion but avoid the "create a svn username on source.jasig.org" etc.
[13:40:28 CDT(-0500)] <serac> We just organically start trusting you and pulling from you when you request it.
[13:40:45 CDT(-0500)] <wgthom> right, i get that. and agree with the model.
[13:40:48 CDT(-0500)] <serac> It's very organic and consistent with lowering the bar to participation.
[13:40:58 CDT(-0500)] <wgthom> yep
[13:41:26 CDT(-0500)] <serac> And this way it keeps the release maintainer actively involved in all changes to the repo, instead of lazily through post-commit notifications.
[13:41:45 CDT(-0500)] <serac> In practice Scott is very on top of them, so no much gain in practice there.
[13:41:54 CDT(-0500)] <serac> But in principle it's nice.
[13:42:14 CDT(-0500)] <serac> It could be a bottle neck, though, but I'd recommend try and see.
[13:42:26 CDT(-0500)] <wgthom> yes, worried a bit about the bottle neck but
[13:43:13 CDT(-0500)] <wgthom> I think we can work through it in any case
[13:43:28 CDT(-0500)] <apetro> alright
[13:43:37 CDT(-0500)] <serac> Ok, good. Just wanted to brainstorm a little.
[13:43:45 CDT(-0500)] <apetro> so, putatively, I might be the "lieutenant" on ClearPass
[13:43:52 CDT(-0500)] <serac> Correct.
[13:43:56 CDT(-0500)] <apetro> does this mean I should go ahead and figure out what it means to pull that into GitHub and actually do it?
[13:44:05 CDT(-0500)] <apetro> that seems entirely unblocked by the whole 3.4.9 thing
[13:44:14 CDT(-0500)] <serac> Yes, entirely.
[13:44:22 CDT(-0500)] <serac> You should read up and get ready, but no rush.
[13:44:47 CDT(-0500)] <serac> Unless you want to cut a CP release immediately following 3.4.9.
[13:45:00 CDT(-0500)] <serac> In that case get hopping.
[13:45:01 CDT(-0500)] <serac>
[13:45:05 CDT(-0500)] <apetro> well, in concept I do
[13:45:22 CDT(-0500)] <apetro> but in practice it's already a problem that ClearPass is a few patch releases behind
[13:45:26 CDT(-0500)] <wgthom> would CPass have to part for the CAS repo for apetro to be a "lieutentant"
[13:45:27 CDT(-0500)] <serac> Yeah, was thinking that wasn't too far fetched.
[13:45:50 CDT(-0500)] <serac> wgthom: good point
[13:45:52 CDT(-0500)] <serac> You're right.
[13:46:09 CDT(-0500)] <wgthom> a get lucky sometimes
[13:46:59 CDT(-0500)] <serac> But that workflow could come at some point – I fully expect to move forward with making CP a proper server module.
[13:47:07 CDT(-0500)] <serac> What's status of that, btw?
[13:47:29 CDT(-0500)] <wgthom> thinking more about IMW...
[13:47:52 CDT(-0500)] <wgthom> as a good model to go too...
[13:47:54 CDT(-0500)] <wgthom> to
[13:48:25 CDT(-0500)] <wgthom> and transitioning current cas committers to have IM rights
[13:48:35 CDT(-0500)] <apetro> I see making ClearPass a proper CAS module as blocked by opening CAS 3.5 path
[13:48:44 CDT(-0500)] <wgthom> so as to reduce botteneck.
[13:49:06 CDT(-0500)] <apetro> as in, that's an example of a change to work out in the towards-3.5-trunk
[13:49:23 CDT(-0500)] <serac> apetro: makes sense
[13:50:03 CDT(-0500)] <serac> wgthom: Let's just try it as stated and tweak if needed.
[13:50:17 CDT(-0500)] <serac> Should be easy to grant others write privs on the GitHub repo if needed.
[13:50:39 CDT(-0500)] <wgthom> how was it stated? I though we were brainstorming...
[13:50:50 CDT(-0500)] <serac> As stated on the page I cited.
[13:50:56 CDT(-0500)] <serac> We are.
[13:51:18 CDT(-0500)] <wgthom> yes....I was referencing the IMW workflow on that page
[13:51:46 CDT(-0500)] <serac> There's only one release manager in that model. You're thinking of it as a collective position?
[13:52:07 CDT(-0500)] <serac> I personally think having a backup is wise in case Scott is hit by a bus or is on vacation or whatever.
[13:52:34 CDT(-0500)] <serac> But there's no value in more than 2 if indeed there is no bottleneck.
[13:52:45 CDT(-0500)] <serac> So I'm proposing try and see.
[13:52:51 CDT(-0500)] <serac> We can always open up more if needed.
[13:52:57 CDT(-0500)] <serac> Scaling back is always harder.
[13:54:03 CDT(-0500)] <wgthom> yes, I was suggesting IMW maps well, and that current committers take on the role of Intergration Mangers when appropriate.
[13:54:17 CDT(-0500)] <wgthom> for instance apetro could merge in ClearPass updates
[13:54:31 CDT(-0500)] <wgthom> rather than wait for someone else to do it
[13:55:55 CDT(-0500)] <serac> For me this discussion reflects something about the CAS development model.
[13:56:15 CDT(-0500)] <serac> We have a position called "Lead Developer" who is really an architect+release manager in practice.
[13:56:43 CDT(-0500)] <serac> Then we have a collection of everyone else who maintains modules, does small fixes, etc.
[13:58:48 CDT(-0500)] <serac> The only reason everyone can commit to the master repository is because there is only one.
[13:59:12 CDT(-0500)] <apetro> hmm.
[13:59:17 CDT(-0500)] <serac> I can imagine that if we'd been on git from day one there would be a single (or at most 2 - primary+backup) person with access to the master.
[13:59:35 CDT(-0500)] <serac> I sincerely really value the release manager role.
[13:59:53 CDT(-0500)] <wgthom> we could have easily adopted the same workflow with svn.
[13:59:59 CDT(-0500)] <apetro> Not sure I agree with that. The only reason that I can commit to the CAS repository, the whole repository, is that I'm trusted to exercise those powers responsibly.
[14:00:03 CDT(-0500)] <serac> easily?
[14:00:08 CDT(-0500)] <wgthom> right
[14:00:19 CDT(-0500)] <serac> I believe the burden's on you to illustrate how.
[14:00:28 CDT(-0500)] <wgthom> apetro: right...
[14:00:43 CDT(-0500)] <wgthom> serac: patches
[14:00:49 CDT(-0500)] <wgthom> instead of cvs commits
[14:00:55 CDT(-0500)] <wgthom> lead dev has to merge and commit
[14:01:04 CDT(-0500)] <apetro> I thoroughly value the release manager role. I don't believe that preventing other trusted committers from touching the code is requisite to allow the release manager to fulfill that role.
[14:01:12 CDT(-0500)] <wgthom> agreed.
[14:01:18 CDT(-0500)] <wgthom> need a release manager...
[14:01:28 CDT(-0500)] <wgthom> to shepherd the release
[14:01:34 CDT(-0500)] <wgthom> not act as a gate keeper
[14:02:00 CDT(-0500)] <serac> A good release manager, like a good shepherd, is both a keeper of sheep and gatekeeper.
[14:02:17 CDT(-0500)] <serac> I don't think we have any wolves here.
[14:02:54 CDT(-0500)] <serac> But most release managers have some (security) policy to back up their role.
[14:03:52 CDT(-0500)] <serac> That said, I can live with trusting all current committers to have access and having verbal/written/project policy dictate the responsibilities of the release manager.
[14:04:34 CDT(-0500)] <serac> We should draw a picture to indicate how this works so we can cite it primiently.
[14:04:39 CDT(-0500)] <serac> prominently
[14:04:41 CDT(-0500)] <wgthom> yes..."gatekeeper" is a role shared by the committers...and is done better since there are more folks involved.
[14:05:18 CDT(-0500)] <wgthom> and yes...communication on the dev list is the key... intent, action, etc.
[14:05:28 CDT(-0500)] <apetro> communication is key.
[14:05:34 CDT(-0500)] <serac> I honestly think there's some benefit in moving to review-then-commit from where we are now, commit then review.
[14:05:44 CDT(-0500)] <serac> But not enough to fight about it.
[14:05:53 CDT(-0500)] <apetro> eh
[14:06:14 CDT(-0500)] <apetro> I look forward to effective adoption of git making these issues less important.
[14:06:29 CDT(-0500)] <serac> One can hope.
[14:06:30 CDT(-0500)] <apetro> My git book arrives tomorrow, soon after which I hope to be more intelligent about this.
[14:07:14 CDT(-0500)] <wgthom> why wait? http://progit.org/book/
[14:07:16 CDT(-0500)] <apetro> I think development branches should become more conservative the closer they get to production release.
[14:07:54 CDT(-0500)] <apetro> and I look forward to development towards 3.5 being more viable and welcoming of all kinds of interesting, collaborative mistakes that we can learn from in coalescing towards a solid 3.5 release.
[14:07:57 CDT(-0500)] <serac> How are we violating that at present?
[14:08:01 CDT(-0500)] <wgthom> whoops...my time is up. I thank you for yours.
[14:08:08 CDT(-0500)] <serac> wgthom: later
Page Comparison
General
Content
Integrations