[Hamara-devel] number of suggestions

[shirish शिरीष]

Hi all,
Just went through the month's mail. Number of things need to be pointed out :-

The Wiki -

a. While moinmoin has been used for now, I think that was a mistake
and will share the reasons for it :-

1. The comparison between moinmoin 1.8 and Mediawiki is wrong on
number of counts. As Mediawiki stands today, all the issues that have
been pointed out in moinmoin 1.8 are and have been handled in
mediawiki.

The most interesting which mediawiki has bought and wikipedia used a
lot is the talk page which is non-existent in moinmoin.

Allow me to share an e.g. :-

See https://en.wikipedia.org/wiki/Debian and more interestingly
https://en.wikipedia.org/wiki/Talk:Debian

That is how a wiki works and should work where people can throw
queries back and forth.

While Hamara is just getting its feet up there would be disconnect
with users till 'target users' are not identified.

For e.g. see http://wiki.hamaralinux.org/How%20do%20I%20calibrate%20my%20printer%3F

now if a newbie user were to per-use that article he would not know
how to make head or tail of it. And because there is no talk page s/he
would either try on the forum, or on the mailing list or IRC to figure
it out and the chances of the wiki article improving will be less . If
there was a talk page then that would be asked there and some
suggestions made on the article on the talk page itself.

You can also see the concept of badges which wikipedia was the
innovator of (which now mozilla thinks it made.)

https://en.wikipedia.org/wiki/Wikipedia:Barnstars

Now of course wikipedia is also getting into the badges bit

https://en.wikipedia.org/wiki/Wikipedia:BADGE

To add to it you can also do funky things like this :-

https://en.wikipedia.org/wiki/User:Shirishag75

Moinmoin doesn't have all these possibilities or at least haven't seen
any wikis of moinmoin which had these fun things. Whether or not
hamara wants to have fun things like these could be another question
so would let that be something you can look into.

BUGS -

b. Bugzilla has the most impossibiliest interfaces to work with. It is
fine if you are going to have only a few bugs there, but it is
impossible to navigate if you have any more than 100 odd packages.
https://bugzilla.mozilla.org/ is a prime example of why it doesn't
scale well.

You have few options before you -

a. Have your own server and put launchpad on it. That is what ubuntu
uses, the good points about it -

1. The code is GPLv3
2. It's good looking

b. For some reason if you don't like launchpad then you can use
debbugs. The good points about it :-

1. The code is GPL
2. The code can be found out at many places, for e.g. :-

http://git.donarmstrong.com/debbugs.git/
https://github.com/dondelelcaro/debbugs

3. Scalability is not an issue at all - 800000 bugs reported and more.
Both Debian and GNU BTS like it.

4. It is a pretty valuable asset when you are downloading new versions
of packages. See apt-listbugs specially when downloading new versions
and figuring out whether a package is safe for installation or not.
See https://flossexperiences.wordpress.com/2013/10/29/init-apt-listbugs-apt-listchanges/
to know more.

The downside - there is no web interface (yet) . There are GSOC
projects for that but only time will tell how good or bad they are.

This is one of the things which also clinched for me when I was
looking to jump from ubuntu to Debian, no single-sign-on stuff. While
people can easily get my public activity stats on the project, privacy
is still maintained.

c. Trac is also good, dunno if it was mentioned during bug-reporting
tools, I haven't seen it being used in large projects but it is good
looking and has integration with jenkins which would be a point in
it's feather.

" We will not do what Canonical is doing with Ubuntu, taking
everything from the community and returning back very little." - Raju

I think the best way would to say that all the code generated will be
GPLv2 or GPLv3 (depending on what the team is/would be ok with.) and
all the code will be available to per-useable on git.

Now what 'all' would cover or not cover would leave to the powers that be.

GNOME - QT - While it would not be the place to discuss that article,
would just say that the QT/KDE devs. used to be full of themselves
when they were getting good funding from Nokia. I also remember how
QT/KDE libraries will take over a GNOME session even if one QT/KDE
app. was opened up. Also getting the looks right was a nightmare in
QT/KDE.

The observations were in accordance with the Indian KDE folks at a
point in time years ago, hopefully they have changed but not known.

Rolling release or fixed release -

This is actually more of a non-issue. Neither of those matter because
you are assuming that people have good bandwidth which is not the
case. The underlying problem that needs to be tackled is updates and
that is severely broken. One way is what Debian does with point
releases, every couple of months or so they do point releases, for
e.g. Debian wheezy has had 8 point releases where only bug-fixes are
put up. But this means that you need two sets of people, one who would
be doing only the bug-fixes part while the other set of people do
development. This is what Ubuntu tried and failed.

Rolling release is also a good idea but you would need to have
snapshots for people to get on. How frequent/in-frequent these
snapshots should be would be anybody's guess.

Looking forward to what people think of the above.
-- 
          Regards,
          Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8