SourceForge for RT add-ons?

RT Developers
1

Hi all,

What about opening a new SF.net project, “rt-addons” ?

During my development of rtimportldap, I sent several
updates to the lists, which is not nice, I don’t like to flood the
people’s mailboxes. Now, thanks to Andreas Hofmeister,
there’s another update coming up, with more group synchronization
options. Thus, this small project needs a kind of collaborative
development environment, and SF.net seems to be the ideal place for this.

On the other hand, it wouldn’t be nice to create a separate SF project
just for this import utility.

If the community (and Jesse first of all) is not against this,
I can organize the project at SF, think about the directory structure,
etc., and then give Jesse (and/or someone else) the administrative rights.

With regards,
Stan

2

Hi all,

What about opening a new SF.net project, “rt-addons” ?

I sort of have a bias against sourceforge. What about creating a new RT
queue at fsck.com for tracking contributed addons that I haven’t yet
manually added to contrib? Would that satisfy the need you have?

Best,
Jesse

»|« Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.

3

What about opening a new SF.net project, “rt-addons” ?

I sort of have a bias against sourceforge. What about creating a new RT
queue at fsck.com for tracking contributed addons that I haven’t yet
manually added to contrib? Would that satisfy the need you have?

And/Or, (multiple) someone else(s) add stuff to contrib.

                         Bruce Campbell                            RIPE
               Systems/Network Engineer                             NCC
             www.ripe.net - PGP562C8B1B             Operations/Security
4

What about opening a new SF.net project, “rt-addons” ?

I sort of have a bias against sourceforge.

well, you weren’t sure about autoconf, and now we use it…
There are good things about SF, and it doesn’t mean there’s no
other solution:

– multiple developers with CVS write access
– public CVS repository
– file distribution system
– bug tracking (well, we all know a better way for doing this)
– zero cost of ownership
– documentation management

There are nice projects which feel fine at SF, with dozens of developers
on the list.

What are you afraid of with SF? even if you loose control due
to some politic changes at SF, you still have your CVS tarball backup.
And since there seem to be big companies interested,
SF will last for long time.

What about creating a new RT
queue at fsck.com for tracking contributed addons that I haven’t yet
manually added to contrib? Would that satisfy the need you have?

that would be nice for a start.

Regards,
Stan.

5

Stanislav Sinyagin ssinyagin@yahoo.com writes:

well, you weren’t sure about autoconf, and now we use it…
There are good things about SF, and it doesn’t mean there’s no
other solution:

Sourceforge has migrated from free to proprietary software for
implementing the service. That’s a bad advertisement for the free
software commutiy.

Florian Weimer Weimer@CERT.Uni-Stuttgart.DE
University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT fax +49-711-685-5898

6

Sourceforge has migrated from free to proprietary software for
implementing the service. That’s a bad advertisement for the free
software commutiy.

I don’t see any bad in that. They did this more than a year ago, and
still they are the central point for freeware.
They needed a more profitable business model, and they built it.
Still with losses (see their fiscal year 2003 results),
but the situation is much better than a year ago.
I believe it would be better for everyone when SF is driven
by a stable and solid company, not about to crash tomorrow.

Well, there are many alternatives to SF: Savannah is one of them,
http://cbbrowne.com/info/lsfmandate.html gives a few more.

At last, we can leave everything as it is. I just thought a public SF-alike
collaborative place for RT-addons would give only benefits to RT.

Regards,
Stanislav

7
  • Jesse Vincent jesse@bestpractical.com [2002-12-28 12:38]:> On Sat, Dec 28, 2002 at 06:36:17AM -0800, Stanislav Sinyagin wrote:

Hi all,

What about opening a new SF.net project, “rt-addons” ?

I sort of have a bias against sourceforge. What about creating a new RT
queue at fsck.com for tracking contributed addons that I haven’t yet
manually added to contrib? Would that satisfy the need you have?

savannah.gnu.org is a great alternative to sourceforge; it runs a hacked
version of the alexandria software, but (obviously) on free software.

(darren)

Never attribute to malice that which is adequately explained by
incompetence.
– Napolean Bonaparte

8

