OK, Gentlemen, prepare for migration
Manuel Amador (Rudd-O)
Rudd-O.com to use the latest Plone version.
However, I have not touched zfs-fuse.net (which keeps running as usual).
So, here's the deal: what migration strategy do you recommend? A
different type of web site (perhaps a wiki-like site)? The same old
site we were using before?
Also, would you consider making one joint site for zfs-fuse and
zfsonlinux?
Now is the time to speak.
Please reply-to-all so I can get notified of the replies
Thanks in advance!
sgheeren
> So, here's the deal: what migration strategy do you recommend? A
> different type of web site (perhaps a wiki-like site)? The same old
> site we were using before?
content :)
> Also, would you consider making one joint site for zfs-fuse and
> zfsonlinux?
To be honest: I don't think that could be the topic of discussion right
now. Yes I would consider that, but it appears that zfs-on-linux have
their own very functional site (much simpler) already, so I can't see
them 'moving in'. If you really meant: what about 'moving in with them'
- I think there is a sort-of-long-lease-invitation to do such a thing,
based on the assumption that the projects might start sharing (parts of)
the POSIX layer. In that case, I can see us _re_move the zfs-fuse.net
site. However, that day is not now, AFAICT
Cheers,
Seth
Fajar Priyanto
<rud...@rudd-o.com> wrote:
> After a long time (7 years!), I have finally migrated the server at
> Rudd-O.com to use the latest Plone version.
>
> However, I have not touched zfs-fuse.net (which keeps running as usual).
>
> So, here's the deal: what migration strategy do you recommend? A
> different type of web site (perhaps a wiki-like site)? The same old
> site we were using before?
>
> Also, would you consider making one joint site for zfs-fuse and
> zfsonlinux?
>
> Now is the time to speak.
Hi,
I'm just a happy newbie zfs-fuse user so I don't think my opinion
matters, but I just want to comment :)
IMHO, the current zfs-fuse website is fine. It's concise and clear in
delivering the news about zfs-fuse.
Using other CMS may be more convenient if the website has active
articles to show, but not in zfs-fuse case.
About merging with zfsonlinux, has there been any talk with them in the past?
Gmail
Fajar Priyanto <faj...@gmail.com> wrote:
>--
>To post to this group, send email to zfs-...@googlegroups.com
>To visit our Web site, click on http://zfs-fuse.net/
Seth Heeren
> I'm definitely in favor of a merger. I know zol are into the idea. There needs to be a merger of the projects eventually. It's now a good time for zfs-fuse?
>
Who's that? You show up as 'Gmail'...
Christ Schlacta
servers were used for outbound mail configurations. I'm Christ Schlacta
(as it should say now), and I am currently subscribed to both (zfs on
linux, zfs-fuse) lists (from different aarcane@ e-mail addresses so I
don't post to the wrong list on accident!). There's been talk there of
a merger in the past too, but nothing ever came of it.
Seth Heeren
Also, can you substantiate that? What is the foundation for your
claim. If it is your opinion, please state as such.
Personally, I'm all for it, but I don't think it makes sense until the
projects actually have a common component. Right now the common ground
is... it was designed for linux.
If that alone is enough grounds to merge projects we can expect SF.net
to see a reduction of unique projects by a factor of 99% :)
I'm afraid that few people will be found that have the time/skill/
motivation to integrate/share the POSIX layer between the projects.
Until those people come available, I don't see a merger happening/
working. But perhaps I'm underestimating the number of fuse-lovers
among the ZoL hackers and they might start coming to zfs-fuse to get
precisely that work started. Or maybe it will take until zpool v64
until the urge rises (mmm. hard to predict the future is. human beings
whimsy are and rational not, some. time tell it will)
My $0.02 as usual
sgheeren
> I'm Christ Schlacta (as it should say now), and I am currently
> subscribed to both (zfs on linux, zfs-fuse) lists (from different
> aarcane@ e-mail addresses so I don't post to the wrong list on
> accident!).
> There's been talk there of a merger in the past too
I suppose that would have been Brian and me? We have talked a bit on
combining efforts - back when KQ was still vapor wear, and possibly
going to stay vapor wear.
I suppose ZoL was hoping to 'inherit' part of the posix layer. I didn't
have the time/skill to do that at the time, and it seems, largely, that
ZoL's POSIX layer is doing fine on it's own these days.
Personally, I never discussed the merging of sites (I just sketched my
current view on that in another reply), allthough *iff* ZoL and zfs-fuse
had ended up sharing code, it would have made heaps of sense, if only to
actively merge the communities. (By and large, that has already happend,
because most of the active Zfs-fuse list members are also seen
frequenting the ZoL trackers; some of the zfs-fuse hackers of old are
seen contributing/testing ZoL)
So, really, for now, I'm not aware of the benefit of merging the sites
on short term.
For now,
Seth
Manuel Amador (Rudd-O)
on github, and their bugtracker is fantastic, while the releases, news,
documentation and stuff like it, can live on the web site and will serve
a dual purpose mostly, because it's mostly both for ZoL and ZFS-FUSE.
Heck, we can even be the ZFS on BSD hub if we wanted to. So I'd like
you guys to share your vision with the list, and I'll make the
infrastructure available for it.
I'll probably create an independent Plone site precisely for this
purpose, so managers can do whatever they want at will, without relying
on me. We'd just need to coordinate product upgrades, and I can provide
continuous education in the use of the site and Q/A about using it.
So, what do you guys think?
Manuel Amador (Rudd-O)
documentation, news, things like that, I DEFINITELY see a benefit.
Most DEFINITELY.
Also, distributing the maintenance of the site to several people, more
heads think better than fewer.
And maybe later we can share code or merge the projects altogether.
Christ Schlacta
First and Foremost, all the ZFS code should be in one single repository
for ease of maintenance, bug fixes, coordination, and interoperability's
sake. a fix in one branch would quickly propagate to all (both?) projects.
Secondly, there should be as LITTLE repetition of code and effort as
possible. Repetition of code leads to bugs, and repetition of effort
leads to wasted effort. Both are decidedly bad.
Finally, I believe the userland should be unified. there should only be
one set of ZFS userland utilities provided. The interface between zfs
userland and [fuse | kernel] space should be made identical and
compatible. This will make more inroads to ensuring bugfixes and
feature implementations are propagated quickly.
The underlying reasoning behind all of this is primarily that the goals,
aims, and purposes of both projects is the same. To provide a
functional implementation of ZFS on Linux. The differences in code
should be minimal, and limited to what's necessary for operations (and
to a lesser degree for performance).
Furthermore, I believe that providing a unified front for ZFS
documentation and news is also important, as Manuel Amador pointed out.
I think we need to make such changes as duplicating existing error code
messages from the former sun website, and build a new repository of
knowledge at a shared website that non-Solaris OS' can link to with
potential implementation-specific feedback, such as platform specific
fixes or "This feature is not yet supported on your platform" type
messages.
Lastly, I think we should CONSIDER taking this whole project one step
further and sharing a repository and website with *bsd, and the various
Solaris Forks as well. The unification of ZFS outside the Solaris world
can only bode WELL for interoperability's sake, which is good for ZFS as
a whole, and on each platform, as well as for the sanity of devs who may
at some point have to cope with interoperability concerns created by the
current schism. I understand that because the Solaris forks and BSD are
VERY different there may be difficulties implementing this step, and
they may represent serious burdens, but I believe the net result would
be positive if the cost or difficulty is not too great.
sgheeren
> First and Foremost, all the ZFS code should be in one single
> repository for ease of maintenance, bug fixes, coordination, and
> interoperability's sake. a fix in one branch would quickly propagate
> to all (both?) projects.
The code bases are too diverse a.t.m.
>
> Finally, I believe the userland should be unified.
Again, nice; also slightly more feasible in the short term. **But**
you'd need to have versioning of the client and zfs 'daemon/kernel'
interfaces because, right now it will not be simple to keep those in
synch. IMO, having several 'current' versions of the userland tools for
use with different 'backends' is nearly as bad as having separate userlands?
> The underlying reasoning behind all of this is primarily that the
> goals, aims, and purposes of both projects is the same
Actually a very valid point.
> Furthermore, I believe that providing a unified front for ZFS
> documentation and news is also important
Good point as well. Allthough, I see no problem just _pointing_ at this
supposed new source of information when it comes into being. You needn't
worry about the amounts of documentation being generated over at
zfs-fuse (just check the site?)
> Lastly, I think we should CONSIDER taking this whole project one step
> further and sharing a repository and website with *bsd, and the
> various Solaris Forks as well. The unification of ZFS outside the
> Solaris world can only bode WELL for interoperability's
I agree. In a way, having the vision and just keep on pushing in the
general direction has a higher chance of getting there.
Let me add one worry of my own: I'd hate this to have the actual effect
of 'storing zfs-fuse as a legacy branch in the museum department' at the
ZoL hub, though. At least having the separate site, underlines the
notion that many people (including ZoL users) still consider zfs-fuse to
add value for some deployments.
That all said, I think I'm willing to modify my stance towards:
- we can go for a move-over (I suppose ZoL is the right destination,
since the name fits and they have the active community a.t.m.)
- just don't expect magic interoperability. It will cost a lot of work
(see my first two inline responses)
Any thoughts?
Manuel Amador (Rudd-O)
task compared to merging the Web sites. So why don't we start with the
most expedient part first?
:-)
Brian Behlendorf
>
> First and Foremost, all the ZFS code should be in one single repository
> for ease of maintenance, bug fixes, coordination, and interoperability's
> sake. a fix in one branch would quickly propagate to all (both?) projects.
Let me start by saying in principle I like the idea of everyone working
on a single zfs project. In the long term it's good for all the reasons
you've mentioned. But in the short term getting everything merged is a
ton of work. You would need buy in from the active developers and a
substantial amount of their time.
> Secondly, there should be as LITTLE repetition of code and effort as
> possible. Repetition of code leads to bugs, and repetition of effort
> leads to wasted effort. Both are decidedly bad.
I agree, but at the moment the code bases are far two different just as
Seth has said. It could be done, and it probably should eventually be
done, but it won't be a quick process and it will certainly be
destabilizing. I for one don't want to relegate the zfs-fuse port to a
legacy branch. It should be part of the main development tree since
it's so useful.
> Finally, I believe the userland should be unified. there should only be
> one set of ZFS userland utilities provided. The interface between zfs
> userland and [fuse | kernel] space should be made identical and
> compatible. This will make more inroads to ensuring bugfixes and
> feature implementations are propagated quickly.
This would have to be done as part of merging the code bases.
> The underlying reasoning behind all of this is primarily that the goals,
> aims, and purposes of both projects is the same. To provide a
> functional implementation of ZFS on Linux.
I think we can all agree on that.
> Furthermore, I believe that providing a unified front for ZFS
> documentation and news is also important, as Manuel Amador pointed out.
This would certainly be nice, and I think it's probably the best place
to start. But we need someone, or several someones, to volunteer to
develop and support this site long term. As I'm sure many have noticed
that ZoL site is pretty basic. The simple reason for that is it's not
where I want to be spending my time. This in particular is one place
where I think the non-developer zfs Linux community could make a
substantial contribution.
> Lastly, I think we should CONSIDER taking this whole project one step
> further and sharing a repository and website with *bsd, and the various
> Solaris Forks as well.
Sharing a website seems possible to me... but sharing a repository I've
actually given a lot of through too and I don't see how it could be
done. Perhaps the fuse implementation could be made to work on all
platforms but not the native version.
I think the wiser approach here is to pursue with the BSD and Illumos
developers refactoring the zfs code to be more portable. I think most
of the platform specific code could be reasonably abstracted. The
current code actually does a pretty decent job of this.
Thanks,
Brian
Manuel Amador
and I am willing to set up both a common area for a wiki and the mailing list
contents (so they are searchable for people who have questions) and also a
project area specific to zfs on linux, plus projects for zfs-related work.
To whomever is interested in seeing the progress of the site: feel free to let
me know and I'll grant you preview access.
---------------------------
Changing subjects for a bit: the bug tracker is unmigratable, and we need to
migrate off of plone 3 because there is a vulnerability in it. What should we
do about the bugs listed there?
---------------------------
I strongly believe the code and bug trackers ought to be moved to github
(because github is far superior for those purposes).
Code merges and migrations can wait. I believe those tasks can proceed much,
much easier if they are done within github, too.
What say you?
Manuel Amador
and I am willing to set up both a common area for a wiki and the mailing list
contents (so they are searchable for people who have questions) and also a
project area specific to zfs on linux, plus projects for zfs-related work.
To whomever is interested in seeing the progress of the site: feel free to let
me know and I'll grant you preview access.
---------------------------
Changing subjects for a bit: the bug tracker is unmigratable, and we need to
migrate off of plone 3 because there is a vulnerability in it. What should we
do about the bugs listed there?
---------------------------
I strongly believe the code and bug trackers ought to be moved to github
(because github is far superior for those purposes).
Code merges and migrations can wait. I believe those tasks can proceed much,
much easier if they are done within github, too.
What say you?
Seth Heeren
> Changing subjects for a bit: the bug tracker is unmigratable, and we need to
> migrate off of plone 3 because there is a vulnerability in it. What should we
> do about the bugs listed there?
I'd prefer to let it stick there. If you can get some kind of csv/xml
export, that would suit me too. It would be very valuable as a
reference. It contains numerous pointers into (version) history that I
cannot track manually :)
> To this, I would like to add that I am willing to migrate the content by hand,
Mmm... where to? I haven't seen any concrete propositions - if you
want to provide something that ZoL / Zfs-BSD might want to buy into,
I'd expect some tangible proposition.
Seth
Manuel Amador
On Monday, December 19, 2011 04:16:31 Seth Heeren wrote:
> > Changing subjects for a bit: the bug tracker is unmigratable, and we
> > need to migrate off of plone 3 because there is a vulnerability in it.
> > What should we do about the bugs listed there?
>
> I'd prefer to let it stick there. If you can get some kind of csv/xml
> export, that would suit me too. It would be very valuable as a
> reference. It contains numerous pointers into (version) history that I
> cannot track manually :)
>
Roger that.
> > To this, I would like to add that I am willing to migrate the content by
> > hand,
> Mmm... where to? I haven't seen any concrete propositions - if you
> want to provide something that ZoL / Zfs-BSD might want to buy into,
> I'd expect some tangible proposition.
>
To an independent Plone 4.1 site, completely spun off from Rudd-O.com, under
its own management and with its own features. How the site looks, what
features it has, how it will be organized, it's all entirely under the control
of whoever want to be managers of the site. It's also double as fast as the
old site, and I haven't even turned on any HTTP caching policies.
I'm already running it, in a private subdirectory.
Gmail
Manuel Amador <rud...@rudd-o.com> wrote:
>To this, I would like to add that I am willing to migrate the content by hand,
>and I am willing to set up both a common area for a wiki and the mailing list
>contents (so they are searchable for people who have questions) and also a
>project area specific to zfs on linux, plus projects for zfs-related work.
>
>To whomever is interested in seeing the progress of the site: feel free to let
>me know and I'll grant you preview access.
>
>---------------------------
>
>Changing subjects for a bit: the bug tracker is unmigratable, and we need to
>migrate off of plone 3 because there is a vulnerability in it. What should we
>do about the bugs listed there?
>
>---------------------------
>
>I strongly believe the code and bug trackers ought to be moved to github
>(because github is far superior for those purposes).
>
>Code merges and migrations can wait. I believe those tasks can proceed much,
>much easier if they are done within github, too.
>
>What say you?
>
Manuel Amador (Rudd-O)
I will get a listing of bugs and their contents shortly, and post it
somewhere.
In the meantime, the people who are managing their and the official
zfs-fuse repository, need to open Github accounts and push their
repositories there. For people using the repos in git.zfs-fuse.net,
please migrate to Github. I'll make a note to make redirects for anyone
using the old repos, so we will lose nobody in the process of migrating.