Regen2 accounts transferred

I killed regen2 about 2 years ago. Today I was contacted by Rafal Kupiec asking about the project. Since it's dead he asked if he could take over the project. I have transfered the github account, and freenode channel #regen2 to him. The google groups are remaining archived. At some point in the future there should be a site at asiotec.org I have no idea what he plans on doing with it.

SubmittingPatches is better than "Patches Welcome"

So I received my first patch for Perl code a week ago. Amazingly I didn't have to tell the person patches were welcome, they must have assumed so because my project was licensed under an OSI approved license. Also amazingly I've applied the patch even though it didn't meet my quality standards. I figure that's my fault though because no where did I document what those were.

Back when I forked Regen2 from Funtoo one of the first things I did (and a reason for the fork) was create a policy for patch submission. The policy for Funtoo was that all patches were welcome, and I recall 2 patches by 1 user specifically that should have been 10 patches and 2 (or more) of those 10 patches should have been dropped, because they were doing things they shouldn't have. In order to create this policy as easily as possible, I stole Git's SubmittingPatches policy and modified it to work with Regen2.

Once again I've been faced with patches that just aren't up to par. So once again I'm using Git's policy as a baseline for contributions to my projects. Here's the beginning of the documentation

Checklist (and a short version for the impatient):

Commits:

- make commits of logical units
- check for unnecessary whitespace with "git diff --check"
before committing
- do not check in commented out code or unneeded files
- the first line of the commit message should be a short
description and should skip the full stop
- the body should provide a meaningful commit message, which:
- uses the imperative, present tense: "change",
not "changed" or "changes".
- includes motivation for the change, and contrasts
its implementation with previous behaviour
- if you want your work included in the main repository, add a
"Signed-off-by: Your Name " line to the
commit message (or just use the option "-s" when
committing) to confirm that you agree to the Developer's
Certificate of Origin
- make sure that you have tests for the bug you are fixing
- make sure that the test suite passes after your commit

Patch:

- use "git format-patch -M" to create the patch
- do not PGP sign your patch
- be careful doing cut & paste, not to corrupt whitespaces.
- provide additional information (which is unsuitable for
the commit message) between the "---" and the diffstat
- if you change, add, or remove any features or
make some other user interface change, the associated
documentation should be updated as well.
- if your name is not writable in ASCII, make sure that
you send the patch in the correct encoding.

Long version:
...

The only part I added was to add documentation for features. Obviously some parts under patch need modification as I'm not using a mailing list.

Obviously part of the reason I don't like "Patches welcome" is I've seen that policy lead to the acceptance of really bad patches. Now obviously I make mistakes, everyone makes mistakes, but patches can be improved before they are committed. Even good patches can be flat out rejected for other reasons (I've had this happen. The consensus was not that the patch was bad, but the entire script need to be rewritten).

So what was wrong with this patch if I accepted it? well essentially it wasn't a git patch and it was applied to the wrong directory (because I had the original source in src/ and the generated a / I'm not using CommitBuild to another branch) and, it also broke my test suite (even though it was a patch for a test. The breakage was a bug in another test).

In any event, I believe that having your project be "Open Source" and having a patch submission policy does more to say "Patches Welcome" than "Patches Welcome". You don't have to agree with that, but regardless of whether you do, or not, I think having a policy is a good thing.

P.S. Trolling posts will be deleted. Be constructive or talk elsewhere.

Google trashed my Google Site's Content

When I forked Regen2 from Funtoo over a year ago I created a web page for it on sites.google.com. The hosting and uptime were both right for what I needed. The dns has long expired but I went to sites today to find a public link to the content, only to find that at some point they upgraded sites and completely trashed all the content I had put on there. Sure they have a revision control on there now... but it doesn't contain ANY of the content I had left. WTF Google? I'm sure someone is going to say 'backups' but honestly, I killed the project, whatever was there wasn't really important to me anymore. But I didn't expect that it would get trashed in some Google update.

Iron Man and introductions

So I've decided to "compete" in the Iron Man competition.

My name is Caleb Cushing, I'm a 25 year old, unemployed, student, living in the Greater Lansing, MI, USA, area. I've been programming perl for approximately 6 months. This includes a lot of off time, time to relearn the language from the class I took a couple years ago (and learn modern perl), learning Catalyst and DBIC, all of which is an ongoing process. I would guess I've been writing useful code for about 4 months and even that is a slow going process as I've still got a lot to learn.

