[users] MailScanner in rpmforge?

[Dag Wieers]

On Mon, 10 Dec 2007, Hugo van der Kooij wrote:

> Karanbir Singh wrote:
> > Hugo van der Kooij wrote:
> >>>> So let me simplify the question.  If I pick up the gauntlet the coming
> >>>> week and produce a SPEC file that will fit with the ones on rpmforge.
> >>>> Will it be added to rpmforge?
> >>> I am happy to work with you on this issue if you like.
> >>
> >> The plan is currently that Jules will run a minimal repository.
> >
> > So, is there a reason why he wants to run his own repo and not have
> > MailScanner included in rpmforge / rpmrepo ?
>
> Well. The topic has been here for a number of months. Jules clearly
> indicated he had no objections to include MailScanner into rpmforge.
>
> But the few requests I placed to learn how I should get MailScanner in
> rpmforge were simply never answered.

Few things you need to know:

 - RPMforge is waiting for the rpmrepo to take off so we don't want to
   add too many people (maintaining single packages) to our commiters
   list. In fact I am not that much interested in having lots of packages
   maintaining a single package. We cannot manage that currently. Also
   because we do not do fine-grained access control.

 - MailScanner seems overly complex in its dependencies. perl programs
   with lots of requirements are very problematic anyway because 2 perl
   programs with specific dependencies could void compatibility.

 - I cannot accept the submission myself because I know too little about
   MailScanner and I find it too risky to add it without understanding the
   complications. (Your mail only makes that more obvious)

 - Likely none of the other svn commiters are interested in MailScanner
   for the same reasons ?

Besides that, I am very wary of taking on more work because I have less
and less free time myself to spend on the project.


> How long does one have to wait to get an answer to a simple question? So
> I took the time to make sure one can install MailScanner through yum
> without waiting any longer for a reply from rpmforge by setting up a
> small repository.

It is not a simple question. You have all the right to create your own
repository.


> BTW: The perl-MIME-Tools package seems to be broken. I need to
> investigate the details a bit more before I can comment.

You see how very complicated MailScanner can make RPMforge. We can only
know if it breaks something when everything gets tested before released
and without a testing repository it is even hard to test it. We are
waiting for the rpmrepo initiative to move forward so things can be
discussed there. (I don't want to go and add a testing repo in RPMforge if
it ceases to exist in eg. 6 months time)


> The perl-MailTools package was updated from 1.77 to 2.02 but it seems
> the changes in 2.02 made it incompatible with the previous version so
> people may get hurt if they upgrade to version 2.02

Another reason why MailScanner makes our lifes harder instead of easier ?


> These concerns also come into play when one has to considere wether or
> not rpmforge is ready for MailScanner.

Exactly !


> PS: You are aware I have not seen anything on the Sparc front either?

Right. My opinion is that there are too many roadblocks for people to
become effective within CentOS. I would prefer if we could give people
more easily responsibilities so that they can progress and see what
happens.

I would be very happy to be able to say to you:

  Hugo, you are now in charge of getting everyone interested in a Sparc
  release together, organise the troops, plan the whole thing and execute.
  And if you have any needs, let us know and we will help you.

However, I have no authority to do so, and I do not know who has :) I
think we need to work on that. My believe is that SIGs are a solution to
this problem.

If you want RPMforge packages for Sparc however, I do have that authority
like for the PPC RPMforge build we are doing this right now. If other
people want to commit to something for RPMforge, let me know. For a single
package that is hard, but for a complete platform or for leading in the
kernel module packaging, perl packaging, games, kde, or anything else we
can support you in making yourself effective.


-- 
--   dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
[Any errors in spelling, tact or fact are transmission errors]