20110213 GitWorkflowLog

Hint: You might find this page more readable if you edit and preview it to use style="white-space:pre-wrap".

The thin style used on this site makes it not a big improvement...

[20:00:18] <aseigo>	ok.. it's 20:00 UTC. let's begin...
[20:00:22] <eean>	yep
[20:00:37] <aseigo>	who all is here for the meeting? please "raise your hand" / say something so i can record you as being present :)
[20:00:48] <argonel>	hi
[20:00:51] <aseigo>	note that the agenda is here: http://community.kde.org/20110213_GitWorkflowAgenda
[20:01:02] 	 * toma <-
[20:01:13] 	 * Sho_ raises tentacle
[20:01:33] 	 * annma is more a spectator than an intervenant
[20:01:33] <khindenburg>	hello
[20:01:34] 	 * tampakrap
[20:01:36] <giucam>	hey there :)
[20:01:45] <allen_laptop>	cue intro music
[20:02:00] <aseigo>	oh, and can someone log this for later publication? (technically, i guess i could: konvi is logging it for me.. but i never pass up an opportunity to delegate ;)
[20:02:15] <tampakrap>	yeah don't worry
[20:02:17] Error	likes: Unknown command.
[20:02:26] 	 * jlayt likes to watch
[20:02:43] 	 * svuorela is present, but plan to watch only.
[20:03:00] 	 * skelet is curious about
[20:03:29] 	 * ipwizard_ is also watching
[20:04:06] <eean>	http://titanpad.com/SnJwFW2iXL meeting minutes
[20:04:17] 	 * ABCD is just an interested observer
[20:04:55] <aseigo>	ABCD: what's your first name (last name optional) so i can record you properly? :)
[20:05:14] <ABCD>	Jonathan Callen
[20:06:37] <aseigo>	ok, others who have just joined, please add yourselves to http://community.kde.org/20110213_GitWorkflowAgenda#Attendees
[20:06:55] <aseigo>	minutes, as per eean's awesomeness: http://titanpad.com/SnJwFW2iXL
[20:07:11] 	 * aseigo ponders why we aren't using kde's notepad, but ok :)
[20:07:23] <eean>	(you can't just create one on-demand)
[20:07:26] <aseigo>	please enter your name on the minutes before you edit anything
[20:07:29] <aseigo>	eean: aha!
[20:07:45] <aseigo>	ok, so let's get started and hope more join us as we go...
[20:09:07] <mpyne>	Well I'll be out occasionally myself but I'll try to keep up.
[20:09:13] <aseigo>	ok, so the idea of the meeting is to take some meaningful steps towards defining the desired workflow for kdelibs and kde-runtime
[20:09:32] <aseigo>	and perhaps in doing so to create a template that other KDE project teams can emulate
[20:09:56] <aseigo>	we can perhaps break the meeting down into the following topics:
[20:10:12] <aseigo>	* 3rd party examples we want to use as inspiration / learn from
[20:10:17] <aseigo>	* Topic branches
[20:10:23] <aseigo>	* Bug fixes
[20:10:29] <aseigo>	* Trivial changes
[20:10:37] <aseigo>	* Documentation
[20:10:45] <aseigo>	* Helpful tools (e.g. the commit template)
[20:11:01] <aseigo>	sound good? or rather: any objects or additions? (i'll wait ~30s)
[20:11:13] <aseigo>	(during which time i'll add the recent joiners ;)
[20:11:19] <wrohdewald_>	wrohdewald_ only watches
[20:11:20] <mpyne>	Obviously we should come to some overall conclusion as well. ;)
[20:11:27] <ivan|home>	aseigo: add me
[20:11:34] <ivan|home>	although I have no idea to what :)
[20:11:36] <mpyne>	i.e. when are topic branches used, what is the overall workflow otherwise, etc.
[20:11:43] <khindenburg>	git.reviewboard - we covering using this?
[20:12:02] <eean>	mpyne: ah yea, certainly need a bullet point for that :)
[20:12:11] <ivan|home>	any log for the talk so far?
[20:12:28] <tampakrap>	yeah sec
[20:12:32] <eean>	ivan|home: nothing so far really
[20:12:45] <ivan|home>	eean: ok, thanks :)
[20:12:55] <djszapi>	eean: except the point that aseigo mentioned :)
[20:13:03] Topic	eean sets the channel topic to "Discussing KDE's switch to git | Today's Workflow Meeting Agenda: http://community.kde.org/20110213_GitWorkflowAgenda | http://titanpad.com/SnJwFW2iXL minutes | http://community.kde.org/Sysadmin/GitKdeOrgManual | https://sysadmin.kde.org/svnaccount/repo-request.php | http://community.kde.org/Sysadmin/DeveloperAccessForRuleWriting | http://projects.kde.org/projects/playground/sdk/kde-rule".
[20:13:43] <eean>	khindenburg: re: reviewboard, it might come up as part of the workflow discussion, dunno if it needs its own bullet point though
[20:13:44] <mpyne>	ivan|home: Ensure you add yourself to the list of attendees on the GitWorkflowAgenda wiki in the /topic
[20:14:26] <ivan|home>	ok
[20:14:39] <aseigo>	for newcomers, minutes are being group recorded at http://titanpad.com/SnJwFW2iXL
[20:14:53] <aseigo>	khindenburg: yes ... that wil come up throughout i think
[20:15:03] <mpyne>	Another possible topic that would warrant specific mention is any notable pitfalls of an altered workflow
[20:15:24] <aseigo>	mpyne: yes, that's something we will need/want to bring up at each point
[20:15:25] <ivan|home>	aseigo: pad allows max 16 users :(
[20:15:26] <mpyne>	A specific example being Ben Cooksley's warning about git pull --rebase after a merge commit but before pushing it
[20:15:54] <mpyne>	Which makes sense now that I've thought about it, but I probably would not have been innocent of just on my own
[20:16:15] <aseigo>	basically instead of looking at it in gernal terms and looking at pitfalls, reviewboard, etc as individual topics, we'll look at it in terms of types of workflow (features, bugfixes, etc) and cover pitfalls, reviewboard, etc in each
[20:16:22] <mpyne>	ok
[20:16:31] <aseigo>	ivan|home: 16 should be enough for note taking :) if anything gets missed, just holler
[20:16:45] <ivan|home>	ok :)
[20:16:46] <eean>	ivan|home: sucks :/
[20:16:49] <aseigo>	mpyne: yes, i think that falls into "documentation"
[20:17:04] <aseigo>	so. topic #1: the examples of others
[20:17:16] <aseigo>	oh, and i should my role in this meeting as clear as possible as well:
[20:17:41] <aseigo>	i'm really not here to suggest a specific workflow, etc. i'm going to try to facilitate as much as possible and stay out of the prescription business :)
[20:18:01] <aseigo>	there are others here with more knowledge about git than me, and facilitating this meeting will be enough of a task on its own
[20:18:05] <aseigo>	ok, that said... topic #1...
[20:18:20] <aseigo>	on the wiki we have 3 examples listed:
[20:18:38] <aseigo>	CMake .. in particular it covers feature/topic branches: http://public.kitware.com/Wiki/Git/Workflow/Topic
[20:19:02] <aseigo>	it isn't 100% relevant to KDE as it assumes that there is no feature branch collaboration between developers (which is certainly untrue about KDE)
[20:19:06] <aseigo>	but there's some good stuff there
[20:19:16] <aseigo>	Qt's commit policy: http://qt.gitorious.org/qt/pages/CommitPolicy
[20:19:25] <aseigo>	Videolan's strategy: http://wiki.videolan.org/Git
[20:20:20] <aseigo>	any comments / thoughts on those examples?
[20:20:39] <mpyne>	Now we're obviously a bit different from Linux kernel development, but there's probably insights to be gleaned from there if it's documented somewhere
[20:20:58] <eean>	we are *so* different from Linux
[20:21:30] <mpyne>	fair enough
[20:21:34] <aseigo>	eean: true; perhaps there are insights there though? mpyne: did you have anything in mind in specific as to what kinds of things we can take from there?
[20:21:37] <eean>	they have a hierarchical structure. certainly I guess we can learn from Linux that feature branches are very powerful good things.
[20:21:55] <mpyne>	I've always been a big fan of "we screwed this up; here's our lessons learned"
[20:22:17] <mpyne>	if only to make sure they really don't apply here. But I don't know of any after-the-fact discussions of that sort
[20:22:39] <mpyne>	I'm sure there's a million on the vger linux list, but I don't have time to look them up, and I don't suppose the rest of us do either. ;)
[20:22:57] <mpyne>	Either way other projects will have likely already hit them for us and so it's probably not a big deal anyways
[20:24:17] <argonel>	i've found git.git valuable a couple of times, for instance tracking a remote repo
[20:24:29] <eean>	ok so videolan's page is actually pretty much what we have atm
[20:24:54] <eean>	just straightforward work in master development
[20:25:27] <eean>	using rebase for local commits
[20:25:45] <aseigo>	richmoore: notmart: rakuco: can you add yourselves to http://community.kde.org/20110213_GitWorkflowAgenda#Attendees .. notes are at http://titanpad.com/SnJwFW2iXL
[20:25:56] <notmart>	aseigo: okie dokie
[20:26:09] <aseigo>	ok, so we may not have tons to directly rip off from these other groups, but perhaps some useful inspiration :)
[20:26:20] <aseigo>	let's move on to the Interesting Stuff then ...
[20:26:27] <rakuco>	I've already added myself to the attendee list
[20:26:34] <aseigo>	topic #2: Feature Development ... how do we handle Topic Branches
[20:26:37] <aseigo>	rakuco: rocking
[20:27:14] <aseigo>	the goal of this part of the meeting is to emerge with at least a skeleton of a workable, kdelibs-relevant workflow for feature devel
[20:27:23] <aseigo>	(this will be the first part of our "meeting deliverables"
[20:28:10] <richmoore>	if we have too many then they won't get tested
[20:28:36] <richmoore>	so i'd suggest they be kept for non-trivial stuff
[20:29:13] <eean>	well feature branches always happen. in the previous svn model people would just keep the work on their computer much of the time
[20:29:19] <mpyne>	indeed
[20:29:41] <mpyne>	Which also seems to be what CMake devs recommend, but I think it would be preferable in our model to also push topic branches
[20:30:12] <eean>	I agree. this way you can at least see people as they develop and it avoids unexpected code drops
[20:30:13] <mpyne>	If we do that, the question becomes should we have some naming policy to separate them from actual integration/release branches? (like /branches/work in svn?)
[20:30:20] <aseigo>	mpyne: yes, remember that cmake devs don't ever collaborate on feature devel
[20:30:31] <jlayt>	ddr
[20:30:48] <notmart>	a thing i wondered about feature branches... after merged in master, are they supposed to stay there forver for hystorical reasons or be deleted?
[20:30:50] <aseigo>	(this was a clarification on the k-c-d list from Neundorf)
[20:31:29] <mpyne>	I think the reference can be deleted without affecting history, but I'm not sure.
[20:31:42] <rakuco>	what I was planning on doing is developing topic branches locally (occasionally pushing it to a personal clone if someone else is interested)
[20:31:45] <mpyne>	If not I think it would be preferable to hide the reference instead of deleting it if that's possible in git
[20:31:48] 	 * aseigo thinks so too.. can a gitspert confirm?
[20:31:50] <ahiemstra>	yeah, after merging it makes sense to delete the branch imo
[20:32:08] <aseigo>	rakuco: does that make it easier or harder for others to collaborate with you?
[20:32:17] <ahiemstra>	all that does is basically deleting the head
[20:32:18] <rakuco>	compared to svn?
[20:32:27] <aseigo>	rakuco: no, compared to the future :)
[20:32:38] <aseigo>	rakuco: this is what we want, not what we had or even have now
[20:32:43] <eean>	a branch is just a named commit. deleting the name doesn't delete the commit if other commits reference it (eg if it was merged)
[20:32:48] <mpyne>	That's basically the Two Big Ways of collaborating that I'm aware of: 1) topic branches pushed remotely, and 2) personal clones
[20:33:20] <mpyne>	eean: Is it possible to see what the branch name was later? Or is that info lost?
[20:33:24] 	 * aseigo notes that right now we don't have team clones, either. though we can (ab)use a personal clone as one.
[20:33:42] <eean>	well if you delete it, it would be lost. having a 'kdelibs-history' repo to put that stuff would make sense to me.
[20:33:48] <mpyne>	I'm not honestly sure if the pro/cons of each development model, other than that kdesrc-build probably like 1) better than 2) ;)
[20:33:53] 	 * notmart doesn't like clones much, but i'm a gitgnorant
[20:34:03] <eean>	so that the main repo's namespace doesn't get messy. this seems like a problem we can address in about 6 months :)
[20:34:13] <Mek>	even when not deleting, the branch name would only be reliably associated with the actual merge commit
[20:34:17] <rakuco>	aseigo: I think works fine -- people can push to my clone if they feel like doing so, or they could clone my clone and start working on it (and someone could even be considered 'upstream' during development)
[20:34:28] <richmoore>	mpyne: since getting everything together is going to be a pain, kdesrc-build's wants are pretty important
[20:35:38] <mpyne>	well I'm certainly not here to impede on whatever the best workflow actually is. And kdesrc-build could in theory survive if I've coded it right. ;)
[20:35:48] <eean>	advantages to having feature branches in the main repository: the feature branch is very visibly developed. people get emails when anyone commits there, CIA is notified etc
[20:36:02] <eean>	disadvantage: no rebasing over master, since you can't force push into the main repo
[20:36:27] <bcooksley>	aseigo: as part of the operation of git.ko, if you delete a branch or tag, a backup ref is automatically created, containing the branch name and a timestamp
[20:36:37] <mpyne>	As far as rebasing goes, if you force-push that way into a personal clone wouldn't you eventually have to force-push to integrate that history into the original master?
[20:36:44] <mpyne>	i.e. does that merely delay the problem?
[20:36:52] <eean>	mpyne: no, since the commits you are rebasing aren't in the main repo yet
[20:36:57] <mpyne>	ok
[20:37:01] <aseigo>	bcooksley: huh. that's pretty cool.
[20:37:40] <aseigo>	rakuco: how do you propose that others become aware of what work you are doing? (and extrapolate that to the dozens (or, over time, hundreds) of people who will be working on this codebase)
[20:38:17] <bcooksley>	be aware that extensive use of clones isn't recommended, unless you are willing to squash commits together, as when you go to push it to the main repo, you'll run afoul of the 100 new commit for the repo maximum (which prevents a flood from occurring)
[20:38:29] <mpyne>	I think it's pretty important to note that anyone interested can easily be aware of new branches as opposed to new clones of a feature in development. Obviously that can be desired or not desired depending on what is going on.
[20:39:10] <steveire_>	Is this where the git workflow meeting is?
[20:39:14] <mpyne>	steveire_: Yes.
[20:39:16] <eean>	bcooksley: well I think thats kind of predeciding the meeting... clearly if the policy is to use clones, then sysadmin would have to figure it out :)
[20:39:19] <steveire_>	danke :)
[20:39:32] <steveire_>	Shame I missed it til now
[20:39:34] <mjansen_>	bcooksley: i guess it is only time before a option appears in push that pushes in packages of X commits
[20:39:39] <mpyne>	Please note your attendance in the GitWorkflowAgenda wiki in /topic
[20:40:00] <bcooksley>	mjansen_: you can already do that, however if someone did it they would likely get whacked heavily
[20:40:22] <rakuco>	I've never worked on a feature in which bazillions of other people are interested yet ;) in kdelibs I'd send an email to, say, kde-core-devel to say I'm working on feature X. my grip with pushing a development branch to the officla repository is that it 'feels' more official than it should be during development -- as eean said, you can't easily rebase, for example
[20:40:23] <bcooksley>	eean: in this case, they should squash commits prior to push
[20:40:24] <argonel>	ugh, don't do that
[20:40:38] <mjansen_>	which defeats the purpose of using git imho ... but not my decision
[20:40:41] <aseigo>	steveire_: yes... please add yoruself to http://community.kde.org/20110213_GitWorkflowAgenda#Attendees
[20:40:49] <aseigo>	steveire_: notes at http://titanpad.com/SnJwFW2iXL
[20:41:34] <eean>	bcooksley: erm, I just don't like appeal from authority here. though I do agree
[20:41:39] <eean>	because re: clones and the 100 commit max, in my opinion clones branches make sense if you want to be able to force push (which means you don't want others to work, or only two or three people working closely together). but such branches are unlikely to have >100 commits, and probably shouldn't.
[20:41:56] <mpyne>	bcooksley: Is it possible to have some kind of "server side" integration of commits from a clone to a different git.ko repo that would be easier on resources?
[20:41:56] <steveire_>	Thanks. I'll try to pick up where we are now
[20:42:04] <aseigo>	eean: is there a way to allow rebasing certain branches in the main repo? is it an all-or-nothing thing?
[20:42:19] <bcooksley>	mpyne: the problem is that main repositories have email/cia enabled on them
[20:42:23] <mpyne>	e.g. like in SVN you could copy from a URL to another URL without having data go server->client->server
[20:42:38] 	 * Sho_ thinks the 100 commit limit is stupid, btw
[20:42:46] <Sho_>	it's not like we *need* to use a pentium 3 as our mail server.
[20:43:13] <eean>	aseigo: bcooksley is the expert there, but yes I think we could specify that such a thing was possible. eg all branches that start with the name "moshpit-" allow force pushes
[20:43:17] <bcooksley>	I don't think we exactly have a right to send 1000 emaghils to cia thou
[20:43:21] <mpyne>	Perhaps a repo-flag similar to how the repos start out with hooks disabled until the repo admin re-enables them?
[20:43:23] 	 * toma thinks mail floods are stupid
[20:43:41] <toma>	1 mail per push makes more sense, but people need to adapt to that
[20:43:47] <mpyne>	That has the very large downside of possibly forgetting to send those emails later though!
[20:43:47] <bcooksley>	aseigo: permissions wise, it can be done
[20:43:52] <Mek>	or 1 mail per push if > X commits
[20:44:04] <bcooksley>	Mek: that would generate inconsistencies
[20:44:11] <mpyne>	well even that gets into the realm of very large emails, which are also bad
[20:44:16] <Sho_>	Mek: The problem with that is that we currently have consumers that rely on one commit per mail
[20:44:23] <Mek>	bcooksley: and disabling mail at all for pushed of > X commits is better how?
[20:44:27] <Sho_>	e.g. the commit digest software
[20:44:54] <aseigo>	(cia.vc)
[20:44:55] <toma>	we can put in resurces to adapt
[20:45:02] <Mek>	if the choice is between no mail for pushes of > X commits, or one mail, the one mail seems to be a lot better...
[20:45:16] <mpyne>	Perhaps it's easiest just to say that if you intend for new code to land in a repo that it should be in a topic branch (with appropriate naming convention) on the repo? If the work is just experimental/exploratory it would be done in a personal clone?
[20:45:21] <steveire_>	Ah, good to see the moshpit idea for forcepushable branches. That's something I wanted to propose. I've used "volatile_" branches in the past
[20:45:22] <tsdgeos>	fwiw in poppler we do mail per push not per commit
[20:45:56] <aseigo>	ok.. so let me summarize for a moment here as we're getting a number of items that very good and we're starting to drift into specific topics a bit:
[20:46:04] <aseigo>	* topic branches are good, and they should be publi
[20:46:05] <aseigo>	c
[20:46:06] <argonel>	with a large commit, could we not somehow flag or otherwise provide a list of "important" commits that should be sent through cia/email, and just elide the rest?
[20:46:15] <aseigo>	* if in the main repo, they are easier to find BUT: 
[20:46:20] <aseigo>	** we need a naming convention
[20:46:27] <mjansen_>	I would propose to agree on some kind of workflow and THEN thinking how that affects tools and adpating them. The other way is wrong imho.
[20:46:29] <aseigo>	** they should be deleted after merge
[20:46:41] <Sho_>	mjansen_: agreed
[20:46:49] <mpyne>	mjansen_: also agree
[20:47:21] <aseigo>	** we would need to change the force push disallowed on all branches policy, and institute some "per branch" (or name matchign) feature
[20:47:28] <aseigo>	* if in separate personal clones, we don't have the rebase issue, BUT
[20:47:34] <aseigo>	** they are harder to find and collaborate on
[20:47:51] <aseigo>	** we face the "too many commit mails" issue pretty quickly
[20:48:12] <aseigo>	* we have the commit email spawning issue, regardless, as a separate meta-topic about all of git.kde.org to deal with
[20:48:22] <steveire_>	how so? (too many mails) The problem is getting 30 commits at once?
[20:48:29] <aseigo>	i'd like to table that last point for discussion outside this meeting. it should continue, but it's not specific to kdelibs, right?
[20:48:39] <richmoore>	if we have a lot of branches then we'll want a way to document what they do too
[20:48:42] <aseigo>	(and we have a lot of kdelibs ground to cover)
[20:48:43] <eean>	correct, I agree on the tabling
[20:48:44] <mpyne>	steveire_: When/IF the clone gets merged back to the original repo, all those commits are dumped at once
[20:48:54] <mpyne>	+1
[20:48:54] <bcooksley>	steveire_: if someone rebases a branch with 300 commits on it, that is a minimum of 600 emails being sent, excluding bugs.ko
[20:49:02] <bcooksley>	when that happens, cia lags for everyone
[20:49:22] <richmoore>	it's likely to get blocked by spam filters too
[20:49:27] <aseigo>	so our first decision here to make is: branches prefered in clones or master?
[20:49:37] <aseigo>	er, main repo
[20:49:56] <steveire_>	Is commit mails for releasee branches only an option?
[20:50:07] <steveire_>	Sorry if that's been covered
[20:50:14] <aseigo>	steveire_: i don't think it has yet :)
[20:50:18] <eean>	steveire_: no, and thats tabled
[20:50:38] <steveire_>	tabled? You mean coming up?
[20:50:40] <eean>	aseigo: I think we should prefer in main repo. but I'm not sure any rebasing should happen in any branch in the main repo, so that leaves a role for clones.
[20:50:43] <aseigo>	steveire_: let's add that to the email issue ... (i'll note that that also impacts things like BUG: entries)
[20:50:50] <mpyne>	Those emails need to be sent if the commit ever makes it to the release branch, 400 emails at once is very difficult to review for trojans ;)
[20:51:08] <bcooksley>	steveire_: due to the way the commit hooks get the list of new commits, that isn't possible i'm afraid, as it works on the whole repo
[20:51:12] <aseigo>	eean: and it's realistic to develop a feature branch without rebasing?
[20:51:20] <eean>	aseigo: sure, just merge instead
[20:51:33] <aseigo>	eean: ok :) that's what we've doing in plasma, btw... (merging from master)
[20:51:44] <mpyne>	I would agree with staying in the main repo simply due to visibility, *especially* for something as important as kdelibs
[20:51:45] <aseigo>	or something like that anywasy...
[20:51:46] <richmoore>	merging has worked for me with qt too
[20:51:56] <notmart>	how is history cleanliness if you keep merging a gazillion times?
[20:52:02] <eean>	notmart: poor
[20:52:14] <aseigo>	ok, so unless we have a wave of "use clones" in the next 30s, let's go with that.
[20:52:15] <eean>	so... I guess thats the pro/con of it :)
[20:52:22] <toma>	isn't the complete size of a repo also growing when features are developed inside the repo vs in a clone ?
[20:52:25] <steveire_>	In the past there have been very few work-branches in svn afaik. there may be an encouragement for people to create more branches. I don't see why they all need to be tracked by all the hooks until they get into a branch that will be released some day
[20:52:30] <mpyne>	I'm surprised git has no way to simply filter out "Merge from branch 'foo'" in its logs though ;)
[20:52:32] <steveire_>	bcooksley: Can the hooks be changed
[20:52:42] <argonel>	imo use clones, we should keep the history in the main repo as clear as possible
[20:52:46] <bcooksley>	toma: yes, as all branches are fetched by default
[20:52:47] <steveire_>	(I know they recently had lots of changes anyway)
[20:53:10] <eean>	toma: probably not
[20:53:19] <bcooksley>	steveire_: if you have a better way, completely safe with new refs being created, i'm happy to hear about it... git does not make that job easy
[20:53:20] <rakuco>	mpyne: git log --no-merges
[20:53:22] <richmoore>	bcooksley: is that a server side or client side default? ie could we change it if we wanted to?
[20:53:23] <aseigo>	is there a way to keep history of main clear while using branches in main?
[20:53:28] <Sho_>	steveire_: it's easy not to send mails when commits get pushed into release branches, but that doesn't solve the problem for when those commits get pushed into the release branches eventually
[20:53:29] <bcooksley>	richmoore: client side
[20:53:30] <mpyne>	so that already exists then for the history concern...
[20:53:50] <eean>	(I'm completely failing on the minutes and I have no help :( http://titanpad.com/SnJwFW2iXL )
[20:53:50] <Sho_>	steveire_: err, non-release-branches in the first one
[20:53:54] <aseigo>	please, let's not discuss emails right now :)
[20:54:04] <argonel>	having a special workflow to reintegrate the clone into the main repo gives a chance to inspect the history and make it more linear
[20:54:18] <richmoore>	bcooksley: ok, thanks
[20:54:20] <rakuco>	can we *please* always merge with --log?
[20:54:39] <aseigo>	argonel: with the downside of commit floods and much lower visibility of feature branches, yes?
[20:54:47] <mpyne>	aseigo: Rebase commits before pushing them really. A better job of that can be done if using clones, but I'm not convinced that a passable imitation can't be done in the main repo, and the merge commits can be elided anyways...
[20:54:48] <rakuco>	(when merging something into the official branches, I mean)
[20:54:56] <argonel>	aseigo: i think the lack of visibility of feature branches is a social problem
[20:55:03] <aseigo>	rakuco: can you add this to the minutes at the end under the topic of "documenting best practices considrations"
[20:55:32] <steveire_>	Sho_: I'm still not quite sure what the problem is. If only release branches get the hooks executed, then it's only 300 mails when a 300 commit branch is rebased, not 600, right?
[20:55:35] <aseigo>	argonel: indeed; the question is what workflow and tool usage minimizes it
[20:55:52] <Sho_>	steveire_: the *2 comes from one mail for kde-commits and one for CIA
[20:55:53] <aseigo>	steveire_: dude, emails. later. :)
[20:55:56] <richmoore>	argonel: we should have a tool that lists the branches, and a way for people to document their purpose 
[20:55:59] <Sho_>	but yeah, emails later
[20:56:08] <steveire_>	Right, sorry
[20:56:08] <eean>	steveire_: ssh! lol
[20:56:28] <argonel>	richmoore: maybe our projects.kde.org xml file can be adapted for that?
[20:56:43] <richmoore>	argonel: i don't see why not
[20:56:49] <mpyne>	It already does list branches, although I'm not sure what the input to that is other than git from the main repo ;)
[20:57:07] <eean>	argonel: well, why I think whether something is developed in the main repo or in clones is a social question
[20:57:08] <aseigo>	argonel: then we would need a tool that people need to know of and use to track these things?
[20:57:09] <richmoore>	mpyne: yeah, but i'm thinking richer meta info - what it does and who to talk to
[20:57:21] <mpyne>	ok
[20:57:26] <argonel>	aseigo: well, for people a wiki page or a link on the projects.ko site
[20:57:29] <tampakrap>	how about techbase?
[20:57:37] <aseigo>	manual
[20:57:40] <argonel>	for command line, something that looks at the xml
[20:57:51] <aseigo>	where "manual" means "people are expected to do a good job of keeping up with changes" ...
[20:58:02] <mpyne>	Given that I just look at a techbase wiki page talking about how a project would be integrated once KDE 4.4 was released, I'm not really sure I'm big on using a wiki for it... :(
[20:58:03] <aseigo>	don't rely on people when a computer can do the job
[20:58:32] <argonel>	whats the workflow for discovering feature branches when they're in main?
[20:58:36] <eean>	we already have a command line tool for tracking remote branches, its called git :D (eg just use the main repo, and perhaps namespace within it)
[20:58:41] <aseigo>	argonel: git branch -r
[20:58:44] <steveire_>	argonel: gitk
[20:58:48] <tampakrap>	it can be semi-automatic, a script could be used to clean non-existent repos for example
[20:58:58] <mpyne>	projects.kde.org also shows branches on the main repo
[20:59:23] <richmoore>	are we likely to hit scalability issues if we have say 200 branches in the main repo?
[20:59:24] <eean>	and also git pull, git fetch, will squeak about new branches it finds
[20:59:24] <aseigo>	so let's explore a specific issue on the branches-on-main approach that may end up ruling it out:
[20:59:38] <aseigo>	what kind of namespacing could we feasibly enforce for such branches?
[20:59:52] <aseigo>	richmoore: good question... gitsperts?
[20:59:58] <mpyne>	eean: good point.
[21:00:00] <eean>	richmoore: lets cross that bridge when we get there. I've seen repos like this... its not a big deal (but it does point to needing naming standards)
[21:00:04] <steveire_>	richmoore: nope
[21:00:10] <richmoore>	ok, cool
[21:00:13] <Sho_>	richmoore: the only scalability problem I can see with that is reading the output of "git branch -r" when it has 200 lines
[21:00:22] <eean>	right
[21:00:25] 	 * aseigo notes that in kde-workspace right now we are using: "project/commiter/topic" .. e.g. "plasma/aseigo/activitydataengine"
[21:00:26] <richmoore>	Sho_: grep :-)
[21:00:32] <eean>	its a human scalability issue, not a computer one
[21:00:33] <mpyne>	If the concern with the main repo is simply with cluttering the history, that can be papered over with --no-merges to git-log as rakuco mentioned, and some discipline with the actual workflow itself
[21:00:40] <Sho_>	otherwise, git was made for branching :)
[21:00:56] <aseigo>	eean: can we minimize that with good naming conventions of branches?
[21:01:05] <eean>	yep for sure
[21:01:07] <steveire_>	regarding namespace, why?
[21:01:10] <richmoore>	how about we at least categorise things as experimental, feature?
[21:01:10] 	 * aseigo notes that if there isn't a good naming convention system, then we can probably rule out the main repo option :)
[21:01:16] <notmart>	aseigo: to fake it's a team one, could become just project/feature?
[21:01:27] <mpyne>	steveire_: To decide between official-ish branches and "mere" topic development
[21:01:29] <aseigo>	notmart: yes .. that's another permutation indeed
[21:01:32] <notmart>	(i.e. /me did a couple of those if really doesn't work i'll ask to be renamed)
[21:02:02] <aseigo>	richmoore: purely experimental things could be done in personal clones? or how experimental are you thinking? what's the division in your mind between experimental and feature?
[21:02:03] <steveire_>	But why  "plasma/aseigo/activitydataengine" instead of "volatile_dataengine_refactor"
[21:02:07] <rakuco>	I must admit, though, that it always bothers me when a development branch has a lot of merge commits. if it's still under heavy development there should be rebases, not merges. it is like needlessly polluting history
[21:02:14] <rakuco>	(wrt git log --no-merges)
[21:02:22] <aseigo>	steveire_: because then on listing branches we get a nice sorting :)
[21:02:22] <steveire_>	Does the aseigo mean you started it and guide the progress of it?
[21:02:34] <notmart>	and a very good greppbility
[21:02:35] <aseigo>	steveire_: projects are clustered, the name tells me who to talk to about it, the topic tells me wtf it's trying to do
[21:02:39] <aseigo>	steveire_: yes
[21:02:43] <eean>	rakuco: well people 'merging' their local-only branch is clearly wrong 
[21:03:12] <richmoore>	aseigo: i'd say experimental is shared with others, but would never be merged (though it could generate ideas/tools that could be used for a later feature branch)
[21:03:17] <steveire_>	What do official branches look like? KDE/4.6 or 4.6 ?
[21:03:31] <eean>	both!
[21:03:34] <aseigo>	heh :)
[21:03:39] <steveire_>	Can't official mean numeric or "master" ?
[21:03:49] <mpyne>	rakuco: Isn't the idea there to be able to easily merge the development branch *back* once it's done, without a million new conflicts?
[21:03:51] <aseigo>	richmoore: ok.. so would experimental make more sense in a personal clone, or should we try and work that into main repo too?
[21:04:00] <steveire_>	I don't see the value of having aseigo in there
[21:04:07] <steveire_>	The commits tell you who to talk to about it
[21:04:21] <rakuco>	mpyne: if you rebase you don't get a million conflicts, as ideally your commits are on top of master
[21:04:37] <rakuco>	unfortunately I need to leave and will only be back in 2 hours. you kids have fun :)
[21:04:41] <steveire_>	Simpler is better
[21:04:41] <richmoore>	aseigo: i think both could work. we just need to decide if the value of the visibility of the experiments is sufficient to make the overhead for the main repo woth it
[21:04:46] <mpyne>	I think experimental should be personal clone IMO, especially as it would allow more drastic refactoring and fixing of commit history
[21:04:55] <aseigo>	steveire_: you may be right, perhaps it doesn't have any. it's something we and krita have been using and it seems fairly useful, but it certainly does imply a "one developer working on this" process
[21:05:01] <eean>	mpyne++
[21:05:13] <richmoore>	mpyne, eean: that's fine with me
[21:05:16] <mpyne>	My point regarding merging things back is that master itself is diverging away
[21:05:20] <aseigo>	ok.. so we're dividing experimental and "Feature meant from the start to be merged"?
[21:05:50] <mpyne>	even in kdesrc-build, with a topic branch for just *one* major feature group, I've had to merge back and forth just to keep up with refactoring of the code that ended up being required.
[21:05:50] <steveire_>	into "in a separate repo" and "in the official repo" ersp?
[21:05:54] <richmoore>	aseigo: yeah, obviously a feature might fail, but sometimes we just go 'what would happen if...'?
[21:05:56] <steveire_>	resp*
[21:05:58] <mpyne>	Probably my fault for having global variables, but still. ;)
[21:06:03] <aseigo>	steveire_: would you find something like .. "kdecore/pluggablekconfig" more / less useful?
[21:06:08] <aseigo>	richmoore: yes :)
[21:06:38] <steveire_>	I would find pluggablekconfig more useful personally
[21:06:51] <steveire_>	People who are going to collaborate on it will know about it anyway
[21:07:06] <aseigo>	steveire_: that's part of the idea, though, isn't it? to advertise to those who aren't yet?
[21:07:09] <steveire_>	You shouldn't need git branch -a to tell you what's going on
[21:07:21] <aseigo>	in a perfect world, perhaps
[21:07:26] <aseigo>	not sure we live in that worl :)
[21:07:28] <aseigo>	er, world
[21:07:34] <eean>	git branch -a is a great way to learn about whats going on
[21:07:39] <aseigo>	(i know in kde-workspace we don't)
[21:07:40] <fredrikh>	if you need to include your name in the name of a branch it's a strong indication to me that the branch doesn't belong in the main repo
[21:07:48] <aseigo>	(and we communicate between each other a LOT)
[21:07:54] <mpyne>	Are we really debating one or two '/' characters? :)
[21:07:57] <aseigo>	(much more than k-c-d does)
[21:08:00] <Sho_>	fredrikh: +1
[21:08:09] <aseigo>	fredrikh: good point...
[21:08:13] <steveire_>	So you mean if you're working on pluggable kconfig and I want to do "something" in kdecore I would list what's going on and find that?
[21:08:18] <mpyne>	I do agree with fredrikh though, git log contains enough author info for those interested.
[21:08:32] <aseigo>	ok, so ... no author names. we have git log for that.
[21:08:35] <steveire_>	Are you trying to appeal to people who don't know kconfig is in kdecore?
[21:08:39] 	 * aseigo is sweeping consensus here...
[21:08:47] <eean>	fredrikh: well I disagree, even if only one person is working on it, i think it should be in the main repo (for the increased visiblity, avoiding code drops etc)
[21:08:55] <mpyne>	steveire_: Where is lnusertemp? Quick, go! ;)
[21:09:05] <aseigo>	steveire_: kdecore is a poor example perhaps. perhaps solid is a better one.
[21:09:05] <steveire_>	No idea.
[21:09:15] <aseigo>	steveire_: "udevbackend" or "solid/udevbackend"
[21:09:20] <mpyne>	Do keep in mind you can rename branches locally if it's too annoying to type (at least, in theory)
[21:09:26] <richmoore>	eean: i'd say if it's a feature branch then it should be in the main repo even if there's only one poor sole fixing the bug
[21:09:43] <richmoore>	eean: we don't need a name in it since it'll be dfaure :-)
[21:09:44] <mpyne>	It's in kinit btw, although it's referred to by kdecore/kernel/kstandarddirs.cpp as I discovered yesterday
[21:09:47] <aseigo>	richmoore: lol
[21:09:49] <mpyne>	richmoore: lol
[21:10:05] 	 * aseigo ponders
[21:10:21] <steveire_>	aseigo: moshpit-udevbacked, then it will be rebased as it's worked on and gitk --all whos it :)
[21:10:28] <eean>	yea, I might agree that not having names is a good idea. the issue is that if its a longer-term featuer branch it might create 'ego' coding.
[21:10:31] <steveire_>	s/whos/shows
[21:11:03] <aseigo>	how about this (provide your feedback, please :) => if a branch is specific to a subproject, e.g. solid, specify it in the branch name such as "solid/udevbackend". otherwise, give it a good descriptive name such as "pluggable-kconfig"
[21:11:26] <fredrikh>	eean: well it also sends a message to others not to push to that branch
[21:11:37] <richmoore>	how about this - if the branch only affects files in foo/bar then prefix with foo/bar
[21:11:41] <notmart>	aseigo: +1
[21:11:49] <eean>	fredrikh: thats what ego coding does yea :)
[21:11:53] <aseigo>	richmoore: that's a good metric for "specific to a subproject" indeed
[21:11:54] <fredrikh>	yeah
[21:11:56] <steveire_>	notmart: It's not a y/n question :)
[21:12:29] <toma>	and then you need to touch other subproject and rename?
[21:12:34] <mpyne>	steveire_: maybe it was a math question. ;)
[21:12:39] <steveire_>	I say descriptive name. 
[21:12:49] <mpyne>	How about class-or-libname/feature-name ?
[21:12:50] <steveire_>	toma: rename?
[21:13:00] <mpyne>	steveire_: Because you're no longer just within the bounds of /sub/foo
[21:13:01] <toma>	rename the branch
[21:13:25] <richmoore>	toma: yeah, though i'd have thought you'd usually know if you're likely to spread like that
[21:13:43] <mpyne>	Maybe they didn't do the exploratory clone first ;)
[21:13:47] <notmart>	steveire_: i understood as this i.e. project/featre when applicable, descriptive name when is not really about under certain project?
[21:13:50] <richmoore>	toma: can you simply rename a branch?
[21:13:50] <aseigo>	toma: possibly; doesn't seem common though?
[21:13:59] 	 * notmart is to use project/foo as much as possible
[21:14:08] <eean>	richmoore: no; you have to push to a new one and then ask a repo admin to delete the old one
[21:14:16] <toma>	richmoore: don't ask me
[21:14:19] <steveire_>	That seems to be spitting hairs. In practice how much do you think work on a particular branch will be so complicated that so many people will work on it at the same time for a long enough time for that to be worth it?
[21:14:24] <richmoore>	eean: ok
[21:14:28] <aseigo>	toma: weighing how often that happens (subprojectd scope increase) vs usability of having project hinting in branch names?
[21:15:00] <toma>	don't know, just saying it might happen
[21:15:02] <richmoore>	i would guess it would be rare, but that's on the basis of no real evidence
[21:15:09] <aseigo>	so far, ime, feature branches tend to start out rather well defined :)
[21:15:09] <mpyne>	That's why I recommended class-or-libname/feature-name
[21:15:25] <aseigo>	one of the nice things about git's "branch all the time" is branches stay smallish and focusedish
[21:15:43] <aseigo>	ok.. now, let's add the last BOOM! to this: merging
[21:15:49] <mpyne>	It's not a straight directory prefix so if you actually do need to go outside of class.cpp it shouldn't catch people off guard as long as it's really related
[21:16:13] <steveire_>	To stick my oar into the merging thing - I think only feature branches should be merged, everything else rebased.
[21:16:19] <aseigo>	what is the process? announcing i wish to merge my feature branch? when i can merge it? what do we wish to encourage with regards to our release engineering schedule?
[21:16:22] <steveire_>	s/feature/release
[21:16:26] <toma>	lots of dead feature branches will blow up the size of the repo, vs a clone where we dont have that
[21:16:39] <eean>	toma: um, why do you think that?
[21:16:44] <mpyne>	Personally I think "blow up" is overstated.
[21:16:47] <aseigo>	toma: we're going to be deleting branches, no?
[21:16:48] <richmoore>	we already said experiments should be in personal clones
[21:16:56] <toma>	aseigo: are we?
[21:16:57] <mpyne>	git performed *magic* on the kdesrc-build history.
[21:17:04] <aseigo>	toma: on merge at least, yes
[21:17:06] <eean>	toma: unless these are feature branches made by pinheiro, I don't see that happening
[21:17:11] <aseigo>	but that is a good sub-point: when do we consider an unmerged branch "dead"
[21:17:16] <toma>	aseigo: but if development is abandoned?
[21:17:22] <mpyne>	Even if you delete the branch, the commits that it consisted of will survive due to the merge. But really, git can handle it.
[21:17:31] <aseigo>	we know we have a backup for any deleted branch ... 
[21:17:45] <richmoore>	actually that raises another point - can we 'extract' a dead branch and move it to a graveyard repo?
[21:17:52] <eean>	richmoore: yes for sure
[21:17:54] <mpyne>	If you never merge an abandoned branch I'm not sure if git-gc will clean that up or not...
[21:17:55] <steveire_>	aseigo: If your work is in volatile_refactorkconfig you check that out, then rebase it onto master, then git checkout master, git rebase volatile_kconfig git push master, git branch -d volatile_kconfig
[21:17:57] <argonel>	branches that 'die', that is ones that never getting merged, won't their refs just disappear when garbage collected?
[21:17:57] <aseigo>	do we want something like "every january we clean out any branches that were not merged and not worked on in the last calendar year"?
[21:18:37] <aseigo>	argonel: that's the question: do we garbage colleect? if so, how and when?
[21:18:55] <steveire_>	In that scheme, dead branches are branches which can't be rebased onto master
[21:18:58] <eean>	I suggest we table this until its actually a problem. :) personally I don't see anything wrong with repos with hundreds of branches, makes us look productive.
[21:19:00] <ivan|home>	or at least hide them somehow
[21:19:00] <tampakrap>	a script can check for abandonded branches (eg last commit >6months) and mail the repo admins
[21:19:01] <argonel>	aseigo: locally git does it for you, i don't know what happens on the server
[21:19:04] <richmoore>	too infrequent - a process run once a year is broken by design (i have several at my company and we have to fix them by hand each year as we get the scripts closer to correct operation)
[21:19:22] <mpyne>	Perhaps once every release?
[21:19:29] <richmoore>	mpyne: +1
[21:19:37] <mpyne>	we already have a release checklist after all
[21:19:52] <richmoore>	ahem _MALLOC_CHECK 
[21:20:06] <mpyne>	Although probably it would be better not to make it a release team responsibility to *do* it, just prompt whoever volunteered to do it ;)
[21:20:11] <toma>	we can do it at feature freeze
[21:20:13] <mpyne>	richmoore: I *knoooow*. :)
[21:20:15] <argonel>	X number of days without a commit to a branch sends a mail to somebody "responsible" for it, and if we don't get an ACK back it vanishes?
[21:20:25] <mpyne>	I caught the malloc_check_ thing for 4.5 too, at least we're consistent with that one :(
[21:20:44] <mpyne>	feature freeze is actually a great time for that.
[21:20:46] <argonel>	where X is perhaps 180
[21:20:47] <steveire_>	Is there still a desire to put experimental stuff in a separate clone?
[21:20:55] <mpyne>	Ends up on a public calendar so it's not just release team looking at it.
[21:20:59] <mpyne>	steveire_: yes
[21:21:01] <richmoore>	steveire_: there is from me
[21:21:21] <steveire_>	And who defines what is experimental and what is not?
[21:21:22] <argonel>	there's no reason not to, you can push it to the main repo later if it becomes necessary
[21:21:26] <richmoore>	mpyne: yes, that may also drive people to finish things
[21:21:33] <eean>	steveire_: the developer
[21:21:41] <mpyne>	argonel: I like that idea, although the email should also go to a responsible mailing-list that way if the feature is actually useful or should not be deleted, *somebody* could notice it's impending doom
[21:22:11] <steveire_>	Where do the clones live?
[21:22:13] <eean>	I really think we are trying to solve a problem we don't have with this email thing :)
[21:22:17] <richmoore>	mpyne: from what eean says, the delete is not irretrievable anyway and we can have a graveyard clone
[21:22:17] <steveire_>	In my scratch area?
[21:22:18] <eean>	steveire_: quickgit.kde.org
[21:22:35] <eean>	nah, its under a special clone area
[21:22:35] <bcooksley>	steveire_: clones/<repo name>/<username>/<clone name> on git.ko
[21:22:39] <argonel>	mpyne: we could make a "contract" over a branch thats in main, indicating the expected lifespan of the branch and its intention
[21:22:59] <mpyne>	richmoore: that's fine too
[21:23:01] <steveire_>	Ok. If such a facility is available, why have 'non-experimental' stuff in the main repo? Why have two places to look?
[21:23:04] <argonel>	so a field in some DB has an "expiration date" and an "owner"
[21:23:10] <steveire_>	Or more than two
[21:23:17] <richmoore>	argonel: too complex, if it's one release then at least everyone knows where they stand
[21:23:39] <argonel>	richmoore: what about the possibility of a "kde5" branch? :)
[21:23:43] <mjansen_>	how about providing a second repo for all of our official repos for branches?
[21:23:57] <richmoore>	argonel: i'd say that should be another clone tbh
[21:24:01] <mjansen_>	without email hooks  and stuff?
[21:24:14] <argonel>	richmoore: true enough, given the potential for rebases
[21:24:36] <eean>	mjansen_:  why?
[21:24:56] <mjansen_>	to keep the official repo clean and providing a server way to push from devel to official
[21:25:04] <Uninstall>	richmoore, why a different clone? I don't see the reason
[21:25:13] <eean>	whats the point of keeping the main repo clean
[21:25:16] 	 * Uninstall has still a low git knowledge
[21:25:22] <mpyne>	I'd really, really like to ensure that no matter what happens here that the kde-commits mailing list still works
[21:25:29] <steveire_>	What I'd like (getting back to the issue of merges again) is no merges in release branches, and rebasable branches, possibly in a -next clone, like how linux does it, or how git.git has -pu
[21:25:32] <argonel>	i kind of like the idea of a kde5 branch that is always available
[21:25:34] <aseigo>	mjansen_: hooks can be added to a repo with a simple command iirc
[21:25:47] <mpyne>	And by "works" I mean that commits are sent to the list as they happen, instead of 300 at a time. But we're slipping back onto emails...
[21:26:04] <argonel>	so when committing one of those "in kde5 change this" comments, one could also push the actual change to the branch
[21:26:18] <mpyne>	btw I forget, is this workflow kdelibs-specific, or meant to apply to the whole SC (or somewhere in between?)
[21:26:36] <aseigo>	mpyne: we're focusing on kdelibs / kde-runtime, but one can also view it as a template exercise
[21:26:41] <mpyne>	argonel: Actually that is a good idea, although kind of orthogonal to this I think.
[21:26:45] <mpyne>	ok
[21:26:53] <aseigo>	mpyne: i don't think we should try and solve all-of-SC, but our results could be very useful for everyone else too :)
[21:26:58] <toma>	can someone recap what the actual topic is now?
[21:27:01] <aseigo>	(keeps the scope definition within reach)
[21:27:01] <steveire_>	argonel: Or a volatile_bic branch
[21:27:05] <aseigo>	toma: sure ... :)
[21:27:14] <aseigo>	ok, so ... 
[21:27:21] <aseigo>	* feature branches in a share repository
[21:27:25] <aseigo>	* experimental stuff in separate clones
[21:27:43] <aseigo>	* kill off "dead" branches (no commits for N days) one each release cycle
[21:27:50] <aseigo>	er, on each releae cycle
[21:27:56] 	 * aseigo can't type worth crap :)
[21:27:58] <steveire_>	What's a share repo?
[21:28:04] <argonel>	steveire_: aren't there things that are bic that don't have to wait until kde5?
[21:28:05] <eean>	he meant main repo I think
[21:28:09] <aseigo>	steveire_: the main repo, for instance
[21:28:17] <khindenburg>	so that kill is only for kdelibs and kde-runtime correct?
[21:28:40] <steveire_>	argonel: 'this branch contains binary incompatible changes and will be rebased'
[21:28:49] <aseigo>	khindenburg: right now, yes. we'll try and define it for kdelibs and runtime. hopefully we'll come up with something useful for otherprojects to adopt too, though.
[21:28:54] <steveire_>	Thinks that are BC don't wait
[21:28:57] <argonel>	steveire_: imo it doesn't make it clear whats going to be in kde5
[21:29:07] <steveire_>	I have such a branch in grantlee, but didn't push it to public
[21:29:18] <steveire_>	volatile_kde5, then
[21:29:24] <mpyne>	grantlee doesn't have the same reqs as kdelibs though, no?
[21:29:25] <toma>	i think we should KDE wide policy, not limited to kdelibs and runtime. We are still 1 project I hope.
[21:29:28] <aseigo>	kde5 is interesting, but far future. let's discuss the next year's releases?
[21:29:33] <argonel>	i've seen all kinds of comments that things needed to be changed in kde4, but they're unchanged because either nobody had time or nobody knew
[21:29:51] <aseigo>	toma: the SC is more or less one project, yes. there are others more independent, though.
[21:30:04] <aseigo>	toma: and if we try and say we're solving all of SC right here, right now it'll get insanely complex i fear :)
[21:30:11] <steveire_>	mpyne: correct
[21:30:14] <mpyne>	either way, are we more-or-less agreed on the topics we've covered? If so, what's next up?
[21:30:17] <aseigo>	toma: make the problem bite size :)
[21:30:21] <steveire_>	What was the arg against a -next repo?
[21:30:28] <aseigo>	ok, so.. two topics remain here:
[21:30:28] <eean>	mpyne: I'm not sure we actually talked about merging heh
[21:30:33] <mpyne>	OK, merging
[21:30:34] <eean>	we started talkign about old branches instead
[21:30:37] <khindenburg>	I can foresee konsole having long-lived branches as I'm coding it myself - I wouldn't want them deleted
[21:30:41] <aseigo>	* do we have an integration repository? or do we hang everythign off the main repo?
[21:30:47] <steveire_>	I'm completely lost on what's been agreed tbh
[21:30:48] <aseigo>	* how do we handle branching merges?
[21:30:55] <Uninstall>	have you already talked about how to *ask* for branch removal?
[21:31:10] <aseigo>	Uninstall: that's covered in the git docu already?
[21:31:11] <mpyne>	Ask sysadmin using the existing practices for that.
[21:31:30] <fredrikh>	the only points of having an integration branch is if someone is actually testing that branch
[21:31:31] <mpyne>	aseigo: eons ago you mentioned a "always summer in trunk" philosophy IIRC.
[21:31:32] <steveire_>	aseigo: merging branches? 
[21:31:33] <steveire_>	:)
[21:31:36] <eean>	aseigo: are you confusing repository / branch? imo we should try to keep everything in one repository as much as possible.
[21:31:43] <aseigo>	steveire_: feature branches in a shared (e.g. main repo), experimental things in personal clones, pruning dead branches, deleting branches after merge, sensible naming scheme for branches
[21:31:46] <fredrikh>	and the more branches we have, the fewer people are testing each branch
[21:31:48] <Uninstall>	aseigo, is it? Today I suggest to move a waiting for removal branch to something like TRASHCAN/branchname
[21:31:49] <aseigo>	eean: no, i'm not :)
[21:31:52] <mpyne>	I think it's not easy to shift to *that* kind of a workflow although it sounds good in principle
[21:32:10] <eean>	having separate repos for integration just seems pointlessly confusing
[21:32:12] <aseigo>	eean: the suggestion was to have a "-next" repository
[21:32:17] <eean>	why?
[21:32:22] <bcooksley>	ah, remember that even if you delete a branch, it's contents are still safe in refs/backups/....
[21:32:26] <eean>	some hg user? :)
[21:32:28] <steveire_>	fredrikh: Why would people need to test my crazy experimental branch?
[21:32:29] <mpyne>	I thought the -next repo was for kde5 :P
[21:32:31] <aseigo>	eean: i don't know .. i'm just facilitating. ask steveire_ :)
[21:32:37] <steveire_>	feature branches in a shared (e.g. main repo) -- Then why integration clone?
[21:32:40] <aseigo>	aha.. for kde5... ok..
[21:32:51] <aseigo>	if that's the case, lets put kde5 next to "emails" ..
[21:32:54] <steveire_>	Nope, not for kde5
[21:33:02] <steveire_>	for the kconfig_refactor branch
[21:33:16] <aseigo>	steveire_: that would be in a personal clone under "experimental"?
[21:33:17] <fredrikh>	steveire: my point is that if no one is testing your feature branch and no one is testing the code in the integration branch/repo, then what's the point of taking a detour through the integration branch?
[21:33:20] <mpyne>	we've already talked about experimental/feature branches though
[21:33:35] <notmart>	having -one- branch for kde5 seems a bit hmm
[21:33:45] <aseigo>	steveire_: and once you are nearing "this is sane for the general kdelibs population to start teasing at" then merge it as a feature branch on the main repo?
[21:33:56] <notmart>	at this point there could be thousands of them, all quite experimental...
[21:34:02] <steveire_>	One official repo which contains only branhes that will be released from, and another clone, which is free-for-all regarding rebases, and when your branch is done, you rebase it into the official relkeases clone
[21:34:03] <aseigo>	notmart: no kde5, please :)
[21:34:18] <richmoore>	can i suggest we move kde5 out of scope since we have enough stuff to sort making kde4 on git work?
[21:34:25] <notmart>	aseigo: eh, that's the point :)
[21:34:33] <eean>	steveire_: I don't see the point of have two repos. they could be in the same repo, just namespaced separately
[21:34:33] <aseigo>	notmart: hah. :)
[21:34:39] <notmart>	richmoore: eheh, +1 :)
[21:34:50] <toma>	mpyne: deleting branches has to be done by the repo maintainer, iow the one listed on projects.ko. sysadmin is not involved in that
[21:34:50] <steveire_>	fredrikh: The detour through the integration clone is to allow rebasing in a volativle clone
[21:35:03] <mpyne>	toma: OK, even better.
[21:35:26] <steveire_>	eean: i think a different remote is the namespace
[21:35:29] <argonel>	steveire_: +1
[21:35:34] <mpyne>	Honestly I don't think we as a ginormous project will be able to make a parallel "integration" branch work too well...
[21:35:37] <steveire_>	It's a built in namespacing in git
[21:35:43] <eean>	steveire_: but thats just less visible for no apparent benefit
[21:35:48] <steveire_>	mpyne: clone, not branch
[21:36:11] <mpyne>	Fair enough, although my original point stands ;)
[21:36:11] <steveire_>	Why does it need to be uber-visible?
[21:36:15] <eean>	its easy enough to namespace by naming our branches
[21:36:16] <richmoore>	isn't that just going to be an extra hurdle for people? does it bring real valuable?
[21:36:24] <richmoore>	s/valuable/value/?
[21:36:27] <eean>	steveire_: um, why not?
[21:36:28] <mpyne>	Multiple people are sharing this integration clone, no?
[21:36:56] <steveire_>	If I want to work directly on master for small bug fixes I work on the main one, If I want to work on a feature that will take a long time and many commits I work on the orther
[21:37:15] <mpyne>	who updates the integration clone from master as master changes?
[21:37:16] <eean>	on the other *branch* :)
[21:37:32] <argonel>	mpyne: he who made the clone in the first place
[21:37:33] <PovAddict>	sorry guys, I greatly overslept a nap
[21:37:37] <steveire_>	If I am doing my bug fixes in the main one and having a good time, I look to the other one to see what's coming and to see if I can help (Where I means joe newbie)
[21:37:42] <richmoore>	Q: Can you explain this to a new developer?
[21:37:59] <mpyne>	argonel: That goes back to my original question then, is this integration clone shared or not? I'm confused as to the proposal here :)
[21:38:01] <steveire_>	mpyne: whoever pushes
[21:38:02] <eean>	PovAddict: heh, we haven't really gotten to where you're especially needed (the status of the 4.6 branch)
[21:38:19] <argonel>	mpyne: imo "integration clone" is just a fancy name for a scratch repo
[21:38:26] <steveire_>	richmoore: Was that at me?
[21:38:32] <PovAddict>	about feature branches/repos, I'd like to mention a specific case here
[21:38:44] <PovAddict>	sreich was working on plasma support for kdm
[21:38:48] <richmoore>	steveire_: sorry yes. i'm very confused, and i suspect a new developer would be
[21:38:53] <PovAddict>	I migrated his SVN branch into git
[21:39:03] <mpyne>	Yeah, let's start with Q: Can you explain this to an experienced developer? :)
[21:39:11] <PovAddict>	it's currently in a separate clone under his namespace in git.kde.org
[21:39:12] <mpyne>	(which is harder, as there's more pre-conceived notions!)
[21:39:39] <argonel>	are we not somewhat devoid of documentation though?
[21:39:42] <PovAddict>	should it be in a separate clone, or should it be a branch in the main kde-workspace repo?
[21:40:22] <steveire_>	richmoore: : Stuff which will be in the next KDE releases is in kdelibs.git. Stuff which kde hackers are hacking and which may be finished some day is in kdelibs-next.git
[21:40:22] <mpyne>	argonel: Well we can't document the workflow until we get one hashed out ;)
[21:40:23] <aseigo>	PovAddict: as long as it remains "experimental", in a separate clone
[21:40:40] <argonel>	mpyne: :)
[21:40:42] <mpyne>	steveire_: That sounds very much like a shared repo and not a scratch repo
[21:40:50] <steveire_>	As a new developer, If I want to fix a bug I work in kdelibs.git
[21:41:04] <mpyne>	I could see the integration clone thingy working for a scratch repo, but not a shared one. Call me pessimistic if you want ;)
[21:41:20] <steveire_>	mpyne: Yes, it would be shared. I don't quite follow what you mean though
[21:41:27] <PovAddict>	another specific situation: students of a university are contributing to KDevelop, doing all their work in feature branches in a separate clone
[21:41:39] <mpyne>	That's why I was asking "who merges back from master", who does this and that, etc?
[21:41:41] <richmoore>	steveire_: can i paraphrase then: kdelibs.git is 4.6-stable branch and kdelibs-next.git is HEAD?
[21:42:07] <mpyne>	Leaving it on the one who's pushing/pulling from it is just not a very good idea IMO. Is this an existing git workflow that can be googled or something?
[21:42:21] <PovAddict>	the clone is "clones/kdevelop/bport/kdevelop-isi.git", created by Benjamin Port; since git.kde.org doesn't support "team clones"
[21:42:26] <PovAddict>	however anyone can push to it
[21:42:37] <PovAddict>	the only difference is bport is the only one who can create new branches
[21:42:39] <mpyne>	Especially given the description as a "rebase free-for-all", it sounds like way to much chaos to be able to reliably run from and therefore test
[21:42:47] <steveire_>	richmoore: kdelibs.git contains a master branch, a 4.6 branch. That's it. Some day it will get a 4.7 branch. kdelibs-next.git comtains those branches too, but also contains refactor_kconfig
[21:43:22] <eean>	PovAddict: I think they should be developing in the main repo, unless there's something special about the fact that they're a school group
[21:43:29] <toma>	PovAddict: if there is a need, i'm sure we can create team clones somehow
[21:43:37] <eean>	steveire_: whatever for?
[21:43:50] <richmoore>	steveire_: that would seem to put the testing burden on the developers, when they're the scarce resource rather than the users who are plentiful
[21:43:53] <eean>	steveire_: what gets put into the kdelibs-next.git master?
[21:43:56] <PovAddict>	eean: mostly I think it's to avoid annoying via CIA and stuff
[21:44:05] <steveire_>	linear history in kdelibs.git and rebasable branches in kdelibs-next.git
[21:44:17] <mpyne>	CIA *will find out* eventually either way
[21:44:26] <eean>	PovAddict: those thigns aren't annoying, they're good to keep visiblity of their work high. but yea maybe it is special with it being a school group.
[21:44:27] <mpyne>	This is why we should calm down a bit about emails :)
[21:44:37] <PovAddict>	in both the kdevelop-ISI case, and in sreich's kdm-plasma branch, I think there wasn't a justified decision to use a clone instead of branches in the main repo
[21:44:37] <steveire_>	eean: kdelibs-next.git master is what I start with if I want to create a new branch
[21:44:43] <steveire_>	Otherwise nothing
[21:44:51] <eean>	steveire_: so that's really confusing 
[21:44:53] <argonel>	PovAddict: i think they've done it right. Port rebases the feature branches into master, then pushes those to origin/master
[21:44:54] <steveire_>	richmoore: testing burden?
[21:45:02] <eean>	you have this master branch thats for nothing
[21:45:14] <eean>	and is kept up to date by *crickets*
[21:45:15] <steveire_>	When refactor_kconfig is finished it goes into master, and then gets tested.
[21:45:18] <richmoore>	PovAddict: think we could move that out of the meeting as it's making it very hard to read what's going on?
[21:45:36] <argonel>	PovAddict: i assume he's acting as a mentor?
[21:45:41] <PovAddict>	argonel: yes indeed
[21:45:47] <PovAddict>	richmoore: move what out?
[21:46:00] <richmoore>	discussing one specific special case
[21:46:05] <steveire_>	richmoore: What do you mean testing burden?
[21:46:06] <mpyne>	steveire_: So if kdelibs-next is not for testing I think we're missing the reason as to why it exists at all.
[21:46:25] <PovAddict>	richmoore: these are two real cases that we should take as example to make a general guideline
[21:46:30] <argonel>	PovAddict: so the mentor should be looking at their patches anyway, so moving them from one remote to the other would cause him to do that
[21:46:31] <steveire_>	rebasable branches which are namespaced by git branch -a because they;re in a different remote
[21:46:34] <eean>	yea steveire_ you're not making sense to anyone :)
[21:46:44] <steveire_>	Ok. I'll drop it so.
[21:46:52] <mpyne>	But *why* are they in a different remote is the question here. :)
[21:47:08] <eean>	so you need to establish why repos are better namespaces then rename name namespacing. which is a bikeshed question. 
[21:47:11] <steveire_>	different server side hooks - -f not forbidden
[21:47:21] <richmoore>	steveire_: ok, i'm wondering who's doing the testing. is there going to be a recommended branch for our cutting edge users?
[21:47:25] <eean>	the real question is: if we want to have feature branches that are rebaseable or not
[21:47:31] <steveire_>	richmoore: kdelibs.git master
[21:47:44] <eean>	richmoore: steveire_'s dropped that, lets let him drop it
[21:47:46] <steveire_>	eean: I do :)
[21:47:49] <mpyne>	steveire_: OK, maybe look at the logs and see if you can be more specific on some of your answers, mail it to kde-scm-interest that way we can keep going with the meeting.
[21:48:02] <richmoore>	eean: ok, dropped
[21:48:22] <aseigo>	ok.. so another possibility to table. and consensus right _now_ seems to be "one master repo, no integration repo", subject to further future consideration.
[21:48:22] <mpyne>	I have a paper I have to write tonight (assuming my wife doesn't deliver the baby tonight) so I'd like to keep it going if possible. ;)
[21:48:25] <PovAddict>	fyi, I personally rebase the hell out of my feature branch(es) only when I'm alone working on them
[21:48:39] <steveire_>	mpyne: Nah, i'll drop it completely. It's fine
[21:48:41] <aseigo>	have we discussed merging? don't think so :)
[21:48:50] <steveire_>	Rebasable branches in the main repo is cool with me too
[21:48:53] <mpyne>	One thing to keep in mind on that is it is possible to rebase commits that have never been pushed, even on a shared branch.
[21:48:54] <PovAddict>	aseigo: merging in feature or version branches?
[21:48:58] <aseigo>	* when and how does someone say "i will be merging this feature branch"
[21:49:05] <aseigo>	PovAddict: feature branches still :)
[21:49:06] <mpyne>	It's only one you've pushed them that you're "locked in"
[21:49:25] <steveire_>	mpyne: What's a non-shared bracnh?
[21:49:27] <aseigo>	(Or do we care, and people can merge at wil?)
[21:49:35] <mpyne>	aseigo: If we keep it like SVN, it's basically "when it's done" ;)
[21:49:46] <eean>	steveire_: for technical reasons we might come around to the two repo thing :) but we can talk in ideals now.
[21:49:57] <argonel>	i have several "unshared" konversation branches.. they're only on my hd
[21:50:13] <steveire_>	aseigo: I think the first qeustion is should feature branches be rebased or merged.
[21:50:13] <mpyne>	steveire_: A branch you've never pushed basically, or if you have pushed it, it's to a repo that people know history can break from
[21:50:13] <eean>	argonel: we should kill such behavior with fire imo :)
[21:50:34] <mpyne>	Which one is the one that makes git --rebase work?
[21:50:41] <mpyne>	not rebase
[21:50:43] <argonel>	eean: well, with branch names like "duh, wtf was i doing here", maybe they're not something anyone else would want :p
[21:50:44] <mpyne>	--bisect
[21:50:49] <steveire_>	If they should be rebased, the question doesn't make sense anymore, and if they shold be merged, I don't think it matters. 
[21:50:59] <eean>	argonel: so good candidates for your personal clone :)
[21:51:11] <argonel>	rebase squash is going to affect --bisect as well, right?
[21:51:21] <mpyne>	Perhaps
[21:51:48] <mpyne>	I like the "merge" idea as I think it's more descriptive of what's going on. But if what's going on is just an artifact brought about by this workflow, it's not too big a deal either
[21:52:03] <mpyne>	Either way it would be nice to have --bisect if at all possible.
[21:52:12] <PovAddict>	afaik, the main problem with bisect and branches is that it may find two entire branches are fine and the bug being introduced in the merge between them
[21:52:13] <toma>	instead of noting the actual commands, it's better to go a level higher and discuss the consequences 
[21:52:18] <steveire_>	How is merge descriptive of what's going on?
[21:52:22] <mpyne>	Even little old me was able to identify a kernel hiccup with git bisect
[21:52:28] <richmoore>	rebase is lossy irc, do we want a lossy history?
[21:52:42] <argonel>	richmoore: what kind of loss are you thinking of?
[21:52:54] <mpyne>	richmoore: It's lossy in that the commit ids change, but that's it AFAIK. Is there some other losses?
[21:52:57] <steveire_>	richmoore: Do we want unreadable commits because they do 8 things at once?
[21:53:01] <aseigo>	mpyne: how do we communicate when it's done?
[21:53:23] <argonel>	it doesn't lose the original timestamps, i had to resort to manually editing a patch to get rid of those :)
[21:53:29] <richmoore>	argonel: well, doesn't it involve rewriting the history of the commits?
[21:53:31] <aseigo>	mpyne: i think that with kdelibs, at least, we probably want something a bit more conservative than "push whatever, whenever". we did that in kde2 and kde3 and it gave us a mess :)
[21:53:36] <mpyne>	aseigo: delete the ref I would imagine. :)
[21:53:51] <aseigo>	mpyne: but pre-merge-into-master?
[21:53:52] <mpyne>	I wonder if there's a good way to leave a note in git that "feature branch foo has been merged to master"
[21:54:03] <aseigo>	mpyne: we get a nice commit mail about that iirc
[21:54:23] <mpyne>	I mean for those who don't get such mails, but instead get git update errors now
[21:54:29] <aseigo>	gitsperts: rebase or merge feature brancches onto master?
[21:54:30] <richmoore>	we could merge master back into the branch
[21:54:32] <mpyne>	(e.g. kdesrc-build users who are crazily testing branches)
[21:54:33] <argonel>	richmoore: well, the commit messages, timestamp and contents are kept. it does obscure what ref head was at when you started writing the patch
[21:54:59] <mpyne>	AFAIK you should always merge the destination branch into the feature branch right before finally merging feature branch into master anwyays
[21:55:04] <richmoore>	argonel: ok, so we'd only lose the implementation meta data
[21:55:09] <mpyne>	Although maybe that was just some git blog's advice somewhere
[21:55:24] <argonel>	richmoore: and the tradeoff is an easier to understand graph
[21:55:26] <richmoore>	mpyne: you can do that locally without pushing 
[21:55:28] <PovAddict>	that's messy
[21:55:40] <mpyne>	richmoore: right
[21:55:47] <argonel>	somewhere around here i have some very scary commit graphs
[21:56:05] <PovAddict>	if you merge master into your feature branch (which you should do regularly anyway), and right afterwards you merge your feature branch into master, that last merge will be a fast-forward
[21:56:19] <mpyne>	So that is good or bad then?
[21:56:21] <argonel>	richmoore: http://d.spearce.org/2007/07/wide-gitk.gif
[21:56:24] <PovAddict>	the merging commit message will say you merged master into feature (from the first merge), not the other way around
[21:56:25] <mpyne>	You just said it was messy I thought
[21:56:49] <notmart>	argonel: wow O.o
[21:56:56] <PovAddict>	if you were rebasing all along, the final merge will be a fast-forward too
[21:57:10] <argonel>	thats what unrestrained merging does :)
[21:57:11] <PovAddict>	so I think we need a way to announce a feature was merged into master, independent from the commit graph in git
[21:57:19] <richmoore>	argonel: scary, you have a motif combo box in the bottom right!
[21:57:20] <PovAddict>	argonel: what repo is that? o.O
[21:57:47] <aseigo>	PovAddict: can we get a pre-merge workflow?
[21:57:51] <aseigo>	here's why:
[21:57:53] <argonel>	richmoore: haha not my screenshot, its from shawn pearce
[21:57:55] <steveire_>	PovAddict: If the feature is rebased in, why have  notification?
[21:58:01] <aseigo>	historically in kdelibs we've had all kinds of ... hm .. unhappy additions
[21:58:08] <aseigo>	many more very HAPPY ones, of course :)
[21:58:26] <aseigo>	some of those unhappy additions would have been turned into happy ones with input and review
[21:58:42] <aseigo>	of course, people can't provide input and review on everything (time issues). similar to why we have/had kde-review
[21:58:59] <argonel>	original blog - http://blog.spearce.org/2007/07/difficult-gitk-graphs.html
[21:59:00] <aseigo>	we give people a signal that "now's a good time to look, cuz it's going to go live!"
[21:59:34] <mpyne>	A separate question. If you rebase a branch onto master, doesn't that re-send every single commit mail?
[21:59:40] <aseigo>	is there perceived value in having a "please announce N days/hours before merging a feature branch"? or should we rely on other social mechanisms outside the scope of our git workflow
[21:59:41] <aseigo>	?
[22:00:09] <mpyne>	I think there's great value in that kind of warning.
[22:00:11] <argonel>	mpyne: i believe so
[22:00:21] <bcooksley>	mpyne: it does
[22:00:25] <steveire_>	mpyne: It's only a re-send if the commit hook tracks all random branches
[22:00:29] <mpyne>	right
[22:00:30] <PovAddict>	aseigo: I think what we need is "please announce N days/hours before introducing a large change in the repo"; whether it was done in a branch or not is an irrelevant detail
[22:00:33] <steveire_>	or feture branches.
[22:00:39] <steveire_>	I'd say make the hooks only work on release branches
[22:00:40] <PovAddict>	what if I have a tiny 3-commit feature branch?
[22:00:45] <mpyne>	I hate to bring up emails but this makes it a big workflow decider then
[22:01:32] <mpyne>	I will like to re-stress my earlier point that sending 300 mails en masse to kde-commits for post-merge-to-master review is, quite simply, bullshit
[22:01:43] <mpyne>	that's no review at all
[22:01:49] <steveire_>	aseigo: how about this: when I think refactor_kconfig is done but needs review I rebase it to master and push
[22:01:55] <steveire_>	Then I email kcd for review
[22:02:07] <eean>	mpyne: its more for archival purposes at that point :)
[22:02:07] <steveire_>	You can look through the commits as they apply to current master
[22:02:10] <PovAddict>	steveire_: having done most of the work in a separate repo? sounds good to me
[22:02:16] <mpyne>	And if you believe that mails should be sent from feature branches from that reason, it seems to imply you *must* merge back to master instead of rebase.
[22:02:35] <eean>	yep
[22:02:37] <steveire_>	PovAddict: The consensus would be that the work is done in kdelibs.git, not a separate repo
[22:02:38] <argonel>	bcooksley: can the hooks differentiate merge from rebase?
[22:02:47] <steveire_>	And I woul stress the rebase not merge thing
[22:02:50] <mpyne>	eean: If we're not sending emails for feature branches then it's not for archival as there's no guarantee of wider review at all :(
[22:02:57] <PovAddict>	steveire_: you can't rebase then, that's non-fastforward pushing
[22:03:14] <bcooksley>	argonel: they can't tell at all if you've rebased, they can detect merge commits and ignore them....
[22:03:17] <eean>	argonel: yes, very much so. they will reprocess any rebased commits and will ignore any already pushed commits when you merge
[22:03:28] <steveire_>	If it's merging we're doing then you'll have to review commits which are made irrelevant by a merge further up, but you won't know until you hit the merge
[22:03:38] <steveire_>	I can give an example of that in grantlee if you want
[22:03:41] <bcooksley>	argonel: steveire_: it uses a very special mix of rev-parse, grep, rev-list and merge-base to build the list of commits to process
[22:03:51] <mpyne>	eean: How does that work? Is it based on the commit message alone (because the commit ids must change with a rebase)
[22:04:24] <mpyne>	steveire_: Later commits can invalidate earlier commits in a rebased history as well though
[22:04:29] <PovAddict>	if there's commits in the server, and you rewrite them (eg. with rebase) and push them, you'll cause a new stream of emails
[22:04:29] <eean>	yea with the ids. also note that rebased commits may even have human-changes, if you had to fix merge conflicts
[22:04:32] <steveire_>	But why are the hooks processing all random feature branches?
[22:04:38] <mpyne>	steveire_: You're more arguing for reviewing from now to the past I think :)
[22:04:58] <steveire_>	mpyne: The 'fix x' commit can be squashed into the 'introduce x' commit
[22:05:01] <bcooksley>	steveire_: why you ask? because the hooks don't give a damn what it is, they just know they have to process it
[22:05:08] <mpyne>	steveire_: To avoid sending 400 emails at once when the branch is merged/rebased to master
[22:05:28] <steveire_>	mpyne: I don't see the problem with that. 
[22:05:36] <bcooksley>	the hooks process any push to any ref, regardless of what it is
[22:05:45] <mpyne>	steveire_: That's possible with branches as well. Like I mentioned earlier, you can rebase any commits that you haven't pushed.
[22:05:47] <steveire_>	For one thing a very large branch like that could likely be rebasead in stages
[22:05:49] <toma>	we can still do a 1 mail per push, if people want that and help with adapting the current users
[22:05:55] <bcooksley>	steveire_: under your proposal, commits would miss mails to the list, thus avoiding review
[22:06:21] <steveire_>	bcooksley: Correct
[22:06:23] <mpyne>	toma: I think that would be good anyways, but a 400 mail-in-1 monolith is still a Bad Idea IMHO
[22:06:36] <steveire_>	Those commits should be reviewed when they're ready to go into a release brac
[22:06:41] <steveire_>	branch
[22:06:57] <steveire_>	Ok, lets say I have a 400 commit branch
[22:06:59] <bcooksley>	mpyne: yes, we know it isn't good, but until the legacy systems get fixed....
[22:07:12] <mpyne>	So basically between the time it's developed and finally moved in is when the review would happen? e.g. reviewboard entry?
[22:07:29] <steveire_>	Lets say many of those commits are actual bugs in master that I just fixed in my branch because I didn't want to bother switching branches
[22:07:30] <PovAddict>	only repository admins can do non-fastforward pushes; so you can't rebase your feature branch constantly and also have it in the main repo
[22:07:46] <mpyne>	bcooksley: That point has nothing to do with legacy systems. I just personally don't want to download 500 KB emails ;)
[22:07:49] <richmoore>	mpyne: even scarier would be the effect on bugs.kde.org of a 400 bugfixes in one merge :-)
[22:07:52] <bcooksley>	PovAddict: even repo admins can't fast-forward
[22:07:56] <mpyne>	richmoore: lol, good point.
[22:08:04] <mpyne>	b.k.o can even't handle an advanced search at this point
[22:08:08] <steveire_>	Here's what should happen: I create a new branch, put only the bug fixes into it, and push that to master, then I rebase and my 400 commit branch is down to 200 commits
[22:08:35] <bcooksley>	er. push that to master = merge that to master?
[22:08:56] <PovAddict>	steveire_: that's a good workflow; unless your branch was already pushed to the main server repo before
[22:09:17] <steveire_>	po"<PovAddict> only repository admins can do non-fastforward pushes; so you can't rebase your feature branch constantly and also have it in the main repo" Enter the argument for a separeate wqork branches repo
[22:09:19] <richmoore>	i think i'm too ignorant here, and perhaps others are too. can someone give a simple definition of rebasing?
[22:09:27] <aseigo>	PovAddict: can you explain the impact of that?
[22:09:39] <mpyne>	richmoore: honestly the git-rebase man page is not too bad.
[22:09:46] <PovAddict>	ok, simple problem here:
[22:09:55] <argonel>	thats partly covering up for bad workflow at the outset
[22:09:57] <mpyne>	richmoore: but the idea is that to go from A->B->C->D, there was a diff applied for each arrow.
[22:10:01] <steveire_>	bcooksley: no, push a master whcch contains the committs, rebased so there is no merge
[22:10:06] <mpyne>	git-rebase re-applies those diffs starting from a point other than A.
[22:10:18] <PovAddict>	if you push your feature branch, then rebase it, you cannot push again the result of the rebase
[22:10:20] <mpyne>	so you should still get the same results overall, but the history may be a bit different.
[22:10:25] <steveire_>	richmoore: Imagine a reviewboard patch
[22:10:26] <mpyne>	Which changes the commit ids involved.
[22:10:28] <aseigo>	ok... since we're a couple hours into this thing and we're a bit mired on this point ... can i suggest the following:
[22:10:31] <richmoore>	mpyne: so a 3 way nerge
[22:10:41] <steveire_>	Imagine it does multiple things so it should be in multiple commits
[22:10:48] <PovAddict>	git.kde.org only allows pushes if the new commit graph is a strict superset of what the server has (aka. a fast-forward)
[22:10:48] <mpyne>	A 3 way merge could be converted into a linear history with rebasing, is the idea.
[22:11:12] <steveire_>	So if you create a rebased branch it's like having a 'strream of commits that apply to master'
[22:11:12] <aseigo>	let's get a few individuals to write up a set of proposed merge "best practices". let's put them on the wiki page.
[22:11:32] <aseigo>	each person can present _a_ workflow. maybe steveire_, PovAddict, eean could do this?
[22:11:32] <PovAddict>	ok, please let's let both aseigo and steveire finish their half-written thoughts
[22:11:32] <steveire_>	Consider that in the svn workflow, reviewboard patches had to be updated because of changes in trunk
[22:11:42] <steveire_>	In git we call those kinds of changes rebasing
[22:11:51] <aseigo>	PovAddict: i have no particular thoughts started atm :)
[22:11:53] <richmoore>	ok, thanks
[22:12:10] <eean>	aseigo: yes, makes sense
[22:12:16] <aseigo>	andt his workflow should just be for the merging bit
[22:12:17] <steveire_>	So you can create a branch which doesn't have any merges and contains purposeful commits which apply to master.
[22:12:22] <steveire_>	You can do that by reabsing
[22:12:23] <aseigo>	we're basically on consensus for everything up until then
[22:12:27] <steveire_>	I'm donethanks :)
[22:12:30] <aseigo>	steveire_: :)
[22:12:42] 	 * aseigo remembers now why he used to do =) instead
[22:12:50] <mpyne>	You can also create purposeful commits in a merging workflow, please don't forget :)
[22:13:04] <mpyne>	The only problem is that you cannot rebase what has been pushed already, for the reasons PovAddict gave
[22:13:16] <mpyne>	I have run git-rebase quite a few times already working on kdesrc-build
[22:13:24] <mpyne>	(hey, no one's perfect ;)
[22:13:26] <steveire_>	That means the rebased commits are not necdessarily purposeful
[22:13:27] <argonel>	well, you *can*, its just very impolite :)
[22:13:36] <aseigo>	mpyne: we expect *you* to be, though. ;P
[22:13:37] <steveire_>	I'll give an exmaple in grantlee. Bear with me
[22:13:37] <PovAddict>	argonel: you can't, the server won't allow the push
[22:13:43] <PovAddict>	if you plan to rebase your branch, you'll have to use a separate repo for that branch
[22:13:44] <mpyne>	well our git server will block it
[22:13:48] <aseigo>	ok, quickly last two things for today's meeting (and we'll overflow the rest of the agenda)
[22:13:53] <aseigo>	* bugfix strategy
[22:13:55] <argonel>	PovAddict: it will if you go on bended knee to sysadmin and say "mea culpa" :)
[22:14:00] <aseigo>	* documentation plan
[22:14:04] <mpyne>	steveire_: They were certainly purposeful by the time the rest of the world saw them though
[22:14:11] <aseigo>	so.. bugfixing
[22:14:22] <aseigo>	options currently seem to be:
[22:14:30] <aseigo>	* in a branch, merge to master, backport to stable
[22:14:52] <aseigo>	* in stable, merge into master (or cherry-pick when merge is broken?)
[22:15:03] <aseigo>	* free for all: do it where you want it.
[22:15:20] <aseigo>	* others?
[22:15:26] <aseigo>	... discuss!
[22:15:27] <aseigo>	:)
[22:15:31] <mpyne>	Seems to cover it. Like last time, pro/cons?
[22:15:39] <bcooksley>	the primary difference is backport vs. forwardport 
[22:15:42] <PovAddict>	for completeness: * the usual SVN way, commit to master, cherry-pick to stable
[22:15:47] <PovAddict>	(backport)
[22:15:51] <mpyne>	good point
[22:16:08] <mpyne>	Smarter ones than me seem to prefer fixing in stable, merging to master.
[22:16:08] <toma>	we have always backported, why change it ?
[22:16:23] <mpyne>	But I'm not sure it's really feasible. I even tried it yesterday
[22:16:29] <notmart>	emotionally, i'm pro backport, again, oput of gitgnorrance...
[22:16:36] <notmart>	real drawbacks of bckporting?
[22:16:39] <aseigo>	toma: for a few reasons...
[22:16:41] <eean>	toma: it lets git keep track of whether you've up-ported all your fixes or not
[22:16:42] <mpyne>	I'm not going to run 4.6 kdelibs and re-compile everything just to test a KSharedDataCache patch
[22:16:49] <bcooksley>	plus what happens when you have a "hack fix" for stable, and a proper fix which breaks string freeze for instance?
[22:16:54] <aseigo>	a) testing against stable is far easier for a bug fix compared to testing against a trunk with new features
[22:17:01] <mpyne>	Not until it's actually complete :)
[22:17:14] <aseigo>	b) it ensures things land in stable :)
[22:17:31] <steveire_>	http://dpaste.org/yEHm/
[22:17:33] 	 * jlayt don't think one size would fit all, but think forwardport is a better workflow
[22:17:33] <PovAddict>	I'd like to mention a few things here
[22:17:39] <PovAddict>	we need good documentation of this
[22:17:40] <aseigo>	c) git makes branch handling easy, unlike svn where backporting was simply a shit load easier
[22:17:45] <toma>	aseigo: again, we have always done backporting, a) and b) seems to work fine for us
[22:17:48] <mpyne>	And the patch I'm referring to needs slight alteration for 4.6 so I can't merely merge it one way or the other anyways :(
[22:17:51] <aseigo>	jlayt: agreed on the "one size fit all"
[22:17:54] <PovAddict>	as you may know, I recently did the initial merge of 4.6 to master in kde-workspace
[22:18:07] <PovAddict>	yesterday I looked at the repo, and all commits in 4.6 were backports of bugfixes in master
[22:18:09] <afiestas>	+1 for forwarding
[22:18:21] <aseigo>	toma: again, this about what we want, not what we've done. :) of course, we can keep status quo, but we ought to have good reasons for it other than "because we have been"
[22:18:29] <notmart>	ook
[22:18:33] <mpyne>	Maybe I'd go for "forward port if possible, but don't bend over backwards to do it"
[22:18:35] <aseigo>	toma: and yes, i agree it generally works, but if we can improve on that?
[22:18:44] <mjansen__>	does someone think it is possible to enforce whatever decision is made?
[22:18:45] <aseigo>	PovAddict: +10 on documentation
[22:18:50] <aseigo>	mjansen__: socially, yes
[22:18:58] <steveire_>	mpyne: See the commits I reference here: http://dpaste.org/yEHm/ Many of the commits in the branch are not purposeful as they don't contribute to the overall goal of getting the feature in
[22:18:59] <PovAddict>	another point: if you make a change in master, and backport it to stable, a merge from stable into master will work just fine
[22:19:04] <mjansen__>	even if it costs possible backports?
[22:19:08] <toma>	aseigo: i think moving to git is difficult enough, combining it with a change of workflow seems bad to me.
[22:19:12] <aseigo>	where "enforce" means "encourage and most people will be cooperative because KDE people are awesome like that"
[22:19:23] <eean>	PovAddict's last point is important. :) its easy to do a bit of both
[22:19:27] <aseigo>	toma: it's a small change -> in trunk or in branch (in svn terms)
[22:19:45] <bcooksley>	aseigo: some people are sufficiently confused enough with git atm...
[22:20:09] <aseigo>	indeed. just realize that whatever we do now for things like bug fixing is what we'll likely be "stuck" with
[22:20:12] <toma>	we have historically a developers group that like to work in head. Now you are proposing they should all work in a branch and work from there.
[22:20:16] <aseigo>	it will become much harder to change this later
[22:20:17] <PovAddict>	something even more important to note: when I did the initial merge from 4.6 to master in kde-workspace, I found one or two bugfixes that hadn't been forward-ported
[22:20:26] <PovAddict>	meaning they were in 4.6 and not in master
[22:20:41] <eean>	toma: so what we have been doing hasn't been working ^^
[22:20:47] <mjansen__>	the last thing would be easier done with a cron job that checks for missing merges and sends the list to the ml
[22:20:52] <toma>	eean: ?
[22:20:55] <PovAddict>	surprisingly, one of those bugfixes was from dfaure
[22:20:58] <eean>	PovAddict's point
[22:21:15] <mpyne>	mjansen__: which only works if git can actually determine the commit is missing from 1 (i.e. a merge was done)
[22:21:25] <bcooksley>	having a bugfix in master but not in stable is the lesser of two evils compared to the fix in stable but not in master
[22:21:28] 	 * aseigo needs to take a break for 10.. bbiab
[22:21:34] <aseigo>	(please continue on this issue :)
[22:21:43] <mpyne>	I shall also take a break to change a diaper then :P
[22:21:46] <PovAddict>	btw, for testing purposes, you can still do your fix in master
[22:21:52] <PovAddict>	without pushing it
[22:22:10] <PovAddict>	once it's working fine, cherry-pick it to stable and push that
[22:22:33] <mjansen__>	if it can't it's not worth to call it a revision control system. it was only so complicated because the merges, cherry-picks weren't don int git
[22:22:36] <bcooksley>	also, some people have had bug fixes which may have caused regressions.... given the majority of devs run trunk, it is probably better to let them test it prior to back porting a possibly dangeous fix
[22:22:39] <richmoore>	we want svnbackport to be implementable
[22:22:53] <toma>	bcooksley: +1
[22:23:14] <steveire_>	I say free-for-all. I will do my bug fixes in stable and merge into master. If mpyne doesn't keep 4.6 around, then he puts his bug fix in master and doesn't backport. 
[22:23:23] <PovAddict>	bcooksley: in that case it may be fine to push to master and then backport
[22:23:39] <steveire_>	Someone else might want to do the fix in master, cherry-pick, test push. I don't think it needs regulation
[22:23:52] <richmoore>	tbh this is starting to sound like i'd need to know way more than i do about git to simply fix a bug
[22:23:53] <PovAddict>	but many people push to master and *immediately afterwards* push to 4.6, which doesn't give any more testing than doing it in 4.6 and merging to master
[22:24:05] <mjansen__>	only one regulations. not fixing it twice
[22:24:09] <richmoore>	the result from my side will be that bug fixes would not be backported
[22:24:12] <steveire_>	"<PovAddict> once it's working fine, cherry-pick it to stable and push that" Don't do this without building and testing
[22:24:18] <bcooksley>	steveire_: what happens if a bug fix involves patches which are different on the 4.6 and master branches due to a refactor, or other changes?
[22:24:55] <steveire_>	bcooksley: I will implement in 4.6 and merge fixing the conflict and reimplementing for master.
[22:24:58] <bcooksley>	steveire_: only committing buildable changes is already part of our social commit access policy
[22:25:01] <PovAddict>	bcooksley: then you should do the change in 4.6, merge into master, tweak it in master, and push both 4.6 and master
[22:25:07] <steveire_>	Someone else will fix in master, then reimplement to fix in 4.6.
[22:25:19] <PovAddict>	bcooksley: if you simply do separate changes in 4.6 and master, merging 4.6 into master later will probably bring conflicts
[22:25:34] <mjansen__>	steveire_: then merge strategy =ours
[22:25:40] <bcooksley>	PovAddict: exactly, that is why you cannot try to run with two different workflows at once
[22:25:47] <mjansen__>	that's why we need then cron job
[22:25:54] <steveire_>	mjansen__: I don't know what that means tbh
[22:26:00] <PovAddict>	careful with --ours, it's easy to lose changes...
[22:26:19] <mjansen__>	we need to know about missing merges as early as possible
[22:26:33] <richmoore>	guys, seriously - if people need to be git experts to work on kde then they won't do so
[22:26:39] <mjansen__>	careful with editors ... it's easy to lose changes ... 
[22:26:41] <richmoore>	we need this stuff to be simple
[22:26:44] <bcooksley>	richmoore: +1
[22:26:47] <PovAddict>	in the initial 4.6->master merge in kde-workspace, I used merge -s ours, but first I spent a week looking at every single commit to make sure it was already forward-ported
[22:26:48] <steveire_>	And if I do my fix and I can't merge 4.6 into master but it doesn't merge I try to fix the conflict or email someone who can
[22:26:50] <bcooksley>	hence my support of backport
[22:26:59] <eean>	why is backport simpler?
[22:27:34] <steveire_>	I really think we can do both. Where I forwardport and you backport.
[22:27:34] <eean>	we make things simpler by giving concise outline of the 'correct' method, thats kind of the point of this discussion
[22:27:47] <mjansen__>	PovAddict: only because there were so many
[22:27:47] <steveire_>	Eventually you will decide it's better :)
[22:27:52] <eean>	heh yes
[22:27:56] <PovAddict>	you don't have to be a git expert
[22:28:17] <PovAddict>	you do have to eg. understand what rebase actually does if you're going to use it, which I think hasn't been the case sometimes :)
[22:28:20] <richmoore>	you really do - even to understand half of what you are suggesting
[22:28:36] <PovAddict>	I think the discussion looks more complex than it actually is
[22:28:58] <eean>	richmoore: and you're suggesting?
[22:29:03] <PovAddict>	let's assume we pick the forward-porting workflow
[22:29:04] <bcooksley>	ok, consider one of the following scenario's:
[22:29:32] <bcooksley>	1) code was refactored in master, fixing a bug in the process, but stable still needs the fix so get's it, obviously the stable fix can't be merged in
[22:29:32] <PovAddict>	all you have to do is: do your bugfix in 4.6, commit, switch to master, merge 4.6
[22:29:57] <bcooksley>	2) fix which possibly introduces more regressions, and can vary depending on the setup
[22:29:58] <richmoore>	eean: apply a bug fix in master, and have an equivalent of svnbackport for the previous release
[22:30:13] <PovAddict>	is svnbackport a tool?
[22:30:23] <Sho_>	PovAddict: kdesdk/scripts
[22:30:25] <richmoore>	yes, it's a script in kdesdk/scripts
[22:30:51] <mjansen__>	that script is called cherry-pick
[22:31:05] <eean>	richmoore: why is apply a bug fix in 4.6 so much more difficult to the git newb? :)
[22:31:19] <PovAddict>	indeed, it looks like that script is unnecessary in git
[22:31:26] <mpyne>	The thing with implementing in 4.6 and merging to master is that if everyone does that, you /should/ always be able to merge to master, with the only conflicts due to your one bug fix.
[22:31:31] <richmoore>	eean: because anyone who wants to learn stuff will be using trunk
[22:31:37] <mpyne>	And then you can tell which bugfixes have been forwardported or not.
[22:31:59] <mjansen__>	afaics cherry-picking does not prevent the merge too.
[22:32:02] <PovAddict>	note that all this discussion is about what should ideally happen
[22:32:12] <mjansen__>	only doing it twice in unrelated commits does
[22:32:13] <steveire_>	bcooksley: (2) If it might introduce regressions or be really complex or different in 4.6 put it in master and be done with it
[22:32:14] <mpyne>	mjansen__: Really? That's good
[22:32:25] <eean>	richmoore: I really don't follow that logic at all
[22:32:27] <steveire_>	In practice I think that's rare anyway
[22:32:34] <PovAddict>	in KDevelop, most people use the forward-port workflow; but it still happens that people push things in master that other devs suggest backporting, and it's possible
[22:32:39] 	 * richmoore notes that theory is lovely and pretty, but doesn't get things done
[22:32:52] <PovAddict>	also, not everybody merges from 4.6 to master
[22:32:56] <mpyne>	eean: It's easier to go back in time for one repo with the rest in master than to go forward in time for one repo to master
[22:32:58] <mpyne>	due to dependencies
[22:33:00] <PovAddict>	you can do your bugfix in 4.6 and let someone else merge it later
[22:33:13] <argonel>	i think i +1 the "free for all" idea.. we should "suggest" a backport workflow, because its a bit easier to understand and most people will run trunk (therefore easier to at least ensure it builds)
[22:33:21] <jlayt>	there are good use cases for both forwardport and backport, and people are stubborn/forgetful, we will need to ensure both work and tell people how to make it work
[22:33:25] <toma>	ok, so we all agree, lets move on ?
[22:33:26] <eean>	mpyne: you lost me on the time travel :)
[22:33:44] <argonel>	if someone wants to do something more complicated, they'll either know what they're doing or wear egg
[22:33:48] <bcooksley>	toma: +1
[22:33:49] <mpyne>	Moving a 4.6 KDE SC to have kde-runtime (and only kde-runtime) from master is difficult
[22:34:13] <mpyne>	Moving a master KDE SC's kdemultimedia back to 4.6 is easier
[22:34:23] <toma>	Handling trivial changes
[22:34:24] <toma>	require branches, allow direct to an integration branch or even master?
[22:34:39] <mpyne>	Directly to master IMHO
[22:34:51] <richmoore>	mpyne: as soon as we have an upstream library make an incompatible change, both are damn near impossible :-(
[22:34:52] 	 * jlayt wonders why anyone only running trunk would be interested in backporting fixes
[22:35:00] <richmoore>	jlayt: i do
[22:35:05] <mpyne>	I do as well
[22:35:11] <richmoore>	jlayt: so that people get fixes
[22:35:17] <mpyne>	My problem is having to wait hours for the damn rebuild to be done.
[22:35:30] <mpyne>	I don't have enough time to maintain completely parallel KDE trees
[22:35:32] <steveire_>	jlayt: +1
[22:35:42] <notmart>	jlayt: interested because people get bugs in their distro packages? i do as well :)
[22:35:50] <PovAddict>	mpyne: if you're going to be switching branches often, you need ccache
[22:35:54] <mjansen__>	mpyne: but how do you know that fix even compiles after backporting?
[22:36:01] <steveire_>	Also, re argonels point. Should we encourage pleople to run 4.6 instad of master?
[22:36:05] <mpyne>	PovAddict: already have it :P
[22:36:16] <mpyne>	mjansen__: See above about waiting hours for the rebuild...
[22:36:16] <PovAddict>	then it shouldn't take hours :)
[22:36:36] <bcooksley>	steveire_: we should encourage master usage, to ensure the next major releases features get some decent testing
[22:36:39] <mpyne>	kdesrc-build disagrees :)
[22:36:41] <notmart>	mpyne: yeah, for me too, maintaning two complete kdelibs/rintime/workspace is a big no no for too many
[22:36:42] <steveire_>	Oh, by the way, git-new-workdir allows you to have 4.6 and master without duplicating on hd
[22:36:51] <PovAddict>	in kdevelop I have separate workdirs for stable and master, via git-new-workdir
[22:37:12] <PovAddict>	but that's a bit of a special need; sometimes I use one version of KDevelop to debug the other version :)
[22:37:34] <steveire_>	I have Qt 4.5 4.6 and 4.7 checkouts.
[22:37:38] <mjansen__>	But i still would like to know if i am the only one that thinks a automated check for missing merges is useful?
[22:37:38] <mpyne>	git-new-workdir isn't even available on my git
[22:37:55] <steveire_>	I had kdepim stable and master checkouts from git too
[22:38:12] <toma>	i think we are finished with this part. 
[22:38:13] <mpyne>	mjansen__: I think it's a good idea, just not sure how feasible.
[22:38:13] <PovAddict>	mjansen__: well, if everyone uses the forward-porting workflow, that comes for free
[22:38:32] <richmoore>	mjansen__: could it be based on the BUG# commit tag perhaps? 
[22:38:32] <steveire_>	PovAddict: It even comes for free if only some of us do
[22:38:33] <mjansen__>	only in theory. we just need one server and a cron job
[22:38:48] <mjansen__>	in an ideal world it would never send a mail
[22:38:51] <steveire_>	It comes for free if some of us merge 4.6 into master as a matter of workflow
[22:38:59] <mpyne>	So "forwardport if feasible, free-for-all if difficult" ok then?
[22:39:00] <steveire_>	Not even everyone needs to do that.
[22:39:06] <PovAddict>	automatically checking for missing backports isn't possible, since software can't figure out whether something is a bugfix that should be in 4.6 or not
[22:39:26] <mjansen__>	i only think about forward porting
[22:39:42] <PovAddict>	then no need for any tool
[22:39:58] <PovAddict>	merge 4.6 into master and you know you have forward-ported everything
[22:40:06] <mjansen__>	yes ... to socially enforce the need to do that
[22:40:27] <mjansen__>	to be reminded if you forgot, didn't know
[22:40:38] <eean>	but yea each repo just needs some people to do that 
[22:40:49] <steveire_>	mjansen__: It's not a huge problem if someone else doesn't do it but I do.
[22:40:51] <mpyne>	So what's next on the agenda?
[22:40:59] <PovAddict>	we don't need everyone to do the merge after every single bugfix...
[22:41:00] <eean>	it should be our preferred method, but backporting shouldn't be discouraged at all
[22:41:04] <mjansen__>	wasn't someone above saying don't do manually what a tool can do?
[22:41:18] <steveire_>	PovAddict: Right. I would even advocate doing such merges rarely
[22:41:23] <mjansen__>	but i guess that means i am the only one
[22:41:41] <mpyne>	Well, not *all* stable branch commits should be forwardported, so be careful with automating that
[22:41:41] <mjansen__>	PovAddict: why?
[22:42:04] <PovAddict>	mpyne: got an example?
[22:42:07] <mjansen__>	why not doing it when you still know what the commit was about?
[22:42:30] <mpyne>	PovAddict: When a bugfix occurs to foo.x.5, but the corresponding code in foo.x+1.0 has been removed completely
[22:42:32] <mpyne>	I WIN :)
[22:42:36] <richmoore>	for example if you can fix something in a different way in the new code
[22:42:43] <PovAddict>	mjansen__: why do you need to know what the commit is about just to do the merge?
[22:42:48] <richmoore>	eg. safe but simple vs fast but complex
[22:42:51] <mjansen__>	if the automatic merge does it wrong?
[22:43:10] <mjansen__>	oh ... did you ever do real merges? I mean the complicated ones
[22:43:21] <mjansen__>	you do need to know
[22:43:33] <mpyne>	I think we all agree that forward porting is a good idea, and that a reminder tool would be nice in support of that.
[22:43:34] <PovAddict>	if you merge early and often, you don't get complicated merges
[22:43:41] <mjansen__>	i do merging for a living. 
[22:43:49] <mpyne>	I think we also all agree that git can aid that process significantly if someone does happen to forget.
[22:43:59] <mpyne>	So is there much more to discuss on this topic really?
[22:44:01] <mjansen__>	PovAddict: you do. consider refactoring, astyle, file moving
[22:44:28] <mpyne>	If not, I'd like to move on to bugfix integration in the agenda
[22:44:36] <PovAddict>	ok
[22:44:41] <mpyne>	sorry, handling trivial changes
[22:44:48] <mpyne>	we're already talking about bugfixes :)
[22:44:55] <mpyne>	options seemed to be
[22:44:58] <PovAddict>	trivial changes like what?
[22:45:04] <toma>	still talking about this ?
[22:45:06] <toma>	god...
[22:45:15] <mpyne>	PovAddict: e.g. this button's slot wasn't connected.
[22:45:20] <mpyne>	Add very simple feature foo, etc.
[22:45:27] <PovAddict>	I just go and push it, I don't see what the problem is here :)
[22:45:31] <mpyne>	I agree.
[22:45:39] <mpyne>	Were there any other thoughts regarding that?
[22:45:52] <mpyne>	e.g. reasons to require it to be done in a branch and then integrated somehow?
[22:45:53] <argonel>	there might have been some question as to whether reviewboard was necessary there
[22:46:15] <PovAddict>	I think this is pretty simple
[22:46:26] <mpyne>	Good point. I think our existing social policies on that should still apply, but there's no reason not to detail that in the proposed workflow documentation
[22:46:36] <PovAddict>	if you do it in a branch and immediately integrate it, it's pointless; just do it directly in master
[22:46:48] <mpyne>	e.g. don't merge trivial anything to kdepim if you're not a kdepim dev, at least send an email or review request first, etc.
[22:46:53] <PovAddict>	if you don't immediately integrate it (because you need to ask for pre-review), then that's not a trivial change :)
[22:47:41] <mpyne>	The devs for most KDE code don't mind trivial improvements from what I can tell, kdepim is the only difference I've heard of and even that I've never run across myself
[22:48:18] <mpyne>	OK, so * integrate straight into master, make review requests as normal from before
[22:48:20] <PovAddict>	hm, so this is about trivial changes from people outside the project?
[22:48:31] <mpyne>	Maybe? :)
[22:48:35] <PovAddict>	a branch may be useful for that
[22:48:39] <mpyne>	The wiki agenda is kind of sparse
[22:48:47] <PovAddict>	push to branch, then someone who *is* part of the project can review and merge
[22:48:50] <steveire_>	How is kdepim different?
[22:48:57] <PovAddict>	much more easily than would be done in SVN
[22:49:10] <jlayt>	so long as trivial excludes any api/bic changes, i usually don't mind, but a cc is polite
[22:49:17] <mpyne>	steveire_: Last I'd heard it was a bad idea to start touching stuff in there without so much as a courtesy email
[22:49:18] <argonel>	i have to leave, have a good night everyone :)
[22:49:24] <mpyne>	argonel: good night
[22:49:30] <steveire_>	I've never been told that :)
[22:49:50] <mpyne>	Anyways, let's take it for granted that new contributors won't be able to directly merge to master anyways, but can work on personal clones
[22:50:04] <mpyne>	Or at least that's what I seem to remember of the capabilities with the new identity.kde.org
[22:50:23] <toma>	if it is a trivial change everyone should push directly
[22:50:23] <mpyne>	So they'd have to either submit patches for review or have a pull request from their personal clone anyways
[22:50:31] <mpyne>	OK, sounds good
[22:50:38] <mpyne>	Next up is
[22:50:46] <PovAddict>	erm hold on
[22:50:48] <PovAddict>	[19:49] <mpyne> Anyways, let's take it for granted that new contributors won't be able to directly merge to master anyways, but can work on personal clones
[22:50:51] <toma>	the fact that you have a git account that can do that means you can fix trivial stuff
[22:51:00] <PovAddict>	that's not how it works
[22:51:18] <PovAddict>	you either have a developer account, and you can push to any main repo, or you don't, and you can't push anywhere in git
[22:51:19] <mpyne>	Anyone with a KDE identity can merge? Or not everyone can make personal clones?
[22:51:23] <mpyne>	ok.
[22:51:25] 	 * notmart would like it'll continue to not b how iy works
[22:51:37] <PovAddict>	I think that's up for discussion though
[22:51:40] <mpyne>	I'll refer back to toma's response then
[22:52:06] <PovAddict>	it has been suggested that people should be able to get access to personal clones without access to main repos
[22:52:10] <mpyne>	If you have a git account we trust you to be able to handle trivial changes
[22:52:23] <PovAddict>	so that new contributors can use a personal clone instead of mailing patches to a mailing list, until they get full git access
[22:52:32] <mpyne>	OK, but that's only peripherally associated with our workflow I think.
[22:52:59] <mpyne>	The basic idea for new contributors is to get the new code to us somehow, we're not typically too picky as to how they do it.
[22:53:33] <mpyne>	So if sysadmin wants to work on getting personal clones for those with an identity but no dev access that's great, but I don't think it would be an action item from this meeting
[22:53:44] <PovAddict>	fair enough
[22:53:50] <mpyne>	ok
[22:54:08] <mpyne>	Next up (if there's nothing else) is whether there are any common tasks we should document recipes for
[22:54:17] <PovAddict>	definitely
[22:54:21] <mpyne>	e.g. a bunch of "lessons learned" or do/don'ts
[22:54:30] <mpyne>	OK, so that's settled then! ;)
[22:54:50] <PovAddict>	we surely need documentation
[22:54:56] <mpyne>	We're all agreed on that.
[22:55:04] <jlayt>	but not as detailed as teh cmake doco :-)
[22:55:09] <PovAddict>	we need to get some people to pledge to help, though
[22:55:58] <mpyne>	How do we collate the "little recipes" then (assuming we have someone who will type up the docs)
[22:56:08] <mpyne>	email all to the person, or ask for the wiki to be updated directly?
[22:56:26] <mpyne>	I suppose the answer as always would be 'both'
[22:56:36] <jlayt>	if git experts write the correct recipes, I'm happy to try make them more non-expert friendly
[22:56:44] <mpyne>	Awesome
[22:57:07] <mpyne>	Do we have any volunteers for typing up a Wiki workflow based on the results of the meeting?
[22:57:30] <jlayt>	purely out of self interest in having somethign easy to follow :-)
[22:57:31] <mpyne>	I might be able to help this next weekend or possibly on Wednesday/Friday
[22:58:08] <mpyne>	ok.
[22:58:23] <mpyne>	jlayt: Have you pretty much been here throughout for the meeting?
[22:58:47] <jlayt>	yep, reading if not always understanding
[22:58:49] <PovAddict>	what to do about large binaries, such as artwork?
[22:58:59] <mpyne>	Great question
[22:59:02] <PovAddict>	some people said they should stay in SVN, not migrated to git
[22:59:09] 	 * Uninstall is back
[22:59:15] <PovAddict>	some sysadmins said SVN will not be around forever
[22:59:19] <mpyne>	And yet there's been talk of SVN really going away after all
[22:59:45] <mpyne>	I know there is work out there to make git support large binaries a bit better than it does now.
[23:00:00] <mpyne>	Because git modifications sent directly to the git mailing list, to frontends to git.
[23:00:07] <PovAddict>	IMO SVN should stay alive
[23:00:13] <jlayt>	still l10n to solve, and what about the svn history not migrated that we assumed would always be found there
[23:00:14] <mpyne>	Hopefully if we do get rid of SVN git will have adequate support.
[23:00:32] <mpyne>	jlayt: Well SVN history sucks anyways if you're referring to the CVS history that got converted :)
[23:00:32] <Uninstall>	I think we should continue to use SVN until git developer will solve the problem
[23:00:33] <aseigo>	sorry... furniture pick up
[23:00:35] <PovAddict>	but I'm not part of the sysadmins keeping it alive, so...
[23:00:39] <aseigo>	where are we?
[23:00:41] <aseigo>	:)
[23:00:59] <mpyne>	aseigo: I think we've cleared up through "common tasks with recipes"
[23:00:59] <richmoore>	You are in a bunch of caves all alike
[23:01:05] 	 * aseigo has a yet again emptier house ... erf.
[23:01:12] <aseigo>	richmoore: haha. is there a door to the east?
[23:01:15] <mpyne>	Now we're discussing the quite important topic of large binaries and eventual SVN status
[23:01:16] <aseigo>	E
[23:01:27] <aseigo>	awesome, you guys rock.
[23:01:44] <aseigo>	have we put together a list yet of pages on techbase that need to be moved / updated / re-written?
[23:01:49] <mpyne>	Nope
[23:01:50] <toma>	PovAddict: i feel svn should be gone asap. maintaining dual stack is a pita. we have choosen for git, deal with it.
[23:02:09] 	 * aseigo plans to use that for a publicized "git wiki day" on irc
[23:02:16] <richmoore>	iirc the big arguement there was from the i18n teams
[23:02:22] <steveire_>	git people know about the binaries issue. hg people have solved the problem, so I'm sure git will too: http://thread.gmane.org/gmane.comp.version-control.git/165389
[23:02:27] <mpyne>	With /that/ said, my understanding was l10n was continue to be developed from SVN.
[23:02:34] <aseigo>	richmoore: yeah, i think we can move them over once everything is in git and things settle out.
[23:02:41] <mpyne>	Possibly l10n could help with the sysadmin workload on that?
[23:02:56] <toma>	richmoore: it's a matter of time before a l10n team starts wondering if they can move too
[23:03:06] <toma>	richmoore: want to support that too ?
[23:03:14] <mpyne>	Either way hopefully there will be decent support in git for large binaries before that becomes an issue.
[23:03:20] <richmoore>	toma: i'd support them moving (dual stack is daft)
[23:03:36] <richmoore>	toma: the only question is what they need in terms help/tools to make it possible
[23:03:44] <toma>	exactly
[23:03:44] <Uninstall>	mpyne, exactly, so in the meantime I would like to restore wallpapers back to SVN
[23:03:46] <mpyne>	I mean someone even threw out the "tarball" idea on a mailing list, which gives me pause. :)
[23:03:58] <toma>	richmoore: leaving them behind is really leaving them behind
[23:04:16] <PovAddict>	I think we should use the right tool for the job, and git is not the right tool for eg. Oxygen icons
[23:04:16] <Uninstall>	no, please, no tarballs
[23:04:33] <mpyne>	Let's bring back CVS! ;)
[23:04:39] <Uninstall>	SVN is ok for me and nuno
[23:04:47] <toma>	mpyne: i was just emphasizing the problem there, as the thread did not get any attention it deserved
[23:04:50] <bcooksley>	we still have the CVS repo around on the server btw....
[23:05:14] <steveire_>	Are we close to wrapping up the meeting? I don't see anything in the notes about rebase-vs-merge for longish lived feature branches
[23:05:14] <mpyne>	toma: fair enough.
[23:05:56] <toma>	so conclusion: stick it back in svn and wait until git finds a solution?
[23:06:06] <richmoore>	if we can document their workflow then we can probably have a juniour job to develop a tool for it
[23:06:15] <mpyne>	Has to go somewhere, and current git sucks, so I think that's the least of all evils
[23:06:18] <Uninstall>	toma, exactly
[23:06:31] <mpyne>	With the understanding that svn will die someday
[23:06:34] <toma>	any objections to my proposal ?
[23:06:38] <Uninstall>	no
[23:06:49] <toma>	ok, now we need to decide the place
[23:07:07] <mpyne>	kdebase-wallpapers ?
[23:07:14] <mpyne>	or kdeworkspace-wallpapers maybe
[23:07:29] <toma>	mpyne: that's /trunk/KDE/kdebase-wallpapers? 
[23:07:37] <Uninstall>	toma, yes
[23:08:18] <mpyne>	Also yes, it's part of the SC
[23:08:27] <toma>	everyone asleep ?
[23:08:42] <mpyne>	Everyone's "give a shit" is zero, or they agree, or they're asleep
[23:08:50] <mpyne>	I won't waste time trying to figure out which is which :)
[23:08:55] 	 * jlayt has no irons in this fire
[23:09:08] <toma>	jsut common sense is fine
[23:09:11] <Uninstall>	I would like to underline that they are part of kdebase
[23:09:21] <mpyne>	base or workspace?
[23:09:26] <Uninstall>	and they must installed with kde-workspace
[23:09:31] <mpyne>	even in svn kdebase was not just kdebase
[23:09:35] <mpyne>	ok
[23:09:42] <Uninstall>	they've been in kdebase/workspace/wallpapers
[23:09:43] <rakuco>	hmm. huge backlog
[23:09:44] <richmoore>	workspace, runtime will work without them
[23:09:47] <toma>	i bet from a packaging pov this sucks
[23:09:57] <mpyne>	so I think kdeworkspace-wallpapers is most descriptive then
[23:10:15] <Uninstall>	richmoore, the default wallpaper is hard coded in kdelibs, so technically they are runtime ;)
[23:10:30] <mpyne>	It would still work though, it would just look ugly :)
[23:10:40] <toma>	maybe just /trunk/KDE/wallpapers
[23:10:57] <richmoore>	Uninstall: hmm i doubt that would get triggered if we're running a single app under a different DE :-)
[23:11:04] <mpyne>	Anyways, quick reminder to those who are here participating who haven't already documented their attendance to please do so in http://community.kde.org/20110213_GitWorkflowAgenda#Attendees
[23:11:24] <mpyne>	toma: Honestly I don't think people will have any great objection to damn near whatever you name it.
[23:11:46] <PovAddict>	is the name between () the irc nickname or i.k.o name?
[23:12:01] <toma>	mpyne: yeah, just want to make sure nobody goes yelling at me when I commit
[23:12:10] <steveire_>	PovAddict: I don't tihnk it matters :)
[23:12:13] <toma>	evryone had a chance to speak up now
[23:12:15] <mpyne>	he who commits decides, etc etc. ;)
[23:12:17] <toma>	so, let's move on
[23:12:22] <toma>	it's a wrap ?
[23:12:36] <mpyne>	yup
[23:12:44] <mpyne>	aseigo: Did you want to resume chairing, or?
[23:13:16] <mpyne>	If not, I'd like to skip to Commit template in case we have to adjourn early
[23:13:31] <rakuco>	are the minutes up-to-date?
[23:13:41] <toma>	next time we might want to adapt fedora's method of meetings maybe. 
[23:13:43] <mpyne>	rakuco: I don't even know who's keeping them up to date...
[23:13:54] <toma>	seemed efficient to me 
[23:14:09] <mpyne>	ok. You'll have to let me in on the fedora secret later, or I can look it up I suppose.
[23:14:12] <Uninstall>	toma, do I need to get my karma fixed?
[23:14:31] <toma>	?
[23:14:44] <mpyne>	Commit templates for those who don't know, are adjustable ways of tweaking the template that shows up when you run git-commit. Apparently they can be set per-repo
[23:14:55] <mpyne>	An example template was given on kde-scm-interest IIRC.
[23:15:10] <PovAddict>	to remind people of tags like BUG?
[23:15:11] <Uninstall>	toma, can I commit back wallpapers to trunk/KDE/kde-workspacewallpapers without any change to my permissions?
[23:15:19] <mpyne>	PovAddict: Exactly.
[23:15:34] <toma>	Uninstall: let me lift the restrictions
[23:15:40] <Uninstall>	ok
[23:15:46] <mpyne>	And to remind that the first line should be 65-chars or less if possible, there should be a completely blank second line, etc.
[23:15:51] 	 * khindenburg always forgets the fixed-in one
[23:15:52] <Uninstall>	toma, thanks :)
[23:15:53] <PovAddict>	Uninstall: make sure you do a svn copy, not just a file addition
[23:16:12] <aseigo>	mpyne: continue :)
[23:16:17] <mpyne>	aseigo: ok
[23:16:28] <Uninstall>	PovAddict, why?
[23:16:35] <mpyne>	Does anyone know where the example template went to? I can't find mine. :)
[23:16:53] <jlayt>	i posted it to k-c-d, then there were a couple of updates
[23:16:55] <PovAddict>	Uninstall: so that you can follow history from the new location
[23:17:16] <Uninstall>	PovAddict, ok
[23:17:24] <toma>	Uninstall: done
[23:17:56] <steveire_>	http://thread.gmane.org/gmane.comp.kde.devel.core/68626/focus=68695
[23:18:06] <mpyne>	steveire_: thanks
[23:19:11] <mpyne>	So everyone can take a look at the template. (http://thread.gmane.org/gmane.comp.kde.devel.core/68626/focus=68695)
[23:19:41] <mpyne>	Are there any major objections to using this as the template for KDE SC modules in general?
[23:19:49] <mpyne>	Or something substantially similar to this
[23:20:01] <mpyne>	We can fine-tune the wording if need be
[23:20:07] <mpyne>	brb
[23:20:14] <mjansen__>	Question is how we distribute it
[23:20:53] <mjansen__>	the easiest possibility for distribution would be to add it to every repo. but not the easiest to keep in sync
[23:20:55] <khindenburg>	I like the longer one w/ the keywords
[23:21:23] <PovAddict>	mjansen__: I'm not sure if they come with clones
[23:21:45] <mpyne>	Well they can be git-added just like everything else, no?
[23:21:51] <PovAddict>	ah
[23:21:56] <PovAddict>	I thought it was some special file inside .git
[23:21:57] <mpyne>	I mean projects already distribute .gitignores that way, right.
[23:21:57] <mjansen__>	they can. do we want that?
[23:22:09] <PovAddict>	not a normal file in the repo contents
[23:22:29] <mjansen__>	with build-tool/kdesrc-build we can add it after cloning but the other devs
[23:22:59] <mjansen__>	need a easy way to get them too. especially if the version is adapted for some projects and not the same everywhere
[23:23:01] <mpyne>	It seems to require alterations in .git/config though
[23:23:29] <mjansen__>	getting the file is the first step to activate it. if you never see it ...
[23:23:45] <mpyne>	right
[23:24:33] <mjansen__>	so i would propose we make it a recommended practice to add the template in the repos
[23:24:56] <mpyne>	I agree, if only because there's no way to force git to pick it up or even use it.
[23:25:08] <mpyne>	And it's no big deal if it's not used either!
[23:25:53] <mpyne>	That meshes well with "recommended git config settings"
[23:26:00] <mjansen__>	i guess you will spew out the required perl code to activate it if present 
[23:26:00] <mpyne>	We already know about the kde: trick I think
[23:26:11] <jlayt>	there's a "git-config set" command to set the template, just like setting your name and email, so make it part of the starting out techbase recipe
[23:26:24] <mpyne>	mjansen__: Maybe, maybe not. I'll do it if people want it but it's just more work for me otherwise. ;)
[23:26:42] <mpyne>	jlayt: good idea
[23:26:54] <mjansen__>	for me it's the next step. setting username, email, and other config options
[23:26:57] <mpyne>	Are there any other git-config settings we should recommend then?
[23:27:32] <mpyne>	username and email are essentially required, we'll push kde: prefix hard for git, and now we have a good template
[23:27:52] <mpyne>	Sounds like a "none additional"
[23:28:02] <mjansen__>	everytime i open notes i am informed they were already migrated.
[23:28:06] <mjansen__>	color.ui: true
[23:28:14] <jlayt>	any convenience alises like the vlc wiki does?
[23:28:19] <mjansen__>	push.default: tracking
[23:28:28] <mjansen__>	courtesy of thiago
[23:28:29] <mpyne>	I have a bash alias for shifting sourcedir/builddir
[23:28:33] <mpyne>	beyond that, not really
[23:28:52] <mpyne>	push.default tracking is probably a good idea
[23:29:09] <mpyne>	that's the one that avoids pushing all local refs to remote on a "git push", right?
[23:29:33] <mjansen__>	that pushes by default to the remote branch your local branch is tracking
[23:29:37] <mpyne>	ok
[23:29:41] <PovAddict>	when I first got an account, I set push.default to 'none' so that 'git push' gives an error if I don't tell it exactly what branch to push
[23:29:43] <mjansen__>	not to the remote branch with the same name
[23:29:59] <mpyne>	None might actually be better for that reason.
[23:30:13] <mpyne>	I dread the day when someone accidentally pushes their 40 local branches to a kde repo ;)
[23:30:31] <mpyne>	So let's add on a push.default recommendation
[23:30:40] <mpyne>	question is just, "none or tracking"?
[23:31:00] <mjansen__>	tracking
[23:31:24] <jlayt>	unless people always match the local branch name to teh tracking branch name None sounds better
[23:31:45] <PovAddict>	did we decide on KDE/4.6 vs 4.6?
[23:31:48] <jlayt>	err, tahat snot right :-)
[23:31:50] <mpyne>	That will take us to a question about naming conventions...
[23:31:53] <mpyne>	PovAddict: Exactly
[23:32:08] 	 * jlayt getting tired
[23:32:09] <mpyne>	Given that, I think "none" is probably the safest default choice
[23:32:18] <steveire_>	me too.
[23:32:45] <steveire_>	I'm going to head off. I don't tihnk the docs issue can be solved until the merge-v-rebase issue is
[23:32:50] <mpyne>	OK
[23:32:55] <mjansen__>	mpyne: you dread --all nothing that options can do against that
[23:33:11] <mpyne>	I dread "git push origin" to be specific
[23:33:38] <mpyne>	Which IIRC with the default push.default pushes all branches or something like that.
[23:33:59] <mpyne>	No, all matching branches
[23:34:05] <mpyne>	but still more than 1 possibly :)
[23:34:18] <Uninstall>	mpyne, is that a bad thing?
[23:34:33] <mpyne>	Uninstall: for me the first time I tried it, it actually almost was
[23:34:42] <Uninstall>	mpyne, what happened?
[23:34:43] <mpyne>	I thought I was pushing the branch I had checked out
[23:34:50] <mpyne>	You guys saw "xml-support" :P
[23:35:29] <mpyne>	Either way though, we're all able to set our own more-superior tracking settings if it comes to that, and that's fine.
[23:35:35] <jlayt>	recipes should also not give the short-hand default versions, give the full version, let them learn the quick way once they understand better, i.e. git push origin KDE/4.6:KDE/4.6
[23:36:08] <mpyne>	I do think default settings should require more typing if only for clarity and being independent of end-users local settings
[23:36:29] <mpyne>	Did we want to take up naming convention for release branches then?
[23:36:39] <mpyne>	Obvious choices are 4.x or KDE/4.x
[23:37:37] <jlayt>	well, 4.x is quicker, but if we have feature brances in the same repo would KDE/4.x make it clearer they are formal branches?
[23:37:46] <mpyne>	btw, is everyone ok with finishing up in about 23 minutes or so, with the possibility of a follow-up meeting next week?
[23:37:59] <Uninstall>	yes
[23:38:03] <mpyne>	OK
[23:38:09] 	 * jlayt lifts head off keyboard to nod agreement
[23:38:12] <mpyne>	lol
[23:38:37] <mpyne>	KDE/4.x makes it more difficult for my current kdesrc-build, but dfaure has ideas on how to fix that anyways
[23:38:50] <mpyne>	(and it's a minor thing besides with module-sets)
[23:39:10] <mpyne>	So let's rephrase then, are there any problems with using KDE/4.x besides extra typing?
[23:39:16] <jlayt>	talking to packagers at fosdem, they don't care so long as it's consistent across all of kde
[23:39:20] <PovAddict>	yes
[23:39:29] <PovAddict>	local branches are usually called 4.x, not KDE/4.x
[23:39:46] <mpyne>	I actually just did that style checkout today ;)
[23:39:49] <PovAddict>	so when git is configured to push to matching-name branches, that ends up with devs accidentally creating new 4.x branches
[23:39:59] <PovAddict>	in the server
[23:40:00] <PovAddict>	next to the KDE/4.x branches
[23:40:00] <mpyne>	I can see how that would interfere with some push.default settings to have different names
[23:40:55] <mpyne>	So would it work to have the server-side hook forbid 4.x branch naming for the KDE SC/Platform modules? Is that even a good idea?
[23:41:14] <PovAddict>	if we end up choosing KDE/4.x, it would be a good idea to forbid creation of 4.x on the server, yes
[23:41:35] <PovAddict>	and viceversa, I guess
[23:42:01] <mpyne>	Yeah, it seems that either way we need to ensure we're consistent, if only for the packagers' sake
[23:42:23] <mpyne>	Do any of the sysadmin types know if the pre-commit hooks can check for that easily?
[23:42:29] <mpyne>	Would doing that be a big burden?
[23:42:39] <Sho_>	mpyne: it's trivial.
[23:42:43] <mpyne>	ok
[23:43:03] <Sho_>	we can set any sort of right based on regular expressions against the ref name
[23:43:22] <mpyne>	So how about we got for KDE/4.x with a pre-commit hook to forbid ^4.\d ?
[23:43:23] <Sho_>	for individuals and groups of people
[23:43:42] <PovAddict>	what's your argument for KDE/4.x instead of 4.x?
[23:43:47] <Sho_>	hm I heavily dislike the KDE/ prefix, I thought we already had consensus on dropping it
[23:43:51] <mpyne>	a) We're already using it.
[23:43:55] <Sho_>	no we're not
[23:44:06] <Sho_>	kdepim* was first and didn't use it
[23:44:06] <mpyne>	I could have *sworn* that earlier today it was KDE/foo
[23:44:14] <jlayt>	we're using both
[23:44:14] <PovAddict>	mpyne: it's currently an inconsistent mess
[23:44:16] <Uninstall>	I like KDE/ prefix
[23:44:19] <PovAddict>	some repos use one, some repos use the other
[23:44:19] <Sho_>	kdelibs and workspade/runtime deviated what was already there
[23:44:22] <mpyne>	Beyond that I have no strong opinions
[23:44:31] <Sho_>	in parlance, we also always talk about "the x.y branch"
[23:44:32] <mpyne>	I will admit I like the prefix
[23:44:32] <PovAddict>	so we'll need to fix existing repos anyway
[23:44:50] <mpyne>	even if it's more work for me in kdesrc-build
[23:44:57] <mpyne>	but beyond that I could hard carely less
[23:44:58] <Uninstall>	It underlines that is *the branch* of a stable release
[23:45:04] <mpyne>	um, hardly care,
[23:45:17] <jlayt>	it becomes related to the naming scheme, if 4.x on it's own is clear as being a release branch as opposed to a feature branch
[23:45:52] <mpyne>	Even with that it should be "obviously apparent" that KDE/4.x is at least as "official" FWIW
[23:46:02] <PovAddict>	if anyone calls his feature branch 4.7 today, we have reasons to shoot him
[23:46:05] <mpyne>	But at the end of the day we'll make a choice, document it, that will be that, etc.
[23:46:32] <mpyne>	We can make the branches as official as we want them to be.
[23:46:40] <PovAddict>	"let's just flip a coin... if it turns out to be a wrong choice, we'd rather hate a quarter than ourselves"
[23:46:47] <jlayt>	lol
[23:46:48] <mpyne>	(Although that's another good question, should we forbid the ^KDE/ prefix from the proles? ;)
[23:46:53] <Sho_>	PovAddict: heh
[23:47:05] <mpyne>	I'll actually do that if people are ok with that. lol
[23:47:18] <aseigo>	mpyne: yes iho
[23:47:20] <aseigo>	er, imho
[23:47:29] <PovAddict>	hm good point
[23:47:59] <mpyne>	ok
[23:48:02] <PovAddict>	I think whatever we choose, we shouldn't only forbid any push to the other name, but also forbid creation of the rightly-named version branches except from people who are supposed to do that kind of thing (release team? or who?)
[23:48:15] <mpyne>	Let's coin flip first. :)
[23:48:37] <mpyne>	The coin is a Navy command coin since I have no change available.
[23:48:47] <mpyne>	Tails is "Fighting Mary"
[23:48:50] <mpyne>	Heads is the ship emblem
[23:48:53] <aseigo>	mpyne: so both sides are "heads" and the head is a picture of the sub commander? ;)
[23:48:55] <mpyne>	Who wants to call it? Uninstall
[23:49:00] <mpyne>	?
[23:49:04] <PovAddict>	o_o
[23:49:11] <mpyne>	aseigo: lol, no
[23:49:31] <mpyne>	OK, Uninstall took to long
[23:49:34] <Uninstall>	mpyne, you mean KDE/4.6?
[23:49:37] <aseigo>	HEADS!
[23:49:41] <mpyne>	yes
[23:49:51] <Uninstall>	yes, I like KDE/4.6
[23:49:53] <PovAddict>	aseigo: do you have an opinion on the naming scheme, to avoid having to use the coin?
[23:50:00] <aseigo>	i like the KDE/4.6 tbh
[23:50:10] <aseigo>	it takes a moment to get used to, but then it makes it very, very clear that these are "official"
[23:50:19] <aseigo>	and in a git branch -r it makes it really easy to grep for them
[23:50:22] <aseigo>	and they are grouped together
[23:50:24] <mpyne>	aseigo: So to be clear, you've called HEADS, if it lands HEADS you want KDE/Foo?
[23:50:51] <aseigo>	we just need to kindly bitchslap people who get it wrong and create a local "4.7" and push it. like i did the other week. :P
[23:51:08] <mpyne>	it will be a precommit bitchslap, we just need a decision
[23:51:10] <aseigo>	mpyne: yes, unless i was just persuasive enough to remove the need for the cointoss :)
[23:51:24] <mpyne>	"Fighting Mary"
[23:51:27] <mpyne>	Tails
[23:51:29] <mpyne>	4.x
[23:51:31] <PovAddict>	aseigo: no need to bitchslap, sysadmins have said they can technically forbid using the wrong name
[23:51:35] <mpyne>	brb
[23:51:45] <bcooksley>	yes, then the hooks give a scary message like
[23:51:48] 	 * aseigo still thinks KDE/foo is better for the grouping/grepping reason
[23:51:58] <bcooksley>	"Push declined - attempted repository integrity violation"
[23:52:38] <aseigo>	bcooksley: if it can also say what integretry violation happened that'd make it pure gold
[23:53:31] 	 * aseigo suggests we move to the "action items" portion of the meeting if that's settled
[23:53:35] <bcooksley>	aseigo: a message usually comes before that message, that is just being explicit at what is happening
[23:53:36] <bcooksley>	ie
[23:53:40] <mpyne>	aseigo: I think so too, but the good ship Maryland has spoken
[23:54:02] <bcooksley>	"Creation of release branches is restricted to the KDE Release Team"
[23:54:16] <bcooksley>	"Push declined - attempted repository integrity violation"
[23:54:17] <Uninstall>	aseigo, wilder pushed today 4.6 ;)
[23:54:28] <mpyne>	aseigo: Now's probably a good time to recruit volunteers to type up the meeting report
[23:54:44] <aseigo>	bcooksley: _awesome_. have i mentioned you guys rock yet today? :)
[23:55:11] <bcooksley>	aseigo: note that it isn't actually implemented yet ;) just proposed messages. thx anyway :)
[23:55:26] <aseigo>	mpyne: yep.. meeting report. and a "Schedule, publicize and host an IRC day to push the results into documentation on techbase (aseigo)"
[23:56:06] <aseigo>	any other action items?
[23:56:23] <aseigo>	and who wants to put together the report for k-c-d from http://titanpad.com/SnJwFW2iXL?
[23:56:28] <aseigo>	and is http://titanpad.com/SnJwFW2iXL up to date? seems not?
[23:56:28] <mpyne>	I skipped some bullet items like identifying pages that need updated on techbase
[23:56:40] <mpyne>	And using content from the g.ko manual
[23:56:44] <PovAddict>	aseigo: eean was working on it, and he went afk
[23:56:50] <mpyne>	aseigo: I haven't even touched that titanpad link
[23:57:05] <mpyne>	I should at least have the full backlog
[23:57:21] <aseigo>	ok... i _have_ to go now unfortunately, otherwise i'd help with that. can someone please do so?
[23:57:34] 	 * aseigo uses the whole lame "moving house" excuse again for that :)
[23:57:48] <mpyne>	updating titanpad?
[23:57:52] <jlayt>	i'll try update from backlog in morning, it's almost am here
[23:58:07] <mpyne>	jlayt: OK, awesome.
[23:58:23] <aseigo>	jlayt: dude! :) thanks...
[23:58:25] <mpyne>	It's times like these I wish I had the internet at work for when I was doing nothing :-/
[23:58:33] <aseigo>	mpyne: :)
[23:58:49] 	 * jlayt reserves right to re-flip coin for best-of-3 :-)
[23:58:49] <mpyne>	gotta go again, bbiab
[23:59:03] <jlayt>	laters
[00:02:51] <mpyne>	alright, back
[00:03:08] <mpyne>	In case it wasn't too clear earlier that should just about officially adjourn the meeting for today
[00:03:52] <mpyne>	I'll nominate aseigo to send out a meeting request for part two if he desires, as for myself I'm pretty comfortable we worked through the major points, with the exception of merge/rebase based on commit mails
[00:04:09] <mpyne>	So keep that in mind as an agenda point if we do this again next week.
[00:05:30] <aseigo>	mpyne: fair 'nuff. plop that as an action item
[00:05:36] <aseigo>	jlayt: ^-----
[00:06:29] <PovAddict>	btw, I'd like to declare the kdeedu migration delayed
[00:07:14] <PovAddict>	apart from some known issues in the conversion that should be fixed anyway, the fact that SVN will eventually disappear puts higher standards on how accurate the git history should be
[00:07:23] <mpyne>	Indeed
[00:07:40] <mpyne>	The git kdesrc-build history is far more accurate than svn was, but that came at a lot of time-consuming cost.
[00:07:43] <PovAddict>	so I'd like to convert some KDE-wide feature branches, such as kaction-cleanup-branch
[00:07:49] <mpyne>	Which would inevitably be much larger in kdeedu
[00:08:39] <Sho_>	PovAddict: "the fact that SVN will eventually disappear"?
[00:09:16] <PovAddict>	Sho_: toma said he won't maintain *both* SVN and git servers forever; I don't know if that's his opinion or an official KDE Sysadmin statement
[00:10:02] <Sho_>	PovAddict: afaik the endgame is to put it in read-only mode and keep that up indefinitely
[00:10:23] <mpyne>	So the same result either way
[00:10:43] <mpyne>	e.g. does anyone even know that webcvs doesn't work? ;)
[00:10:53] <mpyne>	No one will check the old repo unless it's absolutely necessary.
[00:11:26] <Sho_>	I don't disagree that the history conversions should be accurate mind you
[00:11:30] <PovAddict>	well, for the question of whether to keep artwork in SVN or move it to git, getting rid of SVN and making SVN readonly give the same result: artwork has to move to git
[00:12:08] <PovAddict>	but if SVN will not be available even readonly, that means we should put a *lot* more care to making git history accurate
[00:12:55] <PovAddict>	btw the kde-wide feature branches I found are: kaction-cleanup-branch, kconfiggroup_port, kinstance-redesign
[00:39:26] <rakuco>	were there any discussions about people merging their own changes to master instead of rebasing them before committing? for example, someone makes one commit locally, then merges origin/master, then pushes instead of fetching origin, rebasing origin/master and then pushing
[00:40:03] <eean>	rakuco: not really, since the answer seems clear
[00:40:49] <mpyne>	answer seemed to be that we need to use merges based on the commit mails alone, but there was some debate on that as well
[00:42:11] <mpyne>	Good points were brought up that the commit history could be made prettier by using rebase (both because there's no merge commit, and because each individual commit could be made more "purposeful"), but I'm not sure that that is a good technical (as opposed to aesthetic) reason
[00:42:15] <PovAddict>	for local changes you haven't pushed yet, rebasing is ok
[00:42:45] <PovAddict>	the problem is with feature branches, you can't rebase it with master daily and push that...
[00:43:08] <mpyne>	right
[00:43:27] <mpyne>	and if you don't ever rebase until right near then end, then it's very easy to get the Mother of All Merge Conflicts
[00:45:33] <rakuco>	in this case I was specifically talking about people making ~1-3 commits and then merging master into their master instead of rebasing and pushing. it just makes history uglier
[00:45:59] <PovAddict>	rebasing is fine for that
[00:47:11] <PovAddict>	in either case you need to know what you're doing... :)

*** Logfile started
*** on Mon Feb 14 00:56:54 2011

[00:56:54] Topic	The channel topic is "Discussing KDE's switch to git | Today's Workflow Meeting Agenda: http://community.kde.org/20110213_GitWorkflowAgenda | http://titanpad.com/SnJwFW2iXL minutes | http://community.kde.org/Sysadmin/GitKdeOrgManual | https://sysadmin.kde.org/svnaccount/repo-request.php | http://community.kde.org/Sysadmin/DeveloperAccessForRuleWriting | http://projects.kde.org/projects/playground/sdk/kde-rule".
[00:56:54] Topic	The topic was set by eean!~imonroe@amarok/developer/eean on 2011-02-13 20:13.
[00:57:35] Mode	Channel modes: no messages from outside
[00:57:35] Created	This channel was created on 2009-01-26 16:02.
[01:02:20] <eean>	rakuco: nothing kde specific about deciding that people should rebase their local commits and avoid unnecessary merge commits :) that's just general git foo
[01:13:55] <mpyne>	eean: That's very true, but I don't think that's what steveire was talking about ;)
[01:14:12] <mpyne>	Even I recommended rebasing your local commits so that they were intelligible ;)
[01:14:18] <eean>	its what rakuco was talking about though
[01:21:57] <khindenburg>	other than gitk and cola-git, does anyone use another tool?  I didn't care much for cola
[01:23:05] <eean>	never heard of cola-git
[01:23:23] <eean>	khindenburg: qgit is a slower version of gitk (at least, with the way i use gitk)
[01:23:51] <khindenburg>	http://cola.tuxfamily.org/
[01:23:51] <eean>	there's a kde app in development called cacoon I think
[01:24:37] <khindenburg>	is there anything in kdevelop?
[01:24:43] <eean>	yea I think so
[01:25:09] <khindenburg>	I could never get kdevelop to work w/ konsole
[01:26:08] <eean>	huh? 
[01:26:10] <mpyne>	I also have qgit
[01:26:24] <eean>	oh you develop konsole
[01:26:26] <eean>	right :)
[01:27:13] <eean>	kdevelop's cmake support is awfully good, surprised to hear it didn't work with a cmake app
[01:27:22] <eean>	maybe easier now that konsole is by itself
[01:27:51] <khindenburg>	eean: true, might have to try again
[01:37:10] <khindenburg>	hmm, why do my git aliases not work... /sigh
[01:54:30] <khindenburg>	ugh, wtf.. I don't need this crap... http://stackoverflow.com/questions/4019501/git-alias-problem
[01:56:39] <rakuco>	khindenburg: I like tig
[02:01:54] <khindenburg>	well that's an annoying bug in git...  
[02:03:23] <khindenburg>	rakuco: txs, checking it out
[02:24:22] <eean>	heh tig is cool
[02:30:55] <PovAddict>	kdevelop's support for git is underwhelming
[02:36:57] <argonel>	so what color did we pick? :)
[02:41:49] <khindenburg>	my git diff doesn't seem to handle non-english chars
[02:44:24] <argonel>	you're set to utf8?
[02:45:46] <khindenburg>	konsole is setup to utf-8
[02:46:00] <PovAddict>	khindenburg: what problem did you have with konsole code in kdevelop?
[02:47:11] <khindenburg>	PovAddict: I could never get it to import and compile... though really it isn't compatable  w/ using kdesrc-build
[02:47:53] <PovAddict>	hm
[02:48:27] <PovAddict>	interesting, maybe kdvelop could grow some explicit support for kdesrc-build
[02:48:53] <PovAddict>	kdevelop, too
[02:49:18] <argonel>	i've always had a gui for kdesrc-build in the back of my mind, i don't know that i'd want it in kdevelop though
[02:49:37] <khindenburg>	Sebastian Kühn works pastted  into konsole, but git diff doesn't show it
[02:50:26] <argonel>	khindenburg: does $LANG have a value?
[02:50:47] <khindenburg>	argonel: no
[02:51:39] <argonel>	i don't know how your distro wants those expressed, mine likes LANG=en_US.UTF-8
[02:51:59] <argonel>	`locale` should know, though
[03:09:47] <PovAddict>	argonel: why no kdesrc-build in kdevelop?
[03:10:16] <PovAddict>	there already is / will be a GUI to clone git repos from p.k.o, choosing from a list
[03:14:08] <khindenburg>	argonel: Ok for some reason itwasn't setup on my system - got it now
[03:19:27] <mpyne>	I wish someone would make a good gui for kdesrc-build
[03:19:41] <mpyne>	I had one waaaaaaay back in the day, but it really was just a config file generator
[03:20:49] <PovAddict>	is there kate syntax highlighting for kdesrc-buildrc?
[03:21:25] <mpyne>	Believe it or not, yes
[03:21:29] <mpyne>	Although it's outdated
[03:21:36] <mpyne>	which is really weird, because I always use vim to edit mine
[03:24:33] <PovAddict>	I wrote kate syntax highlighting for svn2git rules, makes them much more readable :)
[03:25:11] <mpyne>	nice
[03:26:42] <khindenburg>	if I push to master, what is the 4.6.0?  master * v4.6.0-32-gacd507e konsole/src/ (5 files):
[03:27:01] <mpyne>	That's the latest tagged commit upstream of your current commit
[03:27:18] <mpyne>	i.e. the baseline for the rest of that version string
[03:27:36] <mpyne>	-32- means there's been 32 commits in the chain from your commit to the tagged one
[03:27:44] <Sho_>	khindenburg: it's output from "git describe"
[03:27:45] <mpyne>	-gFOO is the SHA1 of your new commit
[03:27:51] <khindenburg>	why would it print  that if I'm on master?
[03:27:52] <mpyne>	lol, or that
[03:28:11] <PovAddict>	it means it's commit acd507e, which is the 32nd commit since v4.6.0 was tagged
[03:28:12] <mpyne>	because after the next commit master will be something else
[03:28:26] <Sho_>	khindenburg: because it gives a useful indication of where your commit is in relation to the last tag (if there is one)
[03:28:30] <mpyne>	So just saying "master" isn't very descriptive a few weeks from now for those who want to identify your commit
[03:28:42] <Sho_>	khindenburg: as well as their order if there are multiple commits
[03:28:57] <khindenburg>	ah, ok txs
[03:30:13] <mpyne>	I suppose it's time to merge the xml-support stuff for kdesrc-build to master and see who finds bugs with it ;)
[03:30:24] <PovAddict>	is 4.6 merged into master in the konsole repo?
[03:31:49] <mpyne>	I would like to note for the record that merging instead of rebasing caused only 2 new commits enough there were 21 commits between the old master and the new one ;)
[03:31:50] 	 * PovAddict stabs Andriy
[03:31:54] <mpyne>	s/enough/although/
[03:32:09] <PovAddict>	a commit on master with FIXED-IN: 4.6.1
[03:32:53] <mpyne>	PovAddict: What if he left out the fixed-in on his 4.6 commit? ;)
[03:33:14] <PovAddict>	he hasn't committed to 4.6 (yet)
[03:33:30] <mpyne>	ah
[03:33:31] <khindenburg>	PovAddict: which one are you referring to?
[03:34:37] <khindenburg>	I haven't used FIXED-IN with any git pushes
[03:34:51] <mpyne>	You're also not Andriy ;)
[03:35:34] <khindenburg>	oh,  sorry didn't see change of subject
[03:36:25] <PovAddict>	if I'm complaining about commits, I may change the subject every time CIA announces something in #kde-commits :)
[03:38:04] <PovAddict>	there goes the backport
[03:39:30] <PovAddict>	anyone wants to help get the initial 4.6->master merge done in kdelibs?
[03:40:46] <PovAddict>	I need to make a list of every commit in 4.6 that is a backport from master, and every commit in 4.6 that was forward-ported to master
[03:41:15] <PovAddict>	a long and tedious but highly parallelizable task
[03:41:36] <mpyne>	Well there you go, it's backported for real
[03:41:50] <mpyne>	He even left in the FIXED-IN keyword in case b.k.o didn't like it the first time
[03:42:27] <khindenburg>	that reminds me can you have 2 fixed-in ?  like 4.6.1/4.7 ?
[03:42:54] <PovAddict>	mpyne: yeah, probably a direct cherry-pick
[03:43:24] <PovAddict>	khindenburg: I don't even know what's the consumer of fixed-in
[03:44:10] <mpyne>	khindenburg: No.
[03:44:42] <mpyne>	b.k.o only supports one really. A dual tag like yours might be OK but really all bugfixes are supposed to be forward-ported anyways, right? ;)
[03:44:53] <PovAddict>	is it for changelogs?
[03:44:57] <mpyne>	So in general we use the lowest released version for FIXED-IN.
[03:45:08] <mpyne>	PovAddict: Just for the bug itself for now that way people know what version to test
[03:46:15] <PovAddict>	anyway, just have to get him to commit in 4.6 and merge
[03:58:36] <rakuco>	so the idea after writing down some guidelines is to not have this kind of silly commit workflow anymore, right?
[03:59:44] <PovAddict>	you mean commiting to master and then backporting? that will still *work*, but it'd be discouraged
[04:01:28] <PovAddict>	note that a 'commit on stable and merge to master' workflow isn't possible on many repos yet because they never had such a merge yet, so if you try, you get a zillion conflicts
[04:33:17] <argonel>	PovAddict: not in kdevelop because i don't use it :)
[04:33:54] <PovAddict>	ah ok
[04:34:19] <PovAddict>	I thought you meant kdesrc-build stuff wouldn't belong to kdevelop
[04:34:39] <argonel>	nope. just that if it were part of kdevelop i'd still not have one for kate :)