[Nut-upsdev] on Ubuntu Developer Summit (Oneiric), NUT and 2.8.0

[Arnaud Quette]

2011/6/8 Charles Lepple <clepple at gmail.com>

> On Sat, Jun 4, 2011 at 6:08 AM, Arnaud Quette <aquette.dev at gmail.com>
> wrote:
>
> > All these are scheduled for 2.8.0, around September. There will also be:
> > - the work already done, like NSS support (as an alternative to OpenSSL)
> and
> > the maturing Windows port.
> > - a Java binding (jNUT), needed for Eucalyptus integration,
> > - some work around Avahi and mDNS / DNS-SD.
>
> This seems ambitious for a few months. Then again, there's the old
> quote about the person saying it can't be done shouldn't get in the
> way of the person who is making it happen :-)
>

indeed, ambitious. but there is a good bunch of people working on this, or
2.8 in general
I also don't see you blocking the way, but the opposite ;-)


> A couple of vaguely related things:
>
>  * For years we've said that the NUT project only publishes source
> code, not binaries (leaving the binaries up to packaged
> distributions). I realize that Windows is a special case (since so few
> Windows users have a working software build infrastructure), but we
> really should have a little more separation between the source code
> and the Windows installer (such as giving it another download
> directory outside of source/).
>

right, I had to do a quick move for the .msi publication.
but I had the exact same remark to myself.
the "source only" distribution will come to an end, but only for "weak"
distributors (Windows, Mac for .pkg maybe, older Unix).
though the exact details of this are still missing (like which BB slave
system to generate packages for each system family), what is sure is that we
will still rely on Linux distro, for example, to generate official packages
(including backports ;-)

the idea is to have a "package/" directory, with per OS sub-directories
(windows, mac, hpux, aix, solaris).

 * If meeting the release date is the top priority, what are the
> priorities? Alternatively, if we are trying to release with a given
> set of broader power management features, what is the minimum set
> necessary to be useful? Is there a freeze date for Oneric that you are
> trying to meet?
>

well, this is the thing I'm finishing to check.
I've not committed on specific Oneiric release (alpha1 / 2 / 3).
moreover, there are a few things that may be separated from 2.8, like jNUT.
so this gives us some flexibility.
finally, there will be peoples (other than me) to ensure Debian packages
update and Ubuntu sync will be under control.
having a single-point-of-failure (namely /me) at every cross in the workflow
has show its limits.


>  * The Alioth outage is another reminder that we have a single point
> of failure in the repository. Combining that with the wide array of
> feature branches we will need to cover the goals mentioned above, it
> might be a good idea to move to a DSCM like Git so that we don't have
> complicated merge scenarios like the Windows branch. If a feature
> isn't ready for 2.8.0 (I don't like assigning version numbers to
> features, but I guess it's easier than picking a decent code name)
> then we need a way to keep that branch up-to-date with respect to the
> "trunk".
>

indeed, and this has been a growing point of concern on my side recently,
for the exact same reasons we've discussed and you mentioned above.
since Alioth is now providing git as an option, could you please check
implications and come up with a small migration plan?

this would at least be a first step, while waiting for something more
global, including trackers and the portal in general...

 * I would also propose that one of the first commits on a feature
> branch should be a little more description of the requirements, or
> design ideas.
>

I was more on having a tracker detailing the point, and referenced in the
first commits.
but I still find GForge trackers so... hem old school and not flexible
enough (ie, does not allow further edition once a task is submitted, no
direct link to SCM nor roadmap, ...)

cheers,
Arnaud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20110609/6e3bb516/attachment.html>