Streamline pkgsrc issues: DragonFly developer gained NetBSD commit privilege
c.turner at 199technologies.com
Tue Sep 20 11:46:20 PDT 2011
On 09/12/11 05:17, John Marino wrote:
I think the dfly-pkg-people idea was probably okay in theory, but it
doesn't sound like it's been too successful so far.
Personally I think this is symptomatic of the fact that our overall df-to-pkgsrc
bug reporting / fixing process could be much more clearly defined - e.g.:
- df wiki page on the 'official' procedure to get something included
(e.g. some of this might just point to regular pkgsrc procedure - and other
stuff might relate to getting 'our' committers to pick something up, etc)
maybe outlining this by 'class' of issue - e.g. new packages: should be
submitted to pkgsrc-wip or what have you, whereas a 'branch bugfix' might
be submitted to netbsd bugs and notify the df-people, etc.
- some kind of cross-notification about what bugs are in the system /
what needs fixing, etc.
- perhaps some kind of information about who has commit access and/or
a mailing list df-side to bang on people to get things 'properly' verified /
cleaned up / tested / committed etc. No need to wait on some specific person
for a one-liner ./configure script patch, etc. to make some package
assigned to pkgsrc-users@ work, on the latest pkgsrc branch / df relaease, etc.
The bulk build reports are great, as is the query pr stuff, and having
pkgsrc committers - but we just need some 'glue' to bring it all together IMHO
which would probably help improve things a ton
Seems like a df-side mini-project which serves as an official liason with
the pkgsrc/netbsd side people would fill the need here - not trying to usurp
their processes by proxy but at the same time there are some aspects that are
more-df-than-netbsd here and probably make sense to be handled as such.
I'm happy to pitch in where possible if any of the above needs doing -
just don't feel like I have the 'authority' to set the tone, policy etc -
More information about the Users