Hi, I've noticed that many of the recent port adoptions in opt and core have only changed the Maintainer: field and not added a Packager: field for the previous maintainer. In the past I've also noticed a bunch of commits pretty much randomly changing those fields, in particular some of sten's (danm's previous) ports. Personally I've always wondered what that sort of useless information is doing in an otherwise sparse system like CRUX ports. Sure, the creator of the port could get some credit, but really, creating a port is usually a matter of seconds for the autotools-based ones, minutes for others (in general) and a couple of hours for the really tricky/polished ones. I also tend to think that the Maintainer: field could be left out and a repo-wide contact address be used instead (being a virtual one for repos with multiple maintainers) - but it does make sense for 'contrib' in its current form, at least, so lets leave that out for today. Anyway, it'd be nice to reach some consensus and see some consistency with the use of that field. Is the info useful? Could it be located elsewhere, e.g. commit messages? If not, wouldn't (multiple) Contributor: fields make more sense, or will there always be at most 2 people contributing to a port?
Hi, On 2006-09-29 at 00:27, Mark Rosenstand wrote:
Anyway, it'd be nice to reach some consensus and see some consistency with the use of that field. Is the info useful? Could it be located elsewhere, e.g. commit messages? If not, wouldn't (multiple) Contributor: fields make more sense, or will there always be at most 2 people contributing to a port?
I think that if something is decided to be left out, it should be Packager, since maintainer changes are tracked in svn, and whoever imports it should be responsible for the port even if it's copied from someone else (this should probably be mentioned in the initial commit message). Adding multiple contributor fields doesn't sound very good. -- Antti Nykänen | aon@iki.fi | http://aon.iki.fi/
On Fri, 2006-09-29 at 15:15 +0300, Antti Nykänen wrote:
Hi,
On 2006-09-29 at 00:27, Mark Rosenstand wrote:
Anyway, it'd be nice to reach some consensus and see some consistency with the use of that field. Is the info useful? Could it be located elsewhere, e.g. commit messages? If not, wouldn't (multiple) Contributor: fields make more sense, or will there always be at most 2 people contributing to a port?
I think that if something is decided to be left out, it should be Packager, since maintainer changes are tracked in svn, and whoever imports it should be responsible for the port even if it's copied from someone else (this should probably be mentioned in the initial commit message). Adding multiple contributor fields doesn't sound very good.
Completely agreed. In contrast to the Packager field, the Maintainer field is actually useful - the Contributor idea was just to show that even the current "usage" of Packager (giving credit) is broken because it only allows one person to be listed :)
On Fri, Sep 29, 2006 at 02:23:30PM +0200, Mark Rosenstand wrote:
Completely agreed. In contrast to the Packager field, the Maintainer field is actually useful - the Contributor idea was just to show that even the current "usage" of Packager (giving credit) is broken because it only allows one person to be listed :)
And the more general question is: What is Pkgfile's license? Pkgfiles are programs, scripts, and they are expected to have some license, or be in public domain. It makes more sense to me smth like: # This Pkgfile convered by GPL license. Copyright (c) .... In case when several persons will contribute to Pkgfile, we'll end up with something like: # This Pkgfile convered by GPL license. Copyright (c) .... # (c) ... # (c) ... # (c) ... And that list will grow in time, and there will no way to cleanup such fields. Plus, IMHO you can't do "(c) CRUX team", because "CRUX team" is neither person nor formal organization. It is very edgy question at least to me, because personally I think that Packager field is "bloat" from practical POV, and because I have to maintain CRUX-ARM on my own, that means I have to maintain Packager field for the rest of my life. Though, if I must save these fields, then right thing to do is s/Packager/Author/ and everything will clear to me. Waiting for clarifications... Thanks, -- Anton (irc: bd2)
There is no point in putting a script, be it a shell or a perl or a whatever script, under the GPL since you can't release binaries, and thus you can't make secret changes. # Han -- http://www.xs4all.nl/~hanb/software/crux/
On 9/30/06, Han Boetes <han@mijncomputer.nl> wrote:
There is no point in putting a script, be it a shell or a perl or a whatever script, under the GPL since you can't release binaries, and thus you can't make secret changes.
But anyone who improves a GPL or similarly licensed script is required to make their improvements under the same license. clare
On Sat, 30 Sep 2006, Han Boetes wrote: > There is no point in putting a script, be it a shell or a perl or > a whatever script, under the GPL since you can't release binaries, > and thus you can't make secret changes. I think that the GPL is not only about inhibiting secret changes to source code of binary stuff. OTOH it does seem to me a little bit of an exaggeration to want it for the ports. Michele -- > Are there any estimated timescales on when Perl6 will be available? next christmas (for some definition of christmas). - Uri Guttman in comp.lang.perl.misc (slightly edited)
Mark Rosenstand wrote:
Hi,
Hey,
I've noticed that many of the recent port adoptions in opt and core have only changed the Maintainer: field and not added a Packager: field for the previous maintainer. In the past I've also noticed a bunch of commits pretty much randomly changing those fields, in particular some of sten's (danm's previous) ports.
A clarification on core/opt ports previously owned by Per: We will normalize maintainer / packager information with the next release. The current headers are a direct consequence of adopting some port as individual developer and some other as a more general 'core-ports'.
Personally I've always wondered what that sort of useless information is doing in an otherwise sparse system like CRUX ports. Sure, the creator of the port could get some credit, but really, creating a port is usually a matter of seconds for the autotools-based ones, minutes for others (in general) and a couple of hours for the really tricky/polished ones.
Well' I won't call it totally useless, and giving some credit is fine.
I also tend to think that the Maintainer: field could be left out and a repo-wide contact address be used instead (being a virtual one for repos with multiple maintainers) - but it does make sense for 'contrib' in its current form, at least, so lets leave that out for today.
The Maintainer field is the only information we have inside opt to see who's owning a port so I think it won't change. Not sure about the core ports: the core team could decide to use a virtual user as you suggest, in any case since the field is needed for opt and contrib I guess keeping it is a sane decision.
Anyway, it'd be nice to reach some consensus and see some consistency with the use of that field. Is the info useful? Could it be located elsewhere, e.g. commit messages? If not, wouldn't (multiple) Contributor: fields make more sense, or will there always be at most 2 people contributing to a port?
I agree some standardization is needed; I think Maintainer/Packager served us quite well so far and I see few reasons to change them; one of them is listing multiple contributors as you pont out: maybe simply using multiple Maintainers line can allow us to add the info without having to rewrite some hundred scripts/tools :) Regards, Simone
Dear All, While this is being considered, I have always hoped that eventually the team would see the advantage of dating packages; in the Pkgfile. regards and thanks to you all, clare
participants (7)
-
Anton -
Antti Nykänen -
Clare Johnstone -
Han Boetes -
Mark Rosenstand -
Michele Dondi -
Simone Rota