Previously, I was the tree maintainer for Funtoo, and tried spinning my own fork of Funtoo/Gentoo, it needed more devs than me to survive though. I now use Arch Linux. After an arch/perl user who went by aCiD2 moved to OS X I adopted most of his perl AUR (arch user repository) packages in addition to ones I had created myself. I now have over 200 CPAN packages on AUR in Arch's PKGBUILD format.

I'm a contributer to Catalyst::Manual and I created Template::ShowStartStop by forking Template::Timer.

I'm sure I'll become more active as time goes on, and have more interesting posts than this one.

Regen2. don't care anymore

Yep, I don't really care anymore. So much work needs to be done, I can't do it alone, but neither Gentoo, Funtoo, Sabayon, or Exherbo, are going down the right path to the salvation of the 'gentoo way'. Without help or regular feedback I lost the will to work on it. Will regen2 ever be revived? I don't know.

if you want go to Funtoo, it should be easy enough to do


git remote add funtoo git://github.com/funtoo/portage.git
git remote update
git checkout funtoo/funtoo.org
emerge -avuDN world

at this time I'm not actually using gentoo*, I'm using arch, I may also check out debian sid, or maybe some other rolling distro.

Arch, Funtoo, and Regen2's future

as I've been saying here recently I'm burned out, on so many angles it's not funny. I'm apathetic, I'm not really sure I care anymore. I'm actually playing with arch at the moment to see if it's a better fit. I also here debian sid might work. I don't want to maintain the tree 7 days a week anymore, and I'd like an up to date system.

I've been talking w/ drobbins lately about the possibility of a common tree with funtoo, I'm not sure he wants to do it the same way I do, which is unfortunate. doing this might take the load off me that I don't want, but it's entirely possible that it's too late for it to matter.

I'm going to take a few days and see what happens, it's entirely possible that I'm just going to give up at this point. I'll let people know in a few days what I've decided.

Regen2 0.9.1.0 Released

_Release Highlights_

vanilla-sources-2.6.28.9
gcc-4.3.3
glibc-2.9_20081201-r2
openrc-0.4.3-r1
baselayout-2.0.0-r2
git-1.6.2.3
perl-5.10.0
bash-4.0_p17

app-sh/dash is now included in the tarball, in the next major release I hope to make it /bin/sh please test and report any bugs with doing this. apache2 and mysql are known to have issues. openrc works fine, the average desktop system should work.

_Known Issues_

emerge --sync will not clone the tree if it does not exist in portage 2.1

so for now you'll have to work around that issue. by manually doing the git clone.

_Download_

torrents are here http://www.mininova.org/user/xenoterracide and here http://code.google.com/p/regen2/downloads/list?q=label:0.9.1.0 actual tracker is TPB

http downloads are here http://regen2.devangels.org/release/ thanks to is_null for the mirror. If you're interested in mirroring them let me know. I'll put up a proper mirror list at some point.

EDIT: Thanks to theappleman for more hosting

HTTP (Europe):
http://g.applehq.eu/files/regen2/0.9.1.0/amd64/stage3-amd64-2009.04.18.tar.bz2
http://g.applehq.eu/files/regen2/0.9.1.0/x86/stage3-x86-2009.04.18.tar.bz2

