[arc-discuss] [osol-discuss] Project planning and ARC/no-ARC integration (was "was Alpine, now Exim...")

[Dennis Clarke]

On Mon, May 5, 2008 at 5:02 PM, Mark Martin <storycrafter at gmail.com> wrote:
> (forking to ARC-discuss)
>
> On Mon, May 5, 2008 at 11:22 AM, James Carlson <james.d.carlson at sun.com>
> wrote:
> >
> > Alan DuBoff writes:
> > > On Mon, 5 May 2008, James Carlson wrote:
> > >
> > > > In this case, no extra repository would have helped.
> > >
> > > It would have helped me. As it is, I had to go out, get the sources,
> > > compile them and it didn't compile the first time straight out of the
> > > tarball, I had to try a few different options.
> >
> > How would you be more helped by an external repository that doesn't
> > have Alpine in it than an internal repository that doesn't have Alpine
> > in it?
> >
>
> I'll let Alan answer that definitively, of course, but I took it to mean
> had/were an external repository been available, an external contributor
> could have posted the built bits once they'd done the port and build.  I
> don't think he was suggesting that the repository availability was a
> necessary precondition to the build, but rather for the availability.
>
> Regardless, this brings to my mind an issue.  As there was already an ARC
> case open, there are a couple of cases that are possible.
>
> 1) An ARC case is brought for a FOSS item.  It takes forever (or never?) to
> complete.
>
> 2) An ARC case is brought for a FOSS item and has Big Rules integration.  It
> takes forever to complete.
>
> 3) A project is secretly started behind SWAN that intends to follow #1 or
> #2, but no announcement is made and no-one externally is aware of it.  If
> future ARC policy indicates that it's not a Big Rules integration, the
> project team may not even intend to bring the project for ARC review.
>
> In either case, a consumer/contributor may not want to wait, or if #3, may
> not even know a project is already underway.  They may want to do as Alan
> did, and port/build themselves.   What do they do with the resulting
> package?  What happens when any of the 3 previous cases complete (possibly
> creating duplicate packages with incompatible integration/ARC expectation
> levels)?  How can we prevent duplicate efforts?
>
> As for the first two cases, theoretically I suppose, you contact the
> original submitters and check status. If the answer is "Real Soon Now", do
> you just have to wait, or can you say, I can port that FOSS in 2 notes and
> go ahead and put it in the unstable repo?
>
> For the 3rd case, I suppose you can simply announce your intention to port
> FOSS project Y on some list and if no one responds in a timely manner,
> proceed as the singular trailblazer and again, put it into unstable (or if
> intending Big Rules integration, see #1 or #2).
>
> I have heard mention of a big list of FOSS Wants. Is this published
> somewhere?  If there is a big pipeline of FOSS stuff being targeted,
> shouldn't we be aligning that with the evolving ARC vs. FOSS integration
> effort?  I know I've done a fair share of FOSS ports some years ago for my
> own personal pet projects (I even attempted, once, to try getting one of
> them into Blastwave and never followed through).  I personally feel the
> barrier for publishing and then maintaining the port may be more challenging
> than the port itself -- especially if I had an "itch to scratch" and even
> went so far as to want to do Big Rules integration.
>
> What's the expectation for a "contributor" (grant or no) who wants to
> scratch an itch and then make it available for others via a
> Use-This-if-You-Dare repository?
>
> Mark

It can sometimes be very difficult to herd cats in any given
direction. I think there was once an EDS commercial to that effect
years ago and it played on a superbowl time slot. Thank you for being
outspoken here and just laying your thoughts out.  You are talking
about cat herding I think.

I can tell you this, often times a software package gets ported
because someone somewhere needs it and so they do it themselves in
their spare time. Then they figure someone should post it somewhere
because someone needs it. Next thing you know you have a repo and
build center like Blastwave with a pile of software that needs to be
vetted for basic functionality testing and then bug reports and then
eventually a quarterly stable release. All of that requires resources
and money and people to dedicate their time to it as if it were their
baby. Diapers and all. I stand guilty as charged and I do what I can.
We have a new day here in front of us in some respects but with the
same old problems we have had for years. You can not get around FOSS
stuff needs to get done and someone somewhere needs to do the work.

For example, someone needed to mount a NTFS filesystem yesterday or
the day before so I ported the mount_ntfs app and built it with Studio
compilers and cleaned up some of the code.  Next thing ya know we have
mount_ntfs SVR4 packages in the Blastwave test cess at :

    http://www.blastwave.org/testing/index_cron.html

Looks like we have five more apps there since yesterday afternoon.

That is how it happens. The cats need software and so they login and
they do what they need to do and crank out a package and it drops into
the test cess pool as I lovingly call it. Some things die there and
most things move onwards past initial phase one basic tests. Months
later the packages gets integrated into the stable release.  The
community feeds its own needs if we give them the ability to do so and
a venue to move forwards.

Just a comment from someone that has some experience with this sort of thing.

Dennis