What about opening a new SF.net project, “rt-addons” ?

I think this is a good idea.

During my development of rtimportldap, I sent several updates to the
lists, which is not nice, I don’t like to flood the people’s
mailboxes. Now, thanks to Andreas Hofmeister, there’s another update
coming up, with more group synchronization options. Thus, this small
project needs a kind of collaborative development environment, and
SF.net seems to be the ideal place for this.

I have a few modules in the RTx:: namespace (named similarly to DBIx::slight_smile:
that provide convenient wrappers around many of the things in RT::
modules, and have a number more planned. I would be happy to move
development to another system, especially if there is the potential for
feedback and contributions.

I would like to see a section with examples on how people have
integrated RT into other systems, such as IRC or CVS. Examples of how
people have set up their mail servers to integrate with RT would also be
useful.

On the other hand, it wouldn’t be nice to create a separate SF project
just for this import utility.

Agreed – it’s too special purpose.

If the community (and Jesse first of all) is not against this, I can
organize the project at SF, think about the directory structure, etc.,
and then give Jesse (and/or someone else) the administrative rights.

I think the biggest problem is going to be finding people to administer
the project – it would be unfair to Jesse to simply assume that he will
be doing it. If something like this does get set up, I will be happy to
help administer it, or do whatever I can to help.

(darren)

It has long been an axiom of mine that the little things are
infinitely the most important.
– Arthur Conan Coyle

9

Hi Darren and all,

What about opening a new SF.net project, “rt-addons” ?

I think this is a good idea.

ok, let’s choose the platform.
I’d vote for SF.net in favor to savannah, because of the reasons:

– SF is driven by a company which put its whole business model
into the project. There’s big money, hence more stability.

– Savannah is driven by (slightly marginal) enthusiasts,
on a relatively small server. Hence, less stability, regardless of
the FSF philosophy.

– Savannah supports SSH1 protocol only, and also I suspect less
functionality (I didn’t compare this yet) than SF.

I think the biggest problem is going to be finding people to administer
the project – it would be unfair to Jesse to simply assume that he will
be doing it. If something like this does get set up, I will be happy to
help administer it, or do whatever I can to help.

I’m ready for this. I’ve been administering two active and another couple
of inactive project at SF, so this would be quite easy for me.
Of course, any help is appreciated. Especially on the starting stage,
when we have to define the directory structure.

Question to Jesse: does this need a separate mailing list, or rt-devel
is enough?

BTW, rtimportldap gained another spin last Sunday, so it really needs
a place like the above.

Cheers,
Stan

10

What about opening a new SF.net project, “rt-addons” ?
I think this is a good idea.
ok, let’s choose the platform.
I’d vote for SF.net in favor to savannah, because of the reasons:

Hrm. Just to forstall anyone getting too far ahead of themselves, I’ve
started the process of creating ‘rt-addons’ on Source Forge.

Its prime purpose, at the moment, is to provide pointers between people
searching SF for ‘RT’ (etc), and the RT contrib site.

Regards,

                         Bruce Campbell                            RIPE
               Systems/Network Engineer                             NCC
             www.ripe.net - PGP562C8B1B             Operations/Security
11

What about opening a new SF.net project, “rt-addons” ?
I think this is a good idea.
ok, let’s choose the platform.
I’d vote for SF.net in favor to savannah, because of the reasons:

Hrm. Just to forstall anyone getting too far ahead of themselves, I’ve
started the process of creating ‘rt-addons’ on Source Forge.

Nice.

Its prime purpose, at the moment, is to provide pointers between people
searching SF for ‘RT’ (etc), and the RT contrib site.

This is a really good idea – even if we do end up putting the stuff on
savannah, or anywhere else, getting search results for RT on sourceforge
can only help us.

(darren)

All things are possible, except for skiing through a revolving door.

12

What about opening a new SF.net project, “rt-addons” ?

I think this is a good idea.

ok, let’s choose the platform.
I’d vote for SF.net in favor to savannah, because of the reasons:

– SF is driven by a company which put its whole business model
into the project. There’s big money, hence more stability.

– Savannah is driven by (slightly marginal) enthusiasts,
on a relatively small server. Hence, less stability, regardless of
the FSF philosophy.

– Savannah supports SSH1 protocol only, and also I suspect less
functionality (I didn’t compare this yet) than SF.

The lack of ssh2 doesn’t bother me (all the hosts I use are basically
ssh1 only), and I haven’t explored savannah with an eye towards what is
missing, though nothing stood out as obviously missing.

The fact that there’s a company behind SF is kind of immaterial to me –
I know that the FSF will be around for a long time, most likely much
longer than SF.

The size of the SF system vs the savannah system, however, is
significant, and I agree with you on that point.

Jesse’s objection (SF uses non-free software) still stands, and is not
insignificant, though I personally use SF very often.

All things considered, I will vote for hosting the project on
sourceforge. I can be contacted offlist for details about my SF
username and such.

I think the biggest problem is going to be finding people to
administer the project – it would be unfair to Jesse to simply
assume that he will be doing it. If something like this does get
set up, I will be happy to help administer it, or do whatever I can
to help.

I’m ready for this. I’ve been administering two active and another
couple of inactive project at SF, so this would be quite easy for me.

Same here – I have several SF projects under my sway (some active, some
not so much), so I am willing and able to Do Stuff.

Question to Jesse: does this need a separate mailing list, or rt-devel
is enough?

Since rt-addons are not supported by Best Practical, it seems that a
separate list would be useful. Some addons might warrant their own
lists (i.e., the stats package), and I would definitely like to see a
list dedicated to CVS commit messages, which shouldn’t go to rt-devel
(too special-purpose, doesn’t need to be archived).

(darren)

People who sacrifice beauty for efficiency get what they deserve.
– Tom Robbins

13

Hrm. Just to forstall anyone getting too far ahead of themselves, I’ve
started the process of creating ‘rt-addons’ on Source Forge.

fine, here’s the proposal of CVS directory structure:

htdocs/
rt2-addons/
utils/
ScripActions/
ScripConditions/
…
rt3-addons/

14

Hrm. Just to forstall anyone getting too far ahead of themselves, I’ve
started the process of creating ‘rt-addons’ on Source Forge.

fine, here’s the proposal of CVS directory structure:

htdocs/
rt2-addons/
utils/
ScripActions/
ScripConditions/
…
rt3-addons/

I had a feeling that perhaps the addons themselves should be the
top-level modules:

htdocs/
addons/
AutoAssign/
rt2/
rt3/
AutoReplySquelch/
rt2/
rt3/
GroupService/
rt2/
rt3/
Keywords/
rt2/
rt3/
LDAPTicket/
rt2/
rt3/
…

And so on (I’m using names from
http://www.fsck.com/pub/rt/contrib/2.0/ right now), and then each
module could have a 2.0 and 3.0 directory, and possibly a 1.0 directory.
Or, different versions could be CVS branches within the repository. I
think it might be a mistake to include implementation details such as
version number in the top level of the CVS repository.

Most people who are, or will be, looking through the add-ons aren’t going
to be thinking in terms of “I have RT 2.0.15, what can I download?”, but
rather: “I need to integrate LDAP with RT; let’s see what’s available.”
I realize that the current contrib section is set up by version, but the
URL that is distributed for contribs is
http://www.fsck.com/pub/rt/contrib/2.0/, which leads you a listing of
what’s available.

Thoughts?

(darren)

M-x global-thermonuclear-warfare

15

This is a really good idea – even if we do end up putting the stuff on
savannah, or anywhere else, getting search results for RT on sourceforge
can only help us.

except that “rt” is too short a string to search for, and freshmeat is
a better place if you just want a listing.

seph

16

htdocs/
addons/
AutoAssign/
rt2/
rt3/
AutoReplySquelch/
rt2/
rt3/

this sounds reasonable.

In addition, I could make the autoconf/automake packaging
for the utilities which need some path to install and
need RT paths for library inclusion.

We can package all the utilities into one package, say,
rt-addon-utils.2.0.XX.tar.gz, where 2.0 corresponds to
RT’s version, and XX is local release numbering.
The package would contain ./configure and “make install”,
with default installation path, say, /usr/local/rt-addons/bin,
and ./configure would search for RT in some well-known places,
like /usr/local/rt* or /opt/rt*, with the option --with-rt=path

Thus we avoid two traps:

– manualy editing the Perl and RT paths when installing the new utility
– figuring out where to put those files.

And, of course, people will still be free to download indivifual
files and install them manually.

The CVS path for this would be /addons/utils

Happy New Year, by the way…

Stan

17

Hrm. Just to forstall anyone getting too far ahead of themselves, I’ve
started the process of creating ‘rt-addons’ on Source Forge.

fine, here’s the proposal of CVS directory structure:

Part of what I’m intending to do with the SF project is to have a similar
layout to what (I feel) should be in the 3.0 contrib. Hence, version
numbers won’t be in the path.

Hence, a simplistic layout would be:

Actions			# ScripActions
Authentication		# added based on the ldap references since
CLI			# CLI utils
Conditions (Scrip)	# ScripConditions
Conversion		# added based on questions re import utils
Core			# Mods to RT Core
Doc			# added; link to RT/FM
Other			# No category known
Packages		# eg, Stats package
Web			# Web page presentation.

And the index.html of each being a collection of current contribs.

And so on (I’m using names from
http://www.fsck.com/pub/rt/contrib/2.0/ right now), and then each
module could have a 2.0 and 3.0 directory, and possibly a 1.0 directory.
Or, different versions could be CVS branches within the repository. I

The repository as such would be just web pages. The distribution files
would be still hosted at www.fsck.com .

                         Bruce Campbell                            RIPE
               Systems/Network Engineer                             NCC
             www.ripe.net - PGP562C8B1B             Operations/Security
18

Part of what I’m intending to do with the SF project is to have a similar
layout to what (I feel) should be in the 3.0 contrib. Hence, version
numbers won’t be in the path.

Hence, a simplistic layout would be:

  Actions                 # ScripActions
  Authentication          # added based on the ldap references since
  CLI                     # CLI utils
  Conditions (Scrip)      # ScripConditions
  Conversion              # added based on questions re import utils
  Core                    # Mods to RT Core
  Doc                     # added; link to RT/FM
  Other                   # No category known
  Packages                # eg, Stats package
  Web                     # Web page presentation.

And the index.html of each being a collection of current contribs.

This is reasonable.

The repository as such would be just web pages. The distribution files
would be still hosted at www.fsck.com .

The problem with that, which is one of the reasons a different server
was suggested (I believe), is that it isn’t “self service”, from the
point of view of the developer of each contrib – everything blocks on
Jesse (or whomever has write access to the appropriate directory on
fsck.com) getting the time to put it up there. With a CVS repository,
developers can commit on their own schedule; only a Release Technician
can make a release, so there can still be some control by an admin over
what gets officially “blessed” as part of the contribs.

(darren)

Your freedom to swing your fist ends at the tip of my nose.
– Larry Niven

19

The problem with that, which is one of the reasons a different server
was suggested (I believe), is that it isn’t “self service”, from the
point of view of the developer of each contrib – everything blocks on
Jesse (or whomever has write access to the appropriate directory on
fsck.com) getting the time to put it up there. With a CVS repository,
developers can commit on their own schedule; only a Release Technician
can make a release, so there can still be some control by an admin over
what gets officially “blessed” as part of the contribs.

What we’re currently working on:

* Publically readable contrib cvs hosted by Best Practical.
* A set of volunteers who have commit access
* A publically visible queue for 2.0 contributions, one ticket
  per addon
* A publically visible queue for 3.0 contributions

Over time, we'll work on UI for the rt queues to make them nice
and pretty. It _may_ be the case that we discover over time that
we don't really need the CVS in addition to the queues, but it
makes sense to me to try it for now.


It's my intent that any third party developer should be able to
submit "Contrib" items.  I believe that, "Blessing" some and not 
others defeats the purpose. I haven't yet "rejected" anything
from the contrib directories, it's more that I've been lame
about copying the files out of mail and into place.

I can't set all this up today, as 100 people are arriving at my
house in just over 3 hours, but the mechanics should be in place
in the next few days.


Best,
Jesse

»|« Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.