Re: Maintenance of the Hurd parts in glibc (was: about GNU Hurd)

[Michael Casadevall]

I believe antrik hit the nail on the head (and I apologize for not being active on the lists; real life caught up with me). Watching how things are being done, I find it insane that as it stands I have to patch the sources so heavily to get a usable system (The 2GB for patch ext2fs has been sitting on the Savannah tracker for almost three years (
https://savannah.gnu.org/patch/?func=detailitem&item_id=2508);). One of the priorities I think is getting patches from Debian merged upstream into Mach and Hurd CVS many because it seems most of the development has moved from our own CVS repositories into Debian's patches; I suspect the best thing that could be done is give the more active members CVS write access despite the fact they aren't experienced as the current maintainers, and make a branch of the current repos so we'd have gnumach-1-branch-experimental and hurd-experimental so that we can merge in the Debian patches and any other ones that have been sitting on the list for ages.

Leave the current gnumach-1-branch and hurd branches for when we do a stable release (i.e. all development work is done on the experimental branch, when release time comes, we simply cherry-pick the stable patches from experimental and stick it in the main branch, and make a release). The only downside to this CVS is rather painful when it comes to merging and has no provisions for cherry-picking patches; it might be worth migrating to Git for this alone; I believe Savannah runs a git-cvsserver so people who prefer CVS can still use it.

I realize I'm still fairly new here, and I suspect many people are going to complain that I don't have the right to suggest criticize how things are done here, but I do speak from experience; I was (and still am) project manger of a game called Castle Infinity. When I joined the project, development was a complete mess because of similar issues we had here (lack of organization, lack of motivation/time by elder members). The first thing I did once I realized was going on was locked our SVN repository's trunk, and creating a new branch called nc-build35 for the next release, and told anyone who wanted to develop to switch to that branch. Quite suddenly, progress was being made, and we were able to organize out first release in over a year; the reason for this was simple, it was easy enough to get people to develop on something when they had the ability to write to the repository, and people were working on a common codebase vs. their own forks of the old trunk. 

When release time comes, the current maintainers can pull any patches that have proven to be stable from experimental into trunk and make a new release; incidentally it would also be easier to do this since now the most up-to-date version of a patch would be available at ones fingertips. In addition, with everything also kept in a central repository, its easy to go back in time in a patches development and get an older version if needed instead of having to search the mailing lists for old versions of patches, and fixing them to apply cleanly to updated sources.
Michael

On 7/22/07, olafBuddenhagen@gmx.net <olafBuddenhagen@gmx.net > wrote:

Hi,

On Sun, Jul 22, 2007 at 02:36:32PM -0400, Richard Stallman wrote:

> There may be a misunderstanding.   Two different issues were raised:
> getting Hurd-related changes into Glibc, and getting changes into the
> Hurd.

Well yes. While the glibc issue seems to have turned out mostly a
communication problem (although some of Ullrich Drepper's comments on
the Hurd-related bugs suggested otherwise...), the Hurd issue is much
more fundamental.

There is no problem for obvious fixes: There are at least two active
developers with commit access, who can directly commit such obvious
things. However, the currently active people are relatively new to the
Hurd, and aren't confindent enough yet to decide on any more fundamental
matters; while those who have been around long enough to have the
necessary understanding, are lacking either time or interest -- so often
there is just nobody to even comment on a proposed change, far less to
give it official blessing :-(

The result is that most patches end up in Debian GNU/Hurd (the Debian
maintainers happily apply any patch that seems to improve things, no
matter whether it's a "proper" solution or only an experimental hack);
but most of them never make it to the official Hurd CVS.

-antrik-


_______________________________________________
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd