[Pkg-zfsonlinux-devel] Current status?

[Aron Xu]

Hi Darik,

I think this is one of the most important thing you actually want to emphasis:
>
> But I'm shipping product today, which has ultimate value.
>

It's likel the DKMS patch you are using in your "product", which adds
your name to the whole file of 5000 lines because you've added no more
than 30 lines to that file, which forces us to choose a dirtier but
much safer (copyright-wise) approach. Isn't these two stuff add up to
your today's replies?

Darik, by either of the things I know you want keep your credit, but
to be honest I don't think this should be done in a way of attacking
people who are potential game changers.

Starting from the day I posted the two GSoC project ideas, to anyone
asked me about the two ideas I said that I may apply one of them as a
student, no matter it's Debian's GSoC admins, potential mentors, and
even other students. And even Brian, the ZoL maintainer, knows that I
want to work this project as a student very early, right after you
quit from co-maintaining this project on Alioth in action. Since you
aren't actively involved in either Debian or the Debian's efforts of
this project, neither me, nor any existing co-mentors proposed to ask
you join the mentoring group. Yes, it's your disregarding leads to
your today's questions.

OK, let me comment on what you've said below:

On Mon, May 6, 2013 at 10:47 AM, Darik Horn <dajhorn at vanadac.com> wrote:
> 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.
>

That's the responsibility of a student, at least she/he needs to ask
mentors about more information if she/he thinks he wants to know more.
I'm one of them and I shared the knowledge with other active members
of the project plus anyone interested in talking with me about those
details.

> 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.
>

This GSoC idea has gone through all essential procedure, is publicly
posted in Debian's soc-coordination page (which is way better than
some of other ideas), and is being advertised on public Wiki page for
months, waiting for potential mentors and students. You aren't
involved in such work by anyway, so it's ridiculous that you wish all
the notifications go to you.

> 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 had a chance to talk shortly with Veselin on IRC, for helping him
ping the project's mentors. It's not mentors' nor mine responsibility
to coach any student in this stage - the project isn't started, and
mentors only have the responsibility to discuss
questions/applications/anything that the student wants to discuss with
them. This is how GSoC works, please read GSoC documents if you want
to get involved.

>
>> 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.
>

I know you thought that before reading more about this year's GSoC,
but not quite sure how long before.

> 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?
>

Official Debian Developers do not imply anything advanced than other
Debian contributors. It's just mean that someone get more trusted
through a long time of valuable contribution to the project and passed
necessary procedure. I became a DD not because ZFS on Linux, nor
anything related to filesystems. All Debian contributors are equal and
DDs only get extra privilege to 1) vote on project votes and proposing
GRs 2) upload to the archive without another people's sponsoring.

I wanted to persuade you such thing before you quit-in-action, but I
failed. You said this project does not make you a Debian developer on
#zfsonlinux, and you expressed that you quite mind the -guest
additions to the account name on Alioth.

> 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.
>

Debian is not a company, and is not structured like a company,  I do
not have the power to manage you and even I don't pay for your work.
People do work when they have consensus and understanding to each
other. It's the very basic rule when everyone is volunteer but my
assumption that you understand it could be wrong.

> 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.
>

April 22nd is when the student application opens, and May 3rd is the
deadline. Do you think submitting proposal on April 27th something
inappropriate? If so, you must argue that with Google.

>
>> 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.
>

I don't think it's finished, but I know you have something working as
said in previous mail. It's not finished because the project scope is
within Debian, but your packages do not fit Debian's policies. We
chose to rework quite some thing, and you choose to quit when diffs
are generated.

> #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.
>

Hey it's not empty, tweaking of apt-btrfs-snapshot is definitely the
right thing to do, and everyone searches about apt snapshot will get
the idea.

> #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.
>

Again it's not achievable, just not using the way you think.
Debian-Installer is super flexible stuff which you can hack on a very
wide range of places, and I bet you didn't understand what's the
purpose of "Additional Notes". This will sure create an ongoing
commitment and one of GSoC's goals is to have more flood to join new
areas and continue to work on it.

> #4 is legitimate and worthwhile.
>
> #5 is already satisfied by the comprehensive upstream build farm.
>

Yes, and I think it could be the reason of being marked as optional.

> 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.
>

Cannot agree with your summary, as commented above.

>
>> 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.
>

This is the gotcha, :-)

> 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.
>

Please give details and evidence? Talk is cheap, and even you just blame.



--
Regards,
Aron Xu