Re: one concrete idea for fedora
On Mon, 2017-08-21 at 19:41 -0700, stan wrote: > On Mon, 21 Aug 2017 18:19:09 +0100 > Sérgio Bastowrote: > > > and How I create one boot.iso (or netinstall iso ) ? > > I haven't actually done this, and you will probably get better > responses on the users or test lists, but here are some links that > might help you. > > https://fedoraproject.org/wiki/How_to_create_and_use_a_Live_CD > > https://www.watters.ws/mediawiki/index.php/Build_a_custom_Fedora_inst > all_CD > > https://forums.fedoraforum.org/showthread.php?t=303200 > > http://everyday-tech.com/create-a-custom-centos-iso/ > > https://superuser.com/questions/699709/how-to-create-a-modified-fedor > a-iso if we add boot.iso to http://dl.fedoraproject.org/pub/alt/live-respins/ we near to have a stable release ... (boot.iso can have a later kernel and more stable core packages ) Thanks -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: one concrete idea for fedora
On Sun, 2017-08-06 at 10:06 -0400, Matthew Miller wrote: > On Sun, Aug 06, 2017 at 03:42:08AM +0100, Sérgio Basto wrote: > > I'm very sorry for my bad mood and I apologize. > > But what I want emphasize is that we are losing the concept of > > stability not just in Fedora, it is in many other projects, KDE for > > example, simply don't have any "stable" or LTS release or something > > like that, that is real stable and solid as rock. > > LTS and unchanging really isn't in Fedora's charter. But, we do want > releases to be solid for daily use, and it's true that a stream of > updates can detract from that. I really would like us to follow the > long-standing official updates policy > https://fedoraproject.org/wiki/Updates_Policy which says that updates > within a release should have minimal disruption. > > I know this is at odds with many developer and packager desire to > make > updated software available quickly, and I know there are a subset of > users who like this too. The Modularity initiative aims to make it > easy for us to do _both_. > > > For packages maintainers like me, that maintain packages in free > > time, > > we got more and more work and begins to become impossible maintain > > all > > packages correctly, we got lot of packages that aren't updated > > because > > people simple don't have time, so should be important, that some > > team > > take care of completely out-date packages, like, for example, > > gitlib > > [1], also maybe in wild changes like systemd, selinux, appdata, > > etc, > > the team help packagers on maintain his packages. > > I'm sorry, I'm not sure I understand what you're saying here. Do you > mean that it would be nice to have a team of people who would work to > update packages across the distro if there are big changes to core > packages? We actually have that, in the Proven Packagers team. See > the > "Mass package change proposal" for an example of this in action. yes , is that what I meant, I need help on selinux :) and webalizer ... Thanks , best regards. > -- > Matthew Miller >> Fedora Project Leader > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: one concrete idea for fedora
On Sun, Aug 06, 2017 at 03:42:08AM +0100, Sérgio Basto wrote: > I'm very sorry for my bad mood and I apologize. > But what I want emphasize is that we are losing the concept of > stability not just in Fedora, it is in many other projects, KDE for > example, simply don't have any "stable" or LTS release or something > like that, that is real stable and solid as rock. LTS and unchanging really isn't in Fedora's charter. But, we do want releases to be solid for daily use, and it's true that a stream of updates can detract from that. I really would like us to follow the long-standing official updates policy https://fedoraproject.org/wiki/Updates_Policy which says that updates within a release should have minimal disruption. I know this is at odds with many developer and packager desire to make updated software available quickly, and I know there are a subset of users who like this too. The Modularity initiative aims to make it easy for us to do _both_. > For packages maintainers like me, that maintain packages in free time, > we got more and more work and begins to become impossible maintain all > packages correctly, we got lot of packages that aren't updated because > people simple don't have time, so should be important, that some team > take care of completely out-date packages, like, for example, gitlib > [1], also maybe in wild changes like systemd, selinux, appdata, etc, > the team help packagers on maintain his packages. I'm sorry, I'm not sure I understand what you're saying here. Do you mean that it would be nice to have a team of people who would work to update packages across the distro if there are big changes to core packages? We actually have that, in the Proven Packagers team. See the "Mass package change proposal" for an example of this in action. -- Matthew MillerFedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: one concrete idea for fedora
On Fri, 2017-08-04 at 09:24 -0400, Matthew Miller wrote: > On Fri, Aug 04, 2017 at 11:23:30AM +0100, Sérgio Basto wrote: > > Do a stable release do Fedora 25.1 or 26.1 > > > > install a live disk and have 2 bg of updates is a joke, > > you may take double of the time but do something that we can call > > it > > stable . > > Making a stable release like this would imply that we go through the > QA > effort that we do with our actual stable releases. This is a lot of > work. So, this idea is much easier said than done. > > Note, though, that if you use the network installer instead of the > live > CD, you can have the updates repo eanbled for the initial install, so > you *just* get the new versions of packages. Matthew and all in general , I'm very sorry for my bad mood and I apologize. But what I want emphasize is that we are losing the concept of stability not just in Fedora, it is in many other projects, KDE for example, simply don't have any "stable" or LTS release or something like that, that is real stable and solid as rock. For packages maintainers like me, that maintain packages in free time, we got more and more work and begins to become impossible maintain all packages correctly, we got lot of packages that aren't updated because people simple don't have time, so should be important, that some team take care of completely out-date packages, like, for example, gitlib [1], also maybe in wild changes like systemd, selinux, appdata, etc, the team help packagers on maintain his packages. About ISOs available at http://dl.fedoraproject.org/pub/alt/live-respin s/ , yeah I forgot that, IHMO, it should be mention on https://getfedor a.org/ . Also I notice it now :) , if we also have netinstall images updated, it will be awesome. About "Making a stable release like this would imply that we go through the QA " OK I know, anyway I think you should consider that, I think they will have much less work than the first release, because usually when we respin packages that are in stable releases we don't have any problem. On F25 , if I'm correct, we got rpm update of backend database and it is awful when we do an rpm command in a middle of one dnf upgrade after a fresh live installation, we got a big rpm error and and we will need rebuild rpm database I guess etc. So with one updated live or with F25.1 release we could have more sense of stability. Best regards and thanks, [1] https://bugzilla.redhat.com/show_bug.cgi?id=822844 > -- > Matthew Miller >> Fedora Project Leader > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org