Éric Marcoux
email: eric.marcoux@univ-orleans.fr

Noémie Breillat

Catherine Guerrot

Philippe Négrel

Berrada Samia

Hmima

David Selby

Multi-isotopic tracing (Mo, S, Pb, Re-Os) and genesis of the Mo-W Azegour skarn deposit (High-Atlas, Morocco) 2019, February 25 th

Keywords: Azegour skarn, molybdenite, molybdenum, lead, sulphur, isotopes, Re-Os geochronology, mineralization

The Mo-Cu-W Azegour skarn, located in the High-Atlas in Morocco, is associated with a Late Hercynian alkaline granitic intrusion. Here the origin of the mineralisation via Re-Os geochronology and using Mo, S and Pb isotopes is discussed. The age of mineralization defined by Re-Os molybdenite geochronology is 276 ± 1.2 Ma for the Azegour mine, and 267 ± 1.2 for the Tizgui deposit suggesting for multiple mineralization events associated with the Hercynian alkaline granitic intrusion. The δ 98 Mo NIST of molybdenite range from -0.60 ‰ to 0.42 ‰ (n=26) for the Azegour mine and from 0.08 ‰ to 0.40 ‰ (n=2) for the Tizgui mine. Variations of the δ 98 Mo NIST occur either at the deposit scale with a difference of about 0.72 ‰, and at the sample scale (few cm), which exhibits a difference of up to 0.40 ‰. A multi-phased mineralization is proposed as the main processes explaining the variation in the δ 98 Mo NIST values although the influence of a Rayleigh fractionation process cannot be precluded. The high δ 34 S values determined from molybdenite, pyrrhotite, and chalcopyrite (8 to 14.7 ‰) suggest a sedimentary origin for sulphur from the Cambrian sedimentary country rocks. Whereas, the initial 206 Pb/ 204 Pb compositions of common lead (18.08 to 18.30) for

Introduction

Skarns are among the most common types of deposit in the world and have been widely studied. They form large deposits of tungsten, lead-zinc, copper and gold, and also yield tin in the form of cassiterite, and very seldomly, molybdenum.

The present study focuses on the Azegour Mo-skarn in Morocco. Located in the High-Atlas, the Azegour site (Fig. 1) is a Mo-W-Cu skarn with production from three historic mines: main Azegour, by far the main one, Tizgui and Entifa. This skarn was exploited from 1932 to 1959 supplying 1300 t of MoS 2 . The Mo content is estimated around 8000 t (Permingeat, 1957). A re-opening of the mine is possible. Molybdenite is not the only economically important mineral in the Azegour skarn, scheelite and chalcopyrite were reported at economic grades (Permingeat, 1957). The existence of Mo mineralization and deposits in this area occurs over more than 3.5 km (Fig. 2).

Figure 1: Location of the Azegour skarn in North part of Moroccan High-Atlas

Molybdenum (Mo) isotopes are commonly used to investigate (paleo-)redox conditions, Mo input into the oceans from weathering, and more recently, as with other transition-meta isotopesl, for studying trace-metal pollution [START_REF] Archer | The isotopic signature of the global riverine molybdenum flux and anoxia in the ancient oceans[END_REF]. In the frame of mineral resources, only few studies have been performed regarding Mo isotopes in molybdenite. These studies have principally focused on molybdenite in pegmatite veins [START_REF] Greber | Mo isotope composition in Mo-rich high-and low-T hydrothermal systems from the Swiss Alps[END_REF], and porphyry systems [START_REF] Greber | Magmatic-hydrothermal molybdenum isotope fractionation and its relevance to the igneous crustal signature[END_REF][START_REF] Shafiei | Mo isotope fractionation during hydrothermal evolution of porphyry Cu systems[END_REF] and on

M A N U S C R I P T A C C E P T E D ACCEPTED MANUSCRIPT

3 other molybdenite-bearing ore deposits [START_REF] Hannah | Molybdenum isotope variations in molybdenite: Vapor transport and Rayleigh fractionation of Mo[END_REF][START_REF] Mathur | Variation of Mo isotopes from molybdenite in high-temperature hydrothermal ore deposits[END_REF][START_REF] Breillat | A new global database of δ 98 Mo in molybdenites: A literature review and new data[END_REF]. These studies suggest that the influence of the crystallisation temperature, stage of crystallisation, Rayleigh processes and crystal structure (2H or 3R polytypes) are factors that control the Mo isotopic composition.

Here we utilize Mo, together with Pb and S isotope data of sulphides and gangue minerals and Re-Os molybdenite geochronology to provide an improved understanding of the genesis of the Mo mineralisation of the Azegour skarn deposit system.

Geological context

