Hi there.
I am including Alexandre in CC, as we have even considered the
possibility of forking mondo some time ago (creating a mondo-ng), but
seeing as you are open to contributions, this means that we can join
forces and make things happen much more smoothly.
On Aug 31, 2009, at 14:01, Bruno Cornec wrote:
Andree Leidenfrost said on Mon, Aug 31, 2009 at 07:18:58PM +1000:
I am also CC'ing upstream and I suggest the of you communicate
directly,
especially but not limited to issues that could possibly be addressed
upstream - Bruno is planning a new release shortly.
Yes. 2.2.9 is in a frozen state now. I just want to fix a last
remaining
bug seen on a customer site. Then publish.
Please, just wait a little bit. It would be nice to have a sort-of
peer-review on the code.
Alexandre is not experienced with coding, but he is quite competent
and a fast learner. He also has a very good sense of "cleanliness",
which is not to be found everywhere. I'd even say that this is
something lacking from current-day coders.
I'm also working in // on 2.2.10 which already contains a large number
of modifications.
I'm not sure exactly which changes you have already implemented. It
seems that the code is hosted in a SVN repo, is that correct?
If yes, could you please provide a "svn2cl --group-by-date --rev HEAD:
1" log? I'm not at a Unix system right now, unfortunately.
On Wed, 2009-08-26 at 06:05 -0300, Rogério Brito wrote:
Anyway, back to the subject of maintaining mondo, yes, I would
like to
work on it a little bit. I'm still not sure if I can co-maintain it
(most probably, I can), but I would like to delve further in the
code.
Well, I'm also interested to provide to Debian the latest packages as
soon as possible. Thanks to Andree's work, I have a whiole build
infrastrcuture in place to produce packages for Debian 3.1, 4.0 and
5.0.
I just created/adapted two patches for mondo 2.2.7, which would be a
good thing to have upstream, if they aren't merged yet. Also, I
included some packaging clean ups that may be worth incorporating in
your build infrastructure.
(Do you still have Debian 3.1 and 4.0 around? You should probably
know that they are obsolete, especially 3.1. 4.0 is the current
"oldstable" and support for it will cease in the near future, if it
has not yet stopped).
So Iwas considering the possibility to become a Debian Maintainer (Cf:
http://wiki.debian.org/Maintainers) in order to be able to help.
WDYT ?
Being a Debian Maintainer is really a simple task. Basically, it just
boils down to being endorsed/advocated by a DD and waiting 4 days for
no objections.
I'd suggest you to do so.
That being said, if I decide to co-maintain the package, can I
put my
name in the uploaders field and add the DMUA: yes (as I am a DM)? In
Personaly, I have no issue for that, of course. And feel free to
involve
me around bugs seen in Debian for Mondo/Mindi.
Great.
I'm not sure what you mean here. Mondo/mindi is already in a public
repo (http://trac.mondorescue.org/browser/branches/2.2.9).
This is a good thing. I will check it out and compare incremental
changes from 2.2.7 -> 2.2.8 -> 2.2.9.
Have you changed things a lot?
Even my build
system is in a public repo
(http://trac.project-builder.org/browser/projects/mondorescue/
pbconf/branches/2.2.9
e.g. for the upcoming stable version).
Do you think of the specific Debian build files ?
I was proposing maintaining this is a public repository in Debian's
alioth system, but since you already have it hosted somewhere, it
saves us the trouble.
Knowing that my goal is to reduce as much as possible the differences
between upstream and packages. Andree helped me a lot in that
perspective, and his contribution has been very valuable for the
project, as well as for Debian.
Right. Divergence is a root of many evils. Carrying patches specific
to a given distribution is a PITA, IMVHO.
What do you think? I would also be willing to spread the word so
that
we can get some more contributions (and/or users).
Yes ! Yes !!
Well, I'm getting Alexandre involved here for the moment. I think
that we can advertise mondo on debian-user and Ubuntu communities.
Once it's ready, we can at least announce on our ML that we have
another
DD with Andree working on the packaging. I'll let you do the same
on the
Debian side.
Nice. Just for your knowlege, I have the following things in mind
(please let me know which ones are already implemented, if they are):
* include support for PowerPC (at least, NewWorld powermacs),
Debian kFreeBSD i386, and kFreeBSD amd64. This should be a little
easier now, since we are soon getting to use GRUB 2, which is going
to deprecate GRUB-legacy in the near future and provide a uniform
platform for booting with many arches.
* support lzma as a compression method and, in fact, generalize so
that we can allow the user some arbitrary compression methods.
* include support for burning CDs with dao instead of the tao
method (this is a bug that I filed on Debian quite some time ago).
* abstract the way that support for initramfs/initrd is checked, as
not all kernels can be verified that way. Ultimately, trust the user,
following the good old tradition of giving him enough rope to hang
himself.
* refactor the code so that we get less code duplication.
* refactor the code so that we can include more things in the
libmondo thing, proper for abstracting things that would be better
adapted for new platforms.
* run dynamic analysis tools such as valgrind on the binaries (the
last thing that we want is a backup program failing in an emergency
situation of restore).
* run static analysis tools such as splint on the source code.
* compile the code with -Wall -Wextra -Werror -Os -g and fix the
warnings. Making all warnings explicit usually exposes bad coding
practices.
* get busybox-mind merged upstream as much as possible (ideally, we
would not have to have busybox-mindi used by the mondo/mindi).
* audit the code so that suspect things can be eliminated (say,
magic constants should have a name stating their purpose).
* cleaning the logs a little bit.
* write the documentation in a format that is less painful than
plain *roff. My proposal: generate the manpages from Perl's POD, as
it is easier to understand since it is closer to plain text than the
*roff formats).
* take care of the coding standards.
* make some releases that consist only of stabilization changes,
without adding any features.
* make the Debian package depend on less tools and recommend them
instead (APT/aptitude already install recommends automatically, but
the experienced system administrator should have control of what gets
installed on his system).
Happy to see continuous interest from Debian to our project !
Sure, it is a highly useful (pair of) program(s). And has saved me
once, due to my daily backup paranoia. :-)
Regards, Rogério Brito.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
