<div class="gmail_quote">2008/4/6 Stephen John Smoogen <<a href="mailto:smooge@gmail.com">smooge@gmail.com</a>>: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div class="Ih2E3d">On Sun, Apr 6, 2008 at 12:10 PM, Brad Bell <<a href="mailto:bradbell@seanet.com">bradbell@seanet.com</a>> wrote: > I am a Fedora package maintainer and am considering creating an EPEL branch. > > In the guidelines on > <a href="http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies" target="_blank">http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies</a> > under the heading > Some examples of what package updates are fine or not > it appears that package updates should: > 1. be backward compatible > 2. fix a serious bug > > It seems that, once a package is released in EL-n, new features are not a > reason to create a new release of the package in EL-n. An update with the > purpose of adding new features should wait for EL-(n+1) ? > </div>Ok I am running a fever and not feeling too hot so between allergies and other stuff... so please make allowances: When people started with EPEL, a lot of us had these great ideas like making software solid and steady from quarterly release to release. A lot of initial interest from "customers" was on this format of doing things with the only things occurring between quarter releases was backported patches or security fixes. There was also a lot of people who want to get the latest "stable" version of say cobbler, func, free-ipa since its under heavy development and they need newer features for their environment. And so some software gets updated monthly and some software stays 'frozen' at some version. I think the main thing is finding out what 'your' particular EPEL customers want. Say what packages you are wanting to support, and what level of maintainership you are willing to provide for EPEL and request feedback. If the customers want a locked down version.. then they need to provide you with the resources to make that happen. In my dealing with EPEL software, what I have found I needed was a solid update schedule: Black Tuesday etc, and knowing what is going to occur in an update so I can 'freeze' a package on systems if I know I can't go to that update... even if it means I am going to run a security borked software piece. Anyway.. hope the above makes some sort of sense... </blockquote><div> It also mean that it's _you_ packager to know [how|when|what] update an release from upstream for a specific branch by taking in order the severity of the new release. </div></div>that imply to know the role of each branch as well. -- Xavier.t Lamien -- <a href="http://fedoraproject.org/wiki/XavierLamien">http://fedoraproject.org/wiki/XavierLamien</a> GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB