[Mageia-dev] New bugzilla proposal

Thu Jan 6 20:15:01 CET 2011

Le jeudi 06 janvier 2011 à 18:43 +0100, Wolfgang Bornath a écrit :
+> 2011/1/6 Michael Scherer <misc at zarb.org>:
+> >
+> > And for the rest, well, the bug be it in documentation, translation, or
+> > code must follow the same lifecycle, and imho, should be grouper
+> > logically and we should not duplicate information everywhere, with
+> > information being "version of the product/components".
+> 
+> How would you group a translation error in the documentation of rpmdrake?
+> How would you group a documentation error in teh documentation of rpmdrake
+> How would you group a translation error in rpmdrake?
+
+The question before "how" is "why".
+Why would you want to group all documentation error together ?
+
+Grouping by "product" ( not in the bugzilla meaning ) is IMHO required
+to avoid duplication of version, to be able to see what bugs affect a
+precise version of a software, be it a documentation bug, translation
+bug and so on, and so decide if a software is ready for release.
+
+And the problem is we are mixing the package and the software, and I
+think we should not.  
+
+One of the goal of the project is "work in collaboration with other open
+source projects.". Code reuse is one of the way to achieve it.
+
+But not having a clear separation between distribution ( aka rpm ) and
+software ( ie, tarball and code ) prevented code reuse in the past at
+least at a psychological level, if not at a practical level.
+
+Code and package were not separated, so editing urpmi spec required to
+use a different procedure. That's 1 bad point ( exceptions are always
+sooner or later causing human error ).
+
+Not separating code and packages make people forget to keep genericity
+in mind, thus preventing code reuse ( hardcoding configuration, or thing
+that should be made more generic ). See the work we have to do on youri.
+
+We didn't have formal release process for tools like urpmi, no external
+website, no tarball. Basically, no visibility. And the idea of a forge
+was partially fueled by this, at least from what I remember ( ie to give
+visibility, to ease outside contribution ).
+
+So, treating all rpm the same, wether we develop it or not is more
+coherent ( no exception on bug that should be reported either upstream
+or not, so easier to decide ), would enhance external reuse and
+contribution ( more visibility ), and raise quality ( as we will have to
+think to more than our use case ).
+
+
+-- 
+Michael Scherer
+
+