Re: [Spacewalk-devel] Future of the development stack?
On 14/10/13 11:37, Cliff Perry wrote: Hi Duncan and guys, so the last I saw, 12 days ago, was this Spacewalk branch https://git.fedorahosted.org/cgit/spacewalk.git/log/?h=bootstrap-css Grant loaded it onto a test system and it was looking good, still some polish needed and fixes done in a few places, but great to see. Hey Cliff Thanks for the feedback, it is much appreciated. So, I had a couple of questions 1) Any further progress/merging into that branch? I spent the Hackweek at SUSE porting the list widgets. Grant Gainey supported me with useful information. Silvio just pushed the current branch to the spacewalk git. The current plan is to make a sprint this and next week and look into: - Perl pages (we upstreamed some Java ports, but as part of a different feature branch :-)) - Details everywhere - asset processing and CDNs (I will explain below) Then we would like to try to merge upstream, and work the next details (static html pages that require different classes, by-hand widgets and porting images to font icons that are not generated by jsp tags) in a second round when the first basic stuff is already merged. This would open the window for others to contribute, port, and to get some bug reports. We would continue then to do minor work as we find issues and in a ~6 weeks we will do another 2 week sprint focusing various developers on polishing specific reported problems. So our main focus now is to manage to get this week and next week everything in a state where a merge would be accepted. 2) There was at least two css scripts being pulled from 3rd party locations which were required. They need to be packaged/shipped - since a fully disconnected Spacewalk instance, would not have internet access to pull it down. Yes, this is the asset processing part I mention above. We did this for development convenience. We will remove this and use bundled versions. Also, right now LESS is preprocessed to CSS in the client using less.js. We want to introduce a developer/production mode that in the second case it uses the css (generated during build) and in the first it would preprocess at runtime for developer convenience. Also this processing could include minifying and bundling of various assets together. This could help eg. RHN by reducing bandwidth and number of requests. Rails has this feature, may be we can mimick it somehow with Struts. 3) More a reminder, to ensure all code/libraries/scripts used are GPL friendly. http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses Twitter Bootstrap: Apache License 2.0 jQuery: MIT Font-Awesome code: MIT (all compatible) Font-Awesome fontss: SIL Open Font License (OFL) Addressed here: http://www.gnu.org/licenses/license-list.html#SILOFL (not a problem) Really, this is good stuff and I look forward to seeing the finished and polished product. Thanks a lot for the feedback! -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Future of the development stack?
On 07/06/13 12:39, Duncan Mac-Vicar P. wrote: Hey astronauts We have been planning features for SUSE Manager and we are asking ourselves if for some of them it makes sense to do it with the current stack. As part of the CSS re-factoring upstream we lost all our re-branding work, which is fine, because we had forked the CSS so we kind of deserve it :-). However even by doing it by cascading a .css file at the end, it is cumbersome to override the previous styles. The world outside keeps moving and people are nowadays solving these problems by standardizing the css framework a bit eg: twitter bootstrap, where you have a very nice standard theme to start with, and then you can customize it in a standard way, as all css rules are documented and standarized. We already are using bootstrap in other SUSE products, and other major opensource projects (eg: OpenStack, OpenShift, etc) are also using it. We could start using bootstrap for new features, but we would be afraid to have them rejected by upstream. But another possibility would be to contribute upstream a port of all the styling to bootstrap from the beginning, which would be a mega-patch, but we would not start working on something like this without having discussed whether this is wanted or not. This would mean basically replace all css rule names of all pages. Similar discussions go in other areas of the web stack. We are realizing for some features we could avoid struts and use a client side Javascript framework (AngularJS, batman.js, etc) and have the Java web framework provide the data. Would features using a client side framework be rejected? I wanted to ask what is upstream strategy on these topics. Which kinds of contributions would be welcome and desired by Redhat (that is the biggest contributor)? Which aren't?, so that we, SUSE, as a frequent contributor and community members could align ourselves to this. We are trying to keep SUSE Manager as close to Spacewalk as possible, but we also don't want to get stuck without good reasons. Regards, Hi Duncan and guys, so the last I saw, 12 days ago, was this Spacewalk branch https://git.fedorahosted.org/cgit/spacewalk.git/log/?h=bootstrap-css Grant loaded it onto a test system and it was looking good, still some polish needed and fixes done in a few places, but great to see. So, I had a couple of questions 1) Any further progress/merging into that branch? 2) There was at least two css scripts being pulled from 3rd party locations which were required. They need to be packaged/shipped - since a fully disconnected Spacewalk instance, would not have internet access to pull it down. 3) More a reminder, to ensure all code/libraries/scripts used are GPL friendly. http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses Thanks! Really, this is good stuff and I look forward to seeing the finished and polished product. Cliff ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Future of the development stack?
Hey astronauts We have been planning features for SUSE Manager and we are asking ourselves if for some of them it makes sense to do it with the current stack. As part of the CSS re-factoring upstream we lost all our re-branding work, which is fine, because we had forked the CSS so we kind of deserve it :-). However even by doing it by cascading a .css file at the end, it is cumbersome to override the previous styles. The world outside keeps moving and people are nowadays solving these problems by standardizing the css framework a bit eg: twitter bootstrap, where you have a very nice standard theme to start with, and then you can customize it in a standard way, as all css rules are documented and standarized. We already are using bootstrap in other SUSE products, and other major opensource projects (eg: OpenStack, OpenShift, etc) are also using it. We could start using bootstrap for new features, but we would be afraid to have them rejected by upstream. But another possibility would be to contribute upstream a port of all the styling to bootstrap from the beginning, which would be a mega-patch, but we would not start working on something like this without having discussed whether this is wanted or not. This would mean basically replace all css rule names of all pages. Similar discussions go in other areas of the web stack. We are realizing for some features we could avoid struts and use a client side Javascript framework (AngularJS, batman.js, etc) and have the Java web framework provide the data. Would features using a client side framework be rejected? I wanted to ask what is upstream strategy on these topics. Which kinds of contributions would be welcome and desired by Redhat (that is the biggest contributor)? Which aren't?, so that we, SUSE, as a frequent contributor and community members could align ourselves to this. We are trying to keep SUSE Manager as close to Spacewalk as possible, but we also don't want to get stuck without good reasons. Regards, -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