FSP (just for fun ^^, it'd take about 8-9hrs to download the x86):
fsp://fsp.applehq.eu:2009/regen2/0.9.1.0/amd64/stage3-amd64-2009.04.18.tar.bz2
fsp://fsp.applehq.eu:2009/regen2/0.9.1.0/x86/stage3-x86-2009.04.18.tar.bz2

--
Caleb Cushing

http://regen2.org

Looking for tree maintainers

I'd like to see multiple people merging the tree, with best case scenario being that it happens more than once a day. worst case status quo. I'm willing to write the scripts and teach anyone how to do it. I just ask that you can read an ebuild (to some degree) and have good judgement, or at least not too embarrassed to ask. Most ebuild merges are IUSE, KEYWORDS, and cvs line. the rest is really almost automated, merge (del package.mask) merge (fix ebuilds), repoman manifest, gen_metadata, commit, push. This will allow me to focus on other things hopefully, and make the distro better quality.

email the dev list if you're interested.

Regen2 0.9.1.0

I haven't forgotten about it. I seem to lack all motivation on Spring Break. Nothing to procrastinate on. Now that school has started I'm working in full swing, I've been learning metro the past few days. I should have the tarballs ready by the end of the week. I'm not sure on mirrors right now. Have at least one volunteer mirror, and I will be torrent-ing them. I've been seriously procrastinating on finding out how to get on the Uni mirror ring.

~arch will be testing again not stable

I think the idea of a meta distro on top of a stable base is the way to go, let people choose just what they want on bleeding edge. I like my kernel, gcc, and perl solid, sometimes I want firefox's beta's but that doesn't mean I want the rest of the system like that. At some point gentoo's ~arch became more stable that stable, this needs to end. Even if it means making stable a bit more unstable. I'd like to see more people running stable systems.

~arch is going to be aimed more at things that are stable enough, and pending stable. It's going to become more unstable than it is in a sense because I'm not afraid to hardmask stuff that was ~arch and is found to be broken. I'm also not afraid to release slightly broken stuff into ~arch, for example I'll release a new git into ~arch without an update noperl patch which means using -perl won't work. I won't release completely broken or overtly buggy things into ~arch though, I'm just not afraid to release with a missing patch (set) as long as it'll build and work in most cases and update later.

I've decided on a policy for stabilizing the kernel, first of regen2's kernel is vanilla-sources, if you're running another sources this doesn't apply. I will stabilize the previous kernel when the new major version is released so I will stabilize 2.6.28.x when 2.6.29 comes out, after that I will stabilize each new kernel a few days after it hits the tree (actually I may not wait), since the kernel's development model makes it highly unlikely that regressions will be introduced that late in the cycle. I may use a similar update scheme for other packages but it will be a package by package basis. But likely once a major version moves to stable it will be trivial to move new minor versions to stable.

I want to know what people use? what should be stable in regen2. 2 things I won't stabilize right now are qt-4.5 and kde-4.2. They work well enough but have too many bugs upstream, imho (should a kde developer look at this feel free to look at my buglist on your bug tracker, prtscrn must work before I'll mark kde stable, but hey at least dpms works with screensaver now). Anything else goes what do you use/need that's in ~arch and has been there for a long time. feel free to mention in comments, the dev list or the Bug tracker

Regen2 0.9.1.0 soon

Last night I decided I'd be rolling out the first release of Regen2 in the first week of April.

So as I'm sure everyone knows version are arbitrary they mean nothing... well ours are going to mean something. The first 2 numbers are the year, so 20(0.9).1.0. the Third number is the quarter, we are going to be mass stabilizing system once per quarter. I'm not sure that this will include new profiles. 4rth number is kinda arbitrary at this point, I'm not sure how/if I want to use it, opinions welcome. since releases will be 'stable' I could use 0 as kind of an alpha, first release. 1 as beta, 2 as rc, and 3 as final. I could also do a 0-alpha1, 0-beta1, etc. and when stage4's and other stuff are rolled out use the version number to denote updated non-system software. In other words I could do releases each month of say kde in stage4's but I wouldn't change system more than once a quarter.

So far my list of packages that'll be marked stable include.

gcc-4.3.3(maybe r1)
glibc-2.9_20081201-r2
openrc-0.4.3-r1
baselayout-2.0.0-r2
git-1.6.2.1
perl-5.10.0

I'll have to spend the next few days figuring out the rest.

I'm debating also on whether I'm locking down major or minor versions. meaning I might consider stabilizing gcc-4.3.4 in the middle of this quarter but not gcc-4.4.

I'm open to opinions on anything. This may be a dictatorship, but I still don't mind hearing from people not me, as with enough eyes all bugs are shallow.

Tree hasn't been updated - why

So 2 days ago, when I went to sync to gentoo I didn't get any updates. I'm not really sure why as the process seemed to go alright. It could have something to do with the next bit.

My System appeared to have been compromised. Syslog-ng was disabled and all logs post dec 30 2008 were removed. So i've spent the better part of yesterday/today reinstalling my system. Tree should be synced and merged tonight.

SYNC_METHOD

I'm going to be pushing out an new feature to portage today, since testing has gone well.

SYNC_METHOD is a new portage variable, I've also gone to the trouble of defining it in make.globals. The default for Regen2. is git, however, rsync and cvs have also been defined although not tested.

the main benefit of SYNC_METHOD is to use one way of detecting the program you should use to detect the tree. previous variations were problematic, as rsync does not have a directory like .git and .git supports the rsync:// protocol.

