-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Michael Schwendt wrote: | On Wed, 08 Jun 2005 16:33:17 +0100, Andy Green wrote: | | |>|>I don't know how to read that page except as a statement that you will |>|>not be cooperating with other repos |>| |>| Now you're jumping back and forth between different interpretations of the |>| page. ;) |> |>What was my alternative interpretation I just jumped from? | | The theories "cooperation is impossible" and "resistance is futile".
So this is my alleged "jumping back":
"cooperation is impossible" and "statement you will not be cooperating with repos" were based on reading your page we have been discussing, listing reasons why cooperation is not going to happen.
http://www.fedora.us/wiki/RepositoryMixingProblems
"resistance is futile" is based on the same page's explicit Cunning Master Plan to make a single repo that includes everything (except non-Redhat-friendly packages with MP3/mplayer/etc), and to enBorgulate all independent packagers.
and quoted above is my alleged "jumping forth":
''I don't know how to read that page except as a statement that you will not be cooperating with other repos''
Seems unusually consistent to me. Dag had the same understanding too:
http://dag.wieers.com/home-made/apt/FAQ.php
|>Encourage the independent packager to submit their packages to Fedora |>QA. After package improvement, QA testing and some security |>verification, their package can be in the Fedora tree. The original |>packager gains the support of other Fedora developers, Bugzilla and |>other infrastructure to raise the level of quality and compatibility of |>submitted packages.'' |> |>That was the only way I saw on the page you would work with the |>[previously] "independent packager". However I note some willingness |>further down in your last mail. | | Once again you're reading between the lines, which is kind of becoming a | hopeless case. That paragraph encourages users to do something when they
I agree this thread isn't getting anywhere useful, but noting that sumbitting packages to you is "the only way I saw on the page you would work with the [previously] "independent packager"" is not "reading between the lines", it is reading the words on the lines.
|>| not done. Fedora Extras is treated as _the_ primary base repository after |>| Fedora Core, which can be built upon. It is focused on these two. External |>| package providers are welcome to offer add-ons on top of Core+Extras. And |> |>Yeah, as I wrote before (base+extras) is the new base. Again the effect |>is to pull packages from the RPMForge orbit into Extras, which because |>of its "enabled by default" feature and Fedora relationship is likely to |>become the uber-repo that you envisage. | | Which is a good thing.
High quality GPL'd packages coming out of Extras have to be a good thing for everybody. RPMForge getting packages sucked out of it does not sound like a good thing for most people.
|>| in case an external repository, which depends on Core+Extras, needs |>| software versions newer than what is provided in Extras, that would be a |>| scenario for coordination attempts with focus on not breaking Extras. A |>| way of "upgrade first, then deal with the wreckage" is not something |>| anyone at Fedora Extras will like. |> |>It's encouraging that "Cooperation is possible" then... but this is new |>information to me. | | As long as you can't explain where your "cooperation is impossible" | theory comes from, I cannot comment on this. Then there's still the | question what kind of cooperation do you think of?
Lol... since you today noted that cooperation is possible, I am pleased to agree with you it is possible. But anyone reading your old document will not come away with that impression I think. Maybe you should update it with this case where cooperation is possible.
|>|>|>| Have you ever before thought about how exactly collaboration between |>|>|>| multiple repositories could work? If so, care to share some thoughts? |>|>|> |>|>|>Yeah. Have you thought about extending RPM? |>|>| |>|>| An extended/enhanced RPM is _not_ something we have at the moment. It's |>|>| not something that was available when Fedora at fedora.us was discussed. |>|>| It's not ready. Hence it doesn't solve any problem. It doesn't |>remove the |>|>| need for fine-grained packaging policies either, which extend up to the |>|>| spec-file level. |>|> |>|>What kind of policies are we talking about here? Since everyone at |>|>least agrees to be compatible with Fedora base, maybe these problems too |>|>are open to a technical solution. |>| |>| Policies about everything that would ensure that package "foo" in |>| repository X is fully compatible with repository Y. |> |>Is there a URL with a canonical list anywhere? | | Existing packaging policies/guidelines (see fedoraproject.org wiki) are | not as detailed as would be necessary to guarantee that if two developers | packaged the same software, the results would be equivalent/compatible.
I think with a will to be inclusive and improvements to the tools, you can probably resolve the messy problems without mandating more detailed policies.
Anyway, I detect we are going around in circles and not moving forward, you are welcome to the last word.
- -Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFCp1aCjKeDCxMJCTIRAutbAJ9/XiUmHWv6A4P21t6MzdsjSKHXSACfTpYy oIrOg+XP4b8qvW2pOFyg9tM= =dPpD -----END PGP SIGNATURE-----
