diff --git a/pisi/install.py b/pisi/install.py
index 265dada0..dab49350 100644
--- a/pisi/install.py
+++ b/pisi/install.py
@@ -26,6 +26,15 @@ class InstallError(Exception):
 ## evet module'un ismi yanlis. ozunde install/upgrade/remove
 ## islemlerinin cok buyuk farklari yok. hepsine operations.py denip
 ## su class gereksizliginden kurtulacagim.
+#
+# operations.py'yi ayrıca yapalım. Tek paket kurulumunu ayrı bir modül
+# ile kotarmak daha temiz bir implementation'a götürecektir
+# bizi. PisiInstall'un sınıf olması ise bence gereksiz değil, install
+# sırasında kullanılan ortak veriyi aşağıda görüyoruz zaten. Ayrı ayrı
+# fonksiyonlar ve ilk parametre olarak "package_fn" gibi bir değerin
+# gönderilmesi gereksiz bence. Dahası bu PisiBuild ile de uyumlu bir
+# implemantation olduğu için daha rahat anlaşılır bir kod tabanı
+# oluşturuyor. (baris)
 def remove(package_name):
     """Remove a goddamn package"""
     ui.info('Removing package ' + package_name)
@@ -43,6 +52,16 @@ class PisiInstall:
         self.ctx = installcontext
         ## bu context fikri multi package installation fikriyle
         ## uyusmuyor ne yazik ki. gitmesi gerek.
+        #
+        # Ben buna karşıyım. Multi-package işini kotarmak yalnızca
+        # install'da değil hemen hemen tüm işlemlerde halletmemiz
+        # gereken bir iş. Build, install, remove, upgrade, vs. hemen
+        # hepsinde multi-package ile ne yapacağımıza karar vermemiz
+        # gerekiyor. Bu yüzden katman katman düşünelim
+        # işleri. install.py tek paketi kuran bir modül, build.py'nin
+        # tek pspec.xml dosyasından peket derlediği gibi. Biz bu
+        # modülleri kullanarak üst seviye modüller ile çoklu paketler
+        # işini halletmeliyiz. (baris)
         self.metadata = self.ctx.metadata
         self.files = self.ctx.files
         self.package = self.ctx.package