I've added these defaults to make.globals

# Default sync method
SYNC_METHOD="git"

# Default sync mirror
SYNC="git://github.com/regen2/portage.git"

# default git method specific settings
PORTAGE_GIT_METHOD="checkout"
PORTAGE_GIT_REMOTE="origin/regen2.org"

you may of course override them with make.conf.

changes will officially be in portage-2.2_rc23-r3.

to Gentoo dev or not to Gentoo dev

So after a little post about Regen2 on the Gentoo-dev mailing list. I've been offered mentoring to become an official gentoo dev. I'm conflicted, my main reason for saying yes would be to learn stuff that I can't learn on my own. But I'm not sure I really want to be a gentoo-dev this means doing these other time consuming things, and I wouldn't be able to do nearly enough from the inside. I still have to proceed with regen2... as I don't believe gentoo (in spirit) can be saved from within. So should I work to become an offical gentoo dev?

regen2 maintaining it's own openrc

So openrc was updated recently, and I noticed it, I decided it was time to find out why drobbins had created his own version. so I viewed them, ultimately I decided that drobbins had made too many changes but the gentoo ebuild had its own issues. So I modified the Gentoo ebuild to use EAPI 2, removed all of the live ebuild code that shouldn't be in it, updated the branding, and we're ready to rock.

split package.mask

There's been a problem with ${PORTDIR}/profiles/package.mask since I added sunrise, I didn't realize at the time the problem wouldn't be adding atoms, it would be keeping track of when they should be removed. I've decided that the best way to do it is to use portages 'directory concatenation' feature, I turned package.mask into a directory, it now contains a file for each overlay that has a package.mask, and one for gentoo.org and regen2.org. This will make it much easier to keep track of removals. They originals are being merged in from a package.mask 'overlay' on regen2's github account. Let me know if anything is now masked that shouldn't be or unmasked that shouldn't be.

merged java-overlay

Java in Gentoo is horribly out of date, and from what I've seen of the java overlay, it doesn't improve the situation much, but it's still better than without it. I've merged it into regen2.org, since this was I think the most painful merge since the first I ever did, I may have made mistakes on some ebuilds, let me know if you experience problems.

USE="experimental-git" sys-apps/portage

drobbins recent tip made me think, that maybe I should point out that his solution to the problem is an annoying work around. I had this problem for a while, it was caused by my having autocrlf = input in my .gitconfig settings. Several people have told me that they have this problem without changing their crlf settings for git. After a while I decided that Funtoo/Gentoo's git handling patches were incomplete at best and unfriendly at worst. So I wrote a patch that brings complete git handling to portage.

Why is it experimental? well it hasn't been officially accepted into portage, and as far as I know I'm the only one using it. One of the reason's it's not officially accepted is I haven't documented it.

WARNING: enabling it will cause auto git detection to fail, so if you don't finish setting it up portage will default to rsync.

So first you need to be using my regen2 tree, or get the ebuild and the patch from my tree, and enable the experimental-git flag for sys-apps/portage.

Now, like all the other protocols portage supports you need to set the SYNC variable in /etc/make.conf.

SYNC="git://github.com/regen2/portage.git"

the first 6 characters need to be git:// for git to work.

if you don't already have a git repository then sync will clone the repository at this url, in fact you may need to delete your portage and do a fresh clone for things to work in certain situations. I never discerned the reason for this.

now you need to set your method the most reliable, yet slowest is checkout.

PORTAGE_GIT_METHOD="checkout"

I believe this method will never experience the problem that drobbins was referring to.

for checkout you also need to set the remote branch you want to run off.

PORTAGE_GIT_REMOTE="origin/regen2.org" changing this variable and resyncing will allow you to change branches. checkout is even immune to upstreams forced updates, which is why I prefer to use it myself as sometimes I force updates on my development branch.

PORTAGE_GIT_LOCAL="regen2.org" is also a valid variable, however checkout doesn't use it. It's used by the methods rebase, which will run the git rebase command, this is recommended for people who don't run their own remote repo yet have there own custom git patches.

The final method available is merge, it works similar to the current pull behavior of portage, except it will actually merge from whatever remote you have specified into whatever local you have specified.

all methods use git remote update to avoid problems figuring out where to get updates from. I had problems with git knowing what to do with pull, when my origin was my personal repo on github and where I really needed to be updating from was funtoo not origin.

