Le samedi 18 février 2006 à 23:05 -0600, Dennis Gilmore a écrit : > One thing i realise now is that some people may not want to or have the > resources to support the development branch. Its a huge moving target. not > only do you get frequent changes in extras you get it in core also. and > some people just cant or dont want to keep up. we kinda assume that they > will. I totally agree most maintainers have a range of releases they're prepared to work on, for some this range centers on devel for others on legacy. I thoroughly disagree we should treat all releases the same and let people contribute to whichever random FE release they want to. This is what the kernel team used to do in 2.4+2.5 days, and the result is dispersion of efforts and massive frustration on part of everyone (2.4 contributors complaining core team does not care about them, core team complaining freeloaders want them to review 2.4 stuff and won't help get 2.5 out of the door). Devel should be mandatory for new functionality. If we don't do that we betray Fedora goals, because most contributors will do the current release only. This will mean no one will run/test rawhide and the various FCn+1Tx, leading to a FCn+1 that slips or sucks, and harming the whole project (after a while people won't be contributing to current FC but current FC + a few stabilizing months and so on). Also, devel packaging is when you see rawhide is missing some crucial bits and when you can ask for them to be pulled in. After release it's *too* *late*. RH people have moved to the next release. (this is my main beef with the other external repositories. They all say devel is too much work, and in practical terms their influence with users and upstream is used to focus efforts on FCn-x, diverting efforts that should be used on rawhide) People not interested in devel can join FEL. That means they also have no say in what new features get in FE. We should have three levels of support (more would be nicer for packagers, but do you imagine the level of frustration of users which have to evaluate support on a package per package basis ?) 1. partial maintenance -> devel only or devel+FCn, and only if some needed features are not present in FCn or FCn-1 2. "standard" maintenance -> same as FC, from devel to FCn-1 till devel graduates to FCn+1T2 3. "long-term" maintenance -> for packages that are picked up by FEL at FCn+1T2 time. And FEL should draw a red line after which *no* packages are maintained anymore (iterate if there is the will and resources to create a FEL++ team charged with "extended long term" maintenance) And I absolutely do not mean FEL should be a separate entity with no access to FE ressources. It could be a FE SIG or something else within FE. But there must be some coordinating structure, and package lifetimes should not be decorrelated. Pick up when you want and abandon whenever you feel so is fine and dandy for packagers, but it's also user hell. One big part of distribution work is to make something coherent out of random pieces of software. That includes coherent support durations. -- Nicolas Mailhot
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
-- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