The molybdenum-copper Azegour skarn in Morocco is located 60 km south of Marrakech in the northern boundary of High Atlas Mountains (Fig. 1) (coordinates: 31°09'16" N, 8°18'19" W). Numerous studies have discussed the geology of the Azegour skarn over the past 80 years (e.g., [START_REF] Moret | Recherches géologiques dans l'Atlas de Marrakech[END_REF][START_REF] Heim | The molybdenum mine at Azegour, Morocco[END_REF]Permingeat, 1957;[START_REF] El Amrani | Contribution à l'étude pétrologique, minéralogique, métallogénique et de pétrologie structurale des formations de la région d'Azegour (Haut-Atlas occidental, Maroc)[END_REF][START_REF] Berrada | Mineralogical and geochemical features of the wollastonite deposit of Azegour, Haut-Atlas (Morocco)[END_REF], 2015). The skarn formed as the result of the intrusion of a Permian granite into a series of volcano-sedimentary units (Fig. 2 and3) dated Cambrian by the presence of Archoeocyathydes [START_REF] Neltner | Assessment of the 187 Re decay constant by cross calibration of Re-Os molybdenite and U-Pb zircon chronometers in magmatic ore systems[END_REF].

Figure 2: Geological map of the Azegour region. Figure 2 is fully contained in the red triangle on figure 1

The volcano-sedimentary series are composed of grey to black shales, a volcanic unit (with dominant andesitic flows and dacitic pyroclastic rocks), marbles, recrystallized limestone and dolostone. A Late Hercynian alkaline granitic intrusion [START_REF] Lagarde | Granites tardi-carbonifères et déformation crustale. L'exemple de la Meseta marocaine[END_REF][START_REF] Mrini | Chronologie Rb-Sr des granitoïdes hercyniens du Maroc : conséquences[END_REF], named the Azegour granite, outcrops for 7 km along a NW-SE direction with a 1 km width.

The skarn is developed within the Palaeozoic volcano-sedimentary units (Fig. 2).

M A N U S C R I P T A C C E P T E D ACCEPTED MANUSCRIPT

Figure 3: Granite and skarn contact in Azegour

The Azegour granite is hyperaluminous [START_REF] Lagarde | Granites tardi-carbonifères et déformation crustale. L'exemple de la Meseta marocaine[END_REF][START_REF] Ait Ayad | Le Granite d'Azegour (Maroc) : cartographie géochimique et interprétation géodynamique[END_REF] and is mainly composed of quartz, feldspar (orthoclase and plagioclase), and minor biotite. The granite crystallisation is dated at 269 ± 11 Ma [START_REF] Charlot | Rapport technique et quelques résultats[END_REF] and 271 ± 3 Ma [START_REF] Mrini | Age et origine des granitoïdes hercyniens du Maroc; Apport de la géochronologie et de la géochimie isotopique (Sr, Nd, Pb)[END_REF] by the Rb-Sr method. The Sr and Nd initial ratios (I Sr = 0.7051; ε Nd(T) = -1; T = 270 Ma) obtained on the Azegour granite suggest a composite origin (crust-mantle) with a strong mantle component [START_REF] Mrini | Age et origine des granitoïdes hercyniens du Maroc; Apport de la géochronologie et de la géochimie isotopique (Sr, Nd, Pb)[END_REF][START_REF] Mrini | Chronologie Rb-Sr des granitoïdes hercyniens du Maroc : conséquences[END_REF]. Metasomatized carbonate layers constituting the skarn are several meters thick, and are mainly composed of massive garnetite and/or wollastonite-rich rock, with rare pyroxenite. Garnets belong to three different types: a green-black garnet is very common, forming crystals up to 8 cm, and composed of andradite with locally a core of Al-rich andradite (up to 5 % Al 2 O 3 ); a very common brown-black garnet forms thick layers associated with quartz and commonly reveals a core of pure andradite surrounded by a Al-rich andradite (up to 10 % Al 2 O 3 ), close to a grossular type, and an orange garnet (Toulkine village zone) that is compose of only grossular garnet. The abundance of spessartine is always low (4 % maximum). Wollastonite is slighly manganiferous, whereas vesuvianite is F-and Cl-rich (up to 3.3 % and 1.2 %, respectively).

The mineralogical assemblage suggests the formation of the prograde stage of the skarn occurred at around 620 -650 °C, under a pressure of 1.7 -2 kbar, and a fCO 2 of 31 mole %, in a reducing environment (fO 2 of 10 -18 to 10 -16 atm.), preceding a retrograde stage. Sulphides formed during the retrograde stage (< 450 °C) [START_REF] Berrada Hmima | Le skarn Mo-W-Cu à grenat, wollastonite, pyroxène et vésuvianite d'Azegour (Haut-Atlas, Maroc)[END_REF]. The garnetites are the main Mo-bearing rocks in the form of large (up to 3 cm) molybdenite crystals (Fig. 4). Similar to molybdenite, scheelite occurs only in garnetite, whereas chalcopyrite and pyrrhotite (Fig. 5) are mainly associated with pyroxenite. The skarn is widely overlain by Cretaceous formations.

Photograph in reflected light

Methodology

Molybdenum isotopic composition

The analyses of molybdenum isotopic composition have been performed at BRGM (France) on 29 samples of molybdenite. The procedure for analysing the Mo isotopic composition in molybdenite has been described in detail in [START_REF] Breillat | A new global database of δ 98 Mo in molybdenites: A literature review and new data[END_REF]. As Mo is the major cation in molybdenite (59.94 %), no chemical purification prior to analysis was undertaken (Anbar et al., 2001;[START_REF] Barling | Natural mass-dependent variations in the isotopic composition of molybdenum[END_REF][START_REF] Malinovsky | Variations in the isotopic composition of molybdenum in freshwater lake systems[END_REF][START_REF] Mathur | Variation of Mo isotopes from molybdenite in high-temperature hydrothermal ore deposits[END_REF]. [START_REF] Mathur | Variation of Mo isotopes from molybdenite in high-temperature hydrothermal ore deposits[END_REF] evaluated possible matrix effects induced by the lack of chemical purification for molybdenite by analysing the same sample with or without purification and both results were in agreement. Around 100 mg of molybdenite (single grain for large crystals, multiple grains for disseminated molybdenite) was handpicked and then finely crushed in order to homogenize the sample. Around 10 mg of molybdenite powder were dissolved in 4 ml of aqua regia (1 ml of HNO 3 7N and 3 ml of HCl 8N) at 100 °C in PTFE beakers until complete dissolution. The solutions were dried and the residues were dissolved in 10 ml of HNO 3 3 % (v/v). From this concentrated solution, a final solution was prepared in HNO 3 3 % in order to get a final Mo concentration of 1 µg.ml -1 (allowing a signal of around 2.5 V on mass 95 Mo).

Zirconium was added to this solution to yield a concentration of 0.5 µg.ml -1 (allowing a signal of around 4 V on mass 90 Zr). The Mo blank level for the whole procedure is less than 0.05 % and thus negligible as compared to the sample concentration. The Mo-isotopic composition analyses were performed using an MC-ICP-MS Neptune (Thermo-Finnigan). Zirconium (Zr) and ruthenium (Ru) produce several isobaric interferences on 92, 94, 96 and 96, 98, 100 masses, and only 95 Mo and 97 Mo are free of interference. Such interference is easily corrected with the following cup configuration: 90 Zr-L3, 91 Zr-L2, 92 Mo-92 Zr-L1, 94 Mo-94 Zr-Ax, 95 Mo-H1, 97 Mo-H2, 98 Mo-98 Ru-H3, 99 Ru-H4. In our samples and standards, ruthenium has never been detected. The Mo-isotope measurements were run within sequences composed of blank, standard and sample analyses. After the sample and standard analyses, two minute washes (HNO 3 3 %) are done to get the low background values (less than 5 mV). The reported data represent the mean value of a minimum of 5 runs of 20 measurements. Mass bias was corrected by 90 Zr /91 Zr external spiking (Zirconium ICP standard CertiPUR Merck) at 0.5 µg.ml -1 [START_REF] Anbar | Precise determination of mass-dependent variations in the isotopic composition of molybdenum using MC-ICP-MS[END_REF] and standard-sample-standard bracketing. The external long-term reproducibility obtained during the course of this study was 0.08 ‰ (2σ, n = 137) for an ICP standard solution (Techlab n°B3015042). In order to test the reproducibility of our procedure on the same matrix, a Re-Os molybdenite standard (Henderson Molybdenite Reference Material 8599 [RM8599], [START_REF] Markey | Standardizing Re-Os geochronology: A new molybdenite reference material (Henderson, USA) and the stoichiometry of Os salts[END_REF] has been repeatedly analysed as a secondary standard. All data are reported as classic δ 98 Mo NIST units relative to a standard solution, in this case NIST SRM 3134 (lot # 891307), according to the following formula (Eq. 1):

δ 98 Mo NIST = ቂ ሺ వఴ ୭ వఱ ୭ ⁄ ሻ௦ ሺ వఴ ୭ వఱ ୭ ⁄ ሻ௦௧ௗௗ -1ቃ * 1000 (Eq. 1)
The NIST SRM 3134 solution (lot#891307) has been proposed as a reference for reporting Mo-isotopic compositions [START_REF] Wen | Isotopic delta values of molybdenum standard reference and prepared solutions measured by MC-ICP-MS: Proposition for delta zero and secondary references[END_REF][START_REF] Greber | δ 98/95 Mo values and molybdenum concentration data for NIST SRM 610, 612 and 3134: Towards a common protocol for reporting Mo data[END_REF][START_REF] Goldberg | Resolution of inter-laboratory discrepancies in Mo isotope data: an intercalibration[END_REF].

Following [START_REF] Goldberg | Resolution of inter-laboratory discrepancies in Mo isotope data: an intercalibration[END_REF], the δ 98 Mo NIST of NIST SRM 3134 is defined as 0 ‰ and data are reported according to this value. The reference material 8599 yielded a δ 98 Mo NIST of - (2σ, n = 85;[START_REF] Breillat | A new global database of δ 98 Mo in molybdenites: A literature review and new data[END_REF]. Variation between samples is expressed as ∆ 98 Mo which corresponds to the difference between the maximum and the minimum values of δ 98 Mo NIST .

M A N U S C R I P T A C C E P T E D ACCEPTED MANUSCRIPT 7 0.20 ± 0.08 ‰

Sulphur isotopic composition

The sulphur isotopic compositions were measured in BRGM (France) for molybdenite, chalcopyrite and pyrrhotite samples from the Azegour skarn. Molybdenite flakes were handpicked, and then crushed in agate bowl. Chalcopyrite and pyrrhotite were collected using a Dremel™ drill. Around 100 to 150 µg of the obtained powder with pentoxide of vanadium as catalyser were placed into a tin capsule. Analyses were performed on Elementary Analyser IRMS Delta V Plus (Thermo Finnigan). Sulphides were converted to SO 2 with a flash combustion at 1 000 °C and analysed after chromatographic separation. At least two replicates were performed. All data are reported as classic δ 34 S vCDT units relative to vCDT standard according to the following formula (Eq. 2):

δ 34 S vCDT = [ ሺ యర ୗ యమ ୗሻ ⁄ ௦ ሺ యర ୗ/ యమ ୗሻ௦௧ௗௗ
-1] * 1000 (Eq. 2)

Lead isotopic composition

Lead isotopic compositions of molybdenite, chalcopyrite, pyrrhotite samples from the Azegour skarn and K-feldspar from the Azegour granite have been measured in BRGM (France) according to techniques adapted from [START_REF] Marcoux | Isotopes du plomb et paragenèses métalliques, traceurs de l'histoire des gîtes minéraux. Illustration des concepts de source, d'héritage et de régionalisme dans les gîtes français[END_REF] and Pomiès et al. (1998).

After cleaning, sulphides (50 to 100 mg) are dissolved with a mixture of HNO 3 7N -HCl 6N and a drop of concentrated HBr in a Teflon container. Feldspars (200 mg) were dissolved in a closed container by using a HF-HNO 3 -HClO 4 mixture at 120 °C for one week. After evaporation, the residue was dissolved by using HCl 6N, and heat again at 120 °C for one

M A N U S C R I P T A C C E P T E D ACCEPTED MANUSCRIPT 8 week.
After complete dissolution (sulphides and feldspars), the solutions were dried and then dissolved with 3-4 ml of HBr 1N. The Pb was separated on quartz columns filled with 1 ml AG1X8 ion exchange resin by using HBr and HCl acids. The lead fraction is then purified on a small 0.1 ml column by using HCl. After evaporation the residue was then recollected with HNO 3 and dried again. Blanks for the overall procedure are lower than 100 pg and are negligible relative to the amount of sample analyzed. Measurements of the lead ratios ( 206 Pb/ 204 Pb, 207 Pb/ 204 Pb and 208 Pb/ 204 Pb) were obtained on static mode on a multicollector MAT262 Thermal Ionisation Mass Spectrometer. Samples and standards were loaded on a zone-refined Re filament previously outgassed. Silica gel was used as an emission stabilizer.

About 150 ng of lead were loaded with H 3 PO 4 onto each filament. The Pb isotopic ratios were corrected for a mass bias of 0.14 % per amu (atomic mass unit) determined by repeated measurements of the NBS982 standard. Individual error on all ratios is commonly better than 0.01% (2σ m ), whereas external reproducibility (2σ) is 0.06 % for the 206 Pb/ 204 Pb, 0.09 % for the 207 Pb/ 204 Pb and 0.12 % for the 208 Pb/ 204 Pb.

For chalcopyrite, pyrrhotite, molybdenite and K-feldspar, Pb, U and Th contents of the sample were used for correcting the measured Pb isotope ratios for the addition of radiogenic Pb, assuming a mean age of 270 ± 10 Ma. These corrections are insignificant for most of the samples due to very low U/Pb and Th/Pb values, except for AZT1a pyrrhotite ( 238 U/ 204 Pb = 15.7). However, the corrected ratios for this sample are in the range of the other sulphides. For molybdenite (Mo4, Mo7, Mo8; 238 U/ 204 Pb = 0.1, 5.9 and 11.4 respectively) corrected values remain more radiogenic than the other sulphides.

Re-Os isotopic composition

M A N U S C R I P T A C C E P T E D ACCEPTED MANUSCRIPT 9
The Re-Os analyses were performed on 3 samples of molybdenites. Samples were prepared in BRGM (Orléans, France), with the chemical and mass spectrometry protocols performed at Durham University (UK) in the Laboratory for sulphide and source rock geochronology and geochemistry and the Arthur Holmes Laboratory, members of the Durham Geochemistry Centre. Molybdenite separates of the 125 -250 µm fraction were obtained by traditional methods (crushing, heavy liquids, magnetic separator and handpicking under a microscope to remove impurities).

The procedure for the Re-Os analyses is described in detail in Selby and Creaser (2001a, b).

The Carius tube method [START_REF] Shirey | Carius tube digestion for low-blank rhenium-osmium analysis[END_REF] was used for dissolution of the molybdenite and equilibration with the tracer solution ( 185 Re + normal Os). Osmium was separated and purified by CHCl 3 solvent extraction and micro-distillation. The rhenium was separated and purified using NaOH-acetone solvent extraction and anion chromatography.

The purified Re and Os fractions were loaded onto Ni and Pt wire filaments, respectively, and analysed for their isotope composition by negative thermal ionisation mass spectrometry (NTIMS) of a Triton Scientific mass spectrometer. Molybdenites have naturally high Re content and no initial Os [START_REF] Morgan | Rhenium and non-radiogenic osmium in Australian molybdenites and other sulphide minerals by neutron activation analysis[END_REF][START_REF] Markey | Highly precise Re-Os dating for molybdenite using alkaline fusion and NTIMS[END_REF], all the 187 Os is derived from the decay of 187 Re [START_REF] Faure | Principles of isotope geology[END_REF]. Model Re-Os ages were calculated using the equation ln( 187 Os/ 187 Re + 1)/λ, using the decay constant (λ) of 1.666e -11 a -1 [START_REF] Smoliar | Re-Os ages of group IIA, IIIA, IVA, and IVB iron meteorites[END_REF].

Uncertainties include all sources of analytical uncertainty (Re and Os mass spectrometer measurements, blank abundances and isotopic compositions (Re = 3.2 ppt; Os = 0.3 ppt;

187 Os/ 188 Os = 0.223 ± 0.03, n=1), spike calibrations and reproducibility of standard Re and Os isotopic values), and with and without the uncertainty in the decay constant (0.35 %; [START_REF] Smoliar | Re-Os ages of group IIA, IIIA, IVA, and IVB iron meteorites[END_REF]Selby et al., 2007).

Re-Os

The results of Re-Os analyses on molybdenites are given in Table 1. The Re and 187 Os concentration for Tizgui MoS 2 are respectively 14.00 ± 0.05 ppm and 39.35 ± 0.13 ppb. The Re concentration for the two Azegour MoS 2 is 7.00 ± 0.03 ppm and 2.87 ± 0.01 ppb and the 187 Os concentration is 20.31 ± 0.07 ppb and 8.33 ± 0.02 ppb.

Table 1: Re-Os data and model dates for molybdenites analyzed in this study.

The Re-Os model age for the Tizgui mine sample is 267.79 ± 1.45 Ma, whereas the Re-Os ages for the Azegour mine are almost 10 Ma older (276.56 ± 1.51 Ma and 276.84 ± 1.49 Ma; Table 1).

Molybdenum

The molybdenite from Azegour skarn display δ 98 Mo NIST values that range between -0.60 ‰ and +0.42 ‰ (Fig. 6 and Table 2) resulting in a variation of ∆ 98 Mo= 1.02 ‰. Such a variation at the scale of a deposit is coherent with the variations for other occurrences or deposits shown by previous studies. For example, [START_REF] Mathur | Variation of Mo isotopes from molybdenite in high-temperature hydrothermal ore deposits[END_REF] 2). The variation within individual samples from -0.17±0.11 ‰ to 0.42±0.13 ‰ (Mo076, Table 2), giving a ∆ 98 Mo of around 0.59 ‰, is similar to the whole variation measured in the Tizgui mine and not significantly different to variations measured in this study. [START_REF] Greber | Mo isotope composition in Mo-rich high-and low-T hydrothermal systems from the Swiss Alps[END_REF] and [START_REF] Shafiei | Mo isotope fractionation during hydrothermal evolution of porphyry Cu systems[END_REF] found evidence of multi-modality in the distribution of the δ 98 Mo NIST in molybdenites. On the contrary, in the Azegour skarn, the distribution of the data follows a Gaussian (normal) distribution, but nonetheless there is no clear evidence of multi-modality in the distribution of the δ 98 Mo NIST in the molybdenites as illustrated in the Figure 6. Given that the multi-modality is typically interpreted as representing different phases of crystallisation, the Gaussian (normal) distribution may

Sulphur

The molybdenites from the Azegour skarn have δ 34 S vCDT values ranging between 12.4 and 14.7 ‰ and the molybdenite samples collected in the Tizgui mine exhibit nominally lower values (12.4 ‰, n=2) than those of the Azegour mine (12.7-14.7 ‰, n=27) (Table 3 and Fig. 7).

The δ 34 S vCDT values of chalcopyrite range between 10.5 and 12.5 ‰ (n=5). The δ 34 S vCDT for the pyrrhotites from Tizgui mine are 8.0 and 8.3 ‰ (n=2), with the pyrrhotites from Azegour mine possessing values of 12.2 and 14.2 ‰. [START_REF] Mrini | Age et origine des granitoïdes hercyniens du Maroc; Apport de la géochronologie et de la géochimie isotopique (Sr, Nd, Pb)[END_REF], with the [START_REF] Stacey | Approximation of Terrestrial Lead Isotope Evolution by a 2-Stage Model[END_REF]

Figure 7: Histogram of δ 34 S vCDT isotopic composition of molybdenite, chalcopyrite and pyrrhotite samples Table 3: Sulphur isotope data of molybdenites, chalcopyrites and pyrrhotites analyzed in this study.

Lead

M A N U S C R I P T A C C E P T E D

growth curve (SK) and

Doe-Zartman (1979) orogen curve. The measured ratios have been corrected for the addition of radiogenic Pb, assuming an age of 270 Ma. Molybdenite corrected ratios are too radiogenic and do not appear on this figure. Lead isotopic composition of neighbouring ore deposits are mentioned for comparison: galena from Amensif ore deposit (Ilmen et al., 2014) and from Draa Sfar and Hajar huge VMS (Marcoux et al., 2008). Table 4: Lead isotope data of molybdenite, chalcopyrite, pyrrhotite and K-feldspar analyzed in this study. Measured values have been corrected to an age of 270 Ma.

Discussion

Re-Os dating of the molybdenites

The results are consistent with the age of the granite crystallisation dated at 269 ± 11 Ma (Rb-Sr, [START_REF] Charlot | Rapport technique et quelques résultats[END_REF] and 271 ± 3 Ma (Rb-Sr, [START_REF] Mrini | Age et origine des granitoïdes hercyniens du Maroc; Apport de la géochronologie et de la géochimie isotopique (Sr, Nd, Pb)[END_REF]. Therefore, we conclude that the Mo mineralisation is contemporaneous with crystallisation of the Azegour granite.

However, a difference of a few million years can be observed between the molybdenite sample from Tizgui (youngest) and samples from Azegour (oldest). Molybdenite records the timing of mineralisation and by inference the age of the associated granite suggesting in this

M A N U S C R I P T A C C E P T E D ACCEPTED MANUSCRIPT
14 case a multi-phased granitic intrusion. Such a magmatic-hydrothermal multi-phased history is very common in porphyry and related-skarn ore deposits [START_REF] Sillitoe | Porphyry copper systems[END_REF] as well as in major skarn deposits like Los Santos, Spain [START_REF] Timon-Sanchez | Mineralogical and physiochemical evolution of the Los Santos scheelite skarn, Salamanca, NW Spain[END_REF] and Salau, France (Poitrenaud et al., in press) where two successive intrusions emplaced at 269 ± 6 and 280 ± 6 Ma (K/Ar dates), and 289.1 ± 1.9 Ma and 295 ± 2 Ma (LA-ICP-MS-U-Pb dates) respectively. At Azegour we assume that the intrusion could also be multiple phased but of similar lithology or, more likely, the presence of a younger intrusion at depth that gave way to the Tizgui mineralization.

Possible causes of Molybdenum isotopic composition variations

Four processes are described in the literature to explain these variations at deposit scale and even at sample scale. First, [START_REF] Klemm | Fluid and source magma evolution of the Questa porphyry Mo deposit, New Mexico, USA[END_REF] suggested that the fractionation of the Mo isotopes is due to the different stages of mineralisation, a progressive enrichment in heavy Mo isotopes in the residual melt of subvolcanic magma chamber being the cause of the variation in the Mo isotopes. The second process was described by [START_REF] Greber | Magmatic-hydrothermal molybdenum isotope fractionation and its relevance to the igneous crustal signature[END_REF], which argued for a fractionation of the Mo isotopes at the magmatic-hydrothermal transition. A third process was first described by [START_REF] Hannah | Molybdenum isotope variations in molybdenite: Vapor transport and Rayleigh fractionation of Mo[END_REF] and later by [START_REF] Klemm | Fluid and source magma evolution of the Questa porphyry Mo deposit, New Mexico, USA[END_REF], who suggested that fractionation that occurs during the same stage of mineralisation, but also within an individual hand specimen, is due to a Rayleigh fractionation of a hydrothermal fluid and a fractionation due to fluid phase separation (brine and vapour). We recall that Rayleigh fractionation describes the evolution of a multi-phased system, an hydrothermal system in this study, in which one phase is continuously removed from the system through fractional distillation. This fractional distillation is one of the most common cause of isotopic fractionation. Finally the last process was evoked by Shafiei et al.

M A N U S C R I P T A C C E P T E D ACCEPTED MANUSCRIPT

15 (2015). They suggested that the fractionation of the Mo isotopes could be controlled by the molybdenite structures (2H or 3R polytypes). When considering the whole variation of the Mo isotopes observed in our data set, the variation within individual hand samples, the lack of evidence of different values between the two sampling sites in Azegour and the two different facies, we argue that the principal process of Mo fractionation in the Azegour skarn is the succession of two phases of crystallisation evidenced by Re-Os molybdenite ages, without precluding a probable influence of Rayleigh fractionation in the hydrothermal fluid.

Source of ore-forming fluids: Sulphur isotopic composition

The high values observed mostly within molybdenite for the Azegour skarn require a contribution from a 34 S-enriched sulphur source. Magmatic sulphides in uncontaminated felsic magmas generally have a signature value of 0 ± 3 ‰ (Ohmoto, 1972;Hoef, 1997), in agreement with [START_REF] Liu | Fluid inclusions and H-O-S-Pb isotope systematics of the Chalukou giant porphyry Mo deposit, Heilongjiang Province, China[END_REF] that suggested that δ 34 S of between 2 and 4 ‰ indicate a magmatic sulphur source. Values for Cu-porphyry deposits are mostly between -5 ‰ and +5 ‰, with carbonate-hosted Pb-Zn ore deposits values from -20 ‰ and +20 ‰. Most skarns have δ 34 S values between -5 ‰ and +5 ‰ (e.g. [START_REF] Ault | Sulfur and lead isotope study of the EL Mochito Zn-Pb-Ag deposit[END_REF]) indicating a magmatic source for sulphur.

The high δ 34 S values measured in Azegour fall outside the field values indicating a predominantly magmatic origin of sulphur in skarn deposits. The Azegour skarn is not the only skarn with high values of δ 34 S. [START_REF] Ishihara | Source diversity of ore sulfur from Mesozoic-Cenozoic mineral deposits in the Korean Peninsula region[END_REF][START_REF] Ishihara | Possible carbonate origin of ore sulfur from Geumseong Mo deposit, South Koera[END_REF] observed a range from 11.1 ‰ to 14.8 ‰ for Geumseong molybdenum skarn deposits (Korea) and suggest that extraction and migration of sulphur of the host carbonates into the skarn mineralization. Rose et al. (1985) reported values from 6.3 to 19.9 ‰ for the Cornwall skarn (Pennsylvania, USA). These high values of δ 34 S are well explained by a sedimentary source of sulphur and, in

M A N U S C R I P T A C C E P T E D ACCEPTED MANUSCRIPT
16 some cases, a marine sedimentary source or evaporites with high δ 34 S of sulphur cannot be precluded (e.g., [START_REF] Faure | Mineralogical and stable isotope studies of gold-arsenic mineralisation in the Sams Creek peralkaline porphyritic granite, South Island, New Zealand[END_REF]. The Azegour skarn occurs in carbonate series with black shales from the lower Cambrian [START_REF] Neltner | Assessment of the 187 Re decay constant by cross calibration of Re-Os molybdenite and U-Pb zircon chronometers in magmatic ore systems[END_REF], which usually possess a δ 34 S > 20 ‰ [START_REF] Jébrak | Geology of Mineral Resources[END_REF], and are thus likely the dominant source of sulphur for the skarn, but, given to the δ 34 S values, a complementary source of sulphur, probably magmatic, is also required.

Source of ore-forming fluids: Lead isotopic composition

These high values indicate the influence of a more radiogenic component in their genesis.

Uranium is very scarce and disseminated as tiny uraninite crystals, but Permingeat (1957) noted that, at the mine scale, uranium is preferentially associated with molybdenite but none uraninite inclusion has been observed in molybdenite. However, as initial lead isotopic compositions calculated for molybdenite are still more radiogenic than for other sulphides, explanations could be that Pb from molybdenite is sources in the more radiogenic host rocks, while Pb from other sulphides is sourced in the magmatic intrusion, what is supported by sulphur isotopic results. [START_REF] Ilmen | Mineralogical and geochemical characteristics of the Amensif Cu, Pb, Zn, (Ag, Au) ore deposit, Western High Atlas, Morocco[END_REF] have performed Pb isotopic analyses on a galena from the Amensif deposit, which is located 5 km in the south of Azegour skarn and is spatially associated with the Azegour granite. The 206 Pb/ 204 Pb isotopic values of galena (18.05, Fig. 8), close to initial isotopic values measured on Azegour sulphides, suggest that the Pb was sourced from the Lower Paleozoic volcano-sedimentary units [START_REF] Ilmen | Mineralogical and geochemical characteristics of the Amensif Cu, Pb, Zn, (Ag, Au) ore deposit, Western High Atlas, Morocco[END_REF].

Our data (molybdenite not included) define a narrower range with a mean 206 Pb/ 204 Pb value at 18.18 ± 0.07 (σ). The initial 206 Pb/ 204 Pb value of the skarn is around 18.08 -18.30. Feldspar sample from the Azegour granite having a 206 Pb/ 204 Pb value of 18.20,

M A N U S C R I P T A C C E P T E D ACCEPTED MANUSCRIPT

suggests that the granite cannot be considered as a major source for lead in the skarn, although its role as an accessory source cannot be discarded.

6.

Summary of the origin of the ore-forming elements in Azegour

The Re-Os analyses of molybdenite (~267 and 276 Ma) provide a robust geochronology for the mineralisation of the Azegour skarn, which are broadly contemporaneous with the previous emplacement history of the granite (Rb-Sr ages determined on the granite ranging from 269 ± 11 to 271 ± 3 Ma). Although presently there is no evidence of multi-staged emplacement of the Azegour granite, the Re-Os molybdenite dates do imply two phases of mineralisation within the Azegour system, and thus the presence of a hidden younger intrusion at depth. Multi-phased crystallisation is proposed as the principal process of Mo fractionation in the Azegour skarn and could explain Mo isotopic variation in occurrence and sample scale, whereas a Rayleigh fractionation in hydrothermal fluid cannot be precluded.

The 34 S-enrichment of the sulphide ores of the Azegour skarn suggests a strong participation of surrounding rocks. Regarding lead isotopes, the location of all Azegour samples below the [START_REF] Stacey | Approximation of Terrestrial Lead Isotope Evolution by a 2-Stage Model[END_REF] and just below [START_REF] Doe | Plumbotectonics, the Phanerozoic[END_REF] orogen curves suggest that the ore forming materials are derived from a mixture of upper crustal material with an important contribution of mantle lead, a result in accordance with the previous Sr and Nd isotopic studies [START_REF] Mrini | Age et origine des granitoïdes hercyniens du Maroc; Apport de la géochronologie et de la géochimie isotopique (Sr, Nd, Pb)[END_REF].

Figure 4 :

 4 Figure 4: Coarse molybdenite (white and grey) within garnetite from the Azegour mine.Photograph in reflected light

  found a ∆ 98 Mo of around 0.75 ‰ for El Teniente ore deposit in Chile. A slightly larger variation was shown by Greber et al. (2011) for the Grimsel Pass pegmatite (∆ 98 Mo of ~1.14 ‰) and for the Alpjahorn pegmatite ∆ 98 Mo of ~1.35 ‰). Greber et al. (2014) found a ∆ 98 Mo= 0.88 ‰ in the Questa porphyry Mo ore deposit (New Mexico, USA). Additionally, Shafiei et al. (2015) reported the largest variation (∆ 98 Mo of around 1.94 ‰) for the Kerman porphyry deposit (Iran).

Figure 6 :

 6 Figure 6: Histogram of Mo isotopic composition of molybdenite samples from Azegour mine and Tizgui mine

  one phase of crystallisation has occurred, what is clearly not the case in the Azegour skarn. Table 2: Mo-isotope data of molybdenites analyzed for this study. Data are relative to NIST3134 (δ 98 Mo NIST =0). N = number of analyses for each sample. Long-term external reproducibility of 0.08 ‰ (2σ) on δ 98 Mo NIST . References to sub samples are indicated by an additional subscript a to d, meaning up to 4 subsamples, i.e. same rock sample referred MoXXX and up to 4 samples of molybdenite grain in the samples MoXXX.

Figure 8 :

 8 Figure 8: Pb-Pb diagrams of initial composition of chalcopyrite, pyrrhotite, and K-feldsparfrom Azegour granite[START_REF] Mrini | Age et origine des granitoïdes hercyniens du Maroc; Apport de la géochronologie et de la géochimie isotopique (Sr, Nd, Pb)[END_REF], with the[START_REF] Stacey | Approximation of Terrestrial Lead Isotope Evolution by a 2-Stage Model[END_REF] growth curve (SK) and

  Initial lead isotopic compositions ( 206 Pb/ 204 Pb, 207 Pb/ 204 Pb and 208 Pb/ 204 Pb) calculated using a mean age of 270 ± 10 Ma are reported in Table 4 and Figure 8. The range of the initial lead isotope composition can be illustrated by the 206 Pb/ 204 Pb i value, ranging for chalcopyrite, pyrrhotite and feldspar samples from 18.08 to 18.30. Chalcopyrite 206 Pb/ 204 Pb i values are close (18.13 to 18.23), whereas pyrrhotite 206 Pb/ 204 Pb i values exhibit a wider range from 18.08 to 18.30. The 206 Pb/ 204 Pb i values for molybdenite are more radiogenic, between 18.51 and 20.01.

	ACCEPTED MANUSCRIPT
	13

Acknowledgments

This work is part of Noémie Breillat PhD research supported by the Region Centre and the Carnot-BRGM Institute. We thank Anne-Marie Desaulty, Anne-Marie Gallas, Anne-Thérèse Montech, Alexandre Vrain, Antonia Hoffman, Chris Ottley and Geoff Nowell for their support during laboratory work Rebecca Neely is thanked for her constructive remarks.


Zeinab Abou Khalil

Eleni Constantinou

Tom Mens
email: tom.mens@umons.ac.belaurence.duchien

Laurence Duchien

Clément Quinton
email: clement.quinton@univ-lille.fr

A Longitudinal Analysis of Bug Handling Across Eclipse Releases

Large open source software projects, like Eclipse, follow a continuous software development process, with a regular release cycle. During each release, new bugs are reported, triaged and resolved. Previous studies have focused on various aspects of bug fixing, such as bug triaging, bug prediction, and bug process analysis. Most studies, however, do not distinguish between what happens before and after each scheduled release. We are also unaware of studies that compare bug fixing activities across different project releases. This paper presents an empirical analysis of the bug handling process of Eclipse over a 15-year period, considering 138K bug reports from Bugzilla, including 16 annual Eclipse releases and two quarterly releases in 2018. We compare the bug resolution rate, the fixing rate, the bug triaging time and the fixing time before and after each release date, and we study the possible impact of "release pressure". Among others, our results reveal that Eclipse bug handling activity is improving over time, with an important decrease in the number of reported bugs before releases, an increase in the bug fixing rate and an increasingly balanced bug handling workload before and after releases. The recent transition from an annual to a quarterly release cycle continued to improve the bug handling process.

I. Introduction

In continuous software engineering, every major software release provides a significant amount of new or modified functionality compared to the previous release. Developers strive to resolve as many bugs as possible in current and upcoming releases. Unfortunately, not all bugs can be resolved and fixed before the release deadline. In order to address the most important bugs for each release, a bug handling process is followed, relying on dedicated collaborative bug tracking tools such as Bugzilla. Researchers have investigated different factors in the bug handling process that may affect bug triaging and fixing time, and provided models for predicting and estimating this time [START_REF] Saha | Understanding the triaging and fixing processes of long lived bugs[END_REF]- [START_REF] Zhang | Predicting bug-fixing time: an empirical study of commercial software projects[END_REF]. They also studied techniques to improve the process of bug fixing [START_REF] Bhattacharya | An empirical analysis of bug reports and bug fixing in open source Android apps[END_REF], [START_REF] Gupta | Improving software maintenance using process mining and predictive analytics[END_REF], bug triaging [START_REF] Jeong | Improving bug triage with bug tossing graphs[END_REF]- [START_REF] Xuan | Automatic bug triage using semi-supervised text classification[END_REF], or assigning developers to bug reports [START_REF] Anvik | Automating bug report assignment[END_REF]- [START_REF] Xia | Dual analysis for recommending developers to resolve bugs[END_REF]. The research community has investigated several aspects of pre-and post-release bugs. The number and rate of resolved and fixed bugs are important indicators of software quality [START_REF] Spinellis | Evaluating the quality of open source software[END_REF]. Rapid release policies might affect bug handling quality, since releases are delivered more often, and the community may have less time to address unresolved bugs. Khomh et al. [START_REF] Khomh | Do faster releases improve software quality? An empirical case study of Mozilla Firefox[END_REF], [START_REF] Khomh | Understanding the impact of rapid releases on software quality[END_REF] analyzed Mozilla Firefox to study the effect of switching to a rapid release cycle on the speed and proportion of bugs being fixed. Interviews with Mozilla developers revealed that the success of such a new release policy on bug handling depends on the prior preparation to adapt to this policy [START_REF] Khomh | Understanding the impact of rapid releases on software quality[END_REF]. In the second half of 2018, Eclipse has also transitioned from an annual to a quarterly (13-week) release cycle. It therefore becomes relevant to investigate how this change has affected Eclipse's recent bug handling activity. In this paper, we study the bug history of 18 major releases of the Eclipse core projects over a 15-year lifetime. In particular, we investigate: 1) how the bug handling time differs before and after an upcoming scheduled release; and 2) if and how the switch to a quarterly release cycle affects the bug handling process. To do so, we rely on four measurements to quantify bug handling: triaging and fixing time, and resolution and fixing rate. Our investigation is guided by four research questions: RQ 0 : How does the number of bugs differ before and after each release? This exploratory question provides an initial understanding of the magnitude of bug-related activity for each Eclipse release in the period before the release is scheduled and the period afterwards. RQ 1 : How do the bug resolution and fixing rates evolve over releases, and how do they differ before and after each release? We intuitively expect that Eclipse maintainers handle bugs more intensively in the period before than after the upcoming release date, as they strive to resolve and fix as many bugs as possible in the upcoming release. Moreover, to assess the bug handling process improvement over time, we study the bug resolution and fixing rates and check whether or not they are increasing across releases. RQ 2 : How do the bug triaging and fixing time differ before and after each release? We assume that intense bug handling activity before an upcoming release leads to faster bug triaging and fixing times than after the release. We thus investigate the differences between the two time periods in terms of days elapsed to triage and fix bugs. RQ 3 : How do the bug triaging and fixing time change when approaching a release deadline? Based on 40 interviews, Murphy-Hill et al. [START_REF] Murphy-Hill | The design of bug fixes[END_REF] observed that developers become more conservative in their changes to avoid the risk of introducing new bugs, and focus more on bug fixing activities as the release deadline approaches. Similarly, we assume that for Eclipse, bugs are triaged and fixed faster closer to a release deadline, due to the increased pressure to resolve as many bugs as possible for the upcoming release. We also assume that in the light of an upcoming release, the triaging and fixing time of bugs of the current release will increase, since developers may prefer to focus on bugs of the upcoming release rather than on the ones of the current, already published, release. To this end, we empirically compare the differences in bug triaging and fixing time of the current and upcoming release in function of the upcoming release deadline. The research questions are analyzed for three ranges of Eclipse releases: 1) the 3.x release series; 2) all 4.x releases following an annual release cycle; and 3) all 4.x releases following a quarterly release cycle. We report and discuss the findings for each release range so as to identify the changes in the bug handling process throughout Eclipse's history, as well as the effect of switching from an annual to a quarterly release cycle.

II. Related Work

A. Bug fixing in short release cycles Khomh et al. [START_REF] Khomh | Do faster releases improve software quality? An empirical case study of Mozilla Firefox[END_REF] empirically studied the effect of rapid releases on software quality for Mozilla Firefox. They quantified quality in terms of runtime failures, presence of bugs and outdatedness of used releases. Related to our work, they compared the number of reported, fixed and unconfirmed bugs and the fixing time during both the testing period, i.e., the time between the first alpha version and the release, and the post-release period. They showed that less bugs are fixed during the testing period and that bugs are fixed faster under a rapid release model. In a follow-up work [START_REF] Khomh | Understanding the impact of rapid releases on software quality[END_REF], the authors reported that, although post-release bugs are fixed faster in a shorter release cycle, a smaller proportion of bugs are fixed compared to the traditional release model. Interviews conducted with six Mozilla employees revealed that they can be "less effective at triaging bugs with rapid release" and that more beta testers using the rapid releases can generate more bugs. Da Costa et al. [START_REF] Da Costa | The impact of switching to a rapid release cycle on the integration delay of addressed issues -An empirical study of the Mozilla Firefox project[END_REF] studied the impact of Mozilla's rapid release cycles on the integration delay of addressed issues. They showed that compared to the traditional release model, the rapid release model does not integrate addressed issues more quickly into consumer-visible releases. They also found that the issues are triaged and fixed faster in rapid releases. They extended their work in [START_REF] Da Costa | The impact of rapid release cycles on the integration delay of fixed issues[END_REF] where they reported that issue triaging time is not significantly different among the traditional and rapid releases.

B. Bug triaging

Saha et al. [START_REF] Saha | Understanding the triaging and fixing processes of long lived bugs[END_REF] extracted code change metrics, such as the number of changed files, to identify the reasons for delays in bug fixes and to improve the overall bug fixing process in four Eclipse projects: JDT, CDT, Plug-in Development Environment (PDE), and Platform. Their results showed that a significant number of long-lived bugs could be reduced through careful triaging and prioritization if developers would be able to predict their severity, change effort and change impact in advance. Zhang et al. [START_REF] Zhang | An empirical study on factors impacting bug fixing time[END_REF] studied factors affecting delays incurred by developers in bug fixing time. They analyzed three Eclipse projects: Mylyn, Platform and PDE. They found that metrics such as severity, operating system, description of the issue and comments are likely to impact the delay in starting to address and resolve the issue. Hooimeijer and Weimer [START_REF] Hooimeijer | Modeling bug report quality[END_REF] presented the correlation between bug triaging time and the reputation of a bug reporter. They designed a model that uses bug report fields, such as bug severity and submitter's reputation, to predict whether a bug report will be triaged within a given amount of time in the Mozilla Firefox project.

C. Bug fixing time prediction and estimation

Panjer [START_REF] Panjer | Predicting Eclipse bug lifetimes[END_REF] carried out a case study on Eclipse projects, and showed that the most influential factors affecting bug fixing time are found in initial bug properties (e.g., severity, product, component, and version), and post submission information (e.g., comments). Giger et al. [START_REF] Giger | Predicting the fix time of bugs[END_REF] found that the assigned developer, bug reporter and month when the bug was reported have the strongest influence on the bug fixing time in Eclipse, Mozilla, and Gnome. Marks et al. [START_REF] Marks | Studying the fix-time for bugs in large open source projects[END_REF] studied different features of a bug report in relation to bug fixing time using bug repository data from Mozilla and Eclipse. The most influential factors on bug fixing time were bug location and bug reporting time. Zou et al. [START_REF] Zou | An empirical study of bug fixing rate[END_REF] investigated the characteristics of bug fixing rate and studied the impact of a reporter's different contribution behaviors to the bug fixing rate in Eclipse and Mozilla. Among others, they observed an increase in fixing rate over the years for both projects. On the other hand the observed rates were not high, especially for Mozilla. All these studies are valuable in understanding the overall bug fixing process, factors affecting bug fixing time, bug fixing time estimation and triaging automation. In our work, we focus on the bug triaging and fixing time, and on bug resolution and fixing rate. We are not aware of any study comparing these metrics before and after the release is delivered, and how they evolve over successive releases.

III. Experimental Setup

This section presents our experimental design, the selected case study, the data extraction process and the metrics that will be used to answer the research questions. The datasets and scripts generated for the current study are publicly available in a replication package [START_REF] Khalil | A longitudinal analysis of bug handling across eclipse releases[END_REF].

A. Selected Case Study

We selected Eclipse as a case study because it: 1) is a large and mature project that has had a sufficiently long release history with associated bug reporting activity 2) has been widely studied in previous software evolution research [START_REF] Mens | The evolution of Eclipse[END_REF], [START_REF] Businge | Survival of Eclipse third-party plug-ins[END_REF] and in research about bug fixing in particular [START_REF] Panjer | Predicting Eclipse bug lifetimes[END_REF], [START_REF] Kumar | Evolution of developer social network and its impact on bug fixing process[END_REF]; and 3) is a popular open source project that has a stable development community and a regular release process. Eclipse relies on the Bugzilla bug tracking platform [START_REF]Eclipse bugzilla repository[END_REF] to manage and keep track of its bugs, allowing developers to effectively manage all concerns of the bug life cycle. The Eclipse community separates its development between the core Eclipse projects and its plugins. We focus only on bugs related to the core of Eclipse, as the bug handling activity for plugins can be affected by the absence of factors such as continuous bug monitoring and continuity of the plugin development. The core of Eclipse is composed of the projects Platform, JDT, e4, Incubator, Equinox and PDE [START_REF]Eclipse[END_REF]. e4 is an incubator for community exploration of future technologies of Eclipse and uses a different versioning scheme than the other projects; we therefore excluded it from our analysis. Since our focus is on the relation between bug reports and the official Eclipse releases, we also excluded Incubator because the few (49) bugs reported for this project do not provide a version of the Eclipse release, i.e., all bugs provide an unspecified version. Our analysis of Eclipse starts from version 3.0, which is the first release coordinated and shipped by the independent Eclipse Foundation; previous releases were coordinated and controlled by IBM. Since release 3.0 in June 2004 until release 4.8 in June 2018, Eclipse followed an annual "simultaneous release" scheme 1 where a new release was delivered every year in June. In June 2012, Eclipse switched from the 3.x series to the 4.x series, highlighted by a "dual" release of 3.8 and 4.2 that were maintained in parallel 2 . Each annual release since 3.3 until 4.5 was followed by two "service releases" in September and February, respectively. Releases 4.6 and 4.7 had three "update releases" in September, December and March. Since release 4.9, Eclipse has switched to a new quarterly release policy (i.e., every 13 weeks) without intermediate update releases.

B. Bug Tracker Data

Our empirical analysis is based on bug report data extracted from Bugzilla for each Eclipse release. A typical bug report contains a variety of fields, such as the description, product, component, status, reporter, fixer, severity, version, target milestone, and operating system. Each bug report is accompanied by a history containing all events that occurred during the bug's life cycle (e.g., bug reporter and creation time, change of resolution and status field of a bug, assigned developer, etc.). All these aspects play a role in the bug handling process.

Using the Disco process mining tool [START_REF]Disco process mining tool[END_REF] we extracted the bug handling process based on the 138,445 bug reports in our dataset; the process to acquire this dataset is explained in detail in Section III-C. The results are shown in Fig. 1. Typically, a bug gets introduced as NEW and then either becomes CLOSED (5.5%) or ASSIGNED to a developer who becomes responsible for its resolution (36.9%).

It is important to note that many bugs get RESOLVED without ever being ASSIGNED (54.3%). The resolution status of a RESOLVED bug may contain different possible values. In the majority of the cases (55.3%), the status will be FIXED (i.e., the bug has been resolved by fixing it). However, many bugs get resolved by marking them as DUPLICATE (18.6% of the cases) or as WORKSFORME (implying that the bug cannot be reproduced by the assignee, corresponding to 10.1% of the cases). Other resolution statuses are INVALID (7.4%), WONTFIX (7.2%), NOT ECLIPSE (1.4%) and MOVED (0.01%). Less than 1 out of 3 bug reports ever reach the VERIFIED state after they have been RESOLVED (28%). Hence, one should not rely on this state to carry out empirical analyses about bug handling.

C. Data Processing

To extract the Eclipse bug reports and the respective bug histories we used the Bugzilla API3 . Since we focus on the core of Eclipse, we only considered bug reports for which the product field was tagged as Platform, JDT, Equinox or PDE. We initially extracted 205,031 bugs for these projects and excluded 27,799 bugs that were marked as enhancement in the severity field, since feature enhancements are considered to be new functionality requests rather than bugs [START_REF] Saha | Are these bugs really "normal"?[END_REF].

In [START_REF] Tu | Be careful of when: an empirical study on time-related misuse of issue tracking data[END_REF]. The misuse of issue tracking data may threaten the validity of findings because the values of issue fields (severity, priority, component, version, etc.) often change over time. They recommend researchers that rely on such data to have a full understanding of their application scenarios, the origin and change of the data, and the influential issue fields to manage data leakage risks.

In the context of our work, we examined the threats related to the bug report fields version, resolved, fixed, and assignee. The version field is used to indicate the version(s) affected by the bug report and usually contains the numbers or names of the releases. Examining the bugs that changed the version field during the bug fixing cycle, we found 4,063 bugs that were reaffected to different releases throughout their history, out of which 3,621 bugs that were reaffected to different major releases. We handle such bugs by considering them only for the last major release they affected as including the same bugs in multiple releases would bias the results for our pre-release analyses. From these bugs, only 98 (out of 109,367 resolved bugs) are resolved in multiple major Eclipse releases, thus the impact on our analyses is minimal.

A reported bug is marked as resolved and the resolution date is tracked by locating in the bug history a modification of the status field to the value RESOLVED. Similarly, a resolved bug is marked as fixed and the fixing date is tracked by locating the presence of the last FIXED status in the bug history. If the resolved status is modified multiple times, the last date that the bug was marked as RESOLVED will be registered. We opt for this strategy as the presence of multiple resolutions of the same bug implies that resolutions prior to the last one were not satisfactory. A reported bug is marked as assigned and the assignment date is tracked by checking for the presence of the ASSIGNED value in the status field of the bug history.

In case of multiple reassignments, we rely on the first recorded assignment date, reflecting the moment when the bug was triaged for the first time. The Eclipse community has also been assigning bugs using an alternative process since 20094 : it is possible to use an "assigned to" task without using the status field. This assignment method always assigns bugs to an email address in the form [component name]-triaged@eclipse.org. We identified and marked as assigned 4,811 bugs corresponding to this case.

D. Proposed Bug Handling Metrics

We introduce the notation B report to refer to the set of all reported bugs that we considered for our analysis.

Similarly, B assign refers to the subset of all assigned bugs, B resolve to all resolved bugs, and B fix to all fixed bugs. A superscript notation allows to restrain these sets to bugs targeting a specific release. For example, B 4.7 resolve contains all resolved bugs for which the version field refers to 4.7.

Since our empirical analysis aims to relate bug handling activity to release dates, we need to compare the dates corresponding to specific activities against these release dates. To do so, we define the following functions:

• D report : B report →
∀b ∈ B assign : T triage (b) = D assign (b) -D report (b) ∀b ∈ B fix : T fix (b) = D fix (b) -D report (b) Let d =]d 1 , d 2 ]
be a date range. We define bug resolution rate ResRate as the proportion of reported bugs that have been resolved in the considered date range. We also define two different fixing rate metrics. FixRate report , taken from [START_REF] Khomh | Understanding the impact of rapid releases on software quality[END_REF], computes the ratio of fixed over reported bugs. It relies on an implicit assumption that all reported bugs will eventually reach the RESOLVED status at some point in their lifecycle. This is not always the case based on our process mining results (Fig. 1) and the observations of [START_REF] Luijten | Assessment of issue handling efficiency[END_REF]: many bugs are CLOSED without ever reaching RESOLVED status. We therefore define a variant metric FixRate resolve as the ratio of fixed over resolved bugs:

ResRate(d) = |B resolve (d)| |Breport(d)| FixRatereport(d) = |B fix (d)| |Breport(d)| FixRate resolve (d) = |B fix (d)| |B resolve (d)| Example.
The following example illustrates these three metrics. Suppose 30 bugs are reported during date range d, of which 20 bugs are resolved and 12 of those resolved bugs are actually fixed. Then resolution rate is ResRate = 20 30 = 0.66, and fixing rates are FixRate report = 12 30 = 0.4 and FixRate resolve = 12 20 = 0.6.

E. Separation before and after Eclipse releases

Let R = {3.0, 3.1, 3.2, 3.3, 3.4, 3.5, 3.6, 3.7, 3.8/4.2, 4.3, 4.4, 4.5, 4.6, 4.7, 4.8, 4.9. 4.10} be the ordered set of considered Eclipse releases. We define the following functions:

• date: R → Date returns the date of a given release • prev: R/{3.0} → R returns its previous release • next: R/{4.10} → R returns its next release Given a release r ∈ R, we focus our analysis on only those bugs that target this release, based on the value of their version field in the bug report. We study the period before and after the release by restricting the date range to the dates between two successive releases. For example, by bugs reported after release r = 4.5 we mean all bugs targeting that release, and being created in the date range [date(4.5),date(4.6)[. Similarly, the period before release 4.5 considers the date range [date(4.4),date(4.5)[. We introduce a shorthand notation for the fixing and resolution rates before and after each release. For example, the resolution rates before and after a release r are defined as follows, restricting to only those bugs targeting r:

F. Preliminary Analysis

For each considered release, we computed the number of reported, resolved, fixed and assigned bugs targeting this release, without any restriction on the date range. Fig. 2 shows these statistics and reveals that the number of reported bugs targeting a given release (blue line) is monotonically decreasing all along the 3.x range of releases. Starting from release 3.8/4.2, the number of bug reports appears to become stable. For the quarterly releases starting from 4.9, the numbers decrease again. Fig. 3 shows the corresponding evolution of ResRate, FixRate report and FixRate resolve . We observe a decreasing resolution rate all along the Eclipse releases, while FixRate resolve is increasing and FixRate report tends to be stable across releases. For the 3.x release range, ResRate decreases from 0.96 to 0.64, while FixRate resolve increases from 0.50 to 0.76. Starting from release 3.6, FixRate resolve is consistently higher than ResRate. We assume that this change in behaviour has to do with the practice of "resolving" a bug by giving it the LATER or REMIND status in the resolution field, corresponding to the desire to postpone the bug resolution. 5 This practice was fairly common early on in the 3.x release range, but gradually declined and is no longer used since release 3.6 (red vertical line). By analyzing the delays of a follow-up resolution of the REMIND/LATER bugs (3479 bugs), we found that most of them lingered for more than 3 years before getting their final resolution. For the 4.x annual release range we observe a stability in the rates up until release 4.5, after which ResRate continues to decrease and FixRate resolve continues to increase. We assume that this change is caused by the introduction of an Automated Error Reporting Client (called AERI) 6 since June 2015 (yellow vertical line). Fig. 4 compares the number of bugs reported before and after each release: | B before report (r) | and | B after report (r) |. As for Fig. 2 we observe a monotonic decrease in number of reported bugs for the 3.x release range, with a ratio |B after report (r)| |B before report (r)| between 0.38 and 0.66. This ratio increases to the range from 0.75 to 1.07 for the 4.x release with the exception of release 4.8 and 4.10. The exception for 4.8 is possibly caused by the quarterly release policy starting at 4.9 and for 4.10 because it is newly released. 5 See https://www.eclipsezone.com/eclipse/forums/t83053.html 6 See https://www.eclipse.org/community/eclipse newsletter/ 2016/july/article3.php

IV. Results

This section reports quantitative evidence for the research questions. All statistical hypothesis tests use a significance level α = 0.05, rejecting the null hypothesis for p < 0.05. When computing the effect size we use Cliff's delta [START_REF] Cliff | Dominance statistics: Ordinal analyses to answer ordinal questions[END_REF], [START_REF] Hess | Robust confidence intervals for effect sizes: A comparative study of Cohen's d and Cliff's delta under non-normality and heterogeneous variances[END_REF], and interpret the results using [START_REF] Hess | Robust confidence intervals for effect sizes: A comparative study of Cohen's d and Cliff's delta under non-normality and heterogeneous variances[END_REF].

RQ 0 How does the number of bugs differ before and after each release? Fig. 5 shows, before and after each release, the monthly evolution (i.e., consecutive 30-day time periods) of the number of reported, assigned, resolved and fixed bugs, respectively, aggregated per release series as the sum of bugs. For the 3.x series, we generally observe an important increasing trend during the first eleven months before the release date, followed by a decreasing trend starting from one month before the upcoming release deadline (probably due to imminent deadline pressure) until the date of the next release. For the 4.x series, the results are similar, but much less pronounced. To test the difference between the number of bugs before and after the release we use a Wilcoxon rank sum test that replaces the Mann-Whitney U test when the observations are paired. The test makes no assumptions about the distributions, making it appropriate for our analyses since the values in our dataset are not normally distributed. The null hypothesis H 0 states that the distribution of the monthly number of bugs before the release is not different from the respective distribution after the release. H 0 could be rejected with large effect size for the populations of reported (p = 0.006, d = 0.61), assigned (p = 0.006, d = 0.61) and fixed (p = 0.011, d = 0.56) bugs, respectively, but only for the 3.x release series. For the population of resolved bugs for the 3.x release series we could not reject H 0 . For the 4.x series of annual and quarterly releases, we could not reject H 0 except for the number of reported bugs for the annual releases, but the effect size is medium. For Eclipse 3.x releases, more bugs are reported, assigned and fixed before the upcoming release than after the release, indicating that more effort is spent for handling bugs before the upcoming release. For Eclipse 4.x no difference is observed, suggesting an increasingly balanced bug handling workload before and after the release date.

RQ 1 How do the bug resolution and fixing rates evolve over releases, and how do they differ before and after each release?

First, we compute the resolution rate before and after each release date. Fig. 6a shows a decreasing trend of ResRate (y-axis) over the different releases (x-axis). A linear regression analysis confirms this trend for ResRate before (R 2 = 0.785) and ResRate after (R 2 = 0.863). Using a Wilcoxon rank sum test we verified the null hypothesis H0 1r that there is no statistical difference between the resolution rates before and after the release. We could not reject H0 1r (p = 0.85), i.e., the resolution rates before and after each release are similar. This is visually confirmed starting from release 3.5. The reason of decreasing resolution rates specifically after release 3.5 is that the Eclipse community has decided in 2007 to stop using the resolution statuses LATER and REMIND as they gave rise to bugs that remained unresolved for too long 7 . For the 4.x series, the resolution rates before and after fluctuate somewhere between 0.4 and 0.6. This signifies that around 1 out of 2 bugs do not get resolved.

The resolution rate tends to decrease over releases, but there is no significant difference in resolution rate before and after each release. One out of two bugs does not get resolved in the 4.x release range.

Next, we compute the fixing rates (FixRate report and FixRate resolve ) before and after each release date. Fig. 6b shows that the fixing rates before each release (horizontal red lines) are higher than the fixing rates after the release (blue lines). Using the Wilcoxon rank sum we test the null hypothesis H0 1f that there is no statistically significant difference between fixing rates before and after a release. H0 f 1 was rejected for FixRate report (p = 6 × 10 -5 ) with large effect size (d = 0.8). H0 f 1 was rejected for FixRate resolve (p = 0.02) with medium effect size (d = 0.47). This shows that the bug fixing rate before the release date is higher than after that date. It is interesting to note the difference in behaviour between FixRate report and FixRate resolve . Consistent with what we already saw in Fig. 3, FixRate report remains stable over time and FixRate resolve increases over time. A linear regression analysis confirms this positive trend for FixRate before resolve (R 2 = 0.816) and FixRate after resolve (R 2 = 0.899). As in Fig. 3 we observe that FixRate resolve is improving faster since release 4.5, probably because of the introduction and continued use of the AERI error reporting tool.

The fixing rate before a release is higher than after a release. The rate of fixed bugs over resolved bugs is increasing over time. The introduction of an automatic error reporting tool coincides with a further improvement of bug fixing rate.

RQ 2 How do the bug triaging and fixing time differ before and after each release?

For each release, we compute the bug triaging time T triage (b) for each assigned bug b before and after the release date. Triaging time before a release is computed for bugs targeting that release that are reported and assigned in the date range [date(prev(r)),date(r)[, while after the release we use the range [date(r),date(next(r))[. Similarly, we calculated the bug fixing time before and after each release for bugs targeting that release that are reported and fixed in the respective date ranges.

For both time measurements, we use the technique of survival analysis [START_REF] Aalen | Survival and event history analysis: a process point of view[END_REF] to model the expected time duration until the occurrence of an event of interest. In the triaging case, the event of interest is bug assignment and the duration to the event is computed from the creation date of the bug until the first assignment date. In the fixing case, the event of interest is a bug being fixed and the duration to this event is calculated from the creation date of the bug until the last fix date.

Triaging time results: Fig. 7 shows a selection of Kaplan-Meier survival curves for specific releases, together with their confidence intervals, before and after the release date. 8 We generally observe that triaging time before a release tends to be lower than triaging time after that release. We also observe that the difference between the survival curves tends to decrease over successive releases; for some releases, like 4.7, the difference is very low or absent. To statistically confirm the difference in triaging time before and after each release, we use a logrank test [START_REF] Bland | The logrank test[END_REF]. The null hypothesis H0 t 2 states that there is no difference between the triaging time survival distributions before and after a release. Table I reports for which releases H0 t 2 can be rejected. We can reject H0 t 2 for all releases except 3.4, 4.4, and from 4.7 till 4.10. Especially for the latest releases, including all quarterly releases, we cannot observe any statistically significant difference. Fixing time results: The survival curves for bug fixing time (not shown due to lack of space) reveal that for the 3.x release range and most of the annual 4.x releases, it takes less time to fix a bug before compared to after a release. With a statistical logrank test we verify hypothesis H0 f 2 that there is no difference between the fixing time survival distributions before and after a release. We cannot reject H0 f 2 for releases 4.3, 4.6, 4.8 and 4.9. The difference between 4.9 and 4.10 is explained by the shorter timespan of bugs in release 4.10 as it is the newest release in our dataset; this explains why bugs appear to be fixed faster for 4.10 after the release.

Eclipse 3.x Eclipse 4.x (annual) Eclipse 4.x (quarterly) rel. H0 t 2 H0 f 2 rel. H0 t 2 H0 f 2 rel. H0 t 2 H0 f 2 3.0 R R 3.8/4.2 R R 4.9 - - 3.1 R R 4.3 R - 4.10 - R 3.2 R R 4.4 - R 3.3 R R 4.5 R R 3.4 - R 4.6 R - 3.5 R R 4.7 - R 3.6 R R 4.8 - - 3.7 R R
Bugs tend to get triaged and fixed faster before a release than after it. The transition from an annual to a quarterly release policy appears to have been beneficial, since no statistical difference in triaging time can be observed before and after such releases.

RQ 3 How do the bug triaging and fixing time change when approaching a release deadline?

For each release, we compute triaging time T triage (b) for each bug b, by analyzing the population of reported bugs that were actually ASSIGNED in a particular date range. We compute bug fixing time T fix (b) in a similar way for FIXED bugs. We group our results in two date ranges based on when the assignment or fixing took place: 1) during the first 9 months after the current release (henceforth called early period) and 2) during the last 3 months before the next release (henceforth called pressure period). We consider the period of 9 months after the current release for quarterly releases because the development teams start early working on the releases following the next release.

Release 4.10 is excluded from this analysis as its activity duration is not sufficient to perform the experiment. Firstly, we investigate the bug activity of the current and next release for the pressure period (blue boxes in Fig. 8). We visually observe that during the pressure period, bugs for the next release are triaged (left column) and fixed (right column) faster than for the current release. This can be explained by an increasing deadline pressure, requiring developers to prioritise the bugs of the next release and triage and fix them fast to deliver the release with fewer bugs. Mann-Whitney U tests (see Table II) confirm that the null hypothesis H0 t 3a , stating that the time to triage bugs of the current and next new release is not different from in the pressure period, can be rejected for all releases except 4.8. We found a negligible effect size for release 4.4, a small effect for 8 releases, medium for release 4.5 and large for 4 releases. Similarly, we confirm the null hypothesis H0 f 3a , i.e., the time to fix bugs of the current and next new release is the same in the pressure period, can be rejected for all releases (see Table II). We found a small effect size for release 4.8, medium for releases 3.8/4.2, 4.6 and 4.9, and large for 11 releases. Secondly, for both the current and the next release, we investigate the differences in triaging and fixing time between the early period (red boxes in Fig. 8) and the pressure period (blue boxes). For the current release, we observe that the triaging and fixing are longer in the pressure period than in the early period. These results indicate that bugs triaged and fixed in the pressure period have been open for a long time and that developers tend to triage many bugs that had lived for a long time in the current release before releasing the next one. Mann-Whitney U tests (see Table II) confirm that the null hypothesis H0 t 3b , stating that the triaging time of the current release in the early period is not different from the pressure period, can be rejected for all releases except 3.5, 4.4 and 4.8. We found a negligible effect size for 4.3 and 4.6, a small effect for 6 releases, medium for 3 releases and large for release 3.3. The respective results for the fixing time show that the null hypothesis H0 f 3b can be rejected for all releases. The effect sizes range between small and large. Therefore, for most releases, bugs of the current release took longer to triage or fix during the pressure period compared to the early period. For the next release, we do not observe a difference between the triaging time of the bugs in the pressure period and early period. Bugs for the next release tend to be triaged in the same way regardless of the considered period. Developers try to triage these bugs as soon as possible. Mann-Whitney U tests (Table II) confirmed that the null hypothesis H0 t 3c , stating that triaging time of the next release in the early period is not different from in the pressure period, can be rejected for the 3.x series except for 3.4 and 3.5. We cannot reject H0 t 3c for any of the 4.x releases except for 4.4, 4.5 and 4.8. Even for those releases where H0 t 3c can be rejected, the effect size is negligible or small (for 3.3). This implies that there is little or no difference between the triaging time of the next release in the early period and in the pressure period. For the fixing time, we visually observed a longer time during the pressure period. The null hypothesis H0 f 3c , stating that bug fixing time of the next release in the early period is not different from in the pressure period, can be rejected for all releases except 4.7 and 4.8. For all the releases where H0 f 3c can be rejected, the effect size is negligible except for 3.2, 4.4 and 4.9. This implies that, with the exception of those releases, there is very little difference in the time to fix bugs of the next release during the early period than during the pressure period.

Bug triaging time increases as the next release is approaching. It takes less time to triage and fix bugs during the pressure period of the next release compared to the current release. Bugs of the current release that are triaged and fixed in the pressure period have been open for longer compared to the respective ones in the early period. The fact that the next release is approaching does not affect the triaging and fixing time of bugs for the next release.

V. Discussion

Changes in the bug fixing process can have a direct impact on the efficiency of bug handling activity. As we have shown in Section III-F and RQ1 in Section IV, the Eclipse community stopped using resolution statuses indicating that the bug still needed futher processing (LATER or REMIND status). This decision naturally caused a decrease in the resolution rate, but the fixing rate increased. The introduction of an Automated Error Reporting client (AERI) was also considered as beneficial by the Eclipse community. AERI facilitates reporting errors as users do not need to create Bugzilla entries; such entries are handled by the Eclipse community based on the reports they receive. In turn, users can provide comments with their reports which are helpful when fixing bugs; according to an AERI report [START_REF] Sewe | One year of automated error reporting[END_REF] commented reports are more than twice as likely to be fixed compared to the ones without a user comment. Similarly, our empirical analysis has confirmed the positive effects of AERI on the bug fixing rate. The bug fixing rate has been studied by Zou et al. [START_REF] Zou | An empirical study of bug fixing rate[END_REF] who analysed the characteristics of bug fixing rates in Eclipse and Mozilla. They measured bug fixing rate, defined as the number of fixed over closed bugs, at a yearly basis from 2001 to 2014, and found that the rate increased from 0.49 to 0.77 for Eclipse and 0.32 to 0.72 for Mozilla. They took into account all issues in all Eclipse projects (not only the Eclipse core) without distinguishing between real bugs and enhancements. For the fixing rate they considered only closed bugs, while we found many Eclipse bugs to be FIXED without ever being CLOSED (see Fig. 1). While we measured the fixing rate of real bugs in the Eclipse core at a release basis, our results align with their reported fixing rates (see Fig. 3). They found that the overall fixing rate of Mozilla (0.44) is much lower than Eclipse (0.66) and report that more bugs tend to be invalid for Mozilla than for Eclipse. Khomh et al. [START_REF] Khomh | Do faster releases improve software quality? An empirical case study of Mozilla Firefox[END_REF], [START_REF] Khomh | Understanding the impact of rapid releases on software quality[END_REF] studied bug handling activity in Mozilla Firefox. They analysed two years of bug activity, whereas we performed a longer study considering 15 years of bug activity for Eclipse. Khomh et al. reported that the transition to a rapid release cycle for Mozilla Firefox has led to shorter bug fixing time, but less bugs are triaged and fixed in a timely fashion. Our results for Eclipse partially align as we also found less bugs to be triaged and fixed. In contrast to Firefox, however, we observed that the fixing rate for Eclipse has improved after transitioning to shorter release cycles (see Section III-F). A possible reason for this difference is that developers from the Firefox community stated that they were not given enough time to prepare for the transition to smaller release cycles [START_REF] Khomh | Understanding the impact of rapid releases on software quality[END_REF], whereas the Eclipse community has been working towards this transition for over a year [START_REF]Eclipse transition to smaller release cycles[END_REF] and has started to introduce intermediate (quarterly) "update" releases since Eclipse 4.6 in 2016. Our results highlight the importance of well preparing the transition from a traditional to a rapid release policy so as the community to become more effective in bug handling activities. Other projects can benefit from the lessons learned about how both Firefox and Eclipse carried out such a transition. While preparing a release, various nightly and integration builds are made available to developers only for testing purposes. However, milestone and release candidates are intended for adoption and testing by users before the scheduled annual release [START_REF]Eclipse development process[END_REF]. This might explain the high number of reports before an official release. Our results show that developers focus more on triaging and fixing bugs of the next release than ones impacting users in the current release. Moreover, bugs of the current release that are triaged in the pressure period have been open for a long time. This can happen because long-lived and possibly complex bugs are planned to be fixed for the next release. The severity of a reported bug is a critical factor in deciding how soon it needs to be fixed [START_REF] Lamkanfi | Predicting the severity of a reported bug[END_REF].

VI. Threats to Validity

Threats to construct validity in our study concern the bug assignment identification and multiple instances of an activity. We minimized the first threat by identifying bug assignments based on both the status and existing practices (see Section III-C). We mitigated the second threat by considering the date of the first assignment, and the date of the last resolution and fixing activities. A threat to internal validity is that our empirical analysis relies on Bugzilla bug reports. We mitigate this threat by verifying that all Eclipse bugs are managed in Bugzilla; even the bugs submitted using AERI are stored in Bugzilla. Another threat stems from bugs not being tagged with a valid release; we excluded such bugs as it is not feasible to properly address such cases. Finally, bugs can be tagged with different major versions throughout their history; we quantified the possible bias from such cases and found that only 98 bugs can affect our analysis; the bias they introduce is insufficient to alter our findings. Regarding external validity, we cannot generalize our results as we only analyzed a single case study of Eclipse.

While the followed methodology is applicable to other systems, the obtained findings are not generalizable. Smaller and less mature projects are likely to reveal other evolutionary characteristics in their bug fixing behavior. Even for Eclipse itself, the findings are only based on the core projects that have a large number of bugs and an active developer community. The findings may differ for smaller and/or peripheral projects within Eclipse that have smaller communities. We mitigate threats to reliability validity by providing a publicly available replication package [START_REF] Khalil | A longitudinal analysis of bug handling across eclipse releases[END_REF] and a detailed description of the followed methodology in Section III.

VII. Conclusion

We conducted an empirical study of the bug handling activity in the Eclipse core projects over a 15-year lifetime. We analysed 16 annual and two quarterly releases, allowing us to study the transition to a rapid release cycle in autumn 2018. We evaluated the evolution of bug triaging time, bug fixing time, bug resolution rate and bug fixing rate. We compared these metrics before and after each release date and between release ranges. Over time, the number of reported bugs per release is decreasing, suggesting that Eclipse and its bug handling process are mature and of high quality. More bugs are reported, assigned and fixed before each release deadline than after it. This difference is becoming smaller with newer releases, mostly because there are less reported bugs before each rapid release. While the bug resolution rate is decreasing over time to rather low values, the fixing rate is becoming very high (close to or above 90%). This improved efficiency seems to be due to a combination of a well-managed bug handling policy and the recent introduction (in June 2015) of an automated error reporting tool. When approaching a release deadline, effort is shifting from bug triaging to fixing, and priority is given to fixing bugs of the next release as opposed to handling bugs of the current release. Overall, we did not observe any negative effect of the transition from an annual to a quarterly release cycle. On the contrary, some observed differences in triaging and fixing times, and rates before and after releases are no longer present. Based on our analysis, we believe that Eclipse is handling its bug activity very well and has benefited from the transition to a rapid release cycle. It remains to be seen if even faster release cycles will continue to yield benefits or on the contrary will have negative consequences.

Fig. 1 :

 1 Fig. 1: The life-cycle of Eclipse bug reports.

  ResRate before (r) = ResRate([date(prev(r)),date(r)[) ResRate after (r) = ResRate([date(r),date(next(r))[) We similarly restrict B report , B fix , B assign and B resolve . For example, B before report (r) = {b ∈ B r report | Dreport(b) ∈ [date(prev(r)),date(r)[ } B after report (r) = {b ∈ B r report | Dreport(b) ∈ [date(r),date(next(r))[ }

Fig. 2 :

 2 Fig. 2: Number of bugs targeting a specific release. The vertical dashed lines indicate the switch from Eclipse 3.x to 4.x, and from an annual to a quarterly cycle after 4.8.

Fig. 3 :

 3 Fig. 3: Resolution and fixing rates per targeted Eclipse release.

Fig. 4 :

 4 Fig.4: Reported bugs before and after each release.

  (d) number of fixed bugs

Fig. 5 :

 5 Fig.5: Monthly evolution of the number of bugs before/after a release, aggregated by release series (y-axis is measured in thousands of bugs).

Fig. 6 :

 6 Fig. 6: Evolution of the resolution and fixing rate before and after each release. (The red vertical line corresponds to the introduction of the AERI error reporting tool.)

Fig. 7 :

 7 Fig. 7: Kaplan-Meier survival curve with 95% confidence interval (indicated by the shaded areas) for triaging time before and after each release.

FXUUHQWFig. 8 :

 8 Fig. 8: Triaging time distributions (left figures) and fixing time distributions (right) when approaching next release.

  triaging

1

  This terminology is used by the Eclipse foundation to reflect a coordinated release effort including the Eclipse Platform and other Eclipse projects. See https://wiki.eclipse.org/Simultaneous Release.

				2,674
				CLOSED	674	REOPENED	881	VERIFIED
			7,671	11,988		12,864		31,356
	138,444	NEW 148,911	50,334 7,631	75,521 ASSIGNED 58,311	7,589 RESOLVED 11,093 120,573 37,115	30,013	FIXED DUPLICATE INVALID WORKSFORME MOVED WONTFIX NOT_ECLIPSE
	2 https://www.eclipse.org/eclipse/development/plans/eclipse
	project plan 4 2.xml

  a next step we filtered bugs based on the version field. As the goal of this work is to study the bug resolution process in relation to each Eclipse release, we only considered those bug reports whose version field value corresponds to an actual Eclipse release ranging between 3.0 and 4.10. To this end, we excluded 3,237 bugs with unspecified version field and 32,985 bugs corresponding to versions smaller than 3.0 or larger than 4.10. We did not consider release 4.11 because at the time of analysis (March 2019) the full dataset was not yet available for extraction. We restricted ourselves to values that actually correspond to valid Eclipse releases; e.g., the valid version values of the 4.7 release found in our dataset were 4.7, 4.7.1, 4.7.1a, 4.7.2, 4.7.3 and 4.7.0 Oxygen. From the remaining bugs, we excluded 2,565 bugs that corresponded to versions that are not listed in the official releases of Eclipse, i.e., 3.9, 3.10, 4.0 and 4.1. Our final dataset (including releases 3.0→3.8, 4.2→4.10) consists of 138,445 bug reports. For the remainder of the analysis, we partitioned all reported bugs into groups according to their major release number as we focus on the major Eclipse releases. For example, group 4.7 contains all reported bugs whose version field prefix is 4.7. For the specific case of the "dual release" of Eclipse 3.8 and 4.2 (that both have the same release date), a single group, 3.8/4.2 was created. The aforementioned processing steps mitigate several threats that could bias the results of our study. Additional factors that can bias our results are explained by Tu et al.

  Date returns the creation date of a bug report.

• D assign : B assign → Date returns the first date the bug report status field has been set to ASSIGNED.

• D resolve : B resolve → Date returns the last date the bug report status field has been set to RESOLVED. • D fix : B fix → Date returns the last date the bug report status field has been set to RESOLVED with value FIXED for the resolution field. Using these functions, we define bug triaging time and bug fixing time as:

TABLE I :

 I Logrank test for difference between the survival distributions of triaging time (resp. fixing time) before and after each release. R indicates that H0 is rejected.

TABLE II :

 II Mann-Whitney U test for triaging and fixing

	time when approaching a release deadline. Whenever a signif-
	icant difference is found, cell values summarize the effect size:
	N(egligible), S(mall), M(edium), L(arge); -indicates that H0
	could not be rejected.

https://bugzilla.readthedocs.io/en/latest/api/core/v1/ bug.html#search-bugs

https://wiki.eclipse.org/Platform UI/Bug Triage

The full set of survival curves can be found in[START_REF] Khalil | A longitudinal analysis of bug handling across eclipse releases[END_REF]

Acknowledgment

This research was partially supported by the FNRS and FWO under the Excellence of Science project 30446992 SECO-ASSIST, the FRQ-FNRS collaborative research project R.60.04.18.F SECO-Health and Région Hauts-de-France.