Fixing maintainer/packager for core ports
Hi, I think the time has come to normalize maintainer/packager information, expecially regarding core ports. As you'll remember, for 2.2 we simply left Per as a maintainer and replaced his email with core-ports at crux dot nu. My proposal: - Keep Per as the packager for inherited core ports, with his personal email. - Use the "real" packager for newer ports (ie udev) - Use "CRUX System Team, core-ports at crux dot nu" for the core ports maintainer field - Use the specific maintainer for core ports that the System Team members are not much interested in due to personal preferences, if any (I'm thinking of ports like xfsprogs) Comments are welcome. Regards, Simone
Simone Rota [2006-12-04 15:20]:
- Keep Per as the packager for inherited core ports, with his personal email.
-1. This will lead to people sending e-mail to Per about stuff that he last touched years ago. Not good IMO.
- Use the "real" packager for newer ports (ie udev)
+1.
- Use "CRUX System Team, core-ports at crux dot nu" for the core ports maintainer field - Use the specific maintainer for core ports that the System Team members are not much interested in due to personal preferences, if any (I'm thinking of ports like xfsprogs)
Okay, but what about e.g. core/bzip2? I adopted it some months ago; are you suggesting to make it owned by "core system team" again? Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
On Mon, Dec 04, 2006 at 06:15:33PM +0100, Tilman Sauerbeck wrote:
- Keep Per as the packager for inherited core ports, with his personal email.
-1.
This will lead to people sending e-mail to Per about stuff that he last touched years ago. Not good IMO.
As you prefer, even I cannot see how this is different from having packager != maintainer everywhere else. I mean, people are supposed to contact the maintainer anyway, not the packager. I'm also fine with core-ports in both fields as a second option, yet it takes some credit away from Per as the original packager.
- Use "CRUX System Team, core-ports at crux dot nu" for the core ports maintainer field - Use the specific maintainer for core ports that the System Team members are not much interested in due to personal preferences, if any (I'm thinking of ports like xfsprogs)
Okay, but what about e.g. core/bzip2? I adopted it some months ago; are you suggesting to make it owned by "core system team" again?
Yes; I thought one of the main tasks of the ST was to be in charge for the core ports, where some additional consistency is needed. The exception above was to offer better support for ports which cannot be reliably tested by the ST (ie if nobody uses xfs) or require some specific knowledge / actual usage (ie exim) Regards, Simone
Simone Rota [2006-12-04 18:43]: Hi, sorry for not responding earlier.
On Mon, Dec 04, 2006 at 06:15:33PM +0100, Tilman Sauerbeck wrote:
- Use "CRUX System Team, core-ports at crux dot nu" for the core ports maintainer field - Use the specific maintainer for core ports that the System Team members are not much interested in due to personal preferences, if any (I'm thinking of ports like xfsprogs)
Okay, but what about e.g. core/bzip2? I adopted it some months ago; are you suggesting to make it owned by "core system team" again?
Yes; I thought one of the main tasks of the ST was to be in charge for the core ports, where some additional consistency is needed. The exception above was to offer better support for ports which cannot be reliably tested by the ST (ie if nobody uses xfs) or require some specific knowledge / actual usage (ie exim)
I wasn't aware of that (didn't we want to define the group's responsibilities and stuff some time?). IMO it's nicer to have a specific maintainer for a port, and use the "ST group" as a fallback if noone cares about a specific port enough to put his name on it. But it's not that I cannot be convinced that your scheme is superior. Maybe it needs some voting though ;) Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
On Fri, Dec 15, 2006 at 02:30:53PM +0100, Tilman Sauerbeck wrote:
Yes; I thought one of the main tasks of the ST was to be in charge for the core ports, where some additional consistency is needed. The exception above was to offer better support for ports which cannot be reliably tested by the ST (ie if nobody uses xfs) or require some specific knowledge / actual usage (ie exim)
I wasn't aware of that (didn't we want to define the group's responsibilities and stuff some time?).
That's how I got it back at the time, but you're right: we have not talked in detail about this yet. I have the feeling that a small system group, say a couple of devs, would be a more efficient solution to take care of the tasks previusly managed by Per.
IMO it's nicer to have a specific maintainer for a port, and use the "ST group" as a fallback if noone cares about a specific port enough to put his name on it.
Heh, exactly the opposite of my idea :)
But it's not that I cannot be convinced that your scheme is superior. Maybe it needs some voting though ;)
Sure, I suggest we discuss this in next tuesday irc meeting: given that X11R72 appears very close to release* I think we really should get rid of our remaining doubts / tasks about CRUX 2.3 Regards, Simone * http://wiki.x.org/wiki/ReleaseSchedule -- Simone Rota Bergamo, Italy - http://www.varlock.com
Simone Rota [2006-12-15 15:02]:
[snip]
But it's not that I cannot be convinced that your scheme is superior. Maybe it needs some voting though ;)
Sure, I suggest we discuss this in next tuesday irc meeting: given
Yes, that would be great.
that X11R72 appears very close to release* I think we really should get rid of our remaining doubts / tasks about CRUX 2.3
Yeah. We finally need to resolve the fonts.dir issue, too (blame me hard on this one). Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
On Fri, 2006-12-15 at 15:12 +0100, Tilman Sauerbeck wrote:
Simone Rota [2006-12-15 15:02]:
[snip]
But it's not that I cannot be convinced that your scheme is superior. Maybe it needs some voting though ;)
Sure, I suggest we discuss this in next tuesday irc meeting: given
Yes, that would be great.
that X11R72 appears very close to release* I think we really should get rid of our remaining doubts / tasks about CRUX 2.3
Yeah. We finally need to resolve the fonts.dir issue, too (blame me hard on this one).
A workaround that would do for 2.3 would be to bundle fonts in packages named by directory, e.g. all font-*-100dpi tarballs in a xorg-fonts-100dpi package. Looking forward, support for package scriptlets would be nice. The scripts could be auto-generated based on file patterns at build time, while still allowing custom scripts (e.g. running gtk-query-immodules-2.0 in the gtk package.)
On Mon, 4 Dec 2006 15:20:09 +0000 Simone Rota <sip@varlock.com> wrote:
My proposal:
- Keep Per as the packager for inherited core ports, with his personal email. - Use the "real" packager for newer ports (ie udev) - Use "CRUX System Team, core-ports at crux dot nu" for the core ports maintainer field - Use the specific maintainer for core ports that the System Team members are not much interested in due to personal preferences, if any (I'm thinking of ports like xfsprogs)
I have no say in this, but IMO it's pretty useless to keep the original packager around, since he/she/it should never be contacted anyway. An alternative is to keep the packager around if somone feels it's needed for crediting or some such, but without listing the mail-adress, to add an obstacle to mailing the wrong person. Just my truely worthless 0.02€ // treach
participants (4)
-
Mark Rosenstand -
Simone Rota -
Tilman Sauerbeck -
treach