Re: DEB packaging request
On Tue, Jun 11, 2002 at 08:12:36AM -0700, Sam Hart wrote:
> 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.
Sure, the closer you are to a problem, the harder it is to see it from the
point of view of someone not familiar with the details.
> 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.
Sounds good. Of course, the WNPP system handles the "prevent redundancy"
aspect on the Debian end of things (although not foolproof, as people can
ITP things under different package names, miss an outstanding ITP, etc.)
But staying informed about new things to package is a good thing. I think
I'd like to participate for that reason.
> 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.
Makes sense. If you're out shopping for new packages, I can see the benefit
here. And I'm always shopping for new packages (often just relaying my
thoughts to the list to see if someone else will pick up the package).
> 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.
So the tuxmath person may or may not want to be on this list, and it doesn't
make a big difference to you?
> 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.
I think it's really slick when we're able to do that. I do nearly
simultaneous releases with xpilot upstream due to my close "group"
relationship with them (I'm in a bit deeper than with your release
management group, doing actual upstream development as well).
> 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.
Great.
> It's been my experience that such lists either 1) get abused by the
> maintainer, or 2) go largely un-used (eg, no subscribers).
Fair enough.
> 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).
Also true.
> 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.
OK. I can see you have thought this out. I just wanted to be sure I
understood why you lumped everything together into one list.
> 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.
Yes, it does seem that communication is lacking here.
> Since we are both working towards the same goal, we're just trying to make
> it easier for us to work together.
I'd like that.
> 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.
That seems inescapably to be me. :)
> 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.
Sure. Sign me up.
> 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.
That's how it appeared to me. I didn't think it was a bad idea, just
something needing correction of focus.
> 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.
Well, I can help provide some continuity to the Tux4kids + Debian Jr.
relationship. I guess the biggest problem I face is that things can quickly
fall out of date because there are just too many packages to keep track of.
When I look at it that way, it certainly would be easier for me to be on one
list covering several of your packages rather than several different
single-package lists.
> 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.
I hope it works out.
> 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).
I'm not sure you made it out to be. I think it's just me thinking "Oh no,
not another list. Do I really want/need to join this?" But your elaboration
on the benefits is really quite compelling, so I think I'll enjoy being a
part of the group. Participation as a liaison does mesh with my goals for
the Debian Jr. project.
> 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 :-/
Apology not necessary. There is hardly a stronger force in the universe than
the avoidance of unnecessary work. I'm perfectly reassured now that we'll
mutually benefit from me being on your list. :)
> 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.
Yup. See you on the list. You can subscribe me as
"Ben Armstrong"<synrg@sanctuary.nslug.ns.ca> or point me at instructions
for subscribing myself.
Regards,
Ben
--
nSLUG http://www.nslug.ns.ca synrg@sanctuary.nslug.ns.ca
Debian http://www.debian.org synrg@debian.org
[ pgp key fingerprint = 7F DA 09 4B BA 2C 0D E0 1B B1 31 ED C6 A9 39 4F ]
[ gpg key fingerprint = 395C F3A4 35D3 D247 1387 2D9E 5A94 F3CA 0B27 13C8 ]
--
To UNSUBSCRIBE, email to debian-jr-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: