Maintainer input on release notes
We had a short discussion of this at this morning's meeting but felt a broader discussion here was warranted. When preparing the Release Notes, we often ask the developers for wiki input, and generally come up dry. More recently, we look though the repos for changes, but the upstream release notes are often very poor or nonexistent. Every release includes literally thousands of changed packages, and while we strive to document significant changes, these poor upstream release notes leave us little clue as to what constitutes significant. Certainly the feature pages get us started, but they only capture a tiny fraction of what changes in a release. But if we think about the maintainers, chances are they begin working on the next thing just as soon as the compose closes for the previous release, if not sooner. Very likely they have an interest in the packages they are maintaining, and it would not be surprising if they viewed some features to be important. But by the time we ask for input, odds are they have moved on and most of the updated packages in the new release are ancient history. However, if we were to open the beats as soon as possible, certainly when the compose closes or even as soon as we have converted the beats to XML, then the developers could make a note in the wiki about what is significant, right at the time they are working on it and interested in it. Of course we would still need to remind the maintainers that we want their input, and especially that it doesn't need to be beautiful prose - all we really need is a clue as to what is important. But I think if we can capture the input early, we have better odds of getting more complete release notes. Is this something we should do? Is there something different we should be doing? --McD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Embedded SIG
On Sun, Apr 21, 2013 at 5:01 AM, Markus Mayer lotharl...@gmx.de wrote: So I have decide to ask if there are others like me, and if there are willing to form a SIG (special interest group) to enhance embedded developing with fedora. I have an interest in an Embedded SIG, although less for the ARM as for the Microchip devices (PIC, dsPIC) which are reasonably well supported. Not that I don't play with ARM, too, but it is somewhat less of a passion. --McD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Request: Co-maintainership of Chitlesh's Fedora packages
SK I would be willing to assist to the degree I can. I consider Chitlesh's packages to be quite valuable and would like to see them kept up to date. I probably couldn't offer much for the more arcane stuff, but I could deal with the more vanilla microcontroller, circuit design, etc. packages. --McD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Release Notes
This release we seem to have gotten quite a few timely bugs, some of them quite subtle. I thank all of you who took the time to pore over the beta notes and submit bugs. Many of these subtleties the Docs writers really can't pick up on, and your effort makes the release notes that much better. And certainly bugzilla is far and away the best place to let us know. --McD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Seeking package review - R-qcc
R-qcc is an SPC/SQC plugin for R: https://bugzilla.redhat.com/show_bug.cgi?id=722640 The spec file is pretty much a rip off of other R plugins - there doesn't seem to be anything particularly special about this plugin. I am working on a guide for using R for Six Sigma practitioners, and this plugin offers lots of stuff Black Belts do. Although it is a pretty simple install direct from CRAN, it would be nice if readers could grab it from the repo. --McD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Beats are open
The release notes beats for Fedora 16 are now open. If you are working on some new feature for Fedora 16 that should be included in the release notes, please consider heading on over to https://fedoraproject.org/wiki/Documentation_Beats select the appropriate beat for your feature, and write a little something. You don't need to be flowery, or excessively detailed. Docs team members will be editing the beat content when it gets converted to Publican. If you are working on a major feature listed in the feature pages, of course we will be taking the prose from that page. But often the release notes section is written very early, and by now you probably have a lot more to say. If you don't tell us about the great stuff you are working on, how can we tell the world? It only takes a few minutes, and we all could benefit from knowing what is coming up. Thanks --McD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Release Notes Beats closing
I will be converting the remaining beats tomorrow. If there are any last minute additions, get them in now. --McD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Release Notes Beats closing
We are behind schedule on Release Notes. Most of the wiki beats have been updated, at least for key features. If you have been working on a beat, please review it and set the Wiki Good indicator to 1 if you think it is OK on https://fedoraproject.org/wiki/Category:Documentation_beats If you are a developer you may want to go to the above page, find the beat relevant to your work and review it. It is a wiki, so if you think something needs to be added or changed, do it! If the In Publican indicator is already 1, please set the Wiki Good indicator to a * so we know that the wiki needs to be re-converted. It looks like there are a number of new and interesting packages in the Scientific and Technical area, but many of them are quite, well, technical. We could really use some help here. Keep in mind that since we went to a real Alpha, the release notes are largely complete by Beta. Changes after Beta cause double work for L10N, so please don't put this off. Since we are behind schedule, just because the Wiki Good indicator is 0 doesn't mean that beat won't get converted. --McD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F14 Final Wiki Freeze
Monday, October 4, is the wiki freeze for the GA release notes. If there is something you want to see in the release notes now is your last chance. The release notes draft content can be found at https://fedoraproject.org/wiki/Documentation_Beats This page links to a wiki page for each area in the release notes. Simply add your content to one of these pages. It will be edited so there is no need to be concerned about getting elegant prose. Just getting the fact down will be a help. Thanks --McD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Release Notes Draft
On Tue, 2010-09-07 at 00:14 -0400, Matthew Miller wrote: On Mon, Sep 06, 2010 at 11:45:53AM -0400, John J. McDonough wrote: A number of beats were blank, and some of them probably should be, but I left them in the document for now as a reminder in case you are aware of something that is missing. I will get rid of them tomorrow. Systemd needs more explaining, if we want that transition to go smoothly. And it should be in the index under init as well as systemd. And also, it should not go under Boot -- it is a system which manages processes on the system from startup to shutdown. Certainly we would welcome more detail. You should feel free to provide it on the wiki. https://fedoraproject.org/wiki/Docs/Beats/Boot I'm less sure about moving it. Since there were no other significant changes to System Daemons perhaps it could go there and not get lost, but I suspect system admins would need to make lots of changes to their init scripts and I would think the first place they would look would be Boot. I would dearly love to give admins some help on what they need to do to restore their configurations after this update, but I can't do it without help, probably a lot of help, from development. Since the XML conversion is now complete there is no longer a need to maintain the beta wiki freeze, so if you can possibly contribute, please do. The longer you wait, though, the more of a problem it creates for L10N. But I do think it is important. --McD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Release Notes Draft
On Tue, 2010-09-07 at 09:01 -0400, Christopher Antila wrote: Hi John: I made changes to (i.e. finally completed) the KDE portion of the wiki's Desktop beat a few days ago, and they are not in the draft. I will add these to the git version today/tonight. If there's anything that I need to know before doing this - like things that I need to do aside from downloading the repo, changing the file, then committing my changes, please let me know. Of course you will want to build the en-US and make sure it builds properly before committing the changes. If you can get the changes committed before 0337Z, then they will show up in the overnight POTs and draft build. The POT update runs fairly quickly, so L10N should have those well before 0400Z each day. The draft build starts later and takes a while, so the updated drafts on http://fedorapeople.org/groups/docs/release-notes won't show up until shortly after 0930Z. I've made some other suggested changes and restarted the draft build manually, and the link at http://jjmcd.fedorapeople.org/Download/Release_Notes/ is now just a symlink to the groups/docs copy. --McD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Release Notes Draft
The wiki has been converted and a draft of the release notes is available at http://jjmcd.fedorapeople.org/Download/Release_Notes/ for your review. The sources are up to date in git, but the translation branch is not yet complete. I will go ahead and do that this afternoon. If you could review your beat promptly that would be a help. This evening we are due to send the first POTs to L10N and we should stabilize them by tomorrow, so any edits should be made promptly. A number of beats were blank, and some of them probably should be, but I left them in the document for now as a reminder in case you are aware of something that is missing. I will get rid of them tomorrow. Beginning tonight I will start the nightly build, and all the languages, initially partially or not at all translated, will begin appearing in http://fedorapeople.org/groups/docs/release-notes/ Thank you all for your hard work! --McD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Release Notes Draft
On Tue, 2010-09-07 at 01:23 +0200, Jonathan MERCIER wrote: Le lundi 06 septembre 2010 à 11:45 -0400, John J. McDonough a écrit : The wiki has been converted and a draft of the release notes is available at [clip] Why i do not see D programming ? It's there: 6.1.1 New Programming Language (although it should probably also be in 6.3 - good catch) hint - if you are looking for something specific, try the index. Pretty much every package mentioned should be in the index. --McD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Alpha Release Notes Next Week
One week from today we will begin preparing the Alpha Release Notes. If you have an application you think should be mentioned in the Alpha Notes please be sure your Feature page is concise and compelling. The Alpha Release Notes are quite succinct, so not every new feature will be mentioned, in fact, probably not every major feature will be mentioned. But if we don't know what cool thing you are working on, then for sure it won't be included. If you have a really important story to tell, consider going to https://fedoraproject.org/wiki/Documentation_Beats select the appropriate beat, and write a short pitch on what cool thing you are adding for Fedora 14. If English isn't your first language, or you don't think you are the best writer, don't worry. We have editors who will polish it up. Just be sure to make us aware of what you have been doing. Thanks for all your hard work --McD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Wiki Freeze Reminder
In just over a week, on April 19, the wiki will freeze for Release Notes for Fedora 13. If you have content you would like to see the the Release Notes go to: https://fedoraproject.org/wiki/Documentation_Beats and click on the most appropriate beat. Add your content there. Note that the content will be reviewed and edited so there is no need to be concerned that your prose is exactly perfect. If you are pressed for time, a few words about what changed along with a link to more detail would be fine. The Docs Project needs to know what you have provided for F13 before it can write about it! --McD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal
Chris Adams wrote: Once upon a time, Kevin Kofler kevin.kof...@chello.at said: If the infrastructure sucks where you live, what needs to happen is that the infrastructure needs to improve, not that the whole world adapts to stone-age infrastructure. Bandwidth is required for many more applications than just fetching Fedora updates. That is just completely out of touch with reality. We live in the real world and have to deal with real problems; you can't just wave a magic wand and make them go away. While many third-world countries have made high speed connections a priority, these countries are often densely populated. In more rural areas, high speed connections are economically impractical. Here in Michigan, which is one of the more populous states, terrestrial high speed connections are simply unavailable in about half the state. Satellite connections are expensive, not terribly fast, and because of the weather, very unreliable. Much of this state has a population density less than 5 people per square kilometer, and that is crowded compared to many of the western states. At those population densities it will be some time before technology will be able to deliver high bandwidth connections economically to much of the population. If you are sitting in the crowded cities of western Europe, it may be hard to imagine a world where your nearest neighbor is a kilometer away, but that is how it is in much of the world. The distances can be vast, and hard to picture from inside Europe (or Manhattan, for that matter). --McD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposa
Kevin wrote: But that still doesn't answer the question whether it shouldn't be up to people like you to choose a distribution catering to your needs as opposed to imposing them on the existing Fedora. The problem is, if all the distributions optimize for people with low bandwidth, then what should people like me who have higher bandwidths and would like to use their bandwidth to get current software use? Oh, I don't totally disagree with your premise. Two of our core values are First and Features. If someone is using Fedora then they want to be on top of the latest open source goodness. Isn't that the point? But we may also want to understand what that does to our user and contributor base. There is a lot of variability around the world, and around our base. We need to balance the need to provide people with the latest and greatest against the possible reduction in our base, and should we make such a change, we would want to be very careful how we frame it, to avoid unnecessarily alienating a larger group. --McD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Release Notes Wiki Freeze
Next week is the wiki freeze for Fedora 13 Release Notes. If you have something important that needs to be in the release notes, update the appropriate wiki beat. Go to http://fedoraproject.org/wiki/Documentation_Beats and select the appropriate beat. Then add a note to that beat. Your update need not be polished prose; if you can summarize the key points that need to be documented and perhaps include a link to more details, the Docs Project can take it from there. As in Fedora 12, we are not looking to document every little change. The release notes will highlight significant changes, and include a link to the upstream page for all changes. If your component is hosted by Fedora, please consider enhancing the information pointed to by the yum link, which is what will appear in the release notes. Thanks for your help --McD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
