diff options
Diffstat (limited to 'zarb-ml/mageia-dev/20110106/001984.html')
| -rw-r--r-- | zarb-ml/mageia-dev/20110106/001984.html | 111 |
1 files changed, 111 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/20110106/001984.html b/zarb-ml/mageia-dev/20110106/001984.html new file mode 100644 index 000000000..157d2c4c3 --- /dev/null +++ b/zarb-ml/mageia-dev/20110106/001984.html @@ -0,0 +1,111 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] New bugzilla proposal + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20New%20bugzilla%20proposal&In-Reply-To=%3C1294341301.3329.161.camel%40akroma.ephaone.org%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001982.html"> + <LINK REL="Next" HREF="001986.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] New bugzilla proposal</H1> + <B>Michael Scherer</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20New%20bugzilla%20proposal&In-Reply-To=%3C1294341301.3329.161.camel%40akroma.ephaone.org%3E" + TITLE="[Mageia-dev] New bugzilla proposal">misc at zarb.org + </A><BR> + <I>Thu Jan 6 20:15:01 CET 2011</I> + <P><UL> + <LI>Previous message: <A HREF="001982.html">[Mageia-dev] New bugzilla proposal +</A></li> + <LI>Next message: <A HREF="001986.html">[Mageia-dev] New bugzilla proposal +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1984">[ date ]</a> + <a href="thread.html#1984">[ thread ]</a> + <a href="subject.html#1984">[ subject ]</a> + <a href="author.html#1984">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Le jeudi 06 janvier 2011 à 18:43 +0100, Wolfgang Bornath a écrit : +><i> 2011/1/6 Michael Scherer <<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">misc at zarb.org</A>>: +</I>><i> > +</I>><i> > And for the rest, well, the bug be it in documentation, translation, or +</I>><i> > code must follow the same lifecycle, and imho, should be grouper +</I>><i> > logically and we should not duplicate information everywhere, with +</I>><i> > information being "version of the product/components". +</I>><i> +</I>><i> How would you group a translation error in the documentation of rpmdrake? +</I>><i> How would you group a documentation error in teh documentation of rpmdrake +</I>><i> How would you group a translation error in rpmdrake? +</I> +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 + +</PRE> + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001982.html">[Mageia-dev] New bugzilla proposal +</A></li> + <LI>Next message: <A HREF="001986.html">[Mageia-dev] New bugzilla proposal +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1984">[ date ]</a> + <a href="thread.html#1984">[ thread ]</a> + <a href="subject.html#1984">[ subject ]</a> + <a href="author.html#1984">[ author ]</a> + </LI> + </UL> + +<hr> +<a href="https://www.mageia.org/mailman/listinfo/mageia-dev">More information about the Mageia-dev +mailing list</a><br> +</body></html> |