Aug 08 2013

OpenMandriva Lx progress schedule

penguin_moonNicolas Pomarède, long time community member (user/contributor) of Mandrake/Mandriva, asked some questions to the Technical Committee of OpenMandriva.

Bernhard Rozenkränzer (bero), coordinator of the distribution development, answered him.

Q (N.P.): So, back to the distribution, where are we now? Could we have an updated schedule? Not something like “we’re doing QA [Quality Assurance]” or “we did an alpha-beta-whatever” some months ago, but a real schedule for the month to come.

A (bero): thanks for bringing up [this] topic.

The problem there is that we’re currently blocked by more or less external matters that should be resolved soon, but we have no way to know when exactly.

We’re planning to make a beta release as soon as possible, but in order to do that right (e.g. push in packages identifying it as a release and telling it to update from 2013.0 directories rather than cooker), we need a release branch on ABF.

Once we get that, we have to build a few packages there (anything related to updating), then we can build an iso and pass it to QA for testing. Building the beta candidate iso once we have the release branch should take less than a day.
This should take around 3 days, but there might be further delays if QA actually finds showstoppers that need to be fixed before we go beta.

Then we’ll have to give QA some time to find potential showstoppers, push the beta out to mirrors, get bug reports from the public, and fix relevant bugs reported.
Since we’ve had an extremely long alpha cycle, I’d think we can get by with just 1 beta release and a 3 week beta cycle, but we may decide to prolong it and make more beta releases if people find serious bugs that take longer to fix.

After that, we build another (RC) iso, push it to QA, allow them a bit of time to test, push it out to the public and wait for more bug reports/fix bugs.
This should take 2 weeks unless we run into serious bugs that take longer to fix.
After that, it’s building another (hopefully final) iso, push it to QA, get green light, push it out, and un-freeze cooker.

Q: What are the current blocking points?

A: Main blocker right now is not having the release branch on ABF.
Other known things that we need to fix:

  • fix remaining mass build failures (fortunately there’s not that many)
  • replace remaining Mandriva branding/artwork
  • make sure the infrastructure (including mirrors, download pages, relevant code such as urpmi) is ready to handle releases and updates from release branches
  • go through the reports on bugzilla, sort out which ones are relevant for the release, fix them

Q: What is the deadline to work on them?

A: Deadline for work that should go even into the beta (given we’re hard-frozen, only bugfixes allowed even now – but exceptions can be discussed here, the libreoffice 4.1 update has already been approved): Until the release branch is created on ABF. (Yes, that’s not a real date, but that’s when we’re planning to cut the beta release.)

Q: What are the different RC versions to expect, and especially what would be the date for each of these?

A:

  • Beta release: 2-3 days after this, unless QA finds showstoppers that can’t be fixed in this timeframe.

If we find enough serious problems to decide we need a second beta (I hope this won’t be necessary since we’ve already been delayed more than enough and we’ve had a long alpha cycle):

  • Beta 2 release: Around 3 weeks later
  • RC release: Around 3 weeks later unless public testing finds showstoppers that can’t be fixed in this timeframe.
  • Final release: Around 2 weeks later unless public testing finds showstoppers that can’t be fixed in this timeframe.

I realize this is more vague than what you were hoping for — but it is impossible to set schedules in stone when we have no way to know what feedback we’ll get and we have no way to know for real how many contributors will be available for how much time to fix things. We’re not a company with any guaranteed availability of people.

Q: Some months ago, I could understand it could be difficult to have a precise view on this, because the association, servers, infrastructure… needed to be set up, but now, where are we?

A: All the setup is essentially done (with a bit of a problem remaining on the ABF (build system) side — we have no way to create release branches without semi-external help).
Cooker is usable and in pretty good shape. It is still difficult to have any precise schedules — and this is unlikely to change anytime soon, there’s simply no way to guarantee some delivery date if the number of contributors is small enough for 1 “missing person” to matter, and there’s 0 guaranteed availability. We’re a community project now — with all the advantages it brings, but also the few disadvantages it brings (no full-time developers with guaranteed availability).

Note from bero: things have improved since this answer (the ABF issue is resolved), so there’s a pretty good chance we can actually stick to this timeline. Of course we still have to make room for the possibility that there will be showstopper bugs that simply take longer than expected to fix, so don’t take this as a 100% promise.

