Re: F21 schedule: what would you do with more time?
On 08/22/2013 05:15 PM, Jaroslav Reznik wrote: - Original Message - On Thu, Aug 22, 2013 at 11:03 PM, Matthew Miller mat...@fedoraproject.org wrote: What things we do _now_ could be improved with the investment of some effort? Perl rebuild always take a lot of time, and as a result it will affect the mass rebuild. It's unfortunately about Perl release timing... Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Upstream was asking for Fedora usual date of release, so what could we say ;-) It's twice a year. Marcela -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 schedule: what would you do with more time?
- Original Message - work on a composedb that gives easier insight into where things are in the release cycles. where releases are in their cycle, i.e end of life, stable or in development, for stable releases when updates where last pushed, or if updates push is in progress, for in development, last nightly compose, last milestone compose, and if things are in progress. Nice, I offer my help with it, something we really need. Just let me know. Jaroslav ive probably missed a bunch of things here but thats a brief dump of some of what ive been wanting to work on for ages and not had thetime to do so. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlIWMXMACgkQkSxm47BaWffsKgCffKmZQCYcFT31N0Eday93+zFu QTkAmwYqf9b2ZNMvW0sRY5iG5lK4u+dA =GrLI -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 schedule: what would you do with more time?
- Original Message - Dne 23.8.2013 10:24, Peter Robinson napsal(a): On Thu, Aug 22, 2013 at 4:12 PM, Matthew Miller mat...@fedoraproject.org wrote: On Thu, Aug 22, 2013 at 11:08:18PM +0800, Christopher Meng wrote: What things we do _now_ could be improved with the investment of some effort? Perl rebuild always take a lot of time, and as a result it will affect the mass rebuild. Apparently less so with all the new ARM builders, right? Is this something you're saying could be improved, or is it just something we always need to budget time for? The perl upgrade process is some what manual and there's a whole bunch of circular dependencies that cause/require a bunch of manual bootstrapping of certain packages so the perl mass rebuild is some what different to a standard all in mass rebuild. Peter The same applies for Ruby. It is definitely not just fire the rebuild and forget. During the process, there is typically need to update some packages to be compatible with latest release, some were FTBFS already before, some others need bootstrap due to circular dependencies. I'd say we need a real solution for ordered rebuilds. Every team that needs this has a different tools/scripts to do it. Perl, I'd say Ruby, KDE (actually not ordered one), GNOME... And not usable by infra for mass rebuilds etc. Mirek, any ideas? ;-) Jaroslav Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 schedule: what would you do with more time?
On Sat, Aug 24, 2013 at 09:56:06AM +0200, Till Maas wrote: On Fri, Aug 23, 2013 at 09:33:59AM +0100, Peter Robinson wrote: On Thu, Aug 22, 2013 at 4:56 PM, Mat Booth fed...@matbooth.co.uk wrote: Here's my favourite bugbear: https://fedorahosted.org/packagedb/ticket/243 I have no idea why the package retirement process needs intervention from rel-eng.-- Mat Booth http://fedoraproject.org/get-fedora There's been discussion of adding fedpkg retire-package to fedpkg which would basically just open a dead.package file to allow you to add an entry and then remove the contents from git, block the package in koji, and retire it in the package DB. I don't think anyone has had the time to do this yet both in fedpkg and the backend although I suspect this gets a whole lot easier now with fedmsg. For the fedpkg/packaged DB integration you can try this patch: https://fedorahosted.org/fedpkg/attachment/ticket/8/0001-retire-packages-in-packagedb-as-well.patch If you first apply http://ur1.ca/f6nkk you can run fedpkg from the git repo directly to test it. I do not have a package to retire, therefore I was not able to test it yet. A script to get all retired packages from datanommer is also already working pretty good. It only needs integration to listen on fedmsg to get it completely automated: http://ur1.ca/f6xco Your two paste have expired, mind to send new ones with a longer lifespan? thanks, Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 schedule: what would you do with more time?
On Sun, Aug 25, 2013 at 09:41:56PM +0200, Pierre-Yves Chibon wrote: On Sat, Aug 24, 2013 at 09:56:06AM +0200, Till Maas wrote: On Fri, Aug 23, 2013 at 09:33:59AM +0100, Peter Robinson wrote: There's been discussion of adding fedpkg retire-package to fedpkg which would basically just open a dead.package file to allow you to add an entry and then remove the contents from git, block the package in koji, and retire it in the package DB. I don't think anyone has had the time to do this yet both in fedpkg and the backend although I suspect this gets a whole lot easier now with fedmsg. A script to get all retired packages from datanommer is also already working pretty good. It only needs integration to listen on fedmsg to get it completely automated: http://ur1.ca/f6xco Your two paste have expired, mind to send new ones with a longer lifespan? The fedpkg changes have been merged already and are on the way to updates-testing: https://git.fedorahosted.org/cgit/fedpkg.git The blocker scripts are here, the first one is meant to run permanently, the second one to run every now and then: http://till.fedorapeople.org/tmp/fedmsg_blocker.py http://till.fedorapeople.org/tmp/block_retired.py Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 schedule: what would you do with more time?
On Fri, Aug 23, 2013 at 09:33:59AM +0100, Peter Robinson wrote: On Thu, Aug 22, 2013 at 4:56 PM, Mat Booth fed...@matbooth.co.uk wrote: Here's my favourite bugbear: https://fedorahosted.org/packagedb/ticket/243 I have no idea why the package retirement process needs intervention from rel-eng.-- Mat Booth http://fedoraproject.org/get-fedora There's been discussion of adding fedpkg retire-package to fedpkg which would basically just open a dead.package file to allow you to add an entry and then remove the contents from git, block the package in koji, and retire it in the package DB. I don't think anyone has had the time to do this yet both in fedpkg and the backend although I suspect this gets a whole lot easier now with fedmsg. For the fedpkg/packaged DB integration you can try this patch: https://fedorahosted.org/fedpkg/attachment/ticket/8/0001-retire-packages-in-packagedb-as-well.patch If you first apply http://ur1.ca/f6nkk you can run fedpkg from the git repo directly to test it. I do not have a package to retire, therefore I was not able to test it yet. A script to get all retired packages from datanommer is also already working pretty good. It only needs integration to listen on fedmsg to get it completely automated: http://ur1.ca/f6xco Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 schedule: what would you do with more time?
On Thu, Aug 22, 2013 at 4:12 PM, Matthew Miller mat...@fedoraproject.orgwrote: On Thu, Aug 22, 2013 at 11:08:18PM +0800, Christopher Meng wrote: What things we do _now_ could be improved with the investment of some effort? Perl rebuild always take a lot of time, and as a result it will affect the mass rebuild. Apparently less so with all the new ARM builders, right? Is this something you're saying could be improved, or is it just something we always need to budget time for? The perl upgrade process is some what manual and there's a whole bunch of circular dependencies that cause/require a bunch of manual bootstrapping of certain packages so the perl mass rebuild is some what different to a standard all in mass rebuild. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 schedule: what would you do with more time?
On Thu, Aug 22, 2013 at 4:56 PM, Mat Booth fed...@matbooth.co.uk wrote: On 22 August 2013 16:03, Matthew Miller mat...@fedoraproject.org wrote: Based on discussion at Flock, on the devel mailing list, and in the FESCo meeting, we are looking for feedback on the idea of a longer release cycle for Fedora 21 -- not (right now at least) the bigger question of the 6-month cycle overall, but just, right now, slowing down for a release to get some things in order. Specifically, both Release Engineering and QA have clear needs (and even plans for) greater automatiion, but are also incredibly busy simply doing the things they need to do _now_ to get the release out the door. So, FESCo would like to see some specifics, like If we had one week with nothing else to worry about, we could have automated generation and upload of cloud images (to pick an example I personally care about). Or with six months of overall delay, we could have continuous integration testing of a key subset of rawhide. Or we could spend a couple of weeks and automate the new package and review workflow. What Infrastructure projects would be helped by this? Web and design team, would slowing down the release focus allow time to work on, oh, say, getting the Wiki beautiful (or does it not matter)? What else? As we look at Fedora.next ideas and possibly decide to start implementation in the F21 timeframe, we will likely find _new_ things that take specific work. Let's not worry about that right now. What things we do _now_ could be improved with the investment of some effort? Here's my favourite bugbear: https://fedorahosted.org/packagedb/ticket/243 I have no idea why the package retirement process needs intervention from rel-eng.-- Mat Booth http://fedoraproject.org/get-fedora There's been discussion of adding fedpkg retire-package to fedpkg which would basically just open a dead.package file to allow you to add an entry and then remove the contents from git, block the package in koji, and retire it in the package DB. I don't think anyone has had the time to do this yet both in fedpkg and the backend although I suspect this gets a whole lot easier now with fedmsg. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 schedule: what would you do with more time?
E.g. going after these: http://ausil.fedorapeople.org/**f20-failed.htmlhttp://ausil.fedorapeople.org/f20-failed.html Right now we have ~350+ broken packages, a lengthy series of broken deps, an unknown amount of defacto unmaintained packages and an unknown amout of maintainers having gone MIA. Agreed. What Infrastructure projects would be helped by this? A web infrastructure to * ease package orphanage. * launch AWOL/MIA requests * a unified koji/bodhi/bugzilla Web-GUI You think BZ is slow now? * much longer build.log holding time for FTBFS. I think this comes down to the amount of storage it takes and the amount we have available. Also, - faster builders: Introduction of the arm has significantly increased the turn around times of package building. - better mirroring: I am having the impression mirrormanager doesn't work well at all. E.g. this morning, yum sent me around the globe for rawhide and failed in the end, seemingly because all fast mirrors seem to be busy loading f20. TBF I don't believe this is anything to do with mirror manager at all, the fact is a lot of mirrors just don't hold rawhide or don't update it daily so they're at times out of date. Secondary arches have similar issues regarding those sorts of problems because there's a lot less mirrors of those. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 schedule: what would you do with more time?
On 08/23/2013 10:39 AM, Peter Robinson wrote: * a unified koji/bodhi/bugzilla Web-GUI You think BZ is slow now? What do you mean by now ... now as in comparison to yesterday, or in general. In general, my issues with bugzilla basically are two: - It's UI is clumsy to use for Fedora - filing or searching bugs requires a lot of user interaction, some of which are not easy to accomplish. I meanwhile have begun to favor searching BZ for some classes of BZs through the pkgdb (https://admin.fedoraproject.org/pkgdb/packages), because its UI seems easier to use. - The turnaround times, esp, during searches leaves much to be desired on my side. I have no idea about the cause, whether my gradually aging machine has become too slow for bugzilla, whether I am having a bad network connection to BZ@RH, whether my firefox/F19 is having problems or if bugzilla is having performance problems. All I can say, my subjective experience with bugzilla often is jerky responses to UI interactions. In most cases in the order of several seconds, but sometimes also in the order of several tenths of seconds, in rare cases in the order of several minutes. I meanwhile am leaning to enter and search BZ throuhg https://admin.fedoraproject.org/pkgdb/packages * much longer build.log holding time for FTBFS. I think this comes down to the amount of storage it takes and the amount we have available. Is that really that much? I am not asking for keeping all of a failed built forever. I am only asking to keep the last failed builts, or at least the log files of them. When it comes to estimating whether somebody might be able to help out, they are a valuable resoure. At least I stop looking into FTBFSes, when noticing the class of failure probably appears not to be in my domain of knowledge. - better mirroring: I am having the impression mirrormanager doesn't work well at all. E.g. this morning, yum sent me around the globe for rawhide and failed in the end, seemingly because all fast mirrors seem to be busy loading f20. TBF I don't believe this is anything to do with mirror manager at all, the fact is a lot of mirrors just don't hold rawhide or don't update it daily so they're at times out of date. Well, I am pretty sure the metalink files as being provided by dl.fedoraproject.org occasionally point me to mirrors which were out-of-sync. These incidents sometimes seem to be temporary, but I've also observed cases where mirror manager pointed me to mirrors which seem to have been busy syncing. This not only happens for rawhide and not only during branching, but occasionally also happens with fedora-updates. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 schedule: what would you do with more time?
Dne 23.8.2013 10:24, Peter Robinson napsal(a): On Thu, Aug 22, 2013 at 4:12 PM, Matthew Miller mat...@fedoraproject.org mailto:mat...@fedoraproject.org wrote: On Thu, Aug 22, 2013 at 11:08:18PM +0800, Christopher Meng wrote: What things we do _now_ could be improved with the investment of some effort? Perl rebuild always take a lot of time, and as a result it will affect the mass rebuild. Apparently less so with all the new ARM builders, right? Is this something you're saying could be improved, or is it just something we always need to budget time for? The perl upgrade process is some what manual and there's a whole bunch of circular dependencies that cause/require a bunch of manual bootstrapping of certain packages so the perl mass rebuild is some what different to a standard all in mass rebuild. Peter The same applies for Ruby. It is definitely not just fire the rebuild and forget. During the process, there is typically need to update some packages to be compatible with latest release, some were FTBFS already before, some others need bootstrap due to circular dependencies. Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 schedule: what would you do with more time?
On Fri, Aug 23, 2013 at 12:32 PM, Ralf Corsepius rc040...@freenet.de wrote: On 08/23/2013 10:39 AM, Peter Robinson wrote: * much longer build.log holding time for FTBFS. I think this comes down to the amount of storage it takes and the amount we have available. Is that really that much? And if it is, just compress them. 50-60 MB build logs compress to 1-2 MB with gzip (checked with webkitgtk and libreoffice). gzipped logs can be served so that they're directly viewable in browsers so there shouldn't be any inconvenience, on the contrary actually due to smaller download size, for example like this with Apache: Files *.log.gz ForceType text/plain AddEncoding x-gzip .gz /Files -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 schedule: what would you do with more time?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 23 Aug 2013 09:33:59 +0100 Peter Robinson pbrobin...@gmail.com wrote: On Thu, Aug 22, 2013 at 4:56 PM, Mat Booth fed...@matbooth.co.uk wrote: On 22 August 2013 16:03, Matthew Miller mat...@fedoraproject.org wrote: Based on discussion at Flock, on the devel mailing list, and in the FESCo meeting, we are looking for feedback on the idea of a longer release cycle for Fedora 21 -- not (right now at least) the bigger question of the 6-month cycle overall, but just, right now, slowing down for a release to get some things in order. Specifically, both Release Engineering and QA have clear needs (and even plans for) greater automatiion, but are also incredibly busy simply doing the things they need to do _now_ to get the release out the door. So, FESCo would like to see some specifics, like If we had one week with nothing else to worry about, we could have automated generation and upload of cloud images (to pick an example I personally care about). Or with six months of overall delay, we could have continuous integration testing of a key subset of rawhide. Or we could spend a couple of weeks and automate the new package and review workflow. What Infrastructure projects would be helped by this? Web and design team, would slowing down the release focus allow time to work on, oh, say, getting the Wiki beautiful (or does it not matter)? What else? As we look at Fedora.next ideas and possibly decide to start implementation in the F21 timeframe, we will likely find _new_ things that take specific work. Let's not worry about that right now. What things we do _now_ could be improved with the investment of some effort? Here's my favourite bugbear: https://fedorahosted.org/packagedb/ticket/243 I have no idea why the package retirement process needs intervention from rel-eng.-- Mat Booth http://fedoraproject.org/get-fedora There's been discussion of adding fedpkg retire-package to fedpkg which would basically just open a dead.package file to allow you to add an entry and then remove the contents from git, block the package in koji, and retire it in the package DB. I don't think anyone has had the time to do this yet both in fedpkg and the backend although I suspect this gets a whole lot easier now with fedmsg. to block packages in koji you need to be an admin. the plan is to teach pkgdb to block packages and get it access to a cert with admin privileges, then have fedpkg handle git and talking to pkgdb, then pkgdb can handle the blocking in koji. but no one has had the time to implement it. pkgdb needs to also make sure that packages can't be retired in stable Fedora's. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlIXlEkACgkQkSxm47BaWfewMgCfZf0ZGxqxTODi4tAMH87VQ+Iu 66oAn1722phEFrtdXr9HKlyUIQjLqRxW =yHHc -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 schedule: what would you do with more time?
On 08/22/2013 09:03 AM, Matthew Miller wrote: As we look at Fedora.next ideas and possibly decide to start implementation in the F21 timeframe, we will likely find _new_ things that take specific work. Let's not worry about that right now. What things we do _now_ could be improved with the investment of some effort? Some kind of continuous integration testing would be lovely - automatically build some dependent packages when one is updated and note any failures. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F21 schedule: what would you do with more time?
Based on discussion at Flock, on the devel mailing list, and in the FESCo meeting, we are looking for feedback on the idea of a longer release cycle for Fedora 21 -- not (right now at least) the bigger question of the 6-month cycle overall, but just, right now, slowing down for a release to get some things in order. Specifically, both Release Engineering and QA have clear needs (and even plans for) greater automatiion, but are also incredibly busy simply doing the things they need to do _now_ to get the release out the door. So, FESCo would like to see some specifics, like If we had one week with nothing else to worry about, we could have automated generation and upload of cloud images (to pick an example I personally care about). Or with six months of overall delay, we could have continuous integration testing of a key subset of rawhide. Or we could spend a couple of weeks and automate the new package and review workflow. What Infrastructure projects would be helped by this? Web and design team, would slowing down the release focus allow time to work on, oh, say, getting the Wiki beautiful (or does it not matter)? What else? As we look at Fedora.next ideas and possibly decide to start implementation in the F21 timeframe, we will likely find _new_ things that take specific work. Let's not worry about that right now. What things we do _now_ could be improved with the investment of some effort? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 schedule: what would you do with more time?
On Thu, Aug 22, 2013 at 11:08:18PM +0800, Christopher Meng wrote: What things we do _now_ could be improved with the investment of some effort? Perl rebuild always take a lot of time, and as a result it will affect the mass rebuild. Apparently less so with all the new ARM builders, right? Is this something you're saying could be improved, or is it just something we always need to budget time for? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 schedule: what would you do with more time?
- Original Message - On Thu, Aug 22, 2013 at 11:03 PM, Matthew Miller mat...@fedoraproject.org wrote: What things we do _now_ could be improved with the investment of some effort? Perl rebuild always take a lot of time, and as a result it will affect the mass rebuild. It's unfortunately about Perl release timing... Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 schedule: what would you do with more time?
On Thu, Aug 22, 2013 at 11:03 PM, Matthew Miller mat...@fedoraproject.org wrote: What things we do _now_ could be improved with the investment of some effort? Perl rebuild always take a lot of time, and as a result it will affect the mass rebuild. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 schedule: what would you do with more time?
On Thu, Aug 22, 2013 at 5:03 PM, Matthew Miller mat...@fedoraproject.org wrote: Based on discussion at Flock, on the devel mailing list, and in the FESCo meeting, we are looking for feedback on the idea of a longer release cycle for Fedora 21 -- not (right now at least) the bigger question of the 6-month cycle overall, but just, right now, slowing down for a release to get some things in order. Specifically, both Release Engineering and QA have clear needs (and even plans for) greater automatiion, but are also incredibly busy simply doing the things they need to do _now_ to get the release out the door. So, FESCo would like to see some specifics, like If we had one week with nothing else to worry about, we could have automated generation and upload of cloud images (to pick an example I personally care about). Or with six months of overall delay, we could have continuous integration testing of a key subset of rawhide. Or we could spend a couple of weeks and automate the new package and review workflow. What Infrastructure projects would be helped by this? Web and design team, would slowing down the release focus allow time to work on, oh, say, getting the Wiki beautiful (or does it not matter)? What else? As we look at Fedora.next ideas and possibly decide to start implementation in the F21 timeframe, we will likely find _new_ things that take specific work. Let's not worry about that right now. What things we do _now_ could be improved with the investment of some effort? Given that most of this stuff can be done parallel to the release (it is not like everyone is busy for full 6 months during the release cycle) I doubt this gains us much if anything. People will use the addtional time to do what they always do which means we just get a release with roughly the changes / churn of 2 releases. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 schedule: what would you do with more time?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 22 Aug 2013 11:03:52 -0400 Matthew Miller mat...@fedoraproject.org wrote: Based on discussion at Flock, on the devel mailing list, and in the FESCo meeting, we are looking for feedback on the idea of a longer release cycle for Fedora 21 -- not (right now at least) the bigger question of the 6-month cycle overall, but just, right now, slowing down for a release to get some things in order. Specifically, both Release Engineering and QA have clear needs (and even plans for) greater automatiion, but are also incredibly busy simply doing the things they need to do _now_ to get the release out the door. So, FESCo would like to see some specifics, like If we had one week with nothing else to worry about, we could have automated generation and upload of cloud images (to pick an example I personally care about). Or with six months of overall delay, we could have continuous integration testing of a key subset of rawhide. Or we could spend a couple of weeks and automate the new package and review workflow. What Infrastructure projects would be helped by this? Web and design team, would slowing down the release focus allow time to work on, oh, say, getting the Wiki beautiful (or does it not matter)? What else? As we look at Fedora.next ideas and possibly decide to start implementation in the F21 timeframe, we will likely find _new_ things that take specific work. Let's not worry about that right now. What things we do _now_ could be improved with the investment of some effort? some of the things I would like to work on include, fully automating the release process, today i have to do mutliple things from multiple locations to trigger off the different pieces of the release. write a tool like mash for pulling together the Live Spins and Images trees. run pungi and mash inside of koji so that all parts of the release compose process are done as koji tasks and make greater transparency on what Release Engineering do. get time to update all the documentation, and list out all the thoughts in my brain and try to build a community around release engineering so I don't have to work 60-80 hours a week just to try and keep up. work on a composedb that gives easier insight into where things are in the release cycles. where releases are in their cycle, i.e end of life, stable or in development, for stable releases when updates where last pushed, or if updates push is in progress, for in development, last nightly compose, last milestone compose, and if things are in progress. ive probably missed a bunch of things here but thats a brief dump of some of what ive been wanting to work on for ages and not had thetime to do so. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlIWMXMACgkQkSxm47BaWffsKgCffKmZQCYcFT31N0Eday93+zFu QTkAmwYqf9b2ZNMvW0sRY5iG5lK4u+dA =GrLI -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 schedule: what would you do with more time?
On Thu, 22 Aug 2013 17:19:09 +0200 drago01 drag...@gmail.com wrote: On Thu, Aug 22, 2013 at 5:03 PM, Matthew Miller mat...@fedoraproject.org wrote: Based on discussion at Flock, on the devel mailing list, and in the FESCo meeting, we are looking for feedback on the idea of a longer release cycle for Fedora 21 -- not (right now at least) the bigger question of the 6-month cycle overall, but just, right now, slowing down for a release to get some things in order. Specifically, both Release Engineering and QA have clear needs (and even plans for) greater automatiion, but are also incredibly busy simply doing the things they need to do _now_ to get the release out the door. So, FESCo would like to see some specifics, like If we had one week with nothing else to worry about, we could have automated generation and upload of cloud images (to pick an example I personally care about). Or with six months of overall delay, we could have continuous integration testing of a key subset of rawhide. Or we could spend a couple of weeks and automate the new package and review workflow. What Infrastructure projects would be helped by this? Web and design team, would slowing down the release focus allow time to work on, oh, say, getting the Wiki beautiful (or does it not matter)? What else? As we look at Fedora.next ideas and possibly decide to start implementation in the F21 timeframe, we will likely find _new_ things that take specific work. Let's not worry about that right now. What things we do _now_ could be improved with the investment of some effort? Given that most of this stuff can be done parallel to the release (it is not like everyone is busy for full 6 months during the release cycle) I doubt this gains us much if anything. People will use the addtional time to do what they always do which means we just get a release with roughly the changes / churn of 2 releases. Sure, it could be done in parallel to the release if we had twice the people. Are you volunteering to help test? I can't speak for other groups but QA is usually consumed with testing and coordination from branch to release. Granted, it isn't 100% of the time it does practically prevent us from working on anything big like automation or new tools. Constantly switching back and forth from full testing mode to dev mode for a day or two at a time isn't practical for most humans (myself included). The delay isn't about increasing the number of features we can stuff into F21 so much as it is about giving support groups more time to improve processes and tools for going forward. Tim signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 schedule: what would you do with more time?
On 22 August 2013 16:03, Matthew Miller mat...@fedoraproject.org wrote: Based on discussion at Flock, on the devel mailing list, and in the FESCo meeting, we are looking for feedback on the idea of a longer release cycle for Fedora 21 -- not (right now at least) the bigger question of the 6-month cycle overall, but just, right now, slowing down for a release to get some things in order. Specifically, both Release Engineering and QA have clear needs (and even plans for) greater automatiion, but are also incredibly busy simply doing the things they need to do _now_ to get the release out the door. So, FESCo would like to see some specifics, like If we had one week with nothing else to worry about, we could have automated generation and upload of cloud images (to pick an example I personally care about). Or with six months of overall delay, we could have continuous integration testing of a key subset of rawhide. Or we could spend a couple of weeks and automate the new package and review workflow. What Infrastructure projects would be helped by this? Web and design team, would slowing down the release focus allow time to work on, oh, say, getting the Wiki beautiful (or does it not matter)? What else? As we look at Fedora.next ideas and possibly decide to start implementation in the F21 timeframe, we will likely find _new_ things that take specific work. Let's not worry about that right now. What things we do _now_ could be improved with the investment of some effort? Here's my favourite bugbear: https://fedorahosted.org/packagedb/ticket/243 I have no idea why the package retirement process needs intervention from rel-eng. -- Mat Booth http://fedoraproject.org/get-fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 schedule: what would you do with more time?
On 08/22/2013 05:03 PM, Matthew Miller wrote: Based on discussion at Flock, on the devel mailing list, and in the FESCo meeting, we are looking for feedback on the idea of a longer release cycle for Fedora 21 -- not (right now at least) the bigger question of the 6-month cycle overall, but just, right now, slowing down for a release to get some things in order. E.g. going after these: http://ausil.fedorapeople.org/f20-failed.html Right now we have ~350+ broken packages, a lengthy series of broken deps, an unknown amount of defacto unmaintained packages and an unknown amout of maintainers having gone MIA. What Infrastructure projects would be helped by this? A web infrastructure to * ease package orphanage. * launch AWOL/MIA requests * a unified koji/bodhi/bugzilla Web-GUI * much longer build.log holding time for FTBFS. Also, - faster builders: Introduction of the arm has significantly increased the turn around times of package building. - better mirroring: I am having the impression mirrormanager doesn't work well at all. E.g. this morning, yum sent me around the globe for rawhide and failed in the end, seemingly because all fast mirrors seem to be busy loading f20. Web and design team, would slowing down the release focus allow time to work on, oh, say, getting the Wiki beautiful (or does it not matter)? Well, IMO the web design is the least issue to be concerned about wrt. the release process and packager works. What would really make sense is a faster koji/bodhi/bugzilla. From here, esp. bugilla is such kind of clumsy to use and ... such kind of slooow, I am glad I don't have to use it. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 schedule: what would you do with more time?
On 08/22/2013 05:12 PM, Matthew Miller wrote: On Thu, Aug 22, 2013 at 11:08:18PM +0800, Christopher Meng wrote: What things we do _now_ could be improved with the investment of some effort? Perl rebuild always take a lot of time, and as a result it will affect the mass rebuild. Apparently less so with all the new ARM builders, right? Dunno. Is this something you're saying could be improved, or is it just something we always need to budget time for? The issue with this perl rebuilt was the person conducting the initial rebuild didn't manage to finish it. Don't get me wrong - He did a good job, but his time frame simply was unrealistically short. This later on caused hickups during the official mass-rebuild, which still has its impact until today, because nobody has managed to fix some of the remaining bugs. When or even if these bugs can be overcome is still an open question. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 schedule: what would you do with more time?
On Thu, 22 Aug 2013 18:00:54 +0200 Ralf Corsepius rc040...@freenet.de wrote: ...snip... What Infrastructure projects would be helped by this? A web infrastructure to * ease package orphanage. * launch AWOL/MIA requests * a unified koji/bodhi/bugzilla Web-GUI * much longer build.log holding time for FTBFS. Yep. Although these could be done any time in the release cycle if people were working on them right? Also, - faster builders: Introduction of the arm has significantly increased the turn around times of package building. Yeah. I don't know of any faster arm hardware yet, but if there is some we could look at upgrading to it. - better mirroring: I am having the impression mirrormanager doesn't work well at all. E.g. this morning, yum sent me around the globe for rawhide and failed in the end, seemingly because all fast mirrors seem to be busy loading f20. I think part of this also might be us signing all the rpms for f20. This means pretty much every package changes due to the signature. Also, yeah, the f20 tree syncing out. (Although it should be hardlinked to rawhide). Hopefully this will stablize in the next few days. Web and design team, would slowing down the release focus allow time to work on, oh, say, getting the Wiki beautiful (or does it not matter)? Well, IMO the web design is the least issue to be concerned about wrt. the release process and packager works. What would really make sense is a faster koji/bodhi/bugzilla. From here, esp. bugilla is such kind of clumsy to use and ... such kind of slooow, I am glad I don't have to use it. Yeah, there are folks working on making bugzilla faster. ;( I agree it's an issue. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 schedule: what would you do with more time?
On Thu, 22 Aug 2013 11:03:52 -0400 Matthew Miller mat...@fedoraproject.org wrote: Based on discussion at Flock, on the devel mailing list, and in the FESCo meeting, we are looking for feedback on the idea of a longer release cycle for Fedora 21 -- not (right now at least) the bigger question of the 6-month cycle overall, but just, right now, slowing down for a release to get some things in order. Specifically, both Release Engineering and QA have clear needs (and even plans for) greater automatiion, but are also incredibly busy simply doing the things they need to do _now_ to get the release out the door. So, FESCo would like to see some specifics, like If we had one week with nothing else to worry about, we could have automated generation and upload of cloud images (to pick an example I personally care about). Or with six months of overall delay, we could have continuous integration testing of a key subset of rawhide. Or we could spend a couple of weeks and automate the new package and review workflow. What Infrastructure projects would be helped by this? Web and design team, would slowing down the release focus allow time to work on, oh, say, getting the Wiki beautiful (or does it not matter)? What else? ...snip... So, on the infrastructure side we are pretty used to rolling things out while the release cycle is going. We do freezes before milestones and those freezes give us some time to work on things as well as other 'quiet' parts of the release cycle. In general most of our constraints are people related. We just don't have enough developers and sysadmins to setup, deploy and maintain all the things we might want to do. * move more infra hosts to selinux enforcing. * A fedora site search engine setup * mailman3/hyperkitty roll out (this is progress, we do have people working on it) * Setup a more usable release engineering side in our staging env. This entails setting up a koji, builder, tying to pkgs01.stg, tying to bodhi, etc. * limesurvey instance (we have a package in review, it's been stalled for a long time, if someone could take over packaging that would be great! bug: https://bugzilla.redhat.com/show_bug.cgi?id=819480 ) * Figure out new docs process and how we can use it to deploy docs.fedoraproject.org (waiting on input from docs folks). * Re-install part of our cloud with latest openstack and test it out, then migrate things to it and reinstall the old one. * If we had time we could work on cleaning up a lot of cron jobs/scripts to use fedmsg/be smarter. ...I can come up with a bunch more... But as noted these mostly can be done anytime we have people willing to do them. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 schedule: what would you do with more time?
On Thu, 22 Aug 2013 18:27:20 +0200 Ralf Corsepius rc040...@freenet.de wrote: The issue with this perl rebuilt was the person conducting the initial rebuild didn't manage to finish it. Don't get me wrong - He did a good job, but his time frame simply was unrealistically short. Well, I noticed the rebuild was running only some times. I assume when they were there to launch the builds in that batch? Is there any way all the builds could be listed and just fired off and queued all at once? Here's the distribution on the f20-perl rebuild builds: Jul 11:0 Jul 12:71 Jul 13:1 Jul 14:0 Jul 15:47 Jul 16:0 Jul 17:867 Jul 18:224 Jul 19:0 Jul 20:255 Jul 21:162 Jul 22:104 Jul 23:87 Jul 24:141 Jul 25:23 Jul 26:49 Jul 27:0 Jul 28:20 Jul 29:27 Jul 30:18 So, there were days with 0 builds and some with only a few. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 schedule: what would you do with more time?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 22 Aug 2013 18:00:54 +0200 Ralf Corsepius rc040...@freenet.de wrote: On 08/22/2013 05:03 PM, Matthew Miller wrote: Based on discussion at Flock, on the devel mailing list, and in the FESCo meeting, we are looking for feedback on the idea of a longer release cycle for Fedora 21 -- not (right now at least) the bigger question of the 6-month cycle overall, but just, right now, slowing down for a release to get some things in order. E.g. going after these: http://ausil.fedorapeople.org/f20-failed.html Right now we have ~350+ broken packages, a lengthy series of broken deps, an unknown amount of defacto unmaintained packages and an unknown amout of maintainers having gone MIA. What Infrastructure projects would be helped by this? A web infrastructure to * ease package orphanage. * launch AWOL/MIA requests * a unified koji/bodhi/bugzilla Web-GUI Since we dont run bugzilla I dont know that we could, I did bring up at flock that id like to see a unified web gui for koji bodhi and packagedb. * much longer build.log holding time for FTBFS. This is a setting for the cron job that cleans things up. We have it at a week because we have been tight on space for years. it used to be two weeks. I just bumped it to four weeks for build logs and 3 weeks for scratch builds, since we moved to bigger storage recently. Also, - faster builders: Introduction of the arm has significantly increased the turn around times of package building. - better mirroring: I am having the impression mirrormanager doesn't work well at all. E.g. this morning, yum sent me around the globe for rawhide and failed in the end, seemingly because all fast mirrors seem to be busy loading f20. Web and design team, would slowing down the release focus allow time to work on, oh, say, getting the Wiki beautiful (or does it not matter)? Well, IMO the web design is the least issue to be concerned about wrt. the release process and packager works. What would really make sense is a faster koji/bodhi/bugzilla. From here, esp. bugilla is such kind of clumsy to use and ... such kind of slooow, I am glad I don't have to use it. we do not run bugzilla, we cant do much about it. there has been people looking at bugtracking and moving to something we would run. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlIWQiUACgkQkSxm47BaWfeicwCeJ33sq/sgHyo067rMWKByc5uS XJUAoIm6oBJKAPIsatWFdWL4ILoDYYmD =pEWq -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 schedule: what would you do with more time?
On 08/22/2013 03:03 PM, Matthew Miller wrote: Based on discussion at Flock, on the devel mailing list, and in the FESCo meeting, we are looking for feedback on the idea of a longer release cycle for Fedora 21 -- not (right now at least) the bigger question of the 6-month cycle overall, but just, right now, slowing down for a release to get some things in order. Specifically, both Release Engineering and QA have clear needs (and even plans for) greater automatiion, but are also incredibly busy simply doing the things they need to do _now_ to get the release out the door. So, FESCo would like to see some specifics, like If we had one week with nothing else to worry about, we could have automated generation and upload of cloud images (to pick an example I personally care about). Or with six months of overall delay, we could have continuous integration testing of a key subset of rawhide. Or we could spend a couple of weeks and automate the new package and review workflow. What Infrastructure projects would be helped by this? Web and design team, would slowing down the release focus allow time to work on, oh, say, getting the Wiki beautiful (or does it not matter)? What else? As we look at Fedora.next ideas and possibly decide to start implementation in the F21 timeframe, we will likely find _new_ things that take specific work. Let's not worry about that right now. What things we do _now_ could be improved with the investment of some effort? In the core/baseOS... Continue systemd integration stuff and other packaging cleanup surrounding the core/baseOS In the QA community... Work on implementing and intergrading the QA community member role which replaces proven testers and the bugzappers as well as work with releng and spins to sort out and implementing some form of the spin idea I had as well and work with Anaconda team to come up with some kind of testing plan and timing since it's quite time consume trying to be testing the installer at the same time we are working with package and other testing. In a perfect QA world the installer release would be done at branch and or no later then alpha. In the server community Working with and implementing some of my ideas to further build and mobilise the server community. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 schedule: what would you do with more time?
On 08/22/2013 06:47 PM, Kevin Fenzi wrote: Well, I noticed the rebuild was running only some times. I assume when they were there to launch the builds in that batch? Is there any way all the builds could be listed and just fired off and queued all at once? Peter queue honor build requires (Dennis script for mass rebuilds does not) so if some build fail, the queue is heavily reduced or stopped at all. This last until the failed build is manually resolved. Firing off all builds at once will not help, because they would fail anyway due missing build requires. Mirek (who just sit beside Petr, so I coincidentally know about it) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 schedule: what would you do with more time?
On Thu, 22 Aug 2013 11:03:52 -0400 Matthew Miller mat...@fedoraproject.org wrote: Based on discussion at Flock, on the devel mailing list, and in the FESCo meeting, we are looking for feedback on the idea of a longer release cycle for Fedora 21 -- not (right now at least) the bigger question of the 6-month cycle overall, but just, right now, slowing down for a release to get some things in order. Specifically, both Release Engineering and QA have clear needs (and even plans for) greater automatiion, but are also incredibly busy simply doing the things they need to do _now_ to get the release out the door. So, FESCo would like to see some specifics, like If we had one week with nothing else to worry about, we could have automated generation and upload of cloud images (to pick an example I personally care about). Or with six months of overall delay, we could have continuous integration testing of a key subset of rawhide. Or we could spend a couple of weeks and automate the new package and review workflow. For QA tools/automation, a week isn't going to give us much - we already have a couple of weeks between releases and we're more blocked by projects that will take longer than a week. I've been meaning to sit down and come up with a more detailed list/plan for qa development (automation, other tools) but that hasn't happened yet. At the end of this email, I made a list of the things that I've been talking about with various folks in the order of both how important I think they are and how much the project would benefit from a more extended break between releases. Exactly how much of this we could do with more time depends on both how much time we're talking about and who all would be involved. Tim Taskbot [1]: This will become the foundation for future automation work and at the moment is at least somewhat blocking our other automated testing initiatives from moving forward. This would (eventually, not all of this would be part of the first deliverable) give us: - easier for new people to get up to speed and help creating/maintaining checks/tasks - more flexibility in the types of checks/tasks that could be automated - better triggering (run X check for builds of Y package, run Z at a certain time etc.) - better reporting - automated analysis of logs for oddities or to answer questions like how long have we been seeing this error in syslogs [1] http://tirfa.com/tag/taskbot.html Automated Install Testing: Many of our current validation test cases [2] are very straight forward and could be automated to free up human testers to do other testing that isn't (easily) automate-able. We have a start on this with infinity [3] but there is still some development work, a lot of integration work to do and test cases to write before any of this is usable. [2] https://fedoraproject.org/wiki/QA:Fedora_20_Install_Results_Template [3] https://github.com/garretraziel/infinity Smoke image build automation: This has been started [4] as part of GSoC 2012 but is still a little shy of being usable in production. The idea would be to build images as soon as new packages (anaconda, maybe others) so that a set of automated install smoke tests could be kicked off. This could involve working with releng on something to do the composes - I'm less interested in who does the work than I am in being able to get images to test on demand. [4] https://fedorahosted.org/fedora-build-service/ Test Case and Results Management: We want to replace our current wiki-based system of test cases and results matrices. I'm not aware of any existing system that would fit our needs and I think we're going to end up rolling our own unless something new shows up. Update/Build Gating: There's been talk about gating updates based on automated test results for a while but nothing's finished yet. A lot of this is integration with bodhi/koji but there are still some bits that haven't been implemented (test result manual override is the first thing that comes to mind) Better Automated Checks: Rewriting depcheck to be more useable, abi breakage checks, running gnome's new test suite or anything else that people can come up with. This can happen just as easily in parallel with releases once we have the infrastructure in place to run them, though and doesn't really require an extended break between releases. What Infrastructure projects would be helped by this? Web and design team, would slowing down the release focus allow time to work on, oh, say, getting the Wiki beautiful (or does it not matter)? What else? As we look at Fedora.next ideas and possibly decide to start implementation in the F21 timeframe, we will likely find _new_ things that take specific work. Let's not worry about that right now. What things we do _now_ could be improved with the investment of some effort? signature.asc Description: PGP
Rebuilding in dependency order (was: F21 schedule: what would you do with more time?)
Miroslav Suchy wrote: On 08/22/2013 06:47 PM, Kevin Fenzi wrote: Well, I noticed the rebuild was running only some times. I assume when they were there to launch the builds in that batch? Is there any way all the builds could be listed and just fired off and queued all at once? Peter queue honor build requires (Dennis script for mass rebuilds does not) so if some build fail, the queue is heavily reduced or stopped at all. This last until the failed build is manually resolved. Firing off all builds at once will not help, because they would fail anyway due missing build requires. You make it sound like Peter has a tool for rebuilding in dependency order. I need such a thing. Can it be made to work for other things than Perl? -- Björn Persson Sent from my computer. signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 schedule: what would you do with more time?
On Thu, Aug 22, 2013 at 10:38:38AM -0600, Kevin Fenzi wrote: In general most of our constraints are people related. We just don't have enough developers and sysadmins to setup, deploy and maintain all the things we might want to do. I definitely know how that is. Of the list you give, maybe the staging releng environment is most helped by a pause? But as noted these mostly can be done anytime we have people willing to do them. So I guess the flip side of that is: anyone feel like their time would be freed up to work on any of these things? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 schedule: what would you do with more time?
On 08/22/2013 03:19 PM, drago01 wrote: Given that most of this stuff can be done parallel to the release (it is not like everyone is busy for full 6 months during the release cycle) I doubt this gains us much if anything. This is laughable response we in QA and I'm pretty sure it's the same for Releng are pretty much busy the entire time always! We get about 3 - 5 weeks of quiet time after GA to actually work on the community side of stuff which most people just use to take a break to gather energy for $next cycle since after that we are back on full swing. Additional 3 months to the release cycle will give us exactly that 3 additional months to dedicate building our community, process and workflows And I'm pretty sure the installer team is on same or similar schedule as us. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 schedule: what would you do with more time?
On Thu, Aug 22, 2013 at 7:37 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 08/22/2013 03:19 PM, drago01 wrote: Given that most of this stuff can be done parallel to the release (it is not like everyone is busy for full 6 months during the release cycle) I doubt this gains us much if anything. This is laughable response we in QA and I'm pretty sure it's the same for Releng are pretty much busy the entire time always! most != all -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 schedule: what would you do with more time?
On Thu, Aug 22, 2013 at 11:03:52AM -0400, Matthew Miller wrote: As we look at Fedora.next ideas and possibly decide to start implementation in the F21 timeframe, we will likely find _new_ things that take specific work. Let's not worry about that right now. What things we do _now_ could be improved with the investment of some effort? To me it seems that core applications are currently stuck in development because key persons do not have enough time. For example Bodhi2 is expected for years. Also getting signature verification into fedup is blocked by implementing signing in the composing process. In general I would welcome if some time could be freed to make sure that every code that is produced by Fedora can be easily acquired via a secure and verified way. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 schedule: what would you do with more time?
On Thu, Aug 22, 2013 at 10:41:25AM -0600, Kevin Fenzi wrote: On Thu, 22 Aug 2013 18:00:54 +0200 Ralf Corsepius rc040...@freenet.de wrote: ...snip... What Infrastructure projects would be helped by this? A web infrastructure to * ease package orphanage. * launch AWOL/MIA requests * a unified koji/bodhi/bugzilla Web-GUI * much longer build.log holding time for FTBFS. * Manage SCM branches Yep. Although these could be done any time in the release cycle if people were working on them right? The problem is that stuff is not documented enough and key persons do not have time to help/accept patches. AFAIK Luke is the only person deploying new versions of Bodhi for example. Therefore it usually takes ages until a patch moves from trac to the live system. Also most of the inner architecture of Fedora's release process is not visible for most people, making it very hard to improve stuff. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 schedule: what would you do with more time?
On Thu, 2013-08-22 at 17:19 +0200, drago01 wrote: On Thu, Aug 22, 2013 at 5:03 PM, Matthew Miller mat...@fedoraproject.org wrote: Based on discussion at Flock, on the devel mailing list, and in the FESCo meeting, we are looking for feedback on the idea of a longer release cycle for Fedora 21 -- not (right now at least) the bigger question of the 6-month cycle overall, but just, right now, slowing down for a release to get some things in order. Specifically, both Release Engineering and QA have clear needs (and even plans for) greater automatiion, but are also incredibly busy simply doing the things they need to do _now_ to get the release out the door. So, FESCo would like to see some specifics, like If we had one week with nothing else to worry about, we could have automated generation and upload of cloud images (to pick an example I personally care about). Or with six months of overall delay, we could have continuous integration testing of a key subset of rawhide. Or we could spend a couple of weeks and automate the new package and review workflow. What Infrastructure projects would be helped by this? Web and design team, would slowing down the release focus allow time to work on, oh, say, getting the Wiki beautiful (or does it not matter)? What else? As we look at Fedora.next ideas and possibly decide to start implementation in the F21 timeframe, we will likely find _new_ things that take specific work. Let's not worry about that right now. What things we do _now_ could be improved with the investment of some effort? Given that most of this stuff can be done parallel to the release (it is not like everyone is busy for full 6 months during the release cycle) I doubt this gains us much if anything. People will use the addtional time to do what they always do which means we just get a release with roughly the changes / churn of 2 releases. QA, releng and anaconda are on a more or less permanent iteration treadmill from Alpha TC1 onwards, severely limiting the time we have to work on anything else. We can only really get substantive work done on 'things that are not release validation' in the ~two months (on a regular cycle) between FNN Go and FNN+1 Alpha TC1. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 schedule: what would you do with more time?
On Aug 22, 2013, at 9:42 AM, Dennis Gilmore den...@ausil.us wrote: some of the things I would like to work on include, fully automating the release process, today i have to do mutliple things from multiple locations to trigger off the different pieces of the release. write a tool like mash for pulling together the Live Spins and Images trees. run pungi and mash inside of koji so that all parts of the release compose process are done as koji tasks and make greater transparency on what Release Engineering do. get time to update all the documentation, and list out all the thoughts in my brain and try to build a community around release engineering so I don't have to work 60-80 hours a week just to try and keep up. work on a composedb that gives easier insight into where things are in the release cycles. where releases are in their cycle, i.e end of life, stable or in development, for stable releases when updates where last pushed, or if updates push is in progress, for in development, last nightly compose, last milestone compose, and if things are in progress. ive probably missed a bunch of things here but thats a brief dump of some of what ive been wanting to work on for ages and not had thetime to do so. Sooo, is about one week enough time for all of this? Or other? Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 schedule: what would you do with more time?
On Aug 22, 2013, at 3:03 PM, Adam Williamson awill...@redhat.com wrote: QA, releng and anaconda are on a more or less permanent iteration treadmill from Alpha TC1 onwards, severely limiting the time we have to work on anything else. We can only really get substantive work done on 'things that are not release validation' in the ~two months (on a regular cycle) between FNN Go and FNN+1 Alpha TC1. I'm going to take a wild guess here, QA could probably use a month of going into a black hole for starters, as in, en vacaciones, no me contacte. So in reality, that probably translates into maybe a four day weekend. But how much time do you think QA needs for things other than release validation? So far the push back range is a wee bit broad, 2 weeks to six months. If it needs to be six months, fine. But there's also a risk of losing a lot of momentum with a six month hiatus. That's why I arbitrarily came up with 3 months on the high end. There are still positives to the Fedora pressure cooker (ANOTHER RELEASE NAME IDEA!), a.k.a. crazy train. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 schedule: what would you do with more time?
On Thu, 2013-08-22 at 18:11 -0600, Chris Murphy wrote: On Aug 22, 2013, at 3:03 PM, Adam Williamson awill...@redhat.com wrote: QA, releng and anaconda are on a more or less permanent iteration treadmill from Alpha TC1 onwards, severely limiting the time we have to work on anything else. We can only really get substantive work done on 'things that are not release validation' in the ~two months (on a regular cycle) between FNN Go and FNN+1 Alpha TC1. I'm going to take a wild guess here, QA could probably use a month of going into a black hole for starters, as in, en vacaciones, no me contacte. So in reality, that probably translates into maybe a four day weekend. But how much time do you think QA needs for things other than release validation? So far the push back range is a wee bit broad, 2 weeks to six months. If it needs to be six months, fine. But there's also a risk of losing a lot of momentum with a six month hiatus. That's why I arbitrarily came up with 3 months on the high end. There are still positives to the Fedora pressure cooker (ANOTHER RELEASE NAME IDEA!), a.k.a. crazy train. The more time we have, the more stuff we can do. We have a list of things we'd like to have that could fill a couple of years of work easy, most likely. I was thinking three months was not arbitrary, but 'the right amount of time to get back into sync with GNOME', which was one of the aims of our six month cycle prior to F18. If we're going to do a 'hiatus', it would seem sensible to use it to get back into a cycle which works nicely with the GNOME dev cycle. (No, I am not going to use the word 'cadence' at any point in this mail. Damni-) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
