[Pkg-zfsonlinux-devel] Current status?

[Darik Horn]

On Sun, May 5, 2013 at 4:02 PM, Aron Xu <happyaron.xu at gmail.com> wrote:
>
> Aren't these are information publicly available?

Yes, but only for a small value of public, as evidenced by the small
number of people that seem to know about it.

We should survey the interested students to ask whether they know that
these resources exist, or whether they were included in the
collaboration, or whether they were encouraged to participate.

Mitesh, Veselin, and anybody else:  How many email conversations have
you had regarding your GSoC applications?  Get any feedback?  Were you
coached in any way on how to get the job?


> I don't quite understand what do you mean. Starting from the very
> first project idea get posted in Feb, this mailing list is in the
> recipient. And of course you know this GSoC project long before
> application deadline, you have plenty of time to advise students to
> participate this project. It makes little sense saying as such when
> it's finished.

I was surprised when I reviewed the official GSoC documentation
because I thought that *you* were a project mentor.

First, you did code reviews for Carlos, vetted contributions, and
provisioned the work as an official Debian Developer.  But you are now
listed as the student and Carlos as the mentor.  How did that
student-mentor relationship get reversed?

Second, for example, I found a defect during bench testing and you
told me to squash the review. I respected your orders as the putative
team leader. You exercised management authority when you said that "I
understand your questions are valid, but they shouldn't be blockers of
other changes".  Choosing to prioritize recruitment over product
quality is very much an executive decision.

Third, your application wasn't published in a place that I could see
it until April 27th.  Had I been fully informed, or had you presented
as a student in dealing with me,  I never would have donated the time
to entertain those regressions, failures, and system mangling.


> Could you elaborate why packaging is half of the deliverable?

Per http://wiki.debian.org/SummerOfCode2013/Projects#ZFS_on_Linux_integration

#1 is finished and already has several hundred production
installations.  Similarly, advanced users have been directly
re-purposing the grub materials from Ubuntu to Debian for a long time.

#2 is an empty task.  Wrapping scripts is unnecessary, and
apt-zfs-snapshot is really part of #4, although it could be a tweak of
the existing apt-btrfs-snapshot software instead.

#3 cannot be achieved because the release team will not accept
external modules, which is admitted in the Caveats section.
Regardless, this is a large amount of work that could overrun the
schedule and create an ongoing support commitment.

#4 is legitimate and worthwhile.

#5 is already satisfied by the comprehensive upstream build farm.

Thus, the proposal is essentially a beadm port from Solaris to Linux.
More ideas could have been obtained by checking the ZoL issue tracker,
asking questions in the zfs-discuss list, or using the software.
Debian users want things like clustering, monitoring, a working
zeventd, automatic device replacements, a complete hotplug facility,
systemd integration, etc.


> clear that Debian's GSoC admins said packaging projects aren't
> accepted at all this year. And we all know there is packages provided
> by you, so it's a good base and makes packaging itself won't form a
> GSoC. You have more or less ignored the later integration part, which
> could be the most value-adding part of such a project.

But I'm shipping product today, which has ultimate value.

Now, if you want to talk about performance metrics, then I count 35
current commits that have closed zero issue tickets and caused a
handful of regressions.  Given a pile of several hundred bugs and
enhancements from which to choose, this effort has produced literally
nothing of value after five calendar months of active development.

-- 
Darik Horn <dajhorn at vanadac.com>