Re: Module Proposal: Zeitgeist

[Mikkel Kamstrup Erlandsen <mikkel kamstrup gmail com>]

On 22 April 2010 20:09, Johannes Schmid <jhs jsschmid de> wrote:
> Hi!
>
> Am Donnerstag, den 22.04.2010, 19:57 +0200 schrieb Siegfried-Angel
> Gevatter Pujals:
>> 2010/4/22 Frederic Peters <fpeters gnome org>:
>> > "We are discussing the issue and we don't see a problem to have our
>> > trunk from launchpad ported to git with every release.", but release
>> > team is too late for translators.
>>
>> Yeah, I agree that copying stuff over just before we release isn't
>> really useful.
>>
>> Here is what I envision:
>>
>>  - Translations handled using GNOME infrastructure, that's fine.
>>
>>  - For the code, "trunk" could be moved to Git with Launchpad
>> mirroring it. Most of the actual development would probably still
>> happen in branches, but periodically landed into trunk. Rodrigo said
>> that's what he does too so I don't see how it's a problem. (By the
>> way, Seif and Markus will need Git accounts if that's what we do).
>>
>
> Well, it's actually up to you where you host your "private" repositories
> so I guess that would be fine (as long as you accept patches that are
> against git master). You won't make friends when saying: "Sorry, this
> doesn't apply to my bzr branch, could you please update".
>
>>  - Switching to another interface for bug/blueprints/reviews part is
>> the biggest issue (it's not about the data, but the fact that
>> Launchpad is what works best for us). Personally I'd be happy with a
>> middle-ground like having Launchpad as the main tracker, but accepting
>> bug reports on Bugzilla and forwarding those to Launchpad.
>
> Could you explain why? Could you give facts? Is there something that
> needs to be improved with GNOME infrastructure? Some specific for "your"
> workflow?

Here's what we do. We set a series of milestones and target bugs and
blueprints to these milestones. We also attach branches (not patches)
to bugs and blueprints. When a linked branch is ready to merge into
another branch (trunk or other) we add a merge request, which enables
the review system. We create sub teams and sub projects that all have
different rights and responsibilities. So basically we use pretty much
all aspects of a modern project hosting solution. Bugzilla is just a
bug tracker.

You don't see a lot on LP these days because we have completed most of
what we had up. Admittedly it's not very obvious how to list closed
bugs, but we have all in all 146 on the Zeitgeist project (keeping in
mind that we moved the project a while back).

So there. I like this setup, but personally I could also work with
Bz+git, even though Bz feels a bit 1990ish.

I am not sure this whole hosting discussion is worth the effort. If we
as a team can guarantee that we will work towards an acceptable
solution (given that we are accepted) that ought to be good enough.
Or, as Emmanuelle pointed out, if we end up as an external dep. then
the discussion is just moot.

-- 
Cheers,
Mikkel