[Fedora-packaging] Summary/Minutes from today's FPC Meeting (2013-08-01 16:00 - 17:40 UTC)

[T.C. Hollingsworth]

Hi!

Sorry I couldn't make the meeting this morning.  I'll definitely try
to make the one in two weeks.

In the meantime, I'd like to go ahead and answer some of the questions
from the meeting in the interim.

On Thu, Aug 1, 2013 at 10:45 AM, James Antill <james at fedoraproject.org> wrote:
> * Node.js guidelines update - https://fedorahosted.org/fpc/ticket/311
>   (spot, 15:32:44)
>   * ACTION: Draft approved (+1:6, 0:0, -1:0)  (spot, 15:52:47)

Thanks!

> 15:41:11 <tibbs|w> The multiple version thing is kind of weird, though.  I'm thinking they might need some section on actually naming the different packages.

We just intended to follow the general distro rule for this kind of
thing.  (e.g. the latest gets an unversioned name, compat versions get
a version number added to the Name.)

Would be happy to make this explicit if need be.

> 15:42:04 <abadger1999> For the nodejs_arches => would it be better to recommend defining nodejs_arches at the top of the spec file if we're on Fedora18 or EPEL?
> 15:42:19 <tibbs|w> Either way, I guess.
> 15:42:48 <tibbs|w> Though I wonder why EPEL has to differ here.  Red Hat doesn't package the node stuff directly, do they?
> 15:43:36 <tibbs|w> And F18, for that matter; why not just add the macros somewhere so we don't have to have this pointless difference?
> 15:43:38 * Smoother1rOgZ here
> 15:43:51 <abadger1999> Or even %{!?nodejs_arches: %global nodejs_arches  %{ix86} x86_64 %{arm}}
> 15:44:31 <abadger1999> tibbs|w: yeah -- I wonder if there's something about that needing to be defined in a certain place so that it can be built on the proper builders?

It needs to be in redhat-rpm-config since it needs to be available at
createSRPMfromSCM time in Koji.  Panu only committed my patch for F19.
 You'll have to yell at him if you want it in F18 too.  ;-)

There's the same issue with EPEL6, but even worse since there's no way
that's getting into RHEL's redhat-rpm-config.  I wonder if we could
have an epel-rpm-config for this purpose, theres at least one other
instance where it would be handy for eliminating the delta between
Fedora and RHEL, and there probably will be others.

We could reccomend the syntax abadger1999 suggested, but sgallagh said
he preferred just letting git branching doing its things in the
discussion we had previously.  Personally I really don't care, as long
as it works.

> 15:47:47 <geppetto> There are some minor things … like is it ok to add the "%{?nodejs_find_provides_and_requires}" at the top of a non-EPEL6-- specfile.

Yeah, that's what the question mark is for.  ;-)

Sorry, guess I should have added something about that to the blurb
there.  (Would do so now but I'm not sure if it's okay to modify a
draft at this stage.)

> 15:53:19 <abadger1999> Right now, multiple versions gate on the nodejs-packaging package to update a file; it would be better for them to drop into a dircetory I think.

The problem with that is then every package that depends on a package
in this situation would need to BuildRequire it.  The solution we went
with makes it completely transparent to dependent packagers.

> * Web Assets - https://fedorahosted.org/fpc/ticket/323 -
>   https://fedoraproject.org/wiki/User:Patches/PackagingDrafts/Web_Assets
>   (spot, 16:01:43)

> 16:05:25 <geppetto> src="/_sysassets/javascript/jquery/jquery-min.js … holy 50 character paths batman!

Yeah, I really want to make it /_sysassets/js/ for short.  (But still
support the latter for consistency with the filesystem directories.)

> 16:05:57 <spot> i figured we'd do this one at a time

I can split it into three tickets if that would help.

> 16:06:26 <limburgher> My response to "Not sure if this is a good idea" in the Flash section is "No, you're right, it isn't."
> 16:10:32 <spot> just looking at Web_Assets draft, i don't see any real issues with it, aside from being mildly bothered by the Flash binary exception

