Timestamps are in GMT/BST.
[0:41] * awoods (~awoods@pool-72-66-80-117.washdc.fios.verizon.net) Quit (Ping timeout: 245 seconds)
[2:11] * Tonny_DK (~thl@130.226.36.117) has joined #duraspace
[3:02] * grahamtriggs (~grahamtri@cpc1-stev6-2-0-cust340.9-2.cable.virginmedia.com) Quit (Quit: grahamtriggs)
[4:06] -hubbard.freenode.net- *** Looking up your hostname...
[4:06] -hubbard.freenode.net- *** Checking Ident
[4:06] -hubbard.freenode.net- *** No Ident response
[4:06] -hubbard.freenode.net- *** Found your hostname
[4:06] [frigg VERSION]
[4:06] * DuraLogBot (~PircBot@fedcommsrv1.nsdlib.org) has joined #duraspace
[4:06] * Topic is 'Welcome to DuraSpace - This channel is logged - http://duraspace.org/irclogs/'
[4:06] * Set by cwilper on Tue Jun 30 16:32:05 EDT 2009
[7:02] * grahamtriggs (~trig01@80.169.130.178) has joined #duraspace
[8:05] * awoods (~awoods@pool-173-79-154-160.washdc.fios.verizon.net) has joined #duraspace
[9:30] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has joined #duraspace
[9:51] * Tonny_DK (~thl@130.226.36.117) Quit (Quit: Leaving.)
[12:04] * grahamtriggs (~trig01@80.169.130.178) has left #duraspace
[12:55] * barmintor (barmintor@specdl11.cul.columbia.edu) has left #duraspace
[14:32] * grahamtriggs (~grahamtri@cpc1-stev6-2-0-cust340.9-2.cable.virginmedia.com) has joined #duraspace
[14:34] * StuartLewis_ (~StuartLew@121.98.157.79) has joined #duraspace
[14:49] * cccharles (~cccharles@131.104.62.47) has joined #duraspace
[14:52] * jatrimble (~jtrimble@maag127.maag.ysu.edu) has joined #duraspace
[14:55] * caryn (~80c8e115@gateway/web/freenode/x-esttweiaczqkpidr) has joined #duraspace
[14:57] * mdiggory (~mdiggory@ip-66-181-1-6.cust.i2bnetworks.com) has joined #duraspace
[14:58] * keithg (~keith-noa@lib-kgilbertson.library.gatech.edu) has joined #duraspace
[14:58] <tdonohue> Hi all...in a few minutes we'll be starting our first DSpace Developer's "Special Topics" meeting regarding our Release process/procedures/planning.
[14:58] * StuartLewis__ (~StuartLew@121.98.157.79) has joined #duraspace
[14:58] <mdiggory> I'm here but I'm at JASIG and may not be able to participate much
[14:58] <tdonohue> mdiggory: good to know...you are welcome to add more comments later to the wiki. http://wiki.dspace.org/index.php/Proposals#Release_Cycle.2FProcess_Proposals
[15:00] * StuartLewis_ (~StuartLew@121.98.157.79) Quit (Ping timeout: 265 seconds)
[15:00] <tdonohue> Ok, we may as well get started. There are three Release Process proposals on the table, though we aren't limited to just discussing the contents of these proposals, they at least give us a starting point. http://wiki.dspace.org/index.php/Proposals#Release_Cycle.2FProcess_Proposals
[15:01] <tdonohue> The goal is not to approve one or more of these (though we could if we wanted)...but, rather to discuss them and see if we can generate a consensus around one or more ideas for how to change our Release processes
[15:01] <mdiggory> For the record I prefer a Time Driven Release cycle. But should be also sensitive to releasing at points of stability, identified by the developers
[15:01] * richardrodgers (~richardro@pool-173-76-18-245.bstnma.fios.verizon.net) has joined #duraspace
[15:02] <mhwood> What I see behind much of this is a need for more frequent *planning*.
[15:02] <mdiggory> and smaller iterations
[15:02] <StuartLewis__> mhwood: +1
[15:02] <tdonohue> also, it's not a matter of one proposal *versus* the other...multiple ideas could be approved or we could come to a consensus about parts of each proposal
[15:02] <mdiggory> quite true
[15:02] <StuartLewis__> I like them all! :)
[15:02] <caryn> faster releases could also allow dspace to be more responsive to community needs..
[15:03] <tdonohue> Sounds like we are already getting into the "Time Driven Release Proposal" http://wiki.dspace.org/index.php/TimeDrivenReleaseProposal
[15:03] <tdonohue> (and that's a good place to start)... richardrodgers was there anything else you wanted to add, as you wrote this one?
[15:03] <mdiggory> caryn: the challenge is that while we are trying to be responsive, we are trying to do too much at once
[15:03] <mdiggory> so a relase has many many new features
[15:04] <caryn> mdiggory: agreed. the comment meant mostly that if we can release a newer version quicker, it might have one or two features, which will satisfy at least part of the population
[15:04] <StuartLewis__> I suppose 1.6 was the opposite. It was a 'Feature Driven Release'. We released once the big 3 requested features were finished. While this seems to have worked this time, I think I'd prefer time driven.
[15:04] <mdiggory> and that also make upgrading more and more difficult for orgs
[15:04] <mhwood> One cure for that is not to try to do it all at once, but to slot developments into a roadmap with multiple waypoints.
[15:04] <grahamtriggs> For the record, I was also going to suggest Time Driven releases as a way forward... which has a nice benefit amongst others of never, ever having a release '2.0'
[15:04] <caryn> mhwood: definitely!
[15:05] <jatrimble> Could I suggest that if time driven, more frequent updates then to be delivered for bug fixes and the like?
[15:05] <mdiggory> grahamtriggs: it certainly fits well will my backporting intiative
[15:05] <caryn> and, if the community knows where the waypoints are, they can also do some planning (i.e. if i know feature x is coming out in a year, i won't upgrade until then)
[15:05] <StuartLewis__> It also might encourage more release coordinators, as your time-in-office is time limited too.
[15:05] <mdiggory> we also need more minor branch maintence releases...
[15:05] <richardrodgers> jatrimble: what kind of updates - minor releases?
[15:05] <grahamtriggs> mdiggory: I have a few thoughts / concerns around that, but this isn't the place right now to discuss
[15:06] <mdiggory> We need to more official version of JHU's CI environment
[15:06] <tdonohue> StuartLewis__ +1 - scheduled releases would allow for definitive timeframes for being a release coordinator
[15:06] <StuartLewis__> Is there anyone who has worries or reservations about time driven releases?
[15:06] <jatrimble> yes, the 1.6.X releases.
[15:06] <mdiggory> We currently have Hudson setup at NESCent doing something similar
[15:06] <mhwood> caryn: oops, there is usually some worry that people will do exactly that: not upgrade until their favorite feature comes out.
[15:06] <tdonohue> Is there anyone who has reservations about a time driven release schedule? Or is everyone in general agreement?
[15:06] * vhollister (~440e1e7e@gateway/web/freenode/x-flskwqwbnhgdxbob) has joined #duraspace
[15:07] <jatrimble> If 1.6.1 1.6.2 1.6.3 each (theoretical only) came out every other month on the 15th. Major releases only twice a year: Feb and August, for example
[15:07] <caryn> mhwood: what is the problem with that?
[15:07] <mdiggory> More integration builds mean continuous testing of more minor releases available to the community
[15:07] <caryn> needing to be fluent in multiple releases?
[15:07] <mdiggory> ehem... 1.5.3 (ducks)
[15:08] <jatrimble> <--will not shoot mdiggory
[15:08] <mhwood> One thing about frequent periodic releases is that some features take more time than the interval allows. We'll need to be comfortable with managing multiple developing branches pretty much all the time, and merging them at appropriate points.
[15:08] <StuartLewis__> More continuous testing requires more automated testing that we don't yet have. Maybe we need a create-an-automated-test-a-thon?
[15:08] <grahamtriggs> jstrimble: well, he ducked, so kick him in the .....
[15:08] <jatrimble> lol
[15:08] <mdiggory> minor releases should not be big fanfare marketing projects....
[15:08] <tdonohue> mhwood - I think that is a good point.
[15:08] <jatrimble> mdiggory: exactly...but the community can depend on fixes on odd or even number months.
[15:09] <mdiggory> stuartlewis: Yes, we are on the verge of having that
[15:09] <jatrimble> Even is a fix release, say 1.6.2 has only 10 fixes...at least their incorporated.
[15:09] <mhwood> caryn: if everybody is waiting for current+2, we get no testing of current+1
[15:09] <caryn> got it.
[15:09] <mdiggory> we should be more comfortable with seeing numbers like 1.6.14
[15:09] <jatrimble> BINGO!
[15:10] <jatrimble> Now we are cooking here....Cigar to Mark
[15:10] <mhwood> Yes, we definitely need to get fixes out more frequently.
[15:10] <grahamtriggs> to be clear, I would scrap 1.6.x, 1.7.x, etc. and go for Ubuntu style numbering - ie. 10.03
[15:10] <jatrimble> The only issue is database changes are/should be incorporated as major releases.
[15:10] <StuartLewis__> So maybe release 1.x.y every 2 months, regardless? Hopefully it will fix some issues, if not all?
[15:11] <jatrimble> *shudder* at Ubuantu release #s.
[15:11] <mdiggory> jatrimble: right... thise smaller maintaince releases are alway backporting backward compatable changes from the trunk
[15:11] <mhwood> Do we want a maintenance-fix interval, a feature interval, and an architecture interval?
[15:11] <richardrodgers> I guess I'd like to see the volume of fixes before setting interval
[15:11] <mdiggory> mhwood: sensible
[15:11] <jatrimble> Well, you could code the release numbers based on the type:
[15:11] <mdiggory> at least try and then adjust
[15:11] <caryn> jatrimble: i was just going to suggest the same thing!
[15:12] <jatrimble> So, you might have 1.6.1 1.6.1a (small fix), 1.6.2 Maintenance release 1.6.2a small fix/bug fix
[15:12] <mhwood> I thought for a while we had that now: a.b.c, a=architectural changes, b=features, c=bugs, but we don't seem to do that.
[15:13] <jatrimble> mhwood: well you assume, but in reality we haven't...
[15:13] <caryn> couldn't we do an architectural fix as 1.7? then, use 1.6.1 as either small fix/bug or maintenance?
[15:13] <mhwood> *Is* there a document that says what our numbers mean?
[15:13] <tdonohue> So, what if we were just to schedule major releases (e.g. 1.7) and let the minor (1.6.1, 1.6.2) be driven more by need (i.e. only release if there are bugs to fix)?
[15:14] <StuartLewis__> caryn: That is hopefully the plan - we've branched a 1.6.x branch now, and have trunk for 1.7.
[15:14] <caryn> tdonohue: that would work well, i think
[15:14] <grahamtriggs> jatrimble: shudder if you must, but having a radical change to the versioning is what frees us from the shackles of the past. Otherwise we will continue to have the mythical '2.0' towering over us, and never really be able to advance around it
[15:14] <jatrimble> Well, 1.8 could be the muthical 2.0 IMHO.
[15:14] <jatrimble> mythical
[15:14] <StuartLewis__> http://wiki.dspace.org/index.php/ReleaseProcedure#Numbering_Convention
[15:15] <StuartLewis__> tdonohue: +1
[15:15] <richardrodgers> tdonohue: +1
[15:16] <jatrimble> tdonohue: +1 doable.
[15:16] <caryn> tdonohue: +1
[15:16] <mhwood> Or can we just engineer a radical change in what people think 2.0 means?
[15:16] <jatrimble> what does that do to your thinking Mdiggory?
[15:16] <tdonohue> I'd like to avoid the "what is 2.0" question for now, and leave that for another Special Topics meeting -- that's a rathole waiting to happen :)
[15:17] <grahamtriggs> tdonohue: I'm sort of a -1. But without really wishing to block a strong majority
[15:17] <mhwood> Hmmm, if we're going to use timing to drive feature releases, we may need to do likewise with fix releases or we'll starve the fixes.
[15:17] <richardrodgers> grahamtriggs: why -1?
[15:17] <tdonohue> grahamtriggs: why? can you explain?
[15:17] <richardrodgers> mhwood: not sure I see that
[15:17] <mdiggory> likewise, I'm focusing on version N.N.N right now
[15:18] * vhollister (~440e1e7e@gateway/web/freenode/x-flskwqwbnhgdxbob) Quit (Ping timeout: 252 seconds)
[15:18] <grahamtriggs> because we're missing how our projects - maven projects - can evolve outside of the overall distribution revisioning
[15:18] <mhwood> Maybe a "3 nonminor bugs or 3 months" sort of schedule? Just to throw some arbitrary numbers.
[15:18] <mdiggory> grahamtriggs: cha ching!
[15:18] <mdiggory> For the record... dspace-services already has a different release number/schedule than trunk
[15:19] <mdiggory> and we already need to consider the next release of it....
[15:19] <grahamtriggs> Say we fix a bug in dspace-api 1.7.0.... we release dspace-api-1.7.1... but we don't really need to push a whole 1.7.1 release... we can leave it up to people to pick the fixes up as needed
[15:19] <mdiggory> and having a space to properly spark more community particiapation in it
[15:20] <StuartLewis__> Does the average DSpace sys admin understand maven release numbering a picking up updates outside of the normal release cycle? (not sure I do fully yet)
[15:20] <mhwood> So do I need a script to keep my build tree up-to-date, instead of just 'svn update'?
[15:20] <richardrodgers> grahamtriggs: OK- but how do timed releases work against that?
[15:20] <tdonohue> I worry about that route... "What version of DSpace are you running? well, we're running 1.7.0, but with some 1.7.1 api, etc. etc." The average person won't get it, I worry
[15:20] <tdonohue> StuartLewis__ +1
[15:20] <mdiggory> grahamtriggs: yes, this is part of my reasoning for suggesting that many part of what are in trunk may need to be refactored into new projects with alternate release cycles.
[15:21] <mdiggory> but, we need more control over upgrading specific portions of DSpace
[15:21] <StuartLewis__> Running mvn package, and finding new code installed when you've not updated your dspace source will worry and confuse a lot of people.
[15:21] <mdiggory> if we are to ever get away from the "classpath overide nightmare"
[15:21] <grahamtriggs> we focus on timed releases of 1.7.0, 1.8.0 (or 10.09, 11.03, etc.)... the individual components of 1.7.1, 1.7.2, etc. just happen as and when (they may even occur after the following major release has occurred - LTS!!)
[15:21] * vhollister (~440e1e7e@gateway/web/freenode/x-olgsqinpwjhygpto) has joined #duraspace
[15:22] <mdiggory> classpath overriding is worse than choosing maven dependencies manually
[15:22] <mdiggory> IMO
[15:22] <mhwood> Hmmm, Eclipse releases oodles of pieces on all kinds of schedules, but then they have to bind up and test specific version sets periodically and release them together under some astronomical name.
[15:22] <tdonohue> I'm noticing we're already at 20mins for this one proposal....
[15:23] <tdonohue> Is this something that grahamtriggs and mdiggory can write up (even in just an email), to give us all a better understanding of your concerns?
[15:23] <grahamtriggs> stuartlewis: I'm not concerned about people not understanding Maven. It's a standard tool, and worth educating them. If we don't educate, then we always stick ourselves in the position of no-one learning
[15:23] <StuartLewis__> tdonohue: What is the proposed outcome from this meeting? set of initial proposals we can take further?
[15:23] <tdonohue> outcome = improving proposals or scrapping them and coming up with new ones
[15:23] <mdiggory> grahamtriggs: we are heading down the architecture discussion road... maybe we should capture this as another special topic....
[15:23] <tdonohue> so, yes, we're looking to come up with some proposals to take further, and eventually vote on
[15:24] <StuartLewis__> Ok - how about a proposal for 1.x releases every 6 months?
[15:24] <kshepherd> hi all, bit late sorry
[15:24] <grahamtriggs> mdiggory: fair enough, but it's worth capturing the general point here...
[15:24] <mdiggory> I'd like to address the asynchronous release points outside the chat asynchronously...
[15:24] <caryn> StuartLewis_: +1
[15:25] * kshepherd reads scrollback
[15:25] <mdiggory> then we can revisit it, maybe next time
[15:25] <grahamtriggs> if DSpace is to innovate quickly, then people will have to learn quickly!
[15:25] <StuartLewis__> with months 1-4 for development, and months 5-6 for testing, fixing, and release?
[15:25] <mhwood> But how much learning is necessary, in various roles?
[15:25] <mdiggory> grahamtriggs: Its already here... the world is inovating right now around DSpace
[15:26] <richardrodgers> stuartlewis: I'd say let initial frequency match volunteer RCs
[15:26] <tdonohue> It sounds like we've come up with the following: (a) Scheduled releases is generally good (we need to decide on a proposed schedule), (b) grahamtriggs & mdiggory would like to better use maven asynchronously (need that idea captured somewhere -- and discuss in more detail later)
[15:26] <jatrimble> graham: DSpace installed in so many places because it was easy. Make it hard, and people won' install it.
[15:26] <mdiggory> I'm listening to Rod Johnson from VMWare /Springsource talk about this stuff.... right now JASIG keynote
[15:27] <caryn> jatrimble: +1
[15:27] <mdiggory> jatrimble: yes still needs to be easy to install....
[15:27] <mdiggory> But we have two conflated issues here
[15:27] <caryn> and, it should be easy to understand what we're installing
[15:27] <mdiggory> 1.) installation 2.) development
[15:27] <tdonohue> Do we want to table the rest of this for now, and move on to other suggestions? We need to discuss in more detail what Mark & Graham have suggested, but it sounds like we generally agree here
[15:27] * StuartLewis__ notes we till get more dspace-tech emails about maven than anything else.
[15:28] <mdiggory> We do need to achieve and installer that does not require the user to need to expereince MAven
[15:28] <StuartLewis__> tdonohue: +1 - move onto release advisory team
[15:28] <grahamtriggs> jatrimble: The proposal doesn't make it any harder for people to install a major revision. They just need to do a bit more thinking to be able to get patches without upgrading to the next major revision
[15:28] <tdonohue> Ok, next proposal (brainstorm from Val & I) - Establishing a Release Advisory Team: http://wiki.dspace.org/index.php/ReleaseAdvisoryTeamProposal
[15:29] <mdiggory> Fedora moving to OSGi, and this is one of the reasons...
[15:29] <mdiggory> ok, moving on
[15:30] <mhwood> That's one way to get members in various roles to mix a bit more, which I think we need.
[15:30] <tdonohue> I'll note that StuartLewis__ had a similar "advisory team" suggested...he called it a "community decision making team" in his blog post
[15:30] <StuartLewis__> Speaking as the most recent RC, I'd have liked to have had a Release Advisory Team to work with.
[15:30] <mdiggory> I like Advisory more that Decision Making
[15:30] <mdiggory> but still... needs to have a leadership role
[15:30] <caryn> i actually like this idea, and i would add that it would be good to have this in place before the last previous version is cut (kind of like what Stuart was talking about with RCs)
[15:31] <mdiggory> But need to be careful that it does not bottlenecck development or release processes
[15:31] <jatrimble> Who has time to think? I've got 5 servers to administer plus 35 librarians to keep calm.
[15:31] <mhwood> Or that it ignores what development can accomplish per unit time.
[15:31] <StuartLewis__> mdggory: My hope is it would speed things up by distribution actions, rather than being a bottleneck.
[15:31] <tdonohue> StuartLewis___ +1
[15:32] <tdonohue> we're not looking to create "red tape"
[15:32] <StuartLewis__> This weekly dev meeting would / could still be the primary development meeting, but with additional release-related meetings for the release advisory group.
[15:32] <tdonohue> this is more a group that could help advise the RC & committers about new feature ideas, etc.
[15:32] <mdiggory> So we need to identify how it will will speed up processes....
[15:32] <caryn> it allows a wider community to play the role that comes naturally (committers could developers, RC could manage, advisory could provide direction, etc)
[15:33] <StuartLewis__> caryn: +1 - yes - that is one of the most important aspects. It brings in more people with more skills and time.
[15:33] <tdonohue> I think rather than "speed up processes" I see this group as helping us better *schedule* or plan features -- this group could help us better understand what the community means when it says "we want statistics" (like in the 1.6 planning), or "we want versioning", etc
[15:34] <mdiggory> I think that I am wary because traditionally the release process has been entrenched in a very technical level of complexity to attain.
[15:34] <richardrodgers> OK but then that isn't release planning...
[15:34] <mdiggory> richardrodgers: I agree
[15:34] <mhwood> Yes, smoother and more predictable progress may be more satisfying to the broader community than just "faster".
[15:35] <mdiggory> thats more like project management / requirements gathering
[15:35] <richardrodgers> yep - which we could certainly do better
[15:35] <tdonohue> ok, so maybe the name is wrong...I was thinking more at a proj. mgmt level overall
[15:35] <grahamtriggs> tdonohue: I would rather look at it as group to inspire and challenge the community to create new ideas
[15:35] <tdonohue> that could happen too, grahamtriggs
[15:36] <tdonohue> it's essentially a group that the RC + committers can go to that helps us communicate better with the community / repo mgrs
[15:36] <mdiggory> I think that we should think about this visually....
[15:36] <caryn> i think both would happen... and the community would have a motivation to say "check out dspace" (i.e. i helped with it, so it's really cool...)
[15:36] * kshepherd proposes a Release Advisory Group Role Definition Committeee ;)
[15:36] <mdiggory> As an invereted pyramid
[15:36] * tdonohue proposes we put kshepherd in charge of that committee :)
[15:36] <mdiggory> we need a strong platform for developers to inovate
[15:36] <vhollister> grahamtriggs: faciliate discussion/translate req'mts too
[15:37] <StuartLewis__> I would have loved to have a group that could help with things like PR, project management, feature specification, etc. Lots of different things. They act as a conduit into the community for these different aspects.
[15:37] <mdiggory> They are the widest part of the pyramid.... at various levels of support under that platform are project management and foundation
[15:37] <jatrimble> <==has to run...will read logs later.
[15:37] * jatrimble (~jtrimble@maag127.maag.ysu.edu) Quit (Quit: Leaving)
[15:38] <mdiggory> but that end goal of the structure is to facilitate innovation at the developer level for the benefit of the user community.
[15:38] <grahamtriggs> vhollister: yes, I'm just looking at the idea of 'guiding the committers'... to do what? we've all basically said we don't have the time - at least not to be asked to do major things.
[15:39] <tdonohue> So, if we renamed this to "Community Advisory Group"? does that change things? Pull out the "Release" part of it, even though I feel they will still be helping RC with various proj. mgmt type tasks on a given release
[15:39] <StuartLewis__> I think a group would hope to free up developers to develop, by taking away other background tasks.
[15:39] <mhwood> tdonohue: I think that's a good idea
[15:39] <caryn> grahamtriggs: wouldn't more specific design specs help streamline the development?
[15:39] <mdiggory> empowering developers = innovation = happier user community
[15:39] <richardrodgers> there still is an unmet need for a 'dating service' - where folks interested in same things can better find each other and pool resources
[15:40] <mdiggory> what tasks would be taken away?
[15:40] <grahamtriggs> yes... if we advise the community of where we want to go, and what we need to happen, we can hopefully get some good submissions
[15:40] <tdonohue> grahamtriggs: I wouldn't think of it as actively guiding committers....it's more of a team that the committers can ask questions too...like, what features do you mean when you say "versioning", etc
[15:40] <vhollister> grahamtriggs: but it would be helpful for such a group to narrow the priority list and have the req'mts laid out w/specifics (all informed by the larger community)?
[15:40] <mdiggory> that make oru lives easier?
[15:40] <tdonohue> mdiggory: I think the task of us having to gather requirements from the community would be taken away -- this group would do that for us
[15:40] <mdiggory> the challenge is that the projects that are completed by developers come from organizational requirements.... not the community
[15:41] <mdiggory> versioning will happen as a project when someone is paid to work on it
[15:41] <mhwood> Sometimes more innovation = confused community. Change things too fast and people dig their heels in. Innovation is one important dimension of development, but there are others.
[15:41] <mdiggory> whether that comes from an institution or a company
[15:42] <mhwood> But developers need to keep an ear open to the requirements process, or they get requirements that can't be met, or that could've been met much more cheaply with a little adjustment.
[15:42] <tdonohue> (versioning was just an example...could have just as easily said "statistics" or "embargo"....the idea is the same, they'd help us understand what repo managers are really looking for out of features)
[15:42] <grahamtriggs> vhollister: but who is going to get tasked with implementing the priorities? :)
[15:42] <mdiggory> I don't think we have any problems recognizing that we want something like "versioning" , the challenge is is dedicating resources to work on it
[15:42] <caryn> tdonohue: that's exactly what I'm thinking...
[15:43] <mhwood> Another challenge is knowing what people mean by "versioning".
[15:43] <mdiggory> versioning is a good example because while we have projects that piloted it, its not in trunk
[15:43] <tdonohue> mdiggory: this group isn't about the resources...that would still take us finding a volunteer to implement. this group is just about helping that volunteer (once they are found) to map out the requirements, etc
[15:43] <StuartLewis__> The group would be purely advisory - they wouldn't be able to ask for things that we don't have the development for. And a portion of the group would be made up of developers / committers anyway. So I have no worries about having such a group.
[15:44] <tdonohue> StuartLewis__ +1 - group is completely advisory...they do not "control" the committers, so to speak :)
[15:44] <mdiggory> tdonohue: I like that.
[15:44] <vhollister> grahamtriggs & mdiggory: good points about the potential pitfal of this structure -- what if developers can't deliver -- it would lose momentum
[15:44] <mhwood> We can't let the advisory function become too much out of sync with delivered requirements, though.
[15:44] <mdiggory> But even moreso.... a lobbying committee to get directorship to buy into sharing those resources
[15:45] <vhollister> ==>i've got to go, i'll follow up on the transcript
[15:45] <tdonohue> mhwood: right... that's why I initially called this a "Release Advisory" group...as I saw it as helping give advice around given releases, and they'd need to be up-to-speed on what was planned for the next release, etc
[15:45] <grahamtriggs> vhollister: it's good to have more users involved, but we need to make sure it doesn't create a weight of expectation
[15:45] <mdiggory> because if the source of the $$$ supporting that developer do not buy in... then they do not have the time to volunteer
[15:46] <vhollister> grahmtriggs: agreed - delicate, artful balance on that one
[15:46] <caryn> helping to clarify user community needs is only part of the group's functions, right? they would also help with marketing/communication - and i might add testing
[15:46] <tdonohue> grahamtriggs: that's why Val & I are also on this group...we can help stop unreasonable expectations :)
[15:46] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[15:46] <mhwood> Dunno about focusing on releases, though. More like updating the roadmap?
[15:46] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[15:46] <mdiggory> this is all good...
[15:47] <mdiggory> mhwood: +1
[15:47] <tdonohue> So, in general, does this idea sound good? Say we just called it a "Community Advisory" group, does everyone like these concepts?
[15:47] <mdiggory> +1
[15:47] <StuartLewis__> Yeas - I like it! :) +1
[15:47] <caryn> +1
[15:47] <kshepherd> yep +1
[15:47] <mhwood> I like more understanding between users and developers. +1
[15:47] <richardrodgers> sure more involvement & voices good +1
[15:48] <mdiggory> careful ... is this voting?
[15:48] <tdonohue> excellent. Val & I can then work to flush this out a bit more, and we can have a final proposal that everyone can vote on later
[15:48] <tdonohue> no no..this is not official voting right now :)
[15:48] <tdonohue> just making sure we have general consensus to bring this idea forward
[15:48] <mdiggory> quite true
[15:49] <tdonohue> Val also wants to put this idea in front of her "DSpace Community Outreach Group" as many of them may be prime candidates as potential members for this sort of advisory group
[15:49] <tdonohue> ok, so the last set of ideas are all Stuart's. StuartLewis__ is there anything you wanted to highlight that we haven't already discussed?
[15:50] <tdonohue> http://wiki.dspace.org/index.php/Proposals#Release_Cycle.2FProcess_Proposals
[15:50] <StuartLewis__> Most of what I wrote is based around what we have talked about so far.
[15:51] <grahamtriggs> this is another area where timed releases will help... most of the 'process' becomes self-organising....
[15:51] <StuartLewis__> The only difference was a though about moving 'executive decision making powers' out of the classic DSpace 'committers group', so that being a committer means just that, having svn write access. This lowers the bar for entry to the committers group, brings in more committers, and more available effort.
[15:52] <mhwood> Like, "OMG the release date is roaring down on us, we'd better get organized"?
[15:52] <StuartLewis__> I realise this is contraversial though!!!
[15:52] <mhwood> What decisions are we talking about? Because if no committer is willing to commit a patch, it doesn't go in, regardless what others think.
[15:53] <StuartLewis__> mhwood: The committers group has traditionally conflated "committing code" with "decision making, direction steering, and ultimate control over what goes in DSpace".
[15:53] <kshepherd> i agree that commit rights and decision-making don't have to go hand-in-hand, but i tend to think the "barrier of entry" stuff should be focused more on patches making it to JIRA in the first place
[15:53] <kshepherd> it's easy to test and commit a patch
[15:54] <kshepherd> writing it takes more motivation ;)
[15:54] <tdonohue> decision making = voting privileges. Technically, we let anyone vote in these meetings, but if it came down to a true disagreement then the committers votes are "more official" (if that makes sense)
[15:54] <mdiggory> sorry... ive got to run... I'll readup later
[15:54] * mdiggory (~mdiggory@ip-66-181-1-6.cust.i2bnetworks.com) Quit (Quit: mdiggory)
[15:55] <StuartLewis__> Yes - things have changed over the past year since we have started to have these weekly developer meetings. This has opened up the decision making process, so I see it as less of a problem now than a year ago.
[15:55] <grahamtriggs> "If all 700+ institutions could donate a small amount of effort, must think what we could do!" - spend all our time in admin!! :)
[15:55] <kshepherd> hah
[15:55] <tdonohue> and, Stuart's just suggesting that there be two groups, one with the full "voting" privileges, and one that can commit code....there may be lots of overlap between the two, but you could also just be in one of the two
[15:55] <mhwood> Decisions about patches? about committing resources to features? about architecture? about scheduling? other?
[15:56] <richardrodgers> stuartlewis: I'd say more that 'committing code' has been a *proxy* for 'decision making'
[15:57] <tdonohue> so, the big area that this idea now affects is whether or not we allow people to commit code to our SVN (in modules or prototypes/sandbox, especially) without being full-fledged "committers"
[15:57] <StuartLewis__> Perhaps we're too involved in the process - maybe we need to ask people outside of this group and the people here today? Maybe we're the wrong people to answer the question of whether the committer group is seen as an effective group or not?
[15:58] * kshepherd has a conference call to join now, so might be semi-afk
[15:58] <tdonohue> StuartLewis__ yea, that could be too
[15:58] <mhwood> Effective for what?
[15:58] <kshepherd> StuartLewis__: yeah good questions -- hard for us to know without some outside observations
[15:58] <StuartLewis__> mhwood: Another good question! What *is* the role of the committer group vs. what *should* it be?
[15:59] <mhwood> Well, if we're going to have this other role defined, then I guess a committer is like what IBM called a "code librarian" -- someone who makes sure that good practices have been followed, and then checks changes in.
[16:00] <mhwood> Probably with a formal statement of good practices to be checked.
[16:01] <tdonohue> Ok, well we're at the top of the hour. I think we've made some general headway here today on Release process ideas. Val & I will move forward with the "Community Advisory" group idea...I'd appreciate it if mdiggory and grahamtriggs could write up their maven asynchronous ideas somewhere, and we can discuss later how to work that into the Scheduled Releases idea (which also seemed to gain good traction)
[16:02] <mhwood> Would like to see some discussion sometime of low-level stuff like, where do things not destined for the upcoming release go.
[16:03] <richardrodgers> mhwood: you mean like a 'contrib' thing?
[16:04] <tdonohue> mhwood: couldn't we handle that by working in multiple branches? (e.g. 1.6.x for 1.6.1 and trunk or 1.7.x for 1.7.0, etc)
[16:04] <grahamtriggs> richardrodgers: I was going to say something else, but historically there wouldn't be much difference
[16:04] <StuartLewis__> tdonohue: / vhollister: Thanks for facilitating this - has been an interesting hour of discussion.
[16:04] <mhwood> No, like "this is too late for 1.6.0, so it goes in 1.6.x".
[16:05] <richardrodgers> Oh ok, yes there needs to be some protocols worked out there
[16:05] <mhwood> Yes, this would mean branching sooner.
[16:05] <tdonohue> right, so if we opened branches sooner, you could put it right into the next version's branch
[16:05] <tdonohue> yep...exactly
[16:06] <tdonohue> thanks all for the discussion! I think this was great. We can continue these brainstorms on IRC or future meetings, and at some point we will vote on the final proposals
[16:06] <StuartLewis__> Bye all. Thanks.
[16:06] * StuartLewis__ (~StuartLew@121.98.157.79) Quit (Quit: StuartLewis__)
[16:06] <mhwood> Yes, thanks all.
[16:06] <caryn> thanks, everyone!
[16:06] * caryn (~80c8e115@gateway/web/freenode/x-esttweiaczqkpidr) Quit (Quit: Page closed)
[16:07] * keithg (~keith-noa@lib-kgilbertson.library.gatech.edu) Quit (Quit: keithg)
[16:13] <richardrodgers> bye thanks all
[16:13] * richardrodgers (~richardro@pool-173-76-18-245.bstnma.fios.verizon.net) Quit (Quit: richardrodgers)
[16:34] * noreply_ (~chatzilla@c-67-171-28-159.hsd1.wa.comcast.net) Quit (Read error: Operation timed out)
[16:35] * noreply_ (~chatzilla@c-67-171-28-159.hsd1.wa.comcast.net) has joined #duraspace
[18:05] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has left #duraspace
[18:43] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[18:44] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[19:10] * scottatm (~scottatm@peat.evans.tamu.edu) Quit (Quit: scottatm)
[19:49] * bradmc_ (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[19:49] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[19:49] * bradmc_ is now known as bradmc
[20:44] * mdiggory (~mdiggory@rrcs-76-79-212-182.west.biz.rr.com) has joined #duraspace
[21:00] * mdiggory_ (~mdiggory@rrcs-76-79-212-182.west.biz.rr.com) has joined #duraspace
[21:03] * mdiggory (~mdiggory@rrcs-76-79-212-182.west.biz.rr.com) Quit (Ping timeout: 265 seconds)
[21:03] * mdiggory_ (~mdiggory@rrcs-76-79-212-182.west.biz.rr.com) Quit (Read error: No route to host)
[21:09] * mdiggory_ (~mdiggory@rrcs-76-79-212-182.west.biz.rr.com) has joined #duraspace
[21:13] * mdiggory_ (~mdiggory@rrcs-76-79-212-182.west.biz.rr.com) Quit (Ping timeout: 252 seconds)
[21:17] * mdiggory (~mdiggory@rrcs-76-79-212-182.west.biz.rr.com) has joined #duraspace
[21:23] * mdiggory (~mdiggory@rrcs-76-79-212-182.west.biz.rr.com) Quit (Quit: mdiggory)
[22:18] * cccharles (~cccharles@131.104.62.47) Quit (Remote host closed the connection)
[22:20] * vhollister (~440e1e7e@gateway/web/freenode/x-olgsqinpwjhygpto) Quit (Quit: Page closed)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.