Re: [Spacewalk-devel] Twitter Bootstrap: Standardizing the CSS framework?
% >> - Spacewalk code is very "distro" oriented. % > % > In what way? In the way that the team tries hard to release binary % > signed rpms with each release to allow the administrators just upgrade % > the software without having to compile it? % % No, that is fine. Just that it is assumed (and in its own right) that % the administrator runs Fedora, and therefore .specs, some Makefiles and % even some code is distro specific. Well they are closely tied to Fedora and EL clones because majority of our users and contributors runs these distros. On the other hand we are open to make changes which simplify building Spacewalk on other distributions (on assumption they won't hurt current users). % >>Spacewalk is very tied to Fedora in this regard. % > % > Not really -- all recent Spacewalk releases were done both on Fedoras % > *and* on RHEL 5 and 6. % % Ok, I did not consider those different. Well in fact they are very different e.g. tomcat 7 vs tomcat 5 and tomcat 6, systemd vs. SysV init, python 2.7 vs 2.4 and 2.6, etc. And all these differences are IMHO nicely handled in specs. % > Why didn't you send those %ifdefs for review? If this is the only % > thing which blocks you do do Spacewalk vanilla releases on SUSE, I'm % > sure the Spacewalk team will be happy to consider those patches for % > master. % % Agreed. I started a new thread about this. % % >> - If you do a feature in Spacewalk master, you just do it and commit it. % >> We have to ask for review and then the feature may not be accepted. % >> Therefore the inverse work-flow, cherry-picking in our tree what looks % >> good to upstream, makes more sense. % > % > There are SUSE developers who have commit access to Spacewalk git, % > based on their history of providing sensible bug fixes and % > contributions. Trust is built over time. If you start with small fixes % > and features, if the patches are clean against master and they are % > correct and not disturbing the rest of the Spacewalk, you will build % > trust for future big changes that you may have planned. % % Fully agreed. I am not complaining about this. It makes total sense. % What I want you to realize is that we don't have that level of control: % eg. you can do features for several months and be sure it will land % upstream). Our process right now just fits our resources and control. % % Making a more vanilla master build on plain SUSE may help us do at least % the changes that _do_not_need_ to start the other way around upstream % first. I think we will invest some time to improve this because I see % some opportunities, and may be some value for openSUSE as well. Definitely, I can see a lot of people trying to build Spacewalk packages in build.opensuse.org they will appreciate for sure. % >> - Stuff like porting pages, happened as the side-effect of features we % >> will have anyway in our tree but we don't know yet if we will be % >> accepted upstream, % > % > The longer you wait and the longer you hack in your tree, the bigger % > the patchset will be when you decide to show ti upstream, and the % > harder will be for upstream to easily accept the feature. % % We know this, we take this decisions in a pragmatic way. Sometimes we % just decide consciously that we will take a fork-debt, and sometimes we % decide to pay it back. % % > Check that communication again. I raised some general questions about % > the overall client -- server mechanism, issues that we saw with it in % > the past, and how it could be improved. I did not see answer that % > would indicate willingness to work on existing issues to improve the % > situation and maybe get the ssh push feature in as a well aligned % > part of the future setup. It was presented as mostly additional code % > which increased the complexity of the code (duplication of the % > scheduling functionality), solution that you propose in one form % > without being prepared to contribute to improving the overall setup. % % Yes, one could see this as duplicate from the "push" side, but that was % not the core of it. The core was when the clients could not reach the % client. You stated "the first scenario does not sound that interesting % to me". This is fine. I gave an example of this scenario: Spacewalk in % the internal network, clients in a public cloud. % % We totally agree with upstream disagreeing. The problem is that in this % case we could not move forward. What is "interesting" or not as a % problem is subjective, and in this case we did not have the power. % Imagine somebody in the community did not find ABRT support % interesting?. This situation is fine and makes sense due to the amount % of contributions from the diverse stakeholders. But control is a fact, % and we can't see "master" in the same way you do. % % >> We should really figure out a "run from source" here :-) % > % > In the Spacewalk team, some developers run Spacewalk in their % > developer's setup which I assume is equivalent to the
Re: [Spacewalk-devel] Twitter Bootstrap: Standardizing the CSS framework?
On 01/08/13 10:05, Jan Pazdziora wrote: > On Fri, Jul 26, 2013 at 03:06:47PM +0200, Duncan Mac-Vicar P. wrote: >> >> Yes, we do all development on SUSE Manager and then rebase against >> master what we want to upstream. It makes total sense. > > It may make sense from SUSE's point of view. Not sure it makes sense > from upstream project health point of view. It would not be very different. We could do a long feature against master, not having it accepted, and then still having to backport it. > >> - Spacewalk code is very "distro" oriented. > > In what way? In the way that the team tries hard to release binary > signed rpms with each release to allow the administrators just upgrade > the software without having to compile it? No, that is fine. Just that it is assumed (and in its own right) that the administrator runs Fedora, and therefore .specs, some Makefiles and even some code is distro specific. >> Spacewalk is very tied to Fedora in this regard. > > Not really -- all recent Spacewalk releases were done both on Fedoras > *and* on RHEL 5 and 6. Ok, I did not consider those different. > Why didn't you send those %ifdefs for review? If this is the only > thing which blocks you do do Spacewalk vanilla releases on SUSE, I'm > sure the Spacewalk team will be happy to consider those patches for > master. Agreed. I started a new thread about this. >> - If you do a feature in Spacewalk master, you just do it and commit it. >> We have to ask for review and then the feature may not be accepted. >> Therefore the inverse work-flow, cherry-picking in our tree what looks >> good to upstream, makes more sense. > > There are SUSE developers who have commit access to Spacewalk git, > based on their history of providing sensible bug fixes and > contributions. Trust is built over time. If you start with small fixes > and features, if the patches are clean against master and they are > correct and not disturbing the rest of the Spacewalk, you will build > trust for future big changes that you may have planned. Fully agreed. I am not complaining about this. It makes total sense. What I want you to realize is that we don't have that level of control: eg. you can do features for several months and be sure it will land upstream). Our process right now just fits our resources and control. Making a more vanilla master build on plain SUSE may help us do at least the changes that _do_not_need_ to start the other way around upstream first. I think we will invest some time to improve this because I see some opportunities, and may be some value for openSUSE as well. >> - Stuff like porting pages, happened as the side-effect of features we >> will have anyway in our tree but we don't know yet if we will be >> accepted upstream, > > The longer you wait and the longer you hack in your tree, the bigger > the patchset will be when you decide to show ti upstream, and the > harder will be for upstream to easily accept the feature. We know this, we take this decisions in a pragmatic way. Sometimes we just decide consciously that we will take a fork-debt, and sometimes we decide to pay it back. > Check that communication again. I raised some general questions about > the overall client -- server mechanism, issues that we saw with it in > the past, and how it could be improved. I did not see answer that > would indicate willingness to work on existing issues to improve the > situation and maybe get the ssh push feature in as a well aligned > part of the future setup. It was presented as mostly additional code > which increased the complexity of the code (duplication of the > scheduling functionality), solution that you propose in one form > without being prepared to contribute to improving the overall setup. Yes, one could see this as duplicate from the "push" side, but that was not the core of it. The core was when the clients could not reach the client. You stated "the first scenario does not sound that interesting to me". This is fine. I gave an example of this scenario: Spacewalk in the internal network, clients in a public cloud. We totally agree with upstream disagreeing. The problem is that in this case we could not move forward. What is "interesting" or not as a problem is subjective, and in this case we did not have the power. Imagine somebody in the community did not find ABRT support interesting?. This situation is fine and makes sense due to the amount of contributions from the diverse stakeholders. But control is a fact, and we can't see "master" in the same way you do. >> We should really figure out a "run from source" here :-) > > In the Spacewalk team, some developers run Spacewalk in their > developer's setup which I assume is equivalent to the "run from > source" wish. It's not my preferred approach as it in the past > lead to different setup being used than what we then released to > users, leading to missed bugs. However, I can well understand the > desire to do so for some reason, so if
Re: [Spacewalk-devel] Twitter Bootstrap: Standardizing the CSS framework?
On Fri, Jul 26, 2013 at 03:06:47PM +0200, Duncan Mac-Vicar P. wrote: > > Yes, we do all development on SUSE Manager and then rebase against > master what we want to upstream. It makes total sense. It may make sense from SUSE's point of view. Not sure it makes sense from upstream project health point of view. > - Spacewalk code is very "distro" oriented. In what way? In the way that the team tries hard to release binary signed rpms with each release to allow the administrators just upgrade the software without having to compile it? > It is not possible right now > to "run" it from the source tree. What are the patches to make it possible? > It needs packaging and "productizing" > in order to run it. We figured that's exactly how our users would want to use it. > Spacewalk is very tied to Fedora in this regard. Not really -- all recent Spacewalk releases were done both on Fedoras *and* on RHEL 5 and 6. > Running vanilla Spacewalk on SUSE would be a big effort and %ifdefs in > the spec files (like they are in our tree. /srv/www vs /var/www anyone) Why didn't you send those %ifdefs for review? If this is the only thing which blocks you do do Spacewalk vanilla releases on SUSE, I'm sure the Spacewalk team will be happy to consider those patches for master. > - If you do a feature in Spacewalk master, you just do it and commit it. > We have to ask for review and then the feature may not be accepted. > Therefore the inverse work-flow, cherry-picking in our tree what looks > good to upstream, makes more sense. There are SUSE developers who have commit access to Spacewalk git, based on their history of providing sensible bug fixes and contributions. Trust is built over time. If you start with small fixes and features, if the patches are clean against master and they are correct and not disturbing the rest of the Spacewalk, you will build trust for future big changes that you may have planned. > - Stuff like porting pages, happened as the side-effect of features we > will have anyway in our tree but we don't know yet if we will be > accepted upstream, The longer you wait and the longer you hack in your tree, the bigger the patchset will be when you decide to show ti upstream, and the harder will be for upstream to easily accept the feature. > so we can't start the other way around, and we can't > decide whether we do or not a feature based on whether upstream will > take it or not (like it happened with SSH push). Check that communication again. I raised some general questions about the overall client -- server mechanism, issues that we saw with it in the past, and how it could be improved. I did not see answer that would indicate willingness to work on existing issues to improve the situation and maybe get the ssh push feature in as a well aligned part of the future setup. It was presented as mostly additional code which increased the complexity of the code (duplication of the scheduling functionality), solution that you propose in one form without being prepared to contribute to improving the overall setup. > We should really figure out a "run from source" here :-) In the Spacewalk team, some developers run Spacewalk in their developer's setup which I assume is equivalent to the "run from source" wish. It's not my preferred approach as it in the past lead to different setup being used than what we then released to users, leading to missed bugs. However, I can well understand the desire to do so for some reason, so if there are any patches to make it easier, just submit them for review. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Twitter Bootstrap: Standardizing the CSS framework?
On 26/07/13 14:05, Tomas Lestach wrote: > How can we be sure, that you cover all the Spacewalk pages, if you focus > on downstream, that has a different set of pages? > If the sent patch was against Suse Manager, I suppose that you do not > really work with Spacewalk itself. > So, are you going to verify the upcoming work only on Suse Manager > or on Spacewalk as well? Yes, we do all development on SUSE Manager and then rebase against master what we want to upstream. It makes total sense. - Spacewalk code is very "distro" oriented. It is not possible right now to "run" it from the source tree. It needs packaging and "productizing" in order to run it. Spacewalk is very tied to Fedora in this regard. Running vanilla Spacewalk on SUSE would be a big effort and %ifdefs in the spec files (like they are in our tree. /srv/www vs /var/www anyone) - If you do a feature in Spacewalk master, you just do it and commit it. We have to ask for review and then the feature may not be accepted. Therefore the inverse work-flow, cherry-picking in our tree what looks good to upstream, makes more sense. - Stuff like porting pages, happened as the side-effect of features we will have anyway in our tree but we don't know yet if we will be accepted upstream, so we can't start the other way around, and we can't decide whether we do or not a feature based on whether upstream will take it or not (like it happened with SSH push). Of course this may change in the future and at some point it may be more productive to develop on Spacewalk master. We should really figure out a "run from source" here :-) Now, going back to how we would do the Bootstrap work, I guess it would make more sense to do it in Spacewalk master, but I haven't really thought how to do it. May be just develop on a Fedora platform for this specific case. Now, SUSE Manager pages are not that different. We have additional pages, but the existing ones are more or less the same. Some features we are working on for first time touches fragments of pages everywhere, and that is the reason why we may not make much of a difference in terms of conflicts by merging the bootstrap stuff. -- 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] Twitter Bootstrap: Standardizing the CSS framework?
Duncan Mac-Vicar P. wrote: % The patch is against SUSE Manager, as I mentioned it is a quick port of % the basics. I sent it mostly so that you get an idea of what is touched. % % I will try to make a patch against master if you really want to "see" it. % % > Btw. do you plan to apply the bootstrap framework to perl pages as they are? % % Well, if we apply it, we will need to fix everything otherwise we will % not be able to release ourselves. What I am not sure is how clean the % initial commit to master can be, as there will be always stuff that will % need fixing and lot of eyes stabilizing it. Well, for me - after applying initial changes nothing should be visibly broken (at first sight). Also there should be current Spacewalk branding ported to new toolkit so users won't (nearly) notice the change of internals. % We have a bunch of perl pages already ported to Java as part of a % feature we are doing, but I guess there is still more Perl around. % % Another possible workaround would be to use LESS features to auto-fix % incomplete ports. We can have a compat.css with the original styles % defined using LESS mixins. Yes, making both original and new pages visually compatible is also important. Regards, -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Twitter Bootstrap: Standardizing the CSS framework?
Duncan Mac-Vicar P. wrote: % The patch is against SUSE Manager, as I mentioned it is a quick port of % the basics. I sent it mostly so that you get an idea of what is touched. % % I will try to make a patch against master if you really want to "see" it. % % > Btw. do you plan to apply the bootstrap framework to perl pages as they are? % % Well, if we apply it, we will need to fix everything otherwise we will % not be able to release ourselves. What I am not sure is how clean the % initial commit to master can be, as there will be always stuff that will % need fixing and lot of eyes stabilizing it. % % We have a bunch of perl pages already ported to Java as part of a % feature we are doing, but I guess there is still more Perl around. That's great, I'd really love to see them in Spacewalk. Please send patches to us. % Another possible workaround would be to use LESS features to auto-fix % incomplete ports. We can have a compat.css with the original styles % defined using LESS mixins. Regards, -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Twitter Bootstrap: Standardizing the CSS framework?
> Well, if we apply it, we will need to fix everything otherwise we > will > not be able to release ourselves. What I am not sure is how clean the > initial commit to master can be, as there will be always stuff that > will > need fixing and lot of eyes stabilizing it. Well, if we need to make any change in downstream, we first make the changes in Spacewalk and after the feature/bug fix looks good, we can take it over to downstream. Regarding new stuff, upstream is for us the primary focus, because we know that every Spacewalk flaw makes it to our downstream product as well. Your work flow seems to be the other way around. You'd like to work on the downstream and then to get some parts back to upstream. This is generally another approach. > We have a bunch of perl pages already ported to Java as part of a > feature we are doing, but I guess there is still more Perl around. So, if you have a different number of ported perl pages than the upstream, how can the final patch be applicable for upstream? How can we be sure, that you cover all the Spacewalk pages, if you focus on downstream, that has a different set of pages? If the sent patch was against Suse Manager, I suppose that you do not really work with Spacewalk itself. So, are you going to verify the upcoming work only on Suse Manager or on Spacewalk as well? > Another possible workaround would be to use LESS features to auto-fix > incomplete ports. We can have a compat.css with the original styles > defined using LESS mixins. Yes, this sounds like a workaround, not like a nice complete work. Regards, -- Tomas Lestach Red Hat Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Twitter Bootstrap: Standardizing the CSS framework?
On 26/07/13 09:05, Tomas Lestach wrote: > Hello Duncan, > > I wasn't able to apply your patch. > Could you send your patch rebased on latest master? Or at least write me > against what commit I shall apply it. > It seems that java/code/webapp/WEB-INF/includes/header.jsp version against > that > the patch is done, was never in Spacewalk. > > Please create your patch using: git format-patch The patch is against SUSE Manager, as I mentioned it is a quick port of the basics. I sent it mostly so that you get an idea of what is touched. I will try to make a patch against master if you really want to "see" it. > Btw. do you plan to apply the bootstrap framework to perl pages as they are? Well, if we apply it, we will need to fix everything otherwise we will not be able to release ourselves. What I am not sure is how clean the initial commit to master can be, as there will be always stuff that will need fixing and lot of eyes stabilizing it. We have a bunch of perl pages already ported to Java as part of a feature we are doing, but I guess there is still more Perl around. Another possible workaround would be to use LESS features to auto-fix incomplete ports. We can have a compat.css with the original styles defined using LESS mixins. -- 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] Twitter Bootstrap: Standardizing the CSS framework?
Hello Duncan, I wasn't able to apply your patch. Could you send your patch rebased on latest master? Or at least write me against what commit I shall apply it. It seems that java/code/webapp/WEB-INF/includes/header.jsp version against that the patch is done, was never in Spacewalk. Please create your patch using: git format-patch Btw. do you plan to apply the bootstrap framework to perl pages as they are? Thank you, -- Tomas Lestach Red Hat Satellite Engineering, Red Hat - Original Message - > From: "Duncan Mac-Vicar P." > To: "spacewalk-devel" > Sent: Thursday, July 25, 2013 7:00:15 PM > Subject: [Spacewalk-devel] Twitter Bootstrap: Standardizing the CSS > framework? > > > Hey astronauts > > Twitter bootstrap (http://twitter.github.io/bootstrap/) is a CSS > framework that in addition to provide a good looking "default" theme, > it > also provides: > > - A very simple and standardized way of building the UI, with > provided > styles for common UI elements > - Grid, Javascript plugins/features, typography, forms > - Awesome documentation (see the website) > - Responsive design > - Font icons (with Glyph-icons or Font-Awesome) > - So popular that apart of good docs there is a big community around > - It works with LESS, which makes reusing and customizing CSS very > easy > - It has explicit instructions on how to customize it. > > We find Bootstrap a very attractive path to: > > - Cleanup the markup and move it to the current state of the art > - Make it very defined an easier for RHN and SUSE Manager to be a > customized version of Spacewalk. > - Have a better toolkit at hand for doing new user interfaces and/or > optional modules. > > We started to explore how it would look to change the CSS framework. > At > the end it resulted not that complicated, as once you set the > framework, > lot of the UI is generated in Java code and custom tags, which have > the > styles hard-coded. > > So I did an initial port (See patch attached). Mostly the base layout > and the tags. There are a lot of jsp pages with plain html that need > porting by hand, but hey, it is a good start. > > Here is a gallery with Spacewalk being customized by just changing a > LESS [²] file with variables (similar to what > http://twitter.github.io/bootstrap/customize.html#variables offers): > > http://postimg.org/gallery/7dwszo2g/35f216dc/ > > So of course this patch needs the 80% remaining work. The SUSE > Manager > team would be willing to do this work if upstream is willing to merge > it > [¹]. > > As 2.0 was just released, this may be a good timing to merge new > stuff. > > If this is accepted we could start working in a final patch in order > to > merge it some months from now. > > What do you think? > Other ideas? > > Regards, > > [¹] (we may still move forward with it at cost of a bigger fork, and > we > really want to make a decision soon to base future work on this). > > [²] http://lesscss.org, works precompiled (compiling to css at build > time) or at runtime with a javascript implementation (eg. for > development). There is a java > implementation as well: http://www.asual.com/lesscss > > -- > 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 ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
