Re: Module Proposal: Zeitgeist


(seems like the initial reply wasn't sent to the ML)

>> According to
>> "Use of GNOME resources: Modules must use GNOME FTP for releases.
>> Modules ought to use GNOME Bugzilla and GNOME Git (there had better be a
>> very good reason for not doing so, such as hosted
>> libraries designed to be used by both GNOME and KDE)."
>> What are your plans? Same probably applies for i18n (damned-lies).
> We don't have any concrete plans. However moving our tarballs to GNOME
> FTP should pose no problem at all, likewise for i18n. Since we are
> talking daemons here i18n is not a big part of the project.

I18n more or less directly depends on having the module in git (as
damned-lies gets the status from git and will be able to commit directly
to git in the not-to-far-away future.

> As for VCS and bug tracking it'll be quite a lot more work on our part
> if we should move. I don't think anyone in the team is directly
> opposed to the idea, but it's more the fact that it would be a major
> inconvenience. We make heavy use of Launchpad's branc/review features
> and integration with blueprints and bugs. Of course we can replace
> this with a hand held combination of bugzilla and wikipages, but it
> would be a major change in our workflow.

I of course see your point that it courses some inconvenience and I
wouldn't want to force you to do this migration tommorow but in the end,
people will try to report GNOME bugs in bugzilla.

I kind of looked on the amount of work that would need to be done and saw
12 bugs and 4 blueprints which is really an amount that can easily be
handled manually (copy&paste into bugzilla). I would rather do such a
migration sooner that later because once your bug database fills up,
things will get more difficult.

If it's just to get this 16 items migrated I will happily volunteer...

> Perhaps an unholy alliance of bzr-git and Launchpad's git-import
> feature can make all parts happy (at least vcs-wise)? I will take a
> look at this when I have the time.

I think you should rather see that the other way round - track your stuff using bzr if you are more familiar with it but keep
the "real" code in git.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]