On Wed, Apr 16, 2008 at 2:02 PM, Patrice Dumas <pertusus@xxxxxxx> wrote: > But I'd like to have first some discussion here to have a fedora point > of view. Just to be clear....you want a distro-specific point of view..about a distro-agnostic coordination process when packages across distributions fork due to a dead upstream. The gods of irony are pleased. Anything more than the following as a Fedora policy is needless micromanagement: 0) Oh crap... the stated upstream for a package you maintain is dead. Decide if the package should be orphaned or not. Set a Fedora tracking ticket indicating a dead upstream for a component. 1) Not orphaned? Look around and see if other distros are using a common defacto upstream. Use the defacto upstream if it exists and encourage them to formalize their commitment as an official upstream to begin integrating distro specific forking. Clear the Fedora tracking ticket with a comment. 2) If not, invite other distro maintainers to have a discussion about how to formalize a common upstream to begin the unforking process. If everyone can agree on a common upstream, use that and clear the Fedora tracking ticket with a comment referencing the discussion for the new upstream. Recommend using freedesktop's distribution list as neutral territory for the discussion if needed. Though if you have to have neutral territory to hold a discussion, then i daresay that's a sign that its going to be a pretty tough negotiation to reach a consensus. 3) If consensus can't be reached on how to build a common upstream... choose whatever distribution fork you feel best meets the needs of Fedora and use it as the upstream going forward. If you have to take over as upstream developer of a fork...setup whatever hosting instance you feel is best as an upstream location. Clear the Fedora project ticket with a comment referencing the failed discussion on how to find a common upstream. What matters is that a Fedora maintainer make the best effort to avoid unnecessarily maintaining a forked codebase. But if it has to be done, then they have the freedom to setup the parameters of that upstream project however they like. Being able to reference a credible attempt at creating a common upstream, should satisfy any need for a 'don't be evil' review of a maintainer's actions on a case-by-case basis. -jef -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
