On Fri, 28 Apr 2006 12:50:27 +0200, Thorsten Leemhuis wrote: > Am Freitag, den 28.04.2006, 12:20 +0200 schrieb Patrice Dumas: > > > And for > > the users it depends, some want updates other don't.[...] > > Doing both (e.g. 50% of the packagers update their packages to new > versions, the other 50% only fix bugs) is IMHO the worst we can do. If > people want new stuff they are probably installing new distribution > versions in any case (not all, but most). That's why I prefer "normally > no big updates" variant for those that prefer a stable distributions. Exactly. Legacy distributions don't make these users happy at all, since, for example, KDE remains at 3.4.2 compared with upstream. Users, who are in search of fresh software, want the current or most recent release of FC+FE. They upgrade. > > > Branches for new packages in CVS are not created for Distributions > > > that are in Maintenance state. FESCo can approve exceptions of this rule > > > if there are good reasons for it. The official package maintainers are > > I completly disagree with that. If a user don't want new packages that > > entered extras while in maintainance state he shouldn't install new > > packages. In my opinion the maintainer could be able to add new packages > > for distributions in maintainance state, if he is confident that he > > will maintain it. [...] > > I can live with that if others agree with it. But there were some people > in FESCo that don't like this idea. Time spent on trying to keep legacy branches alive is missing in other areas. I'd rather see Extras packagers track Rawhide and prepare for the next release of FC, so we have something to offer at the time of release of Test1. Version upgrades in old branches--especially those which are done without careful testing (like closed-eyes copy-to-branch-and-build updates)--increase the risk of resulting in regression, dead-end breakage and increased maintenance requirements. Such as but not limited to requiring further version upgrades in build requirements or in dependencies maintained by other packages (with Epoch bump or package withdrawal as a worst-case). > > > urged to fix their packages also for Distributions that are in > > > Maintenance state. They should work hand in hand with the "Security > > > Response Team" in case they don't have access to older > > > distros anymore to test their updates. > > What about co-maintainership, if a maintainer volunteers for maintaining > > the old branches? > > I left co-maintainership (and your proposal) out for now because it > would have complicated things even more. > > But we should work on the details for "co-maintainership" soon. Co-maintainership, yes. Entering another discussion which loops back and forth without agreement, no. Please, for now leave out the hypothetical human resources who wish to maintain their own packages for many branches for an undeterminate period of time. So: How about we first define and agree on what level of maintenance we try to offer in Fedora Extras for current releases? These are things we must agree on! What do we try to offer? Ultimate stability? Leading-edge? Bleeding-edge? Version upgrade races with upstream? No goals at all? This thread even has the term "security" in the subject line. So: We do agree that current branches of FE shall be kept safe with security updates and that a security response team shall intervene where package maintainers cannot/do not react in time. Do we agree on that? That would be one step away from the infamous dumping ground. If we agree on how we try to maintain the current branch(es), we can proceed to finding out what additional or different policies, procedures and resources may be needed for legacy branches. We do agree that package maintainers may abandon their packages for legacy branches, don't we? A marker-file in CVS is easy to do, an unimportant implementation detail. A security response team (or co-maintainers, whatever, it doesn't matter) would need to take over those packages. Thorsten's message even tried to address that issue and added June 15 2006 as a time limit for proof of activity of the security response team. If packagers are permitted to add entirely new packages to legacy branches of FE, this may increase the maintenance burden for the security rt, since a) the packager cannot guarantee that he does the maintenance himself for an undeterminate period of time, and b) neither can he be forced to do it. > > What is the meaning of 'supported' for FE4 and FE5? > > Good question. No. Read on. > > I consider that > > FE is unsupported (as in the no waarranty clause of free software licences) > > being a project based on volunteering. > Silly. Look up the word "support" in a dictionary! The support we at Fedora Extras offer [or try to offer with no guarantees] is the level of maintenance: creation of packages, reviews, updates, upgrades, responses to bug reports, bug fixes, communication with upstream developers, monitoring of upstream activity wrt bugs, availability of servers and repositories, availability of rebuilds for FC(n+1), [...] -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
