From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001 From: Nicolas Vigier Date: Sun, 14 Apr 2013 13:46:12 +0000 Subject: Add zarb MLs html archives --- zarb-ml/mageia-dev/20110209/002511.html | 125 ++++++++++++++++++++++++++++++++ 1 file changed, 125 insertions(+) create mode 100644 zarb-ml/mageia-dev/20110209/002511.html (limited to 'zarb-ml/mageia-dev/20110209/002511.html') diff --git a/zarb-ml/mageia-dev/20110209/002511.html b/zarb-ml/mageia-dev/20110209/002511.html new file mode 100644 index 000000000..02abd16d6 --- /dev/null +++ b/zarb-ml/mageia-dev/20110209/002511.html @@ -0,0 +1,125 @@ + + + + [Mageia-dev] 26/01/2011 meeting + + + + + + + + + +

[Mageia-dev] 26/01/2011 meeting

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Wed Feb 9 17:35:45 CET 2011 +

+
+ +
On 9 February 2011 11:27, Michael scherer <misc at zarb.org> wrote:
+> On Wed, Feb 09, 2011 at 12:22:59AM +0200, Ahmad Samir wrote:
+>> On 8 February 2011 08:21, Cazzaniga Sandro <cazzaniga.sandro at gmail.com> wrote:
+>> > Le 07/02/2011 22:11, Ahmad Samir a écrit :
+>> >>
+>> >> Personally, as I said before about upstreaming patches, I don't think
+>> >> I have enough experience to judge if a patch should go upstream or
+>> >> not, so that part I can't do.
+>> >>
+>> >> What do you mean by "commented"?
+>> >
+>> > A thing like:
+>> >
+>> > #patch from .... to fix truc
+>> > Patch0: glibc-2.12-truc.fix.patch
+>> >
+>>
+>> That's usually available in the svn log, whoever wrote the patch
+>> should have commented it if that is the policy, however I am not aware
+>> that such a policy exists (IMBW though).
+>
+> There is no specific policy despites the matter being discussed some time
+> ago, but to me, this is the only way to know what was send upstream
+> and what wasn't.
+>
+> It is ok if someone is not sure to send upstream or not,
+> but we cannot know if this is not written. And searching the svn log is tedious,
+> people usually say "add patch to fix stuff", without giving the name. And you
+> have to search for every patch, and nobody ever say what is the upstream
+> status of the patch.
+>
+> So writing in the spec, just before the patch what it does, if it was sent
+> upstream, and where ( or why it shouldn't ) allow to quickly see the status.
+>
+> For example, I found while cleaning newt that some patches where never send
+> to developpers ( and so I did ), that 2 patchs were wrong.
+>
+> So we cannot assumed that it was send back, even when we take the file from another
+> distribution.
+>
+> I started working on a prototype of a web interface to manage this ( called ghostwheel ),
+> but it requires some functions on sophie to work ( and didn't had time to code them ).
+> ( a django web application, so far it does nothing except declaring a db and having a
+> cool name ).
+>
+> If we do not comment and send upstream, we will end up with rpm like gdb :
+>
+> When you look at it ( http://svnweb.mageia.org/packages/cauldron/gdb/current/SPECS/gdb.spec?revision=21081&view=markup ),
+> the patch 320 ( and others ) that seems to come from gdb 6.5, you see there is something fishy
+> since we are now running gdb 7.1. Some seems to be linked to bugzilla ( no mention of the url
+> of the bz ), but does it mean they were sent uptream or not ?
+> The various format-security patches, etc, should also be commented
+> and send upstream. The patches about IA64 should maybe have been cleaned, etc.
+>
+> Ask teuf why it took so long to upgrade gdb :)
+> --
+> Michael Scherer
+>
+>
+
+I agree it's good practice to comment on patches in the spec. But if
+you expect me to trudge through the svn log of each package I
+import/imported to see why a patch was added and add a comment in the
+spec then I won't import any packages.
+
+I am not going to correct a behaviour that was in effect for years as
+"it's not my fault to begin with"... :)
+
+-- 
+Ahmad Samir
+
+ + +
+

+ +
+More information about the Mageia-dev +mailing list
+ -- cgit v1.2.1