[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Let's stop using CVS for debian.org website



     Hi!

* Boyuan Yang <073plan@gmail.com> [2016-11-20 03:45:54 CET]:
> As a newcomer who wants to contribute to the Debian website, I was shocked 
> when I heard that debian.org website is still using CVS to manage the source 
> code.
> 
> I know there is a saying that "If things ain't broken, don't fix it.". But this 
> is nearly 2017 today, not 2007 or 1997. CVS is seriouly outdated and largely 
> replaced by SVN (or even Git).
> 
> If we continue to use CVS in the website source management, the disadvantages 
> are clear:
> 
> * All the shortcomings that exist in CVS but solved by SVN or Git.

 Erm, SVN is in no way better than CVS, the only difference is that it
has somewhat global revisions to replace the timestamps of certain
commit periods.  But that's technicly all there is to it.  There are
also some drawbacks.

 Most of the shortcomings aren't even relevant in the context, but
that's something different.  A shortcoming that git has over cvs/svn is
that subdirectory checkouts aren't possible.

 Please don't be fooled and stay proper with your arguments. :)

> * Fewer and fewer people know how to manipulate with CVS, and most of the 
> others won't be willing to learn it.

 That's a thing for every tool, and the few commands for CVS aren't
difficult at all.  Thing is, every VCS works differently.  And the
learning curve is extremely low for CVS (I mean, *really* low).

 That doesn't change the (partly understandable) stuborness of people
not willing to learn, because CVS *is* ancient and I agree that it
doesn't make much sense these days to dig too much into it -- even
though, like mentioned above, it's really not big of a deal, at all:

*) (once) cvs checkout
*) cvs update (before starting to work)
*) editor file
*) cvs add file (if new)
*) cvs commit

 A thing for a five minute crash course. :)

> * Difficulty in setting up modern web interface. (Compare viewvc with GitHub, or 
> for free software, GitLab or even cgit.)

 Well, "difficulty" is well said.  Noone coded one because it's ancient
and noone cares about it anymore.  So "setting up" would mean code it
from scratch. :)

> * Difficulty in mirroring.

 As much or little difficulty as with svn (see above).

> * ...which means the number of new content contributor would decrease.

 Sure, but everyone who brought it up was just venting and never started
helping out with the task.  Let's see.  My first approach to get it into
git reaches back to 2008: http://rhonda.deb.at/blog/debian/2008/09/16
Since then I invited everyone to help out and would have been more than
willing to give a helping hand too, but I can't do the task on my own,
I just can share my thoughts with the process.

 To some degree I see this similar to the website redesign talks that
always popped up: Kalle was the first (and so far only) person who came
up with a proposal that convinced me that he was really honest on
wanting to make this happen, by thinking about more than just a fancy
interface and create some mockup design but actually started to set up
some real pages to test it with.  That made me realise that it would be
possible to do it with his help and get things done.

 Noone so far convinced me that they really would be willing to get this
done and help with the task - so far everyone who brought it just came
with blank statements how awful CVS is (actually, it isn't that bad) and
never give a helping hand when they see what it might involve.

 I said it multiple times: I am more than willing to drop a lot of
complexity that the current website tool offers (like in the translation
check) if it would make it easier to convert.  We just shouldn't a few
things:

 *) Some translators don't have big bandwidth, so having a possibility
to contribute translations without a complete checkout is somewhat a
must.  Especially when one finds a typo is should be possible to send a
quick patch - and if one of the modern webinterfaces offers a quick edit
possibility (authenticated), that would be a huge benefit.

 *) The buildprocess shouldn't take ages to figure out those things.
Personally I am leaning towards a "git hash-object" number for using in
the translation check because it's quite fast, can be calculated
beforehand and is independent of the commit ID, because commit IDs don't
really gain us anything here.  And a "git diff <blob> <blob>" with the
"git hash-object" is all we need. (Though, intermediate diffs of
multiple changes are a bit more complex to calculate, but that's not the
standard workflow and could be incorporated into the language stats
webpages like it is currently: http://www.debian.org/devel/website/stats/

 *) Subtree checkout might be a very useful thing - but I guess the
handling of submodules is really a horror and we probably can get away
with it.

 Maybe I'm coming up with more things that are stored in my head over
the years thinking of the issues, but those are some hints along that
lines.

> Needless to say there are various tools that can help convert a CVS repo into 
> a SVN repo or Git repo and they handle this job properly.

 We used a git copy of webwml to work on the website redesign to
rebase/merge the commits during the time to not lose changes, see
http://git.deb.at/w/deb/webwml.git and also
https://lists.debian.org/debian-devel-announce/2010/11/msg00001.html

> I know the migration to other version control system would not be trivial and 
> hurt the current workflow, but I strongly suggest that we set up a timetable or 
> future plan.

 Timetable: IIRWIIR.  That's the way things work.  Unless you are
willing to pay people for it so they don't need to do payed work during
the period and can concentrate on it.

> So will debian.org continue to use CVS to manage its source code? 

 If noone is willing to do the work, probably yes, until DSA tells there
is no way anymore to keep it running; and then hopefully more people are
actually interested to make things happen instead of just saying "this
is bad".

> If yes, when will we re-analyze this choice?

 Whenever someone else comes along who just calls for "this is bad"
without actually willing to help.

> If not, when will we do the migration?

 Whenever you (not personal, rather to the broader audience) is willing
to actually put in some work instead of just stating the obvious which
is known since literally a century, at least.

 So long,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los      |
Fühlst du dich hilflos, geh raus und hilf, los    | Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los    |


Reply to: