13:00:25 <_TPG> #startmeeting
13:00:25 <chwido> Meeting started Fri Dec 20 13:00:25 2013 UTC.  The chair is _TPG. Information about MeetBot at https://wiki.openmandriva.org/om/en/MeetBot.
13:00:25 <chwido> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:00:25 <fedya|2> yes
13:00:41 <bero|2> works for me
13:00:41 <_TPG> agenda is quite simple
13:00:54 <_TPG> 1. rpm5.org relations with OMA
13:01:08 <_TPG> 2. ABF branching for 2014.0
13:01:10 <_TPG> 3. Other
13:01:15 <fedya|2> i built a systemd
13:01:16 <fedya|2> haah
13:01:33 <_TPG> #topic 1. rpm5.org relations with OMA
13:02:49 <_TPG> fedya|2, welcome to systemd builders club :p
13:06:15 <_TPG> ok let's wait for n3npq_
13:06:22 <fedya|2> Any good ideas for rpm5 and oma?
13:06:23 * n3npq_ yawns
13:06:35 <_TPG> well i have one :p
13:07:02 <_TPG> n3npq_, have your coffee ?
13:07:23 <_TPG> if yes please do some introductionm
13:07:38 <n3npq_> I put a cuppa in the microwave when topic1 was announced
13:08:28 <_TPG> we have time :p
13:08:40 <n3npq_> atm there is wide divergence between what OMA and RPM5 call RPM5
13:10:05 <n3npq_> there is also no functional relationship between OMA and RPM (or me) capable of identifying features and coordinating releases
13:11:31 <n3npq_> I have development work that I wish to complete. The completion of some of that work is going to make upgrading to "upstream" releases more difficult.
13:12:23 <n3npq_> there are other features that are fully complete since 2011.0 that are being ignored/unused (see bad/invalid/unsigned proposal)
13:13:21 <n3npq_> I'm here (almost 4 weeks now) to attempt to define the relationship.
13:13:48 <_TPG> n3npq_, so what kind of relationship are you suggesting
13:14:21 <n3npq_> one relateionship is that I ask you to publicly claim a fork a walk away.
13:15:07 <n3npq_> … and walk away. that is essentially the status quo. the "branding" issue is resolved by asking you to rename your fork
13:15:31 <n3npq_> I have had discussions about the "ROSA Package Manager" renaming more than a year ago already
13:16:40 <n3npq_> there are other relationships. what kind of relationship are you suggesting?
13:17:32 <bero|2> I think we should move closer to upstream
13:17:42 <_TPG> my suggestion is that OMV should be close with upstream
13:18:05 <bero|2> Probably dropping all patches is not really realistic for now, but we should try to at least get the patch count down
13:18:34 <_TPG> also is think that n3npq_ should maintain rpm package in OMV repo
13:19:05 <n3npq_> another relationship is that you switch to rpm.org: e.g. pcpa's java bootstrap depends on rpm.org functionality that I have suggested on cooker@ … and now other reversions using find-{requires,provides} are being used and (my guess) will continue to be used.
13:19:30 <n3npq_> let's deal with the patches first because its easiest
13:19:40 <n3npq_> I have reviewed the patches multiple times.
13:20:01 <_TPG> n3npq_, do you have a list of patches that have go or no go for mergin into upstream code ?
13:20:42 <n3npq_> POK mailed all the patches in late August. I have integrated all that seem acceptable, rejected patches that are not acceptable, and suggested modifications to others
13:21:03 <n3npq_> so its up to OMA to revisit what has already done if you wish reduced patch count
13:22:12 <n3npq_> there are also 10-12 patches upstream under #ifdef RPM_VENDOR_MANDRIVA that I wish to get rid of because they are too specific to Mandriva with no known interest anywhere else.
13:22:48 <n3npq_> I do not build with those patches enabled, and cannot support/maintain code that I do not execute
13:23:41 <n3npq_> there are also a number of hacks left over since 2011.0 with no ability to repair.
13:24:40 <n3npq_> I have sent kate the list of patches. see <rpm-devel@rpm5.org> archives in late August
13:26:18 <_TPG> ok, so patches that have GO form you will be merged and these with NO GO needs to be reviewed by OMV and finally drop or got rewrite
13:26:57 <n3npq_> patches that were not submitted upstream do not exist from my pov. I cannot be responsible for guessing, nor continuously re-vetting the OMA rpm package in git. I have vetted these patches multiple times and voiced opinions. none of that worked: a couple weeks/months go by and I'm back to the same tasks (just like in 2014.0 specs): re-re-re-re-re-vet patches
13:28:03 <n3npq_> a public forum, either rpm-devel@rpm5.org or blueprints.launchpad.net/rpm (preferred) was requested so that comments were persistent.
13:28:23 <n3npq_> the comments have existed since late August
13:29:19 <n3npq_> not "GO will be merged", all patches that are going to be merged, have been merged
13:30:03 <bero|2> So I think a TODO for someone from OMA side would be to look at upstream code to figure out what patches have been merged and which ones remain
13:30:28 <n3npq_> and there is code upstream that need to be pushed back to OMA in patches.
13:30:29 <bero|2> And then to figure out if we really need the ones that remain or if there's another way to accomplish what they do
13:31:56 <n3npq_> bero|2: I believe we are beyond the point of studying patches and arguing case by case yet again. see "fork" as possible relationship
13:32:22 <n3npq_> and "ROSA Package Manager" as already chosen name
13:33:00 <n3npq_> meanwhile -- there are other parts of this relationship than patches.
13:33:31 <n3npq_> unless patches is all that you require of rpm5.org
13:35:10 <n3npq_> another RFE that was first made of Eugene Dodanov in 2010 was a Mandriva hosted buildbot integrated into rpm5.org continuous integration
13:35:59 <n3npq_> that was also proposed on the Mandriva engineering list, and to ROSA about a year ago.
13:36:12 <n3npq_> or 2y ago … I've forgot.
13:36:41 <n3npq_> the development benefits of continuous integration are well known
13:38:33 <n3npq_> hosting a build slave with whatever packages you want installed avoids me having to identify and maintain a host or VM with cooker moving target packages: which is a whole lotta work
13:39:13 <bero|2> That should be doable inside abf
13:40:13 <n3npq_> what would be needed is ~8Gb (I have run F16/F17 buildslaves in 4G) of disk storage on some server that is being updated regularly
13:40:27 <n3npq_> *shrug* asked and rejected of ROSA
13:41:03 <bero|2> Shouldn't be much of a problem, and I think it should be done...
13:41:26 <bero|2> l
13:41:30 <n3npq_> the answer was "build slave not needed because ABF does better job" which simply isn't true
13:43:01 <n3npq_> meanwhile -- whatever feature set/relationship is decided -- I wish to see this on an "official" OMA ROADMAP somehow.
13:46:04 <n3npq_> any other de facto set of features is subject to triage as part of distro defeaturing. I spent 3 months identifying common/useful features with ROSA only to see the work suddenly postponed indefinitely. those common features marked "Essential" or "High" was part of that work 2y ago. Now I wish to finish the postponed feat=ures (including MANDATORY signatures and removal of --nodigests/--nosignatures disablers)
13:46:59 <n3npq_> so I'd like to see whatever is desired publicly "official"
13:47:45 <bero|2> Got to leave, just got an emergency call
13:48:02 <bero|2> I'll be back later, let me know if there's something I an do to fix things
13:48:25 <_TPG> bero|2, ok
13:49:04 <n3npq_> I'd like too hear comments from others: hero is a member @rpm5.org and these issues have been discussed repeatedly internally to @rpm5.org.
13:50:00 <klebedeff> *am around if will be needed
13:50:02 <n3npq_> what I do not know is what relationship OpenMandriva desires … there is currently no functional relationship between RPM5 and ROSA/OpenMandriva
13:51:04 <n3npq_> lack of functional relationship means no discussion nor proposals are possible outside of distro specs and TC
13:51:10 <_TPG> i think we need a support from upstream in maintaining rpm software in OMV
13:51:32 <n3npq_> depends on what "support" means
13:52:02 <n3npq_> but yes, that is the purpose here, defining a working relationship, setting mutual expectations, etc.
13:52:08 <_TPG> first definition - maintaining "vanilla" rpm inside OMV repos
13:52:42 <_TPG> while someone from OMV will maintain patches that are somehow needed while you are not going to merge into upstream
13:52:59 <n3npq_> two rpm's forces interoperability testing. you know how much depends on rpm, and two rpm's is much much much harder
13:53:26 <_TPG> anyways you are here rpm guru and your knowledge is most welcome to help us
13:53:31 <_TPG> on rpm field
13:53:36 <n3npq_> e.g. odin proposed rpm.org in contrib … never really worked
14:00:36 <n3npq_> the silence is deafening … let's wrap this up (I'm not even sure TC is the proper forum)
14:00:58 <n3npq_> there are 2 "official" 2014.0 proposals
14:01:09 <_TPG> sorry i'm working :<
14:01:35 <n3npq_> 1) patches upstream. I'd suggest a different wording, perhaps re-re-re-re-review and resubmit
14:02:14 <_TPG> well if you claim that TC is not the place you have expected to see the discussion then we can move this on Association level
14:02:34 <n3npq_> 2) bad/invalid/unsigned packages in repositories: this is assigned to bero (per _TPG)
14:04:30 <n3npq_> not claiming anything, read what I wrote. TC meetings on irc are great for bug work collaboration, less good for global strategies. you just spend 2-3 weeks slogging through specs item-by-item when the strategic discussions actually happened in Prague.
14:06:15 <n3npq_> at the level of "branding" confusions about which RPM5, the one in OMA or the one "upstream", is the "real" RPM5, TC meetings will rubber stamp existing RPM5 which is already widely divergent. if that is the relationship you want, so be it.
14:11:35 <n3npq_> there was also a request to run a RPM5 build slave on a server maintained by OMA proposed. bothe hero/mdawkins have seen the continuous integration build slaves in action: I ran rpm5.org code on all Mandriva based distros on the planet (back to 2007.0, Mageia, Caixa Magica) during the 2011.0 release cycle. 2011.0 likely would not have succeeded if I had not run build slaves
14:11:44 <n3npq_> anything else?
14:12:23 <_TPG> ok so i got your point
14:12:53 <n3npq_> there is a set of patches headed from RPM5 -> OMA marked in blueprints.launchpad.net/rpm
14:13:13 <_TPG> speaking of strategy i think TC+Association meeting would fit your needs
14:14:25 <n3npq_> at the explicit relationships discussed here, TC+Association would need vote on "ROSA Package Manager" renaming.
14:15:20 <n3npq_> there are other relationships … I'm seeking a mutually beneficial defined relationship instead of the current status quo.
14:16:31 <n3npq_> but the emphasis is on defined … fork if you wish
14:17:23 <n3npq_> or revert to rpm.org, also mentioned (because its simple to understand)
14:24:08 <n3npq_> anything else?
15:06:28 <itchka> n3:npq: That seems very clear. Does this need a timescale or project plan _TPG?
15:11:12 <_TPG> itchka, this needs a discussion and yes roadmap would be fine to have this
15:11:32 <_TPG> anyways i need to go :(
15:11:37 <_TPG> #endmeeting