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