[Talk-de] RFC: Tags für Tags

[Bernd Wurst]

Hallo.

Am Freitag, 22. August 2008 schrieb Frederik Ramm:
> Bernd Wurst wrote:
> > Ein Fork eines kompletten Projekts (das ist effektiv das was du
> > vorschlägst, bezüglich Arbeitsaufwand und Akzeptanz) ist in der
> > Software-Szene immer das letzte Mittel und kommt ganz weit hinter einer
> > offenen Kommunikation wie ich sie hier eigentlich anstrebe.
> Quark. Als wir damals die Umstellung von 0.4 auf 0.5 gemacht haben, sind
>   wir *genau* so vorgegangen: API angepasst, Editor angepasst,
> existierende Daten exemplarisch konvertiert, und den Leuten gesagt:
> Hier, schaut mal, waer das nicht was fuer uns. Niemand hat von einem
> Fork geredet, hoechstens von einem Branch!

Wer immer "wir" ist... 
Wurde nicht vorher mal generell irgendwo ganz unverbindlich mit "normalen" 
Mappern die Idee diskutiert, ob denn eine Abschaffung von Segmenten 
vielleicht Sinn machen würde? Wurde nicht vorher mal von jemandem gefragt, ob 
es nicht einer Möglichkeit bedarf, mehrere Objekte in einer Gruppe zu 
vereinen?

War der fertige, lauffähige Code von API und Editor wirklich das erste was 
über das "wir" hinaus bekannt wurde?

Wenn ja, dann ist das immernoch ein bescheuertes Entwicklungskonzept aber dann 
hat es wenigstens im Endeffekt geklappt, Respekt.

Wenn nicht, dann überleg(t) bitte vor so einem Posting in welcher Phase sich 
mein Gedanke momentan befindet! Wenn hier 20 mal "Ja, das wäre klasse" 
gekommen wäre, hätte ich es gerne mal implementiert, so jedoch konnte ich 
gleich alternative Vorschläge erhalten, von denen man sich was gutes 
zusamenbasteln kann.

Gruß, Bernd

-- 
Die Philosophie ist eine Art Rache an der Wirklichkeit.  -  Friedrich 
Nietzsche
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 835 bytes
Beschreibung: This is a digitally signed message part.
URL         : <http://lists.openstreetmap.org/pipermail/talk-de/attachments/20080822/62e16ff8/attachment.sig>