[sldev] Fresh new code: eventlet and mulib

Kamilion kamilion at gmail.com
Wed Aug 29 11:14:22 PDT 2007


I second this idea.

Actually, would it be possible to generate the tree the way the LL
internal repo´s set up? I´m betting you guys are going to slowly
trickle other bits of code like this, and it would probably be a lot
easier for the LL devs to keep track of a single tree structure of
projects, and easier for us to keep up with it.
Just my 2 cents...


-- Kamilion Schnook, On vacation in puerto vallerta...






On 8/28/07, Andre Roche <roamingryozu at gmail.com> wrote:
> Would a "Libraries" project with "EVT" "MULIB" or other such libraries as
> components work alright?
>
> On 8/28/07, Rob Lanphier <robla at lindenlab.com> wrote:
> > On 8/28/07 4:27 PM, aric rubin wrote:
> > > Jumping in if I may, I'd suggest that the benefits of keeping all
> > > issues in one place (pjira) far outweigh the difficulties of the use
> > > of the application. I strongly recommend simply staying with pjira for
> > > bug tracking. It'll save us all cycles and pain in the long run.
> >
> > I have to agree, but perhaps for slightly different reasons.  We don't
> > have a great way of doing scalable account management for Trac.  We're
> > currently doing svn/Trac access as a one-off, since I'm imagining less
> > than a hundred accounts there, but we're not set up to create accounts
> > for every person who might want to report a bug in eventlet and/or mulib.
> >
> > We can possibly create a different project(s) in JIRA for these
> > libraries, and should strongly consider it (e.g. "EVT" and "MULIB")
> >
> > I suppose that it's going to create a strange situation where someone
> > using eventlet who isn't using Second Life will still need a Second Life
> > account just to file bugs against it.  However, that seems like a better
> > situation to me than having to personally create accounts for each new
> > eventlet user.
> >
> > Rob
>
> If an account has to be made somewhere, at least an SL account is free, and
> potentially gives them a collaboration space to talk to other users of
> similar interests.
>
> > Ryan Williams (Which) wrote:
> > >> I asked some questions in the previous email, but I don't think they
> > >> were very well communicated because no one responded, let's try again.
> > >>
> > >> The main question is: how closely do we want to associate eventlet and
> > >> mulib development with viewer development?
> > >>
> > >> --- Should we have a separate mailing list(s) for them?
> > >>   Currently I think "no" because there's no noise problem on sldev, and
> > >> we don't have a community of web devs contributing to eventlet and
> mulib
> > >> but not to the viewer (though I expect/hope this will happen at some
> > >> point).
> > >> --- Should we track bugs in PJIRA, or in Trac?
> > >> --- Should we put the documentation on wiki.sl.com, or in Trac?
> > >>   It's really tempting to make the Trac for each project be the
> one-stop
> > >> shop for all relevant information.  It's how I'd do it if I were
> > >> starting these from scratch.  But we do have all this existing
> > >> infrastructure for bug tracking and documentation.  My inclination is
> to
> > >> continue documenting on wiki.sl.com, because I prefer MediaWiki, and
> > >> track bugs in Trac (because things get too easily lost in JIRA, plus
> > >> it's heck of slow).
> > >>
> > >> Thoughts?
> > >>
> > >> -RYaN
> > >>
> > >> P.S. Sorry there hasn't been more developing on these lately -- I've
> > >> been sick.
> > >> _______________________________________________
> > >> Click here to unsubscribe or manage your list subscription:
> > >>
> /index.html
> > > _______________________________________________
> > > Click here to unsubscribe or manage your list subscription:
> > >
> /index.html
> >
> >
> >
> > _______________________________________________
> > Click here to unsubscribe or manage your list subscription:
> >
> /index.html
> >
> >
> >
>
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>
>


More information about the SLDev mailing list