Re: DEB packaging request
I think I probably just didn't explain this very well ;-) You have to
forgive me, over at tux4kids we've been discussing this group thing for
months, so it can be more difficult to explain when its been discussed so
heavily for some time now.
Truthfully, this is not something that is a huge commitment. It doesn't
require that we have one person packaging up /all/ of our projects. As a
matter of fact, the impetus for this is to move away from such an
arrangement. The intent is to make it easier to divide up workload, lower
how much e-mail traffic packagers must wade through to find items relavent
to them, and to prevent redundancy.
On Mon, 10 Jun 2002, Ben Armstrong wrote:
> For existing Debian developers, what particular benefit to them is there to
> doing that? I see how it suits your needs nicely, but not the individual
> Debian developer, keen on packaging maybe just one of your packages for
> Debian.
Well, it actually does two things: 1) It gives people interested in
packaging/porting a project a common place to receive release
announcements (on a lower traffic list) 2) It exposes packagers to other
similar projects we produce that they might be interested in, yet would
probably never find out about on a dedicated sub-project's list.
Remember, everything's optional. If someone /wants/ to help out with a
particular project, they can. If someone wants to just package up tuxmath
for their platform (eg Debian) and that's the only package they're
interested in, that's fine. But then when we spend months between
releases talking largely about management changes and unicode support (as
was the recent case in tuxtype) they don't have to be lurking on the dev
list, getting their mailbox filled with messages they may not care about.
> Of course, being made aware in a timely fashion of new releases would be a
> good thing, but isn't that what -announce lists are for? Or is it
> anticipation of a new release so you can do a simultaneous release of the
> Debian package with a new release of your material that you're aiming at?
No, it's not necessary to have all packages ready for each release.
Naturally, that would be nice (you know, to have it make it's way into
unstable for example), but that's not necessary.
Also, we will be strictly enforcing giving the release management group
plenty of notice prior to a release. Right now, I'm leaning towards a 1-2
week minimum.
> Then I suggest a -devel-announce list per package with posts like "Foo beta3
> ready for testing", "Final release of Foo, next Friday, assuming all goes
> well". This keeps the traffic focused specifically on the particular
> package(s) the Debian (or other distro) maintainers would be interested in.
It's been my experience that such lists either 1) get abused by the
maintainer, or 2) go largely un-used (eg, no subscribers).
Besides, for some people who all they want to do is package and port, this
means they're subscribed to several "announce" lists. Also, since these
announce lists are usually read-only, this also means there can be no
discussion/notification of who's doing what- which can result in a lot of
redundancy (as an example, for the longest time we had two people
independently working on valid RH 6.x RPMs for tuxtype, each with their
own changelogs and dependancies).
If you think about it, then all this central Release Management group list
is, is a common -devel-announce list for all Tux4kids project that is
geared specifically towards those people interested in packaging some of
our sub-projects. But because the list is owned by a central group, we can
prevent abuse, and keep things very much on-topic.
> > The intent is to shield the packagers from the project development (except
> > when they have bugs to report upstream), keeping them on a relatively
> > low-traffic list, and allowing them to package for more than one project.
>
> A noble intent, but falls short of the mark if you have a DD interested only
> in a single package, and not necessarily everything your project does.
True. But this is why I came to Debian Jr. All of our current projects are
geared towards children and education. We currently have two that are
actively developed, one that is sleeping (because I'm in charge of it
and I've been too busy for it) and at least 3 more that are in early
stages of development. Of these, only one is included in Debian Jr.
Since we are both working towards the same goal, we're just trying to make
it easier for us to work together.
> Sure, my question is simply why you don't say "hey, we have this and that
> package here, would someone please package them for Debian Jr.?" which is
> best done as an RFP wishlist bug against the wnpp (see
> http://www.debian.org/devel/wnpp). That's the usual way of going about
> having something added to Debian.
Okay, then perhaps instead we should have a liason on this Release
Management list who, when a project that does not have a Debian package
has a new release, goes and submist an RFP wishlist bug.
We're open to suggestions. This is really a new thing we're trying, and
we're just trying to figure out the best way to go about it.
> When I received this message today and
> looked it over I thought "woah, a bit more commitment than I'm ready for".
> Maybe it's just the way you've worded it that made it strike me this way and
> in reality it's no big deal at all. But perhaps if you had said "anyone
> interested in packaging X, Y, or Z? and btw, if you are, it would be nice if
> you joined this low-traffic list so we can keep you informed about upcoming
> releases" it wouldn't seem quite such a responsibility to participate.
Okay, I get that. I think the reason I approached it this way was because
I am coming at this from a project manager point of view.
One of the biggest problems when you're an open-source manager is getting
people who can to consistantly port/package your application for
architectures you cannot. I've had many people help out over the years,
and whenever a particular packager leaves and is replaced by a new one,
there is always a learning curve for them to get up to speed on the
project.
Our intention with these groups (and, while this is the result of several
months of discussion, we're only now putting it into practice, so we're
yet to see how well it really works ;-) is to reduce the learning curve,
and let people interested be able to focus on what they're good at.
Truthfully, this release management group really wont be as much of a
commitment as I may have made it seem (sorry if I did, BTW ;-) As I said,
you can just think of this list as a special tux4kids-wide
announcement list for people interested in packaging up our projects. It
really would be low-traffic (basically, it would be dead except for
small bursts of activity surrounding a release).
> > we're in charge of just to do this. Besides, the intention of this "Group"
> > infrastructure is to more equally divide up responsibilities, and
> > -hopefully- make our projects easier to manage ;-)
>
> But wouldn't much of the list traffic (since you mention ports for other
> platforms) of little or no interest to a maintainer only interested in
> packaging one of your packages?
Yes, but it should be considerably less than if they were on the main dev
list. All you have to do is look at the tuxtype dev list for the last
several months. The list has been fairly active, but all we've been
talking about is internationalization, font, and managenent (new project
manager) issues.
Plus, it would open up people to our other projects, and possibly get them
interested in them as well.
> Nevertheless, if someone here wishes to join this group, far be it from me
> to dissuade you. I'm merely trying to anticipate potential problems with
> your request, in case you find that Debian participation isn't what you had
> hoped it would be. Perhaps I'm totally off the mark about this, and if so,
> I apologize. It's just how it struck me.
I'm sorry it struck you that way, and I appreciate the comments. I'm
usually not the best at explaining things, but I am the project manager
over there, so it usually falls on my shoulders anyway :-/
I hope I've cleared things up, and been able to express that it's really
not as much of a commitment as you interpreted it was. It's really
intended to make packagers live's easier, not more complicated/difficult.
--
Sam Hart
University/Work addr. <hart@physics.arizona.edu>
Personal addr. <criswell@geekcomix.com>
--
To UNSUBSCRIBE, email to debian-jr-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: