16:00:34 <sochotni> #startmeeting Java SIG -- https://fedoraproject.org/wiki/SIGs/Java
16:00:34 <zodbot> Meeting started Tue Feb 19 16:00:34 2013 UTC.  The chair is sochotni. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:34 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:44 <sochotni> #meetingname Java SIG
16:00:44 <zodbot> The meeting name has been set to 'java_sig'
16:00:49 <sochotni> #topic roll-call
16:00:55 <sochotni> .fasinfo sochotni
16:00:56 <zodbot> sochotni: User: sochotni, Name: Stanislav Ochotnicky, email: sochotni@redhat.com, Creation: 2010-04-06, IRC Nick: , Timezone: Europe/Prague, Locale: en, GPG key ID:  71A1677C, Status: active
16:00:59 <mizdebsk> .fasinfo mizdebsk
16:01:00 <tradej> .fasinfo tradej
16:01:00 <zodbot> sochotni: Approved Groups: +gitfedorareview fedorabugs cla_redhat cla_fedora cla_done +packager provenpackager @git-javapackages
16:01:00 <akurtakov> .fasinfo akurtakov
16:01:03 <zodbot> mizdebsk: User: mizdebsk, Name: Mikolaj Izdebski, email: mizdebsk@redhat.com, Creation: 2012-04-02, IRC Nick: mizdebsk, Timezone: Europe/Prague, Locale: en, GPG key ID: , Status: active
16:01:06 <pingou> .fas pingou
16:01:06 <zodbot> mizdebsk: Approved Groups: @gitmaven-rpminstall-plugin provenpackager git-javapackages cla_fpca cla_done packager fedorabugs @gitjava-deptools
16:01:09 <zodbot> tradej: User: tradej, Name: Tomas Radej, email: tradej@redhat.com, Creation: 2011-08-03, IRC Nick: tradej, Timezone: Europe/Prague, Locale: en, GPG key ID: , Status: active
16:01:12 <zodbot> tradej: Approved Groups: provenpackager cla_fpca cla_done packager fedorabugs
16:01:15 <zodbot> akurtakov: User: akurtakov, Name: Alexander Kurtakov, email: akurtako@redhat.com, Creation: 2008-10-01, IRC Nick: akurtakov, Timezone: Europe/Sofia, Locale: en, GPG key ID: , Status: active
16:01:18 <zodbot> akurtakov: Approved Groups: @giteclipse-packagekit cla_fedora cla_done cla_redhat fedorabugs +packager provenpackager @git-javapackages @giteclipse-fedorapackager
16:01:21 <zodbot> pingou: pingou 'Pierre-YvesChibon' <pingou@pingoured.fr>
16:01:58 <msrb> .fasinfo msrb
16:02:00 <zodbot> msrb: User: msrb, Name: Michal Srb, email: msrb@redhat.com, Creation: 2012-12-04, IRC Nick: None, Timezone: UTC, Locale: en, GPG key ID: None, Status: active
16:02:02 <sochotni> I'll give it until 17:05 for the roll-call I guess
16:02:02 <zodbot> msrb: Approved Groups: @gitmaven-rpminstall-plugin fedorabugs packager cla_done cla_fpca
16:02:15 <vanaltj> .fasinfo jvanalte
16:02:16 <zodbot> vanaltj: User: jvanalte, Name: Jon VanAlten, email: jon.vanalten@redhat.com, Creation: 2011-05-19, IRC Nick: vanaltj, Timezone: UTC, Locale: en, GPG key ID: , Status: active
16:02:19 <zodbot> vanaltj: Approved Groups: packager fedorabugs cla_fpca cla_done
16:03:50 <rgrunber> .fasinfo rgrunber
16:03:50 <zodbot> rgrunber: User: rgrunber, Name: Roland Grunberg, email: rgrunber@redhat.com, Creation: 2009-07-23, IRC Nick: rgrunber, Timezone: America/Toronto, Locale: en, GPG key ID: , Status: active
16:03:54 <zodbot> rgrunber: Approved Groups: @giteclipse-packagekit cla_fedora cla_done cla_redhat packager fedorabugs @giteclipse-fedorapackager
16:05:10 <sochotni> ok, let's get going then
16:05:21 <sochotni> #topic New guidelines & XMvn packaging
16:05:45 <akurtakov> ok, I'll start
16:06:00 <sochotni> #link https://fedoraproject.org/wiki/User:Msrb/JavaPackagingDraft
16:06:12 <akurtakov> xmvn looks cool and simplifies packaging a lot but
16:06:22 <akurtakov> it brings major change to the way packaging is done
16:06:36 <akurtakov> it embeds parent package and removes
16:06:44 <akurtakov> the parent definition from the pom.xml
16:06:48 <akurtakov> in the binary rpm
16:07:17 <akurtakov> this will effectively mean that if one has a bug with e.g. apache-parent
16:07:25 <akurtakov> and fixes it
16:07:30 <akurtakov> he would have to rebuild
16:07:43 <akurtakov> all packages that have apache-parent as their parent
16:07:55 <akurtakov> going all the way down to the rabbit hole
16:08:04 <akurtakov> aka ~100 or more packages
16:08:21 <akurtakov> second, during these rebuilds
16:08:36 <sochotni> akurtakov: meaning current Mass Rebuild?
16:08:37 <akurtakov> we will have a mixture of old (embedded) and new
16:08:42 <sochotni> oh no, nvm
16:08:46 <akurtakov> parent
16:08:50 <mizdebsk> you could say the same about stdio.h header in glibc, if it contains a bug than tousands of packages would need to be rebuilt
16:09:02 <akurtakov> which can even lead to wrong requires
16:09:04 <mizdebsk> but how many bugs we had in parent poms like that?
16:09:13 <akurtakov> being generated hense second rebuild can be needed
16:09:15 <mizdebsk> and how many bugs we had because of inaccurate dependencies?
16:09:20 <akurtakov> mizdebsk: let me finish
16:09:27 <mizdebsk> which is easier to fix? launch a build or investigate dependency problem?
16:09:59 <mizdebsk> xmvn brings some disadvantages, but advantages they greatly outweight them
16:10:07 <akurtakov> third, this introduce unnecessary change form upstream and breaks the goal of having our repo being usable with upstream maven
16:10:13 <akurtakov> mizdebsk: LET ME FINISH
16:10:49 <akurtakov> as such changes will have the only impact
16:10:58 <akurtakov> of differening us from upstream sources
16:11:08 <akurtakov> as they are supposed to have no runtime effect
16:11:14 <akurtakov> forth, and most important
16:11:20 <akurtakov> this change was introduced
16:11:30 <akurtakov> hidden by everyone
16:11:33 <akurtakov> not documented
16:11:39 <akurtakov> not explained
16:11:56 <akurtakov> hidden for almost everyone
16:12:12 <akurtakov> which is not the way things should happen in an open source project
16:12:30 <akurtakov> while I can agree on discussing the technical points
16:12:37 <akurtakov> only point 4 should be enough
16:12:45 <mizdebsk> ad 4.
16:12:48 <akurtakov> for this to be bringed back, documented
16:12:55 <akurtakov> advertized on mailing list
16:12:58 <akurtakov> discussed there
16:13:04 <akurtakov> and only after that enabled
16:13:11 <mizdebsk> i made several announcements on java-devel, noone really answered
16:13:24 <akurtakov> mizdebsk: about embedding parent poms ?
16:13:46 <akurtakov> such thing deserves ATTENTION: Major change coming
16:14:05 <mizdebsk> i'm not embedding them myself, upstream Maven does
16:14:37 <mizdebsk> i only write them to disk as a kind of cache so we don;t need tens of dependencies to repeat the process when rebuilding next package\
16:15:01 <mizdebsk> the code was developed publicly from the very beginning
16:15:08 <akurtakov> mizdebsk: http://repo1.maven.org/maven2/org/apache/maven/shared/maven-dependency-analyzer/1.3/maven-dependency-analyzer-1.3.pom
16:15:11 <mizdebsk> everytone is welcome to join, discuss, develop it
16:15:21 <akurtakov> I don't see parent being removed ?
16:16:22 <akurtakov> when there is something approved, the one proposing a change needs to advertise it
16:16:32 <akurtakov> not everyone else to look in his code repositoriy
16:16:34 <vanaltj> fwiw, most of the mail I see about this was more like announcement "this is what is about to or has already happened" rather than proposal.
16:17:50 <akurtakov> so now I said what I think about this change
16:18:00 <akurtakov> this doesn't mean I'm against xmvn
16:18:20 <akurtakov> I would like to see it being default/advertized way
16:18:27 <akurtakov> but with embedding parent poms removed
16:18:32 <vanaltj> let me see if I understand the mass rebuild issue.
16:18:49 <vanaltj> if some small implementation bug is fixed, even if API/ABI doesn't change, it still requires rebuild?
16:19:30 <sochotni> vanaltj: this embedding is only happening for parent pom.xml files
16:19:41 <akurtakov> vanaltj: it's really a build time only thing
16:19:44 <sochotni> i.e. xmvn installs effective pom
16:20:39 <sochotni> OK, so my proposal...which *does* affect guidelines as well..
16:20:41 <vanaltj> is that yes or no?  (sorry, I am not nearly as familiar with maven as you guys, despite *using* it :P  )
16:21:12 <mizdebsk> vanaltj: definitely not
16:21:20 <vanaltj> ok
16:22:03 <sochotni> revert back to standard pom.xml files
16:22:22 <sochotni> add a guideline text which would limit BR/R on parent poms
16:22:41 <sochotni> so ONLY pure-maven packages can have "Requires: XX-parent"
16:22:42 <mizdebsk> effective poms are a *fundamental* principle behind xmvn
16:23:01 <mizdebsk> you can't just remive it without destroying the whole idea
16:23:04 <sochotni> and parent poms CAN NOT pull in additional deps besides parent poms
16:23:06 * tradej is afk
16:23:22 <sochotni> mizdebsk: nobody is talking about removing parent pom references
16:23:23 <akurtakov> mizdebsk: what stops you from using them but not installing them ?
16:23:43 <sochotni> akurtakov: still need them in buildroot
16:23:57 <sochotni> akurtakov: the parent packages I mean
16:24:09 <sochotni> one level lower
16:25:40 <sochotni> mizdebsk: what would be the issue with such an approach?
16:26:13 <mizdebsk> sochotni: multiple issues
16:26:18 <mizdebsk> 1) code duplication
16:26:48 <mizdebsk> instead of having a single R: in parent pom you have tens of repeated BR: in offspring packages
16:27:10 <mizdebsk> 2) R: can be genrated automaticcaly, BR cant
16:27:19 <mizdebsk> so you'd need to manage that duolicated code manually
16:27:58 <mizdebsk> 3) once package is built and tested a change to parent POM can break it
16:28:15 <akurtakov> my turn ?
16:28:21 <mizdebsk> (like some new dependency added in parent pom makes your pkg suddenly to stop working, not only building)
16:29:05 <mizdebsk> go ahead..
16:29:07 <akurtakov> 1) code duplication : we would have copies of parent pom at different levels in the packages
16:29:33 <akurtakov> 2) not that a problem as pure maven packages can/will do require parents
16:30:08 <akurtakov> 3) not true for anything but maven as changing pom can affect only maven plugins
16:30:11 <akurtakov> at runtime
16:30:23 <akurtakov> about build breakage
16:30:36 <akurtakov> if building breaks you would better see it at build time not at runtime
16:31:03 <pingou> +1 on that
16:31:12 <pingou> I'd rather have my package not building than not working
16:31:18 <mizdebsk> 1) there is a difference between machine duplication of small metadata and manual maintenance of dependencies
16:31:46 <mizdebsk> 3) if you install effective pom then once you build your package it won't change because of some parent pom change
16:31:53 <mizdebsk> so i don't see your point
16:32:13 <sochotni> indeed I have to agree with mizdebsk here, the possibility of runtime brekage is actually smaller
16:32:23 <mizdebsk> if you don;t install effective poms then you can compile and test the package
16:32:24 <sochotni> it's much more likely (and happening) today
16:32:41 <akurtakov> 1) for the very small benefit of less BRs maintained manually you try to push many needed bumps/rebuilds needed for simple change
16:32:44 <mizdebsk> but the next day someone changes some POM and you need to follow up with updating your Requires
16:32:48 <mizdebsk> or you have broken package
16:32:57 <akurtakov> 3) don't live in maven world only - maven is build tool
16:33:04 <akurtakov> used to deliver what users use
16:33:17 <akurtakov> hence they don't care abour parent poms being effective or not
16:33:34 <akurtakov> and updating the parent pom
16:33:42 <mizdebsk> no, users do care
16:33:42 <akurtakov> will not break end user program
16:33:57 <akurtakov> except for packagers
16:34:03 <akurtakov> which I would not call users
16:34:05 <mizdebsk> users don't need 30 parent poms installed along with 40 maven plugins when they install freemind
16:34:19 <mizdebsk> or maven
16:34:30 <akurtakov> mizdebsk: fight mess with even more mess ?
16:34:35 <akurtakov> I dont' see there aren't bugs
16:34:47 <akurtakov> there are problems and they need to be fixed
16:34:52 <akurtakov> but this is not the way
16:35:12 <akurtakov> in the case of freemind
16:35:17 <mizdebsk> there are too many bugs to fix them manually, automatic requires generation provides a way to easily generate accurate dependencies
16:35:30 <mizdebsk> currently there is no standard how dependencies should be declared
16:35:33 <akurtakov> mizdebsk: so what stops you to generate automatic deps
16:35:43 <akurtakov> using the effective pom
16:35:46 <mizdebsk> some packages do declare dependency on POM, some don't
16:35:48 <akurtakov> but installing the normal one
16:35:48 <mizdebsk> etc/
16:36:36 <sochotni> mizdebsk: that is because we do not have a policy for handling parent poms
16:36:44 <sochotni> that doesn't mean it can't change
16:36:47 <mizdebsk> i believe that the issue of effective/raw pom is out of sciope for this meeting
16:36:58 <sochotni> I'd still prefer if I didn't have to manually keep BRs/Rs up to date
16:37:20 <akurtakov> mizdebsk: it's a fundamental scope introduced with xmvn change
16:37:25 <mizdebsk> sochotni: if parent POm doesn't pull plugins for you then you will have to include them manually
16:37:39 <akurtakov> so voting on xmvn is related to this discussion
16:37:51 <akurtakov> unless we agree to vote on xmvn with this disabled
16:37:54 <akurtakov> until agreed
16:38:12 <mizdebsk> my point is that we won't have a consensus now, in a reasonable time
16:38:22 <mizdebsk> so let's better get keep going with other issues
16:38:38 <mizdebsk> and postpone the topic of effective vs raw pom for further discussion
16:38:47 <akurtakov> well, xmvn is the heart of the guideline changes
16:38:55 <akurtakov> if it will come with effective poms being installed
16:38:55 <rgrunber> just wondering, would it be possible for packagers to specify whether to embed, or just pull in from installed parent pom and have deps?
16:39:02 <akurtakov> I would vote the whole change -1
16:39:16 <akurtakov> if we can get xmvn installing normal poms I would vote +1
16:39:25 <akurtakov> that's why it makes huge difference
16:39:58 <mizdebsk> rgrunber: yes, you could  install raw poms
16:40:22 <mizdebsk> but if you want to get simple and accurate automated requires then the only solution i can see is installing effective POMs
16:40:35 <mizdebsk> otherwise it's a mess
16:41:01 <mizdebsk> i analyzed many different possibilities, effective POM is the cleanest solution
16:41:20 <akurtakov> mizdebsk: have you ever thought out of curiosity why maven central installs normal poms not effective poms ?
16:41:48 <sochotni> mizdebsk: yes, but noone has seen/read that analysis which is causing the issue I'd say
16:42:09 <mizdebsk> akurtakov: maven has much more complicated dependency mechanisms
16:42:21 <sochotni> i.e. have a list of options, plusses, minuses and why you believe solution X is the right one
16:42:24 <mizdebsk> optional dependencies, dependency scopes, eclusions, ...
16:42:38 <mizdebsk> we CANNOT to that with rpm, which has much simpler dependency mechanism
16:43:02 <sochotni> akurtakov: plus, let's be honest...every package specifies exact parent pom version
16:43:16 <sochotni> so if you fix parent pom you still need to update all dependent packages
16:43:26 <akurtakov> sochotni: no
16:43:27 <mizdebsk> what works for maven central doesn't necessarly work for us
16:43:35 <akurtakov> we ignore versions
16:43:46 <akurtakov> hence I fix my apache/eclipse/whatever-parent
16:43:49 <akurtakov> and I'm done
16:44:04 <akurtakov> I don't need to rebuild everything the maven will throw in
16:44:28 <mizdebsk> akurtakov: maven central: you bump parent version and break it, offspring remain file because they have versioned R on parent
16:44:29 <sochotni> akurtakov: I assumed you were pointing to effective vs normal poms on Central due to this
16:44:47 <mizdebsk> effective pom: you break parebnt, offspring is still working because their effective pom didbnt change
16:45:01 <mizdebsk> raw pom: as soon as you break parent pom everything breaks
16:45:10 <akurtakov> mizdebsk: let me give you real example
16:45:12 <mizdebsk> so effective POM is much closer to upstream in this matter
16:45:21 <akurtakov> with the adventure of openjdk
16:45:36 <akurtakov> we had problems with plexus compilation
16:45:41 <akurtakov> target/source setting
16:46:10 <akurtakov> we fixed the parent in maven2-common-poms
16:46:20 <akurtakov> and voila everything was back and working
16:46:54 <akurtakov> same for javax.servlet:servlet but multiplyed
16:47:05 <akurtakov> so if I have effective pom
16:47:13 <akurtakov> I can't just fix the parent
16:47:22 <akurtakov> I should rebuild everything that embeds it
16:47:49 <mizdebsk> that's correct
16:48:00 <mizdebsk> but it works the other way too
16:48:26 <akurtakov> nope
16:48:41 <mizdebsk> let me give an example then
16:48:54 <mizdebsk> a real life example that caused much problem in fedora
16:49:24 <mizdebsk> someone updated parent POM in a *stable* release
16:49:39 <mizdebsk> new upstream versiuon added maven-enforcer-plugin
16:50:00 <mizdebsk> with a single update of this POM suddenly tens of packages FTBFS in a stable release
16:50:24 <mizdebsk> because parent POM was broken by adding enforcer plugin w/o declaring this as R:
16:50:27 <akurtakov> mizdebsk: something that is visible on the buildsystem and by packagers only
16:50:53 <akurtakov> while changing the pom makes a huge difference with regards to speaking to upstram
16:50:55 <mizdebsk> akurtakov: not only
16:51:15 <akurtakov> who else
16:51:25 <akurtakov> only people that do run mvn-rpmbuild
16:51:47 <mizdebsk> if parent pom added dependency on some huge package (that happened before)
16:52:13 <sochotni> mizdebsk: there's one more issue with effective poms I believe - you lose comments (including license headers from apache for example)
16:52:18 <mizdebsk> then your application dependency chain gets doubled or tripled
16:52:56 <mizdebsk> sochotni: i don't see how this is a problem
16:53:06 <mizdebsk> effective pom is supposed to be machine-readable only
16:53:16 <mizdebsk> and there are no legal issues about that
16:53:17 <akurtakov> mizdebsk: one simple question that needs yes or no answer
16:53:42 <mizdebsk> "who else?" any user
16:53:51 <mizdebsk> for multiple reasons
16:53:56 <akurtakov> can we have xmvn that doesn't installed effective pom?
16:54:05 <akurtakov> if we can't we should vote right now
16:54:10 <mizdebsk> akurtakov: yes you can
16:54:23 <mizdebsk> xmvn didn't use to install effective pom in the past
16:54:39 <sochotni> I have a suggestion: Let's have XMvn install normal pom.xml, look at guidelines as they are now
16:54:39 <akurtakov> ok, do we all aggree to continue with the guidelines
16:54:45 <mizdebsk> but with introduction of auto requires it has to install effective pom in order to keep dependencies sane
16:54:57 <sochotni> and we can discuss this on ML until our fingers bleed later
16:55:03 <akurtakov> with the prerequisite that xmvn will be switched back to installing normal pom
16:55:16 <sochotni> mizdebsk: we'll just have to complement parent pom requires for the time being
16:55:22 <sochotni> until we agree on a solution
16:55:25 <akurtakov> and for effective pom mizdebsk will have to convince us first
16:55:38 <sochotni> akurtakov: that was the general idea, yes
16:55:39 <akurtakov> via smth written
16:56:00 <akurtakov> sochotni: well, things in rawhide changed so this was needed
16:56:16 <akurtakov> no such change should ever happen without being approved by java sig and FPC first
16:58:21 <akurtakov> the biggest problem is that this was introduced without discussion
16:58:39 <akurtakov> and the opinion of other stackholders were not considered at all
16:58:53 <akurtakov> only after that come the technical problems
16:58:56 <sochotni> mizdebsk: so, OK with the proposal?
16:59:16 <mizdebsk> which one?
16:59:45 <sochotni> that we discuss guidelines as they are on the condition that XMvn installs non-effective poms
17:00:16 <sochotni> I assume this will mean that almost every package already using XMvn will have to be fixed
17:00:37 <sochotni> but that's to be expected since that was a test-run
17:00:45 <akurtakov> well, whatever we decide
17:00:51 <mizdebsk> i would rather pospone the whole guidelines change then
17:00:58 <akurtakov> xmvn needs to be reverted to install normal poms
17:01:01 <akurtakov> asap
17:01:06 <mizdebsk> auto-requires are the main factor driving the change
17:01:19 <mizdebsk> and effective pom are the basics behind it
17:01:21 <akurtakov> and changed to install effective pom only after/if we agree on it
17:01:21 <vanaltj> yeah partial guideline change now, more change later, this doesn't sound like the best thing.
17:02:09 <akurtakov> I'm fine to postpone the guidelines but xmvn needs to be reverted now
17:02:19 <mizdebsk> there is nothing to be reverted
17:02:24 <mizdebsk> xmvn is not in the guidelines
17:02:30 <mizdebsk> it's just a standard fedora package
17:02:33 <akurtakov> mizdebsk: even the behaviour
17:02:39 <akurtakov> or revert all packages using it
17:02:43 <akurtakov> to us mvn-rpmbuild
17:03:02 <mizdebsk> IMO packages using xmvn are in compliance with current guidelines
17:03:16 <mizdebsk> so unless you prove me wrong i disagree with the revert
17:03:17 <akurtakov> as they are using something not in the guidelines if you want to stay to the point
17:03:57 <akurtakov> guidelines say use mvn-rpmbuild
17:04:09 <akurtakov> mizdebsk: don't try to play word games
17:04:12 <akurtakov> others can do it too
17:04:26 <mizdebsk> akscram: no, they SHOULD use mvn-rpmbuild
17:04:28 <mizdebsk> not MUST
17:04:39 <mizdebsk> akurtakov: ^
17:04:51 <vanaltj> what, besides guidelines, are reasons for revert?
17:04:52 <akurtakov> mizdebsk: don't let me escalate this to FESCO even
17:05:03 <akurtakov> changing the poms being installed
17:05:10 <sochotni> akurtakov: FPC
17:05:10 <vanaltj> (and what, besides guidelines, are reason to not revert?)
17:05:12 <akurtakov> is unapproved change
17:05:18 <akurtakov> and should have never happened
17:05:30 <mizdebsk> they are still POMs, effective or not they are valid POMs
17:05:37 <mizdebsk> so no violation here either
17:05:42 <vanaltj> akurtakov: let me rephrase, what's the damage from the change that happened?
17:06:02 <akurtakov> mizdebsk: have you ever read https://fedoraproject.org/wiki/Staying_close_to_upstream_projects?rd=PackageMaintainers/WhyUpstream
17:06:14 <akurtakov> vanaltj: the damage is that if you fix a parent pom
17:06:21 <vanaltj> (I'm trying to get a picture of what the least painful forward motion, regardless of history and what should/could have happened)...
17:06:24 <akurtakov> you need to rebuild all packages that has this as parent
17:06:34 <akurtakov> which you have no easy way to know
17:06:41 <akurtakov> as xmvn removed the parent declaration
17:06:50 <mizdebsk> so you do in upstream!
17:06:56 <akurtakov> and this will go through various levels
17:07:06 <mizdebsk> if you fix upstream artifact you need to modify ALL dependant artifacts and bump version!
17:07:15 <vanaltj> thire is no xmvn --what-depends-on-me ?
17:07:20 <akurtakov> mizdebsk: no
17:07:26 <akurtakov> when you fix glib
17:07:30 <mizdebsk> so my solution is much closer to upstream
17:07:35 <akurtakov> you don't have to rebuild all the packages that require on it
17:07:46 <sochotni> vanaltj: you can do repoquery --arch=src --whatrequires XXX-parent
17:07:48 <mizdebsk> i thought we were talking about java, not glib
17:08:08 <akurtakov> mizdebsk: parent poms are in the same category
17:08:09 <mizdebsk> in Maven world if you change artifact then you need to update all dependant artifacts
17:08:29 <akurtakov> mizdebsk: you don't in Fedora Maven world
17:08:29 <sochotni> vanaltj: that will basically ask "what buildrequires XXX-parent"
17:08:36 <mizdebsk> that change can be bugfix or bug
17:08:36 <akurtakov> which you try to introduce
17:08:42 <vanaltj> sochotni: ah right, of course :)
17:08:49 <sochotni> which in XMvn translates also to "What package embeds XXX-parent"
17:08:53 <akurtakov> sochotni: not that easy
17:09:11 <akurtakov> cause apache-parent will be embedded in many other parent poms
17:09:39 <sochotni> akurtakov: yes, you of course need do do --recursive
17:09:41 <mizdebsk> akurtakov: repoquery can list transttive dependencies out of the box, even print dependency trees
17:09:51 <mizdebsk> so it's not even easy, it's trivial
17:09:52 <sochotni> that's not the point though
17:09:53 <mizdebsk> a single command
17:10:11 <vanaltj> mizdebsk: as packager, I don't want to have to find and then rebuild all deps if I need to bump a parent, and it sounds like reverting would prevent this.  What technical reasons do you have against reverting?
17:10:13 <akurtakov> mizdebsk: do you absolutely reject the proposal to revert xmvn change
17:10:40 <mizdebsk> vanaltj: you won't need to do this, only in some extreme cases
17:10:44 <mizdebsk> like major bug
17:11:05 <pingou> which can happen
17:11:22 <vanaltj> that's not a technical reason why not to revert.
17:11:23 <mizdebsk> akurtakov: you mean revert packages using %mvn_build to mvn-rpmbuild ?
17:11:29 <akurtakov> mizdebsk: NO
17:11:30 <vanaltj> that's trying to minimalize the reason TO revert.
17:11:37 <akurtakov> revert xmvn to install normal poms
17:11:58 <vanaltj> ah right two different revert options...
17:12:21 <akurtakov> mizdebsk: simple yes/no please
17:12:26 <mizdebsk> akurtakov: xmvn is a build tool only, if you use mvn-rpmbuild you still install raw poms manually
17:12:30 <akurtakov> I don't have more time to spend in circles
17:12:30 <mizdebsk> no harm done
17:12:39 <mizdebsk> only %mvn_install installs effective POMs
17:12:39 <akurtakov> yes or no?
17:12:52 <vanaltj> ok so revert packages by inverting the change that we had a couple weeks ago?
17:12:57 <akurtakov> I don't like word games
17:13:18 <mizdebsk> revert packages from %mvn_build back to mvn-rpmbuild? i DO mind
17:13:24 <akurtakov> vanaltj: no, the change was introduced after that
17:13:32 <akurtakov> without being discussed here first
17:13:54 <sochotni> mizdebsk: akurtakov meant mostly about installing normal, not effective poms
17:13:57 <sochotni> I believe
17:14:02 <akurtakov> mizdebsk: revent %mvn_build to install normal poms
17:14:08 <sochotni> i..e change xmvn to install non-effective poms
17:14:23 <mizdebsk> and i already said, autorequires will NOT work properly with this change
17:14:37 <akurtakov> they will but not fully
17:14:44 <mizdebsk> so if you use %mvn_build/%mvn_install and install raw poms instead of effective poms, you'll get a real mess
17:14:47 <mizdebsk> dependency bloat
17:14:52 <mizdebsk> so yes, i DO mind that
17:15:04 <vanaltj> are packages using auto-requires already?
17:15:14 <mizdebsk> vanaltj: yes
17:15:15 <sochotni> vanaltj: yes, about 50-60
17:15:26 <vanaltj> from before this effective poms change?
17:15:42 <akurtakov> mizdebsk: as it's mine vs yours opinion
17:15:43 <vanaltj> or packages updated for this change.
17:15:50 <akurtakov> I would let others vote and decide
17:15:53 <akurtakov> mizdebsk: wdyt ?
17:15:59 <akurtakov> we made our statements
17:16:11 <mizdebsk> i would postpone it for more discussion before letting others decide
17:16:40 <sochotni> vanaltj: repoquery --repoid=rawhide --whatprovides '/usr/share/maven-fragments/*xml' | wc -l
17:16:40 <akurtakov> mizdebsk: you can not enforce others to accept your change
17:16:45 <sochotni> 135 (binary rpms)
17:17:16 <mizdebsk> akurtakov: it's not about enforcing anyone to do anything
17:17:16 <akurtakov> and you do it already by using your proven packager
17:17:20 <mizdebsk> akurtakov: it's about choice
17:17:25 <akurtakov> you enforce effective poms on me
17:17:30 <mizdebsk> you have a chioce which tool you want to use
17:17:37 <akurtakov> for packages that you don't own
17:17:37 <vanaltj> sochotni: what I'm trying to figure out is if packages have been changed already that depend on the new xmvn changes under dispute.
17:17:39 <mizdebsk> %mvn_build vs mvn-rpmbuild
17:17:41 <akurtakov> and you do that choice
17:17:44 <sochotni> vanaltj: yes
17:17:51 <akurtakov> without the maintainer even knows about it
17:18:00 <vanaltj> ugh.
17:18:02 <sochotni> mizdebsk: actually effective poms do affect even mvn-rpmbuild packages
17:18:04 <mizdebsk> akurtakov: in which case?
17:18:18 <mizdebsk> i don't recall changing any package to the new style w/o asking maintainer
17:18:42 <sochotni> before this gets ad-hominem...
17:18:55 <sochotni> stop
17:18:57 <sochotni> both of you
17:19:21 <vanaltj> so, if xmvn gets reverted, there are these 135-odd binary rpms that also must be reverted?
17:19:27 <mizdebsk> all i want is to stop (postpone it) and go on with other stuff (if any)
17:20:01 <sochotni> vanaltj: there are 2 more or less options
17:20:25 <sochotni> revert all xmvn-using packages (around 100) to use mvn-rpmbuild
17:20:27 <sochotni> not ideal
17:20:28 <mizdebsk> vanaltj: no, there's nothing broken, that packages can stay
17:21:07 <sochotni> or make xmvn install non-effective pom which will make auto-requires a bit weird
17:21:19 <mizdebsk> these packages do follow guidelines: install POMs, have proper (implicit) requires on java, jpackage-utils etc.
17:21:20 <sochotni> and will cause some failures to be sure (especially in the beginning)
17:21:32 <mizdebsk> there is no necessity to revert them
17:21:46 <sochotni> and for that...I don't have a good answer
17:21:48 <akurtakov> I want to hear a vote here:
17:22:09 <akurtakov> who wants normal and who wants effective poms to be installed?
17:22:15 <akurtakov> normal
17:22:18 <mizdebsk> +1 effective
17:22:40 <sochotni> voting now doesn't help anything
17:22:53 <akurtakov> sochotni: it will help in my fpc
17:22:56 <akurtakov> ticket
17:23:01 <kdaniel> +1 normal.
17:23:19 <sochotni> akurtakov: I wanted to suggest that, since we are obviously out of line here
17:23:36 <akurtakov> ok, I want to point to the meeting minutes
17:23:44 <sochotni> for what it's worth I believe effective poms are better way to deal with stuff
17:23:47 <akurtakov> so they have the full picture
17:24:16 <sochotni> but current situation is less then ideal from guideline perspective
17:24:59 <rgrunber> i'd prefer normal poms, at least for now.
17:25:14 <sochotni> I don't think there's anything else to add really
17:25:20 <akurtakov> vanaltj: pingou:
17:25:53 <pingou> tbh I could follow the discussion but I don't know enought to vote for a side or the other
17:26:02 <vanaltj> I abstain, for similar reasons.
17:26:45 <pingou> I see the concern from akurtakov
17:26:52 <tradej> same as pingou and vanaltj
17:27:05 <msrb> same here
17:27:19 <akurtakov> aka the 4 of you are 0
17:27:31 <sochotni> so it's 2:2 if I counted correctly, not that it means much
17:27:33 <sochotni> IMO
17:27:36 <akurtakov> so normal/effective 3:2
17:27:38 <akurtakov> :)
17:27:44 <sochotni> oh right
17:27:46 <sochotni> sorry
17:27:46 <mizdebsk> no, obviously more discussion is needed as people are not sure
17:27:54 <sochotni> counted rgrunber and kdaniel as one :-D
17:27:57 <akurtakov> mizdebsk: yes, the problem is
17:28:09 <akurtakov> that change should happen after discussion not before it
17:28:13 <pingou> mizdebsk: discussion and information I think
17:28:20 <akurtakov> you fail to understand this point
17:28:30 <sochotni> we are obviously not going anywhere with this right now
17:28:36 <sochotni> so I am going the end the meeting
17:28:36 <vanaltj> I see issue with how this got introduced, and is a long term problem that needs to be sorted, but I'm not sure that I see reverting as helpful here other than to repair "the process".
17:28:46 <mizdebsk> akurtakov: the change happened only in my packages (or maintainers that approved the change)
17:28:59 <mizdebsk> if there are any bugs caused by that i'll fix them
17:29:17 <mizdebsk> why do you want to force me (and others) to one packaging style?
17:29:32 <sochotni> mizdebsk: there should only be one style
17:29:54 <sochotni> there will be multiple ways to package Maven artifacts over my dead body
17:30:17 <sochotni> we WILL agree or...
17:30:22 <mizdebsk> fedora is a free comminity, not a regime
17:30:42 <mizdebsk> package owners have ultimate decission what they want their packages to look like as long as it follows the policy
17:30:51 <sochotni> #endmeeting