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 - cheers, - Chris
