Açık kaynaklı bir uygulamayı değiştirme

9

Başlangıçta yazmadığım bir açık kaynak uygulamasına bir özellik eklemek istediğimde genel iş akışı nedir? Kodu nasıl öğrenebilirim? Değiştirilmesi veya eklenmesi gereken yeri nasıl bulabilirim? Başka bir şeyi bozmadan değişikliği nasıl yapabilirim? Her şeyin hala çalıştığını nasıl test edebilirim?
Böyle bir projeyle ilgili genel yönergeler nelerdir?

open-source 
— Dani
kaynak
2
Ayrıca , değişikliklerinizi projeye, genellikle bir yama olarak, başkalarının faydalanabilmesi için göndermelisiniz.

Yanıtlar:

6

Bazı protokoller var, herkes az çok zamanla onu terk ediyor, ama işte burada.

  • Dağıtılmış kaynağı indirirsiniz.

  • Kodu kendiniz biraz gezinmeye başlıyorsunuz

    • Derlenmiş bir programsa, şimdi nasıl derleneceğinizi öğrenirsiniz .
    • Derleme konusunda başarısız olursanız, yazar / posta listesine rapor verir ve yol tariflerini alırsınız

  • Kod hakkında gerçekten bir şey anlamıyorsanız ...

    • Eh, hayır, yok onlara yakın isteyin.
    • Bunu bırakıyorsunuz, çünkü muhtemelen eşit değilsiniz ve gerçek bir yardımdan yararlanamazsınız.
    • Yazar (lar) özellik isteklerini kabul ederse bir özellik gönderirsiniz.

  • Başka

    • Değiştirmek istediğiniz yeri bulursunuz.

    • Bazı küçük ayrıntılar merak ediyorsanız, yazar / posta listesini sorar ve niyetlerinizi açıklarsınız.

    • Dağıtımın ana dizinine cd yaparsınız (en üstteki untarring / unzipping)

    • Sen diff -ur . > mypatch.path

    • mypatch.patchNe yaptığınızı, neden yaptığınızı açıklayan yazara gönderirsiniz ve (zaten oradayken) yamadaki haklardan onlara feragat ettiğinizi açıkça belirtirsiniz.

  • yazar (lar) katkınızı beğenmiyorsa

    • değişikliklerinizi bir tür eklenti olarak yayınlamanın bir yolu olup olmadığını kontrol edersiniz

      • bu durumda, şimdi bir eklenti mantainer olma yolundasınız .

    • Başka

      • blogunuzdaki durum hakkında alev atıyor ve yamayı orada açığa çıkarıyorsunuz, açıklamak ve açıklamalarınızla indirmek ve denemek için ücretsiz,

      • Şimdi ve sonra hata sistemi / posta listesi yama için destek satın almaya çalışırken. Yasaklanmaktan kaçının.

    • bu durumların hiçbirinde kodu zorlamıyorsunuz, çok yorucu ve akıl almaz bir süreç olduğundan, zamana ayak uyduramayacaksınız: bu, kullanıcıları üzgün ve karışık bırakacaktır. Çatallar gerçekten sadece büyük bir şirket kararlarını bir OSS parçasına zorbalık yapmaya çalıştığında gerçekleşir .

  • Başka

    • bu yazar (lar) dan başka talimatlar alırsınız

Yanda: diff -ur .yamaya yeni bir alternatif var ve github yolu .

  • Kodlarını adınızın altında github'da "çatalıyorsunuz"
    (şimdi hesabınızda kodlarının bir kopyası var)
  • git'inizi o kişisel kopyanıza bağlayın,
  • üzerinde değişikliklerinizi yapın, kontrol edin,

  • ve ana yazar (lar) a github projenize bakmasını söyleyin.

  • Eğer beğendiyse, senkronize olacaklar .

  • Aksi takdirde, "gitfork" u blogunuza bağlayabilirsiniz.
— ZJR
kaynak
OP'nin yeni yazar yamasını benimsemediği için ürün yazarlarını alevlendirmesini önerene kadar iyi, bunun her iki şekilde de komik mi yoksa ciddi mi olması gerektiği belirsiz, çünkü tüm dünyaya küçük bir çocuk gibi etkili bir şekilde ağlamak ÇOK kötü bir form. bir ürün ekibi yeni özellik yamanızı beğenmez / istemez. Elbette, karar verin, ne kadar mantıksız göründüğüne bakılmaksızın, kabul edilmediyse her zaman muazzam olun. -1 - Bilginize, kaldırırsanız oyumu memnuniyetle tersine çevireceğim.
— ocodo
Değiştirmek istediğim uygulama, yaptığım değişikliklerle standardı kıracak katı bir standardı takip ediyor. Sanırım yamamın uygulanmasını isteyecek konumda bile değilim.
— Dani
@Slomojo OSS olgunlaşmamış insanlarla doludur ve bu tür şeyler her zaman olur, herkes bir katır gibi çalışmaya hazır olmalı ve daha sonra bazen sağlam ve bazen tartışmalı olarak reddedilmelidir . Ve sonra, en azından, her zaman bu konuda koşma ve haklı olduğunu düşünen insanları bulma şansın var. Şimdi, inatçıdan vazgeçmek, bu yanlış ve çok alçakgönüllü bir adım olacaktır.
— ZJR
@Dani lol, gerçekten paylaşım bir yama almak zorunda ve bu konuda rant . Hayatınızı tüketeceğinden çatal vermekten kaçının, maaş çekmeden sürekli olarak yeniden düzenleme gibi hissedersiniz. ... her neyse, birinin böyle bir uzantıyla ilgilenip ilgilenmeyeceğini görmek için posta listesine ve hata rapor sistemine bakın, belki yalnız değilsiniz. Aaave en iyisi, genişletmek için bazı API veya değişikliklerinizi eklemek için bir eklenti-şey olurdu. Bu gibi durumlarda her zaman en iyi seçenek budur: bir eklentiyi korumak . ... bunu düzenleyecek.
— ZJR
2
otomatik test senaryoları varsa, düzeltme ekini göndermeden önce bunları çalıştırın.
— oenone
0

Tipik.

Rastgele bir işletim sistemi projesi olsaydı, büyük olasılıkla burada ve orada küçük hataları düzeltirdiniz.

Sonunda bir "değişiklik" olarak bir grup değişiklik gönderirsiniz.

Eşyalarınız iyi olursa genellikle taahhüt hakları elde edersiniz.

Genel olarak ve soru yüzünden mümkün olduğunca belirsiz ve belirsiz konuşuyorum

— MattyD
kaynak
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.