EPEL meeting summary/minutes - 2009-07-17

[Jesse Keating]

On Jul 18, 2009, at 15:07, inode0 <inode0 at gmail.com> wrote:

> On Sat, Jul 18, 2009 at 2:42 PM, Kevin Fenzi<kevin at tummy.com> wrote:
>> On Fri, 17 Jul 2009 19:16:40 -0500
>> inode0 <inode0 at gmail.com> wrote:
>>
>> ...snip...
>>
>>> Since I am one of the more vocal critics in #rhel on this subject I
>>> guess I'll say my piece here now. The reason I haven't before,
>>> although I have discussed it at some length with stahnma in #rhel,  
>>> is
>>> that I don't believe I have any new arguments to offer. I just am
>>> persuaded by the arguments that are on the table already.
>>
>> ...snip...
>>
>> I'm not going to answer all your comments responding to particular
>> lines out of the irc log, as I don't think thats going to be
>> productive.
>
> I doubt any further discussion will be productive and I'm willing to
> just accept we don't agree on either the merits of repotags or the
> benefits to EPEL using them.
>
>> How about we list up the pros and cons and see if they are worth it?
>>
>> PRO: Easily end user visible marker for where a package came from.
>> PRO: Other 3rd party repos use them, so people are used to them.
>
> Joining that 3rd party community would have been a huge PRO when EPEL
> had the chance. Now it is probably too late to list that as a PRO.
>
> You can add or dismiss the other PROs given as part of the original
> debate, I've got nothing new to add as I said before.
>
>> CON: Causes us to diverge from Fedora
>
> At least for packages targeted at RHEL users, diverging from making
> your packages appear to users to be part of the distribution (which
> makes them think they got them from Red Hat) goes in the PRO category,
> not the CON category, from the perspective of the user.
>
>> CON: Can be easily spoofed / isn't a sure indicator
>
> Here we have the red herring for about the 5th time. This is
> completely irrelevant to the vast majority of RHEL users unless EPEL
> is going to lie about its repotag or unless Dag Wieers is going to lie
> about his. I'd like to believe this is extremely unlikely to happen.
> We have a trusted 3rd party community, trust that has been earned over
> a number of years. Who do you think in that community is going to
> spoof another repo's tags?
>
> If such an unthinkable thing actually did happen it would be quickly
> and easily discovered anyway.
>
>> CON: Would require a mass rebuild of our packages.
>> CON: Would need to be carefull this didn't change the upgrade path  
>> for
>> users using multiple 3rd party repos, or at least notify them about  
>> it.
>
> Both of these are the result of EPEL's previous decisions and you can
> weigh them accordingly but they aren't CONs of repotags. The are just
> CONs of EPEL changing to repotags now.
>
> So from where I sit among RHEL users who occasionally need 3rd party
> support I count zero CONs on your list aside from those that were
> self-inflicted.
>
>> (more to add for either list?)
>>
>> Personally, at this point I would like to know more about the end  
>> user
>> cases you are seeing where a dist tag would help. Perhaps you could
>> post some irc logs of users who this would have helped with (with the
>> nicks redacted?). Can we do something else in these cases? Would a
>> script help?
>
> I'm not interested in searching and editing IRC logs and mailing lists
> for you. You are now asking for too much effort from me when I see
> almost no chance that anything would come from it.
>
> There are several common cases that come up. One simple one is a user
> has a problem with a particular package and its source needs to be
> determined so they can report the bug or whatever. When rpm -q package
> identifies the source everyone's life is just about as easy as it
> could possibly be. If you find a simpler solution I'd love to hear
> about it. Expecting someone providing help to ask that user to do what
> Thorsten provided for 2 or 3 repos is not a simpler solution and is
> really laughable. Yes, there are other ways we can extract the
> information from the user, they take more time and effort on
> everyone's part.
>
> As far as a script helping goes it would only help if it were provided
> by Red Hat has part of RHEL. Otherwise it would not be available
> universally as not everyone uses any particular 3rd party repo. And if
> they (Red Hat) would agree to such a thing, unlikely I think, it might
> as well be part of rpm, like rpm -q
> --where-the-heck-did-this-come-from package.

Or perhaps a bug reporting URL field in each rpm. Accessable via rpm - 
qi or a targetted query.

--
Jes