From Sit
Jump to: navigation, search


  • Roadmap Discussion (From 12:00h UTC)
    • Aims/Targets for SiT 4.0 feature wise, whilst we have a list of features in Mantis these where put there sometime ago so would be useful to review/reassess.
    • Time scales, I know where all busy though having some realistic dates for feature freeze/alpha/beta/x/y/z/release would give us something to focus on. Currently we have 3.6 release 2010-05-11, 3.80 release 2010-05-12 and 4.0 2010-05-15 looks like we're currently in for a busy 4 days ;-)
    • Future of 3.x and whether 3.8's trigger overhaul should be migrated into 4.x and 3.8 dropped?
    • Our migration to git for 4.x development, how we intend to work with it etc
  • Bug triage (All day)
    • Making sure each bug has enough information for the developers to work on
    • Making sure each bug is filed under the correct category
    • Making sure the bug has sensible "Severity" and "Priority" fields
  • Help for new developers

Meeting Summary

  • Aims for SiT 4.0

The roadmap was reviewed and it was decided to push working feedback system, mysql abstraction from 4.0 to 4.1, it was decided to drop 3.8 and move the triggers features to 4.0, the roadmap has been updated at

  • Time scales

It was decided approximately 6 months would be reasonable and the beginning of September is set as the release schedule with a freeze on the 1st and release on the 4th

  • Future of 3.x

It was decided 3.8 would be merged with 4.0 and that 3.60 would be releases as a Long Term Support (LTS) version at the end of March (aim for the 27th)

  • git

It was decided that 3.x development will remain in SVN though 4.x will be done using git. Our subprojects (release tools, vm, website, project) will remain in svn for the time being with the possibility of migrating when we are comfortable with git. It was decided to explore using along with github Discussion was had around staging commits and how we work with git several options where suggested heavy usage of branches was strongly agreed by all though on the topic of staging/peer review their was concerns around sufficient time to perform such maintenance, it was decided to review this at a latter date when we where more comfortable with git.

Full minutes are included below

Meeting Log