Image credit: Penguin looking at the moon http://disney.go.com/create/art/2gs11k6YoEjb00001004x4w0-h-3a10fcpenguin_moonNicolas Pomarède, langjähriges Communitymitglied (Nutzer, Beitragender) von Mandrake/Mandriva stellte einige Fragen an das Technical Committee von OpenMandriva.

Bernhard Rozenkränzer (bero), Koordinator der Entwicklung des Distribution antwortete ihm.

F (N.P.): Nun, zurück zur Distribution, wo stehen wir nun? Können wir einen aktualisierten Zeitplan haben? Bitte nicht etwas wie „Wir machen QA [Quality Assurance – Qualitätssicherung“ oder „wir machen eine Alpha-Beta-wieauchimmer“ vor einigen Monaten aber einen echten Zeitplan für den kommenden Monat.

A (bero): Danke, dass Du dieses Thema ansprichst.

Das existierende Problem ist, dass wir momentan von mehr oder weniger externen Angelegenheiten blockiert werden, die bald gelöst werden sollten aber wir haben keine Möglichkeit, zu wissen wann dies genau geschieht.

Wir planen eine Betaveröffentlichung so schnell wie möglich, aber um dies anständig zu machen (z.B. Einbringen von Paketen, die es als Veröffentlichung identifizieren und sagen, dass es von 2013.0 Verzeichnissen statt Cooker aktualisieren soll) benötigen wir einen Releasezweig auf ABF.

Sobald wir das haben, müssen wir einige Pakete dort bauen (alle bezogen auf Aktualisieren) dann können wir ein ISO bauen und es an QA zum Testen geben. Bauen das Beta-Kandidat-ISO sobald wir den Releasezweig haben sollte weniger als einen Tag dauern.
Dies sollte etwa 3 Tage dauern aber es kann weitere Verzögerungen geben wenn QA etwas findet, was vor der Betaveröffentlichung repariert werden muss (Showstopper).

Dann müssen wir QA etwas Zeit geben, potentielle Showstopper zu finden, die Beta heraus an die Mirrors zu leiten und Bugreports von der Öffentlichkeit zu bekommen und relavente Bugs zu beheben.
Da wir einen sehr langen Alphazyklus haben, glaube ich dass wir mit einem Betarelease und einem 3-wöchigen Betazyklus aus kommen aber wir können uns entscheiden, diesen zu verlängern und mehr Betaveröffentlichung zu machen wenn die Leute mehrere ernste Bugs finden, die länger zur Korrektur brauchen.

Danach bauen wir ein weiteres (RC) ISO, geben es an QA, geben ihnen etwas Zeit zum Test und geben es an die Öffentlichkeit und warten auf weitere Bugreports und Fixes.
Das sollte zwei Wochen dauern, es sei denn wir stoßen auf ernste Bugs, die länger zur Korrektur brauchen.
Danach folgt die Erstellung eines weiteren (hoffentlich finalen) ISO, weitergabe an QA, grünes Licht bekommen, veröffentlichen und Entfrieren des Cookers.

Q: Was sind die aktuellen Blocker?

A: Der Hauptblocker momentan ist, nicht den Releasezweig auf ABF zu haben.
Andere bekannte Themen, die wir beheben müssen:

  • Behebung der restlichen Massenbaufehlern (zum Glück gibt es nicht so viele)
  • Ersetzen des noch bestehenden Mandriva Branding/Artwork
  • Vergewissern, dass die Infrastruktur (inkl. Mirror, Downloadseiten, relevanten Codes so wie urpmi) bereit ist, Veröffentlichungen und Updates von den Releasezweigen zu bekommen
  • Durchgehen von Reports auf Bugzilla, Sortieren welche relevant für die Veröffentlichung sind und sie beheben

Q: Wie ist die Deadline um an diesen zu arbeiten?

A: Deadline für die Arbeit sollte sogar in die Beta gehen (wir sind hard-frozen, nur Bugfixes sind erlaubt – aber Ausnahmen können hier diskutiert werden, dem Libroffice 4.1 Update wurde bereits zugestimmt): Sobald der Releasezweig auf ABF erstellt wird. (Ja das ist kein echtes Datum, aber dort planen wir den Schnitt für die Betaveröffentlichung.)

Q: Was sind die verschiedenen zu erwartenden RC-Versionen und insbesondere was wäre das Datum jeweils?

A:

  • Beta: 2-3 Tage nach dem hier, es sei denn QA findet Showstoppers, die nicht innerhalb dieses Zeitrahmens behoben werden können.

Wenn wir genug ernste Probleme finden um uns zu entscheiden, dass wir eine zweite Beta brauchen (Ich hoffe das wird nicht nötig sein, da wir schon mehr als genug verzögert sind und einen langen Alphazyklus hatten):

  • Beta 2 Veröffentlichung: etwa drei Wochen später
  • RC release: etwa drei Wochen später – es sei denn öffentliche Tests finden Showstopper, die nicht innerhalb dieses Zeitrahmens behoben werden können.
  • Final release: Etwa zwei Wochen später – es sei denn öffentliche Tests finden Showstopper, die nicht innerhalb dieses Zeitrahmens behoben werden können.

Ich verstehe schon, dass dies etwas vage ist, als Du erhofft hast – aber es ist unmöglich, Termine in Stein zu meißeln wenn wir nicht wissen, was für Feedback wir bekommen und keine Möglichkeit haben genau zu wissen, wie viele Beitragende für wie lang verfügbar sein werden, um Probleme zu beheben. Wir sind keine Firma mit garantierter Verfügbarkeit von Personal.

Q: Vor einigen Monaten, konnte ich verstehen es ist schwierig eine genaue Sicht darauf zu haben, wegen der Association, Server, Infrastruktur etc. mussten eingerichtet werden aber nun – wo stehen wir?

A: Die Einrichtung ist erfolgt (mit einem verbleibenden Problem auf dem ABF (build system) – wir haben keine Möglichkeit, Releasezweige ohne semi-externe Hilfe zu erstellen).
Cooker ist benutzbar und im guten Zustand. Es ist immer noch schwierig, genaue Termine zu haben- und das wird sich in Kürze auch nicht ändern. Es gibt einfach keine Möglichkeit, einen Liefertermin bei Beitragenden zu nennen, wo jeder einzelne zählt und sich sein Fehlen bemerkbar macht. Wir sind nun ein Communityprojekt – mit allen Vorteilen, die so etwas bringt aber auch die wenigen Nachteile (keine Vollzeitentwickler mit garantierter Verfügbarkeit).

Notiz von bero: Die Dinge haben sich seit dieser Antwort verbessert (das ABF-Thema ist gelöst), also gibt es eine gute Chance, dass wir uns an diesen Zeitrahmen halten können. Natürlich müssen wir noch Platz schaffen für die Möglichkeit, dass es Showstopper-Bugs gibt, die mehr Zeit zum beheben brauchen. Also nehmt das nicht als ein 100% Versprechen.

Image credit: Penguin looking at the moon http://disney.go.com/create/art/2gs11k6YoEjb00001004x4w0-h-3a10fc

Translation by: Maik „Tapwag“ Wagnerpenguin_moonNicolas Pomarède, membre de la communauté depuis longtemps (utilisateur / contributeur) de Mandrake / Mandriva, a posé quelques questions au Comité technique d’ OpenMandriva.

Bernhard Rozenkränzer (bero), coordinateur du développement de la distribution, lui a répondu.

Q. (N.Pomarède): Alors, revenons à la distribution, où en sommes-nous maintenant ? Pourrions-nous avoir un calendrier mis à jour ? Pas quelque chose comme «nous faisons de l’Assurance Qualité (AQ)» ou « nous avons fait une alpha-bêta-quelque-chose il y a quelques mois », mais un vrai calendrier pour les mois à venir.

R. (Bero): merci de reprendre ce sujet.

Le problème est que nous sommes actuellement bloqués par des questions plus ou moins externes qui devraient être bientôt résolues, mais nous n’avons aucun moyen de savoir quand exactement.

Nous avons l’intention de sortir une nouvelle version bêta dès que possible, mais pour le faire correctement (par exemple installer des paquetages identifiés comme faisant partie de la release et en faisant en sorte que les mises à jour se fassent depuis les répertoires 2013.0 plutôt que cooker), nous avons besoin d’une branche release dans ABF.

Une fois cela obtenu, nous devons produire quelques paquets (tout ce qui concerne la mise à jour), ensuite nous pourrons construire une iso et la transmettre à l’équipe Assurance Qualité pour les tests. Construire une iso bêta lorsque nous aurons la branche release devrait prendre moins d’une journée.
Tout ceci devrait prendre environ 3 jours, mais il pourrait y avoir des retards supplémentaires si l’équipe AQ trouve en fait des bogues majeurs qui doivent être corrigés avant la bêta.

Ensuite, nous devrons donner à l’AQ un peu de temps pour trouver des bogues sérieux potentiels, copier la bêta dans les miroirs, obtenir des rapports de bogues du public, et corriger ceux qui sont pertinents.
Puisque que nous avons eu un cycle alpha extrêmement long, je pense que nous pouvons nous en tirer avec seulement une version bêta et un cycle de test de 3 semaines, mais nous pouvons décider de prolonger et sortir d’autres bêta si on trouve des bogues sérieux qui prennent plus de temps à corriger.

Après cela, nous construirons une autre iso (RC), transmise à l’AQ, en leur laissant un peu de temps pour tester, nous la rendrons publique et attendrons pour plus de rapports de bogues à corriger.
Cela devrait prendre 2 semaines, sauf nous nous heurtons à de sérieux bogues plus longs à corriger.
Après ça, on construira une autre iso (que nous espérons finale) transmise à l’AQ, rendue publique dès le feu vert obtenu, et on dégèlera cooker.

Q : Quels sont les points de blocage actuels?

R : le point de blocage principal pour le moment est de ne pas avoir de branche release dans ABF.
Autres choses connues que nous devons fixer:

  • corriger les échecs de compilation de masse restants (heureusement il n’y en a pas tant que ça)
  • remplacer les élément graphiques de Mandriva encore présents
  • s’assurer que l’infrastructure (y compris les miroirs, les pages de téléchargement, les codes pertinents comme urpmi) est prête à gérer les communiqués et mises à jour à partir des branches release
  • passer par les rapports sur bugzilla, trier ceux qui sont pertinents pour la release, les corriger

Q : Quelle est la date limite pour travailler sur tout ça ?

R : la date limite pour les travaux dans la bêta (étant donné que tout est gelé, seules des corrections de bogues sont permises encore aujourd’hui – mais des exceptions peuvent être discutées ici, la mise à jour de LibreOffice 4.1 a déjà été approuvée): jusqu’à ce que la branche release soit créé sur ABF. (Oui, ce n’est pas une vraie date, mais c’est à ce moment que nous avons l’intention d’arrêter la version bêta.)

Q : Quelles sont les différentes versions RC à attendre, et surtout quelle serait la date pour chacune ?

R :

  • version bêta: 2-3 jours après, à moins que l’AQ trouve des bogues importants qui ne pourraient être corrigés dans ce délai.

Si nous trouvons des problèmes suffisamment graves nous pourrions avoir besoin d’une seconde bêta (j’espère que cela ne sera pas nécessaire, puisque nous avons déjà été retardé plus que suffisamment et nous avons eu un cycle alpha long):

  • Bêta 2 : environ 3 semaines plus tard
  • RC : environ 3 semaines plus tard, à moins que des tests publics trouvent des bogues sérieux qui ne pourraient être résolus dans ce délai.
  • Version finale: environ 2 semaines plus tard, à moins que des tests publics trouvent des bogues sérieux qui ne pourraient être résolus dans ce délai.

Je sais que c’est plus vague que ce que vous espériez – mais il est impossible d’établir un calendrier gravé dans le marbre lorsque nous n’avons aucun moyen de savoir quels seront les retours que nous obtiendrons et ni combien de collaborateurs réels seront disponibles et pendant combien de temps pour corriger les choses. Nous ne sommes pas une entreprise avec la garantie de disponibilité des personnes.

Q : Il y a quelques mois, je pouvais comprendre qu’il pourrait être difficile d’avoir une vue précise sur ce point, parce que l’association, les serveurs, les infrastructures … devaient être mis en place, mais maintenant, où allons-nous?

R : Tout le paramétrage est fait pour l’essentiel (avec quelques problèmes en suspens du côté d’ABF (système de construction) – nous n’avons aucun moyen de créer des branches release sans aide semi-externe).
Cooker est utilisable et en assez bonne forme. Il est encore difficile d’avoir un planning précis – et cela ne devrait pas changer de sitôt, il n’y a tout simplement aucun moyen de garantir une date de livraison si le nombre de contributeurs est si petit qu’une « personne manquante » compte, et il n’y a aucune garantie de disponibilité. Nous avons un projet communautaire maintenant – avec tous les avantages que cela apporte, mais aussi les quelques inconvénients que cela engendre (pas de développeurs à temps plein avec une disponibilité garantie).

Note de Bero: les choses se sont améliorées depuis cette réponse (le problème ABF est résolu), donc il y a une bonne chance que nous puissions réellement tenir ce calendrier. Bien sûr, nous avons encore à faire face à la possibilité qu’il y aura des bogues sérieux qui prendront simplement plus longtemps que prévu à être corrigés, alors ne prenez pas cela comme une promesse à 100%.

Crédit d’image: Pingouin regardant la lune http://disney.go.com/create/art/2gs11k6YoEjb00001004x4w0-h-3a10fc

Trad: jclpenguin_moonNicolas Pomarède, membro da molto tempo della comunità di Mandrake e Mandriva (come utente come collaboratore) fa qualche domanda al Comitato Tecnico di OpenMandriva.

Bernhard Rozenkränzer (bero), coordinatore dello sviluppo della distribuzione, gli risponde.

Q (N.P.): Torniamo alla distribuzione: a che punto siamo? Possiamo avere una tabella di marcia aggiornata? Non qualcosa del tipo “stiamo facendo della QA [Controllo di Qualità]” o “abbiamo fatto una alfa-beta qualcosa” qualche mese fa, ma una tabella di marcia reale per i prossimi mesi.

R (bero): ti ringrazio per aver riproposto questa domanda.
Il problema è che in questo momento siamo bloccati da problemi esterni che dovrebbero essere risolti a breve ma non c’è modo di sapere esattamente quando.

Contiamo di preparare una versione beta prima possibile ma per farlo (ad esempio per identificare i pacchetti come nuova versione e per farli aggiornare dalle cartelle 2013.0 invece che da quelle della cooker) abbiamo bisogno di un ramo release di ABF.

Fatto questo dobbiamo compilare qualche pacchetto (tutto quello che è collegato agli aggiornamenti) e dopo possiamo preparare la iso e passarla al QA (Controllo Qualità) per il collaudo. Dal momento in cui abbiamo il ramo release preparare l’iso della beta candidate dovrebbe richiedere meno di un giorno.
Il tutto dovrebbe richiedere circa 3 giorni ma potrebbero esserci ulteriori ritardi se la QA dovesse trovare grossi guai che sia necessario risolvere prima della beta.
Poi dobbiamo lasciare un po di tempo al QA per scovare potenziali errori, caricare la beta nei mirror, aspettare segnalazioni di bug e risolvere quelli importanti.
Considerato che l’alfa è uscita da un bel po’ di tempo credo ci possa bastare una sola beta da tenere per 3 settimane. Possiamo prolungare il periodo o prevedere altre versioni beta se ci saranno segnalati bug particolarmente importanti che richiedano tempi lunghi per la soluzione.
Poi prepareremo un’altra iso (RC o Release Candidate), la passeremo al QA che avrà bisogno di un po’ di tempo per il collaudo, la faremo uscire e aspetteremo altre segnalazioni di bug che saranno risolti.
Per questo dovrebbero bastare 2 settimane a meno che non saltino fuori problemi seri che richiedano più tempo per essere risolti.
Infine prepareremo un’altra iso (si spera quella definitiva), la manderemo al QA e appena avremo semaforo verde la pubblicheremo e sbloccheremo la cooker.

D: Quali sono gli ostacoli principali in questo momento?

R: In questo momento l’ostacolo principale è la mancanza del ramo release di ABF.
Le altre cose che dobbiamo sistemare sono:

  • risolvere i problemi residui legati alla compilazione (fortunatamente non sono molti)
  • sostituire i marchi e i simboli di Mandriva
  • assicurarci che l’infrastruttura (compresi i mirror, le pagine per i download e i programmi importanti come urpmi) siano pronti a gestire nuove versioni e aggiornamenti dei rami release.
  • esaminare le segnalazioni di bugzilla, selezionare quelle più importanti per la release e risolvere i problemi segnalati

D: Qual è la scadenza ?

R: Scadenza per il lavoro che dovrebbe riguardare anche la beta: fino al momento in cui sarà creato il ramo release in ABF (dato che siamo al blocco degli aggiornamenti già da ora ci stiamo dedicando solo alla soluzione dei bug ma ci possono essere eccezioni, ad esempio l’aggiornamento di Libreoffice alla 4.1 è già stato approvato). Certo non è una vera e propria data ma è quello che ci prefiggiamo per la beta.

D: Quali versioni RC ci dobbiamo aspettare e soprattutto quando è previsto che escano?

R:

  • Versione Beta 2 o 3 giorni dopo quello che abbiamo detto se il controllo di qualità non trova errori seri.

Se ce ne saranno tanti da giustificare una seconda versione beta (ma spero non sarà necessaria visto il notevole ritardo e quindi il lungo periodo in cui la alfa è stata testata):

  • Beta 2: circa 3 settimane più tardi
  • RC: circa 3 settimane dopo se il test degli utenti non trova problemi grossi che non possono essere risolti in questo periodo
  • versione definitiva: circa 2 settimane dopo, al solito se il test degli utenti non trova problemi grossi che non possono essere risolti in questo periodo.

Mi rendo conto come tutto questo sia più vago di quanto speravi ma è impossibile essere precisi senza sapere che problemi incontreremo e quanti collaboratori potranno dedicarsi alla loro soluzione. Purtroppo non siamo una struttura industriale con una precisa disponibilità di personale.

D: Qualche mese fa ho capito che non si poteva avere una visione chiara della situazione perché l’associazione, i server, l’infrastruttura … dovevano essere messi in funzione. Ma adesso a che punto siamo?

R: Sostanzialmente è tutto a posto (rimane qualche problema per l’ABF perché non c’è modo di creare il ramo release senza aiuto esterno).
Cooker è utilizzabile e in buone condizioni. Resta difficile stabile una scaletta precisa e non credo ci riusciremo a breve. Purtroppo non è semplice garantire delle scadenze se anche l’assenza di una sola persona influisce in modo sensibile. Adesso siamo un progetto comunitario, con tutti i vantaggi che ne derivano ma anche con qualche svantaggio (non ci sono sviluppatori a tempo pieno con una disponibilità di tempo garantita)

Nota di bero: le cose sono migliorate dalla risposta precedente (il problema con ABF è risolto) e quindi c’è una buona probabilità che le scadenze siano rispettate. Naturalmente dobbiamo prevedere un po’ di tempo per eventuali problemi che richiedano più del previsto per essere risolti quindi non prendete tutto questo come una promessa da mantenere al 100%.

Image credit: Penguin looking at the moon http://disney.go.com/create/art/2gs11k6YoEjb00001004x4w0-h-3a10fc

Traduzione di Giorgiopenguin_moonNicolas Pomarède, um antigo membro da comunidade (usuário/colaborador) do Mandrake/Mandriva, fez algumas perguntas ao Comitê Técnico da OpenMandriva.

Bernhard Rozenkränzer (bero), coordenador de desenvolvimento da distribuição, respondeu-lhe.

P (N.P.): Então, de volta à distribuição, onde estamos agora? Poderíamos ter uma agenda atualizada? Não algo como “nós estamos fazendo QA [Garantia de Qualidade]” ou “nós fizemos um alfa-beta-qualquer” há alguns meses, mas uma verdadeira agenda do próximo mês que vem.

R (bero): obrigado por nos trazer este tópico.

O problema que existe é que atualmente estamos bloqueados por questões, mais ou menos externas, que devem ser resolvidas em breve, mas não temos como saber quando exatamente.

Estamos planejando liberar o beta o mais rápido possível, mas para fazer isso bem (por exemplo, colocar pacotes identificando o lançamento e dizer para atualizar dos diretórios 2013.0 ao invés do cooker), precisamos de uma ramificação do lançamento na ABF.

Uma vez que conseguirmos isso, temos que construir alguns pacotes lá (tudo que seja relacionado com a atualização), então podemos construir uma imagem iso e passá-la para QA para testes. Construir o iso candidato a beta, quando tivermos a ramificação do lançamento, deve levar menos de um dia.
Isto deve levar cerca de 3 dias, mas pode haver mais atrasos se a QA realmente encontrar bugs críticos que precisam ser corrigidos antes de liberarmos o beta.

Então nós vamos ter de dar à QA tempo para encontrar potenciais bugs críticos, enviar o beta para os mirrors, obter relatórios de bugs do público e corrigir bugs relevantes que tenham sido reportados.
Como tivemos um ciclo alfa extremamente longo, eu penso que basta 1 versão beta e um ciclo de beta 3 semanas, mas podemos decidir prolongá-lo e fazer mais versões beta, se as pessoas encontrarem erros graves que levam mais tempo para corrigir.

Depois disso, construir outro iso (RC), enviá-lo para QA, permitindo-lhes um pouco de tempo para testar, liberá-lo para o público e esperar por mais relatórios/correções de bugs.
Isso deve demorar duas semanas, a menos que nos deparamos com erros graves que levam mais tempo para corrigir.
Depois disso, construir outro iso (espero que final), enviá-lo para QA, obter luz verde, enviá-lo para lançamento e descongelar o cooker.

P: Quais são os atuais pontos de bloqueios?

R: Principal bloqueio atualmente é não ter a ramificação do lançamento na ABF.
Outras coisas que são precisas corrigir:

  • Corrigir os erros restantes da reconstrução em massa (felizmente não são muitos)
  • Substituir as restantes marcas/artes da Mandriva
  • Certificar-se de que a infraestrutura (incluindo mirrors, páginas de download, códigos relevantes tais como urpmi) está pronto para lidar com lançamentos e atualizações da ramificação do lançamento
  • Verificar os relatórios do bugzilla, listar quais são relevantes para o lançamento e corrigi-los

P: Qual o prazo para trabalhar neles?

R: Prazo para o trabalho que deve envolver a versão beta (dado que está completamente-congelada, apenas são permitidas correções de bugs – mas exceções podem ser discutidas aqui, a atualização do LibreOffice 4.1 já foi aprovada): Até à ramificação do lançamento ser criado na ABF (Sim, isto não é uma data real, mas é quando estamos a contar ter a versão beta).

P: Quais são as diferentes versões RC a esperar e especialmente, qual será a data para cada uma delas?

R:

  • Versão beta: 2-3 dias após isso, a menos que a QA encontre bugs críticos que não podem ser corrigidos neste período de tempo.

Se encontrarmos problemas bastante graves e ser decidido que precisamos de uma segunda versão beta (espero que isto não seja necessário, visto já estarmos atrasados mais do que suficiente e tivemos um ciclo alfa longo):

  • Versão beta 2: em torno de 3 semanas mais tarde
  • Lançamento RC: em torno de 3 semanas mais tarde, a menos que o teste público encontre bugs críticos que não podem ser corrigidos neste período de tempo.
  • Lançamento final: em torno de 2 semanas mais tarde, a menos que o teste público encontre bugs críticos que não podem ser corrigidos neste período de tempo.

Sei que isso é mais vago do que você estava esperando — mas é impossível definir prazos em pedra quando não temos maneira de saber que feedback vamos ter e não temos como saber de verdade quantos contribuintes estarão disponíveis, nem por quanto tempo, para corrigir as coisas. Não somos uma empresa com disponibilidade garantida de pessoas.

P: Alguns meses atrás, eu entenderia que poderia ser difícil ter uma visão exata sobre isso, porque a associação, servidores, infraestrutura… precisavam ser definidos, mas agora, como estamos?

R: Toda configuração essencial está feita (com um pequeno problema referente à ABF (sistema de compilação) — nós não temos nenhuma maneira de criar a ramificação do lançamento sem ajuda semi-externa).
Cooker é utilizável e está em boa forma. Ainda é difícil ter uma agenda precisa — e isto é improvável que mude em breve, não há simplesmente nenhuma maneira de garantir uma data de entrega se o número de contribuintes é pequeno o suficiente para 1 “pessoa em falta” ser importante e há 0 garantia de disponibilidade. Agora somos um projeto de comunidade — com todas as vantagens que traz, mas também as poucas desvantagens que traz (sem desenvolvedores em tempo integral com disponibilidade garantida).

Nota do bero: as coisas melhoraram desde [esta resposta] (problema na ABF foi resolvido), então há uma boa chance de que podemos realmente ficar com este cronograma. Claro que ainda temos que dar espaço para a possibilidade de que haver bugs críticos que simplesmente levam mais tempo do que o esperado para corrigir, então não tome isso como uma promessa de 100%.

Crédito da imagem: pinguim olhando a lua http://disney.go.com/create/art/2gs11k6YoEjb00001004x4w0-h-3a10fc

Tradução: Alisson Oliveira (Linukiss)

1 comment

    • Desmondra on August 25, 2013 at 12:32 pm

    I have been working with Mageia 3 and ran into problem:-

    https://bugzilla.gnome.org/show_bug.cgi?id=706565

    It turned out that ifplugd and NetworkManager were both installed, but this did take a lot of effort to resolve.

    And when I wanted to test the alpha I found that using the USB external drive was not acceptable. This is important to me as it enables testing without committing to internal harddrive. So I am looking forward to the beta and will be doing a lot of testing with that.

Comments have been disabled.