12:02:42 <Stskeeps> #startmeeting Mer release management/planning 10/1/2012
12:02:42 <MerBot> Meeting started Tue Jan 10 12:02:42 2012 UTC.  The chair is Stskeeps. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings.
12:02:42 <MerBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
12:03:52 <Stskeeps> hi, welcome to release management/planning meeting - the idea is a bit to discuss and to plan some tasks to make mer releases better, our documentation, processes, etc
12:04:00 <Stskeeps> ie, generating 'task' bugs for mer bugzilla :)
12:04:16 <Stskeeps> who's participating?
12:04:24 <phaeron> I'm here
12:04:33 <lbt> me too
12:05:00 <Sage> o/
12:05:05 <Stskeeps> okay, i'll just start with what's on my list already of things we ought to do
12:05:06 <lbt> although I thought it was 1pm my time ... oops
12:05:07 <X-Fade> lurking :)
12:05:18 <Stskeeps> #info kickstarter templates for vendors to derive from (task)
12:05:37 <Stskeeps> we need kickstarter templates that indicate basic settings for mer images, that can be inherited from by vendors
12:05:51 <Stskeeps> so we can add a package or setting in mer core, and their .ks'es will update
12:05:56 <jukkaeklund> lurking..
12:06:09 <lbt> I'm generally working on vendor setup
12:06:13 <Sage> :nod:
12:06:24 <Stskeeps> #link http://meego.gitorious.org/meego-developer-tools/kickstarter/blobs/master/configurations.yaml
12:06:25 <lbt> hence the kernel config and other adaptation mgmt stuff
12:06:39 <Stskeeps> #info Mer IMG setup (task)
12:06:49 <Sage> in Nemo something that would be part of this in Mer are lines 26-32 in https://gitorious.org/meego-developer-edition-for-n900/image-configurations/blobs/master/configs/Nemo/configurations.yaml
12:06:49 <Stskeeps> we need a IMG instance for the process to use to generate images with
12:07:04 <phaeron> what kind of processes are we talking about
12:07:05 <Sage> also maybe something from Default: lines 6-24
12:07:07 <lbt> there's a bug for that already
12:07:18 <phaeron> I started working on IMG again yesterday
12:07:43 <lbt> #info Use  https://bugs.merproject.org/show_bug.cgi?id=88 for IMG setup
12:08:08 <Stskeeps> phaeron: test images for gerrit changes, for instance
12:08:35 <lbt> for which we need a 'reference' kernel
12:08:43 <Stskeeps> not really, -f fs is fine, too
12:09:03 <lbt> mmm
12:09:05 <Sage> no need to boot the image really, we can do chroot test, right?
12:09:16 <lbt> I don't see it
12:09:16 <phaeron> bugs need more descriptions :D
12:09:21 <lbt> systemd bugs?
12:09:49 <lbt> I'd like to do a kvm or qemu reference kernel
12:10:11 <phaeron> but that's outside the scope of the task
12:10:20 <lbt> it is
12:10:28 <phaeron> let's just get the process and image creation sorted out
12:10:35 <Stskeeps> right
12:10:44 <Sage> Ok, so back to the task. What we are after is Mer kickstarter template in this task.
12:10:54 <Stskeeps> yes
12:11:05 <Sage> Template that vendors can take and derive their own configurations from
12:11:07 <Stskeeps> something people can use, instead of looking at other kickstarter templates
12:11:26 <Sage> Template that would update with Mer Core so vendors would get the updates as well.
12:11:37 <Sage> to their configs when they update mer core
12:11:59 <Stskeeps> :nod:
12:12:03 <phaeron> Sage: didn't we decide to have configurations in a separate subproject so it can build against the need :Utils ?
12:12:07 <Sage> Offtopic: Could we allow description modification for bz for some of us?
12:12:17 <lbt> yes please
12:12:36 <Sage> phaeron: different matter
12:12:47 <lbt> phaeron: IMG already has a variety of ways to adapt an image doesn't it
12:13:04 <phaeron> define adapt
12:13:09 <Stskeeps> okay, i'll just move on to my next proposed task., which is quite related
12:13:13 <lbt> that may be worth looking at before the yaml
12:13:23 <Stskeeps> all of this is because i want to have tar.gz releases, of the bare core, as this is something useful for vendors
12:13:27 <lbt> it can specify templates and 'extra' stuff
12:13:34 <Stskeeps> #info tar.gz releases of core per release
12:13:47 <Sage> So this "Mer kickstarter template" if you will, would be mer-kickstarter-core package in mer gitweb that would contain the basic config for kickstarter (?)
12:13:53 <Stskeeps> Sage: right
12:14:01 <phaeron> Stskeeps: yeah that can be done.
12:14:07 <Stskeeps> and
12:14:11 <lbt> which vendors could rebase on top of
12:14:14 <phaeron> but define the trigger of "release"
12:14:22 <phaeron> in the task that is
12:14:23 <Sage> phaeron: so when vendor would build their own configs their config packages would depend on mer-kickstarter-core on build time when they derive their .ks files
12:14:28 <Stskeeps> #info rootfs builds in integration testing/gerrit changes
12:15:06 <phaeron> we don't have OTS yet though
12:15:17 <lbt> that's not a dependency
12:15:23 <Stskeeps> that's OK, we just need basic image build testing
12:15:26 <Stskeeps> at first
12:15:28 <phaeron> ok
12:15:50 <Sage> for this kickstarter template task we need to modify kickstarter a bit as well to allow this kind of behaviour
12:15:58 <Stskeeps> #info build logs in release (already a bug for this)
12:16:47 <Sage> did we change topic? :)
12:16:56 <lbt> OK .. for the IMG process step 1 is 'does it make a rootfs', step 2 is some kind of 'does it boot', step 3 is some kind of 'OTS testing'
12:17:05 <Stskeeps> Sage: no, just posting ideas
12:17:09 <Sage> ok
12:17:13 <Stskeeps> if you get any ideas that need to be done, #info them as well
12:17:33 <lbt> Stskeeps: you have my points from the last couple of days?
12:17:47 <Stskeeps> lbt: from the triages?
12:18:06 <lbt> yes
12:18:16 <Stskeeps> not personally, i was hoping you'd #info them ;)
12:18:22 <lbt> :)
12:18:51 <Stskeeps> #info SB2-OBS integration - within two weeks, we'll likely be switching to be using SB2-OBS for cross compilation
12:19:16 <Stskeeps> #info requires OBS package builds working, ScriptRipper has done git trees for mer OBS integration as wel
12:19:26 <lbt> #info we need Mer package signing
12:19:27 <Stskeeps> #info requires community OBS to support this as well
12:19:51 <lbt> *cough* what community OBS?
12:20:09 <Stskeeps> the one people use currently
12:20:09 <Stskeeps> :P
12:20:34 <Stskeeps> #link http://wiki.merproject.org/wiki/SB2
12:21:53 <lbt> OK
12:22:03 <lbt> that needs some planning
12:22:05 <Stskeeps> yes
12:22:47 <lbt> I am worried about c.obs future
12:23:17 <lbt> but I guess if we document it then we won't lose anything working on it
12:23:24 <lbt> so it's just a task
12:23:28 <Stskeeps> #info Mer Handbook: Make your own Mer image with 'mic'
12:23:49 <Sage> http://pastie.org/3159898 ?
12:23:53 <lbt> ah ... that prompts another one.... MINT
12:24:12 <Stskeeps> #info get rid of dependancy on meego.com repositories for bootstrapping/tools
12:24:15 <lbt> #info MINT is (now) Mer Intergration Tools
12:24:30 <lbt> we need to bring them into the project
12:24:34 * Sage likes how that turned out :)
12:24:44 <Stskeeps> Sage: for instance, yeah
12:24:46 <lbt> I suggest we put spectacle, mic etc in there
12:25:06 <Stskeeps> :nod:
12:25:08 <Stskeeps> task it?
12:25:10 <lbt> as well as BOSS, IMG ... and OBS?
12:25:10 <Sage> So Mer:Tools repository?
12:25:27 <lbt> I made a BZ product
12:25:29 <Sage> lbt: I would say BOSS IMG OBS etc. are separate
12:25:39 <Sage> Mer:Tools:User
12:25:45 <Sage> Mer:Tools:Host ?
12:25:51 <Sage> or something
12:25:55 <lbt> ETOOMANYDIRS
12:26:20 <Sage> spectale, mic, kickstater etc. have different users than BOSS IMG and OBS
12:26:30 <Sage> osc* ^
12:26:32 <phaeron> yes I agree
12:26:54 <phaeron> Mer:Tools for the dev tools like osc mic and spectacle
12:27:12 <phaeron> MINT: for BOSS and IMG etc..
12:27:28 <Stskeeps> we probably need to set up some kind of Mer:Tools build, yes, that adds to the core but is optional
12:27:46 <Sage> :nod: definitely not include to core package repo
12:28:12 <phaeron> yeah but we need to also decide if we consider Mer to be a host target. that is run mer tools on mer
12:28:28 <phaeron> or just target the popular distros like debian and opensuse
12:28:37 <Stskeeps> #info Establish plan for Mer:Tools (seperate from Core)
12:28:42 <phaeron> and fedora
12:28:54 <Stskeeps> #info Mer a host target - mer tools on mer, or do we build for debian/opensuse too?
12:28:56 <Sage> well, not as such as Mer doesn't contain adaptation and UX
12:29:20 <lbt> I'd suggest that Mer is not automatically a host
12:29:30 <lbt> I can see things like osc not running on Mer
12:29:35 <phaeron> UX not needed. just commadline, so it is missing lbt's reference kernel
12:29:53 <phaeron> lbt: not difficult to work out if we want that
12:30:14 <Stskeeps> perhaps a platform SDK kind of thing instead?
12:30:17 <Sage> phaeron: we probably need more than just a kernel, see our x86 adaptation: https://build.pub.meego.com/project/packages?project=CE%3AAdaptation%3Ax86-generic
12:30:23 <Stskeeps> i mean, this stuff could theoretically be done with SB2
12:30:43 <lbt> *nod* ... just saying that BR for Tools is not enough to warrant inclusion in Core
12:31:00 <Sage> lbt: ^ what do you mean?
12:31:24 <lbt> mic probably won't build for Mer Core
12:31:28 <phaeron> lbt: not inclusion in core. an SDK target that works on mer if you like
12:31:28 <Sage> true
12:31:41 <phaeron> Sage: I see some stuff there that could be moved out
12:31:47 <Stskeeps> #info Perhaps osc etc in "platform SDK"?
12:31:48 <phaeron> but nm for now
12:31:56 <Sage> what about Mer:Tools:Deps or just include those deps to Mer:Tools?
12:31:56 <lbt> phaeron: yes... so Tools needs to have a 'needed libs' area
12:32:08 <lbt> Sage: we managed that in MINT iirc
12:32:31 <Sage> lbt: ^ doesn't say anything to me.
12:32:46 <lbt> yeah ... was typing then thought... take it offline
12:33:00 <lbt> #info Note BR for Tools is not enough to warrant inclusion in Core
12:33:11 * Sage agrees
12:33:18 <Stskeeps> we just put BR's for tools to tools, simple as that..
12:33:20 <Stskeeps> second tier
12:33:25 <lbt> yes
12:33:37 <lbt> maybe it was blindingly obvious then :)
12:33:43 <Sage> :)
12:33:44 <Stskeeps> what guides do you guys think we need made?
12:33:57 <phaeron> yeah SDK is like a UX so to speak. and the needed stuff can be a MW kinda , and adaptation to get it on x86
12:34:08 <lbt> #info need a Mer build/versioning policy/guide
12:34:23 <Stskeeps> #info (migrate Packaging/Guidelines to mer wiki?)
12:34:29 <phaeron> eww the item that never dies
12:34:35 <Sage> :)
12:34:37 <lbt> yes ... I'm kinda doing that
12:34:44 <lbt> the wiki migrate
12:35:03 <lbt> https://bugs.merproject.org/show_bug.cgi?id=91
12:35:35 <lbt> I will laugh so hard if Tizen manages to get changelogs right before Mer
12:35:38 <lbt> not
12:35:55 <lbt> and if they use deb packaging... they will :D
12:36:02 * lbt ducks
12:36:35 * Sage ignores last comments by lbt
12:37:43 <Stskeeps> what do we do about Process in general? do we continue evolving the current BOSS process, or start looking into abstracting things more as builds, with hudson/jenkins?
12:37:49 <Stskeeps> to get a system both we and vendor would use
12:39:05 <Sage> I have no experience in those so hard to comment.
12:39:19 <phaeron> mm
12:39:41 <Stskeeps> i think phaeron's complete-project-copy thing is very useful, at least
12:39:57 <phaeron> yeah still working on it
12:40:23 <phaeron> I am just torn about investing time in doing jenkins
12:40:39 <lbt> I'm still reasonably happy with BOSS. I'd like to see how Jenkins could fit in as a step
12:41:05 <phaeron> I say spend the time in doing abstract builds that can run inside anything whether it is OBS , jenkins or a cron job
12:41:12 <phaeron> using the "build" and fakeobs
12:41:15 <Stskeeps> yeah, that makes more sense
12:41:22 <Stskeeps> even with OBS as backend
12:41:33 <phaeron> yes
12:41:34 <lbt> I don't know what that means
12:41:38 <lbt> rpmbuild?
12:41:56 <Stskeeps> a build, btw, is "start from this starting point, add these changes, build project until done, publish+tests"
12:42:06 <phaeron> the build script that takes repositories
12:42:18 <phaeron> we talked about that in the osc build context
12:42:38 <lbt> those are 2 different uses of the word build
12:43:13 <lbt> Stskeeps said "end to end" and used "project" ... phaeron talked about a package build
12:43:17 <Stskeeps> mm
12:43:46 <phaeron> so what Stskeeps is suggesting is working on this so it is usable as a full build that can be encapsulated in jenkins for example
12:44:11 <lbt> so the obs 'build' shell script
12:44:24 <phaeron> yeah kinda
12:44:40 <lbt> I'm not thrilled at planning to develop a bash solution
12:44:42 <Stskeeps> so, what i would (personally) like, is to have a system that allows me to abstract the OBS process of having a project, state of project, and adding one or more changes, doing a build
12:44:54 <Stskeeps> so it abstracts into what CI systems normally sees as a build, or 'make all'
12:45:13 <lbt> make world ?
12:45:18 <Stskeeps> imagine 'make world' for Mer, yeah
12:45:20 <lbt> every package in Mer
12:45:25 <phaeron> like yocto
12:45:26 <Stskeeps> except it don't have have to rebuild all of them
12:45:28 * phaeron ducks
12:45:59 <Stskeeps> as it will have previous binaries/scheduler state
12:46:25 <lbt> so that'd be like putting all the packages into an OBS and waiting until the build cycles finish then?
12:46:55 <Stskeeps> yes, or continuing from a previous build (think build-compare/oldpackages)
12:47:04 <Stskeeps> it just exits when done
12:47:05 <phaeron> I think the idea is a bit hazy, and needs more concrete requirements / description
12:47:19 * Sage is lost already in this.
12:47:44 <lbt> can we please look at the problem as an improvement of the current system rather than "lets fork"
12:47:52 <Sage> btw, what I would like to see is way to duplicate projects so that the versioning CI count etc. doesn't decrease.
12:47:52 <Stskeeps> yes, of course
12:48:08 <lbt> thanks - that doesn't always feel clear to me :)
12:48:21 <lbt> Sage: yay ... versioning
12:48:31 <Stskeeps> Sage: imagine you had a mer copy in your home dir, this is comparable to doing some changes to it, and run 'make' in it
12:48:51 <Stskeeps> and it would build the packages, handle scheduling of packages, etc
12:48:58 <Stskeeps> and perhaps be able to start off a previously full build
12:49:05 <Stskeeps> ie, not have to rebuild everything
12:49:21 <phaeron> Sage: I had found an email that suggested setting the Release: <int> where int is the start point
12:49:51 <lbt> I'd very much like Release: to be used properly
12:50:04 <phaeron> so I can look into how to make obs preserve the last int when copying across projects
12:50:29 <phaeron> because I've seen code in OBS for different algos to control this
12:50:47 <lbt> phaeron: you can't do this
12:50:54 <phaeron> what ?
12:51:12 <lbt> 2 OBS will have different CI counts
12:51:15 <lbt> and B counts
12:51:23 <lbt> you can't sync them
12:51:43 <phaeron> I am saying it might be possible to preserve them
12:51:48 <phaeron> when copying
12:51:55 <Sage> ^ would like that
12:51:56 <phaeron> not sync them
12:52:29 <Sage> The thing is that when architecture changes we at times need to move packages from one PRJ to another and then would be nice to have CE and B counts to match the previous state
12:52:36 <Sage> Stskeeps: that sounds nice
12:52:56 <lbt> an osc mv command would be good
12:53:10 <lbt> so ... versioning?
12:53:15 <Sage> yes that would be nice as well
12:53:32 <phaeron> can we record these items for further investigation
12:53:50 <lbt> phaeron: they'll be in the log
12:53:55 <Stskeeps> #info 'make' approach for entire Mer core
12:54:37 <phaeron> lbt: like stskeeps is doing , one line clear description so to be able to go through them and understand what needs to be done
12:54:48 <phaeron> instead of reading a whole amorphous log
12:54:56 <Stskeeps> #info "osc mv"
12:55:19 <lbt> #info osc mv to support preservation of CI and B
12:55:36 <lbt> #info osc remote link to support preservation of CI and B
12:56:50 <lbt> versioning now?
12:57:18 <phaeron> yeah why not
12:57:39 <Stskeeps> can we write the versioning thing as requirements or something like that, so we know what we're dealing with?
12:57:41 <phaeron> lbt: I got the needed effect from obs by overriding the "vrev" parameter when commiting
12:57:52 <lbt> Stskeeps: https://bugs.merproject.org/show_bug.cgi?id=91
12:57:58 <phaeron> but needs more investigation of course
12:57:58 <Sage> can we keep 10min break as I think this will be umm... long discussion :)
12:58:03 <lbt> and https://bugs.meego.com/show_bug.cgi?id=10910
12:58:10 <Stskeeps> yes, 10 minutes break first :P
12:58:14 <lbt> Sage: good idea :)
12:58:45 <Stskeeps> i agree on the principle but we need some oneliners stating what vendor requirements are, not the technical soluton
12:58:48 <Stskeeps> solution
13:00:04 <phaeron> #info simplify development process by allowing sortable vcs revision based version ( like sha1sum for git cf. https://bugs.merproject.org/show_bug.cgi?id=91)
13:00:58 <lbt> I think my main issue is that I want to have *some* manual control over Release numbering
13:01:13 <lbt> Version is fixed as upstream
13:01:30 <lbt> in meego the release increment was mastered in OBS
13:01:47 <lbt> and when you move or copy packages you lost it
13:01:51 <Stskeeps> phaeron: i think we just need a common standard for that, yeah, usually we did git<count>.short-sha
13:02:14 <Stskeeps> count being number of commits listed by git log or something
13:02:16 <lbt> the same source package would produce different Release values
13:02:32 <lbt> Stskeeps: I like that one
13:02:57 <Stskeeps> ~git<count>.short-sha
13:02:57 <Stskeeps> that is
13:03:28 <phaeron> well if we take control of the OBS CI then we have that
13:03:41 <lbt> no need
13:03:42 <phaeron> needs a patch the lbt had written afair
13:03:51 <lbt> it's upstream
13:03:53 <Stskeeps> can we take one issue at a time?
13:03:54 <phaeron> ah
13:04:00 <Stskeeps> i think we can wrap up simplify development process
13:04:34 <Stskeeps> next-version~git<count>.short-sha1 , provide sample make-snapshot scripts in Packaging/Guidelines
13:04:56 <Stskeeps> it's a method that's known to work
13:05:11 <lbt> agreed ... but... lets see if it breaks as we continue
13:06:07 <Sage> back
13:06:23 <Stskeeps> lbt: of course, continous evaluation of policies
13:06:32 <Stskeeps> lbt: but this one has proven to be working nicely
13:06:35 <Stskeeps> incremental, etc
13:06:52 <lbt> so this is what? the Release value ?
13:06:58 <Stskeeps> no, Version:
13:07:03 <lbt> mm
13:07:05 <Stskeeps> we're discussing bug 91
13:07:18 <lbt> OK ...
13:07:19 <Stskeeps> i would think
13:07:29 <Stskeeps> or at least simplify development process by allowing sortable vcs revision based version
13:07:50 <lbt> we need to distinguish between Mer and upstream owned packages
13:08:13 <lbt> what version is our systemd?
13:08:15 <Stskeeps> 37
13:08:18 <Stskeeps> :P
13:08:29 <lbt> crappy version # but fine
13:08:41 <Sage> lbt: you updated it so you should know :)
13:08:45 <lbt> so do we claim to run systemd 38~git6.3432
13:09:04 <lbt> Sage: *g*
13:09:04 <Stskeeps> yes, if we took a git snapshot from systemd
13:09:08 <lbt> no
13:09:24 <lbt> it's local but with some packaging patches ... eg to remove __DATE__
13:09:52 <lbt> so version is fixed at 37
13:10:12 <Sage> ...
13:10:14 <phaeron> it should be 37~git<count of commits ontop of 37>.<head sha1sum>
13:10:16 <lbt> if we *do* take a git snap from upstream I agree with your number
13:10:29 * lbt sobs
13:10:29 <Stskeeps> yes, can we move beyond that part now?
13:10:31 <lbt> no
13:10:39 <Sage> umm... wait a sec
13:10:45 <Sage> lbt: what do you mean with 38~git6.3432 ?
13:10:51 <Stskeeps> if we take a git snapshot from upstream, then Version: 38~git<count>.sha1sum
13:10:51 <Sage> 15:09.52 < lbt> so version is fixed at 37
13:11:00 <lbt> Stskeeps: yes
13:11:03 * Sage agrees with Stskeeps
13:11:08 <lbt> we all do
13:11:10 <lbt> that's easy
13:11:12 <Sage> ok
13:11:19 <lbt> if we take systemd 37 stable
13:11:30 <lbt> and apply a patch to remove __DATE__
13:11:33 <Stskeeps> okay, so, yes, we have some changes on top of an upstream snapshot usually
13:11:38 <lbt> then Release is defined to increment
13:11:41 <lbt> not Version
13:11:52 <Sage> lbt: then it is version 37 + something not ~git
13:12:08 <Sage> 37-Mer1 for example
13:13:14 <lbt> can I ask why we don't use the damned Release value?
13:13:14 <Stskeeps> OK, let's look at this the abstract way: mer packages is made up of changes, right?
13:14:12 <Stskeeps> what our requirement is that we want to be able to relate a package to a certain change, right?
13:14:19 <Stskeeps> built package, that is
13:14:21 <lbt> Stskeeps: it's made up from an upstream tarball usually labelled X.Y.Z plus our changes
13:14:45 <lbt> and yes, that's the requirement
13:14:45 <Stskeeps> that's why i asked about requirements before we went into the solutions, why are we doing this in the first place
13:14:57 <lbt> and spec files have 2 relevant fields
13:15:02 <lbt> Version and Release
13:15:21 * Sage is having flash backs...
13:15:22 <lbt> Version is defined by rpm to be the upstream X.Y.Z
13:15:34 <phaeron> I think this is outside the meeting scope ?
13:15:40 <phaeron> I need to go somewhere :)
13:15:41 <lbt> Release is defined to be distro specific version
13:15:41 <Stskeeps> nah, it's sadly within..
13:15:47 <Stskeeps> we can keep on discussing it
13:16:00 <lbt> thanks
13:16:02 <Sage> phaeron: it is within the scope. Also we have discussed this a lot before :)
13:16:12 <phaeron> yeah I remember
13:16:22 <phaeron> I was worried about the meeting time box
13:16:24 <phaeron> that's all
13:16:29 <Stskeeps> Requirement: we want to relate a built RPM package to a certain change (commit) in Mer --- lbt: this correct?
13:16:34 <Stskeeps> let's just establish these first
13:16:40 <phaeron> anyway I'll read backlog
13:17:00 <lbt> Stskeeps: that's sounding like a good base
13:17:02 <Stskeeps> ok
13:17:36 <Stskeeps> Requirement: we want to make it possible for a vendor to maintain branched change in Mer and still relate back to a certain change in Mer, and in vendor system -- this correct?
13:18:05 <lbt> yes
13:18:18 <Stskeeps> ok, let me just log those in meeting log
13:18:21 <Stskeeps> #topic Versioning discussion
13:18:33 <Stskeeps> #info Requirement: we want to relate a built RPM package to a certain change (commit) in Mer
13:18:43 <Stskeeps> #info Requirement: we want to make it possible for a vendor to maintain branched change in Mer and still relate back to a certain change in Mer, and in vendor system
13:18:48 <Stskeeps> what else is there of requirements?
13:18:54 <lbt> something about changelog
13:19:08 <Stskeeps> that is implied, a change has a changelog
13:19:08 <lbt> I want the changelog to refer to the package version
13:19:17 <lbt> nonetheless we don't have it
13:19:38 <lbt> our .changes file does not relate an entry to a version
13:20:21 <Stskeeps> isn't that solution and not high level requirements? structure it in a high level way - what's the use case?
13:20:54 <lbt> I look at a changelog and see a change.... I look at the package version in an image and want to know if the change is present
13:22:40 * Stskeeps ponders how to word that
13:23:01 <Stskeeps> okay, first off, where do you picture you get a changelog from? release announcement?
13:23:10 <lbt> each entry in a changelog should identify the package version that it applies to
13:23:35 <lbt> lets say git HEAD of the package
13:23:53 <lbt> or a package DB that has the latest changelog in a link
13:24:04 <Sage> Stskeeps: [root@localhost ~]# rpm -q --changelog dbus
13:25:08 <lbt> Sage: yes - but note that you may be on this weeks image ... and using that log you check the entry for the image 2 weeks ago
13:25:48 <Sage> lbt: ?
13:25:59 <lbt> comment 1 has the example https://bugs.meego.com/show_bug.cgi?id=10910
13:26:23 <Stskeeps> okay, so, we look at a changelog of git HEAD of a package, a particular change and you want to be able to check if a image's package version has that particular change?
13:26:29 <lbt> yes
13:27:00 <lbt> Sage: the point is .. if I look at the changelog for the installed package then, by definition, all entries are valid :D
13:27:54 <Stskeeps> so, i might be an idiot, but i usually just rpm -q --changelog  -p file.rpm  | grep "change text" to figure that out?
13:27:56 <Sage> yes, but I'm probably missing still something
13:28:18 <lbt> I think you both are
13:28:36 <Stskeeps> are you meant to do this in an automatic way or..?
13:28:37 <Sage> lbt: changelog of git HEAD doesn't correspond to chagelog of rpm package.
13:29:01 <lbt> Sage: I'm talking the mer review git HEAD and the .changes file in there
13:29:17 <lbt> Stskeeps: any way
13:29:17 <Sage> ah, ok. Mixed with upstream git head
13:29:24 <lbt> no
13:29:38 <lbt> Sage: let me phrase it another way
13:29:50 <lbt> if I look at the very latest .changes file
13:29:56 <lbt> then it has multple entries
13:30:06 <lbt> some go back a while
13:30:34 <Stskeeps> Requirement: we need to be able to identify automatically if a certain change is contained in an image's package
13:30:34 <lbt> now... I look at an old image... it says version 0.61.25-3 was installed
13:30:37 <Stskeeps> ?
13:30:59 <lbt> let me continue for Sage first
13:31:19 <lbt> the changelog looks like the example here https://bugs.meego.com/show_bug.cgi?id=10910
13:31:44 <lbt> ie it has many entries labelled 0.61.25
13:31:47 <Sage> lbt: I know where you are getting and I agree
13:31:54 <lbt> ok
13:32:20 <lbt> Stskeeps: requirement ... no 2 changelog entries have the same version identifier
13:32:30 <lbt> it's actually that sane
13:32:52 <lbt> #info Requirement: no 2 changelog entries have the same version identifier
13:33:05 <Stskeeps> .. that's solution, we need to say something about mapping
13:34:04 <Stskeeps> Requirement: we need to be able to identify automatically if a certain change exactly (with context) is contained in an image's package ?
13:34:13 <lbt> I can uniquely map from the changelog entry to package version built from that source
13:34:25 <phaeron> crap missed the appointment
13:34:40 <lbt> I can uniquely map from the changelog entry to package version built with a given change
13:34:41 <Stskeeps> Requirement: we need to be able to identify automatically if a certain change uniquely is contained in an image's package ?
13:34:54 <lbt> it's not automatic per se
13:35:12 <lbt> and it's changelog specific
13:35:34 <Stskeeps> mm
13:35:42 <lbt> *if* we provide a changelog then it should be what people expect
13:35:47 <lbt> a log of changes per version
13:36:29 <lbt> I think you're thinking of technical barriers that make it hard and resisting a sane requirement
13:36:44 <Stskeeps> no, i agree that it's needed
13:37:01 <lbt> OK ... good start :)
13:37:43 <lbt> Each changelog entry uniquely identifes a package built with a given change (ie a version)
13:38:05 <lbt> Each rpm changelog entry uniquely identifes a package built with a given change (ie a version)
13:38:34 <Stskeeps> ok, let's for the sake of argumentation and figuring out a direction imagine we don't have .changes files, or %changelog section, and the changelog of a package is the list of changes to it, just to simplify things a bit
13:39:40 <lbt> do you think that simplifies it?
13:39:55 * Sage doesn't see any change what so ever
13:40:04 <lbt> :P
13:40:15 <Sage> it is still changelog no matter what is the format
13:40:28 <lbt> we're talking source packages
13:40:35 <Stskeeps> if i view a git log, each commit sha1 is unique, even if branched?
13:40:41 <lbt> yes
13:41:43 * lbt notes you can't put the sha1 of a git commit inside itself ... eg in the .changes file in Mer review
13:42:19 <Stskeeps> so just theoretically, if we had the sha1 as Release:, we'd have a unique identifier that we can look up in source trees and check if a certain change is part of the branch/package?
13:42:41 <Stskeeps> er, that was wrong
13:42:55 <lbt> but yes
13:43:08 <Stskeeps> so just theoretically, we would be able to tell with rpm -q --changelog if a change was part of it?
13:43:19 <Stskeeps> if changelog == git log
13:44:04 <lbt> bearing in mind the sha1 would then go into the rpm filename and fully qualified version/release.... yes
13:44:48 <Stskeeps> doesn't really have to, but you're right, for other typical uses it would need to be there
13:44:52 <lbt> since it's a random string that would appear in the version column of  rpm -qa and in the image manifest as rpm-x.y.z-sha1
13:46:24 <lbt> I am happy to have Release: <SPEC_REL>.<CI_CNT>.<B_CNT>
13:46:44 <lbt> and simply atomically increment SPEC_REL when doing a commit
13:47:23 <lbt> enhancing that with some kind of sha1 is good - but I don't see which one
13:48:12 * Stskeeps thinks
13:48:15 <Sage> sha1 is well too distro specific in my opinion if that is packaging git related and not upstream
13:48:58 <Sage> Release: Mer<SPEC_REL>.<CI_CNT>.<B_CNT>
13:48:59 <lbt> Sage: yes, but Release is supposed to be distro specific versioning
13:49:28 <lbt> Sage: :D you're jumping ahead :)
13:49:30 <lbt> but yes
13:49:57 <lbt> for systemd that you had to fork this week: ....   Release: Nemo<SPEC_REL>.<CI_CNT>.<B_CNT>
13:49:59 <Sage> lbt: ok, just want to say that would be nice to know where the package originates
13:50:29 <Sage> lbt: actually, Release: Mer<SPEC_REL>.Nemo<SPEC_REL>.<CI_CNT>.<B_CNT> ?
13:50:48 <lbt> good point
13:51:00 <Sage> or your hour long talk was for nothing ;)
13:51:01 <lbt> I had only thought through "some vendor string"
13:51:20 <Stskeeps> (also, how do we deal with branches within mer ..)
13:51:40 <Sage> Stskeeps: branches within Mer?
13:51:46 <Stskeeps> yeah, stablization branches
13:52:02 <Stskeeps> we can have SPEC_REL == 5 on both trunk and release branch
13:52:03 <Stskeeps> :P
13:52:15 <lbt> http://www.mail-archive.com/meego-packaging@meego.com/msg00415.html
13:52:37 <Stskeeps> and this is where the versions gets complicated
13:52:37 <Stskeeps> :P
13:53:05 <Sage> Stskeeps: recall my talk about string for PRE releases?
13:53:07 <lbt> you know git did the right thing
13:53:24 <lbt> can we abandon version numbers
13:53:28 <lbt> and use sha1
13:53:40 <lbt> and use a git tree to determiine parent/child
13:53:41 <Sage> Mer<SPEC_REL>[PRE|REL].Nemo<SPEC_REL>.<CI_CNT>.<B_CNT> ?
13:53:58 <Stskeeps> lbt: i'd very much like this to be somehow automated :P
13:54:27 <lbt> that means rewriting all dependency resolution code ... so "no, not yet"
13:54:40 <lbt> but I think all the sane talk is automatable
13:54:55 <lbt> Sage: for that string you need a change
13:55:08 <lbt> first of <SPEC_REL> is "the text in the .spec file"
13:55:34 <Sage> hrr...
13:55:34 <lbt> so probably Mer3.Nemo1
13:55:40 <Sage> true
13:58:00 <lbt> so ... do we introduce release numbers?
13:58:46 <Sage> but to change those it would need rebuild of each package?
13:59:47 <lbt> I'm not thinking about that
13:59:50 <Stskeeps> i'm okay with it, but we have to remove Release: from spec file and let it be determined from .changes file
14:00:26 <Stskeeps> OBS already mangles the Release: tag anyway/adds it
14:00:31 <lbt> Stskeeps: yes (kinda)
14:00:39 <lbt> the developer won't care
14:01:01 <lbt> heck - we can remove Version too
14:01:22 <Stskeeps> Version:
14:01:26 <Stskeeps> 's more likely to break tools
14:01:27 <lbt> yes
14:01:55 <lbt> it'll go back in as part of the build, as will Release:
14:01:58 <Sage> I think even removing Release might break thing
14:02:03 <lbt> yes
14:02:09 <lbt> that's why I said kinda
14:02:09 <Stskeeps> Sage: nah, that's normal behaviour, i think?
14:02:22 <lbt> Stskeeps: that's a solution
14:02:45 <lbt> requirement : changes is the master for Version: and Release: and the developer dosen't have to update multiple locations
14:02:54 <Stskeeps> that said, i don't like putting same changelog in two places, one for git commit, one for .changes
14:03:31 <lbt> I never did write "how many changelogs?"
14:03:41 <Stskeeps> no, but i remember it
14:03:41 <Stskeeps> :P
14:04:05 <Stskeeps> okay, so, how would a vendor derive?
14:04:07 <lbt> so I'm going to gently back away from that one
14:04:17 <Sage> Stskeeps: well osc already extract the changelog from .changes. Could we add .git plugin as well? Is there way to add plugins to git?
14:04:40 <lbt> solution :)
14:04:42 <Stskeeps> osc, you mean
14:05:01 <lbt> could we agree that we need tools/plugins?
14:05:08 <Stskeeps> mm
14:05:22 <lbt> I am aware that we need to do something about having tarballs in git
14:05:35 <Sage> similar to fedora?
14:05:45 <lbt> ?
14:05:55 <Sage> http://pkgs.fedoraproject.org/gitweb/?p=polkit.git;a=tree
14:05:56 <Stskeeps> fedora uses 'sources' thing
14:06:26 <lbt> yeah...
14:06:47 <Stskeeps> okay, so, Release: Mer<SPEC_REL>.<CI_CNT>.<B_CNT> ?
14:06:52 <lbt> but I was thinking that we'd have something that uses a clone of upstream git with packaging branches
14:06:54 <lbt> or similar
14:07:02 <lbt> Stskeeps: yes
14:07:25 <lbt> almost
14:07:34 <Stskeeps> actualy, Release: in prjconf or in package?
14:07:57 <lbt> what you said is the value that would be used
14:08:12 <lbt> prjconf is just  Release: <SPEC_REL>.<CI_CNT>.<B_CNT>
14:08:16 <Stskeeps> ok
14:08:39 <lbt> in the package we'd need Release: Mer1
14:08:49 <Stskeeps> okay, so, Release: Mer<ORIG_SPEC_REL>.Nemo<SPEC_REL> ?
14:08:56 <lbt> and Nemo would need Release: Mer1.Nemo3
14:09:00 <Stskeeps> and this would always be bigger than <CI_CNT> ?
14:09:18 <Sage> lbt: Personally I don't like that clone of upstream git thing. With that it is not easy to see what is the upstream version we are used as there is not tarball and md5sum to check with. Also we don't really need that, tarballs are enough
14:09:21 <lbt> SPEC_REL is a macro that means "text after Release: " in the .spec
14:09:42 <lbt> Sage: different topic.... but point noted
14:09:43 * Sage thinks we are very close to solution as well already
14:10:17 <Stskeeps> okay, i meant 'SPEC_REL' as in 'number of changelog entries since last version change'?
14:11:49 <Stskeeps> okay, so, if we can get Release: (in package) automatically generated from a new .changes format, i'm happier
14:11:58 <lbt> what's wrong with ++
14:12:28 <lbt> and I'm sure we can
14:12:40 <Stskeeps> so, changelog format..
14:13:21 <Stskeeps> * Thu Nov 17 2011 Robin Burchell <robin+meego@viroteck.net> - 4.8.0~rc1-mer1 ?
14:13:34 <Stskeeps> mer1 becoming Release:
14:13:55 <lbt> * dow mmm dd yyyy Name Goes Here <your@email.com> - X.Y.Z-R
14:13:59 <lbt> yes
14:14:24 <Stskeeps> and then in nemo, mer1.nemo1?
14:14:29 <lbt> do you want to split XYZ and R with a space?
14:14:41 <lbt> some upstreams may have a - in the XYZ
14:14:45 <Stskeeps> no need to, versions can't contain dashes anyway
14:14:51 <lbt> OK
14:14:54 <lbt> good
14:15:13 <Stskeeps> and how do we react if there's no - ?
14:15:22 <lbt> reject
14:15:45 <Stskeeps> not possible, too much packages in the wild in old format
14:16:00 <lbt> only new changes
14:16:17 <Stskeeps> ie, what should Release: be, if there's no -?
14:16:53 <lbt> yeah ... I get the problem
14:16:59 <Stskeeps> mer0.<count of changelog entries since last version change> ?
14:17:09 <Stskeeps> and making sure people start changes from 1 after that?
14:17:27 <lbt> I think we need to snapshot CI
14:18:03 <Stskeeps> assume this is a change we'd have to edit in OBS and we can't change the world :P
14:18:06 <Stskeeps> or at least make plugin-able
14:18:57 <lbt> I'm thinking a bump to every package spec
14:19:26 <Stskeeps> can't change the world, sorry - we will have people freaking out they can't reuse sample spec packages
14:19:37 <lbt> ?
14:19:45 <Stskeeps> ie, we can't modify all specs/changelogs
14:19:52 <Stskeeps> so no bumping
14:20:03 <Stskeeps> in Mer we can, yes, but rest, no
14:20:07 <lbt> we need to agree what problem we're discussing
14:20:18 <Stskeeps> Release: calculation
14:20:33 <Stskeeps> ok
14:20:33 <lbt> yes
14:20:36 <Stskeeps> if there's a dash
14:20:37 <lbt> where and when
14:20:42 <Stskeeps> we use new method
14:20:48 <Stskeeps> if there's not, we fall back to old behaviour
14:20:52 <lbt> where?
14:20:55 <Stskeeps> and we add this to all mer packages
14:20:58 <lbt> c.obs?
14:21:00 <lbt> Mer OBS ?
14:21:02 <Stskeeps> when determining what Release: should be
14:21:52 <Stskeeps> okay, at each package build, OBS goes in, looks at what Release: tag in package should contain
14:21:59 <lbt> which OBS
14:22:03 <Stskeeps> any
14:22:25 <lbt> why do we care what other OBS'es do?
14:23:00 <Stskeeps> OK, so, i don't want to manually edit Release: in .spec. Release: should come from .changes file
14:23:19 <lbt> right
14:23:29 <lbt> but it will be present in the .spec
14:23:40 <lbt> specify may do it
14:23:47 <lbt> lets assume so .. it seems sane
14:24:01 <Stskeeps> ok, but it's ignored typically
14:24:09 <Stskeeps> and replaced with CI_CNT.B_CNT
14:24:13 <lbt> yes
14:24:21 <lbt> so Mer requires a prjconf
14:24:32 <Stskeeps> riht
14:24:37 <lbt> that uses the upstream'ed <SPEC_REL>
14:24:42 <Stskeeps> SPEC_REL.CI_CNT.B_CNT, that i agree
14:24:46 <lbt> OK ...
14:24:56 <Stskeeps> i'm talking about how to get SPEC_REL
14:25:14 <lbt> so as soon as you enable that... all the packages will have weird Release values
14:25:18 <Sage> lbt: we can modify specify :)
14:25:23 <lbt> yes
14:25:41 <lbt> Stskeeps: currently most Release values are 1
14:25:51 <lbt> but this is only a Mer problem
14:26:15 <Stskeeps> SPEC_REL should be == the first changelog entry, version, after the dash, right?
14:26:31 <Stskeeps> when a dash exists, ie, mer-derived
14:26:39 <lbt> to 'fix' it I think we need a spec bump to add the changelog with the new format, run specify, modify .spec and then a worldrebuild
14:26:46 <Stskeeps> right
14:27:06 <Stskeeps> that part i don't disagree with, in Mer, we need to spec bump
14:27:10 <lbt> OK
14:27:19 <Stskeeps> er, changelog bump, but yeah
14:27:20 <lbt> now we ship sane spec files
14:27:56 <lbt> so I don't see how this impacts 'outside' Mer?
14:28:13 <Stskeeps> it doesn't, but we need OBS to support our ability to fetch Release: from .changes file
14:28:24 <Stskeeps> i don't want to edit in 2 places when +1'ing
14:28:46 <lbt> mmm
14:28:58 <lbt> OBS per se doesn't do that
14:29:08 <Stskeeps> it already deals with %changelog addition
14:29:30 <lbt> ah
14:29:38 <lbt> that just works
14:30:11 <Stskeeps> so, my point is, it should retrieve the stuff after the dash in .changes and make that Release:
14:30:20 <lbt> specify will do that
14:30:49 <Stskeeps> i'm not going to re-run specify either
14:31:25 <lbt> ...
14:31:39 <lbt> what will you run ?
14:31:52 <lbt> 'cos we can hook it to run specify
14:31:53 <Stskeeps> nothing, i'll edit the .changes file, +1 the release in there, that's it
14:32:03 <lbt> eh?
14:32:20 <lbt> sorry I don't get this workflow
14:32:21 <Stskeeps> it's pretty simple requirement: when calculating replacement Release: OBS should retrieve the first changelog entry, grab our intended SPEC_REL from there
14:32:26 <lbt> no wait
14:32:32 <lbt> you have a solution in your head
14:32:32 <Stskeeps> my workflow is: edit spec file, edit changes file, commit
14:32:36 <Sage> all packages are not based on specify
14:32:36 <lbt> I have one in mine
14:32:38 <lbt> they differ
14:32:57 <Stskeeps> i'm not going to change the same thing in spec file and changes file
14:32:58 <Stskeeps> :P
14:32:58 <Sage> also specify 0.23 adds Release: 1 automatically if not present
14:33:05 <lbt> OK ... the first half of this meeting was about how OBS sucks and we want to isolate
14:33:11 <lbt> now we want process in there..
14:33:13 <lbt> hmmm
14:34:14 <Stskeeps> %{_first_changelog_entry_version}?
14:34:15 <Stskeeps> :P
14:34:26 <lbt> wfm... lua can do it
14:35:11 <Stskeeps> ok, so now it moves to a rpm global macros issue instead
14:35:27 <lbt> that OK ?
14:35:43 <Stskeeps> i don't see a problem with that, let me just look at somethng
14:35:43 <lbt> should be ... it'll run the Mer rpm
14:35:54 <lbt> lua has posix extensions...
14:36:03 <lbt> the regexp bit seems not to be working
14:36:11 <lbt> but it has basic pattern matching
14:41:30 <Stskeeps> ok, so, /usr/lib/rpm/meego/dist.sh is what generates the output of %{dist} tag
14:41:53 <Stskeeps> we can probably use that
14:42:05 <Stskeeps> and add Release: %{dist} automatically, or something like that
14:42:24 <Stskeeps> either way, implement it in an automatic way so i only have to do in .changes, and i'm happy
14:42:44 <Sage> \o/
14:42:48 <lbt> yeah ... lua is better than specify
14:43:05 <Stskeeps> even %generate_release_tag is fine with me
14:43:09 <lbt> yes ... and <SPEC_REL> is handled in dist.sh I think
14:43:31 <Stskeeps> ok, can we end this meeting then?
14:43:31 <Stskeeps> :P
14:43:50 <lbt> how do we do the mass bump
14:43:54 <Stskeeps> easily
14:44:03 <lbt> thought you'd say that
14:44:04 <Stskeeps> git clone, submit, perhaps disable reviews temporarily :P
14:44:32 <lbt> so info
14:44:43 <Sage> Just out of curiosity, if we would change this now and then change only in new review that should work as well?
14:45:08 <Stskeeps> hmm?
14:45:14 <Sage> Just saying I think we should test this in use so that we have both types of Releases out there the new and the old
14:45:22 <lbt> #info Mer will move to using Release: values which come from .changes file
14:45:24 <Sage> just to be sure there isn't problems with compatibilty?
14:45:27 <Stskeeps> we'd have that in any setup
14:45:52 <Stskeeps> #agreed merX.nemoY and grabbing it automatically from .changes with RPM scripts, eventually dist.sh in rpm configs %{dist}
14:45:56 <Sage> anyway, I'm glad this matter is moving forward finally :D
14:46:09 <lbt> me too ... how long?
14:46:29 <Sage> couple of years? :)
14:46:40 <lbt> long meeting ... good outcome ... thanks for being patient :)
14:46:42 <Stskeeps> ok i'm ending the meeting
14:46:51 <Stskeeps> #endmeeting