I'm not entirely in love with this either, but the fact of the matter
is a lot of packages already do this:
https://fedoraproject.org/wiki/Web_Assets/Flash/Packages

If we don't want that we'll have to clean that up somehow.

> 16:06:47 <abadger1999> in web assets "Web applications typically involve code that is executed locally, and thus do not fall under these guidelines."  <= not sure what this line means.
> 16:07:39 <tibbs|w> abadger1999: I think he's just saying that something like horde or gallery isnt' covered.
> 16:10:38 <abadger1999> tibbs|w: I'm not sure.... I mean, the portion that executes locally should fall under different guidelines (php in horde's case).  But if there were a dynamic web UI portion to it, should that fall bunder this guideline?
> 16:11:33 <tibbs|w> abadger1999: I assume the idea is that it shouldn't, but maybe the statement about it could be stronger.
> 16:12:01 <tibbs|w> My understanding is that this is for shared assets, not stuff encapsulated into a single application.  But I could just be misunderstanding the whole thing.
> 16:12:13 <abadger1999> tibbs|w: From the wording, I agree... but my question is why shouldn't it?
> 16:12:24 <RemiFedora> yes I understand like tibbs, about "shared" asset
> 16:12:33 <abadger1999> I agree with the shared vs single application.
> 16:14:57 <abadger1999> tibbs|w: maybe the sentence could be revised to "Web applications typically have web assets that are specific to that application.  Those types of web assets do not fall under these guidelines."

Yeah, it's intended for "libraries", not "applications".  I'm open for
suggestions on how to make this clearer.

Applications usually involve web server configuration (whether it be
for PHP, Ruby/SCGI, Python/WSGI, whathaveyou) and don't belong here.
This is for static bits only.

I guess if an applications ships static bits that are useful to other
applications it would be okay for it to drop them here, but I'm having
a hard time coming up with a real-life example where that would be
necessary...

Internal JS/CSS/etc. bits that only apply to your application
certainly don't belong here.  But I just realized that we really want
the remainder of the guidelines (regarding minification, bundling,
etc.) to apply to those too.  I added some language to this effect:
https://fedoraproject.org/w/index.php?title=User:Patches/PackagingDrafts/Web_Assets&diff=347650&oldid=346224
https://fedoraproject.org/w/index.php?title=User:Patches/PackagingDrafts/JavaScript&diff=347646&oldid=346038

Again, advice on how to make things clearer would be most welcome.  :-)

> 16:10:09 <geppetto> Are they just confused about _sysassets vs. _assets … or am I missing something?

Should be /_sysassets, just forgot a place I guess.  It's fixed now.

Note that the paths have now been changed twice now in response to
complaints about possible collisions and confusions from packaging and
devel.

> 16:08:34 <RemiFedora> my main concern is about web servers, other than httpd
> 16:09:23 <RemiFedora> while I think this web guildelines is something usefull, we need to have it working for all web servers, not only httpd

At the moment we really don't support web applications on other web
servers, so I haven't lost too much sleep over this.

But it wouldn't be hard shipping complimentary web-assets-lighttpd and
web-assets-nginx packages with the necessary configs or symlinks, or
just baking it into the default configs there.

Are there any other http daemons we should worry about besides
lighttpd and nginx?

> 16:17:35 <abadger1999> (jquery-ui is probably not hte best example for web-assets... it appears to be mostly javascript.)

It has a bunch of images for icons and other UI elements.  That one
may be a candidate for splitting though since you could just use the
JS bits and your own custom theme in an app though.  It's never going
to be used server-side though which is why it's the first example I
could think of.

> 16:19:08 <abadger1999> Probably should ask nim-nim or font sig to look over the small change to the font guidelines

Nicolas is already okay with it:
https://lists.fedoraproject.org/pipermail/devel/2013-July/186584.html

-T.C.