[Mageia-dev] New bugzilla proposal

[Michael Scherer]

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