WARNING: git-experimental will probably be where I merge patches such as the upcoming manifest patch.

Banned from #funtoo

After significant time, consideration, and consultation with others in #funtoo, there is a consensus that the discussion in #funtoo should focus on Funtoo. Therefore, I have decided to ban you from #funtoo and encourage you to set up your own channel(s) for your personal efforts.
Please utilize Daniel Cordero (TheAppleMan) as your liaison for submitting patches and discussing technical issues.

I like how all of this was done behind the scenes... oh and I was never asked to leave. I just woke up this morning banned. I find it interesting that Gentoo and Sabayon are considered ok topics of discussion, and I probably wouldn't have gotten banned for saying use one of those. But Regen2 seems to be a sore spot. I would have left if asked... I find the ban unnecessary. Or maybe I would have just idled watching for bug reports, I've unfortunately ended up laughing at most of them, as there have been quite a few on qt, and I preemptively masked the new qt, knowing that upstream wouldn't have it all sorted yet. Anyways... I'd like to state that I personally disagree with all the private discussions that go on in Funtoo. In gentoo the problems are public and distracting, when I was part of Funtoo, they were made private, this does not appear to be different now. It's possible this was discussed in #funtoo-dev as I stopped hanging out in that room when I stopped being a funtoo-dev. I think in general it's a bit hypocritical. I suppose you could say, "you were asked to not talk about regen2 what did you expect?", I didn't actually expect not to get banned, I did expect to be asked to leave, or shut up, with the threat of being banned first.

Daniel Cordero (TheAppleMan) has offered to grab patches from the regen2-dev mailing list. no solution for overlays for funtoo was ever decided. I have left it up to them to figure it out, since I refuse to maintain both my tree and apply patches to theirs... (and remove them when they don't want them). I can't actually guarantee either my individual patches or the overlays will be merged.

I'll be continuing to import patches from funtoo, although recently I realized it will be most likely impossible to get them all as drobbins commits quite a few patches during his merges. I recently found out that udev had been updated and had some house cleaning done (there is no stable udev in funtoo now (I think I didn't actually check keywords)) all versions before 135 are gone. So I checked to see if I missed a patch... I didn't which means it was changed in a merge... those are the only commits affecting those directories.

Best of luck to Funtooers.

NOTE: ah... I apologize for the formatting issue in the blockquote, seems to be a problem with blogger. I've fixed it best I can.

open letter to Dan Robbins - merge regen2

I had an interesting conversation with thewtex on #funtoo yesterday. My conclusion is, this divergence of tree's is stupid. We should be working on a common base, at least common enough that users could relatively easily merge our tree's. My tree is currently ahead of yours in content by 3 sunrise merges, 1 mpd, and the 2 merges of the python overlay. Your users can't easily get these updates.

Due to the fact that we have irreconcilable views on what patches we allow, the fork must remain. However, users don't have to suffer for it. The solution is to base funtoo.org on regen2.org. I can't base regen2.org on funtoo.org because I have stricter QA policies, however those policies shouldn't negatively affect funtoo, I can continue to cherry-pick patches that you wish to put into funtoo, so they end up in regen2 as well.

This will require that you, trust me enough to merge the tree. I will be handling the gentoo and overlay merges. You will simply merge my tree daily.

In order to resolve the differences of the tree as they stand I suggest creating a funtoo.org2 branch that's based on regen2.org and discontinuing the maintenance of funtoo.org. cherry-pick any patches I haven't applied to regen2 (I can point out which ones) and apply any other changes you need to. The other option is to merge my tree, this will be painful and arduous for you, but require no work on the part of your users.

This resolves many problems. 1 you won't have to deal with the main tree or overlays, 2 you won't have to run your patches by me and can do what you want, 3 users get the best of both worlds, 4 developers can choose to email you inline patches, or send me pull requests. Everyone should go home happy from this.

what say you?

P.S. I will not have it said that I want a rift in the community, I want whats best for all kinds of users and the status quo is not.

EDIT: in short the answer is no. drobbins doesn't want to merge my tree, as it's supposedly untrusted, he also doesn't want to cherry-pick patches out of my tree. I don't want to spend time merging the overlays just for Funtoo, on top of merging them for Regen2. Apparently my bug fixes, and version bumps aren't good enough for Funtoo.