On Fri, Jun 21, 2013 at 6:55 AM, Michiel van Es <[email protected]> wrote:
> > > On 06/17/2013 10:48 AM, Gordan Bobic wrote: > >> On Sat, 15 Jun 2013 16:33:55 +0200, Michiel Van Es <[email protected]> >> wrote: >> >> Hook me up. >>> >> >> Done. >> > > I added some information to the wiki regarding the v2 image and use the > Interworx image as an alternative method. > Please check if this is OK for you? > > > >> I would add the following information or priority list to your >>> website (I would ditch the wiki since you now have to maintain 2 >>> websites instead of just 1, add the wiki information to a seperate >>> page on the main website): >>> >> >> They have fundamentally different purposes - I don't really see >> them as unifiable, nor do I see it as particularly desirable to >> do so. >> > > Ok, you can do both, I would add the wiki information as a seperate page > to your website but I would at least create a better menu for people > looking for help: > > - a wiki link > - a support link > > > >> - downloads page: add a v1 and v2 raspberry pi image that works and >>> is easy installable with dd (don't mention notes about not working >>> images and how to fix it - the .img file should just work like all >>> other distro's). >>> >> >> Noted. >> >> - faq page: installation tips, quirks that need to be fixed after >>> booting up the raspberry (the udev file, what to do if you resize the >>> 2nd partition, ntp/date settings, etc.) >>> >> >> Surely your first point above renders this point redundant, does it not? >> > > Perhaps not the installation quirks but you can mention where the name > come from, how often it will be updated, again mention where people can > find the wiki and support. > That's where a FAQ is for. > > > >> - roadmap: v2 image that works without copying kernels (an .img file >>> which you can dd and is production ready is much wanted), when updates >>> will be pushed and synched; the updates from the upstream vendor do >>> not only contain security fixes but also bugfixes which are most >>> wanted - who wants to run an OS which is lacking up to date software? >>> >> >> I understand where you are coming from, and the intention is to get >> an automated build system in place that will filter through all >> upstream changes for packages that do not require modifying. >> >> I do not, however, see this as big a deal as you are making it out >> to be. I usually specifically _exclude_ all packages I use in >> production from yum updates, and individually test them extensively >> on a scratch system before updating them. Just because something has >> been updated upstream and had bugs fixed does not mean that it hasn't >> introduced new bugs that will affect your production system. >> > > Then we both have a different opinion in how you want to see a product get > updates. > I am not sure how the rest of the list sees this but working for 2 > international companies in the past using +500 Red Hat/CentOS servers has > learned me that regular patches are more then welcome. > (kernel bugs with nfs locks, apache dos range header, sudo exploitation, > etc.). > Besided that, Red Hat intensively tests its bugfixes and patches, it's not > Fedora... > > You're the only distro who is not updating its packages, other distros > (fedora, raspian, debian wheezy, arch) are frequently updating. > > Why I still choose this distro to run on my Raspberry PI? > Because I like Red Hat/CentOS/Scientific/Red Sleeve as a stable OS. I have to agree with Michiel. I was excited to see this distro, but I resist using it in favor of other distros because of this issue. I used to work for Red Hat and I still use RHEL-like distros in my work/personal life. A distribution should not dictate policy ("rarely, or don't ever update your OS"), but rather functionality ("we will make available the bug fixes and new features as they become available"), and give the end user the *choice* whether or not to update their systems, as they see fit. I get what is being said. While its generally best practice for production, mission-critical systems to not be updated without a thorough bug scrub on a dev system, first, its still often a requirement that the system be updated when that update provides a fix, drivers for new hardware, a new feature that is useful, etc. We shouldn't dictate which updates are important for an end-user and which are not. Also, the fact of the matter is that some systems aren't mission critical but we want the familiarity/functionality of the distro. For example, I'd like to have 3 Raspberry Pi's that are clustered, using a distro's cluster that I'm familiar with and use all day at work, for some home services for which I could care less if I had to reboot a pi or 2.... -Marc > > >> , an EPEL solution or ditch it for the sake of the focus on the >>> stability of Redsleeve itself >>> >> >> It comes down to package requirements. Not having a package >> available is a nuissance. Having a version that is slightly out >> of date and contains a bug in functionality that you don't use >> is much less of an issue. >> > > Then don't mention it as main topic on the main website since the > information is not correct and misleading (i was not the only one asking > about the EPEL packages). > > > >> Either way, once the automated build system is in place both >> issues will disappear. >> >> (or put it on the roadmap for Q4 2013 or such). >>> >> >> There is no roadmap, nor is there a plan for one to exist - this >> is a project, not a product. >> > > A project also has a roadmap, people just want to know when they can > expect things and yes they keep in mind that the product/project is done > with best effort. > There is a difference between getting something done ETA Q4 2013/Q1 2014 > and telling nothing. > > > >> - installation and configuration page >>> - support page: mailinglist information and link to mailinglist(s) >>> >> >> Is the front page not a visible enough place for a link to the mailing >> list? It has always been there. Go to: >> http://www.redsleeve.org, hit Ctrl-F and punch in "mailing". >> >> I'm not sure what I can do to make it more visible, short of putting >> it in blink tags. :) >> > > Its hidden in a sentence under an article about an alpha 2 > release..doesn't sound like an official place to me > > > >> Then people know what to expect, now people read about an alpha 2 >>> version which does not work on the V2, an EPEL repository which does >>> not work or any more information and no support page (I had to google >>> the mailinglist but I could not find it on the website itself). >>> >> >> See above - you clearly didn't look hard enough. :) >> > > I do but people should not Ctrl+F in sourcecode or old articles to find > the obvious right? > > > >> I know this must be a lot to set up but I think a lot of people are >>> willing to help out (I've seen people willing to set up mirrors, the >>> wiki page and to add 3rd party repo's (like Dag Wieers) and give >>> Redsleeve a boost. >>> >> >> I have created wiki accounts for everyone who requested them. >> You should have your login credentials in your inbox. >> > > Thanks, got them and already added *hopefully* some helpful information > for newcomers. > > > >> And if possible, upload a smaller but better resolution redsleeve >>> image to the main website, the current one is not very good ;) >>> >> >> I'll see what I can do. Artwork was done by a friend, I'll >> see if/when he has a chance to do something about it. >> > > I can also change it for you if needed, my gf is a visual designer and can > help out if needed ;) > > >> Gordan >> > > Michiel > > ______________________________**_________________ >> users mailing list >> [email protected] >> http://lists.redsleeve.org/**mailman/listinfo/users<http://lists.redsleeve.org/mailman/listinfo/users> >> >> ______________________________**_________________ > users mailing list > [email protected] > http://lists.redsleeve.org/**mailman/listinfo/users<http://lists.redsleeve.org/mailman/listinfo/users> >
_______________________________________________ users mailing list [email protected] http://lists.redsleeve.org/mailman/listinfo/users