[12:05] <ericthefish> ok first off, aims/targets for 4.0
[12:05] <ericthefish> paulheaney: did you really mean 4.0 or were you wanting to discuss 4.x more generally
[12:06] <ericthefish> we have a heck of a lot of bugs and feature requests it would probably take several hours to go through and set targets on them all
[12:06] [Notice] -sitbot to #sit- New news from mantis: 0001044: Issues with special characters in email addresses || 0000962: No translation for SLA target updates
[12:06] <paulheaney> well I was thinking general goals for 4.x and what is achievable in 4.0, I know on the roadmap we have 4.0, 4.1, 42 etc I think we should have a set of goals for 4.0 and a set for 4.x which we can more accurantly target when we have released/almost release 4.0
[12:06] <ericthefish> but I think it would very useful to set a focus for our future development
[12:07] <paulheaney> I think 4.0 should be big changes like menu etc things which people will notice
[12:07] <ericthefish> our currently focus for 4.0 says "Theme freshen up, code tidy, Basic open access & Interoperability "
[12:08] <ericthefish>
[12:09] <paulheaney> Yeah I think that makes sense
[12:09] <ericthefish> i've put the roadmap onto the wiki menu on the left, maybe we won't let it get outdated so much now
[12:09] <paulheaney> I think the openaccess one is quite an easy one to acheive
[12:10] <ericthefish> I would like to revamp the menu too in 4.0
[12:10] <paulheaney> seconded
[12:10] <ericthefish> so if we mention menu in the focus as well are there any other features that ought to be in 4.0 or is that it?
[12:11] <paulheaney> how we handle schema is one thing I'd like to get in their as well
[12:11] <ericthefish> yeah i saw you logged a bug about that, got teh number handy?
[12:12] <paulheaney> 1080
[12:12] <xerosis> I want to make triggers user-friendly obviously too
[12:12] <paulheaney> not much in that bug just a set of my ramblings, was more of a reminder
[12:12] <xerosis> not loads of code needed for that really
[12:12] <ericthefish> xerosis: is that the work that was planned for 3.80 ?
[12:12] <xerosis> yeah
[12:12] <xerosis> I;ve started it in git, just needs more work
[12:12] <paulheaney> xerosis: I agree the interface/how you create them should be easier
[12:12] <tomse> some renames.. Maintenance = Contracts, and Inventory = remote access/ remote support
[12:13] <ericthefish> what concerns me at the moment is that we have too much work logged against 4.0, while I agree everything we've said here, Mantis tells a different story I think
[12:13] <Nicdev007> i second the menu and triggers overhaul
[12:13] <paulheaney> Inventory isn't really remote access its more just remote access details
[12:14] <tomse> paulheaney: that was my meaning :-)
[12:14] <paulheaney> Mantis does have a list of quite fine grained fixes in 4.0 which differs from the large topis we have on the wiki
[12:14] <Nicdev007> on another point i think escalations are important to look at as well
[12:14] <paulheaney> tomse: so you mean add some sort of remote access functionality ?
[12:14] <ericthefish> what I want to do is to set a "focus" for each planned release, and some headline goals, and if a bug report or feature request doesn't fit with the roadmap plans we should bump them
[12:14] <tomse> paulheaney: no,no.. just rename Inventory to remote support details or remote access details..
[12:15] <ericthefish> the word inventory to me in the context of support suggests a collection of objects that we provide support for
[12:15] <paulheaney> I agree, we should create a 'bug' for each of our big features, assign specifics as children of and anything which doesn't match we move to 4.x
[12:15] <Nicdev007> ericthefish: where was the escalations in the initail roadmap?
[12:15] <tomse> perhaps add a download button to download the config of selected to match the program being in use for that remote instance
[12:16] <xerosis> remember the inventory isn't just for remote access, it can be for local workstations, software etc
[12:16] <ericthefish> Nicdev007: I planned some basic escalation support for 4.0 and then to improve on it in 4.1
[12:16] <Nicdev007> that feature is a drawing point in a lot of packages out there
[12:16] <ericthefish> xerosis: I think inventory ought to be more closely linked with contracts or else renamed as tomse suggests
[12:17] <tomse> xerosis: but it's still details regarding how to remote that workstation/software right ?
[12:17] <ericthefish> Nicdev007: agreed
[12:17] <Nicdev007> ericthefish: seconded :)
[12:17] <xerosis> tomse: not necessarily, it can be used to log an incident against a particular serial number of software for instance
[12:18] <tomse> oohh... there was a functionality that passed my head..
[12:19] <ericthefish> xerosis: since it doesn't link to contracts though there's no concept of support for software serial 12345 expiring?
[12:20] <ericthefish> what are our plans surrounding web services api?
[12:20] <paulheaney> to implement one ?
[12:21] <Nicdev007> ericthefish: i think we discussed this before
[12:21] <ericthefish> when? by who?
[12:21] <ericthefish> it says in the wiki that is a 4.0 feature too
[12:21] <Nicdev007> you and me i think late one evening ;-)
[12:21] <paulheaney> I think we're agreed we need one, it sill be soap (probably nusoap) though we could do to confirm the initial 4.0 functionality
[12:21] <ericthefish> looking here
[12:22] <paulheaney> i.e. do we just view things, edit, create?
[12:22] <ericthefish> I just feel that we have a bit much to chew on
[12:22] <paulheaney> I'd say we should defiantly support viewing/adding/updating incidents and take it from their
[12:22] <ericthefish> imo better to make more releases with less features in each than a single big bang release with tons of features
[12:22] <Nicdev007> paulheaney: i agree that is good enough for a start
[12:23] <Nicdev007> ericthefish: yeah that way we don't break too much
[12:23] <paulheaney> ericthefish: I agree though 4.0 has to be something big to warrent a major bump
[12:23] <ericthefish> each release we make gets us noticed, we get a mention on freshmeat etc. and each release we gain more users
[12:23] <ericthefish> and yeah as Nicdev007 says it's less to break and we also get the benefit of more testing on the features
[12:24] <paulheaney> 4.0 should have the basics of the big new features and 4.1 will build on them
[12:24] <ericthefish> yeah I agree with that, I don't want to be making architecture changes in 4.1
[12:24] <ericthefish> but we could add code in 4.0 but not actually release the feature until 4.1
[12:25] <ericthefish> so make a web services framework in 4.0 but not usable until 4.1
[12:25] <Nicdev007> ericthefish: i like the way we approach it today as in the past we had some other major issues creep in when we tried to do too much
[12:25] <paulheaney> We could make a particular feature as beta (say the WS api)
[12:25] <paulheaney> mark not make
[12:25] <Nicdev007> putting the framework in place is a good idea
[12:25] <ericthefish> yeah can do that, so long as it doesnt' affect other parts of SiT! (which I doubt WS would do)
[12:25] <tomse> seconds with paulheaney, perhaps 2-3 features
[12:26] <ericthefish> ok I'm happy with that too, we should note down in a mantis issue which features we'll do for 4.0
[12:26] <ericthefish> xerosis: that ok for you?
[12:26] <xerosis> one thing I need to bring up, I might be wrong but I think we have two sets of functions for incidents, one in sit, one in WS
[12:26] <tomse> hmm probably I misunderstood.. I meant for beta 4.1 there can be a 2-3 new features
[12:27] <ericthefish> ah ok tomse you're thinking of a slower release of features?
[12:27] <paulheaney> xerosis: my original idea was to move everything over to using the classes so both SiT and WS would use them, but I'm not sure where we stand on that
[12:27] <paulheaney> though I agree we need to avoid code duplication
[12:27] <xerosis> ah I remember now
[12:27] <tomse> ericthefish: not necessarily but rather make it more open to the public what new features are implemented in said beta
[12:28] <xerosis> yeah so we'd need to start porting stuff over at some point
[12:28] <ericthefish> tomse: ok makes sense
[12:28] <ericthefish> thats quite a risky move isn't it, new code for the most fundemental parts of SiT
[12:28] <xerosis> to be fair, some of the code needs cleaning up, we have functions that spew out html which isn't nice :(
[12:28] <tomse> right now one has to read through the changelog to see the new features.. but to add some major ones (more commercially) and yell about them...
[12:29] <ericthefish> triggers would be a nice thing to yell about I think
[12:30] <ericthefish> escalations too maybe
[12:30] <Nicdev007> xerosis: i agree we have a lot of work on functions that are quite old and spew out html ...
[12:30] <Nicdev007> and also on cleaning up
[12:30] <tomse> i.e. for beta 4.0   Triggers, brand new layout, <something more here>
[12:30] <ericthefish> are there any goals listed at that we /don't/ want to do for 4.0 ?
[12:30] <xerosis> for me: triggers, escalations, WS, new menu and theme
[12:31] <xerosis> feedback could be moved
[12:31] <paulheaney> tomse: so was intended 4.0 to be a 'stable' release but a couple of features would be marked beta
[12:31] <xerosis> mysql abstraction is too ambitious
[12:31] <paulheaney> yeah mysql abstraction is too ambitious
[12:31] <ericthefish> paulheaney: 4.0 is unlikely to be a stable release if we add so many new features
[12:31] <xerosis> contractless not be complete in time either
[12:32] <paulheaney> and feedback is 'working' at the moment so its not a biggie
[12:32] <xerosis> but I'd like to get that started
[12:32] <paulheaney> what is meant by "user preferences" ?
[12:32] <tomse> paulheaney: feedback is broken
[12:32] <tomse> I found 2 bugs recently
[12:33] <ericthefish> feedback has always been a neglected feature since I first wrote it
[12:33] <paulheaney> tomse: last time I tested it was working (well sending out emails and allowing people tp pcomplete them
[12:33] <ericthefish> I think it works but it's very buggy, not as polished as other parts of SiT
[12:33] <xerosis> I think salford's is being propped up by something
[12:34] <tomse> paulheaney: I logged 2 bugs regarding my findings (needs some confirmations though)
[12:34] <paulheaney> Salfords works as we only have one form (and we don't use some of SiTs form we use a custom one)
[12:36] <ericthefish> can feedback water till later in the 4.x cycle?
[12:36] <tomse> other than that.. a suggestion :  Add a generic Feedback form to the sample data
[12:36] <ericthefish> *wait!  not water!
[12:36] <ericthefish> thats what happens when you reach for a drink while typing
[12:36] <tomse> ericthefish: I think the 2 bugs I found are easy to fix.
[12:36] <paulheaney> I think if theres specific bugs in 3.x it would be good to fix them their but yes 4.x would be a more realistic time frame to overhaul them
[12:37] <ericthefish> yeah bugs like those that tomse has found I think we'll fix in 3.x if they're not really hard to fix and those fixes will be ported to 4.x
[12:38] <tomse> this gives a great sense of stability aswell
[12:38] <ericthefish> I plan to keep trying to maintain 3.x as stable all through developing 4.0 and probably up to releasing 4.1
[12:38] <Nicdev007> ericthefish: but feedback is not a new feature really
[12:38] [Notice] -sitbot to #sit- New news from mediawiki: MediaWiki:Sidebar
[12:39] <ericthefish> Nicdev007: the plans for feedback in 4.0 were basically to overhall it and put something in the portal to let people add feedback right from there
[12:39] <Nicdev007> ah ok sorry i misunderstood
[12:40] <tomse> ericthefish: should we make a bug regarding each module to add ideas ?
[12:40] <ericthefish> tomse: yes I think so
[12:40] <tomse> little off topic though..
[12:41] <ericthefish> I really wanted to do the contractless support, I don't think it takes much to get that working
[12:41] <paulheaney> ericthefish: no I think thats quite straightforward
[12:41] <paulheaney> we'd just had a generic site (say contractless) and they 'join' that site
[12:42] <Nicdev007> ericthefish: did we make goal for mysql abstraction?
[12:42] <Nicdev007> even if it is  ambitious
[12:43] <paulheaney> Nicdev007: Think thats definetly a 4.x feature
[12:43] <paulheaney> theres 1100 mysql queries
[12:43] <tomse> by abstraction you mean support for different SQL servers ?
[12:43] <Nicdev007> paulheaney: yeah because we had a call from our IT to support other DB's too and that is maybe a good first step
[12:44] <tomse> ahh
[12:44] <Nicdev007> or THE first step
[12:44] <paulheaney> yeah that was the plan so we could support Postgress and others (MS SQL, Oracle etc)
[12:44] <Nicdev007> our gus had a look at the code but the way it is today it is too difficult to support other DB4S
[12:45] <Nicdev007> *DB's
[12:45] <tomse> paulheaney: seems to be a slaves work, mostly search and replace after the initial has been done, right ?
[12:45] <paulheaney> I know ericthefish isn't a fan of this one
[12:45] <Nicdev007> ericthefish: ?
[12:45] <xerosis> I think it needs to be done at some point
[12:45] <Nicdev007> second that
[12:45] <xerosis> the way the SQL is done atm is really sloppy anyway
[12:45] <paulheaney> Alot of it would be fairly mundane so you have to replace all the variable which operate on the data returned
[12:45] <ericthefish> nope, I think thats fair to say.  My experience of that is that you end up with really bad database support because you can only use the few database features that all the products have in common
[12:46] <Nicdev007> i am afraid in the year to come they may force us to MSSQL and that puts me in a pinch :D
[12:46] <paulheaney> With the exception of LIMIT I'm not sure what the other DBs don't support
[12:47] <Nicdev007> bbias
[12:47] <tomse> well.. since it's on the drawing table.. I take it that MySQLi will be supported aswell
[12:48] <ericthefish> if we do do abstraction then yes I think it's pretty much a given part of that would be mysqli
[12:48] <ericthefish> I'm not against it exactly I just don't place as much importance on it as anybody else, and it worries me that we're creating opportunity for more support issues
[12:49] <paulheaney> The problem with abstraction is its a massive job and touches ALL of sit
[12:49] <ericthefish> yeah
[12:49] <xerosis> if done in stages it would be okay: create a mysql only function to start with
[12:49] <tomse> also it decreases the performance
[12:49] <ericthefish> yeah
[12:50] <xerosis> I'm not for or against mysql abstraction, I'm for code abstraction
[12:50] <paulheaney> and thus isn't something to do lightly if we're changing other parts
[12:50] <xerosis> 1100 queries to edit manually itself tells a story
[12:50] <ericthefish> xerosis: you mean passing all our db queries through something?
[12:50] <paulheaney> I think mysql abstraction should be a release on its own
[12:50] <xerosis> yeah
[12:50] <ericthefish> yeah I'm for that definately
[12:50] <paulheaney> xerosis: don't go their spent that last week sorting out when that went wrong
[12:50] <paulheaney> ericthefish knows what I mean
[12:50] <xerosis> then once that is done (which is 99% of the work) possibly add in DB abstraction
[12:51] <ericthefish> paulheaney: lol
[12:51] <paulheaney> I think the classes stuff I proposed would reduce the number of queries
[12:52] <xerosis> true
[12:52] <paulheaney> As long as we don't get to the point where we have a function to draw ONE <option> tag in a <select> I probably be happy at the moment
[12:52] <ericthefish> we're talking about rewriting huge chunks of SiT here though
[12:52] <ericthefish> all very laudable but practically quite difficult to do
[12:52] <paulheaney> yeah thats the problem
[12:52] <ericthefish> anybody have a solution?
[12:53] <paulheaney> not really a solution though anyone used PDO?
[12:53] <xerosis> it doesn't have to be all in one go
[12:53] <paulheaney> Its what drupal are switching to in version7
[12:53] <xerosis> I'm not sure that it's an issue really
[12:53] <ericthefish> I've looked at it, not used it though
[12:54] <xerosis> factorisation can take place and the old code will still work
[12:54] <paulheaney> ericthefish: same here looks like it could possibly be useful
[12:54] <paulheaney> xerosis: yeah it could do
[12:55] <xerosis> realistically, it'll take a year or so
[12:55] <ericthefish> I think we need to shelve this discussion for now tbh, however we decide I don't think it's acheivable in a realistic timescale for 4.0 
[12:55] <paulheaney> agreed, push it to 4.x
[12:56] <ericthefish> 4.what?
[12:56] <paulheaney> I don't think we should get hung up on post 4.0 releases at this time, just had a general bucket for them ie.e 4.x
[12:57] <ericthefish> ok
[12:57] <paulheaney> We can have another one of these gatherings nearer the time to process the 4.x bucket and assign 4.1 features
[12:57] <ericthefish> I'd like to plan more than one release ahead really
[12:58] <ericthefish> otherwise we have no way of organising all the billion items in Mantis
[12:58] <tomse> a thought just popped into my head..  regarding translations : we have today   <something %s of %s>    this can be difficult to translate on some languages...  perhaps something like <something %s.1 of %s.2> would make things easier on the translations
[13:00] <paulheaney> ericthefish: not really sure about planning too far in advance, perhaps 4.1 but no further
[13:00] <ericthefish> tomse: not sure what you mean
[13:00] <paulheaney> I think tomse is saying we don't really have any ordering on the variables, in some languages logging 1 incident of 10 may involve 10 being before 1
[13:01] <paulheaney> I'd imagine french is like that (but everyone knows what my french is like)
[13:01] <ericthefish> ah yeah, I'm not sure how we'd fix that though
[13:02] <ericthefish> tomse: can you log a bug for that one?
[13:02] <tomse> something like that yes :-)    not necesarily numbers, but also strings        1st of december   vs december 1st
[13:02] <tomse> on my way
[13:02] <ericthefish> yeah, and "Ivan's Incidents" as well probably
[13:03] <paulheaney> aye "Ivans incident" ;-)
[13:03] <ericthefish> ok so we're bumping db abstraction
[13:03] <ericthefish> we're bumping feedback
[13:03] <ericthefish> we're doing a small part of the WS API, enough to begin trying it out I guess
[13:04] <paulheaney> Yeah, WS I'm envisaging view incidents definitely and probably create and update
[13:04] <paulheaney> that covers the biggest requests for WS
[13:05] <ericthefish> ok we're going pretty slow here, but is that first agenda item fully discussed ?
[13:05] <paulheaney> Did we ever get a description of what "user preferences" are?
[13:05] <ericthefish>
[13:05] <ericthefish> paulheaney: that's me not being desciptive, it's moving the user config into a userconfig db table like the system config is in 'config'
[13:05] <paulheaney> Ahh OK, thats do able
[13:05] <ericthefish> means that we can support more than just the few var_ things we currently have
[13:06] <paulheaney> Ok, time scales?
[13:06] [Notice] -sitbot to #sit- New news from mantis: 0001085: Translations can be difficult in some languages because of the sequence of %s
[13:06] <ericthefish> 2secs, xerosis how much work have you done on triggers revamp as a percentage?
[13:07] <ericthefish> ok well while we're waiting for xerosis, timescales...
[13:08] <ericthefish> pretty obviously our current ones aren't gonna work, according to our roadmap page we're releasing 4.0 about three weeks ago
[13:08] <paulheaney> It was a good release I thought ;-)
[13:08] [Notice] -sitbot to #sit- New news from mediawiki: Roadmap
[13:08] <tomse> yeah
[13:09] <tomse> we had a nice party en belgium afterwards
[13:09] <ericthefish> hehehe
[13:09] <paulheaney> we did so we must have release
[13:09] <ericthefish> when we originally planned that we said there was about 6 months of work
[13:10] <ericthefish> does 6 months sound about reasonable to complete what is currently at (i edited the page)
[13:10] <paulheaney> yeah, I thnk we've dropped some work is is shorter though we're alot busier that we where when we did that 'planning'
[13:10] <ericthefish> shall I drop the roadmap for 3.80 completely?
[13:10] <xerosis> ericthefish: 15%?
[13:10] <paulheaney> Yeah kill 3.8
[13:10] <xerosis> 20%
[13:10] <paulheaney> 25%
[13:11] <ericthefish> wow no wonder we already got the release done, coding is so quick and easy ;)
[13:11] <paulheaney> ericthefish: I think to aim for 6 months for release for 4.0 isn't unrealistic
[13:11] <ericthefish> roadmap page updated yet again
[13:11] <tomse> hahahah
[13:12] <ericthefish> how about september as a release date?
[13:13] <paulheaney> shall we aim for September 1st?
[13:13] <ericthefish> Sep 4th is better coz it's easier (for me) to do release on saturdays
[13:13] <paulheaney> aim for final freeze 1st, release 4th?
[13:14] <ericthefish> xerosis: that ok for you?
[13:14] <tomse> seconded.. don't want release hangovers in a weekday
[13:14] <paulheaney> gives us three days to play with should we need them
[13:14] <xerosis> fine for me, summer off :)
[13:14] <ericthefish> hehe
[13:14] <xerosis> afk for a few mins
[13:14] <paulheaney> ericthefish: thats about the time we should have gone live with phase2 of work so we might have no spare time but xerosis has just volunteered to code it all for us ;-)
[13:15] <ericthefish> paulheaney: yeah! :-D  *grin*
[13:16] <ericthefish> Part of the reasons for wanting to do all this today is because I really want to set myself some goals and force myself to do more SiT coding
[13:16] <paulheaney> yeah I've looked at the list and not know what to do so done nothing
[13:16] <Nicdev007> ericthefish: yeah agreed .. seems we are not coding forwards but laterally ;-)
[13:16] <ericthefish> I've been really busy for the last 6 months or so and tired and stressed too.  But coding SiT! does relax me... so...
[13:17] <Nicdev007> we are spending a lot of time concentrating on the current versions and not doing enough for the future framework i think
[13:18] <Nicdev007> but without a clear plan it is like trodging in the mud
[13:18] <ericthefish> I think we tangled ourselves in a bit of a mess with our first attemps at Git as well
[13:18] <paulheaney> yeah we tried to complicate that move far too much
[13:18] <Nicdev007> yeah .. personally i like SVN but i am adapting to git ... slowly
[13:19] <paulheaney> SVNs like a nice pair of slippers, but there getting abit worn now, we need to move onto those new slippers we've got
[13:19] <paulheaney> after a bit they will feel like the old pair
[13:19] <Nicdev007> ericthefish: afa your earlier comment about your editor .. do yourself a favour and try netbeans ... searching is VERY powerful there
[13:19] <ericthefish> also on timescales... I reckon we should aim another 3.x release at the end of march
[13:20] <paulheaney> Nicdev007: you want eclipse,
[13:20] <Nicdev007> yeah ;-)
[13:20] <tomse> paulheaney: you want geany
[13:20] <paulheaney> yeah perhaps mark it as a LTS version?
[13:20] <Nicdev007> agreed
[13:20] <ericthefish> 3.60 LTS?
[13:20] <Nicdev007> end of march sounds good
[13:20] <paulheaney> tomse: that looks pretty good, but then I did use to use emacs
[13:21] <paulheaney> yeah 3.60 LTS
[13:21] <tomse> hehe
[13:21] <Nicdev007> OT netbeans has a git module now so you can push directly to the repo
[13:21] <paulheaney> I find eclipse useful as I develop PHP, Java and Python
[13:22] <Nicdev007> i think the idea for Netbeans was born from Eclipse
[13:23] <paulheaney> I used to like Netbeans is GUI developer it was by far the best though I couldn't get on with it for editing java it wanted to do it its way and not mine
[13:23] <Nicdev007> and the add-ons are quite usefull and numerous .. can do PHP and most others all in one ..
[13:23] <paulheaney> I find eclipse more flexible
[13:23] <ericthefish> ok everybody hit F5 on the wiki, hows the roadmap page looking now?
[13:23] <Nicdev007> ericthefish: yeah looks good
[13:24] <paulheaney> looks good
[13:24] <ericthefish> ok next agenda item
[13:24] <ericthefish> future oif 3.x, I think probably covered all that no
[13:24] <ericthefish> so now to discuss git migration
[13:24] <paulheaney> yeap covered, moving into git I think
[13:25] * Nicdev007 was waiting for this one ;-)
[13:25] <ericthefish> Nicdev007: we all discussed Git briefly at FOSDEM, I think we came to the conclusion that we'd made a mistake in the way we tried to use it
[13:25] <Nicdev007> i agree
[13:25] <paulheaney> Our basic idea was 4.x is GIT
[13:25] <ericthefish> we tried to sync our Git efforts with svn in both directions for two branches, trunk and 3.x
[13:25] * Nicdev007 wishes he was at FASDEM
[13:26] * Nicdev007 FOSDEM
[13:26] <paulheaney> and svn for 3.x
[13:26] <ericthefish> that was way too ambitious, especially since we're Git newbies
[13:26] <Nicdev007> yeah i think we went ahead of ourselves but now that we understand a bit better it may be better
[13:26] <tomse> Nicdev007: so did we :-)
[13:27] <ericthefish> yeah so as paulheaney is saying, we kinda planned  (while drinking beer as I recall) that we'd use Git for 4.x development and stick with svn for 3.x
[13:27] <Nicdev007> tomse: :D
[13:27] <paulheaney> Think it was some fine danish beer kindly donated by tomse
[13:27] <Nicdev007> sounds good and cautious
[13:27] <tomse> it was :-)  a shame they weren't all that cold
[13:27] * Nicdev007 salutes Tomse
[13:27] <tomse> hehe
[13:28] <ericthefish> tomse: they were most welcome, thanks so much for providing those \o/
[13:28] <Nicdev007> ericthefish: for the plugins (as they are expanding) how do we do in Mantis?
[13:28] <ericthefish> hang on Nicdev007, lets just get a proper git decision made
[13:29] <Nicdev007> ok sorry
[13:29] <ericthefish> are we all happy with that idea of Git for 4.x and Svn for 3.x ?
[13:29] <paulheaney> yes
[13:29] <Nicdev007> i agree with what was decided at Fosdem
[13:29] <ericthefish> who's gonna set up Git for 4.x?
[13:29] <ericthefish> is it me?  did I already volunteer?
[13:29] <paulheaney> On a similar note is github the place to be?
[13:29] <Nicdev007> i think xerosis is the best candidate :-)
[13:29] <ericthefish> I think we need xerosis back
[13:30] <ericthefish> ok lets discuss plugins while we wait for xerosis
[13:30] <Nicdev007> paulheaney: not sure about that ...
[13:30] <paulheaney> yeah hes done the most playing of all
[13:30] <Nicdev007> ;-)
[13:30] <ericthefish> I'd really like to code some server support for plugins, so that plugins can be installed remotely and updated etc.
[13:30] <paulheaney> phpmyadmin are migrating to git and staying with git on sf
[13:31] <ericthefish> don't know if anybody has seen the way wordpress does plugins?
[13:31] <Nicdev007> ericthefish: yeah i was thinking along the same lines ...
[13:31] <Nicdev007> yeah thats what brought the thought
[13:31] <paulheaney> I think it would be useful if sit could be updated online (though is quite abit of work, I'd imagine)
[13:31] <tomse> ericthefish: you
[13:31] <Nicdev007> to start with the polugins is an idea
[13:31] <tomse> 're welcome
[13:32] <ericthefish> Not sure how much work it is, I have done an auto-updater before but it was for a much smaller project
[13:32] <Nicdev007> for the plugins i think it should be not too difficult though ..
[13:32] <Nicdev007> for the entire sit i am not sure
[13:33] <tomse> atleast a small feature that checks for a new update of sit is available
[13:33] <ericthefish> yeah two seperate problems there
[13:34] <Nicdev007> ericthefish: yeah
[13:34] <ericthefish> checking for updates is easy
[13:34] <tomse> then a link to the download page, or the wiki for the new release.
[13:34] <Nicdev007> yeah
[13:34] <paulheaney> the one thing to bare in mind is that it doesn't block if the server cant get to the internet
[13:34] <tomse> or wait for a timeout
[13:35] <Nicdev007> yep
[13:35] <tomse>  = have in the config that autocheck can be turned off
[13:35] <ericthefish> yeah, we did already discuss checking for updates and we said it would be something you have to "click" to make it check, it won't just check automatically
[13:35] <paulheaney> ahh missed that one
[13:35] <Nicdev007> ericthefish: could put it in the scheduler
[13:36] <ericthefish> I very against SiT! checking for updates automatically by default, but I'm all for it being an option that can be turned on by an admin
[13:36] <Nicdev007> then you can choose to disable it
[13:36] <ericthefish> choose to enable it would be my vote
[13:36] <Nicdev007> or choose the schedule
[13:36] <tomse> playing with wordings, are you now ? hehe
[13:36] <Nicdev007> in the scheduler we already have the ability to disable it
[13:36] [Notice] -sitbot to #sit- New news from mantis: 0001087: Brush off Lee.todif's Windows Batch file command and add it in SVN || 0001086: Release 4.x Menu suggestions
[13:37] <tomse> well the schedule has the ability to enable/disable.. so there would be a good idea
[13:37] <ericthefish> I just think that if we make it connect to a remote server without asking the user first we're gonna alienate a lot of users
[13:37] <ericthefish> I'd be horrified if an app did that to me
[13:37] <Nicdev007> can put it in the scheduler but disabled by default
[13:38] <Nicdev007> and only admin can enable it ??
[13:38] <ericthefish> yeah
[13:38] <tomse> ericthefish: having it in the scheduler, but being disabled until the admin enables it... this would be a choice of his then
[13:38] <ericthefish> yeah happy with that idea
[13:38] <Nicdev007> cool
[13:38] <ericthefish> i'll add some bugs
[13:38] * tomse hates phpbb3 for not being able to disable the autocheck of new version :-/
[13:39] [Notice] -sitbot to #sit- New news from mediawiki: Roadmap
[13:39] <ericthefish> we already have bug 947
[13:39] [Notice] -sitbot to #sit- Bug 947 - Tomse - confirmed - open
[13:39] <Nicdev007> sorry ericthefish while xerosis is still out what does everyone think of the plugins in Mantis
[13:39] [Notice] -sitbot to #sit- New feature - Notice of update available -
[13:39] <tomse> it's hardcoded to check every time you log into the ACP
[13:39] <Nicdev007> ah yeah forgot about that bug
[13:40] <paulheaney> We do have a seperate product for project in mantis, though no sure how to do this going forward, we could end up with an unmanageable list
[13:40] <ericthefish> tomse: don't think that will get into 3.x branch now as you suggested since it's a new feature
[13:41] <ericthefish> might be best to just use the plugins category
[13:41] <Nicdev007> paulheaney: that was my worry ..
[13:41] <Nicdev007> ok for me ..
[13:41] <tomse> ericthefish: I don't complain :-)
[13:41] <ericthefish> the issue really is whether the plugins have their own release cycles or whether they follow sits own release cyle
[13:41] <ericthefish> *cycle
[13:42] <Nicdev007> i think it should follow their own ..
[13:42] <ericthefish> if plugins get released in between sit releases, having them in mantis and not as a seperate project is a problem
[13:42] <paulheaney> we could have a separate product for large plugins (ala project), though relatively small ones I'm uncertain on
[13:42] <Nicdev007> ericthefish: yeah you are right .. maybe we should follow sit
[13:43] <ericthefish> I'm not sure, I think some plugins would benefit from much faster release cycles
[13:43] <Nicdev007> but then we need to have a seperate entry in the roadmap
[13:43] <Nicdev007> or a seperate roadmap
[13:44] <ericthefish> unless we have a separete project in mantis called 'Plugins' and we lump them all together in there?
[13:44] <Nicdev007> ericthefish: is the idea not that when a plugin is mature enought o incorporate it into Sit if it fits the Sit planning??
[13:45] <tomse> Nicdev007: can I msg you ?
[13:45] <Nicdev007> ericthefish: yeah i think a seperate project in Mantis is maybe the better solution
[13:45] <ericthefish> Nicdev007: yeah if we feel it should yeah, sometimes as a plugin thats shipped by default and sometimes as core code
[13:45] <Nicdev007> sure
[13:45] <ericthefish> what do you think paulheaney?
[13:45] <Nicdev007> yeah i wote for a seperate project in Mantis
[13:45] <paulheaney> I'm unsure
[13:46] <ericthefish> are there any other alternatives to put on the table?
[13:46] <paulheaney> A seperate project sounds good for incubator style plugins and if/when they mature they get a separate product?
[13:46] <ericthefish> ok yeah I guess that sounds good
[13:46] <paulheaney> I've probably not made that clear have I
[13:47] <ericthefish> I think I understand
[13:47] <ericthefish> we may find eventually we still have too many projects in mantis, but we're nowhere near that stage yet
[13:47] <paulheaney> ahhh OK, reread it and used seperate product twice to mean different things ;-)
[13:47] <ericthefish> I think if plugins get rolled into to the sit distribution and shipped by default we should manage them in the sit project
[13:48] <paulheaney> to clarify have an incubator product for all developing plugins, when/if we're happy they fit our goals and are mature they move from incubator to their own product
[13:48] <ericthefish> if they're shipped seperately then they get managed in the "Plugins" project until they're mature when they can have their own mantis project if needed
[13:48] <paulheaney> Not sure about shipping plugins with core sit, it should be optionally installable by the admin
[13:48] <ericthefish> Incubator is a great word :-)
[13:48] <paulheaney> via the "sit market place"
[13:48] <Nicdev007> ericthefish: yeah
[13:49] <ericthefish> if we do have a sit market place then yeah we don't need to ship plugins, and no I don't think we should
[13:49] <paulheaney> Think apache and a few other projects tend to call the same thing incubator (probably where I got it from)
[13:49] <ericthefish> ok... so... few things needed to acheive all this
[13:50] <ericthefish> are we all in agreement first of all?
[13:50] <paulheaney> ericthefish: don't think we should what? ship them or have a "market place"
[13:50] <ericthefish> sorry don't think we should ship them in the sit package if we have a market place
[13:50] <ericthefish> market place replaces shipping plugins by default
[13:51] <Nicdev007> ericthefish: you have my vote
[13:51] <paulheaney> yeah if you look at eclipse they ship core eclipse and a few specific versions (c, php etc) and alll the plugins are available via the "eclipse marketplace"
[13:51] <ericthefish> although.. we need to think carefully about what we're going to do about the plugins we have shipped already... people will be using them, we can't suddenly make them dissappear
[13:52] <paulheaney> do we ship plugins?  Didn't think we did
[13:52] <ericthefish> well they're dashlets, but same thing really
[13:52] <paulheaney> ahh you meaning the dashlets, I'd still go with shipping the core dashlets
[13:53] <xerosis> sorry, back
[13:53] <paulheaney> Their kind of different (but the same)
[13:53] <tomse> the core dashlets are great to have.. also gives a sense of a more full product
[13:53] <ericthefish> I think if we do that then we should make a distinction between plugin dashlets and core dashlets
[13:53] <ericthefish> wb xerosis
[13:53] <tomse> wb
[13:53] <paulheaney> if we didn't ship and core dashlets the main page would be blank
[13:53] <ericthefish> very true ;)  not ideal
[13:54] <paulheaney> I've always seen dashlets and plugins as different things anyway
[13:54] <Nicdev007> ericthefish: yeah we have to distinguish the 2 types .. core plugins are really part of sit
[13:55] <ericthefish> ok
[13:55] <paulheaney> I think core plugins is an oxymoron really
[13:55] <Nicdev007> paulheaney: yeah but dashlet are really just fancy plugins :D
[13:55] <paulheaney> how can it be core and a plugin ?
[13:55] <ericthefish> core dashlets vs. plugins (and a subset of plugins is dashlet plugins)
[13:56] <paulheaney> yeah their really does need to be a distinction, dashlets can only do one thing where as a plugin can do just about anything
[13:56] <paulheaney> (well within sit that is)
[13:56] <ericthefish> yeah, ok, I'll try and improve on that
[13:57] <Nicdev007> paulheaney: yeah you are right ... i suppose the fact is that we have certain plugins/dashlets that have always been in SiT
[13:57] <ericthefish> I wanted to merge the two simply so there was a way to manage them, but can do that and still make it clear
[13:57] <ericthefish> at the moment we ship more dashlets than are enabled and you have to "install" them to make the enabled
[13:57] <ericthefish> I think that mechanism needs to dissappear for the core dashlets
[13:58] <paulheaney> Thats probably an oversite
[13:58] <ericthefish> the other dashlets need to become plugins
[13:58] <Nicdev007> ericthefish: yeah agreed
[13:58] <Nicdev007> yip thats is the point ;-)
[13:58] <ericthefish> cool, think we're all on the same page here
[13:58] <ericthefish> are done on plugins for now?
[13:59] <ericthefish> *are we
[13:59] <Nicdev007> i suppose the term plugin is a bit ambigious in itsself .; but you are right .. additional dashlets are plugins to SiT
[13:59] <Nicdev007> i agree
[13:59] <Nicdev007> back to git and xerosis
[13:59] <ericthefish> xerosis: we were begining to discuss Git but decided to wait for you since you're our resident expert
[14:00] <xerosis> let's not go overboard ;)
[14:01] <ericthefish> so to repeat we said at fosdem we'd do Svn for 3.x dev and Git for 4.x development
[14:01] <ericthefish> are you happy with that as well xerosis?
[14:01] <xerosis> that sounds sensible
[14:01] <ericthefish> oh yeah to clarify thats Git only for 4.x
[14:01] <paulheaney> As a minor asside where do our tools etc go?
[14:01] <ericthefish> no svn at all for 4.x
[14:01] <xerosis> hopefully 3.x shouldn't need too much work to make it difficult
[14:02] <ericthefish> erm.. dunno about tools etc
[14:02] <xerosis> paulheaney: an extra branch I would have suggested
[14:02] <ericthefish> maybe stay in svn until we're confident with git?
[14:02] <paulheaney> thinking branches/release-tools/vm/website/project and plugins?
[14:02] <tomse> tools go to the market place ?
[14:02] <paulheaney> xerosis: that was one of the options, I'd either say svn or a branch
[14:03] <paulheaney> tomse: the market place would be for releases not dev
[14:03] <xerosis> I think ideally, they would be in git once we get sorted as that will be active development
[14:03] <xerosis> but there's no rush I spose
[14:03] <ericthefish> can we come back to decision on those until after we've started using git properly?
[14:03] <paulheaney> but like ericthefish says SVNs probably best until we're comfortable with git?
[14:04] * ericthefish likes to be cautious
[14:04] <paulheaney> yeah don't want to bite too much of again
[14:04] <tomse> paulheaney: ahh like that
[14:04] <paulheaney> One thing I did raise earlier is, is github the right host?
[14:04] <tomse> thought you meant finished tools
[14:04] <xerosis> it's worked through it's twitter period IMO
[14:05] <xerosis> just upgraded the UI too, much nicer
[14:05] <paulheaney> phpmyadmin are in the process of switching to got and are staying with sf
[14:05] <ericthefish> The more time goes on the less I want to stick with sourceforge personally
[14:05] <paulheaney> and a couple of other projects have gone with
[14:06] <paulheaney> Yeah I'm no fan of sf and their git pages are somewhat basic compared with github
[14:06] <ericthefish> sourceforge have a habitt of dropping features with a day or so notice
[14:06] <xerosis> gitorious and github are roughly equal now
[14:07] [Notice] -sitbot to #sit- New news from mantis: 0000947: New feature - Notice of update available
[14:07] <xerosis> facebook and yahoo use it, so there's no issues there really
[14:07] <paulheaney> My concern about github is the disk quota/billing side
[14:08] <ericthefish> whats the deal?
[14:08] <xerosis> 300mb is a fair chunk?
[14:08] <paulheaney>
[14:08] <paulheaney> its a fair chunk but not massive, I know where not using much at the moment just don't want to be hampered by this latter
[14:09] <ericthefish> yeah we're only at single figures in megabytes, I think it'll last us a few decades
[14:09] <paulheaney> Amarok and Qt use gitorious
[14:10] <ericthefish> yeah gitorious is agpl too but hmm
[14:10] <paulheaney> was just wondering if we made heavy use of branches if we'd get anywhere near the limit,  probably not though don't want to rush into one host and realise we've hit a limit
[14:10] <ericthefish> I don't think I have an opinion on this, I don't know enough about the subject
[14:10] <tomse> don't forget that we still have the VM at SF (and should probably keep it there hence the billing)
[14:11] <xerosis> feature-wise they're pretty similar so if the limit is an issue then there's no reason we couldn't try gitorious
[14:11] <ericthefish> tomse: yeah I don't see us getting rid of sourceforge completely, not for a long time anyway
[14:11] <xerosis> very little time is spent using the website anyway
[14:12] <ericthefish> how easy/hard is it to switch between them?
[14:12] <ericthefish> can maintain history ?
[14:13] <xerosis> yeah
[14:13] <xerosis> just push the git repo
[14:13] <xerosis> they're just front-ends to git really
[14:13] <ericthefish> can I step back and let you guys decide?
[14:13] <Nicdev007> yeah i am out of this one as well ..
[14:14] <paulheaney> I've not really used gitorious much so its difficult to reach an informed decison
[14:14] <xerosis> well, at what point do we want to import the 4.0 code into git?
[14:14] <ericthefish> today I was hoping
[14:14] <paulheaney> Fairly soon
[14:14] <xerosis> okay well how about we try both for a coupla days?
[14:14] <ericthefish> smashing idea
[14:15] <xerosis> unless gitorious is really bad, I have no objections using it but we can try both out
[14:16] <paulheaney> yeah, one thing I do find with the little browsing of the gitorious site is its faster than github though obviously dont have a project on their
[14:16] <ericthefish> yeah lets give gitorious a try too, can't hurt really and then at least we'll know what we're talking about and can decide
[14:16] <paulheaney> github does have a T+C which says you can only have one free account so we're probably being abit naughty having sitracker as well
[14:17] <paulheaney> the next item then probably is what do we import? 3.x or trunk?
[14:17] <ericthefish> xerosis: can you help me later get our git into a clean state from the svn trunk?  I do believe it's easy but I'll need my hand held
[14:17] <ericthefish> trunk certainly, we already decided 3.x dev would stay as svn ??
[14:18] <xerosis> ericthefish: sure
[14:18] <paulheaney> sorry what would be the basis of 4?  I'd always assumed trunk but from xerosis email was unsure
[14:18] <xerosis> sorry, I just meant whatever svn was up to date
[14:18] <ericthefish> oh perhaps I should re-read that email, I read it on the train while having my ticket checked
[14:19] <paulheaney> Ahh, we've been keeping trunk in SVM upto date with all 3.x fixes
[14:19] <ericthefish> yes, more or less anyway
[14:19] <paulheaney> ericthefish: they check tickets at night on trains?
[14:19] <ericthefish> oh yes!
[14:19] <xerosis> so trunk -> git?
[14:19] <ericthefish> yup
[14:19] <paulheaney> They don't on the calder valley
[14:20] <paulheaney> seconded
[14:20] <xerosis> I would strongly recommend we just import fresh files from svn
[14:20] <xerosis> instead of trying to keep the history
[14:20] <ericthefish> yeah was thinking svn export into a git directory
[14:20] <xerosis> aye
[14:20] * ericthefish checks the agenda
[14:21] <ericthefish> wow look at that 2hours 20 minutes and we've discussed all our discussion items ;)
[14:21] <paulheaney> must say the git discussion was easier that I was expecting
[14:21] <Nicdev007> well done all
[14:21] <ericthefish> thanks everybody, i know it's a bit of a mamoth way to discuss things on irc sometimes
[14:22] <ericthefish> very useful though
[14:22] <ericthefish> just 10,000 bugs to triage now ;)
[14:22] <xerosis> lol
[14:22] <paulheaney> my fingers are tired now
[14:22] <tomse> my hands have blisters
[14:22] <ericthefish> I think I might break for some lunch, my stomache is rumbling
[14:22] <paulheaney> do we need to discuss how we develop with git? ie. branchs or is that for another time?
[14:23] <xerosis> perhaps a quick one?
[14:23] <xerosis> oh, ericthefish needs food
[14:23] <ericthefish> how quick?
[14:23] <paulheaney> think it would be worth it, no more than 10mins?
[14:23] <paulheaney> say finish 14:30 UTC?
[14:23] <ericthefish> 10 minutes I can handle
[14:23] <xerosis> I'll bash out my wee bit:
[14:24] <xerosis> we can setup mantis notification for commits to personal branches and sitracker branch
[14:24] <xerosis> so any commits going into a personal one will notify a bug, the latter will resolve it
[14:24] <paulheaney> my though was from your fork you create a branch per new feature, when your happy you merge with your fork and then push/pull into master?
[14:24] <xerosis> (OT: need to check gitorious can do postcommits too)
[14:25] <xerosis> that's the typical way of working, you can use more/less branches as you see fit really
[14:25] <paulheaney> Do we want any dev pushing straight to master or should we enforce some sort of peer review?  i.e. someone else pulls my code to master and I pull theirs?
[14:26] <xerosis> that's something we need to decide I guess
[14:26] <paulheaney> I think I'd like to get some sort of peer review going on, should improve the code (and our knowledge of  it)
[14:27] <paulheaney> but it does an some extra work (upfront, though should reduce work latter)
[14:27] <xerosis> I think for big features we can certainly use pull requests then
[14:27] <xerosis> again, not sure how gitorious handles those
[14:27] <ericthefish> we're not just coding features, need to remember that, the majority of our commits are bugfixes
[14:27] <xerosis> again, bugfixes in branches are good too
[14:28] <xerosis> "can you try this branch, I think it fixes bug 456"
[14:28] [Notice] -sitbot to #sit- Bug 456 - paulh - closed - fixed
[14:28] [Notice] -sitbot to #sit- Portal uses unchecked variables -
[14:28] <ericthefish> lol thanks sitbot
[14:28] <Nicdev007> lol
[14:28] <ericthefish> mm
[14:28] <xerosis> then you can anyone who needs that fix can merge it with their copy
[14:29] <ericthefish> I think a lot of the time it's gonna be overkill, the real bug 456 is a perfect example
[14:29] <xerosis> yeah no that's fine
[14:29] <xerosis> one line fixes there's no point
[14:29] <xerosis> I'm thinking things like fixing timezones etc
[14:30] <ericthefish> sure
[14:30] <xerosis> nice to pass that code around
[14:30] <ericthefish> yeah that'll actually be good
[14:30] <paulheaney> Though when you start alot of bugs you don't know if its a one liner or a bigger job
[14:30] <xerosis> true
[14:30] <xerosis> there's nothing stopping you using branches locally
[14:30] <ericthefish> yeah it's so easy to branch locally though
[14:30] <paulheaney> branches save you from screwing up the 'old' code
[14:30] <xerosis> ^^
[14:31] <ericthefish> the difference is whether you pass that branch to somebody else to try out, or whether you just merge it with your own 'trunk'
[14:32] <paulheaney> yeah one lines probably just merge, bigger changes need more review
[14:32] <ericthefish> in github we have the sitracker account for potential peer review
[14:33] <ericthefish> is that right?  and after what paul said is it allowed?
[14:33] <xerosis> I think gitorious allows a group store
[14:33] <xerosis>
[14:33] <xerosis> see team clones on the right
[14:34] <xerosis> from what I remember, you can have different groups access to different clones or something
[14:34] <xerosis> e.g. the KDE devs get a copy they can use and the QT devs merge that into theirs
[14:35] <ericthefish> that seems quite nice
[14:35] <xerosis> I swear those icons aren't GPL though ~_~
[14:35] <paulheaney> Yeah thats the kind of thing I was thinking of
[14:35] <ericthefish> they're famfam apparently
[14:35] <ericthefish> creative commons
[14:37] <ericthefish> what I don't want to happen is that develop A works on his own with feature X until it's stable and complete and then pushes it to somebody else for merging
[14:37] <ericthefish> i.e. code bombs
[14:37] <xerosis> I don't think it will, I think the websites encourage more observation of code
[14:37] <ericthefish> I don't know why i'm worried that will happen, but I am.  With SVN it seem that is less likely
[14:37] <xerosis> e.g. the dashboard type things show other peoples' commits
[14:38] <xerosis> 'ooh, Ivan is working on some escalations today, let's have a look..."
[14:38] <paulheaney> Though thats a side effect of the feature we're switching to got for, some devA can write coolfeature4 without breaking everyone else dev
[14:39] <paulheaney> Like xerosis says we can all see what each other is working on and run their code but keep our own code 'stable'
[14:39] <ericthefish> sure it does stop things breaking, but it also increases the risk of what are effectively forks
[14:39] <ericthefish> code developed seperately for 3 months is likely to be hard to merge back
[14:39] <paulheaney> I think the benefits our way this risk
[14:39] <ericthefish> and if we don't share our branches between us we'll be developing incompatible code thats never been tested together
[14:40] <xerosis> hopefully we don't not merge/release for 3 months
[14:40] <paulheaney> We should never get to a stage where we have such a large amount of unmerged work
[14:40] <ericthefish> if I add a feature that deletes users, and you add a feature that deletes users, it could be that we both try and get them merged
[14:41] <ericthefish> ending up with some code that deletes users twice (if there's no review before the merge)
[14:41] <xerosis> that's communication though
[14:41] <paulheaney> If we're both developing the same feature then something has gone massively wrong at a level any version control can't help with
[14:41] <xerosis> you're thinking of problems that svn doesn't solve either
[14:41] <ericthefish> hard to give an example that works, but we may be working on different features but the features clash
[14:41] <xerosis> same with svn too
[14:42] <ericthefish> maybe I add something to the menu, but you've rewritten the menu ?
[14:42] <xerosis> except the merge breaks after
[14:42] <xerosis> with git you know before it will apply
[14:42] <ericthefish> yeah the merge will fail, but that will mean I need to rewrite my code to add to the menu
[14:43] <paulheaney> We need to co-ordinate better, you'll know someones working on the menu from the branch so you liase with them
[14:43] <ericthefish> with our current way of working the new menu would be in svn for me to add to wouldn't it?
[14:43] <ericthefish> yeah spot on, it's the communication that is key to this working
[14:43] <xerosis> you can still see peoples' commits
[14:43] <paulheaney> not necessarily as we have a habit of developing offline wih svn anyway
[14:43] <xerosis> doesnt matter where it is really
[14:44] <ericthefish> yeah sure we can see commits, but who can keep up with reading all those commit messages?
[14:44] <ericthefish> maybe i'm worrying about nothing, just want to be clear it's all gonna work
[14:44] <ericthefish> like I see pauls commit "new menu system" how will I know when it's safe to merge that into my branch so I can add a menu item?
[14:45] <ericthefish> all tototally hypothetical this paulheaney btw not accusing you of breaking the menu ;)
[14:45] <paulheaney> I think the problem your explaining is one we've always suffered with rather than a new one with git
[14:45] <paulheaney> I wouldn't dare ;-)
[14:45] <ericthefish> :)
[14:45] <paulheaney> You'd know it was stable as I'd merge it with my fork of master rather than into my seperate branch
[14:45] <ericthefish> we've always commited to svn really even when our commit breaks svn
[14:45] <xerosis> slightly OT: gitorious is miles better
[14:46] <Nicdev007> lease don't break anything guys ;-) it's working very well up to today..
[14:46] <ericthefish> breaking things is so much easier than fixing things ;)
[14:46] <paulheaney> its alot quicker as well
[14:46] <Nicdev007> i known .. much more pleasure too ;)
[14:46] <paulheaney> I broke 100 things is much more productive than I fixed 2 things today
[14:47] <Nicdev007> lol
[14:47] <ericthefish> yeah just ask mr. barton ;)
[14:47] <paulheaney> :-)
[14:47] <paulheaney> ericthefish: that code I was looking at from our collegue, has 300 functions defined
[14:48] <paulheaney> in 5000 lines of code
[14:48] <ericthefish> just need to make a decision about peer review really?  are we gonna allow devs to commit to the release-branch (trunk) automatically or require a manual review step?
[14:48] <paulheaney> my vote is manual step
[14:48] <Nicdev007> i agree manual
[14:48] <xerosis> or have freezes?
[14:49] <ericthefish> explain plz?
[14:49] <xerosis> like debian/kde do, code needs to be approved after feature freeze or whatever
[14:49] <Nicdev007> as was said communication is key no matter which way ..
[14:49] <ericthefish> i see, hmm I think once frozen nothing should change, or thats cheating really isn't it?
[14:50] <Nicdev007> and yeah .. freezes like that could be good
[14:50] <xerosis> they have soft freezes though
[14:50] <paulheaney> so we push to staging, we then go though the list and approve to release ?
[14:50] <xerosis> like a week before or something
[14:50] <Nicdev007> yeah
[14:50] <xerosis> I like the idea of review BUT we don't have enough time ATM to develop let alone review it all
[14:50] <ericthefish> on our roadmap i put feature freezes in a month before release
[14:51] <ericthefish> thats how I'm thinking tbh, I do try and read every commit that happens but I don't think I'd have time to decide approve vs. deny
[14:52] <xerosis> I think a two-stage branch might be overkill too
[14:52] <ericthefish> i like the idea of an approval process, but I think practically there's not enough time in the day
[14:52] <paulheaney> I currently read the notes but not all the code, the likes of the github/gitorious make approving much easier/clearer
[14:52] <xerosis> I think a lot of the issues will resolve themselves once we start using it
[14:52] <paulheaney> I don't think its a big job if we go though the queue once every now and then
[14:53] <xerosis> either it will work or we'll come up with something else
[14:53] <xerosis> the problem is if we're not letting code in, no-one can get it easily
[14:53] <paulheaney> though like xerosis says we're hypothesising alot of something we know a little on
[14:53] <ericthefish> paulheaney: it needs to be regular or the trunk code wont be tested well enough, and it'll be trunk we're releasing from
[14:53] <paulheaney> yeah I think once a week is necessary
Personal tools