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@xxxxxxxxxxxxxxxxx> 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. -- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
