[19:04:06] <eean> is anyone running this meeting? I can't, I don't know what its about really, just heard about it on the grapevine. :)
[19:04:12] <Chani> see, the dashboard used to go away if a program was launched or a window activated. not any more...
[19:04:24] <Chani> eean: aseigo.
[19:04:24] <boud> same here...
[19:04:31] <boud> aseigo asked me to be around for the beginning
[19:04:42] <MTGap> yeah I've noticed the bug on my own system with alt-tab
[19:05:07] <notmart_> MTGap: to start read http://techbase.kde.org/Getting_Started/Build/KDE4
[19:05:09] <Chani> eean: geez, you expect the guy to actually show up for all these meetings? he's busy, you know!
[19:05:38] <eean> heh
[19:06:24] Join chinmaya has joined this channel ([email protected]).
[19:06:57] <mgraesslin> he probably thinks it was on the 22nd :-)
[19:07:09] <notmart_> meh
[19:07:15] <Chani> yeah, I bet he has no idea it's wednesday
[19:07:26] <Chani> which is, naturally, all our fault :)
[19:08:07] <mgraesslin> no it's all rrix's fault as the akonadi plasma interaction failed to notify him :-P
[19:08:29] <rrix> wha?
[19:08:41] <rrix> blame JohnFlux for that, not me :P
[19:08:45] <mgraesslin> we are just looking for a scapegoat
[19:09:00] * rrix wonders why he's still awake, been up for 28 hours now
[19:09:12] <Chani> rrix: because aaron called a meeting?
[19:09:15] <notmart_> details...
[19:09:34] <rrix> Chani: about what? i've been ignoring email..
[19:09:39] <Chani> rrix: git.
[19:09:41] <rrix> oh, it's right now
[19:09:53] * Chani wishes she had the willpower to ignore email
[19:09:57] * rrix rolls around
[19:10:05] <rrix> Chani: run kmail2, it's easier to ignore it :)
[19:10:17] <Chani> hehe
[19:10:26] <mgraesslin> no it only shows existing mails without subject
[19:10:30] <mgraesslin> new mails work
[19:11:01] <mgraesslin> though if I use it on N900 kwin has no bugs
[19:11:35] * rrix just kills akonadi when he doesn't want to deal with mail
[19:11:48] <Chani> I don't think I have an akonadi to kill any more :/
[19:11:49] <rrix> so, aaron's not here … for a meeting he planned?
[19:12:12] <Chani> you sound surprised.
[19:12:20] <boud> Okay...
[19:12:25] <rrix> No, this isn't my surprised voice :)
[19:12:33] <boud> I'll want to say what I'm here to say and then move away again, since I'm a bit busy
[19:12:54] <boud> KO intends to sponsor eean to create the git conversion rules for kdelibs and kdebase
[19:12:55] * rrix needs to sleep if there's not going to be any actual … guest aseigo appearances
[19:13:06] <Chani> boud: awesome.
[19:13:08] <mgraesslin> boud: awesome
[19:13:12] <rrix> w00t
[19:13:12] <eean> s/create/finish/ :)
[19:13:13] <insanity> eean: You did something wrong... Try s/you/me/ or tell me "help sed"
[19:13:31] <mgraesslin> eean: what are your plans for kdebase? one or three repos?
[19:13:32] <boud> now, there's one condition: it gets done and used -- no month of bikeshedding on splitting or not
[19:13:33] <notmart_> boud: grat :D
[19:13:38] <eean> mgraesslin: oh, no idea
[19:13:39] <Chani> boud: +1
[19:13:39] <notmart_> insanity: shut up :)
[19:13:44] <eean> I guess that was the point of this meeting
[19:13:48] <eean> oh well :)
[19:14:13] <boud> we have been advised to make 3 repos, and that's fine.
[19:14:13] <Chani> in terms of splitting, I say runtime/workspace/apps - I tend to svn up at that level anyways
[19:14:16] * mgraesslin wants three repos and has many reasons for it
[19:14:21] <boud> all we need is a final decision
[19:14:21] <eean> though you guys move stuff around so much between repos, 1 repo makes sense.
[19:14:41] <Chani> okay, that's several votes for 3
[19:14:48] <Chani> eean: we do?
[19:14:51] <eean> don't you?
[19:14:52] <eean> I dunno
[19:14:55] <eean> :)
[19:15:02] <mgraesslin> no in general not
[19:15:06] <eean> okay
[19:15:07] <eean> so scratch that then
[19:15:10] <Chani> I know folderview had to be moved for some dependency, long ago
[19:15:15] <eean> 3 repos makes sense
[19:15:16] <mgraesslin> and Oxygen
[19:15:17] * aseigo rolls in...
[19:15:24] <Chani> k. three repos. next item?
[19:15:30] <aseigo> sorry, ended up on a phone call that wouldn't FREAKING END
[19:15:39] <ruberg> aseigo: I have an multihead issue for you
[19:15:42] <eean> well, we've all been there
[19:16:10] <aseigo> ruberg: let's get back to that after this git thing.
[19:16:20] <notmart_> aseigo: tried to emulate static noises with the mouth?
[19:16:36] <notmart_> i can't hear you fzzzsc*cksss* *click*
[19:16:44] <aseigo> i even emulated snoring ;)
[19:16:50] <MoRpHeUz> eean: yep, aseigo and mgraesslin were really willing to have 3 separate repos and given the arguments it seems like a good idea
[19:16:53] <Chani> was that it for git?
[19:17:07] <MoRpHeUz> and +1 for what boud said: "let's get it done" :)
[19:17:16] * Chani just *loves* meetings with no agenda
[19:17:16] <mgraesslin> yes, please have git yesterday
[19:17:23] Quit chinmaya has left this server (Quit: Leaving).
[19:17:35] <aseigo> *finishes scrollback* folderview was always in apps/ as far as i remember
[19:17:43] <aseigo> what has moved is stuff from workspace into runtime
[19:17:46] <eean> mgraesslin: just give me a tachyon field
[19:18:15] <Chani> aseigo: the "oh crap olderview needs a konq dep" thing was a *long* time ago, maybe it was a playground->apps move
[19:18:15] <aseigo> this was when we decided to make plasma practical for use in random apps
[19:18:16] <eean> aseigo: will that keep happening? its just a hassle with git, though possible.
[19:18:37] Quit timo002_ has left this server (Ping timeout: 265 seconds).
[19:18:40] <aseigo> eean: i don't think so .. we have a good set of definitions for what goes where
[19:18:48] <aseigo> the last few things that hit runtime, for instance, went straight there
[19:18:59] <mgraesslin> eean: we recently had a kwin styles to kdeartwork transition
[19:19:07] <aseigo> developed in playground (in future that'd be a git branch, i hope :) and then moved into runtime
[19:19:22] <eean> okay well thats all fine
[19:19:27] <eean> alternatively you have a couple dozen git repos
[19:19:28] <eean> :)
[19:19:30] <aseigo> i can't say it won't ever happen again in the future, but things have calmed down a lot
[19:19:40] <mgraesslin> and in future I might like to move some kwin effects to kdeplasma-addons
[19:19:42] * Chani does wonder if that photo actiuvity template really belongs in desktop/shell/data/layouts (or whatever it was)
[19:19:43] <aseigo> hehe.. no, 3 is plenty :)
[19:19:46] Join ghostcube has joined this channel (~ghostcube@unaffiliated/ghostcube).
[19:20:56] <Chani> okay, so, is that it?
[19:21:02] <eean> timeline
[19:21:13] <aseigo> eean: let us know what you need as the process gets on its way, of course. i'm very happy we may have someone to do this work :)
[19:21:18] <eean> kdepim is moving dec 20
[19:21:33] <mgraesslin> that would be nice as it's with opening trunk
[19:21:42] <aseigo> timeline.. well, amazing would be to do it all at the "same time"... e.g. kdeplasma-addons is sched'd for dec 20 as well
[19:21:58] <aseigo> i don't know if that's a realistic time from for kdebase, given that it's a month away only
[19:22:00] <eean> ok, dec 20 can be a goal then :)
[19:22:08] <mgraesslin> awesome
[19:22:22] <aseigo> but in that general time frame would be great. if it happened in january, nobody would die either.
[19:22:22] <MoRpHeUz> great!
[19:22:35] * mgraesslin sees a kwin-mobile branch in the near distance :-)
[19:23:35] Join Kame2 has joined this channel ([email protected]).
[19:23:38] <aseigo> ok ... so .. on to workflow?
[19:23:51] <aseigo> or, who's chairing this thing in my absence? :)
[19:24:01] <aseigo> (don't stop just cause i finally got here ;)
[19:24:01] <eean> well there's this tool you might have heard of called reviewboard
[19:24:08] <eean> ;)
[19:24:08] <Chani> I tried but there was no agenda
[19:24:21] <Chani> and noboy's offered one, still :)
[19:24:23] <aseigo> reeee vuuuuuu baaaaah uuuuuurd ... strange word this. ;)
[19:24:57] * Chani dumps the cahir in aaron's hands and goes back to bed
[19:25:26] Quit afiestas has left this server (Remote host closed the connection).
[19:26:00] <aseigo> Chani: you suck :P
[19:26:04] <aseigo> ok.. workflow ..
[19:26:09] <Chani> no, you suck :P
[19:26:34] <aseigo> no, no, no .. YOU suck! (wow, flashbacks to 3rd grade.. neat..)
[19:26:40] <aseigo> *cough*
[19:26:40] <eean> relevant for workflow: email I wrote yesterday about where to store git branches http://mail.kde.org/pipermail/calligra-devel/2010-November/000029.html
[19:26:40] <mgraesslin> ah Plasma is a kindergarden
[19:26:54] <aseigo> mgraesslin: did we really have any doubts? ;)
[19:27:06] <mgraesslin> I was not 100 % sure
[19:27:10] <eean> basically git is awesome because it makes sharing easy
[19:27:16] * Chani isn't entirely sure why she's here, actually. I had nothing to say besides 'three repos, don't bikeshed'
[19:27:18] <eean> and everyone wants to get a '+' for sharing
[19:27:38] <Chani> somehow i keep getting tricked into these things... ;P
[19:27:53] <eean> so you should decide where to share your ongoing development branches now or else its a mess
[19:27:54] <aseigo> eean: interesting email ...
[19:28:20] <aseigo> yes, that's precisely what i wish to discusss
[19:28:51] <aseigo> as well as how we want to deal with release schedules now that we have a tool that makes it very easy to ignore them coplmetely
[19:29:08] <ivan|home> +1
[19:30:30] <aseigo> honestly, i'm pretty torn between keeping people's dev branches out of mainline (personal clones) and making it easy for those of us who do release management to track what people are working on
[19:30:32] Quit Zensursula has left this server (Read error: Connection reset by peer).
[19:30:35] * mgraesslin thinks number 1 would suite us best as we have so many projects inside kdebase
[19:31:22] <eean> you know if you do git branch -a and it returns a thousand branches
[19:31:26] <eean> its not really the end of the world
[19:31:55] <eean> you would obviously have to know the name of the branch you want, but thats it
[19:31:58] <MoRpHeUz> eean: I like options 1 and 2 of your email
[19:32:04] <eean> MoRpHeUz: :)
[19:32:26] Join ereslibre has joined this channel (~rafael@kde/ereslibre).
[19:32:32] <aseigo> having not use personal clones with git much ... how hard is it to switch between such clones?
[19:32:45] <eean> its not hard, you just need to know how to use git remote
[19:32:45] <mgraesslin> git add remote
[19:32:53] <MoRpHeUz> eean: when I clone a repo it doesn't mean that I'm getting all the branches, right? just master. otherwise (2) would be like hell :P
[19:33:17] <eean> MoRpHeUz: you get all teh branches, but unless you have artwork being changed, it wouldn't be heavy at all
[19:33:17] <MoRpHeUz> mgraesslin: I like (1) too :P
[19:33:36] * aseigo is leaning towards 1 as well
[19:33:37] Join task_struct has joined this channel ([email protected]).
[19:33:57] <aseigo> things we should have policies in place for are, imho:
[19:34:08] <aseigo> * bug and features -> how to branch those?
[19:34:18] <aseigo> * integration branches -> do we want those?
[19:34:23] Quit MTGap has left this server (Remote host closed the connection).
[19:34:26] <MoRpHeUz> eean: true for the "size of the repo". but it's also true that all kind of branches (tests that we may do in some branch, etc..) would stale there forever (knowing us the way I know - we never clean our stuff on review board for example hehe)
[19:34:37] <aseigo> MoRpHeUz: yep
[19:34:38] <eean> MoRpHeUz: well you could clean them up fairly easily :)
[19:34:41] <eean> and I suppose option 4) is maybe to have subteam repos instead of personal repos
[19:34:47] <aseigo> s,you,aseigo,
[19:34:47] <insanity> aseigo: You did something wrong... Try s/you/me/ or tell me "help sed"
[19:34:57] <MoRpHeUz> lol
[19:35:08] <aseigo> here's an idea i had the other day, and i'm not sure how batshit insane it is :)
[19:35:37] <aseigo> i think it would be really interesting to have a repo for bug fixes
[19:36:02] <aseigo> and each bug fix could go into a branch, named after the BR# (assuming it has one :)
[19:36:41] <ivan|home> aseigo: even for trivial fixes?
[19:36:48] <aseigo> the beauty of this would be that it would become very easy for downstreams to pick up the fixes (right now it's just all mashed together with feature commits, etc)
[19:37:16] <aseigo> and if we end up fixing-the-fix (not completely uncommon) then that work could also into the same branch, keeping everything together
[19:37:26] <mgraesslin> who not just having a branch and commit bugfixes to branch and merge to master?
[19:37:40] Join timo002_ has joined this channel ([email protected]).
[19:37:48] <MoRpHeUz> mgraesslin: I like this idea...
[19:37:49] <aseigo> mgraesslin: that's indeed another possibility, and perhaps a simpler one
[19:37:57] <aseigo> ivan|home: i dunno .. maybe...
[19:37:59] <mgraesslin> that's the Qt one, isn't it?
[19:38:05] <ivan|home> mgraesslin: +1
[19:38:11] <MoRpHeUz> mgraesslin: I think so...
[19:38:21] * mgraesslin just would like to see more bugfixes in the branches
[19:38:30] <notmart_> nice idea, and distros would go less insane to patch their packages...
[19:38:32] <mgraesslin> so it should be easy to do a bugfix
[19:38:34] <ivan|home> aseigo: the problem is (IMO) that sometimes we'd create a branch, and sometimes forget...
[19:38:35] <aseigo> i just find the idea of being able to do "git branch" and see all the bug fixes pretty fantastic
[19:38:50] <mgraesslin> what's the difference to git log $branchname?
[19:38:54] Quit giucam has left this server (Remote host closed the connection).
[19:39:09] <aseigo> mgraesslin: two major differences.
[19:39:36] <aseigo> a) bug fixes not always made in one atomic commit; often, but not always (and with git i think that will only grow)
[19:39:57] <aseigo> b) sometimes we end up having to fix-the-fix, and then the commits that all belong together for a given fix get mashed together
[19:40:31] <ivan|home> what about fix A depends on fix B
[19:40:35] <aseigo> either way, i'd like to see a bug fix branch .. quest is if we branch off that to do individual bug fixes or not
[19:40:35] <ivan|home> (or something more complicated)
[19:40:55] <aseigo> ivan|home: i don't think there's a good solution for that no matter what we do :)
[19:41:16] <mgraesslin> what about keeping a *good* changelog for distros?
[19:41:26] <ivan|home> well, if it is a bugfix branch - B will come after A
[19:41:38] <ivan|home> at least suggesting the possibility of existing deps
[19:41:40] <mgraesslin> our changelog currently allows to specify the revisions which belong to one fix
[19:42:13] <aseigo> yes, if we can keep to that discipline it would also work out
[19:42:49] <mgraesslin> let's say we move the changelog file to the repo and use a git hook to block pushes to branches not touching the changelog?
[19:42:54] <aseigo> stepping back a bit further ... i'd really like to have an "always releasable" mainline branch, a bug fix branch, a "for community consumption, but possibly unstable" devel branch and then everyone's sandboxes off of that
[19:43:12] <mgraesslin> +1 to all of that
[19:43:15] <ivan|home> +1 rolling KDE
[19:43:17] <ivan|home> :)
[19:43:20] <aseigo> mgraesslin: hm. for a specific branch, e.g. the bug fix branch, that could be
[19:43:56] <aseigo> "always releasable" is going to be really important as we work more with devices
[19:43:56] <Chani> "bug fix branch" - like, 4.5?
[19:44:05] <Chani> erf, the screen looks funny
[19:44:10] <aseigo> Chani: mostly
[19:44:27] * ivan|home wonders whether this is really a discussion about kdelibs/base and not plasma-addons :)
[19:44:37] <aseigo> ivan|home: yes, it is :P)
[19:44:39] <eean> yes :)
[19:44:52] <aseigo> ivan|home: but we'd use the same workflow there as well imho
[19:45:00] <boud> Okay, I think I know what I need to know -- see you all some other time, some other place
[19:45:03] Part boud has left this channel.
[19:45:07] * ivan|home wonders no more :)
[19:45:07] <aseigo> i'd really like to avoid vastly different workflows for different areas ... too hard to keep that straight
[19:45:14] <ivan|home> aseigo: yes, obv, but with much less problems
[19:45:51] Quit ereslibre has left this server (Remote host closed the connection).
[19:45:55] <mgraesslin> so we would need a "sid" branch
[19:46:03] <aseigo> so ... does it make sense to others as well that we have sth like:
[19:46:05] Join enderw99 has joined this channel ([email protected]).
[19:46:11] <ivan|home> mgraesslin: +1 :D
[19:46:14] <aseigo> * a mainline that could be pulled from to release at any moment
[19:46:18] Quit anselmolsm has left this server (Remote host closed the connection).
[19:46:29] <eean> (used for translations)
[19:46:35] <aseigo> * a branch where we do bugfixes only (and where all strictly bug fixes go ... features that end up fixing bugs don't go here)
[19:46:39] <aseigo> eean: yes
[19:46:48] <aseigo> * a mainline that could be pulled from to release at any moment, and which is used for translations and documentation
[19:47:21] <eean> shouldn't mainline have all the latest bugfixes at all times.
[19:47:29] <aseigo> * our feature playground, with ... personal repos, or branches? (i don't care either way... votes)
[19:47:31] <Chani> aseigo: I like that idea, and have liked it since you blogged about it years ago, but I've never actually seen it in practice
[19:47:42] <aseigo> eean: no ...
[19:48:00] <aseigo> eean: because some bugfixes take a while to settle down to being a full fix
[19:48:09] <eean> so its for WIP bugfixes
[19:48:15] <MoRpHeUz> aseigo: er, I would tend to agree with eean that the "master" branch (mainline) would be the "broken" one...
[19:48:23] <aseigo> eean: i think the "winter" branch should get merges from "bugs" on a regular basis though
[19:48:29] <eean> MoRpHeUz: that's not what I said :)
[19:48:40] <MoRpHeUz> ops, so I misunderstood you :P
[19:48:41] <MoRpHeUz> well
[19:48:48] <mgraesslin> so what would be the branch users (and devs) can test?
[19:49:02] <MoRpHeUz> sorry, but I've to go now :( whatever you guys decide I'll support it :D
[19:49:04] Quit bulldog98 has left this server (Read error: Operation timed out).
[19:49:07] <MoRpHeUz> see you
[19:49:27] <aseigo> so i don't think "winter" would have all bug fixes all the time, but all bug fixes should be merged into "winter" ... meaning there would be a small amount of drift between the two with bugfix often being slightly ahead of the curve
[19:49:30] <aseigo> MoRpHeUz: see ya :)
[19:49:35] <aseigo> MoRpHeUz: thanks for coming
[19:49:46] <MoRpHeUz> :D
[19:49:49] <MoRpHeUz> bye bye
[19:49:51] <Chani> would there only be one winter branch? or a new winter for each release?
[19:49:55] Quit MoRpHeUz has left this server (Read error: Connection reset by peer).
[19:49:59] <mgraesslin> I mean I have a real problem if users don't test rendering changes in Kwin on various hardware
[19:50:15] <aseigo> Chani: if we can get away with it: one branch imho
[19:50:30] Join bulldog98 has joined this channel ([email protected]).
[19:50:49] <ivan|home> stable / bugfixes / testing and development?
[19:50:54] <aseigo> mgraesslin: yeah, i think we would encourage our testers to work off of the bugs branch
[19:51:15] <eean> the testers want the latest gizmos though ;)
[19:51:15] <aseigo> mgraesslin: allowing you to attempt fixes there that need testing before dropping them into "winter"
[19:51:33] <mgraesslin> I'm more thinking about features than bugfixes
[19:51:36] <Chani> so.. if I have a one-liner bugfix for some old code, what steps do I go through?
[19:51:42] <aseigo> mgraesslin: ah, well that too :)
[19:52:10] <mgraesslin> if we have to tell users to checkout the mgraesslin branch kwin 4.7 will be more of a mess than 4.5 was
[19:52:23] <aseigo> Chani: commit it to bugfix branch, merge it into feature branch, and then the person who maintains the release branch would eventually merge it into there
[19:52:52] <Chani> we have a person maintaining the release branch? :)
[19:52:56] <aseigo> mgraesslin: i'd like to maintain our "one big branch full of features being landed" branch
[19:53:01] <aseigo> Chani: i think we'll have to
[19:53:16] <Chani> not it!
[19:53:34] <mgraesslin> aseigo: do you want to be the one person for complete kdebase? That's quite a bus factor ;-)
[19:53:35] <aseigo> Chani: not that others couldn't also help out, but having someone who is the fallback position, whose responsibility it is to make sure shit gets merged down ...
[19:53:49] <ivan|home> aseigo: so, bugs branch would be merged into stable and development?
[19:53:58] <aseigo> sure, it can be more than one person ... i do think we need to know who that person is though
[19:54:16] * Chani wonders if a bot couldn't do that, so long as all bugfixes pass through the bug branch...
[19:54:16] <aseigo> ivan|home: in this theoretical approach, yes
[19:54:25] <mgraesslin> I just don't want that we spent too much time on managing git branches
[19:54:29] <ivan|home> cool
[19:54:30] <aseigo> Chani: automation is possible; but only to a degree...
[19:54:49] <mgraesslin> kind of what debian does - automatically merge from sid to testing?
[19:54:51] <aseigo> if we want an always-releasable branch, then we need to be able to _not_ merge things
[19:54:56] <Chani> aseigo: oh, there is one annoying aspect to it branches: switch, switch back, and cmake wants to recompile eeverything because it "changed"
[19:55:06] <aseigo> from bugs to feature branch, that could be completely automated
[19:55:24] <aseigo> Chani: that sucks :)
[19:55:35] Nick releaselogger is now known as apachelogger.
[19:55:59] <aseigo> the big question for me in this is "how do we merge down into the release branch?
[19:56:08] <aseigo> we obviously can't take everything from the feature devel branch
[19:56:40] <Chani> aseigo: it might be better to automate the nagging instead of the merging. combine it with a simple web interface that can show what's not merged yet and let you mark things as ignore... damnit, I wish I could get credit for hte web course at my uni :P
[19:56:43] Quit teho has left this server (Remote host closed the connection).
[19:56:47] Quit enderw99 has left this server (Ping timeout: 240 seconds).
[19:56:50] <eean> winter == release branch?
[19:56:51] <aseigo> eean: yes
[19:57:08] <ivan|home> the merge down can go through reviewboard
[19:57:17] <aseigo> which is why i'd love to see feature branches, with merges from them into the main feature branch ... once we're happy with a given feature, then its branch can also be merged into the release branch
[19:57:29] <mat69> aseigo: just started reading your discussion on branches, what kind of features would move to release branch?
[19:57:32] <mgraesslin> we need a real testing branch, seriously
[19:57:41] <aseigo> mat69: releasable ones. ;)
[19:57:42] <mat69> I am asking because often features are far from finished once they enter trunk now
[19:57:43] <mgraesslin> that approach won't work with the driver mess we have
[19:57:44] <mat69> ok
[19:57:47] <Chani> aseigo: why would you merge them into the main feature branch at all then?
[19:57:52] <aseigo> mat69: yes, that's what i'd like to avoid
[19:58:05] <aseigo> mgraesslin: the feature devel branch could be the testing branch?
[19:58:25] <mat69> aseigo: so that would mean that everyone could create a feature_XY branch to work together with others and to merge that into the feature branch later on?
[19:58:35] <mgraesslin> and what's between completely broken and release branch?
[19:58:40] <aseigo> mat69: in theory .. i haven't quite convinced myself yet though :)
[19:58:43] <mat69> something like playground, just more powerful
[19:59:23] <mat69> only problem of such a problem is that it could end up with a heck of lot micro commits
[19:59:23] <aseigo> one challenge with that workflow is if i see something that needs fixing, do i go looking for the right feature branch or just plonk it right into devel branch?
[19:59:39] <aseigo> the former would be "more correct" in terms of being able to track things for merging into release
[19:59:42] <mat69> yeah, just locally I often forget to switch branches
[19:59:44] <Chani> yeah
[19:59:47] <aseigo> but it's a very high bar for participation
[19:59:48] <mat69> and then I end up rebasing
[20:00:03] <mat69> something that is not a good idea with public branches though ;)
[20:00:17] <eean> mat69: push -f won't be allowed, no worries :)
[20:00:27] <aseigo> mgraesslin: between completely broken and release would be the devel branch imho
[20:00:28] <Chani> the faeture starts in a branch, gets hacked into decent shape... then it goes into "summer" for wider testing, and that *will* uncover bugs...
[20:00:34] <eean> mat69: but there's some shell prompt hacking that can help you I think :)
[20:00:35] <aseigo> mgraesslin: completely broken should go into branches off of devel
[20:00:50] <aseigo> Chani: yep
[20:00:56] <Chani> and then there's integration testing
[20:00:59] <mat69> imo the problem is the more branches we have the more complicated it gets
[20:01:06] <Chani> and occasionally, features that depend on other features
[20:01:09] <aseigo> yep
[20:01:13] <ivan|home> please don't name them summer / winter ...
[20:01:27] * aseigo went to school with a Summer and a Winter
[20:01:57] <ivan|home> yes, but we'll end up with plasmoids,applets,widgets, etc. :)
[20:01:58] <eean> ivan|home: discrimination against equatorial branches?
[20:01:59] Nick apachelogger is now known as bloglogger.
[20:02:02] <aseigo> (random side trivia)
[20:02:06] <mat69> there are some nice concepts on git branch-structure on the net -- searching for the links now -- maybe one of those could fit
[20:02:14] <ivan|home> eean: ! yes :)
[20:02:24] <Chani> so, what that mainline branch is, is more of a staging branch, right? somewhere for taking a finished feature and kicking it into releasable shape
[20:02:34] <Chani> and making sure it plays nice with other new features
[20:02:39] <aseigo> Chani: yes, the devel branch would be for that
[20:02:53] <aseigo> the question is how we would merge stuff from that into the release branch
[20:03:11] <Chani> but if you're always bringing new features in, then it never fully settles, so the problem is how to determine what parts can be pushed to winter...
[20:03:28] <mat69> yeah picking commits by hand would suck
[20:03:30] <aseigo> right now we pause feature development (in theory), and then call everything in the devel branch "release" and work on making it actually worthy of that name
[20:03:34] <Chani> unless you have freezes
[20:03:36] <eean> yea with the typical method (like what cmake does I think) you do all the work in the feature branch, go through a review process, and then land a finished product direct into mainline
[20:03:36] <aseigo> i dn't really like that way of working
[20:03:42] <Chani> right
[20:04:03] <aseigo> eean: i just don't see that working for us, tbh.
[20:04:05] <Chani> so if not that, then what... hmm
[20:04:12] <eean> yes, its different with volunteers
[20:04:15] <aseigo> features are not so cleanly divided
[20:04:18] <aseigo> even without volunteers
[20:04:53] <aseigo> a feature i work on for plasma PanelView may end up screwing up, say, the ControllerWindow (where activities, add widgets, panel management gets shown)
[20:05:13] <aseigo> with something like cmake, there going to be very little cross-talk between features
[20:05:19] <Chani> and then whta if someone was working on something else for controllerwindow at the same time? :)
[20:05:22] * ivan|home bbl
[20:05:28] <Chani> boom.
[20:05:29] <aseigo> Chani: we suffer that right now, nothing new :)
[20:05:42] <Chani> aseigo: yeah, but we have freezes to sort it out in :)
[20:05:46] <mgraesslin> communication problems cannot be solved with git
[20:06:01] <mgraesslin> what about freezing the winter branch to settle down
[20:06:05] <mat69> maybe something like http://nvie.com/posts/a-successful-git-branching-model/
[20:06:07] <Chani> if we twist that, and have branches for sorting things out in instead... hrm.
[20:06:12] <mgraesslin> with very short cycles: e.g. two weeks
[20:06:19] Quit jason27 has left this server (Ping timeout: 252 seconds).
[20:06:33] <mgraesslin> or devel branch instead of winter
[20:06:34] <aseigo> mgraesslin: you mean freezing the devel branch?
[20:06:39] <mgraesslin> yes
[20:06:40] <notmart_> isn't there anything fpr git to tell like show all branches on the server that touch a given file after a given date?
[20:06:57] <eean> not that I know of
[20:07:09] <mgraesslin> aseigo: something like the merge window Linus does
[20:07:20] <Chani> the problem is that while you're in one barnch sorting out one thing, someone in another branch may be unintentionally breaking it. what freezes fgive us is a signle poiht of synchronization
[20:07:20] <mgraesslin> only without Linus
[20:07:33] <Chani> notmart_: there must be
[20:07:44] <Chani> notmart_: but I don't remember how
[20:08:58] <mat69> Chani: I am not sure this would be a problem, wouldn't there be a merge conflict then?
[20:09:21] <Chani> mat69: not necessarily. omeone could change a dbus interface I use
[20:09:21] <aseigo> Chani: i'd love to be able to replace time based freezes as synch tool with branch based mechanics for synch
[20:09:53] <mat69> aseigo: that is what the link I poste above describes to a degree
[20:10:03] <aseigo> i don't know if it is possible (why we're having this discussion) but every time we end up back to "time based freezes" i feel like we're maybe allowing ourselves an easy answer
[20:10:27] <eean> maybe using git for some months will help you out
[20:10:34] Join enderw99 has joined this channel ([email protected]).
[20:10:57] <eean> trivial branching will change how you work for sure
[20:10:58] <aseigo> mat69: yes, it looks sensible ... save for one thing ..
[20:11:12] <aseigo> mat69: it assumes that the devel branch is in a releasable state at random times
[20:11:24] <aseigo> in case we haven't noticed, we don't release when its ready anymore
[20:11:28] <mat69> in any case the described "git merge --no-ff" should help to have a clearer system in most cases
[20:11:31] <aseigo> we release when the calendar says "it's been 6 months"
[20:12:11] <aseigo> i'd _like_ for that artificial time blocking to become a release engineering artifact
[20:12:23] <aseigo> i'd _like_ for us to have a 2-3 week feature cycle
[20:12:24] <ScottK> But with a sensible approach to developing in branches and merging when ready, trunk can be ~releasable all the time.
[20:12:37] * mgraesslin doubts that
[20:12:44] <Chani> aseigo: okay, so, here's a problem to try and solve: it's a week before release. Amy and Bob both have features that are ready for mainline. Carl has a feature that's close to ready, but after he gets it into mainline he's hit by a bus, and it's not ready for release. how do we get release to contain Amy and Bob's features but not Carl's?
[20:13:11] <aseigo> where people develop big things in branches, we commit small things into devel, and we work on the integration of it all in devel and at some random point say "hey, i like this state of things" and note that down for merge into release
[20:13:14] <eean> (that fuckin' bus)
[20:13:21] <mat69> Chani: git revert?
[20:13:51] <aseigo> and when release is open for merging (e.g. not during the 2 months that release dudes are making us not work on features ;) then we merge the last "good" point we had
[20:13:56] <mat69> and once it is finally done -- by someone else -- pushing again
[20:14:12] Quit ruberg has left this server (Ping timeout: 265 seconds).
[20:14:16] <aseigo> Chani: big things need to go into feature branches imho
[20:14:24] <aseigo> devel is an integration branch ...
[20:14:32] <Chani> mat69: let's say that fixes were added to mainline for all three features, and Carl's feature had some funny interactions with Amy's that needed solving. how do we pick out what to revert?
[20:14:38] <aseigo> small things (e.g. something you can finish in 1-4 hours) can go straight into it
[20:14:46] <aseigo> anything multi-day goes into a branch
[20:14:48] <mat69> Chani: by hand, nasty but yeah
[20:15:00] <aseigo> Chani: we don't.
[20:15:03] <mat69> Chani: if micro commits were used it should not be that nasty though
[20:15:11] <aseigo> we don't worry about reverting
[20:15:14] <mgraesslin> you know for those working as volunteers 1-4 hours means 1 to 7 days :-p
[20:15:17] <Chani> right, reverting ftl
[20:15:21] <aseigo> we just don't push it down to release branch in that state
[20:15:26] <Chani> as we haven't actually merged to release anyways
[20:15:29] <Chani> yes.
[20:15:29] <aseigo> right
[20:15:29] <mat69> I think we should do worry for reverting
[20:15:36] <mat69> somethings things not anticipated happen
[20:15:43] <Chani> aseigo: okay, so what *do* we push to release?
[20:15:45] <mat69> in any case I don't think that reverting will be such a big deal
[20:15:59] <aseigo> mgraesslin: wall clock time, not devel effort time :)
[20:16:03] <mat69> Chani: imo the same thing can happen right now as well
[20:16:08] <Chani> mat69: IT'S NOT ABOUT REVERTING
[20:16:11] <mat69> trunk is frozen a feature in there is not complete
[20:16:12] <Chani> oops, soory
[20:16:26] * Chani ought to nerf that key, second slip in two days...
[20:16:33] <mat69> :P
[20:16:35] <mat69> :D
[20:16:35] <aseigo> Chani: we push devel branch down when we're happy with it ...
[20:16:37] <sreich> yeah, mine doesn't do anything anymore
[20:16:43] <sreich> I like it that way :)
[20:16:45] <Chani> mat69: we;re trying to figure out how to do it without freezing
[20:17:05] <mat69> Chani: yeah I know, but I mean the problem you outlined above exists already and is not that bad
[20:17:30] <mat69> and the devel branch is kinda a "freeze"
[20:17:30] <Chani> the problem with not freezing, though, is: what if we're *almost* at a happy point and then someone merges a new feature?
[20:17:35] <mgraesslin> aseigo: how do you get it in the happy state if new features are added all the time?
[20:17:51] <Chani> mgraesslin: yeah that
[20:17:52] <mat69> Chani: no problem with the devel branch aaron outlined above
[20:18:33] <mat69> imo this devel branch would act as kind of buffer
[20:18:38] <aseigo> mgraesslin: small time boxed cycles, with big features staying out in feature branches
[20:18:57] <mgraesslin> ok that is what I meant above with freezing the devel branch
[20:19:07] <aseigo> the merge window thing is a good idea, indeed
[20:19:13] <aseigo> "this week, feature branches can be merged"
[20:19:17] <Chani> oh, another thing that would ease merging pain: merge devel into your branch before merging your branch into devel.
[20:19:25] <mgraesslin> though if I have a change as I have in kwin right now some few weeks are not enough
[20:19:41] <mat69> Chani: why should I do that?
[20:19:42] <Chani> that way any merge conflicts can be handled in-branch. (note: I'm no git expert)
[20:19:46] <aseigo> "the next two weeks we have only fixes to merged features and features that are small enough to not require branches"
[20:19:54] <eean> just being able to have feature branches means that any 'feature freeze' doesn't mean you have to stop working on features. git actually makes alternate release scheduling systems easier and less necessary :)
[20:20:11] <eean> anyways, I'm off so happy thanksgiving to any of my fellow citizens. I'll be needing lots of help from you all in writing the rules, you guys know the history of kdebase the best which is needed when verifying the test conversions.
[20:20:18] <Chani> aseigo: okay, so we still end up with freezes, but much smaller freezes :)
[20:20:18] <aseigo> eean: happy thanksgiving dude
[20:20:25] <eean> so expect to be bugged by me
[20:20:27] <aseigo> eean: thanks for your attendance, input and attention
[20:20:44] * Chani blinks
[20:20:44] <aseigo> Chani: yes, and freezes that are less like freezes and more like shifts in attention
[20:20:53] <mat69> imo the only problem of the freezes now is that you don't have a place to publish your stuff to work togehter on it with others
[20:20:53] <Chani> I still can;t get used to american thanksgiving :)
[20:20:59] <mat69> and playground is not that great for this
[20:21:04] <Chani> aseigo: yeah. just a little frost ;)
[20:21:07] <aseigo> mat69: true
[20:21:09] <mat69> and git would solve that for me
[20:21:11] <Chani> it was snowing here today :)
[20:21:43] <aseigo> ok.. we've been at this for a while .. my suggestion is to table the discussion, let's all think about it for a week or so, and come back with some more fully formed ideas?
[20:21:50] <Chani> +1
[20:22:08] <Chani> although I think mini-freezes is the way to go
[20:22:10] <mgraesslin> one thing to keep in mind: what can be used by users as beta releases to test
[20:22:25] <mat69> tagged devel branch?
[20:22:42] <Chani> mgraesslin: trunk users are my beta testers ;)
[20:22:42] <mat69> hmmm
[20:22:48] <mgraesslin> if we have short cycles we might demand too much from our users
[20:22:57] <mgraesslin> Chani: how many trunk users do you have?
[20:23:08] <mgraesslin> and what is trunk in a git world?
[20:23:19] <mat69> yeah, I mostly get the reports afterwards, when I can't fix them anymore :(
[20:23:28] <mgraesslin> that's the problem
[20:23:39] <notmart_> if master will be the stable-ish one even less betatsters, that's true
[20:23:42] <mat69> and personally I don't use trunk for work myself, only for developing
[20:23:49] * mgraesslin thinks with a failed release still in the mind
[20:23:56] <Chani> merp
[20:24:18] <Chani> seriously though, I got a shitload of bug reports during our last freeze
[20:24:30] <Chani> the beta testers pick up the beta releases
[20:24:51] <mgraesslin> and we got a shitload of bug reports and did not notice we have a real problem
[20:24:55] <Chani> but there aren't that many problems that I don't know about myself
[20:25:00] <mgraesslin> with less testers it get's worse
[20:25:20] * mgraesslin had no idea about the driver problems we had in 4.5
[20:25:26] <Chani> :/
[20:25:26] <aseigo> it would be really awesome if we could use the devel branch for our testers
[20:25:32] <Chani> aseigo: +1
[20:25:38] <Chani> aseigo: but we already are
[20:25:48] <aseigo> yes, but in the git world :)
[20:25:49] <Chani> I'm an involuntary tester for dolphin, konq, etc
[20:25:55] <aseigo> well, not just us though
[20:25:55] <Chani> and used to be for pim until it got too much
[20:26:06] <aseigo> for our beta-release-users as wel
[20:26:17] <mgraesslin> our beta testers need packages
[20:26:20] <Chani> if it was stable enough for wider testing, it would also make me pull my hair out less ;)
[20:26:35] <mgraesslin> ScottK, bloglogger: how often could you provide packages in a PPA?
[20:26:38] <mat69> that is why I don't use trunk anymore ;)
[20:26:39] <Chani> mgraesslin: so we package up devel once in a while then? :)
[20:26:54] <Chani> mgraesslin: I know opensuse does trunk packages
[20:27:08] <mat69> I don't want to end up as bald head :D
[20:27:08] <ScottK> mgraesslin: We try to package every release. Working on beta1 packages now.
[20:27:37] <mgraesslin> Chani: yeah but it would need long freezes again to get feedback
[20:27:44] <Chani> if I could clone myself, I'd go download kde-obs-generator and grok it and make it into a magical automation wonderland ;)
[20:27:59] <Chani> mgraesslin: why?
[20:28:12] <aseigo> ScottK: what changes for you guys between releases for kdebase? is it mostly just "adding in the new dataengines and plasmoids" or is there more significant work?
[20:28:25] <mgraesslin> and I think that most users don't want trunk (bah broken) but take beta (at least devs think it's somewhat stable)
[20:28:27] <aseigo> ervin: ping
[20:28:38] <ivan|home> It looks to me like we're reinventing a spinning wheel - debian's branches look like what we're discussing here (without long release periods obviously)
[20:28:41] <ervin> aseigo: pongish
[20:28:45] <Chani> mgraesslin: yeah... what we're offering here is perpetual betas
[20:28:46] <mgraesslin> Chani: if we merged the broken feature to winter it's too late
[20:28:53] <aseigo> mgraesslin: i'd like the devel branch to become "at least devs think it's somewhat stable"
[20:28:59] <aseigo> mgraesslin: with feature branches being "bah broken"
[20:29:09] <Chani> aseigo: +1
[20:29:11] <aseigo> ervin: can you quickly describe how "boxed" development wrks?
[20:29:18] <aseigo> i mean, right now, that's kind of what we do...
[20:29:25] <mgraesslin> aseigo: so how do I test my new OpenGL rendering branch with hundreds of systems?
[20:29:26] <bloglogger> mgraesslin: somewhat daily really
[20:29:38] <aseigo> the little features and bugfixes people commit all the time are often pretty close to releasable on landing
[20:29:43] <ScottK> aseigo: There's also looking at how we're dividing the various bits into different binary packages. For 4.4/4.5 we refactored the packaging a fair amount to account for multiple possible plasma shells.
[20:29:47] <bloglogger> (which is going to happen soonish anyway with kde trunk builds for kubuntu coming up)
[20:29:51] <ervin> aseigo: not sure I understand the question, ENOCONTEXT
[20:29:55] <aseigo> it's the big features and some specific cases of inerplay
[20:30:16] <ScottK> This cycle we're going to be looking to see if we can get more fine grained to reduce the weight of what's pulled in for Mobile.
[20:30:21] <aseigo> ervin: ah, time boxed devel ... e.g. if you were to impose a, say, 3 week dev cycle on us poor unwashed plasma masses, what would it look like?
[20:30:41] <aseigo> ScottK: ok.. good info to know.. thanks.
[20:30:53] <mat69> mgraesslin: imo the only way to do that is to provide a link to clone your feature branch
[20:31:12] <mat69> in context with the talk above to have only "finished" features in devel
[20:31:14] <mgraesslin> mat69: history showed it doesn't work (not enough feedback on 4.5)
[20:31:30] <aseigo> mgraesslin: for those kinds of things, i'm not sure there's a better answer than "get it to where you are happy with it or as close as you can pull it in that direction, merge it into devel branch for wider testing"
[20:31:38] <mgraesslin> mat69: the feature is done, but might break on Intel or Ati or Intel with Kernel x.y.z
[20:31:53] <aseigo> mgraesslin: the real trick is going to be "how do we trick people who wait for betas to test the devel branch"
[20:32:19] <mat69> mgraesslin: the same problem exists -- to a lesser degree -- with other deps like dbus
[20:32:26] <mat69> and that sucks too
[20:32:30] <mat69> I think most bug reports only show up after release
[20:32:44] <aseigo> mgraesslin: part of that is us keeping the devel branch testable (which we almost nearly manage to do with svn!), part of that is making it available to people (so the packaging question is very relevant indeed :)
[20:32:45] <mat69> in those areas, not sure if a certain way of branches will help changing that
[20:33:28] <mgraesslin> yeah, I think KWin svn trunk was never broken since I'm involved (thanks to many people complaining immediatelly)
[20:33:47] <mat69> imo everything that is not a feature branch should alwasy compile
[20:33:47] <mgraesslin> mat69: probably not
[20:33:59] Quit BajK_ has left this server (Read error: Connection reset by peer).
[20:34:13] <ervin> aseigo: aaaah ok
[20:34:22] <mgraesslin> I meant broken in the sense of broken software, not compiling
[20:34:41] <ervin> aseigo: it'd look kanban :)
[20:35:07] Join jason27 has joined this channel ([email protected]).
[20:35:13] <ervin> aseigo: more seriously, depends what you're after, only "how do we develop?" or also "how do we plan what we do?"
[20:35:14] <mat69> well that is really on the maintainer then, to make sure that the parts they maintain aren't broken
[20:35:55] * mgraesslin remembers a time when systray was completly broken in trunk :-D
[20:36:27] <mat69> feature branches should help there ;)
[20:36:48] <mgraesslin> hopefully
[20:37:27] <mgraesslin> though we are much better in that regard
[20:37:44] <mgraesslin> I switched earlier to 4.6 than in other cycles and it's really smooth
[20:38:49] <aseigo> ervin: how do we develop ... though i suppose the two are linked
[20:39:06] <ervin> aseigo: they always are :)
[20:39:31] <ervin> aseigo: then I'd say on such short cycles like that: keep it small
[20:39:45] <ervin> every single feature in a small temporary branch
[20:39:56] <ervin> when ready for inclusion, merge dans stabilise
[20:40:01] <ervin> s/dans/and/
[20:40:01] <insanity> ervin meant: "when ready for inclusion, merge and stabilise"
[20:40:57] <ervin> on a three week cycle you likely have one or two persons doing at least 50% of merge
[20:40:58] * aseigo read that as "merge, dance, stabilize" which seemed completely sensible.
[20:41:02] <aseigo> "and now we dance..."
[20:41:06] <aseigo> "and now we stabilize..."
[20:41:14] <mat69> :D
[20:41:41] <aseigo> i mean, whenever i get a nice feature in, i feel like (and often actaully do some) dancing
[20:42:05] <ervin> merge window closes after the first 2 or 2.5 weeks
[20:42:05] <ervin> needs to be decided on experience that one
[20:42:24] <aseigo> hm.. ok..
[20:42:34] <aseigo> and people would need a way to indicate what is up for merging
[20:42:44] * mgraesslin likes dancing around the desktop, too
[20:42:46] <ervin> so that you get a chance of the thing being tried for a few days all integrated without outside disturbance
[20:42:46] <ervin> yep
[20:42:56] <ervin> and that's where the "how do we plan stuff" kicks in :)
[20:43:22] Join rbelem has joined this channel (~rodrigo@pdpc/supporter/professional/rbelem).
[20:43:25] <ervin> and I'd tailor a specific kanban for that
[20:44:00] <ervin> problem being that the bottleneck (mergers) is almost not solvable
[20:44:16] Quit apol has left this server (Ping timeout: 245 seconds).
[20:44:20] Quit rrix has left this server (Excess Flood).
[20:44:23] <mgraesslin> and it would be a pity to waste good developers to become mergers
[20:44:35] <Chani> Nightrose: ping. melange?
[20:44:52] <ervin> mgraesslin: note that I never said 100% of their time ;)
[20:45:03] <mgraesslin> even 50 % is too much IMHO
[20:45:12] <ervin> also note that they're responsible for the quality level
[20:45:31] Quit ShadowBelmolve has left this server (Ping timeout: 240 seconds).
[20:45:35] <ervin> our current level can't maintain high quality output if we raise the frequency
[20:45:35] Join ShadowBelmolve_ has joined this channel ([email protected]).
[20:45:40] <ervin> s/level/model/
[20:45:40] <insanity> ervin meant: "our current model can't maintain high quality output if we raise the frequency"
[20:46:39] <mgraesslin> course not, the question is if we cannot do the merges in an at least semi-automatic way
[20:47:23] <mgraesslin> or we get a "scalibility of Aaron" problem
[20:48:24] Join abinader has joined this channel ([email protected]).
[20:50:36] <aseigo> ervin: thanks... good input
[20:51:00] <aseigo> ok, i will think about all this (and hopefully you all will too) and lets take it up again in the coming week
[20:51:07] * aseigo rolls out ....
[20:51:33] Join mikeplus64 has joined this channel ([email protected]).
[20:54:02] <ervin> mgraesslin: you can't make it better than it already is using something like git (for the merges)
[20:54:21] <ervin> it's quite clever already but it can't get all the way up to the semantic level
[20:54:35] <ervin> aseigo: ah also: continuous integration
[20:54:52] <ervin> that would actually relieve a bit of the mergers pain
[20:55:30] Quit ShadowBelmolve_ has left this server (Quit: No Ping reply in 180 seconds.).
[20:56:08] Nick einar77_work is now known as einar77.
[20:56:15] Join Typosu has joined this channel ([email protected]).
[20:57:18] Join ruberg has joined this channel ([email protected]).
[20:58:01] Quit rdieter has left this server (Ping timeout: 245 seconds).
[20:59:05] Quit enderw99 has left this server (Ping timeout: 250 seconds).
[21:00:05] Join enderw99 has joined this channel ([email protected]).
[21:00:17] Join rrix has joined this channel (~rrix@fedora/PhrkOnLsh).
[21:00:57] Quit Killsudo has left this server (Remote host closed the connection).
[21:01:00] Quit rrix has left this server (Excess Flood).
[21:01:37] Join giucam has joined this channel ([email protected]).
[21:01:56] <mat69> ervin: imo the "merger" should ignore anything that does not merge
[21:01:57] Join Killsudo has joined this channel ([email protected]).
[21:02:20] <ervin> mat69: define "does not merge"? :)
[21:02:28] <mat69> merge conflicts
[21:02:33] Join ShadowBelmolve has joined this channel ([email protected]).
[21:02:41] <ervin> yeah sure, that's the trivial case
[21:02:46] <ervin> I don't worry about that one
[21:03:37] Join rrix has joined this channel (~rrix@fedora/PhrkOnLsh).
[21:03:40] <ervin> meeting quality criteria and having something that works, is where the workload is
[21:05:27] <mat69> wasn't devel branch meant to handle that?
